Requisitos de software : un conjunto de solicitudes/declaraciones con respecto a los atributos, propiedades o cualidades de un sistema de software que se implementará. Las tareas de desarrollo/modernización de software (SW) se crean en el proceso de elaboración (análisis y síntesis).
Los requisitos se pueden expresar en forma de declaraciones de texto y modelos gráficos .
En el enfoque técnico clásico, se utiliza un conjunto de requisitos en la etapa de diseño del software. Los requisitos también se utilizan en el proceso de verificación del software, ya que las pruebas se basan en los requisitos.
La fase de desarrollo de requisitos puede estar precedida por un estudio de factibilidad o una fase de análisis de diseño conceptual. La fase de desarrollo de requisitos se puede dividir en identificación de requisitos (recopilación, comprensión, consideración y determinación de las necesidades de las partes interesadas), análisis (verificación de integridad y exhaustividad), especificación (documentación de requisitos - síntesis de modelos de texto y gráficos) y validación.
Las características de calidad de los requisitos se definen de manera diferente por diferentes fuentes. Sin embargo, las siguientes características son generalmente reconocidas :
| Característica | Explicación |
|---|---|
| Singularidad | Un requisito describe una y sólo una cosa. |
| lo completo | El requisito está completamente definido en un solo lugar y toda la información necesaria está presente. |
| subsecuencia | El requisito no entra en conflicto con otros requisitos y es totalmente coherente con la documentación externa. |
| Atomicidad | El requisito es "atómico". Es decir, no puede desglosarse en una serie de requisitos más detallados sin pérdida de exhaustividad. |
| Trazabilidad | El requerimiento cumple total o parcialmente las necesidades del negocio según lo declarado por las partes interesadas y documentado. |
| Relevancia | El requisito no se ha vuelto obsoleto con el tiempo. |
| Factibilidad | El requisito se puede implementar dentro del proyecto. |
| inequívoca | El requisito se define sucintamente sin recurrir a jerga técnica, acrónimos u otro lenguaje oculto. Expresa hechos objetivos, no opiniones subjetivas. Una y sólo una interpretación es posible. La definición no contiene frases confusas. Está prohibido el uso de afirmaciones negativas y afirmaciones compuestas. |
| obligatorio | Un requisito representa una característica definida por un actor, cuya ausencia conducirá a una inferioridad de la solución, que no puede ser ignorada. Un requisito opcional es una contradicción en el concepto mismo de un requisito. |
| verificabilidad | La viabilidad de un requisito se puede determinar a través de uno de los cuatro métodos posibles: inspección, demostración, prueba o análisis. |
Todas las afirmaciones deben ser verificables. La técnica de verificación más común son las pruebas. Si la verificación mediante pruebas no es posible, entonces se debe usar otro método de verificación (análisis, demostración, inspección o revisión del diseño).
Ciertos requisitos son inherentemente no verificables. Incluyen requisitos que dicen que el sistema nunca o siempre debe mostrar una propiedad en particular. La prueba adecuada de estos requisitos requeriría un ciclo de prueba sin fin. Dichos requisitos deben redefinirse para que sean verificables. Como se indicó anteriormente, todos los requisitos deben ser verificables.
Los requisitos no funcionales que no se pueden verificar mediante programación aún deben conservarse como documentación de la intención del cliente. Dichos requisitos del producto se pueden traducir en requisitos del proceso. Por ejemplo, un requisito no funcional de que el software no contenga "pasajes secretos" se puede satisfacer reemplazándolo con el requisito de usar programación en pares. Los complejos requisitos de seguridad del software de aviación se pueden cumplir siguiendo el proceso de desarrollo DO-178B .
Cuando se desarrollan los requisitos, a menudo surgen problemas de ambigüedad, incompletitud e inconsistencia de los requisitos individuales. Eliminar estos problemas en la etapa de desarrollo de requisitos cuesta varios órdenes de magnitud menos que corregir los mismos problemas en etapas posteriores de desarrollo. Para resolver y eliminar estos problemas, existe un proceso de desarrollo de requisitos.
En el desarrollo de requisitos, existe una compensación técnica entre requisitos que son demasiado vagos y requisitos que son tan detallados que:
Los requisitos se utilizan generalmente como un medio de comunicación entre las diferentes partes interesadas. Esto significa que los requisitos deben ser simples y comprensibles para los usuarios y desarrolladores comunes.
Una especificación de software a menudo se denomina especificación técnica .
La mayoría de las veces en la práctica rusa, un analista de sistemas es responsable de crear una especificación de software , a veces un analista de negocios .
Para los modelos gráficos de requisitos históricamente se han utilizado diagramas o metodologías de modelado gráfico: ER (IDEF1FX), IDEF0 , IDEF3 , DFD , UML , OCL , SysML , ARIS ( eEPC , VAD ).
En general, los requisitos cambian con el tiempo. Una vez definidos y aprobados los requisitos, los cambios deben estar sujetos a control de cambios. Para muchos proyectos, los requisitos cambian antes de que el sistema esté completo. Esto se debe en parte a la complejidad del software y al hecho de que los usuarios no saben lo que realmente necesitan. Esta característica de los requisitos ha dado lugar al proceso de gestión de requisitos .
| Desarrollo de software | |
|---|---|
| Proceso | |
Conceptos de alto nivel | |
| Direcciones |
|
| Metodologías de desarrollo | |
| Modelos |
|
Figuras notables |
|