¿Qué es el requisito no funcional en ingeniería de software?

Por: Charles moore Charles moore
Hours Actualizado

⚡ Resumen inteligente

Los requisitos no funcionales especifican atributos de calidad como el rendimiento, la seguridad, la usabilidad, la fiabilidad, la escalabilidad y la portabilidad, definiendo el buen comportamiento que debe tener un sistema de software y transformando expectativas vagas en objetivos de ingeniería medibles, comprobables y exigibles a lo largo del ciclo de vida de la entrega.

  • 📘 Definición: Un requisito no funcional, o NFR por sus siglas en inglés, describe el rendimiento de un sistema en términos de desempeño, seguridad, usabilidad, confiabilidad y portabilidad.
  • 🗂️ Tipos comunes: Usabilidad, seguridad, confiabilidad, escalabilidad, capacidad, disponibilidad, mantenibilidad y cumplimiento normativo son las categorías que trabajan los equipos. track con mayor frecuencia.
  • 📊 Modelo FURPS+: FURPS+ agrupa los requisitos no funcionales (RNF) en función de su funcionalidad, usabilidad, fiabilidad, rendimiento, capacidad de soporte y limitaciones de diseño o interfaz.
  • 🎯 Declaraciones comprobables: Sustituya los términos "rápido" o "seguro" por umbrales numéricos y métodos de verificación para que el requisito no funcional pueda ser probado y aceptado.
  • 🆚 Contraste funcional: Los requisitos funcionales establecen lo que hace el sistema; los requisitos no funcionales establecen qué tan bien lo hace en condiciones reales.
  • ✅ Impacto de negocios: La falta de requisitos no funcionales es la principal causa de incidentes en producción, hallazgos regulatorios y costosas reelaboraciones de arquitectura en etapas avanzadas.
Descubre más

Requisitos no funcionales en ingeniería de software

¿Qué es un requisito no funcional?

A Requisito no funcional Un requisito no funcional (RNF) especifica un atributo de calidad de un sistema de software. Los RNF evalúan el sistema en función de su capacidad de respuesta, usabilidad, seguridad, portabilidad y otros atributos de calidad que son fundamentales para el éxito. Un ejemplo común de requisito no funcional es: "¿Qué tan rápido se carga el sitio web?" El incumplimiento de los requisitos no funcionales da como resultado sistemas que frustran a los usuarios.

En ingeniería de software, los requisitos no funcionales imponen restricciones al diseño del sistema en todo el backlog ágil. Por ejemplo, el sitio debe cargarse en tres segundos cuando los usuarios concurrentes superan los 10 000. Describir los requisitos no funcionales es tan crucial como capturar los requisitos funcionales.

Tipos de requisitos no funcionales

Las principales categorías de requisitos no funcionales son:

Tipos de requisitos no funcionales

Tipos de requisitos no funcionales

  • usabilidad
  • Utilidad
  • Manejabilidad
  • Recuperabilidad
  • Seguridad
  • Datos Integrity
  • CAPACIDAD
  • Disponibilidad
  • Escalabilidad organizacional
  • Interoperabilidad
  • Confiabilidad
  • Mantenibilidad
  • Cumplimiento de la normativa
  • Limitaciones ambientales

Ejemplos de requisitos no funcionales

Aquí se presentan ejemplos prácticos de requisitos no funcionales:

  1. Los usuarios deben cambiar la contraseña inicial después del primer inicio de sesión exitoso, y la contraseña inicial nunca debe reutilizarse.
  2. Los empleados no podrán actualizar su propia información salarial, y cualquier intento de hacerlo deberá ser comunicado al administrador de seguridad.
  3. Todo intento fallido de un usuario por acceder a un elemento de datos quedará registrado en un registro de auditoría.
  4. El sitio web deberá soportar 20 millones de usuarios simultáneos sin que se degraden los tiempos de respuesta.
  5. El software deberá ser portable, de modo que el cambio de un sistema operativo a otro no genere problemas.
  6. La privacidad de la información, la exportación de tecnologías restringidas y los derechos de propiedad intelectual serán auditables.

