1. Requerimientos.
Los requerimientos para un producto o sistema de software determinan lo que hará el sistema
y definen las restricciones de su operación o implantación.
Los requerimientos se pueden dividir en dos:
+ Funcionales. Son declaraciones de los servicios que el sistema debe proveer o de cómo se
debe llevar a cabo el procesamiento.
+ No funcionales. Son restricciones del los servicios o funciones ofrecidas por el sistema.
Las restricciones son tecnología a aplicar, tiempo de respuesta, adopción de estándares.
capacidad de almacenamiento.
Es decir, no se refiere directamente a las funciones específicas del sistema.
Los requerimientos de manera típica son dados por el usuario, y son conocidos como los
requerimientos del usuario. Normalmente especifican el comportamiento externo del sistema
y evitan las características de diseño del sistema. Se redactan utilizando el
lenguaje natural, tablas y diagramas con el fin de que sean comprensibles.
Cuando los requerimientos del usuario son detallados se conocen como requerimientos del
sistema. Se enuncian de una manera precisa y libre de interpretaciones incorrectas. Se
redacta en un lenguaje estructurado, o de programación de alto nivel o uno especial
para especificar requerimientos.
El documento de requerimientos de software son la declaración acordada de los
requerimientos del sistemas. Se estructuran de tal forma que puedan ser utilizados
tanto por los clientes del sistema como por los desarrolladores del software.
El administrar los requerimientos, saber identificar entre funcionales y no funcionales,
entender los requerimientos de usuario y detallarlos para obtener requerimientos del sistema
se identifica como el proceso de la ingeniería de requerimientos.
Dicho proceso es parte del Proceso Unificado de Desarrollo de Software y consiste
en capturar los requisitos como casos de uso.
2. Artefactos.
Los artefactos son las entradas y salidas del proceso unificado de desarrollo de software
(PUDS).
Para el caso de la captura de requisitos, los artefactos fundamentales son el modelo de
casos de uso, que incluye los casos de uso y los actores y opcionalmente los prototipos de
interfaz de usuario.
2.1. Documentación de los requerimientos
El documento de requerimientos expresa de manera informal los alcances del sistema.
Un documento de requerimientos plasma el modelo del dominio o del negocio.
Un model del dominio captura los tipos de entidades MAS importantes en el contexto del problema a resolver.
Una manera mas completa de indicar los requerimientos es el modelo del negocio. Permite entender los procesos del negocio de la organización que requiere el sistema. (Esta manera es aplicable para sistemas de información, para otro tipo de sistemas se tiene que encontrar otra manera de modelar)
El objetivo de dichos modelos es dejar en una manera clara los procesos que tiene la organización y así integrar a los desarrolladores a la problematica a resolver, aunque ellos no sean expertos en el negocio, pueden entender su comportamiento
2.2 Modelos de caso de uso
El modelo de caso de uso plasma el acuerdo entre clientes y desarrolladores, y es un
modelo del sistema desde la perspectiva de la manera como se utiliza el sistema por los
usuarios.
En un modelo de caso de uso se incluyen los casos de uso y actores, ademas de sus relaciones.
En UML queda representado como un paquete que se compone de un sistema de caso de uso, que a
su vez agrega a un conjunto de actores y casos de uso.
Figura 1 2.3 Actor
El modelo de caso de uso describe lo que hace el sistema por cada tipo de usuario.
Cada usuario se representa por uno o más actores. Los actores representan terceros que interactuan con el sistema. Un actor es un tipo de usuario, y la instancia de ese tipo, el usuario real.
En UML se representa de la siguiente manera:
Figura 2 2.4 Caso de uso
Con un actor es posible identificar las entidades externas al sistema. Para definir las funcionalidades internas al sistema se especifican casos de uso.
Un caso de uso es una manera específica de utilizar al sistema mediante la ejecución de una funcionalidad del mismo
De manera mas preceis, un caso de uso especifica una secuencia de acciones que el sistema puede llevar a caba interactuando con sus actores, incluyendo alternativas dentro de la secuencia
Un caso de uso es una especificación, que indica el comportamiento de "cosas" dinámicas o instancias de los casos de uso.
En UML se representa como:
Figura 3 Cuando el sistema obedece un caso de uso esta creando una instancia del mismo.
Un casos de uso tiene un flujo de sucesos, que es una descripción textual de la secuencia de acciones del caso de uso. En dicha descripción se incluyen los actores y su relación con los casos de uso.
Si se desea incluir requisitos no funcionales, se puede indicar en una descripción textual que agrupe este tipo de requisitos
2.5 Glosario o diccionario de datos
Al definir un conjunto de requerimientos, surgen términos comunes que se comparten entre los clientes y desarrolladores del sistema. El glosario permite plasmar un acuerdo de como son entendidos los conceptos manejados.
Un glosario se representa como una clase o entidad.
Figura 4 2.7 Prototipo de interfaz de usuario
Se puede desarrollar un sistema inicial que permita aterrizar los conceptos expuestos en los casos de uso y glosario
Tipicamente el prototipo es una interfaz visual o de comandos que permite expresar los flujos básicos para lograr que el sistema implante su funcionalidad
En UML se representa como un icono de clase estereotipada, en este caso, con estereotipo de entidad:
Figura 52.7 Arquitectura desde la perspectiva de casos de uso
También conocida como las vista del modelo de casos de uso
La arquitectura debe incluir los casos de uso describan una funcionalidad importante y crítica o requisitos importantes que deben desarrollarse de manera inmediata en el ciclo de vida.
3. Funciones del analísta de sistemas, especificador de caso de uso,
diseñador de interfases de usuarios y prototipos, Arquitecto
En una fase de PUDS existen trabajadores, que son los roles que toman las personas en el proceso
El analista del sistema es el responsable del conjunto de requisitos que están modelados en los casos de uso, incluyendo requisitos funcionales y no funcionales. Esto implica que el es el guia para ver como atacar los requerimientos, pero sin llegar al detalle.
El especificador de casos de uso dan la descripción detallada de los casos de uso, incluyendo los flujos de sucesos.
Diseñador de interfaz de usuario dan forma visual a las interfaces gráficas, y luego entonces auxilian en el desarrollo del prototipo de interfaces de usuario.
El arquitecto del sistema ayuda a identificar la vista del modelo de casos de uso.
En el siguiente diagrama se muestra la relación entre los artefactos y los trabajadores:
Figura 6
4. Flujo de trabajoEl flujo de trabajo de esta fase se muestra a continuación:
Figura 74.1 Encontrar casos de uso y actores
Proposito:
Bosquejar las funcionalidades del sistema
Definir las fronteras del sistema, que va a manejar y que sera manipulado de manera
externa al sistema.
Definir quien y que va a interactuar con el sistema
Crear diagramas del modelo de caso de uso
Desarrollar un resumen del modelo de caso de uso
Pasos:
Encontrar Actores.
Cada tipo de factor externo que interactua con el sistema es representado como un actor.
Para encontar actores, se deben contestar las siguientes preguntas:
Cual grupo de usuarios requiere ayuda del sistema para realizar sus tareas ?
Cual grupo de usuarios se necesitan para ejecutar las funciones mas obvias del sistema ?
Cual grupo de usuarios son requeridos para reliazar funciones secundarias, como mantenimiento
y administración del sistema ?
El sistema interactuar con hardware y software externo ?
Cualquier individuo,grupo o factor que se encuentre como respuesta a las preguntas, son
candidatos a ser actores.
Para determinar cuando se tienen los actores correctos, se puede tener retroalimentación
con las personas o grupos identificados.
Puede ser dificil encontrar de manera inmediata todos los actores. Pueden encontrarse muchos
de ellos y luego ser necesario cambiarlos o descartarlos.
Un nuevo actor puede implicar un cambio radical en interfaces y funcionalidades del sistema.
Se debe definir cada actor, con una breve descripción de sus responsabilidades y que
requiere del sistema.
Encontar Casos de uso
Cuando se encuentren los acotres, el siguiente paso es buscar los casos de uso.
Los primeros casos de uso son muy preliminares y sin duda seran cambiados hasta que esten
estables. Dicha estabilidad se puede lograr agregando, removiendo, combinado y dividiendo
los casos de uso.
La mejor manera de encontrar casos de uso es considerar que es lo que requiere el actor.
El supuesto es que el sistema existe solo por sus usuarios y debe basarse en las necesidades
de los mismos.
Por cada actor, realizar las siguientes preguntas:
Cuales son las actividades primarias que el actor espera sean realizadas por el sistema ?
El actor crea, almacena, cambiar, borrar, o lee datos del sistema ?
El actor necesita informar al sistema acerca de cambios externos ?
El actor necesita ser informado de ocurrencias en el sistema ?
El actor inicializa o para al sistema ?
Para contestar estas preguntas, el flujo de eventos de los casos de uso se pueden representar
de manera inicial
Describir brevemente el modelo de caso de Uso
En la descripción del modelo de caso de uso, incluir lo siguiente:
Secuencias tipicas en las cuales el modelo de casos de uso es empleado por el usuario.
Funcionalidad no manipulada por el modelo del caso de uso
Descripción del modelo de casos de uso en su totalidad.
Se debe presentar el modelo de caso de uso en un diagrama de caso de uso, que muestra
la relación de casos de uso y actores.
Se entrega una descripción general que explica el modelo de casos de uso como un todo,
con la interacción de los casos de uso, actores y su relación entre sí.
Con el cliente se puede analizar la descripcion para:
Identificar si se han capturado como casos de uso todos los requerimientos
Saber si la secuencia de acciones es correcta, completa y comprensible
Identificar casos de uso que no agregan valor, y reconsiderarlo
Trabajador: Analista de sistemas
Entradas: Modelo del negocio, requisitos adicionales y lista de características
Salidas: Modelo esbozado de casos de uso y glosario
Figura 84.2 Asignación de Prioridades a los casos de uso
Propósito:
Definir la seleccion del conjunto de escenarios y casos de usos que serán analizados en
la actual iteración.
Definir los casos de uso que son significativos a la funcionalidad central
Definir casos de uso que tienen participación importante en la arquitectura.
Pasos:
Definir prioridades. Identificando los beneficios de cubrir una funcionalidad para
los usuarios, mitigación de riesgos, impacto en la arquitectura/
Trabajador: Arquitecto
Entradas: Modelo esbozado de casos de uso, Requisitos adicionales y glosario
Salidas: Vista del modelo de casos de uso.
Figura 94.3 Detallar los casos de uso
Propósito:
Describir detalladamente los flujos de eventos de un caso de uso
Tener una descripcion que el cliente y los usuarios entiendan.
Pasos:
Detallar el flujo de Eventos del caso de uso
El caso de uso debe incluir lo siguiente:
El estado inicial
Cómo y cuándo comienza el caso de uso
El orden requerido en el que las acciones de deben ejecutar
Cómo y cuándo termina el caso de uso
Posibles estados finales
Caminos de ejecución que no están permitidos
Descripción de caminos alternativos a la secuencia básica
La interacción del sistema con los actores y qué cambios producen.
Trabajador: Especificador de casos de uso
Entradas: Modelo esbozado de casos de uso, Requisitos adicionales y glosario
Salidas: Caso de uso (detallado)
Figura 104.4 Especificar el prototipo e interfaz de usuario
Propósito:
Crear un prototipo de un caso de uso via una interfaz de usuario
Pasos:
Diseñar el prototipo de la interfaz de usuario
Implementar el prototipo
Obtener retroalimentación
Trabajador: diseñador de interfases de usuarios
Entradas: Modelo de casos de uso, requisitos adicionales, caso de uso, glosario
Salidas: Prototipo de interfaz de usuario
Figura 11 4.5 Estructurar a los casos de uso
Propósito:
Extraer el comportamiento de casos de uso que necesitan ser considearso como casos
de uso abstractos. Ejemplo de dicho comportamiento son comportamiento en común, comportamiento
opcional, excepcional y comportamiento que se desarrollara en iteraciones posteriores.
Encontar nuevos actores abstractos que definen roles que son compartidos por varios
actores
Pasos:
Establecer relaciones de Inclusión entre casos de uso
Si un caso de uso contiene un segmento de comportamiento en el cual el resultado, no el metodo
de obtener el resultado, es de importancia a cualquier de los casos de uso, su comportamiento
puede ser factorizado a un nuevo caso de uso de inclusión.
Establecer relaciones de extensión entre casos de uso
Si un caso de uso tiene un segmento de comportamiento opcional o excepcional, y que no
contribuye en manera importante al casos, factorizarlo a un caso de uso de extensión
Establecer relaciones de generalizaci casos de uso
Si dos o mas casos de uso tiene similitudes en estructura y comportamiento, se puede
factorizar el comportamiento para crear un caso de uso padre.
Establecer relaciones de generalización entre actores
Los actores que tengan caracteristicas en comun, pueden originar una generalizacion de actor
Trabajador: Analista de sistemas
Entrada: Modelo de casos de uso, requisitos adicionales, caso de uso, glosario
Salida: Modelo de casos de uso (Estructurado)
Figura 12