Requisitos
- Objetivos
- Introducción
- Recopilar, descubrir
- Análisis de Requisitos
- Documentación de los Requisitos
- Validación de los Requisitos
- Explicar la importancia del proceso de descubrimiento (elicitation en inglés) y análisis de requisitos
- Utilizar el método de casos de uso para documentar los requisitos
- Utilizar los diagramas de clase para modelar el mundo del problema
- Diferenciar entre requisitos funcionales y no funcionales
- Definir términos como: escalabilidad, mantenibilidad, confiabilidad, rendimiento, acoplamiento, cohesión
- Utilizar los diagramas de secuencia para verificar qué casos de uso podrán realizarse con el modelo del mundo
- Reconocer que la documentación de requisitos requiere diferentes niveles de detalle
- Identificar las características del contenido de un documento de definición de requisitos
| Herramientas | |
|---|---|
| www.genmymodel.com | Permite realizar de forma colaborativa diagramas de UML. |
| acceder con el login uniandes. |
Uno de los riesgos más complejos de manejar en el desarrollo de software es el de construir la aplicación que no se necesita; es decir, que no satisfaga lo esperado por el cliente y los usuarios y que no sirva para lo que se esperaba. Si esto sucede, las consecuencias pueden ser económicamente catastróficas. Puede suceder que se descarte el proyecto y se pierda todo el trabajo realizado o que se tenga que rehacer gran parte del mismo.
Hay muchas acciones posibles para mitigar este riesgo y todas pueden ser complementarias. La más importante, porque afecta completamente el ciclo de vida del desarrollo de software, es la de construir incrementos funcionales que puedan ir siendo validados por el cliente y usuarios del sistema. En términos de las metodologías ágiles, significa entregar valor al usuario en un software que funciona y que se puede validar. Si se encuentra que el incremento o alguna funcionalidad no satisface lo esperado, entonces el costo de rehacer será menor que si se tuviera que realizar sobre un software completamente terminado.
Otra acción es realizar las actividades de descubrimiento y análisis de lo que se requiere del sistema de una manera organizada que facilite la comunicación, documentación, análisis y validación de los requisitos.
De acuerdo con la definición de la IEEE, un requisito es:
-
Una condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).
-
Una condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
Otros autores como Robertson, definen requisito de software como algo que el sistema debe hacer o una cualidad que el sistema debe poseer.
Al revisar los requisitos de software, podemos identificar varios tipos:
-
Requisitos funcionales: funcionalidades del software.
-
Requisitos no funcionales: exigencias en otros aspectos del software. Por ejemplo, requisitos en torno a atributos de calidad como rendimiento, tolerancia a fallas y seguridad.
-
Reglas de negocio: validaciones, reglas y normas que deben ser soportadas por el software.
-
Otros requisitos: Otros tipos de exigencias que no pertenecen a las otras categorías. Por ejemplo, tiempos, personal involucrado y presupuestos para el proyecto.
Es el proceso consiste en cuatro actividades (no secuenciales) así:
- Recopilar, descubrir (Elicitation)
- Analizar
- Documentar (Especificar)
- Validar (Lograr un acuerdo con el cliente)
Los pasos anteriores no definen un proceso secuencial. Se trata de un proceso iterativo donde el orden depende de los avances y del entendimiento que se logre con el cliente.
Gradualmente durante estos pasos se va construyendo un documento de definición de requisitos como el que se presenta en el ejemplo Documento Especificación de Requisitos..
Es la obtención y el descubrimiento de los requisitos del software según diversos Stakeholders (constituyentes) y otras fuentes (leyes, restricciones). Las técnicas para realizar esta actividad son las entrevistas, el análisis de documentos, los grupos de discusión, los cuestionarios.
Siempre debemos buscar eliminar las ambigüedades que llevan a interpretaciones distintas del mismo requisito. Los problemas comunes son:
- Requisitos olvidados en particular los no funcionales y las restricciones
- Palabras ambiguas (“pequeño”, “barato”, ...)
- Vocabulario dependiente del contexto del negocio
- Creer que se entendió (el ingeniero)
- Creer que se explicó claro (cliente)
- Pasar por alto lo importante
- Lo necesario vs. lo ideal
- Lo actual vs. el cambio
Un proceso posible para identificar los requisitos es:
| Acción | Descripción |
|---|---|
| Enunciar el problema | El problema puede ser definido como una diferencia entre cómo las cosas son percibidas y cómo son deseadas. |
| Enunciar el propósito | Identificar lo que daría más valor al cliente. |
| Modelar el mundo del problema y definir un vocabulario común. | Identificar los conceptos y las relaciones importantes en los elementos del mundo del problema. Por ejemplo utilizando un Diagrama de clases UML. |
| Documentar | Explicar los conceptos (clases) y las relaciones en un glosario. |
| Entrevistar | Validar el entendimiento con el cliente. Obtener más información. |
Analizar los requisitos significa:
- Determinar si los requisitos son los indicados: claros, completos, coherentes, si se podrán probar (testable)
- Resolver los conflictos que puedan surgir entre los involucrados (stakeholders)
Técnicas: abstraer, modelar, identificar funcionalidad, identificar restricciones, características, prototipar, simular, discutir, …
En la siguiente sección discutiremos los Casos de Uso como técnica para analizar y documentar los requisitos.
Los casos de uso se utilizan para especificar los escenarios en los que un actor interactúa con la aplicación. Básicamente permite documentar, con mucho más detalle, requisitos funcionales de la aplicación considerando los diferentes escenarios y reglas de negocio que deben implementarse.
Es posible especificar los requisitos funcionales usando casos de uso de una manera gradual. La idea es construir una especificación inicial e irla completando a medida que se avanza en el análisis de los requisitos. Una especificación mínima puede incluir una pequeña descripción e información de las entradas y salidas.
Ejemplo: documentar con Historias de Usuario
El propósito de validar los requisitos de software con el Cliente es corroborar que el entendimiento sobre lo que se espera que haga el sistema es correcto. De nuevo, buscamos evitar construir el sistema que no se necesita.
Las técnicas para validar los requisitos pueden ser basadas en:
- Inspección de los documentos por parte del cliente y como resultado él reportará sus hallazgos.
- Presentaciones y reuniones y como resultado se discute y argumenta y se trata de llegar a un acuerdo.
- Prototipos en donde el cliente puede ver más fácilmente lo que será la aplicación.
- Una mezcla de las anteriores (esta siempre es la mejor opción).
- El Lenguaje Unificado de Modelado. Grady Booch, James Rumbaugh e Ivar Jacobson. Addison Wesley, 1999 Capítulos 16 y 17
- Object Oriented Software Engineering. . Prentice Hall, 2000. Capítulo 4, pág. 100–106, 118-119
- Karl. E.Wiegers. Software Requirements. Microsoft Press, 1999. Capítulo 9, pág. 153-162. Capítulo 11
- Suzanne Robertson and James Robertson. 2012. _Mastering the Requirements Process: Getting Requirements Right _(3rd ed.). Addison-Wesley Professional.
Este libro fue creado para el curso ISIS2603 Desarrollo de Sw en Equipos en la Universidad de los Andes. © Desarrollado por Rubby Casallas con la colaboración de César Forero, Kelly Garcés y Jaime Chavarriaga. Universidad de los Andes, Bogotá, Colombia. 2019