Requisitos funcionales y no funcionales

Las principales diferencias entre los requisitos funcionales y no funcionales son:

Parámetros Requerimiento funcional Requisito no funcional
¿Qué es? Verb Atributos
Requisito Es obligatorio es no obligatorio
Tipo de captura Se captura en el caso de uso. Se capta como un atributo de calidad.
Resultado final característica de producto Propiedades del producto
Capturando Fácil de capturar Difícil de capturar
Objetivo Le ayuda a verificar la funcionalidad del software. Le ayuda a verificar el rendimiento del software.
área de enfoque Centrarse en los requisitos del usuario Se concentra en las expectativas del usuario.
Documentación Describe lo que hace el producto. Describe cómo funciona el producto.
Tipo de prueba Prueba de funcion como sistema, integración, de extremo a extremo, pruebas de API, etc. Pruebas no funcionales como pruebas de rendimiento, estrés, usabilidad, seguridad, etc.
Ejecución de pruebas La ejecución de la prueba se realiza antes de las pruebas no funcionales. Después de las pruebas funcionales
Información del producto Características del producto Propiedades del producto

ARTÍCULOS RELACIONADOS

Ventajas de los requisitos no funcionales

Los principales beneficios de Pruebas no funcionales son:

  • Los requisitos no funcionales garantizan que el sistema cumpla con las normas legales y de cumplimiento.
  • Protegen la fiabilidad, la disponibilidad y el rendimiento del sistema.
  • Ofrecen una buena experiencia de usuario y facilidad de manejo.
  • Definen la política de seguridad del software.

Desventajas de los requisitos no funcionales

Las desventajas comunes de los requisitos no funcionales son:

  • Los requisitos no funcionales pueden afectar a varios subsistemas de software de alto nivel.
  • Requieren una consideración especial durante la arquitectura y el diseño de alto nivel, lo que aumenta el costo.
  • La implementación rara vez se corresponde con un único subsistema de software.
  • Son difíciles de modificar una vez que se ha completado la fase de arquitectura.

Modelo FURPS+ para la clasificación de requisitos no funcionales

FURPS+ es la taxonomía más utilizada para los requisitos no funcionales. Desarrollada originalmente en Hewlett-Packard, agrupa los atributos de calidad en cinco categorías principales, además de restricciones adicionales marcadas con el signo "+". Este modelo ayuda a los analistas de negocio a evitar pasar por alto una clase completa de requisitos.

  • Funcionalidad: Capacidad, seguridad y reutilización que van más allá de la lista de funciones básicas.
  • Usabilidad: Factores humanos, estética, coherencia, documentación y capacidad de respuesta de la experiencia del usuario.
  • Fiabilidad: Disponibilidad, tiempo medio entre fallos, capacidad de recuperación, previsibilidad y precisión.
  • Actuación: Velocidad, rendimiento, capacidad, escalabilidad y consumo de recursos bajo carga.
  • Compatibilidad: Capacidad de prueba, flexibilidad, facilidad de instalación, adaptabilidad y facilidad de mantenimiento del sistema entregado.
  • Más (+): Diseño, implementación, interfaz y limitaciones físicas, como plataformas, estándares o hardware requeridos.

Los equipos que asignan cada requisito no funcional a una categoría FURPS+ tienen menos probabilidades de lanzar un sistema que cumpla con las funcionalidades pero falle en cuanto a rendimiento, seguridad o mantenibilidad.

Cómo redactar requisitos no funcionales que puedan ser comprobados

