¿Por qué es más difícil determinar qué componentes del sistema implementan requisitos no funcionales que requisitos funcionales?
Suena como una mierda.
Pero ¿puedes notar la diferencia entre ellos? Si no, eche un vistazo a continuación.
1. Los requisitos no funcionales son requisitos transfronterizos.
Un requisito no funcional suele estar relacionado con funciones múltiples y transfronterizas. Precisamente debido a esta naturaleza transversal, los requisitos no funcionales son más difíciles de analizar e implementar que los requisitos funcionales ordinarios.
2. Es más probable que los requisitos no funcionales hagan que los usuarios se sientan insatisfechos.
Cuando el software se entrega a los usuarios, algunos requisitos no funcionales no se implementan, lo que hará que los usuarios se sientan aún más insatisfechos. insatisfecho. Por ejemplo, funciona lentamente. Es más probable que el incumplimiento de los requisitos del usuario en materia de requisitos no funcionales provoque un retraso en la entrega o incluso la cancelación del proyecto.
3. Los requisitos no funcionales tienen un mayor impacto en la arquitectura del software.
Los requisitos no funcionales transfronterizos son muy complejos de implementar, por lo que suelen tener un mayor impacto en la arquitectura del software. Por ejemplo, el diseño arquitectónico no puede permitir que los requisitos de alto rendimiento (alta velocidad de operación o procesamiento) abarquen múltiples capas en la arquitectura del software. Debido a que las modificaciones a la arquitectura del software en las últimas etapas del desarrollo del software tomarán mucho tiempo y afectarán la entrega del proyecto, los requisitos no funcionales deben analizarse al comienzo del proyecto para determinar el impacto en la arquitectura del software.
4. Es más probable que los requisitos no funcionales sean mutuamente excluyentes.
Los requisitos no funcionales suelen ser mutuamente excluyentes. Por ejemplo, requisitos de seguridad y requisitos de disponibilidad; requisitos de robustez y requisitos de rendimiento, etc. Este es un problema que debe resolverse mediante la práctica especial "Análisis de requisitos para lograr el equilibrio" en el área de proceso de desarrollo de requisitos de GJB5000A.
5. La descripción de requisitos no funcionales requiere más detalles.
Los requisitos no funcionales requieren una descripción más detallada que los requisitos funcionales. Cuando no se especifican los requisitos funcionales, el analista de requisitos aún sabe cómo llegar allí.
Implementarlo; en cuanto a las descripciones de requisitos de rendimiento como "el tiempo de respuesta debe ser lo más rápido posible", los analistas de requisitos no pueden juzgar qué impacto tendrá en la arquitectura del software, ni saben si el software implementado. cumple con los requisitos.
Finalmente, de lo que realmente va a hablar este artículo no es de la diferencia entre requisitos no funcionales y requisitos funcionales, sino de permitir a los desarrolladores prestar más atención al análisis, diseño e implementación de requisitos no funcionales. requisitos y ser capaz de considerar el impacto de los requisitos no funcionales en las primeras etapas del proyecto. Impacto en la arquitectura del software, cronograma del proyecto, estrategia de prueba y costo del proyecto.
Esto es exactamente lo que:
Los requisitos valoran la no funcionalidad porque afecta la superfuncionalidad.
Los usuarios están aún más insatisfechos con el progreso y el costo de la arquitectura.