ANLISIS Y DISEO DE SISTEMAS II

TEMA 4
SEMANA 6
SEMESTRE 2016 II
DOCENTES DEL CURSO

Tema4
GESTION DE REQUISITOS SEGN RUP

Contenido
Gestin de Requisitos segn RUP
1. Qu es la pirmide de requisitos?
2. Caractersticas de un buen requisito.
3. Visin General de la gestin de requisitos segn
RUP

1. QU ES UNA PIRMIDE DE
REQUISITOS?

Es la forma de mostrar los tipos de requerimientos

en forma de Pirmide.
Tipos de requerimientos:
Necesidades del stakeholder
Caractersticas
Casos de uso
Requisitos suplementarios
Casos de prueba
Escenarios.
4

PIRMIDE DE REQUISITOS

Los diferentes niveles marcan el nivel de detalle, pues cuanto menor

sea el nivel, la exigencia de detalle de un requisito ser mayor.
5

1.1. Necesidades del

Stakeholders
Describe lo que el sistema debera hacer para mejorar o
reducir el costo de un proceso de negocio, incrementar
ganancias o alcanzar regulaciones y otras obligaciones.

Stakeholder

ID

Necesidad

STRQ1

Necesito notificar al jefe de soporte cuando una solicitud de

soporte es iniciada

Jefe de soporte

STRQ2

Necesito asignar solicitudes de soporte a un ingeniero de

soporte especfico

Jefe de soporte

STRQ3

Necesito mantener informado al cliente del progreso de una

solicitud de soporte

Cliente

1.2. Caractersticas del sistema

Es un servicio que el sistema provee para satisfacer una o

ms necesidades del afectado. Formulada por el analista del
negocio. Estn descritas en el documento Visin.
ID

Caracterstica

Descripcin

FEAT1

La solicitud de soporte pasar por

El sistema funcionar orientado al una serie de etapas y
trabajo en flujo
asignaciones

FEAT2

Un sistema de notificacin de
Capacidad de notificacin por e- correo centralizado ser utilizado
mail
por el flujo de trabajo

1.3. Casos de Uso

Descripcin del comportamiento del sistema en trminos de
secuencia de acciones.
El propsito de un caso de uso es facilitar los acuerdos entre
los desarrolladores, clientes y usuarios acerca de lo que el
sistema debe hacer.
Base para las realizaciones de casos de uso en el MA y MD.
Expresan los requisitos funcionales del sistema - Diagrama de
casos de uso.
ID
UC1

UC2

Caso de Uso

Descripcin

Generar reserva de habitaciones

Este caso de uso permite registrar la reserva de

uno o ms habitaciones disponibles para un
cliente que lo solicita.

Consultar disponibilidad de
habitaciones

El caso de uso permite consultar la

disponibilidad de una habitacin por algn
criterio de bsqueda: categora, tipo y/o rango
de precios.
8

1.4. Requisito Suplementario

Conocido como requisito de arquitectura o factores de
calidad.
Son los requisitos que no se pueden expresar en CU.
Para crear Requisitos Suplementarios, hacer lo siguiente:
Crear una lista de categoras de los requisitos
suplementarios
Crear preguntas para cada categora.
Explicar al cliente el impacto y costo de cada decisin.
Capturar la respuesta del cliente a cada pregunta.
Asignar prioridad y peso a cada requisito.
Tambin se pueden obtener a partir de las caractersticas
(features) identificados en un nivel anterior de la pirmide.
Rational Software, por Robert Grady - en 1992
Clasificacin llamada FURPS+ (Funcionalidad, facilidad de
9
uso, Confiabilidad, Rendimiento y de Soporte).

10

11

1.5. Caso de Prueba

Consiste en una especificacin de entradas de pruebas,

ejecucin de condiciones y resultados esperados.
Determinan si el requisito funcional o no funcional, es parcial
o completamente satisfactorio.
Creados por el desarrollador, testers, clientes o usuarios.
Se pueden utilizar para pruebas manuales automatizadas
utilizando herramientas (IBM Rational Robot e IBM Rational
Functional Tester).

12

1.6. Escenario
Un escenario es una instancia de un CU.
Es una secuencia de acciones obtenidas del flujo de eventos
de un CU.
Flujo de Eventos: Flujo bsico y alternativos sub flujos.

13

2. Caractersticas de un buen
requisito
Un requisito debe cumplir varios criterios para ser
considerado un "buen requisito". Las caractersticas que
presentan los requisitos son: No ambiguo, Verificable, Claro,
Correcto, Comprensible,
Necesario y Abstracto.

Factible,

Independiente,

Atmico,

Adems de estos criterios para los requisitos individuales,

tres criterios se aplican al conjunto de requisitos. El conjunto
debe ser: Consistente, No redundante y Completo.

14

1.2. Captura de requisitos

Se concentra en capturar las necesidades de stakeholders
utilizando las tcnicas siguientes:
Entrevistas
Cuestionarios
Workshops
Storyboards
Role-playing
Sesiones de lluvias de ideas (brainstorming)
Prototipos
Casos de uso.
15

1.3. Desarrollo del documento

