Analizar los requisitos del sistema
- Área: Desarrollo de requisitos de un sistema que satisfaga las necesidades de negocio
- Tipo de pauta: Directriz
- Carácter de la pauta: Obligatoria
El objetivo principal de la actividad "analizar los requisitos del sistema" es mejorar los requisitos, normalmente mediante la elaboración de modelos que permitan identificar posibles problemas y que detallen más la solución propuesta para resolver las necesidades de negocio de clientes y usuarios, incluyendo la arquitectura lógica del sistema y sus interfaces de usuario y de servicios.
En caso de identificar problemas en los requisitos, éstos deberán registrarse en la actividad Registrar problemas en los requisitos del sistema.
Todos los productos resultantes de esta tarea deben estar trazados convenientemente hacia aquellos requisitos que modelan y/o que justifican su existencia.
Analizar los requisitos del sistema es una de las actividades que forman parte del proceso Desarrollar los requisitos de un sistema software que satisfaga las necesidades de negocio del proceso de Ingeniería de Requisitos.
Pautas
| Título | Carácter |
|---|---|
| Arquitectura lógica del sistema | Recomendada |
| Identificación de Clases | Recomendada |
| Identificación de Casos de Uso | Recomendada |
| Identificación de Interfaces de Usuario | Recomendada |
Arquitectura lógica del sistema
Se deberá realizar la definición de la arquitectura lógica del sistema a desarrollar. Para ello, se deberá utilizar un diagrama de componentes UML, diagrama de paquetes UML o alguna notación ad-hoc que se considere oportuna para su representación.
 | Arquitectura lógica de un sistema software |
|---|---|
| Definición | Modelo de la estructura interna de un sistema software y de sus relaciones con otros sistemas en el que se identifican los principales componentes y sus interacciones. En el ámbito de los sistemas de información, la arquitectura lógica suele seguir variantes del patrón MVC (Modelo-Vista-Controlador) con n-capas, de forma que la capa i-ésima ofrece sus servicios a la capa i-1 utilizando los servicios de la capa i+1. En caso de aplicar un enfoque orientado a servicios, especialmente en casos de sistemas complejos, también es frecuente recurrir a una arquitectura en bus, normalmente usando un bus de servicios empresarial (ESB, Enterprise Service Bus en inglés). |
| Ejemplo (diagrama) |  |
Identificación de Clases
A partir del análisis de los casos de uso se obtiene una lista de objetos candidatos a ser clases. A partir de estas clases se definirá el modelo de clases.
A priori, es posible que no se disponga de la información necesaria para identificar todas las clases a partir de los objetos identificados al analizar los casos de uso, por lo que se hace una primera aproximación que se va refinando mediante la realimentación y solapamiento de otras tareas del análisis:
- Análisis de los requisitos.
- Identificación de los usuarios del sistema.
- Identificación de los subsistemas que lo componen.
- Definición de los interfaces de usuario.
- Definición del modelo de clases.
Una vez definidas cada una de las clases, se incorporan al modelo de clases y se identifican sus atributos, responsabilidades y relaciones. Además, algunos de los objetos representarán mejor la información del sistema si se identifican como atributos en vez de como clases.
Las clases que se identifican pueden ser:
- Clases de Entidad, que representan la información manipulada en el caso de uso.
- Clases de Interfaz de Usuario, que se utilizan para describir la interacción entre el sistema y sus actores y suelen representar abstracciones de ventanas, interfaces de comunicación, formularios, etc.
- Clases de Control, que son responsables de la coordinación, secuencia de transacciones y control de los objetos relacionados con un caso de uso.
 | Modelo de un sistema software |
|---|---|
| Definición | Representación simplificada que describe uno o más aspectos relevantes de un sistema software. En el ámbito de los sistemas de información, los modelos más utilizados son los estáticos, que describen la estructura del estado del sistema, y los dinámico/funcionales, que describen su comportamiento. |
| Ejemplo (estático) |  |
Identificación de Casos de Uso
Se deberá realizar la definición del modelo dinámico/funcional del sistema software a desarrolla. Su representación se realizará mediante diagramas de secuencia UML y/o diagramas de flujo de trabajo, según la naturaleza del caso de uso o requisito de conducta. Se recomiendan los diagramas de flujo para los más cercanos a los procesos administrativo y los diagramas de secuencia para el resto, incluyendo la posibilidad de usar ambos si se considera oportuno.
 | Modelo de Casos de Uso |
|---|---|
| Ejemplo (Diagrama de Secuencia) |  |
| Ejemplo (Diagrama de Flujo) |  |
Identificación de Interfaces de Usuario
A partir del análisis de los modelos funcionales en los que se requiere una interacción del usuario, se definen las interfaces que satisfagan todos los requisitos establecidos, teniendo en cuenta los diferentes perfiles a quiénes va dirigido.
El propósito es construir una interfaz de usuario acorde a sus necesidades, flexible, coherente, eficiente y sencilla de utilizar, teniendo en cuenta la facilidad de cambio a otras plataformas, si fuera necesario. Para ello se realizan los siguientes pasos:
- Especificar los estándares, directrices y elementos generales a tener en cuenta en la definición de la interfaz de usuario, tanto para interfaces interactivas (gráficas o caracteres), como para informes y formularios impresos.
- Identificar los distintos grupos de usuarios de acuerdo con las funciones que realizan, conocimientos y habilidades que poseen, y características del entorno en el que trabajan. La identificación de los diferentes perfiles permite conocer mejor las necesidades y particularidades de cada uno de ellos.
- Finalmente, definir el formato y contenido de cada una de las interfaces de pantalla especificando su comportamiento dinámico.