Un requisito no funcional bien redactado es medible, verificable y tiene un plazo definido. Las afirmaciones vagas como «el sistema debe ser rápido» o «la aplicación debe ser segura» son aspiraciones, no requisitos. Siga los pasos a continuación para convertir una intención en un requisito no funcional comprobable.

  1. Identifique el atributo de calidad. Asigne la inquietud a una categoría FURPS+ para que el equipo sepa si se trata de un requisito de rendimiento, usabilidad, seguridad o confiabilidad.
  2. Elige una métrica. Cada requisito no funcional (NFR) necesita una unidad de medida: milisegundos, solicitudes por segundo, usuarios concurrentes, porcentaje de tiempo de actividad o un estándar de cumplimiento como la norma ISO 27001.
  3. Establezca un umbral numérico. Sustituya “rápido” por “menos de 400 milisegundos en el percentil 95”. Sustituya “altamente disponible” por “99.9 por ciento de tiempo de actividad mensual”.
  4. Describe la condición. Indique la carga, el entorno o el segmento de usuarios al que se aplica el umbral, por ejemplo, "durante las horas pico de ventas con 10,000 usuarios simultáneos".
  5. Defina el método de verificación. Anote el tipo de prueba (prueba de carga, prueba de penetración, experimento de caos, auditoría de accesibilidad) y la herramienta que confirmará el umbral.
  6. Aplique la verificación SMART. Confirme que el requisito sea específico, medible, alcanzable, relevante y con plazos definidos antes de que entre en la lista de tareas pendientes.

Ejemplo de reescritura: “El sistema deberá ser rápido” se convierte en “La página de pago deberá responder en menos de 500 milisegundos en el percentil 95 con 5,000 usuarios concurrentes, verificado por un JMeter “Prueben la carga de cada versión”. La declaración revisada permite a los desarrolladores diseñar teniendo esto en cuenta, a los evaluadores verificarlo y a los propietarios del producto aceptarlo sin objeciones.

Preguntas Frecuentes

Las herramientas de carga y rendimiento basadas en IA generan tráfico realista, detectan anomalías en las distribuciones de tiempo de respuesta y predicen los límites de escalabilidad antes de la puesta en producción. La IA también inspecciona los registros y los patrones de acceso para detectar eventos de seguridad que las herramientas tradicionales basadas en reglas pasan por alto.

Copilot y GPT transforman declaraciones de calidad vagas en requisitos no funcionales (RNF) medibles mediante métricas, umbrales, condiciones y métodos de verificación. Los analistas de negocio revisan cada borrador comparándolo con las categorías FURPS+ y el marco SMART antes de incorporarlo a la lista de tareas pendientes.

Las pruebas funcionales verifican si las características se comportan correctamente, como el inicio de sesión o la búsqueda. Las pruebas no funcionales miden el rendimiento del sistema bajo carga, estrés y uso, abarcando objetivos de rendimiento, seguridad, usabilidad, compatibilidad y confiabilidad.

La escalabilidad, la disponibilidad, la latencia, la elasticidad y la rentabilidad dominan los requisitos no funcionales de la nube. Los equipos también tracLa observabilidad, los objetivos de recuperación ante desastres como RPO y RTO, y el cumplimiento en múltiples regiones son factores clave, ya que impulsan la mayoría de las decisiones sobre la arquitectura en la nube.

Seleccione una métrica con una unidad, establezca un umbral numérico, describa la condición bajo la cual se aplica y nombre el método de verificación. Por ejemplo, tiempo de respuesta inferior a 400 milisegundos en el percentil 95 con 5,000 usuarios, verificado por JMeter.

El cifrado de datos en reposo y en tránsito, la solidez de la autenticación, la autorización basada en roles, el registro de auditoría, el tiempo de espera de la sesión y el cumplimiento de estándares como ISO 27001, PCI DSS y GDPR son los requisitos no funcionales de seguridad que la mayoría de los equipos documentan.

El uso de adjetivos vagos, la omisión de la métrica o la condición, la inclusión de los requisitos no funcionales solo al final de un proyecto y la copia y pegado de código repetitivo que ninguna prueba puede verificar son los errores más comunes que conducen a una reelaboración de la arquitectura en etapas avanzadas.

Los requisitos no funcionales (RNF) se encuentran en la especificación de requisitos de software, los registros de decisiones de arquitectura, los acuerdos de nivel de servicio y las listas de verificación de definición de finalización. Los equipos ágiles suelen asociar RNF medibles a las épicas y a la definición de listo para cada historia de usuario.

Resumir este post con: