METODOLOGÍA DE SISTEMAS UNIDAD II: CAPTURA DE REQUISITOS Ing. Patricia Ontiveros Ing. Laura Zeligueta

Captura de Requisitos Etapa del proceso que se ocupa de producir un conjunto de requisitos a satisfacer por el nuevo sistema. No se realiza un análisis de la situación actual, sólo lo que se pueda describir como requisito a satisfacer.

De la Visión a los Requisitos Llamamos captura de requisitos al acto de descubrimiento. Es el proceso de averiguar lo que se debe construir. Para que el cliente sea capaz de comprender el resultado de la captura de requisitos debemos usar el lenguaje del cliente

Qué son los requisitos? Definimos requisito como “una especificación de lo que se debería implementar”. Existen 2 tipos de requisitos: Los funcionales: qué comportamiento debería ofrecer el sistema. Los no funcionales : una propiedad específica o restricción del sistema.

En principio son una declaración de lo que debería hacer el sistema y no de cómo debería hacerlo. Las restricciones de implementación predeterminan el “como” del sistema.  Así podemos decir que: Los requisitos funcionales se relacionan con: Clientes, productos, pedidos, pagos. Los requisitos no funcionales se relacionan con: Rendimiento, capacidad, disponibilidad,seguimiento de estándares, seguridad.

Flujo de Trabajo Trabajo a realizar Artefactos resultantes Enumerar los requisitos candidatos Lista de características Comprender el contexto del sistema Modelo del Negocio o del Dominio Capturar requisitos funcionales Modelo de Casos de Uso Capturar requisitos no funcionales CU concretos o Requisitos Adicionales

Enumerar los requisitos candidatos Hacer una lista de ideas que se considera un conjunto de requisitos candidatos, algunos se convierten en requisitos propiamente y se transforman en artefactos como casos de uso y algunos se dejan para una versión futura.

Comprender el contexto Hay dos formas de expresar el contexto: modelando el dominio y modelando el negocio. El modelo de Dominio describe los conceptos importantes del contexto como objetos , y los enlaza unos con otros. El modelo de Negocio describe los procesos con el fin de comprenderlos y especificar qué procesos de negocio soportará el sistema.

Capturar requisitos funcionales La técnica para identificar los requisitos se basa en los CU, que capturan tanto los funcionales como los no funcionales que específicos de cada casa de uso. Recordemos que los casos de uso representan una forma de usar el sistema por un actor.

Capturar requisitos no funcionales Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno, de la implementación, rendimiento, dependencias de la plataforma, aspectos físicos y de interfaz. Algunos requisitos no funcionales son específicos de un CU concreto o afectan a ciertos CU. Otros son más genéricos y no pueden relacionarse con un CU concreto, éstos se gestionan como Requisitos Adicionales haciendo una lista.

Ejemplo. Cajero automático Lista de requisitos candidatos FUNCIONES BÁSICAS R1. El usuario podrá consultar el saldo de su cuenta R2. Si el usuario intenta sacar una cantidad que supera el saldo de su cuenta, el cajero le avisará de que no es posible sacar esa cantidad R3. Si el usuario intenta sacar una cantidad que supera el límite diario, el cajero le avisará de que no es posible y volverá a solicitar una cantidad R4. El cliente del banco podrá hacer una transferencia a otra cuenta ..................... REQUISITOS NO FUNCIONALES Fácil de usar Tiempo de respuesta inferior a 30 seg.

Ejemplo. Cajero automático Casos de uso. Descripción inicial Caso de uso: Sacar dinero Actores: Cliente (iniciador) Descripción: El caso de uso comienza con la identificación del usuario. El cliente usa el caso de uso para acceder a su cuenta. El caso de uso le devuelve el dinero solicitado, un aviso de que no tiene saldo o de que ha excedido el límite diario. Caso de uso: Consultar saldo Actores: Cliente Descripción: El caso de uso comienza con la identificación del usuario. El usuario consulta el saldo de su cuenta.

Caso de uso “Sacar dinero” Flujo de eventos ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero 2. Pide la clave de identificación 3. Introduce la clave 4. Comprueba la clave. 5. Presenta las opciones de operaciones disponibles 6. Selecciona la operación de Reintegro 7. Pide la cantidad a retirar. 8. Introduce la cantidad requerida 9. Procesa la petición y da el dinero solicitado. Devuelve la tarjeta y genera un recibo 10. Recoge la tarjeta. 11. Recoge el recibo 12. Recoge el dinero y termina el caso de uso

El papel de los requisitos en el ciclo de vida del software Inicio: se captura los CU para delimitar el sistema y el alcance Elaboración: se captura la mayoría de los requisitos restantes llegando al 80%

Modelo de Negocio El modelado de Negocio es una técnica para comprender los procesos de negocio de la organización. El resultado de esta actividad está soportado por 2 modelos de UML: el modelo de CU y el modelo de objetos.

Cómo desarrollar un Modelo de Negocio Los modeladores deben identificar: Un actor por cada trabajador y por cada actor del negocio que se convertirá en usuario del sistema. Los CU del negocio que utilizan los actores

Modelo de Negocio – Modelo CU II. Breve Tour por UML Modelo de Negocio – Modelo CU Ejemplo: Cajero automático