Visin
Documento importante, el cual puede ser utilizado como un
contrato de los requisitos tcnicos.
El propsito del documento es:
Definir los lmites del sistema
Identificar restricciones del sistema
Conseguir acuerdos con los clientes sobre el alcance
Crear una base sobre la cual se definen los casos de uso
y especificaciones suplementarias
Es un repositorio de los requisititos del tipo Caracterstica
(Feature) y son listados en la seccin Caractersticas del
Producto del documento.
16

17

 Las caractersticas se derivan de las necesidades de los

stakeholders.
Ver las estrategias de transformacin, para crear uno o
varios requisitos FEAT (Features) a partir de los requisitos
STRQ (Stakeholders request) .
Una vez creados los requisitos del tipo caractersticas, se
debe especificar sus atributos. Los atributos ayudan a
organizar y analizar los requisitos.
Ver los atributos que usualmente presentan las
caractersticas de los requisitos

18

1.4. Creacion de Casos de Uso

Los requisitos funcionales son mejor descritos en forma de
casos de uso.
Se derivan de las caractersticas y a partir de los casos de
uso se derivan sus escenarios.
Facilita los acuerdos entre desarrolladores, clientes y
usuarios acerca de lo que el sistema debe hacer.
Puede ser usado como un contrato entre los desarrolladores
y clientes.
Es la base para las realizaciones de casos de uso en el
anlisis y diseo; documentacin y casos de prueba.
19

 Caractersticas de casos de uso:

Son iniciados por un actor.
Modelan una interaccin entre el actor y el sistema.
Describen una secuencia de acciones.
Capturan requisitos funcionales.
Proporcionan algn valor a un actor.
Representan un completo y significativo flujo de eventos.
Incluye las siguientes actividades (visto en clases
anteriores):
Encontrar actores
Encontrar casos de uso y detallarlos
Estructurar el modelo de casos de uso.
20

21

1.5. Especificacin Suplementaria

Captura todos los requisitos que no pueden ser expresados
en casos de uso.
La ECU tambin contiene los requisitos no funcionales, si se
aplican a un solo caso de uso. La Especificacin
Suplementaria contiene todos los requisitos funcionales
genricos que no estn asociadas con ningn caso de uso
especfico.
Muchas caractersticas del documento Visin se convierten
en requisitos suplementarios.
Organizar los requisitos en la seccin apropiada del
documento, de acuerdo a la categora FURPS +.
22

Tipo de
requisito

Funcional

No Funcional

Especificacin de caso de uso

Especificacin
suplementaria

Flujo bsico, sub flujos y flujos

alternativos relacionados a un
caso de uso especfico.

Requisitos
funcionales
relacionados a
ms de un caso
de uso.

Especificacin no funcional
relacionada a un solo caso de
uso.

Requisitos no
funcionales
relacionados a
muchos casos
de uso.

23

24

1.5.1. Creacin de Casos de

Prueba

A menudo, a los testers se les da una impresin de ECU y a

continuacin, ellos realizan las pruebas manuales.
Si descuidamos la creacin formal de los CdP, se puede
terminar con una cobertura pobre de un universo de pruebas
o ejecutando pruebas duplicadas.
Cuando tengamos todos los escenarios de un CU, se crean
los CdP, se siguen los siguientes pasos:
Identificar las variables para cada paso del caso de uso.
Identificar opciones significativamente diferentes para
cada variable.
Combinar opciones en estudio en los casos de prueba.
Asignar valores a las variables.
25

26

1.5.2. Creacin de CdP de la

Especificacin suplementaria
No existe un criterio unificado para crear CdP para requisitos
complementarios debido a que estos requisitos son de
diferente naturaleza.
Se presenta los mtodos de creacin de estos CdP:
Ejecutar CdP seleccionados en diferentes entornos
Agregando una comprobacin adicional a todos los CU
Comprobando y modificando CU especficos
Realizar la accin descrita en el requisito
Listas de verificacin
Pruebas de caja blanca
Pruebas automatizadas.
27

28

1.6. Diseo del sistema

Los requisitos son la base para el diseo del sistema, el cual
es realizado utilizando diagramas de UML. Muchas de las
herramientas, tales como Rational Rose, Rational Software
Architect, Infosphere Data Architect y Rational Software
Modeler, pueden facilitar la creacin de todos los diagramas
necesarios.
Un mtodo es crear diagramas de interaccin de los
escenarios y, al mismo tiempo, asignar funcionalidad a las
clases.
La siguiente figura utiliza la pirmide de requisitos para
representar esta actividad.
29

30

Conclusiones
En RUP, una descripcin simplificada del proceso de
gestin de requisitos contiene los siguientes pasos:
establecimiento de un plan de GR, captura de
requisitos, desarrollo del documento Visin, creacin
de CU, especificacin suplementaria, creacin de CdP,
creacin de CdP de la especificacin suplementaria y
diseo del sistema.
Cada paso de la GR, a partir del segundo, navega a
travs de la pirmide de requisitos de arriba hacia
abajo y de izquierda a derecha.
Los requisitos son ms especficos en los niveles
31
inferiores de la pirmide.

Actividad Propuesta
Desarrolle el Caso que le indique su docente

32