Flujo de Trabajo Requerimiento
| ||||
Flujo de Trabajo Requerimiento: un requerimiento define qué es lo que el sistema debe hacer, para lo cual se identifican las funcionalidades requeridas y las restricciones que se imponen.Además son condiciones o capacidades que necesita un usuario para resolver un problema o lograr un objetivo.Este flujo de trabajo se desarrolla en la fase de inicio del proceso unificado de desarrollo.
Sumario
Objetivos del Flujo de Trabajo Requerimiento
- Definir el ámbito del sistema.
- Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.
- Establecer y mantener un acuerdo entre clientes y otros involucrados sobre lo que el sistema debería hacer.
- Proveer a los desarrolladores un mejor entendimiento de los requerimientos del sistema.
- Proveer una base para estimar recursos y tiempo de desarrollo del sistema.
- Proveer una base para la planeación de los contenidos técnicos de las iteraciones.
Artefactos del FT Requerimientos
Los principales artefactos que se obtienen son:
- Modelo de casos de uso del sistema: Es un modelo del sistema que contiene actores, casos de uso y sus relaciones.
- Actor: Terceros fuera del sistema que interactúan con él.
- Caso de uso: Fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores.
- Descripción de la arquitectura (vista del modelo de casos de uso): Representa los casos de uso significativos para la arquitectura ya que describen alguna funcionalidad importante y crítica o algún requisito que deba priorizarse.
- Glosario de términos: Términos comunes que se utilizan para describir el sistema.
- Prototipo de interfaz usuario: Presentación de la interfaz del producto que representa la funcionalidad contenida en los casos de uso; de manera que permita que el usuario verifique que el sistema va a satisfacer sus necesidades.
Trabajadores del FT Requerimiento
Los trabajadores que participan en este flujo de trabajo son:
- Analista del sistema: Define los alcances del sistema e identifica a los actores y casos de uso que permiten modelar completa y consistentemente el sistema.
- Especificador de casos de uso: Describe detalladamente cada caso de uso de acuerdo a las funcionalidades que engloba.
- Diseñador de interfaz de usuario: Responsable de desarrollar el prototipo de la interfaz de usuario para algunos casos de uso, habitualmente un prototipo para cada actor.
- Arquitecto: Describe la vista de la arquitectura del modelo de casos de uso, definiendo la prioridad de cada caso de uso para decidir en qué iteración será desarrollado cada uno.
Actores del Sistema
Cada trabajador del negocio (inclusive si fuera un sistema ya existente) que tiene actividades a automatizar es un candidato a actor del sistema. Si algún actor del negocio va a interactuar con el sistema, entonces también será un actor del sistema.
Los actores del sistema:
- No son parte de él.
- Pueden intercambiar información con él.
- Pueden ser un recipiente pasivo de información.
- Pueden representar el rol que juega una o varias personas, un equipo o un sistema automatizado.
Actividades
Como parte de este flujo de trabajo las principales actividades que se realizan son:
- Identificar y clasificar requerimientos.
- Encontrar actores y casos de uso.
- Priorizar casos de uso.
- Detallar casos de uso.
- Prototipar la interfaz de usuario.
- Estructurar el modelo de casos de uso.
Características que deben tener los Requerimientos
Deben ser:
- Especificados por escrito. Como todo contrato o acuerdo entre dos partes.
- Posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿Cómo sabemos si cumplimos con él o no?
- Descritos como una características del sistema a entregar. Esto es: que es lo que el sistema debe de hacer (y no como debe de hacerlo).
Clasificación de los Requerimientos
Los requisitos se pueden clasificar en Funcionales y No Funcionales
Requerimientos Funcionales
Son capacidades o condiciones que el sistema debe cumplir.
En la realización de los casos de uso del negocio, se obtienen las actividades que serán objeto de automatización. Estas actividades no son exactamente los requerimientos funcionales, pero sí son el punto de partida para identificar qué debe hacer el sistema. Los requerimientos funcionales se mantienen invariables sin importar con que propiedades o cualidades se relacionen.
Requerimientos No Funcionales
Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Debe pensarse en estas propiedades como las características que hacen al producto atractivo, usable, rápido o confiable. Los requerimientos no funcionales forman una parte significativa de la especificación. Son importantes para que clientes y usuarios puedan valorar las características no funcionales del producto, pues si se conoce que el mismo cumple con la toda la funcionalidad requerida, las propiedades no funcionales, como cuán usable, seguro, conveniente y agradable, pueden marcar la diferencia entre un producto bien aceptado y uno con poca aceptación.
Diagrama de Casos de Uso del Sistema
Un diagrama de casos de uso del sistema representa gráficamente a los procesos y su interacción con los actores.
Cada caso de uso debe comunicarse con al menos un actor, si no aparece ningún actor que se comunique con un caso de uso esto indica error en el modelo de caso de uso o en los requerimientos planteados. Como excepciones a esta última regla podrían considerarse:
- Si el caso de uso es abstracto (no instanciable) no tiene porque incluir relación con actores (aunque puede tenerlas)
- Un caso de uso Padre en una relación de generalización-especialización no tiene porque tener relación con un actor si el caso de uso Hijo describe completamente toda la relación con el actor
- Algunos casos de uso se inician acorde a un horario (ejemplo: una vez a la semana o al día) lo que significa que el reloj del sistema es su iniciador. El reloj es interno al sistema, de esta forma el caso de uso no tendría relación de iniciación con ningún actor, pero para esclarecer el modelo debe colocarse un actor ficticio denominado "Reloj".
Las relaciones de comunicación entre actores y casos de uso no tienen nombre, sólo se necesita especificar el punto de inicio y el fin de la relación. Esto se hace a través de una línea con saeta que indica inicio y fin de la relación
Cada fin de la relación identifica un rol e incluso una multiplicidad (cuántas instancias del actor o caso de uso pueden asociarse con una instancia de actores o casos de uso).
Cada rol de una relación de comunicación tiene una propiedad de navegabilidad, indicando quien inicia la comunicación en la interacción. La navegabilidad se muestra mediante una flecha. Si la fecha apunta al caso de uso, esto indica que el actor es quien inicia la relación con el sistema. Si la fecha apunta al actor, el sistema es quien inicia la interacción con el actor. La relación en ambos sentidos se muestra a través de una línea sin saetas (la doble saeta dificulta la comprensión del diagrama). Por cada flecha de comunicación se asume un mensaje de retorno. No se debe confundir navegabilidad con flujo de datos, la navegabilidad sólo debe expresar relación de iniciación. Ejemplo: un cliente requiere que se muestre un dato del sistema, esto se muestra mediante una flecha del actor al caso de uso a case (representando al sistema), aún cuando la mayor parte de los flujos de datos van del sistema al cliente.
Un actor se comunica con un caso de uso por múltiples razones:
1. Para invocar un caso de uso. Una instancia de un actor siempre invoca una instancia de un caso de uso.
2. Para solicitar algún dato almacenado en el sistema, el cual el caso de uso obtiene y presenta al actor.
3. Para cambiar el dato almacenado en el sistema mediante el uso de un diálogo con el sistema.
4. Para reportar que algo especial ha ocurrido alrededor del sistema y que dicho sistema debe cuidar.
Un actor inicia un caso de uso. Sin embargo, una vez que este ha comenzado, el caso de uso puede comunicarse con varios actores. Se pueden usar relaciones de comunicación entre casos de uso y actores para mostrar cuáles actores se comunican con ellos. La multiplicidad de las relaciones muestra cuántas instancias del actor se relacionan con una instancia del caso de uso al mismo tiempo.
Fuente
- E.V.A. UCI, I. D. S. Conferencia #3. Flujo de trabajo de Requerimientos.
