análisis e ingeniería de requisitos · las fuentes de requerimientos no funcionales y de negocio...

Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 1

Análisis e Ingeniería de Requisitos Tema 3: Captura de Requisitos (I)

Curso 2011-2012


Bibliografía Básica

Ingeniería del Software: un enfoque práctico. Pressman, McGraw-Hill,

2002 5ª Ed.

Ingeniería del Software. Ian Sommerville,Addison Wesley, 2004ª Ed.

Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión. Piattini et al., RA-MA, 1996.

Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es

Proceso de Desarrollo de Requisitos

AIR - 3

Captura de Requisitos Análisis y Negociación

de Requisitos

Documentación de Requisitos Validación de Requisitos

Requisitos Informales

Requisitos Negociados

Borrador del documento de requisitos

Documento de requisitos e informe de validación


Índice de transparencias

Fundamentos de la captura de requisitos

Introducción al proceso unificado

Captura de requisitos según el proceso unificado

1. Enumerar requisito candidatos

2. Comprender el Contexto del Sistema

3. Capturar los Requisitos Funcionales

4. Capturar los Requisitos no Funcionales

Parte I

Parte II


Captura de Requisitos

Captura de requisitos:

En esta etapa los ingenieros de software (IS) trabajan con los clientes y los usuarios finales del sistema.

Determinar: el dominio de la aplicación

qué servicios debe proporcionar el sistema

rendimiento requerido del sistema

restricciones de hardware

etc.



Obtener y comprender los requisitos de los stakeholders es difícil por varias razones:

Los stakeholders no conocen lo que desean obtener de un sistema informático.

Expresan los requerimientos con sus propios términos y con un conocimiento implícito de su propio trabajo.

Diferentes stakeholders tienen diferentes requisitos. Además los suelen expresar de diferentes formas. Los IS tienen que trabajar en todas esas fuentes y determinar las concordancias y conflictos entre requisitos.

Pueden existir factores políticos que determinen la importancia o relevancia de ciertos requisitos.

El entorno económico y de negocios siempre suele ser dinámico. Esto hará que varíe la importancia de ciertos requisitos. Y que aparezcan nuevos stakeholders - > nuevos requisitos.



Proceso de obtención y análisis de requisitos

Descubrimiento de requisitos

(I)

Clasificación y organización de requisitos

(II)

Ordenación de requisitos

(III) Documentación

de requisitos (IV)



Proceso de obtención y análisis de requisitos:

1. Descubrimiento de requisitos. Interacción con los stakeholders para recopilar requisitos. Lectura de la documentación existente y de las especificaciones de sistemas similares.

2. Clasificación y organización de requisitos. Se toman los requisitos recopilados no estructurados y los grupos relacionados de requisitos y los organiza en grupos coherentes.

3. Ordenación por prioridades y negociación de requisitos. Al existir muchos stakeholders, muchos requisitos entrarán en conflicto. En esta actividad se organizan los requisitos según las prioridades, y se resuelven los conflictos a través de negociaciones.

4. Documentación de requisitos. Se documentan los requisitos generando documentos formales o informales. Se puede volver a realizar otra iteración


Fuentes de Información

Los requisitos se originan a partir de: Objetivos

Documentación existente

Conocimiento del Dominio

Interesados (stakeholders)

Entorno operacional y organizacional

Estas diferentes fuentes han de tenerse en cuenta como diferentes puntos

de vista, donde cada uno representa un subconjunto de requisitos, es decir, una perspectiva nueva. Aunque los requisitos no tendrán por qué totalmente independientes.




Puntos de vista: Se utilizan como una forma de clasificar los stakeholders y las fuentes de los requisitos. Existen tres tipos genéricos:

Puntos de vista de los interactuadores: Representan a las personas/sistemas que interactuarán directamente con el nuevo sistema. o Ejemplo: Con respecto al desarrollo de un móvil serían el usuario del móvil, la operadora

de telefonía y los dispositivos con los que se comunique el móvil vía Bluetooth, por ejemplo.

Puntos de vista indirectos: representan a los stakeholders que no utilizan el sistema pero que, de algún modo, influyen en los requisitos. o Ejemplo: Los gerentes de la operadora.

Puntos de vista del dominio: representan las características y restricciones del dominio que influyen en el sistema. o Ejemplo: Representa los estándares de comunicaciones vía móvil que imponga la

operadora/sistemas de telecomunicaciones.



Tipos de puntos de vistas más específicos: Los proveedores de servicios al sistema y los receptores de dichos servicios.

Los sistemas que deben interactuar con el sistema a especificar

Las regulaciones y estándares que se aplican al sistema

Las fuentes de requerimientos no funcionales y de negocio del sistema

Los puntos de vista de las personas que tienen que desarrollar, administrar y mantener el sistema.

Los puntos del vista del marketing y otros que generan requerimientos sobre las características del producto esperadas por los clientes y cómo el sistema debería reflejar la imagen externa de la organización.


