|
Introducción
Esta sección describe las capacidades de la Administración de requisitos de Enterprise Architect, y discute:
| • | Como se generan y organizan los requisitos |
| • | Como Enterprise Architect soporta y simplifica la administración de requisitos. |
Las discusiones adicionales de la administración de requisitos en Enterprise Architect se pueden encontrar en el documento de Administración de requisitos con Enterprise Architect en el sitio web de Sparx Systems.
¿Qué es un requisito?
Los requisitos son esencialmente lo que se requiere que realice el sistema, la aplicación o el proceso de negocio. Un requisito puede ser amplio y de alto nivel, definiendo - por ejemplo - una necesidad para que un proceso actualice una base de datos particular. Un requisito también puede ser más especializado y detallado, registrando la expectativa que - por ejemplo - una llamada del sistema se debe reconocer siempre por retorno. Los requisitos detallados se pueden organizar en una jerarquía culminando en un requisito de alto nivel, de esta manera satisfacer cada uno de los requisitos detallados resulta en alcanzar requisitos de alto nivel y finalmente los requisitos de nivel superior. Esta estructura jerárquica ayuda a administrar la complejidad de sistemas grandes con cientos de requisitos y muchos procesos que se desarrollan para implementar los requisitos.
Reunir requisitos
Reunir requisitos es normalmente el primer paso al desarrollar una solución, ya sea para desarrollar un sistema o un proceso. Los requisitos se reúnen desde todas las partes que se esperan que usen, mantengan o beneficien de la solución, y se organizan en grupos, áreas funcionales y jerarquías de acuerdo a como sea necesario. Estas se pueden transcribir en un hoja de cálculo o una recolección de requisitos o herramienta de administración, o se pueden crear en una herramienta de modelado integrado como Enterprise Architect.
Administración de requisitos y Enterprise Architect
La administración de requisitos es una de las disciplinas más problemáticas en el desarrollo de software, para razones como:
| • | Entradas de grupos diversos en los requisitos. |
| • | Divisiones del límite organizacional. |
| • | Divisiones del límite de la herramienta. |
| • | Volatilidad de requisitos. |
| • | Imprecisión y ambigüedad en los lenguajes naturales. |
Estos pueden causar incidencias con:
| • | Integración con los sistemas de administración de cambios y configuración. |
Enterprise Architect puede reducir o eliminar estos problemas en la administración de requisitos, esta es una de las pocas herramientas UML que integran la administración de requisitos con otras disciplinas de desarrollo de software en el producto central, definiendo requisitos dentro del modelo. Dentro de Enterprise Architect, puede:
| • | Crear y ver requisitos como entidades y propiedades directamente en el modelo. |
| • | Intercalar los requisitos en el archivo CSV externo y luego importarlos en su modelo. |
| • | Detallar casos de uso y escenarios directamente en el modelo. |
| • | Localizar requisitos para los casos de uso, reglas de negocio, casos de prueba, artefactos de análisis (usando, por ejemplo, la Matriz de relaciones). |
| • | Crear MS Word de la calidad del cliente y reportes HTML de requisitos. |
Tenga en cuenta:
|
Todas estas características se ilustran por ejemplos en el modelo EAExample.eap, proporcionados como parte de su instalación de Enterprise Architect en el directorio de archivos de programa de Enterprise Architect:
..\Archivos de programa\Sparx Systems\EA
|
|