Análisis de Requerimientos del sistema

Análisis de Requerimientos En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se le va a presentar la solución que está buscando. Actividades Técnicas 1. Identificar Casos de Uso del sistema Esta información se representa en un diagrama de casos de uso. Cómo encontrar un actor? • Identifique los usuarios del sistema o Porqué se diseña el sistema? o Cuáles son los actores que el sistema va a beneficiar? o Qué actores van a interactuar directamente con el sistema? (actores primarios) o Qué actores van a supervisar, mantener, recibir información del sistema? (actores secundarios) • Identifique los roles que juegan esos usuarios desde el punto de vista del sistema • Identifique otros sistemas con los cuales exista comunicación Cómo encontrar un caso de uso? Identifique las operaciones importantes del sistema a construir Cuáles son las principales tareas de un actor? Qué información tiene el actor que consultar, actualizar, modificar? Cómo? Qué cambios del exterior debe informar el actor al sistema? Qué información debe informársele al actor, con respecto a los cambios del sistema? Cómo encontrar relaciones entre actores y casos de uso? Identifique los casos de uso en los cuales se vé implicado un actor Busque relaciones extends entre casos de uso Qué casos de uso son similares, diferenciándose en la forma en la cual hacen algunas operaciones? Qué caso de uso redefine la forma en la cual se realiza una transacción dentro de otro caso de uso? Busque relaciones uses entre casos de uso Que casos de uso son usados como transacciones de otros? 2. Dar detalle a los casos de uso descritos Describir la información de entrada y salida de cada caso de uso Descripción detallada del caso de uso • Descripción textual de su objetivo • Variantes posibles para realizar este caso de uso. Diagramas de interacción de detalle (de secuencia o colaboración) • Errores y excepciones posibles en el caso de uso Relacionar el caso de uso con la interfaz a usuario que lo representa Especificar el diálogo que da solución al caso de uso (ver definición de interfaz) 3. Definir una interfaz inicial del sistema (si es aplicable) Dibujar las pantallas de interacción para los distintos actores-usuarios Copiar el modelo mental del usuario Revisar los elementos del modelo del mundo interesantes para el actor-usuario (Ver Modelo del Mundo) Visualización típica de los elementos del modelo del mundo Información relevante para el actor Metáforas de interacción válidas Especificar el diálogo que da solución a cada caso de uso que se soluciona con la interacción con esta interfaz. Puede especificarse este diálogo de varias maneras, dependiendo de la complejidad de la interfaz definida (en esta etapa se sugiere escoger el mínimo nivel de detalle posible, para dar más libertad de diseño en las etapas posteriores): 1. Por medio de una descripción textual de su funcionamiento 2. Por medio de diagramas de interacción que muestren la secuencia de operaciones entre los objetos de interfaz y los actores involucrados 3. Por medio de diagramas de estados, donde se muestre claramente los estados de la interfaz Por medio de un prototipo funcional, en términos de la interacción con el usuario Definir restricciones para la comunicación con actores y sistemas Describir en el detalle del actor o de la relación con el caso de uso particular 4. Desarrollar el modelo del mundo Esta información se representa en un diagrama de estructura estática de clases. Identificar Clases • Elementos físicos y lógicos dentro del sistema a modelar • Top-down: Comenzar por la clase del objeto más general (el mundo). Encontrar sus componentes hasta llegar a clases de tipos básicos • Identificar los sustantivos del enunciado del problema y determinar si son clases del modelo del mundo • Identificar clases desde el punto de vista de la información o Identifique los elementos del espacio del problema o Identifique otros sistemas relacionados como objetos externos o Identifique dispositivos relacionados o Identifique los eventos que el sistema debe recordar y manipular o Identifique los roles de los elementos del mundo o Identifique sitios o Identifique unidades organizacionales importantes en el problema • Identificar clases desde el punto de vista funcional (casos de uso) o Identifique los objetos que participan en un caso de uso particular o Continue con los mensajes de cada objeto, dejando para el final los atributos. • Identificar clases desde el punto de vista de sus estados o En qué estados está en sistema? Cuáles objetos determinan estos estados? o Cómo es el ciclo de vida de estos objetos? Posibles errores: • Una clase HACE en vez de una clase ES • Solo se requiere un objeto de la clase • Dificultad para encontrar atributos • Objetos con iniciativa propia • Es un objeto y un usuario a la vez • Solo se encuentra un servicio • Varias clases tienen los mismos atributos o servicios • Solo tienen información o mensajes no relevantes para el problema • Vista Funcional: Dividir un sistema de la manera clásica Identificar atributos y asociaciones. • Cuáles son las características determinantes del objeto en el dominio del problema? • Con qué objetos esta relacionado? • Con qué objetos debe estar relacionado para realizar sus mensajes? • Identificar el nombre, los roles y cardinalidad de las asociaciones • Qué asociaciones hay de tipo partes y un todo (composición)? • Qué información se requiere en una clase para realizar su comportamiento? Posibles errores • Identificar atributos o relaciones no relevantes a los casos de uso identificados • Las relaciones no reflejan directamente la realidad Identificar mensajes • Punto de vista funcional o Qué mensajes debe tener un objeto para colaborar en un caso de uso? • Punto de vista de comportamiento o Qué comportamiento se espera de un objeto dado en el modelo del mundo? o Qué mensajes se requieren para manipular la información que contienen? o Qué mensajes requieren para manipular las relaciones que tiene? o Qué mensajes hacen que el objeto cambie de un estado a otro? Posibles errores • Identificar servicios no relevantes a los casos de uso identificados • Identificar servicios que no puede realizar la clase por falta de información Identificar relaciones de herencia • Qué clases son abstracciones naturales de clases ya existentes? • Qué clases comparten atributos o servicios? • Qué clases extienden atributos o servicios de otras? Posibles Errores • No tener una relación Es Un entre las clases Identificar restricciones del modelo • Identificar valores posibles y no posibles de los atributos. Describirlos como restricciones de las clases • Identificar valores permitidos para las asociaciones. Describirlos como restricciones de la asociación • Identificar restricciones que relaciones dos o más atributos o relaciones. Describirlas dentro de la clase correspondiente Posibles errores • Hay estados en el modelo imposibles en el mundo real • Hay estados en el mundo real no considerados en el modelo Identificar paquetes • Qué subdivisiones lógicas pueden tener las clases identificadas? • Que subconjunto de clases y casos de uso pueden ser reutilizados en otros dominios? • Combinar clases fuertemente relacionadas en un paquete • Combinar clases que tienen que ver con los mismos casos de uso en un paquete Consideraciones de reutilización • Reutilizar modelos de dominio existentes • Identificar posibles variantes en el futuro tenerlas en cuenta para diseño (patrones) 5. Validar los modelos Validar las restricciones descritas para las clases • Para cada clase evaluar la completitud de las restricciones • Desarrollar objetos ejemplo que cumplan con las restricciones y que no sean válidos en el mundo real Validar atributos y mensajes • La clase tiene toda la información necesaria para desarrollar la tarea? • La clase tiene las relaciones necesarias para propagar el mensaje y cumplir con la tarea? • Los mensajes si son utilizados dentro del contexto del problema? • Los mensajes obligan la conservación de las restricciones del modelo? Desarrollar diagramas de interacción (diagramas de secuencia o de colaboración) para la variante por defecto de cada caso de uso, usando los objetos del modelo del mundo encontrados y sus mensajes. • Escoger la opción por defecto de cada caso de uso • Identificar los objetos involucrados • Desarrollar el diagrama de secuencia o el de colaboración para la interacción Validar los diagramas de Interacción • Todo mensaje de un objeto a otro implica una asociación y un rol en el diagrama de clases • Todo mensaje está definido en su correspondiente clase • Opcional: Completar el diagrama de clases con asociaciones de dependencia a las clases de los argumentos de los mensajes Validar con un experto del dominio • Validar estructura del mundo • Validar funcionalidad esperada del sistema • Validar los diagramas de interacción descritos como detalle de los casos de uso Validar con un usuario representativo de cada actor • Validar la funcionalidad esperada para el actor en particular: completitud, relevancia • Validar los diagramas de interacción descritos como detalle de los casos de uso del actor • Validar la interfaz diseñada y el diálogo descrito Iterar si es necesaria más información Un Requerimiento funcional define el comportamiento interno del software: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de uso serán llevados a la práctica. Son complementados por los requerimientos no funcionales, que se enfocan en cambio en el diseño o la implementación. Como se define en la ingeniería de requerimientos, los requerimientos funcionales establecen los comportamientos del sistema. Típicamente, un analista de requerimientos genera requerimientos funcionales luego de graficar los casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un proceso iterativo y algunos requerimientos ser previos al diseño de los CU. Ambos artefactos, los documentos del caso de uso y los de los requerimientos, se complementan en un proceso bidireccional. Un requerimiento funcional típico contiene un nombre y un número de serie único y un resumen. Esta información se utiliza para ayudar al lector a entender por qué el requerimiento es necesario, y para seguir al mismo durante el desarrollo del producto. El núcleo del requerimiento es la descripción del comportamiento requerido, que debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interacción con usuarios, inversores y otros expertos en la organización. Libros [editar] • Wiegers, Karl E. (2003). Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle, 2nd ed., Redmond: Microsoft Press. ISBN 0-7356-1879-8. (en inglés) • Andrew Stellman and Jennifer Greene (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8. (en inglés) Los requerimientos no funcionales especifican propiedades del sistema como restricciones de ambiente y desarrollo, performance, dependencias de plataformas, mantenibilidad y confiabilidad. Los requerimientos de performance imponen condiciones sobre los requerimientos funcionales como velocidad, tiempo de respuesta y uso de la memoria. La mayoría de los requerimientos de performance solamente son relevantes para cada caso de uso y por lo tanto deben estar conectados a cada uno en particular. Esto significa que deberán establecerse en la descripción de cada caso de uso, posiblemente en una sección separada de Requerimientos Especiales. Algunos requerimientos no funcionales se refieren a fenómenos del mundo real, estos pueden ser capturados inicialmente en el documento de requerimientos y luego al determinar los casos de uso y los conceptos asociados, se relacionan a éstos en el glosario o más formalmente a las clases en el Modelo de Análisis. Finalmente, algunos requerimientos no funcionales son genéricos y no pueden conectarse con un caso de uso particular o una clase específica, por lo cual serán manejados separadamente en la lista de Requerimientos No Funcionales. Fase Inicial: En esta fase se clasifican la mayoría de los requerimientos no funcionales. Los que son específicos a un caso de uso se adjuntan a él, los que son específicos a un objeto van a terminar en el glosario adjuntados al modelo de casos de uso, los mas generales, que son menos en numero van a los requerimientos No Funcionales. Si se decidió realizar un prototipo de algún Riesgo identificado, se deben tener en cuenta los requerimientos No Funcionales que sean específicos a los casos de uso correspondientes. Fase de elaboración: A medida que se siguen encontrando casos de uso, aparecen nuevos requerimientos no funcionales y los requerimientos no funcionales que ya habían sido identificados podrían ser adjuntados a los nuevos casos de uso. Fase de Construcción: No se aplica Salida : • • Modelo de Casos de uso (refinado) • • Lista de requerimientos No Funcionales (refinada) Personas Involucradas :  Analistas  Arquitecto Responsable :  Analista