Representar Requisitos
|
En Enterprise Architect, un requisito puede ser modelado como un:
•
|
Requisito Externo - una expectativa del sistema o proceso, lo que debe proporcionar el sistema o proceso, modelado como un elemento; por ejemplo, un requisito de negocios o un pedido de un stakeholder - los Requisitos en este nivel tienen sus propias propiedades y se informan de manera separada en informes de documento
|
•
|
Requisito Interno – una responsabilidad de un elemento existente, lo que debe hacer o lograr el elemento, definido como una propiedad del elemento
|
La Administración de Requisitos en Enterprise Architect se ocupa principalmente de elementos Requisitos externos y de los elementos que los implementan o realizan.
|
Requisitos
Requisitos Internos
|
Requisitos en el Modelo
|
Los elementos de Requisito pueden ser agrupados y organizados dentro de diagramas de Requisitos.
Los elementos de Requisitos están conectados entre ellos por relaciones de Agregación para formar una jerarquía:
Es bastante habitual desarrollar un paquete de muchos cientos de elementos de Requisito, organizados de forma individual y en jerarquías de diversa complejidad. En el Explorador de Proyectos puede utilizar la opción Avanzado | Activar Numeración por Nivel para resaltar el orden y disposición de los Requisitos fácil y rápidamente.
La siguiente ilustración muestra varios Requisitos en un paquete, donde la Numeración por Nivel hace que el orden y disposición sean claros:
Si los elementos son agregado, movidos o eliminados del paquete, la numeración se ajusta automáticamente.
La numeración también puede ser aplicada en el generador de informe de documento utilizando el campo LevelNumber en la sección Elemento – {Element.LevelNumber}.
|
Diagrama de Requisitos
Activar Numeración por Nivel
Diseñar Plantillas de Documento Personalizado
|
Casos de Uso
|
Los Requisitos son implementados (realizados) por elementos de modelo tal como Casos de Uso, Clases, Interfaces y Componentes. Hay varias maneras de trazar el Requisito para la característica o servicio modelado por elementos, o elementos que desarrollan el requisito, mejor visibles en diagramas de Trazabilidad que representan los Requisitos y los elementos de modelo conectados por relaciones de Realizar. El conector Realizar le permite a los miembros del equipo del proyecto mantener objetivos de diseño y desarrollo en conjunto, y la ruta y propósito de desarrollo claros.
La relación de realización más habitual es entre un Requisito y un Caso de Uso. Un Requisito puede ser realizado 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 cumplir, el Caso de Uso es la clave para definir y visualizar como se cumple una condición. Un diagrama de Caso de Uso representa la agrupación lógica de acciones, procesos y componentes para lograr un resultado requerido, y a través del uso de elementos de Actor también define el uso y/o roles del sistema que participan en el proceso.
Cada Caso de Uso (al igual que un elemento compuesto) puede contener una combinación de diagramas hijos que definen en más detalle como una actividad o funcionalidad en particular puede llegar a ser implementada - tales diagramas incluyen diagramas de Secuencia, Comunicación, Actividad, Máquinas de Estado y Flujo de Reglas de Negocios. La implementación real de cada Caso de Uso es realizada por elementos de Clase, Componente e Interfaz organizados en sus propios diagramas. Estas realizaciones también pueden ser capturadas y vistas en diagramas de Trazabilidad, representando la ruta del desarrollo completo desde el requisito inicial hasta las pruebas y producción.
|
Traza: Trazando Dependencias
Ejemplo de Diagrama de Trazabilidad
Requisito de Conector
Caso de Uso
Diagrama de Caso de Uso
Actor
Elemento Compuesto
Diagrama de Secuencia
Diagrama de Comunicación
Diagrama de Actividad
Diagrama de Máquinas de Estado
Crear una Actividad de Flujo de Reglas
|