Los requisitos de software [1] para un sistema son la descripción de lo que el sistema debe hacer, el servicio o servicios que proporciona y las limitaciones de su funcionamiento. El Glosario estándar de terminología de ingeniería de software del IEEE define un requisito como: [2]
Las actividades relacionadas con el trabajo con requisitos de software se pueden dividir en términos generales en obtención, análisis, especificación y gestión. [3]
Tenga en cuenta que la redacción Requisitos de software se utiliza adicionalmente en las notas de la versión del software para explicar qué paquetes de software dependientes son necesarios para que se construya/instale/utilice un determinado software. [1]
La elicitación es la recopilación y el descubrimiento de requisitos de las partes interesadas y otras fuentes. Se puede utilizar una variedad de técnicas, como sesiones de diseño conjunto de aplicaciones (JAD), entrevistas, análisis de documentos, grupos focales, etc. La obtención es el primer paso en el desarrollo de requisitos.
El análisis es la ruptura lógica que procede de la elicitación. El análisis implica alcanzar una comprensión más rica y precisa de cada requisito y representar conjuntos de requisitos de formas múltiples y complementarias.
La clasificación de requisitos o la priorización de requisitos es otra actividad que a menudo sigue al análisis. [4] Esto se relaciona con el desarrollo de software ágil en la fase de planificación, por ejemplo, mediante Planning Poker ; sin embargo, puede no ser lo mismo dependiendo del contexto y la naturaleza del proyecto y los requisitos o el producto/servicio que se está construyendo.
La especificación implica representar y almacenar el conocimiento de los requisitos recopilados de una manera persistente y bien organizada que facilite la comunicación efectiva y la gestión del cambio. Los casos de uso, historias de usuarios, requisitos funcionales y modelos de análisis visual son opciones populares para la especificación de requisitos.
La validación implica técnicas para confirmar que se ha especificado el conjunto correcto de requisitos para construir una solución que satisfaga los objetivos comerciales del proyecto.
Los requisitos cambian durante los proyectos y, a menudo, hay muchos. La gestión de este cambio se vuelve fundamental para garantizar que se cree el software correcto para las partes interesadas.
Teniendo en cuenta que estas actividades pueden involucrar algunos artefactos como informes de observación ( observación de usuarios ), cuestionarios ( entrevistas , encuestas y sondeos), casos de uso , historias de usuarios ; actividades como talleres de requisitos ( charrettes ), lluvia de ideas , mapas mentales , juegos de roles ; e incluso, creación de prototipos ; [5] Los productos de software que proporcionan algunas o todas estas capacidades se pueden utilizar para ayudar a lograr estas tareas.
Hay al menos un autor que aboga, explícitamente, por herramientas de mapas mentales como FreeMind ; y, alternativamente, para el uso de especificaciones mediante herramientas de ejemplo como Concordion . [6] Además, las ideas y declaraciones resultantes de estas actividades pueden recopilarse y organizarse con wikis y otras herramientas de colaboración como Trello . Las características realmente implementadas y el cumplimiento de los estándares varían de un producto a otro.
Se puede crear un documento de especificación de requisitos de software (SRS) utilizando software de uso general, como un procesador de textos o una de varias herramientas especializadas. Algunas de estas herramientas pueden importar, editar, exportar y publicar documentos SRS. Puede ser útil crear documentos SRS siguiendo una estructura y metodología estandarizadas, como ISO/IEC/IEEE 29148:2018. Asimismo, el software puede utilizar o no algún estándar para importar o exportar requisitos (como ReqIF ) o no permitir estos intercambios en absoluto.
Herramientas de este tipo verifican si hay algún error en un documento de requisitos de acuerdo con alguna estructura o estándar esperado.
Las herramientas de este tipo comparan dos conjuntos de requisitos de acuerdo con alguna estructura y estándar de documento esperado.
Herramientas de este tipo permiten fusionar y actualizar documentos de requisitos.
Herramientas de este tipo permiten rastrear requisitos hasta otros artefactos, como modelos y código fuente (trazabilidad hacia adelante) o, hasta otros anteriores, como reglas y restricciones de negocio (trazabilidad hacia atrás).
La ingeniería de sistemas basada en modelos (MBSE) es la aplicación formalizada del modelado para respaldar los requisitos del sistema, las actividades de diseño, análisis, verificación y validación que comienzan en la fase de diseño conceptual y continúan durante las fases de desarrollo y posteriores del ciclo de vida. También es posible adoptar un enfoque basado en modelos para algunas etapas de la ingeniería de requisitos y, uno más tradicional, para otras. Podrían ser posibles muchas combinaciones.
El nivel de formalidad y complejidad depende de la metodología subyacente involucrada (por ejemplo, i* es mucho más formal que SysML e incluso más formal que UML ).
Las herramientas de esta categoría pueden proporcionar una combinación de las capacidades mencionadas anteriormente y otras, como la gestión de la configuración de requisitos y la colaboración. Las características realmente implementadas y el cumplimiento de los estándares varían de un producto a otro.
Existen herramientas aún más capaces o generales que apoyan otras etapas y actividades. Se clasifican como herramientas ALM .
{{cite web}}: Falta o está vacío |url=( ayuda )