Análisis y especificación de Requisitos

El análisis global de los requisitos de una aplicación es un proceso de conceptualización y formulación de los conceptos que involucra de forma concreta. Es una parte fundamental del proceso de desarrollo de una aplicación, la mayor parte de los defectos encontrados en el software entregado se originan en la fase de análisis de requisitos, y además son los mas caros de reparar.

Siempre se ha discutido quién es el dueño de los requisitos: el cliente o el desarrollador. Para gestionar esto, es habitual presentar el análisis de requisitos en dos secciones:

• Requisitos de cliente: documentan los deseos y necesidades de los clientes y se expresan en lenguaje claro para él.
• Requisitos detallados: Determina los requisitos de manera específica y estructurada y están destinadas específicamente hacia los desarrolladores.

Para construir algo primero debe entenderse lo que debe ser ese algo. El proceso de entender y documentar una aplicación software se llama “Análisis de requisitos”. En general los requisitos expresan qué se supone debe hacer una aplicación y no intentan expresar como logra estas funciones. El análisis inicial de un sistema debe tratar de descubrir los requerimientos del producto final que se desarrolla en detalle. Unos de los principales objetivos de UML es hacer que este análisis sea lo suficientemente intuitivo para que los clientes y expertos en el dominio que solicitan el producto puedan comprenderlo, y lo suficientemente formal y riguroso para que se establezca una formulación no ambigua que pueda ser utilizada por los técnicos que la desarrollan. Los aspectos básicos que deben tratarse en esta fase son: 

• Determinar los paquetes de funcionalidad y de la calidad de servicio del producto, formulados de una forma independiente de su implementación, y refinar y detallar estas especificaciones hasta que den lugar a una especificación no ambigua del producto que se desarrolla.
•  Identificar los actores externos al sistema que interactúan con la aplicación de forma relevante.
•  Identificar la semántica y las características de los mensajes que intercambian los actores con el sistema que se desarrolla. 
• Refinar los protocolos de interacción que usan los actores para llevar a cabo las diferentes transacciones que se pueden realizar con el sistema. 

El análisis de requisitos es una necesidad, no es un lujo. Para apoyarlo considérese su efecto sobre las pruebas del producto concluido. Si alguien le proporciona una caja negra con un cable rojo, rosa y morado que sale de ella, sería imposible probarlo.

El proceso de análisis de requisitos requiere diferentes actividades de alto nivel y que son desarrollados por múltiples agentes (usuarios, expertos de dominio, expertos de marketing, programadores, etc.)

Para la formulación de las especificaciones existen diferentes estándar, el mas conocido es el estándar ANSI, IEEE 830-1993.

Para todas las etapas se pueden utilizar métricas tales como: 

• Tiempo dedicado a su análisis. 
• Cantidad producida (páginas de requisitos, minutos de interacción con el cliente, etc.) 
• Calidad deducida de la autoevaluación (Tasas de defectos en las inspecciones). 

Especificación de Requisitos

Para la especificación del requisitos se usan tres tipos de recursos: 

• Descripción del proyecto: Es un paso previo que aunque es obvio tiene una gran importancia, y consiste en generar un documento que de forma concisa resuma la información inicial relativa al proyecto que se inicia. En él debe incluirse la naturaleza y objetivo del proyecto, las características mas relevantes, su oportunidad de mercado, y un análisis de los riesgos que conlleva. Debe ser un documento breve con solo dos o tres páginas, pero que establece un punto de arranque en el que los diferentes responsables de su ejecución (clientes, expertos de dominio y desarrolladores) tienen el mismo concepto sobre lo que se desarrolla..
• Análisis del contexto: Trata de especificar la funcionalidad del sistema a través de la descripción de las interacciones que se pueden producir entre el sistema y el entorno externo. Se formula como diagramas de objetos en los que el sistema aparece como una caja negra sobre la que se identifican los elementos de interacción (sensores y actuadores) y también se identifican los actores externos que interactúan con él, así como los tipos de mensajes que se producen definiendo su semántica y la información que transmiten.
• Casos de uso: Es el recurso específico de UML para describir la funcionalidad y las características de calidad de servicio del sistema. Se basa en identificar los límites del sistema a través de la captura de los actores, de los elementos básicos de funcionalidad a través de casos de uso, y de los protocolos de interacción a través de diagramas de secuencia o de interacción.