1. Características.
1.1. Necesario: Debe ser un requisito que sea indispensable para resolver un problema o alcanzar un objetivo determinado.
1.2. Completo: El requisito debe estar redactado de manera que no se necesite más información para comprenderlo.
1.3. Consistente: El requisito no debe contradecir a otros requisitos
1.4. Correcto: Debe haber acuerdo entre todas las partes involucradas en el proyecto respecto al requisito. Debe contener una sola idea.
1.5. Factible: El requisito debe ser viable dentro de los recursos disponibles, como presupuesto, tiempo y otras restricciones.
1.6. Modificable: Los cambios en los requisitos deben hacerse de manera sistemática y se debe considerar su impacto en otros requisitos.
1.7. Priorizado: Los requisitos deben ser categorizados para determinar su grado de necesidad, como esencial/crítico, deseado u opcional verificable.
1.8. Verificable: Los requisitos deben poder ser comprobados para determinar si se han cumplido. Deben establecerse criterios de aceptación.
1.9. Rastreable: Cada función del sistema debe poder ser rastreada hasta su conjunto de requisitos correspondiente. Esto facilita las pruebas y la validación del diseño.
1.10. Claro: El requisito debe ser fácil de leer y entender. Su redacción debe ser simple y clara para consultas futuras.
2. La ingeniería de requisitos es un proceso fundamental para desarrollar una especificación completa y consistente que describa las funciones del sistema y sirva como base para acuerdos comunes.
2.1. Importancia de los requisitos.
2.1.1. 1.
2.1.1.1. Establecen el alcance del trabajo subsecuente, pueden definir estrategias de desarrollo, riesgos, tomar decisiones de negocio (viabilidad de negocio), de proyecto (tiempo, recursos), de sistema (arquitectura).
2.1.2. 2.
2.1.2.1. Indican al equipo del proyecto qué requieren los usuarios (necesidades de negocio).
2.1.3. 3.
2.1.3.1. El éxito o fracaso de un proyecto está altamente influenciado por la calidad de los requisitos y el proceso para gestionarlos durante el desarrollo de un producto.
2.2. Clasificación.
2.2.1. Requerimientos de usuario.
2.2.1.1. Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
2.2.2. Requerimientos de sistema.
2.2.2.1. Estos requerimientos establecen con detalle las funciones, servicios y restricciones operativas del sistema. El documento de requerimientos del sistema deberá ser preciso, y definir exactamente lo que se va a desarrollar
2.2.2.1.1. Requerimientos funcionales
2.2.2.1.2. Requerimientos no funcionales.
2.3. Ciclo de vida del software.
2.3.1. El ciclo de vida del software es un proceso que permite construir y evolucionar un software garantizando el cumplimiento de requisitos y la satisfacción del cliente.
2.3.1.1. Fases.
2.3.1.1.1. Definición.
2.3.2. Paradigmas de los modelos de ciclo de vida del software.
2.3.2.1. Con la finalidad de proporcionar una metodología común entre el cliente y la empresa de software, se utilizan los modelos de ciclos de vida o paradigmas de desarrollo de software para plasmar las etapas y la documentación necesaria, de manera que cada fase se valide antes de continuar con la siguiente.
2.3.2.1.1. Paradigma tradicional.
2.3.2.1.2. Paradigma orientado a objetos.
2.3.2.1.3. Paradigma de desarrollo ágil.
2.4. Etapas.
2.4.1. Elicitación.
2.4.1.1. Actividad involucrada en el descubrimiento de los requisitos del sistema. Aquí los analistas deben trabajar junto con el cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar y las restricciones que se pueden presentar.
2.4.2. Análisis.
2.4.2.1. Sobre la base de la obtención realizada previamente, comienza esta fase la cual tiene como propósito descubrir problemas con los requisitos del sistema identificados hasta el momento, para ello se basa en los siguientes objetivos:
2.4.3. Especificación.
2.4.3.1. Aquí se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se realiza conjuntamente con el análisis, por lo que se puede decir que la especificación es el “pasar en limpio” el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requisitos basada en los casos de uso se utilizan cada vez más para la obtención de requisitos.
2.4.4. Validación.
2.4.4.1. la validación garantiza que los requisitos, una vez analizados y resueltos los posibles conflictos, correspondan realmente a las necesidades de clientes y usuarios, para evitar que, a pesar de que el producto final sea técnicamente correcto, no sea satisfactorio. La validación puede llevar al analista a reescribir algunas especificaciones de requisitos y, en otros casos, a obtener nuevos, producto de la aparición de necesidades que hasta entonces estaban ocultas, para volver a evaluar el análisis inicial, o para corregir y perfeccionar el conjunto de requisitos documentados.