Ingeniería de requerimientos de software
Objetivos
- Explicar la importancia del proceso de descubrimiento (elicitation) y análisis de requerimientos
- Utilizar el método de casos de uso para documentar los requerimientos
- Utilizar los diagramas de clase para modelar el mundo del problema
- Diferenciar entre requerimientos funcionales y no funcionales
- Definir términos como: escalabilidad, mantenibilidad, confiabilidad, rendimiento, acoplamiento, cohesión
- Utilizar los diagramas de secuencia para verificar que los casos de uso podrán realizarse con el modelo del mundo
- Reconocer que la documentación de requerimientos requiere diferentes niveles de detalle.
Identificar las características del contenido de un documento de definición de requerimientos
| Herramienta | |
|---|---|
| /genmymodel.com | Permite realizar de forma colaborativa diagramas de UML. |
| acceder con el login uniandes. |
Introducción
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: _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 requerimientos.
Definición de Requerimiento
De acuerdo con la definición de la IEEE, un requerimiento 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).
De acuerdo con otros autores como (Robertson - Robertson) definen requerimiento de software como algo que el sistema debe hacer o una cualidad que el sistema debe poseer.
Tipos de Requerimientos
Al revisar los requerimientos de software, podemos identificar varios tipos:
Requerimientos Funcionales: funcionalidades del software.
Requerimientos No Funcionales: exigencias en otros aspectos del software. Por ejemplo, requerimientos 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 Requerimientos: Otros tipos de exigencias que no pertenecen a las otras categorías. Por ejemplo, tiempos, personal involucrado y presupuestos para el proyecto.
El proceso de Ingeniería de Requerimientos
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 requerimientos como el que se presenta en el ejemplo Documento Especificación de Requerimientos..
1. Recopilar, descubrir (Elicitation)
Es la obtención y el descubrimiento de los requerimientos 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 requerimiento. Los
problemas comunes son:
- Requerimientos 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 requerimientos es:
| 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. |
| Explicar los conceptos (clases) y las relaciones en un glosario. | |
| Entrevistar | VAlidar el entendimiento con el cliente. Obtener más información. |
Más información sobre las Entrevistas Cualitativas.
2. Análisis de Requerimientos
Analizar los requerimientos significa:
- Determinar si los requerimientos 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 requerimientos.
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, requerimientos funcionales de la aplicación considerando los diferentes escenarios y reglas de negocio que deben implementarse.
Es posible especificar los requerimientos 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 requerimientos. Una especificación mínima puede incluir una pequeña descripción e información de las entradas y salidas.
3. Documentación de los Requerimientos
Ejemplo Documento Especificación de Requerimientos.
4. Validación de los Requerimientos
El propósito de validar los requerimientos de software con el Cliente es corroboran 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 requerimientos 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).
Referencias
- 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.