Representar requisitos
En Enterprise Architect, un requisito se puede modelar como un:
| • | Requisitos externos - como una expectativa del sistema o proceso, lo que el sistema o proceso debe proveer, modelado como un elemento; por ejemplo, un requisito de negocio o un pedido de un propietario - Los requisitos en este nivel tienen sus propias propiedades y se reportan por separado en los reportes RTF. |
| • | Requisitos internos – una responsabilidad de un elemento existente, lo que el elemento debe hacer o ejecutar, definido como una propiedad del elemento. |
La administración de requisitos en Enterprise Architect esta principalmente comprendida con elementos de requisito externo y los elementos que lo implementan y realizan.
Requisitos en el modelo
Los elementos de requisitos se pueden agrupar y organizar dentro de diagramas de requisitos. Los elementos de requisitos se conectan entre ellos por relaciones de agregación para formar una jerarquía:
Es bastante usual desarrollar un paquete de cientos de elementos de requisitos, ordenados individualmente y en jerarquías de complejidad variada. En el Explorador del proyecto puede usar la capacidad de Mostrar la numeración del nivel para resaltar el orden y arreglo de requisitos rápida y fácilmente. La siguiente ilustración muestra un número de requisitos en un paquete, donde la numeración del nivel hacen que el orden y arreglo sea claro:
Si los elementos se agregan, mueven o eliminan desde el paquete, la numeración automáticamente se ajusta.
Tenga en cuenta: |
Esta numeración también se puede aplicar en el generador de reporte RTF usando el campo NúmeroDelNivel en la sección Elemento – {Element.LevelNumber}. |
Casos de uso
Los requisitos se implementan (realizado) por los elementos del modelo como casos de uso, clases, interfaces y componentes. Hay muchas maneras para localizar el requisito para la característica o el servicio modelado por los elementos, o los elementos que desarrollan el requisito, mas visible en los diagramas de Trazabilidad que describen los requisitos y modelan los elementos conectados por las relaciones de Realización. El conector de Realización permite que los miembros del equipo del proyecto mantengan claro los objetivos del diseño y el desarrollo a la vez, y la ruta del desarrollo y el propósito.
La relación de la realización más usual es entre un requisito y un caso de uso. Un requisito se puede realizar por uno o más casos de uso, y un caso de uso puede realizar uno o más requisitos.
Mientras un requisito define una condición que se debe alcanzar, el Caso de uso es la clave para definir y visualizar como se logra esa condición. Un diagrama de caso de uso describe el agrupamiento lógico de acciones, procesos y componentes para alcanzar un resultado requerido, y a través del uso de los elementos Actor también define el usuario y/o los roles del sistema que participan en el proceso.
Cada caso de uso (como un elemento compuesto) puede contener una combinación de diagramas hijos que se definen en más detalle como se puede implementar una actividad o capacidad particular - por ejemplo los diagramas incluyen diagramas de Secuencia, Comunicación, Actividad, Máquina de estado y Flujo de reglas de negocio. La implementación actual de cada caso de uso se realiza por los elementos de clase, componente e interfaz organizados en sus propios diagramas. Estas realizaciones también se pueden capturar y ver en los diagramas de trazabilidad, describiendo la ruta de desarrollo completo desde el requisito inicial a través de las pruebas y producción.