¿Requisito funcional o no funcional?

Me pregunto sobre los requisitos funcionales o no funcionales. He encontrado muchas definiciones diferentes para esos términos y no puedo asignar algunos de mis requisitos a la categoría adecuada.

Me pregunto sobre los requisitos que no están relacionados con alguna acción o que tienen algunas condiciones adicionales, por ejemplo:

1. En la lista de dispositivos seleccionados, el dispositivo puede repetirse.
2. La base de datos debe contener al menos 100 elementos.
3. La moneda de algún valor debe estar en dólares estadounidenses.
4. El dispositivo debe tener un nombre y un valor de consumo de energía en vatios.

¿Son esos requisitos funcionales o no funcionales?

Los requisitos funcionales definen lo que hará el sistema o la aplicación, específicamente en el contexto de una interacción externa (con un usuario o con otro sistema).

Al realizar un nuevo pedido, el sistema mostrará el costo total y requerirá la confirmación del usuario. Ese es un requisito funcional; Describe una función del sistema.

Consulte Wikipedia: Requisito funcional para más detalles.

Los requisitos no funcionales son requisitos que no describen el comportamiento de entrada / salida del sistema. Tenga en cuenta que todavía estamos hablando de requisitos , no de detalles de implementación , por lo que solo porque estamos usando la frase "no funcional" no significa que algo sea ​​un juego justo para poner en esa sección.

Los tipos más comunes de requisitos no funcionales que verá se relacionan con la operación del sistema (disponibilidad, continuidad, DR), rendimiento (rendimiento, latencia, capacidad de almacenamiento) y seguridad (autenticación, autorización, auditoría, privacidad).

Estas son todas las preocupaciones transversales que afectan a cada "característica", pero en realidad no son características en sí mismas; son más como metadatos de funciones, que ayudan a describir no solo si el sistema hace lo que se supone que debe hacer sino también qué tan bien lo hace. Sin embargo, no lleves esa analogía demasiado lejos, es solo una analogía.

Los requisitos no funcionales no son subjetivos ni manuales, al contrario de lo que algunas personas parecen sugerir aquí. De hecho, deberían tener una métrica rígida (es decir, un tiempo de respuesta de no más de 100 ms). NF requisitos son también no detalles de implementación o tareas como "actualizar el marco ORM" - ninguna pista donde cualquier persona podría conseguir esa idea.

Más detalles en Wikipedia: Requisito no funcional .

Para abordar específicamente los ejemplos en la pregunta:

1. En la lista de dispositivos seleccionados, el dispositivo puede repetirse.

   • Claramente un requisito funcional. Describe cómo se ve la salida del sistema.

2. La base de datos debe contener al menos 100 elementos.

   • Suena como una regla de negocios, también un requisito funcional. Sin embargo, parece incompleto. ¿Cuál es la razón de esta regla? ¿Qué sucederá / debería suceder si la base de datos contiene menos de 100 elementos?

3. La moneda de algún valor debe estar en dólares estadounidenses.

   • Requisito funcional, pero no realmente uno debidamente establecido. Una redacción más útil sería: El sistema admitirá una moneda (USD). Obviamente, esto se enmendaría si se necesitara más de una moneda, y luego el requisito tendría que incluir información sobre las conversiones de moneda, etc.

4. El dispositivo debe tener un nombre y un valor de consumo de energía en vatios.

   • No es realmente ningún tipo de requisito, esto se parece más a una especificación técnica. Se establecería un requisito funcional ya que se supone que la potencia nominal está en vatios. Si hay más de una UOM, entonces, al igual que con la moneda, los requisitos funcionales deben tener secciones sobre conversiones de unidades, dónde / cómo se configuran, etc. (si corresponde).

Ya existe una excelente respuesta de Aaronaught, pero dado que había otras respuestas, ahora eliminadas, que estaban totalmente equivocadas sobre qué es un requisito no funcional, creo que sería útil agregar algunas explicaciones para evitar los errores sobre qué requisito no funcional es.

