Captura De Requisitos

CAPTURA DE REQUISITOS

Es guiar el desarrollo hacia el sistema correcto. Hay diferentes puntos de partida para la captura de requisitos. En algunos casos comenzamos haciendo un modelo del negocio o partimos de uno ya desarrollado. En otros casos si es un sistema acotado que no da soporte al negocio podemos partir de un modelo de objetos sencillo como un modelo del dominio.

En otros casos el cliente puede ya haber desarrollado una especificación completa de requisitos no basada en objetos, de la cual podemos partir.

El flujo de trabajo de requisitos incluye los siguientes pasos:

Enumerar los requisitos candidatos.

Flujo de Comprender el contexto del sistema.

De trabajo de Capturar requisitos funcionales.

Requisitos Capturar requisitos no funcionales.

ENUMERAR LOS REQUISITOS CANDIDATOS

La lista de características deseadas del sistema constituyen los requisitos candidatos.

De cada característica se registra:

- Nombre corto

- Descripción

- Estado (propuesto, aprobado, incluido, o validado)

- Coste estimado de implementación (en término de tipos de recursos y horas-hombre)

- Prioridad (crítico, importante, o secundario)

- Nivel de riesgo asociado a la implementación de la característica (crítico, significativo, ordinario)

Estos valores se utilizan para estimar el tamaño del proyecto y decidir cómo dividirlo en secuencia de iteraciones. La prioridad y nivel de riesgo asociados por ejemplo, se utiliza para decidir en que iteración se implementará la característica.

COMPRENDER EL CONTEXTO DEL SISTEMA

Hay por lo menos dos aproximaciones para expresar el contexto de un sistema: modelado del dominio y modelado del negocio.

Un modelo del dominio describe los conceptos importantes del contexto como objetos del dominio relacionados entres sí.

Un modelo del negocio es más amplio. Describe los procesos con el objetivo de comprenderlos. El modelado del negocio específico que procesos de negocio soportará el sistema.

CAPTURAR REQUISITOS FUNCIONALES

Los requisitos funcionales son capturados por medio de casos de uso, que conforman el modelo de casos de uso. Los casos de uso también capturan requisitos no funcionales específicos de un caso de uso determinado.

CAPTURAR REQUISITOS NO FUNCIONALES

Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la implementación, rendimientos, etc.

Hay requisitos no funcionales específicos para un caso de uso y otros genéricos para la aplicación. Los que son específicos para un caso de uso, pueden documentarse junto con el caso de uso correspondiente. Los que son más genéricos se documentan por medio de una lista de requisitos adicionales.

MODELO DEL DOMINIO

Un modelo del dominio captura los tipos más importantes de objetos en el contexto del sistema. Los objetos del dominio representan las “cosas” que existen o los eventos que suceden en el entorno en el que trabaja el sistema.

Las clases del dominio aparecen en tres formas típicas:

- Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos, cuentas, contratos, etc.

- Objetos del mundo real y conceptos de los que el sistema debe hacer seguimiento como aviación enemiga, misiles, trayectorias, etc.

- Sucesos que ocurrirán o han ocurrido, como llegada de un avión, su salida, hora de la comida, etc.

El modelo de dominio se representa fundamentalmente por diagramas de clases en

UML.

El objetivo del modelado del dominio es comprender y describir las clases más importantes dentro del contexto del sistema.

MODELO DEL NEGOCIO

Es una técnica para comprender los procesos de negocio de la organización.

Está soportado por dos tipos de modelos de UML: el modelado de casos de uso, y modelos de objetos.

Un Modelo de Casos de Uso del Negocio describe los procesos de negocio de una empresa en términos de casos de uso del negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes respectivamente.

Al igual que el modelo de casos de uso para un sistema software, el modelo de casos de uso del negocio presenta un sistema (en este caso, el negocio) desde la perspectiva de su uso, y esquematiza como proporciona valor a sus usuarios.

El modelo de casos de uso del negocio se describe mediante diagramas de casos de uso.

Un modelo de objetos del negocio describe como cada caso de uso del negocio es llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto de entidades del negocio y de unidades de trabajo.

Cada realización de un caso de uso del negocio puede mostrarse en diagramas de interacción y diagramas de actividad.

Una entidad del negocio representa algo que los trabajadores toman, manipulan, inspeccionan, producen o utilizan en un negocio.

Una unidad de trabajo es un conjunto de esas entidades que conforma un todo reconocible para el usuario final.

La técnica de modelado de negocio identifica entidades y trabajadores que participan en la realización de los casos de uso del negocio.

Los trabajadores identificados en el modelo de negocio se utilizan como punto de partida para derivar un primer conjunto de actores y casos de uso del sistema.

BÚSQUEDA DE CASOS DE USO A PARTIR DE UN MODELO DEL NEGOCIO

En primer lugar se identifica un actor por cada trabajador y por cada actor del negocio (es decir, el cliente).

Cada trabajador y actor del negocio que vaya a ser usuario del sistema de información requerirá un soporte por parte del mismo. El soporte necesario se determina tratando cada uno de los actores uno detrás de otro.

Una vez que hemos encontrado todos los roles de un trabajador o actor del negocio, uno por cada caso de uso del negocio en el que participa, podemos encontrar los casos de uso de los actores del sistema.

La manera más directa de identificar un conjunto tentativo de casos de uso es crear un caso de uso para el actor correspondiente a cada rol de cada trabajador y de cada actor del negocio. Los analistas pueden después ajustar los casos de uso tentativos.

REQUISITOS

...