Puntos de vista: Ejemplo para un sistema que gestiona una biblioteca


Todos los puntos de vista

Indirectos Interactuadores Dominio

Administrador de la Biblioteca

Finanzas Proveedor de

artículos Usuarios

Personal de la Biblioteca

Estándares de IU

Sistemas de Clasificación

Estudiantes

Personal

Externos

Administradores del sistema

Catalogadores



Una vez identificados y estructurados los puntos de vista, se deben identificar los más importantes y comenzar con el descubrimiento de los requisitos



Diferentes técnicas:

Entrevistas, JAD, tormenta de ideas, prototipado, etc.

Técnicas más visuales y estructuradas para la comprensión del dominio

Escenarios

Modelos de Casos de Uso

User stories (Metodologías ágiles)

Modelos de contexto: • Diagrama de contexto (metodologías estructuradas)

• Modelo de domino o modelo de negocio (proceso unificado)

• Modelo de procesos de negocio



Escenarios

Escenarios: Esbozos de la interacción de los stakeholders con el sistema.

Primero hay que identificar los diferentes escenarios para los diferentes grupos de usuarios.

El escenario comienza con esbozo de la interacción y durante la obtención se agregan detalles para una descripción más completa.

Un escenario puede incluir:

Lo que esperan el sistema y los usuarios cuando el escenario comienza. Una descripción del flujo normal (básico) de eventos en el escenario. Una descripción de lo que puede ir mal y cómo manejarlo. Información adicional de otras actividades que pueden realizarse al mismo tiempo. El estado del sistema cuando el escenario termina.


Ejemplo para “Nuevo contacto” en el teléfono móvil:

Cabecera Descripción

Suposición inicial El usuario habrá encendido el móvil, habrá desbloqueado el móvil y habrá seleccionado la opción de menú correspondiente.

Normal El usuario introduce el nombre del contacto y el número de teléfono. Después pulsa el botón aceptar. Se verifica si el nombre o el teléfono están duplicados y si no ocurre, se almacena el nuevo contacto.

Qué puede salir mal Que el nombre o el teléfono estén ya duplicados. Entonces se le notificará al usuario para que lo corrija o lo acepte.

Otras actividades Recibir SMS o llamada telefónica.

Estado del sistema al finalizar

El usuario volverá a la situación inicial, antes de entrar en el menú (o dentro del submenú que permitía agregar un nuevo contacto).


Escenarios


Captura de Requisitos Casos de Uso

Casos de uso: Describe, en un diagrama UML, los elementos externos (actores) que interaccionan con el sistema a desarrollar y qué servicios ofrece dicho sistema al elemento externo.

¿Un caso de uso es un escenario? Un caso de uso engloba todos los escenarios de una funcionalidad

concreta incluyendo su flujo normal y los alternativos.


Captura de Requisitos Casos de Uso

Ejemplo: Teléfono móvil


Captura de Requisitos User stories

Historia de Usuario: es una descripción simple de un requisito de un sistema. Escrito a manera de frase corta y sencilla y que representa el deseo de un interesado. Se puede definir como el recordatorio de una conversación con el cliente.

Contenido básico:

Título (el nombre de la historia de usuario)

Quien lo solicita (usuario o persona)

La acción (lo que espera)

Lo que espera (beneficio)

Más detalles:

Id

Valor y tiempo estimado de realización

Prioridad

Quien lo ha escrito

AIR - 19


Captura de Requisitos User stories

AIR - 20



Modelo de contexto

Diagrama de contexto: se utiliza para definir los límites del sistema.

Es preciso trabajar conjuntamente con los stakeholders para comprender lo que es el sistema y lo que es el entorno. Una vez delimitado el sistema se define el contexto y las relaciones del sistema con el entorno Ejemplo: un sistema que gestiona pedido de proveedores

0

Gestión de

Pedidos a

Proveedores

PROVEEDORES Albarán

Pedido Proveedor

CLIENTES

MINORISTAS

Pedido Minorista

DNI Minorista



Modelo de contexto

Modelo de dominio y modelo de negocio: Estudiaremos éstos más adelante en esta misma unidad.



Modelo de contexto

Modelo de procesos de negocio: se utilizan para el modelado de los procesos de negocio de una empresa

Es un modelo de proceso (flujo de trabajo) El objetivo es proporcionar una comprensión completa de los negocios del cliente. Existen diversas técnicas. BPMN (Business Process Modeling Notation) es la técnica estándar para el modelado de procesos de negocios Ejemplos de procesos de negocio de un banco: aceptar depósitos de los clientes, conceder préstamos a los clientes, hacer inversiones, etc. Ejemplo: proceso de negocio de una compra.



Ejercicio: Cajero automático

1. Identifique puntos de vista (interactuadores, indirectos y de dominio)

2. Describa el escenario para la extracción de dinero.

3. Construya el modelo de caso de uso.

análisis e ingeniería de requisitos · las fuentes de requerimientos no funcionales y de negocio...

Documents