Un requisito no funcional es "una cualidad, o propiedad que el producto debe tener" ¹. James Taylor dice que un requisito no funcional "[...] es [no obstante] un requisito, y es importante para el cliente, a veces incluso más importante que un requisito funcional" . Luego da dos ejemplos: el logotipo del producto y la precisión y confiabilidad del equipo. Esos dos ejemplos muestran muy bien que:

• Los requisitos no funcionales no son una comercialización parloteo como: "Internet es importante hoy en día y que quieren tener un sitio web".
• Los requisitos no funcionales conciernen a los clientes, ya que pueden tener un gran impacto en su productividad y en la capacidad misma de usar el producto.
• Los requisitos no funcionales son totalmente objetivos.

El último punto es esencial. Si el requisito es subjetivo, no tiene nada que ver en la lista de requisitos. Sería imposible construir pruebas de validación a partir de algo que sea subjetivo . El único propósito de la lista de requisitos es enumerar las expectativas no ambiguas del cliente. "Quiero que este cuadrado sea rojo" es un requisito. "Quiero que este cuadrado tenga un color agradable" es un deseo que requiere explicación.

Recuerde que la lista de requisitos es como un contrato (y en la mayoría de los casos es parte de un contrato). Está firmado por el cliente y la empresa de desarrollo, y en caso de litigio, se usará legalmente para determinar si ha realizado su trabajo correctamente. ¿Qué sucede si le pido un producto de software, especifico que "el producto debe ser excelente" y me niego a pagar cuando el producto está listo, porque para mí, lo que realmente ha hecho no es un producto excelente ?

Entonces, veamos algunos ejemplos.

  1. El producto de software responde al usuario final.

Esto no es un requisito. No es funcional. No es un no funcional. Simplemente no es un requisito. En absoluto. Tiene valor cero. No puede verificar si el sistema de software cumple con este requisito durante las pruebas de validación. Ni usted, ni el departamento de control de calidad, ni el cliente.

  2. La recarga de las estadísticas del usuario se realiza el 90% del tiempo por debajo de 100 ms. cuando se prueba en la máquina con los rendimientos especificados en el apéndice G parte 2 y la carga por debajo del 10% para la CPU, por debajo del 50% para la memoria y sin operaciones de disco R / W activas.

Es un requisito. Si el apéndice G parte 2 es lo suficientemente preciso, puedo tomar la máquina con el hardware similar y realizar la prueba de validación en el departamento de control de calidad, y siempre obtendré un resultado binario: aprobado o reprobado.

¿Es un requisito funcional? No. No especifica qué debe hacer el sistema. Probablemente hubo un requisito funcional antes, especificando que la aplicación de software debe poder recargar las estadísticas del usuario.

¿Es un requisito no funcional? Es. Especifica una propiedad que debe tener un producto, es decir, el tiempo de respuesta máximo / promedio, dado el umbral de porcentaje.

  3. La aplicación está escrita en C #.

¿Es esto un requisito? Realmente no lo sabemos sin un contexto. Podría ser un deseo del desarrollador principal, que quiere, al insertar este requisito, evitar más adelante una discusión con sus colegas sobre el lenguaje que se utilizará. También podría ser un requisito basado en hardware / software, elementos heredados o de compatibilidad. No lo sabemos

  4. La base de código C # del producto sigue las Reglas mínimas recomendadas de Microsoft y las Reglas de globalización de Microsoft.

