¿Por qué molestarse en diferenciar entre requisitos funcionales y no funcionales?

Entiendo la diferencia entre los dos, pero mis colegas me preguntan sobre el beneficio de etiquetar los requisitos como funcionales o no funcionales (o de transición). ¿Por qué molestarse en hacerlo? Pasó lo que dijo que fue dos días revisando una lista de requisitos para un proyecto, y no vio ningún beneficio, porque el resultado final fue enviar el documento a otra entidad comercial con el edicto "Hazlo todo".

Lo que temo son los requisitos agrupados en un solo documento. Traté de explicar el beneficio en términos prácticos, pero no pude venderlo. ¿Cómo vendo el beneficio de documentar qué requisitos son funcionales y cuáles no?

La separación explícita de los requisitos facilitará el diseño del sistema correcto.

Con requisitos no funcionales (prefiero los atributos de calidad de concepto / término - debería proporcionar nuevas ideas más allá de funcional frente a no funcional), usted está más preocupado por las propiedades del software que por la funcionalidad. Así es como el sistema realiza alguna función, no simplemente lo que hace el sistema. Los requisitos de calidad tienen una influencia significativa en la arquitectura del sistema en formas que los requisitos funcionales no tienen y, por esta razón, deben tratarse de manera diferente.

Mantener los atributos de calidad separados de los requisitos funcionales le permite analizar, especificar y priorizar diferentes tipos de requisitos de diferentes maneras. Por ejemplo, los atributos de calidad normalmente se especifican usando un escenario de atributos de calidad, mientras que los requisitos funcionales pueden tomar la forma de historias, casos de uso, declaraciones o cualquier otro número de formatos. La mayoría de los sistemas en los que he trabajado tenían menos de una docena de atributos de calidad y muchos, muchos más requisitos funcionales.

En realidad, introduciría otro tipo de requisitos: restricciones técnicas . Una vez más, la separación explícita de los requisitos en estos tres grupos le da pistas sobre cómo hacer las compensaciones correctas al construir el sistema. Los requisitos funcionales a menudo son bastante negociables, los atributos de calidad influirán en gran medida en su arquitectura y las estructuras que elija, las restricciones técnicas no son negociables.

Si este fuera mi equipo, les diría que los requisitos deben estar claramente anotados por tipo para asegurarnos de que no nos perdamos algo importante en la arquitectura. Piense en los controladores arquitectónicos, no solo en la funcionalidad.

Anthony Lattanze en Arquitectura de software de sistemas intensivos: una guía para profesionales ofrece una visión general práctica de los impulsores arquitectónicos y por qué deberían tratarse de manera diferente, mucho más integral que mi resumen aquí.

Cuando cada requisito tiene la misma prioridad / peso (particularmente "Obligatorio"), entonces probablemente tenga más de qué preocuparse que simplemente dividir los requisitos funcionales y no funcionales.

Sin embargo, hay varias razones para separar Las dos categorías de requisitos:

Responsabilidad de la implementación He descubierto que muchos requisitos no funcionales, particularmente aquellos centrados en el rendimiento, solo son moderadamente aplicables al desarrollador. Si bien un diseño puede admitir la escalabilidad y la velocidad (y se pueden ajustar secciones de código específicas), en general, cumplir con los requisitos de rendimiento depende de la arquitectura y, a menudo, del tiempo de la configuración del hardware.

Responsabilidad de las pruebas ¿Qué tan experto es el usuario o el equipo de control de calidad para verificar que se cumplen los requisitos de seguridad, tolerancia a fallas, seguridad y confiabilidad?

No se repita La documentación debe seguir el mismo principio DRY que el código. Los requisitos comunes de diseño de la interfaz de usuario deben agruparse. Si la persona responsable de los requisitos realmente quiere, puede hacer referencia a los requisitos no funcionales (individualmente o en grupo) en los requisitos funcionales.

Control de versiones Si está en un entorno corporativo con muchos "estándares", puede escribir documentos de requisitos específicos de IU o seguridad (por nombrar un par) que se puedan versionar. De esa manera, podría escribir los requisitos específicos de la aplicación (en su mayoría Requisitos funcionales): "La aplicación debe cumplir con la V2.3 de los Requisitos de seguridad definidos en XYZ-Company-SecReq-DocumnentNamingStandard.docx".

¿Por qué molestarse en diferenciar entre requisitos funcionales y no funcionales?

Una razón para diferenciar es el nivel de abstracción entre los dos tipos. Los requisitos no funcionales están a nivel de sistema y dicen cómo debe comportarse el sistema en su conjunto. Los requisitos funcionales se refieren a una característica específica y qué características y funcionalidades deben proporcionarse a los clientes.

Los requisitos no funcionales también limitan el sistema, mientras que los requisitos funcionales dicen lo que debe hacer el sistema. Los requisitos no funcionales proporcionan limitaciones en cuanto a cómo los requisitos funcionales se diseñarán e implementarán más adelante. Al separarlos, es posible identificar claramente las características de las restricciones y limitaciones.

Lo que temo son los requisitos agrupados en un solo documento. Traté de explicar el beneficio en términos prácticos, pero no pude venderlo. ¿Cómo vendo el beneficio de documentar qué requisitos son funcionales y cuáles no?

En mi experiencia, los requisitos funcionales y no funcionales se agrupan en el mismo documento o se rastrean en el mismo sistema. Sin embargo, se les dan sus propias secciones separadas del documento, así como criterios de éxito para cumplir con cada una.

En general, clasifica los requisitos para ayudar al equipo a cumplirlos. Si hay un requisito específicamente dirigido a una necesidad arquitectónica, llamarlo un requisito de "Arquitectura" debería ayudar al equipo cuando trabaje en la arquitectura.

Un documento único grande de todos los requisitos no es necesariamente algo malo ... Pasar 2 días revisándolo tampoco es malo. El problema generalmente es que una vez que una persona ha revisado los requisitos, los comprende, pero no es más fácil para nadie hacer lo mismo. Puede ser de gran ayuda comenzar a etiquetar los requisitos con metadatos que ayudarán a las otras personas que se unen al proyecto.

Quizás intente describirlo como un problema de abstracción. Si necesita trabajar en una base de código heredada, no solo lee todas las líneas de código existentes y comienza a trabajar. Sigue la estructura del código para ayudarte. Tener cierta estructura en los requisitos ayuda de la misma manera.

Hay múltiples beneficios para la separación.

1. Ahorre tiempo en las pruebas (es decir, solo pruebe los requisitos funcionales)
2. Ahorra tiempo en futuros cambios a los requisitos (es decir, los requisitos no funcionales tomarán menos tiempo para revisar / aprobar / implementar / probar)
3. En un mundo regulado (es decir, FDA, etc.), los requisitos no funcionales requieren 1/10 de la cantidad de papeleo que requiere un requisito funcional.
4. Otorga al equipo la capacidad de dividir el trabajo entre los miembros del equipo senior (funcional) y junior (no funcional).

Podría seguir...

En la superficie, dos días parece mucho tiempo, a la larga podría ahorrar semanas o incluso meses de trabajo futuro.