Esto es algo extraño Personalmente, preferiría no llamarlo un requisito y ponerlo en un documento separado que especifique los estándares y las mejores prácticas.

  5. La ventana principal de la aplicación tiene un borde azul (# 00f) de 10px con círculos rellenos de rosa (#fcc), esos círculos se colocan en el borde interno del borde y tienen un diámetro de 3px, separados por 20px entre sí.

Es un requisito y no funcional. Especifica algo que podemos probar durante las pruebas de validación, y especifica una propiedad del producto, no lo que el producto está destinado a hacer.

  6. El sistema de seguimiento del vehículo mide la velocidad con una precisión de ± 0.016 mph.

También un requisito no funcional. Da un umbral medible de la precisión del sistema. No dice qué debe hacer el sistema, pero sí qué tan preciso es hacer su trabajo. ¿Pero espera? Indica que el sistema de seguimiento del vehículo mide la velocidad, ¿no es así? Entonces, ¿es un requisito funcional también? Bueno, no, ya que ponemos énfasis en la precisión de la medición, no en el hecho de que la medición se realiza.

  7. El sistema de seguimiento del vehículo mide la velocidad del vehículo.

Ahora es un requisito funcional. No dice cómo funciona el sistema, sino qué está haciendo. A través de los requisitos funcionales, podríamos aprender que el sistema de seguimiento del vehículo mide la velocidad, la energía de la batería, la presión de No sé qué y si las luces están encendidas o no.

  8. Las páginas del sitio web tardan 850 ms. cargar.

Esto no es un requisito. Se trata de ser uno, pero es totalmente inválido. ¿Cómo valorarías esto? Que paginas ¿Todos? Probado a través de una red local de 1 Gbps en una máquina cliente de cuatro núcleos y un servidor de ocho núcleos con SSD utilizados al 2%, o mediante un módem de una computadora portátil vieja y mala mientras el sitio web está alojado en un pequeño servidor utilizado al 99% ? ¿Qué se entiende por "cargar"? ¿Significa descargar la página? ¿Descargarlo y mostrarlo? ¿Enviar la solicitud POST con algunos datos grandes, luego cargar la respuesta y mostrarla?

Para concluir, un requisito no funcional siempre es un requisito, lo que significa que describe algo que es totalmente objetivo y puede verificarse mediante una prueba de validación automática o manual, pero en lugar de decir qué está haciendo el sistema, explica cómo funciona el sistema. está haciendo algo o cómo es el sistema en sí .

^{¹ Gestión de proyectos de tecnología de la información: aplicación de estrategias de gestión de proyectos a iniciativas de software, hardware e integración, James Taylor, ISBN: 0814408117.}

Un requisito funcional describe el resultado de interactuar con el sistema (lo que el sistema hace en situaciones determinadas), mientras que el requisito no funcional generalmente se refiere a aspectos específicos de rendimiento, capacidad, tiempo de respuesta, etc., cosas que no representan funcionalidad, un proceso en el sistema, o el resultado de una interacción.

Dicho esto, el requisito no funcional que está describiendo es en realidad un requisito funcional con una especificación técnica (lo que en realidad lo convertiría en un mal requisito). Un ejemplo de un requisito no funcional para su caso sería algo como esto:

- La IU no debe bloquearse mientras se ejecuta la animación de los dados.

Los requisitos del usuario suelen ser requisitos específicos de la interfaz de usuario, que, según el contexto, serían funcionales o no funcionales, mientras que los requisitos del sistema (capacidad de usuario concurrente, por ejemplo) generalmente no son funcionales.

Solo para agregar a algunas buenas respuestas existentes, los requisitos no funcionales a veces se denominan "ilidades", cualidades que el sistema debe poseer además de su funcionalidad simple. Las "ilidades" incluyen disponibilidad, usabilidad, seguridad, flexibilidad e incluso una estética más subjetiva.

Algunos de estos son muy difíciles de especificar y evaluar. Sin embargo, ellos importan. Si se suscribe a ellos por contrato, entonces querrá evitar las versiones sin sentido onduladas a mano, por ejemplo, "El sistema debe ser seguro". El problema al tratar de concretar tales requisitos es que las personas tienden a gravitar hacia las cosas que son fácilmente medibles, en lugar de las cosas que importan (y los requisitos pueden ser escritos por personas que no tienen ninguna base en las especialidades relevantes ) El resultado final es que generalmente terminas con sistemas que no son seguros, utilizables ni flexibles (la disponibilidad no es tan difícil de especificar y medir, aunque todavía causa muchos dolores de cabeza).

Aquí hay diferencias culturales entre las personas que se ocupan de contratos y asuntos formales, y las personas que se ocupan de un análisis más general, arquitectura, investigación, etc. Un requisito vago de ondulación manual sigue siendo un requisito en lo que respecta a este último, porque expresa cosas que le importan al cliente, incluso si simpatizan completamente con la gente contractual que no es un requisito contractual útil hasta que haya sido explorado en detalle y completamente aclarado.

Un último punto: si no puede (todavía) llegar a una medida objetiva de una "ilusión", eso no significa que el cliente no la necesite. ¡Vago! = Innecesario. Sin embargo, puede significar que necesitamos desarrollar mejores formas de medir tales cosas, obtener y refinar los requisitos no funcionales de forma incremental, o contraer de manera (ágil, etc.) que puedan funcionar sin medidas objetivas por adelantado para todo.

Todos estos comentarios son muy buenos, pero están demasiado cocinados y no ofrecen una plantilla clara para trabajar. ¿No sería claro especificarlo como:

En mi opinión, un requisito funcional es lo que el usuario experimenta cuando usa la aplicación. Es un requisito que debe cumplirse cuando un desarrollador intenta implementar esto desde cero, hacer mejoras o modificaciones. Por ejemplo: el usuario debe iniciar sesión. Digamos que si también agrega una nueva forma de ejecutar la aplicación a través de un símbolo del sistema, el usuario aún debe iniciar sesión.

Un requisito no funcional ocurre debajo del capó. El usuario no lo sabe, pero tiene que estar allí, sin embargo, está implementado. Por ejemplo: la aplicación debe desarrollarse en C #. Si se desarrolla en cualquier otro idioma, el usuario no lo notará. Pero eso puede ser un requisito porque se basa en el código existente. Otro ejemplo sería que debe instalarse en cierto servidor. Mover servidores no sería notado por el usuario.

Funcional o no funcional? Yo diría que ninguno. La mayoría, si no todos los ejemplos enumerados me parecen reglas de negocios (especificando restricciones relacionadas con el proceso y reglas de decisión que los procesos del sistema deben seguir).

Son algo que muchos ingenieros olvidan o desconocen, ya que las reglas comerciales generalmente se recopilan como parte del análisis comercial (y a menudo se integran en especificaciones de requisitos funcionales en lugar de referencias externas).

Un requisito funcional es típicamente algo que el sistema puede o hará. Se puede expresar como resultado de una acción (De un resultado negativo). Un requisito no funcional es algo que al cliente / usuario final no le importa y no afecta el resultado; por ejemplo
, Windows tendrá un borde azul con puntos rosados. - El programa se escribirá en Java.
- Todo lo que tenga que ver con estándares, métodos y procesos de codificación.

Sin embargo, tenga en cuenta que los requisitos no funcionales pueden convertirse en requisitos funcionales por parte de los clientes. ejemplos podrían ser: el programa se escribirá en Erlang porque el cliente leyó un artículo de la revista y quiere que esté escrito en Erlang. - El programa debe usar DB 2. porque el cliente lo va a ejecutar en sus sistemas DB 2 existentes, tiene años de experiencia y un equipo de TI familiarizado con esa plataforma.
- El código fuente debe pasar todas las recomendaciones de MISRA.

En resumen, si al cliente le importa, es un requisito funcional, de lo contrario es un requisito no funcional o posiblemente ni siquiera un requisito.

Creo que los requisitos funcionales son algo necesario para describir el sistema y su comportamiento, pero los requisitos no funcionales no son necesarios para el sistema y no se reunieron durante las negociaciones del diseño del sistema son solo el resultado del sistema, como la calidad de la cobertura de velocidad , seguridad, mantenibilidad, etc. del sistema construido.