Ingeniería de Requisitos

Ingeniera de Requisitos
Temario
Definiciones
Requisitos Funcionales y No Funcionales
Tipos de Requisitos
Proceso de los Requisitos
Obtencin de Requisitos - Tcnicas

Modelado del Sistema - Tcnicas
Especificacin de Requisitos - Documentos de Requisitos
Validacin Tcnicas
Administracin de los Requisitos

Administracin del cambio
Medicin
Metodologas de Desarrollo
Especificacin Formal - Z
Bibliografa
Pfleeger: Captulo 4
Ingeniera de SW - Sommerville (7ma. edicin): Captulos
6 Requisitos del software
7 Procesos de la Ing. de Requisitos
10 Especificacin formal
IEEE Recommended Practice for Software Requirements Specifications

Std 830-1998.
Casos de uso:
Larman: Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and the Unified Process (2nd Edition)
Artculos en la pgina:
Captulo 6 del libro de Craig Larman: Applaying UML and Patterns 2nd Edition
Captulo 19 del libro de Alistair Cockbourn: Writting Effective Use Cases
Is the clock an actor? Artculo de la revista Rational Edge
UML:
http://www.uml.org/
Artculos en la pgina:
Introduccin a UML - Artculo de la revista Rational Edge
Diagramas de Actividad - Artculo de la revista Rational Edge
Motivacin
Definiciones
Requisitos:
Descripcin de los servicios que debe brindar un
sistema y sus restricciones.
Proceso de descubrir, analizar, documentar y verificar
esos servicios y restricciones.
Definiciones
Sistema
Incluye hardware, software, firmware, personas,
informacin, tcnicas, servicios, y otros elementos de
soporte
Requisitos del Sistema

Son los requisitos para el sistema entero
Requisitos del Software

Se refieren solo al SW
6
Requisitos vs. Diseo

Requisitos definen el Qu (el problema) del
sistema
El Diseo define el Cmo (la solucin)
Reporte CHAOS de Standish Group `94

350 orgs., 8000 proyectos
(Standish Gr.1994)
Causas
Causas
%
Respuestas
Requisitos incompletos
13.10%
Falta de involucramiento de
usuarios
12.40%
Falta de Recursos
10.60%
Expectativas no realistas
9.90%
Falta de Soporte de Ejecutivos
9.30%
Requisitos y Especificaciones
cambiantes
8.70%
Falta de planificacin
8.10%
Sistema no se precisaba ms
7.50%
Costos de Errores en los Requisitos

Costo de corregir un error en los requisitos
(Boehm-Papaccio,1988)
Requisitos Funcionales y No Funcionales

Funcionales:
Servicios o funciones que proveer el sistema
Describen la interaccin entre el sistema y su entorno
Ejemplos:
Se deben ingresar cdula, nombre y telfono de cada cliente
Se quiere un listado de los clientes por zona
No-funcional:
Restricciones a los servicios o funciones ofrecidos por
el sistema
Describen restricciones que limitan las elecciones para
construir una solucin
Ejemplos:
Las consultas deben resolverse en menos de 3 segundos
El lenguaje de programacin debe ser Java
10
Requisitos No Funcionales
Del Producto: Especifican restricciones al
comportamiento del producto
Ejemplos: desempeo, confiabilidad, portabilidad, usabilidad
De la Organizacin: Se derivan de las polticas y

procedimientos existentes en la organizacin del cliente
y en la del desarrollador
Ejemplos: estndares, lenguajes de programacin, mtodo de
diseo
Externos: Se derivan de factores externos, como:

Interoperabilidad: con otros sistemas
Legislativos: privacidad, seguridad
ticos: dependen del contexto, las personas, etc
11
Requisitos - Tipos (1)

Al describir requisitos se deben tener en cuenta los
siguientes aspectos:
Ubicacin y Entorno Fsicos
dnde, uno o varios, restricciones ambientales
Interfaces
Entrada de 1 o + sistemas, Salida a 1 o + sistemas,
restricciones de formato, soporte
Usuarios y Factores Humanos

capacidad de cada tipo de usuario, tipo de entrenamiento,
facilidad de uso, posibilidad de mal uso
Funcionalidad y Restricciones asociadas

qu debe hacer, cundo, modos de operacin, cmo y cundo
se puede modificar el sistema, restricciones de velocidad,
tiempo de respuesta, capacidad de proceso
12

Documentacin
cunta, formato, para quin
Datos
formatos E/S, frecuencia, fuentes, destinos, calidad
requerida, precisin en clculos, flujo en el sistema
Recursos
materiales, personal y otros para construir, usar y
mantener el sistema, habilidades de los
desarrolladores, necesidades de espacio y
ambientales, calendario prescrito, limitaciones en
presupuesto
13

Seguridad
control de acceso a las funciones/datos, aislamiento de los
programas, respaldos-frecuencia, disponibilidad-, seguridad
fsica
Aseguramiento de la Calidad
Confiabilidad tiempo medio entre fallas, robustez, tolerancia a
fallas
Disponibilidad - tiempo para estar operativo luego de fallamantenimiento estando activo- tiempo mximo de no
disponibilidad
Mantenibilidad
Seguridad
Portabilidad
14
Obtencin
Obtencin
Anlisis
Anlisis
Especificacin
Especificacin
Verificacin
Verificacin
Validacin
Validacin
Lnea Base de
Requisitos
Planificacin
Planificacin
Lnea base corregida
Planificacin
Planificacin
Trazabilidad
Trazabilidad
Lnea base
actual
SCM
Cambios en
requisitos
Administracin
Administracin
del
del Cambio
Cambio
Cambios
16
en el proyecto
Proceso de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
17
Participantes en el Proceso de
Requisitos
Cliente y Usuarios
Requisitos adecuados a sus necesidades
Diseadores
Comprenderlos para lograr diseo que los satisfaga
Supervisores del Contrato, sugieren:

Hitos de Control, cronogramas
Gerentes del Negocio, entienden:

Impacto en la Organizacin
Verificadores
Comprenderlos para poder verificar si el sistema los
satisface
18
Obtencin de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
20
Requisitos - Fuentes
Necesidades del cliente, usuario, otros
interesados
Modelos del dominio
Revisar la situacin actual
Organizacin actual y sistemas
Versin actual del sistema
Desarrolladores de versin anterior
Documentos existentes (antecedentes)
Sistemas anlogos ya existentes (antecedentes)
21
Obtencin & Anlisis de Requisitos

Se trabaja en conjunto con los usuarios y
clientes
Problemas comunes:
No saben lo que quieren del sistema, slo en trminos
generales, no conocen el costo de sus peticiones
Los requisitos estn en sus trminos y con
conocimiento implcito de su propio trabajo
Distintos usuarios tienen distintos requisitos, se deben
encontrar todas las fuentes
Influyen factores polticos
La prioridad que se da a los requisitos vara con el
tiempo
Aparecen nuevos requisitos
22
Brecha en la Comunicacin (Scharer 90)

Segn desarrolladores, los usuarios...
Segn usuarios,
los desarrolladores...
no saben lo que quieren
no captan las necesidades operativas
no pueden articular lo que quieren
ponen excesivo nfasis en aspectos meramente

tcnicos
muchas necesidades por motivos polticos
pretenden indicarnos cmo hacer nuestro trabajo
quieren todo ya
no son capaces de traducir necesidades claramente

establecidas en un sistema
son incapaces de definir prioridades entre

sus necesidades
siempre dicen que no
rehsan asumir responsabilidades por el

sistema
siempre estn pasados del presupuesto
incapaces de dar un enunciado utilizable de

sus necesidades
siempre estn atrasados
no estn comprometidos con los proyectos

de desarrollo
nos exigen tiempo y esfuerzo an a costa de las

obligaciones esenciales
no aceptan soluciones de compromiso
establecen estndares no realistas para la definicin

de requisitos
no pueden mantener el cronograma
son incapaces de responder rpidamente a cambios

en las necesidades
23
Obtencin & Anlisis de Requisitos

(Modelo Genrico)
Clasificacin y
Organizacin
de Requisitos
Relevamiento
de Requisitos
Priorizacin y
negociacin de
requisitos
Documentacin
de Requisitos
24
Qu relevar
Requerimientos del negocio:
Objetivos del negocio de alto nivel. Responden a la pregunta:
cmo ser el mundo mejor para una determinada comunidad?
Categoras:
beneficios financieros
mejora de las operaciones de negocio
posicionamiento estratgico / competitivo
adoptar una nueva ley
nivelado / desarrollo tecnolgico.
product vision statement

beneficios para los stakeholders
descripcin de la funcionalidades en alto nivel
prioridades del proyecto
limitaciones del producto
Documento de visin. Sirve para establecer una visin

comn con el cliente y para difusin del proyecto.
25
Qu relevar
Reglas de negocio. - Existen independientemente del
software. Aplican aunque se haga manualmente.
polticas de la organizacin
estndares
algoritmos
leyes y regulaciones
Requisitos funcionales
Requisitos no funcionales:
atributos de Q
interfaces externas
restricciones
Criterios de xito. Pe.:

que puedan desarrollar bien tareas significativas
manejo de errores
que satisfaga expectativas de calidad
26
Obtencin de Requisitos
Tcnicas
Investigar antecedentes
Entrevistas individuales/grupales
Encuestas/Cuestionarios
Tormenta de ideas
Workshop
Casos de Uso
Observacin/Participacin
Prototipado
27
Investigar antecedentes
Estudio, muestreo, visitas,
Buena forma de comenzar un proyecto
Interna: estructura de la organizacin, polticas y
procedimientos, formularios e informes, documentacin
de sistemas
Externa: publicaciones de la industria y comercio,
Encuentros profesionales, visitas, literatura y
presentaciones de vendedores
Ventajas
Ahorra tiempo de otros
Prepara para otros
enfoques
Puede llevarse a cabo
fuera de la organizacin
Desventajas
Perspectiva limitada
Desactualizado
Demasiado genrico
28
Entrevista Individual / Grupal

Usar para:
Pasos para las Entrevistas
Entender el problema de negocio

Entender el ambiente de
operacin
Evitar omisin de requisitos
Mejorar las relaciones con el
cliente
Ventajas
Orientado a las personas
Interactivo/flexible
Rico
Desventajas
Costoso
Depende de las habilidades
interpersonales
Seleccionar participantes
Aprender tanto como sea
posible de antemano
Preparar la entrevista
Utilizar un patrn de
estructura
Conducirla
Apertura, desarrollo,
conclusin
Enviar un memo con

resultado
Seguimiento
29
Entrevista Patrn para conducirla

Datos de las Personas: usuarios, interesados, disparador del proyecto
Qu trabajo realizan? Para quin?
Qu interfiere con su trabajo?
Qu cosas hacen su trabajo mas fcil o mas difcil?
Datos: entradas y salidas clave, datos ya existentes

Listar las entradas y salidas
Cul es el problema? Cmo se resuelve ahora? Como le gustara que
se resolviera?
Procesos: propsito, objetivos y metas

Quin necesita la aplicacin?
Cuntos usuarios la van a usar y de qu tipo?
Ubicaciones: lugares involucrados, contexto de los usuarios

Entorno de los usuarios, computadoras, plataformas
Aplicaciones relevantes existentes
Experiencia de los usuarios con este tipo de aplicacin, expectativas de
tiempo de entrenamiento
30
Entrevista Patrn para conducirla (2)

Evaluar confiabilidad, desempeo y soporte necesario:
Cules son las expectativas respecto a la confiabilidad?

Y respecto a la performance?
Qu tipo de mantenimiento se espera?
Qu nivel de control y seguridad?
Qu requisitos de instalacin existen?, cmo se distribuye el software?
, debe ser empaquetado?
Otros
Existen requisitos legales, regulatorios u otros estndares que deban
ser tenidos en cuenta?
Factores crticos de xito:

Qu se considera una buena solucin?
Tener en cuenta:
Si el entrevistado comienza a hablar sobre los problemas existentes, no
cortarlo con una prxima pregunta
Luego de la entrevista y mientras los datos an estn en mente, resumir
los principales req. (aprox. 3) de este entrevistado
31
Encuesta / Cuestionario
No substituye la entrevista
Antes de usar el enfoque:
Determinar la informacin que se precisa
Determinar el enfoque ms adecuado:
Abierto, cerrado, combinado
Mltiple opcin, valor en escala, orden relativo
Desarrollar cuestionario
Probarlo con perfil tpico
Analizar resultado de las pruebas
Su principal uso es para validar asunciones y obtener

datos estadsticos sobre preferencias
Ventajas
Desventajas
Economa de escala
Conveniente para quien
contesta
Respuestas annimas
Menos rico
Problemas por norespuesta
Esfuerzo de desarrollo
32
Observacin / Participacin
Poco utilizado
Antes de usarlo
Determinar informacin necesaria

Comunicar a los involucrados
Considerar perodos normales y atpicos
Planificar las anotaciones
Ventajas
Confiable
Muy rico
Desarrolla empata
Desventajas
Efecto Hawthorne
Cuidado con generalizar
demasiado (sesgo
particular/local)
33
Tormenta de Ideas (Brainstorming)

Objetivo: Lograr consenso sobre los requisitos
Ayuda a la participacin de todos los
involucrados
Permite pensar en otras ideas
Un secretario saca notas de todo lo discutido
Reglas
No se permite criticar ni debatir

Dejar volar la imaginacin
Generar tantas ideas como sea posible
Mutar y combinar ideas
34
Tormenta de Ideas Fase de Generacin

Los principales stakeholders se juntan en un
cuarto.
Se explican las reglas.
Se establece el objetivo:
Qu caractersticas esperan en el producto?
Qu servicios esperan que provea?
Los objetivos permiten decidir cuando terminar.
Se pide que cada participante escriba sus ideas,

luego las ideas son ledas para que otros
piensen en ideas relacionadas y de esa forma
las ideas mutan y se combinan.
35
Tormenta de Ideas Fase de Reduccin

El secretario lee cada idea y pregunta si es vlida
Si hay cualquier desacuerdo, la idea se queda
Agrupamiento de ideas
Nombrar los grupos
Definicin
Se escribe una breve descripcin de lo que la idea significa para
la persona que la escribi
Ayuda a tener un entendimiento comn del requerimiento
Lleva unos minutos por idea
Priorizacin (opcional)
Test de los $100: Cada persona tiene dinero para comprar
ideas, se ordena segn ideas ms compradas
Solo se puede hacer una vez
Se debe limitar la cantidad a gastar en 1 sola idea
36
Sesiones de Trabajo (Workshop)

mbito para las tormentas de ideas
Preparacin
Venderlo a los posibles miembros de la reunin

Asegurarse que asisten los stakeholders correctos
Estructurar la invitacin, el lugar, etc.
Enviar material previo a la reunin
Doc de requisitos
Entrevistas, defectos de los sistemas existentes, etc.
Asegurarse de enviar lo necesario, sin exagerar
Organizar la Agenda
Introduccin
Tormenta de ideas generacin
Tormenta de ideas reduccin
Priorizacin
Resumen
37
Casos de Uso
Formato simple y estructurado donde los usuarios y
desarrolladores pueden trabajar juntos
No son de gran ayuda para identificar aspectos no
funcionales
Mientras se definen los casos de uso, puede ser un buen
momento para definir pantallas u otros objetos con los
que el usuario interacta
Pueden ser usados en el diseo y en el testing del
sistema
Usarlo
Cuando el sistema est
orientado a la
funcionalidad, con varios
tipos de usuarios
Cuando la
implementacin se va a
No son la mejor
eleccin:
Sistemas sin usuarios y

con pocas interfaces
Sistemas dominados
primariamente por
requisitos no funcionales38
Prototipado
Implementacin parcial, permite a los desarrolladores y
usuarios:
entender mejor los requisitos
cules son necesarios, deseables
acotar riesgos
Prototipo desechable: El propsito es solo establecer

que algo se puede hacer, luego se parte de cero en la
construccin, quedando el conocimiento aprendido
Prototipo evolutivo: Es implementado sobre la
arquitectura del producto final, el sistema final se obtiene
de evolucionar el prototipo
Aspectos para los que es frecuente construir prototipos:
Apariencia y percepcin de la interfaz de usuario
Arquitectura (riesgos tecnolgicos, tiempos de respuesta)
Otros aspectos riesgosos
39
Mismos datos, pero

Ingrese
ao:
____
mes:
____
da:
____
Julio 1998
1998
1
Ene
2025
31
Dic
Martes 16 Oct. 2002
40
Anlisis de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
42
Anlisis de Requisitos
Analizar stakeholders / clientes / usuarios

Crear vistas
Detallar
Negociar prioridades
Buscar reqs que faltan
Evaluar factibilidad tcnica - Prototipos
Evaluar riesgos de requerimientos En el Plan
43
Stakeholders / Clientes / Usuarios

Usuarios
Clientes
Stakeholders
Clientes:
Definir responsable de:
resolucin de conflictos
validacin
Planificar reuniones de
revisin de avance con el
responsable.
Definir proceso de resolucin
de conflictos pe. en alcance.
Usuarios:
dividirlos en clases
definir representantes
definir prototipos
acordar responsabilidades y
estrategias de colaboracin
con representantes
44
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
45
Modelos o Vistas del Sistema

Glosario
Modelos grficos:
Modelo conceptual
Diagramas de estado para entidades complejas que pasen por
distintos estados.
Diagramas de Flujo de Datos (DFD)
Prototipos de interfaz grfica. Definir docs del prototipo

(reqs, diseo, CP)
Casos de Prueba
Tablas de Decisin
Redes de Petri
Casos de Uso
46
Diagramas UML
UML
Diagramas de Casos de Uso

Diagramas de Actividad
Diagramas de Estado
Diagrama de Clases
Modelo Conceptual
47
Tablas de Decisin
Descripcin dinmica
Conjunto de condiciones posibles en un cierto instante
Estados donde se verifica una combinacin determinada
de las condiciones
Estados
Acciones a tomar
Condicion
es
Acciones
Importe > 1000
Buenos Antecedentes
Ya oper antes
Autorizar Crdito
Analizar antecedentes
X
X
Nro estados = 2^nro condiciones => tablas extensas

48
Redes de Petri
Descripcin dinmica
Permiten describir:
Concurrencia
Sincronizacin
Grafo dirigido con dos tipos de nodos:

Lugares
y Transiciones
Arcos slo pueden unir lugares con transiciones y
transiciones con lugares
49
Redes de Petri (2)

El estado inicial de una red de
L1 -Lugar con marca Petri se le llama marca, est
dado por los Tokens (marcas)
iniciales
Transicin
L2 -Lugar
Significado:
Transiciones: Modelan
eventos o acciones
Lugares con marca:
Cumplimiento de una
condicin
Transicin activada:
Ocurrencia del evento o
ejecucin de la accin
50
Redes de Petri (3)

Transicin habilitada:
Existe al menos un
token en cada uno de
sus lugares de entrada
L1
L2
Al activarse una transicin,

los tokens que activaron la
transicin desaparecen de
los lugares de entrada y se
generan tokens en los
lugares de salida de la
transicin
L1
L2
T1
L3
L4
L5
L3
L4
L5
51
Redes de Petri Algunas Primitivas

L1
L4
Secuencia
T3
T1
Conflicto
T4
T6
T5
L8
L9
L10
L2
L5
L6
L7
T2
L3
T7
T8
Concurrencia
T9
T10
L11
Sincronizacin
52
Redes de Petri
Ejemplo: Mquina Dispensadora

L2- pronta
T1-Inserta moneda
L1- Tiene moneda
T4-dispensa
T2- rechaza
moneda
T3- acepta
moneda
L3- pronto para
dispensar
Se dispararon las transiciones:

t1,t3,t4
Otra secuencia posible seria t1,t2
53
Diagrama de Flujo de Datos (DFD)

Descripcin dinmica
Proviene de Metodologa de Anlisis y Diseo Estructurado
Fin de la dcada del 70
Usados en versin original de OMT (Rumbaugh 91), no incorporados a UML
Antes de los Casos de Uso era una de las formas ms usadas para describir
un sistema
Archivo
Datos que entran
Elementos
Proceso
Datos que salen
Proceso del sistema que recibe datos y genera otros

Archivo de datos (almacenamiento)
Flujo de Datos
Entidad Externa al sistema a modelar (actor)
54
DFD - Ejemplo
Experiencia y
conocimiento
Mdico
Sntomas
Examen
Diagnstico
Medicacin
Lista de exmenes y
servicios brindados
Diagnstico
Contabilidad
Factura
Exmenes y
Historia Clnica servicios
Precios
Paciente
Registro Contable
55
DFD
Permite visualizar cmo fluye la informacin por el sistema
est asociado a una realizacin particular del sistema
El diagrama no es suficiente para precisar el comportamiento:
por un flujo que entra a un proceso desde un archivo,
fluye un
registro o todo el archivo?
No estipula sincronizacin, un flujo llega a una entidad externa y otro sale
Estn relacionados? Uno es respuesta del otro?
No permite definir procesos (bucles, condiciones, etc.)

Se complementa con un diccionario de datos que describe:
estructura de los flujos y otros detalles
los procesos (lenguaje natural estructurado) con lo que el
comportamiento queda determinado
Permite distintos niveles de abstraccin, anidando DFDs

A menudo sistemas legados estn documentados con DFD
56
Casos de Uso
Tcnica para entender y describir requisitos
Los casos de uso son requisitos, describen
requisitos funcionales
Pone el acento en el uso del producto
Describen como el sistema debe comportarse
desde el punto de vista del usuario
Casos de Uso como caja negra: Especifican que
es lo que el sistema debe hacer sin especificar
cmo debe hacerlo
Se describen mediante documentos de texto
Introducido por Ivar Jacobson (1992)
57
Actor
Entidad externa que interacta con el sistema
(persona identificada por un rol o sistema externo)
Actor principal: Sus objetivos son cumplidos al realizar
el caso de uso
Los actores son externos al sistema que vamos a
desarrollar.
Al identificar actores estamos delimitando el sistema
Usuario: persona que cuando usa el sistema, asume
un rol.
<<actor>>
Sistema
Actor
58
Cajero Automtico - Ejemplo
Cliente
Retirar
Servicio de
Cajeros
Actor principal: Cliente

Actores: Servicio de Cajeros
Caso de Uso: Retirar
Descripcin: Un cliente de un banco retira dinero de
una cuenta a travs del cajero automtico utilizando una
tarjeta bancaria, el Servicio de Cajeros verifica que el
PIN sea vlido y que el monto de la cuenta sea
suficiente para realizar el retiro
59
Caso de Uso
Caso de Uso
Escenario:
Secuencia de acciones e interacciones entre los
actores y el sistema, dando un resultado de valor
observable para un actor particular
Tambin se conoce como instancia de caso de uso
Es una forma particular de usar el sistema, un camino
a travs de un caso de uso.
Caso de uso: conjunto de escenarios posibles

que puede encarar un actor (o varios) con el
sistema para el logro de cierto objetivo.
Un resultado observable de valor se basa en
entregar sistemas que hagan lo que las personas
realmente necesitan.
60

Flujo principal:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Cliente inserta una tarjeta bancaria en el lector del CA.

El CA lee el cdigo de la tarjeta y verifica que es correcto
El CA pide el cdigo de PIN de 4 dgitos
EL Cliente ingresa el PIN
El CA enva cdigo de Tarjeta y PIN al SC
El SC verifica que el PIN sea correcto y contesta: OK
El CA despliega las distintas alternativas disponibles: retiro, depsito,
consulta
El Cliente elige Retiro
El CA pide cuenta y monto
El Cliente los ingresa
CA enva cdigo de Tarjeta, PIN, cuenta y monto al SC
El SC contesta: OK
El CA dispensa el dinero
El CA devuelve la tarjeta
El CA imprime el recibo
61
Caso de Uso : Retirar

Flujo principal: (otra forma)
Cliente
Sistema
Servicio de Cajeros
1. Inserta una tarjeta bancaria en el

lector del CA.
2. Lee el cdigo de la tarjeta y verifica
que es correcto
3 Pide el cdigo de PIN de 4 dgitos
4 Ingresa el PIN
5 Enva Id. De tarjeta y PIN
6 Verifica que el PIN sea correcto
7- Despliega las distintas alternativas
disponibles
8- Elige la opcin: Retiro
9. Pide cuenta y monto
10- Ingresa cuenta y monto
11. Enva al SC el Id. Tarjeta, PIN,
cuenta y monto
12 Contesta: Continuar (OK)
13 Dispensa el dinero
14 Devuelve la tarjeta
15 Imprime recibo
62
Casos de Uso
Forma de encontrarlos: Mirar cada uno de los actores
del sistema y preguntarse que es lo que buscan
cuando usan el sistema.
Recomendacin: Identificarlos con un verbo.
Cada caso de uso modela partes de la dinmica.
Diagrama de Casos de Uso descripcin esttica.
Los casos de uso son independientes del mtodo de
diseo que se utilice, y por lo tanto del mtodo de
programacin, no son parte del anlisis OO, pero son
una excelente entrada para ello.
Los casos de uso pueden dirigir el proceso de
desarrollo. Guan el diseo, la implementacin y la
prueba del sistema.
63
Casos de Uso - Conceptos

Precondiciones: Establece que cosas deben ser
siempre verdaderas antes de comenzar un caso de uso.
No se verifican dentro del caso de uso ya que se asume
que son verdaderas dentro de l.
Poscondiciones: Establece que cosas ocurren al
completar el caso de uso.
Flujo principal: Describe el escenario del caso de uso
de mayor inters para el actor. Tpicamente no incluye
condiciones ni bifurcaciones.
Flujos alternativos: Son todos los otros escenarios; son
bifurcaciones en el flujo principal.
Requisitos Especiales: Son los requisitos no
funcionales, atributos de calidad o restricciones
especficas relacionadas con el caso de uso.
64

Flujos Alternativos :
2A. La tarjeta no es vlida
1. El CA devuelve la tarjeta con el mensaje tarjeta no vlida
2. Fin CU
6A. PIN invlido y menos de 3 intentos
El Cliente puede realizar tres intentos para ingresar el PIN vlido. Sino, el
CA retiene la tarjeta.
1. El SC contesta indicando PIN invlido
2. El CA muestra el mensaje PIN incorrecto y sigue en punto 3
6B. PIN invlido y 3 intentos
El CA debe retener la tarjeta
2. El CA muestra el mensaje Se le retiene la tarjeta
3. Fin CU
9A. El CA no tiene dinero
1.La opcin Retiro en esta situacin no es una alternativa posible, y
el CA despliega la advertencia: Sin dinero.
2. Fin CU
65

Flujos Alternativos (cont.):
11A. Monto insuficiente para el cajero
El monto indicado por el cliente no puede obtenerse a partir de los billetes de que dispone
el CA
1 El CA despliega el mensaje No se cuenta con ese monto en este cajero
2 Vuelve a 9.
12A. No hay suficiente saldo en la cuenta.
1. CA despliega mensaje Su saldo no permite extraer ese monto
2. El CA devuelve la tarjeta
3. Fin CU
12B. No hay contacto con el Servicio de Cajeros (SC)
1. CA despliega el mensaje sin conexin a la red de cajeros
2 . El CA devuelve la tarjeta
3. Fin CU
12C. Enlace con el computador central se cae durante la transaccin
Hay que asegurar que el SC considera slo los retiros efectivamente realizados
14A. El dinero no es retirado de la bandeja.
1. Si despus de YY segundos el dinero est todava en la bandeja, el CA lo recupera y
lo deja en el depsito de dinero usado
1. Sigue en 14
14B. La tarjeta se tranca al intentar devolverla.
1. CA trata de devolverla durante xx segundos.
2. Si en ese tiempo no puede devolverla, CA avisa a mantenimiento
3. Fin CU
66
Diagrama de Casos de Uso

UML provee notacin para los casos de uso para ilustrar
los actores, los casos de uso y las relaciones entre ellos
Permite realizar un Diagrama del Contexto del Sistema
Muestra los bordes del sistema
Retirar
Cliente
Depositar
Transferir
Servicio de Cajeros
67
Construccin del Modelo - Pasos

Definir frontera
Identificar Actores
Para cada Actor, identificar qu cosas quiere hacer
cada uno va a determinar un caso de uso
darle un nombre
Dado un caso de uso

Identificar si participan otros actores
Describirlo brevemente de forma narrativa, centrndose en el
flujo principal (distintas variantes de presentacin y contenido)
Una vez definido el conjunto de casos de uso relevante:

Refinarlos incluyendo condiciones especiales
Identificar casos de uso comunes y particulares (incluye y
extiende), generalizacin
68
Relaciones entre CU Include
Escenarios comunes a ms de un caso de uso

El caso de uso includo no depende del caso de uso base
Cuando una instancia del caso de uso llega al lugar donde el
comportamiento de otro caso de uso debe ser incluido, ejecuta todo
el comportamiento descrito por el caso de uso includo y luego
contina de acuerdo a su caso de uso original.
El caso de uso incluido representa comportamiento encapsulado
que puede ser reusado en varios casos de uso
Desconoce la
En el caso del cajero:
existencia de los
que lo usan
Identificar Cliente
<<include>>
<<include>>
<<include>>
Retirar
Transferir
Depositar
69

Flujo principal:
1.
2.
Incluye el caso de uso: Identificar Cliente

El CA despliega las distintas alternativas disponibles:
retiro, depsito, consulta
3. El Cliente elige Retiro
4. El CA pide cuenta y monto
5. El Cliente los ingresa
6. CA enva cdigo de Tarjeta, PIN, cuenta y monto al SC
7. El SC contesta: OK
8. El CA dispensa el dinero
9. El CA devuelve la tarjeta
10. El CA imprime el recibo
70
Caso de Uso: Identificar Cliente

Descripcin Breve:
Verifica que la tarjeta y el PIN sean vlidos
Flujo Principal:
1.
2.
3.
4.
5.
6.
Cliente inserta una tarjeta bancaria en el lector del CA.

El CA lee el cdigo de la tarjeta y verifica que es correcto
El CA pide el cdigo de PIN de 4 dgitos
EL Cliente ingresa el PIN
El CA enva cdigo de Tarjeta y PIN al SC
El SC verifica que el PIN sea correcto y contesta: OK
Flujos Alternativos:
2A. La tarjeta no es vlida
1. El CA devuelve la tarjeta con el mensaje tarjeta no vlida
2. Fin CU
6A. PIN invlido y menos de 3 intentos
El Cliente puede realizar tres intentos para ingresar el PIN vlido. Sino, el CA retiene la tarjeta.
2. El CA muestra el mensaje PIN incorrecto
3. Sigue en punto 3
6B. PIN invlido y 3 intentos
El CA debe retener la tarjeta
2. El CA muestra el mensaje Se le retiene la tarjeta
3. Fin CU
71
Relaciones entre CU Extend

Es un fragmento de un caso de uso, que agrega
comportamiento a otro caso de uso.
Se usan para explicar escenarios que sera complejo
presentar como flujo alternativo, o que se desea destacar.
Representan una parte de la funcionalidad del caso que no
siempre ocurre (condicional).
Se ejecuta solo si la condicin se cumple.
El caso de uso extendido referencia a su caso de uso base.
Punto de extensin: Punto dentro del caso de uso, donde se
puede insertar comportamiento adicional.
Al terminar el caso de uso extendido, se vuelve al caso de
uso base, en la sentencia siguiente al punto de extensin.
72
Extend - Ejemplo
El cliente puede querer retirar monedas adems
de billetes
<<include>>
Identificar Cliente
Retirar
<<extend>>
Retirar Monedas
73

Flujo principal:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Incluye el caso de uso: Identificar Cliente

El CA despliega las distintas alternativas disponibles: retiro, depsito,
consulta
El Cliente elige Retiro
El CA pide cuenta y monto
El Cliente los ingresa
CA enva cdigo de Tarjeta, PIN, cuenta y monto al SC
El SC contesta: OK
El Cliente pide dispensar el dinero
El CA dispensa el dinero
El CA devuelve la tarjeta
El CA imprime el recibo
Puntos de Extensin:
Retiro de Monedas: En el punto 8 del flujo principal
74
Caso de Uso: Retirar Monedas

Descripcin Breve: El cliente opcionalmente
Punto de extensin
puede querer retirar monedas
indicado por un
nombre
Flujo Principal:
Extensin de Retirar en el punto Retirar Monedas, el
cliente tambin puede elegir monedas, en ese caso:
1. El Cliente elige retirar monedas, especificando tipos de monedas y
la cantidad de rollos para cada uno.
2. El CA calcula el importe a retirar para cada moneda y el total y lo
muestra
3. El Cliente confirma
Flujos Alternativos:
3A El cliente puede querer cambiar la seleccin, se vuelve a 1
G1 El cliente cancela el retiro de monedas. Fin CU Retirar Monedas
75
Relaciones entre CU Generalizacin

Algunas veces existe ms de un escenario principal para un
caso de uso
Se puede crear un caso de uso abstracto, crear un caso de
uso para cada escenario principal y que estos hereden del
caso abstracto
El caso de uso hijo hereda los escenarios, puntos de
extensin y relaciones definidos en el caso de uso padre
El caso de uso hijo puede definir nuevas operaciones, como
tambin redefinir o enriquecer con nuevas secuencias de
acciones operaciones ya existentes en el caso de uso padre
Validar Cliente
Validar con PIN
Validar con Scaner de Retina
76
Actividades
Encontrar actores y casos de uso

Priorizar los casos de uso
Detallar un caso de uso
Estructurar el modelo de casos de uso
77
Casos de Uso - Nivel de detalle

A qu nivel se deben expresar los CU en el
anlisis de requerimientos?
Enfocarse en CU al nivel de Proceso de Negocio
Elemental (elementary business process
(EBP)):
Una tarea ejecutada por una persona en un lugar en un
determinado momento, en respuesta a un evento del
negocio, que agrega valor de negocio mesurable y deja
los datos en estado consistente.
Que cumpla un objetivo del usuario.

Error comn: definir muchos CU a nivel
demasiado bajo: por cada paso o subtarea dentro
de un EBP.
Excepciones: Pe. casos de uso incluidos
78
UML
Unified Modeling Language
Objetivo: Proveer un lenguaje comn que puede ser
usado para el desarrollo de software
Lenguaje que permite:
Visualizar: La comunicacin es a travs de grficos
Especificar: construyendo modelos para el anlisis, diseo,
implementacin
Construir: Permite la generacin de cdigo a partir de un modelo
UML, y la construccin de un modelo a partir del cdigo
(ingeniera reversa)
Documentar: Permite la documentacin completa de todo el
sistema
Aprobado como estndar por la OMG en 1997

Actualmente se encuentra en la versin 2.1.2 (nov 2007)
79
Diagramas en UML
80
Tipos de Diagramas
Modelo Esttico
Construye y documenta los aspectos estticos de un sistema.
Refleja la estructura bsica y estable de un sistema software.
Crea una representacin de los principales elementos del dominio
del problema
Modelo Dinmico
Crea los diagramas que muestran el comportamiento de un
sistema
Para requisitos se utilizan los siguientes diagramas:

Diagrama de Clases (Modelo Conceptual)
Diagrama de Actividad
Diagramas de Estados
81

Permite visualizar en una forma compacta los casos de
uso del sistema y que actores participan en cada caso
de uso
Presenta las relaciones que existen entre los casos de
uso
Muestra los lmites del sistema
Visin esttica de los Casos de Uso de un sistema
Consta de los siguientes elementos:
Actor
Caso de Uso
Relaciones
Include
Extend
Generalizacin
82
Diagrama de Casos de Uso - Ejemplo
<<extend>>
Retirar Monedas
<<include>>
Retirar
Cliente
Validar con PIN

<<include>>
Validar Cliente
Depositar
<<include>>
Validar con Scaner de Retina
Transferir
83
Diagrama de Clases
Nombre Clase
Atributos
Operaciones
Muestra las clases e interfaces que componen el

sistema y las relaciones que existen entre ellas
Muestra aspectos estticos
Clase: conjunto de objetos que comparten:
Atributos
Operaciones
Relaciones
Semntica
Modelo de Dominio (Conceptual): ayudan a entender los

conceptos del dominio del problema y el vocabulario del mismo. Se
excluyen detalles referentes a la implementacin o al lenguaje de
programacin.
Diagramas de clases de implementacin: muestran todos los
mtodos y atributos necesarios para implementar cada clase. Es un
diagrama dependiente de la implementacin y del lenguaje.
84
Modelo del Dominio (Conceptual)

Permite describir las entidades que conforman el
dominio, sus relaciones y atributos
Se representan los conceptos del dominio
Muestra aspectos estticos
Cliente.
nombre
usa
0..1
0..n
Tarjeta
Nmero
PIN
Banco
Nombre
expide
n
tiene
0..1
0..n
1
n
Cuenta
saldo
Retiro.
Cajero.
saldo
1
realiza
n
Transaccin
monto
Depsito.
Transferencia.
85
Diagrama de Actividad
Se construye para modelar el flujo del control (workflow)
Elementos:
Estado de Actividad (o de Accin)
Estado Inicial
Estado Final
Transiciones
Actividades concurrentes
Bifurcaciones
Condiciones de la bifurcacin
[ guarda ]
Andariveles
Permite modelar el flujo del trabajo

En un sistema
En una organizacin
86
Diagrama de Actividad - Ejemplo

Guarda de
decisin
Se abren
Flujos
Paralelos
Sincronizaci
n
87
Diagrama de Estados
Muestra el comportamiento de un objeto representando
los estados en que se puede encontrar y los eventos
que le hace pasar de uno a otro.
Se utiliza para:
Modelar el estado interno de una entidad
Modelar el estado de un caso de uso
Da una vista dinmica del sistema

Permite:
Anidamiento: un estado con subestados
Estados paralelos: reduce el nro. de estados necesarios en el
modelo
Condiciones de bifurcacin
88
Diagrama de Estados Ejemplo 1

ingreso PIN [PIN incorrecto]
Esperar
Tarjeta
ingreso tarjeta
Pedir PIN
ingresar PIN[ PIN correcto ]
Seleccionar
cuenta y monto
ingreso cuenta y monto
Verificar
fondos
fondos insuficientes
Devolver
Tarjeta
retiro de tarjeta
contesta[ fondos suficientes ]

efectivo retirado
Dar Dinero
Contar
dinero suficiente
Dispensar
89
Diagrama de Estados Ejemplo 2
90
Eleccin de una Tcnica para

Modelar Requisitos
No existe un nico enfoque aplicable a todos los
sistemas, depende de cada proyecto
Puede ser necesario combinar varios enfoques
91
Especificacin de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
93
Lenguajes de Notacin
Lenguaje Natural
Comprensible para el Cliente/Usuario

Ambiguo (glosario)
Poca legibilidad (plantilla, formateo del texto)
Difcil de tratar (Verificar correctitud, consistencia,
completitud)
Notaciones Especiales (ms formales)
Poca o ninguna ambigedad

Facilita tratamiento
Necesidad de entrenamiento en la notacin
Dificultades de comprensin por Cliente/Usuario
94
Notaciones Especiales
Grficas vs. Basadas en texto
Estticas vs. Dinmicas
Descripciones Estticas
Se especifican entidades y sus atributos, los requisitos se
pueden ver como las relaciones entre las entidades.
No describe como cambian las relaciones con el tiempo
Descripciones Dinmicas
Especifican estados y las transiciones entre estados en el
tiempo
95
Documentacin de requisitos
Qu documentar:
lo que hace el sistema actual
lo que el cliente pide
lo que el sistema va a hacer
criterios de aceptacin
criterios de verificacin
Recomendaciones:
agrupar por temas
formular los reqs como reqs positivos y no negativos
expresarlos en voz activa y no pasiva
indicar si se est documentando solo lo que va en el alcance o todo lo
que se pidi.
representar reqs. con mltiples vistas (ejemplo de los ciegos y el
elefante).
96
Documentos de Requisitos
Definicin de Requisitos: lista completa de lo que el

cliente espera que el sistema haga, escrita de forma que
el cliente la pueda entender
1. Se debe proveer un medio para acceder a archivos externos
creados por otras herramientas
Especificacin de Requisitos (SRS): reformula la

definicin en trminos tcnicos para que los diseadores
puedan comenzar el diseo
1.1 Se proveer al usuario los recursos para definir el tipo de archivo
externo
1.2 Cada tipo de archivo tendr una herramienta asociada y un
cono que lo identifica
1.3 Cuando el usuario seleccione el cono que representa un archivo
externo, el efecto es aplicar la herramienta asociada con ese tipo
de archivo al archivo seleccionado
97
Documentos de Requisitos (2)

Usar un mismo documento: Entendimiento comn entre
Cliente, usuario, analistas, desarrolladores
Usar dos documentos: Se debe aplicar Gestin de
Configuracin: necesaria para asegurar la
correspondencia entre ambos (si existen por separado)
Permite seguir la pista y correspondencia entre:
Definicin de Requisitos
Especificacin de Requisitos
Mdulos de Diseo
Cdigo que implementa los mdulos
Pruebas para verificar la funcionalidad
Documentos que describen el sistema
98
Documento Definicin de Requisitos

Registrar los requisitos en los trminos del
cliente
1. Delinear el propsito general del sistema: Incluir
referencias a otros sistemas, glosario y abreviaciones
2. Describir el contexto y objetivos del desarrollo del
sistema
3. Delinear visin global del sistema: Incluir
restricciones generales
4. Definir en detalle las caractersticas del sistema
propuesto, definir la frontera del sistema e interfaces.
5. Discutir el ambiente en el que el sistema va a
operar (hardware, comunicaciones, personal).
99
Caractersticas de una Buena

Especificacin SRS (IEEE 830)
Correcta / Vlida: Todos los req. son requeridos en el sistema.
No existe herramienta que asegure esto.
Validado por el cliente (que efectivamente refleje sus necesidades).
Revisar que sea consistente contra otros documentos existentes (pe.
especificacin de reqs. del sistema).
No Ambigua: Todo req tiene una nica interpretacin.

Incluir glosario.
No ambigua para quienes lo crearon y para quienes lo usan.
Completa: Incluye:
Todos los requisitos asociados con funcionalidad, desempeo,
restricciones de diseo, atributos o interfaces externas.
Definicin de respuestas del sw a todo posible datos de entrada
(vlidos o invlidos) en toda clase de situaciones realizables.
No hay referencias sin definir en la especificacin.
La frase a determinar indica SRS no completa. Ocasionalmente
necesaria; describir:
condiciones que causan que no se sepa an.
qu se debe hacer para determinar lo que falta, quin y cundo.
100

Consistente internamente: Los requisitos no son
contradictorios entre s. Probables conflictos:
entre caractersticas de entidades. Pe. color de las luces, formatos
distintos
conflicto lgico o temporal entre dos acciones. Pe. multiplicar o
sumar; en forma simultnea o consecutiva.
diferentes trminos para describir el mismo objeto.
Ordenados por grado de importancia y/o estabilidad

identificador.
Importancia: esencial / deseado
Estabilidad: cantidad de cambios esperados
Necesidad: esencial / condicional / opcional
Esencial (condiciona aceptacin del sw)
Condicional (valor agregado)
Opcional (puede o no valer la pena; se aceptan propuestas alternativas).
101

Verificable: Un requerimiento es verificable si existe un
proceso finito de costo accesible para determinar que el
sistema lo cumple
Usar trminos concretos y cantidades mesurables.
Preparar pruebas para demostrar que se cumplen. Si no se puede,
eliminar o revisar el requisto.
Modificables: Su estructura y estilo son tales que cualquier

cambio en los requisitos puede ser hecho fcilmente en
forma completa y consistente.
Organizacin coherente y fcil de usar (tablas, ndices, refs.
cruzadas
No redundante.
Ventajas de redundancia: lo hace ms legible.
Desventajas: difcil de mantener
Si la uso: referencias cruzadas
Expresar cada req. separadamente.
102

Trazables: El origen de cada requerimiento es
claro, y es posible seguirle la pista en futuros
desarrollos o mejora de la documentacin
Trazabilidad hacia atrs: en versiones previas
Trazabilidad hacia adelante: documentos posteriores:
requiere IDENTIFICADOR NICO.
Realistas / Factibles
Ej.: tiempo de respuesta local=remoto
Ej.: El cliente quiere adelantarse a la tecnologa
Entendibles: Tanto por los usuarios como por los

desarrolladores
103
Verificacin de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
105
Verificacin de Requisitos
Se verifica en el documento de requisitos:
Consistencia: que no haya contradicciones
Completitud: que no falte nada. Chequear por:
Omisiones. Hacer rboles de decisin para ver que estn todas las
opciones detalladas.
Lmites. Ms claro con tabla, ah se ve que no falta ninguno.
Necesidad
Ambigedades
Realismo o Factibilidad: que se puedan implementar con la
tecnologa, presupuesto y calendario existentes.
Verificabilidad: que se pueda disear conjunto de pruebas para
demostrar que el sistema cumple esos requisitos. Cuidado con
adjetivos y adverbios.
Comprensibilidad: que los usuarios finales lo entiendan
Adaptabilidad: que el requisito se pueda cambiar sin afectar a
otros.
Trazabilidad: que est establecido el origen. Incluye verificar
trazabilidad entre la especific. y el doc. de requisitos.
106
Verificacin de Requisitos NO Funcionales

Son difciles de verificar
Se deben expresar de manera cuantitativa utilizando
mtricas que se puedan probar de forma objetiva (esto es
IDEAL)
Propiedad
Medida
Rapidez
Transacciones por seg
Tamao
KB
Fiabilidad
Tiempo promedio entre fallas
Portabilidad
Nmero de sistemas, especificar
Facilidad de uso
Tiempo de capacitacin
Para los usuarios es difcil especificarlos en forma

cuantitativa
107
Verificacin de requisitos
Definir quines, cmo, cundo.
Cmo:
revisiones formales (en grupo)
revisiones por pares
listas de comprobacin
108
Validacin de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
110
Proceso por el cual se determina si la
especificacin es consistente con las
necesidades del cliente
Se verifica en el documento de requisitos:
Validez: que el usuario valide qu es lo que
quiere
Planificar quin (qu stakeholder) va a validar qu
artefacto cmo (tcnica).
Ejecutar
Registrar Reporte de validacin / Firma
111
Tcnicas de Validacin:
Manuales
Lectura, Referencias cruzadas Manuales

Instancias de validacin formal: Entrevistas, Revisiones.
Listas de Comprobacin
Modelos Manuales para verificar funciones y relaciones
Escenarios
Generacin de Casos de Prueba
Pruebas Matemticas: Si se us un lenguaje formal, por ejemplo Z
Automatizadas
Referencias cruzadas automticas: Si los requisitos se expresan
formalmente, las herramientas CASE verifican su consistencia
Ejecucin de Modelos
Construccin de Prototipos
112
Revisin de Requisitos
Proceso manual. Se revisa el documento de requisitos buscando
anomalas y omisiones:
Revisiones informales: discusin informal
Revisiones formales: se hace una recorrida del doc de req con el cliente,
explicando implicancias de cada requisito.
Participan representantes:
del cliente: operadores, quienes realicen entradas, utilicen salidas, y sus
gerentes
del equipo de desarrollo: analistas de requisitos, diseadores, encargados
de pruebas y gestin de configuracin
Incluye:
revisar objetivos del sistema

evaluar alineamiento de requisitos con los objetivos (necesidad)
revisar el ambiente de operacin y las interfaces con otros sistemas
Cmo asegurar que la
funciones completas, restricciones realistas
reunin es efectiva?
evaluar riesgos
Moderador, secretario y
considerar:
responsables por acciones
pruebas del sistema
cambios en los requisitos en el proyecto, su verificacin y validacin
113
Obtencin
Obtencin
Anlisis
Anlisis
Especificacin
Especificacin
Verificacin
Verificacin
Validacin
Validacin
Lnea Base de
Requisitos
Planificacin
Planificacin
Lnea base corregida
Planificacin
Planificacin
Trazabilidad
Trazabilidad
Lnea base
actual
SCM
Cambios en
requisitos
Administracin
Administracin
del
del Cambio
Cambio
Cambios
114
en el proyecto

Los requisitos cambian, debido a:
Muchos usuarios
Quienes pagan por el sistema y los usuarios no son las mismas
personas
Cambios en el negocio
Cambios en la tecnologa
Proceso de comprender y controlar los cambios en los

requisitos del sistema
Se hace en paralelo con el Proceso de Requisitos.
Tres etapas:
Planificacin: Se realiza al comenzar el anlisis de requisitos
Administracin del cambio: Comienza una vez que se tiene una
primera versin del documento de requisitos
Trazabilidad: Se mantiene a lo largo del proceso de requisitos
115
Planificacin
Muchas actividades son tomadas de las tcnicas de SCM
Se debe decidir sobre:
Identificacin de Requisitos: Cada requisito debe identificarse en
forma nica, para poder ser referenciado por otros.
Ejemplo:
<Tipo> < nro> donde Tipo: F Funcional, D- Datos, etc.
Ejemplo: F12
Proceso de Administracin del Cambio: Actividades que evalan

el impacto y costo del cambio
Polticas de Trazabilidad: Definen qu relaciones entre reqs. y
con el diseo se deben registrar y cmo se van a mantener.
Herramientas CASE: De soporte para:
Almacenar los requisitos
Administrar el cambio
Administrar de la trazabilidad
116
Trazabilidad
Informacin de rastreo que se debe mantener
La fuente: Quin propuso el requerimiento y porqu
Requisitos dependientes: Vincula los requisitos
dependientes entre s, se usa para el anlisis del
cambio
Trazabilidad entre artefactos distintos, qu versin
se corresponde con cul. Pe.:
Rastreo reqs - CU
Rastreo al diseo: Vincula el req con los mdulos de diseo
que lo implementan
Uso de matrices de trazabilidad

117
Administracin del Cambio
El cambio va a ocurrir.
Objetivos del control de cambios:
Manejar el cambio y asegurar que el proyecto

incorpora los cambios correctos por las razones
correctas.
Anticipar y acomodar los cambios para producir la
mnima disrupcin y costo.
Si los reqs cambian mucho dp de LB
relevamiento incompleto/inefectivo
o acuerdo prematuro
118
Administracin del Cambio
Cuando se propone un cambio, debe evaluarse el

impacto.
Etapas:
1. Especificacin del cambio
2. Evaluar impacto - Anlisis del cambio y costo:
Se usa la informacin del rastreo

Se calcula el costo en trminos de modificaciones a:
Docs de requisitos
Diseo e implementacin
3. Discutir costo con cliente.

4. Implementar el cambio: se modifican los artefactos necesario
Siguiendo estos pasos se logra
Todos los cambios se tratan en forma consistente

Los cambios a los docs de requisitos se hacen en forma
controlada
119
Procedimiento de control de cambios

Establecer procedimiento de control de
cambios:
quin - Comit de Control de Cambios (CCC)
documentar:
integracin del CCC

alcance de autoridad
procedimientos operativos (pe. evaluar impacto)
proceso de toma de decisiones
120
Gestin de la Configuracin de los Requisitos

Tiene que haber un responsable
Control de versiones: Definir:
tems de configuracin
Procedimientos
Lnea Base. Definicin:

Conjunto de especificaciones y /o productos que han
sido revisados formalmente y acordados, que sirven
de base para desarrollo futuro, y que solo pueden ser
cambiados a travs de procedimientos formales de
control de cambios.
121
Lnea Base de Requisitos

LB de reqs, arranca cuando se decide que son
suficientemente buenos como para arrancar
diseo y construccin.
Sobre LB planifico cronograma y costo.
Asociada a la liberacin de un producto. Debo
poder recomponer la liberacin.
Definir:
qu artefactos van en Lnea Base
cundo entran
122
Medir y Evaluar Requisitos

Medir caractersticas de los requisitos para
obtener detalles
Calidad de los Requisitos
Las mediciones van a estar relacionadas con:

Producto (de los requisitos)
tamao, calidad, atributos tcnicos, ....
Proceso
actividades,...
Recursos
personas, equipos, tiempo, dinero,...
123
Medir y Evaluar Requisitos

Medir
# Requisitos
Entrada para estimacin del producto
# Cambios introducidos
Requisitos Agregados, Modificados, Desechados en el tiempo
Estabilidad
# Requisitos por tipo de requisitos

Permite luego ver en qu parte se encuentra el cambio
# Requisitos validados
Tamao del producto y del proyecto (ej.:PF, LoC)

planificar
124
Los mtodos giles fueron desarrollados en
respuesta a la necesidad de tener una
alternativa a los procesos de desarrollo de
software pesados, guiados por documentos
(AgileAlliance 2002)
Cada metodologa trata distinto los requisitos
Ejemplo de metodologa gil: eXtreme
Programming (XP)
Ejemplo de metodologa pesada: Rational
Unified Process
126
eXtreme Programming
Cliente en el lugar
Un cliente real debe sentarse en el lugar, disponible para escribir
historias, contestar preguntas, resolver disputas y prioridades de
pequea escala.
Historias de usuario
Su propsito es anlogo al de los casos de uso
Son escritas por el cliente, son las cosas que el sistema debe hacer
No son casos de uso, pero describen escenarios
Su formato son tres sentencias de texto escritas por el cliente, en su
terminologa sin sintaxis tcnica.
Cuando llega el momento de implementarla, los dasarrolladores van
con el cliente y reciben una descripcin detallada de los requisitos,
cara a cara
Se usan para planificar el proyecto: se estiman y el cliente las
prioriza definiendo el alcance
127
Rational Unified Process

Disciplina de Requisitos
128
RUP Detalle de Actividades
129
Especificacin Formal
Ventajas:
Permite detectar omisiones e inconsistencias en los
requisitos
Deteccin temprana de defectos
Necesario para demostrar que un programa es
correcto
Desventajas:
Exige entrenamiento
En general no es comprensible para el cliente
Funcionan bien en escalas reducidas, pero se
complican a medida que crece la escala del producto
Su aplicacin suele estar restringida a sistemas

crticos
130
Sistema crtico, un ejemplo

Bomba personal de insulina que intenta emular
el comportamiento del pncreas (alternativa
frente a inyecciones de insulina)
Un sensor mide el nivel de azcar en la sangre
Requisitos relativos a la criticidad
Disponibilidad el sistema debe funcionar cuando el
paciente necesite insulina
Confiabilidad debe proveer insulina en momento y
cantidad adecuada
Seguridad (safety) una dosis excesiva podra poner
en riesgo la vida del paciente
131
Bomba de Insulina - Componentes

Conectado a la
bomba, inyecta
insulina en el
cuerpo
Bombea insulina
del depsito a la
aguja
Depsito
aguj
a
Sensor
Mide nivel
de azcar
en la sangre
Controla todo
el sistema
bomba
Controlador
reloj
Alarma
Suena en caso
de problemas
Pantalla
Fuente de Energa
Muestra la ultima
lectura de azcar
y mensajes de
estado
132
Concepto de Operacin
A partir de la lectura del sensor, el sistema evala el nivel
de glucosa en sangre del paciente
El sistema compara lecturas consecutivas para detectar
una posible tendencia al crecimiento del nivel. En este caso
inyecta insulina para actuar en contra de esa tendencia
La situacin ideal es que el nivel de azcar se encuentre
sistemticamente en la banda de seguridad
Niveles de azcar en sangre:
Inseguro menos de 3 unidades (posible coma)
Seguro- entre 3 y 7 unidades
No deseable (ms de 7 unidades)
Nota: los valores mencionados slo son a ttulo ilustrativo
133
Inyeccin de Insulina
Segn nivel de azcar, tendencia e inyecciones anteriores
Escenarios relativos al nivel de azcar en sangre:
en la banda insegura
No inyectar
Alarma para el paciente
en las otras dos bandas

cayendo
En banda segura no inyectar
En banda no deseable si cae tasa de descenso, inyectar
estable
En banda segura no inyectar
En banda no deseable inyectar de acuerdo a lo indeseado del
nivel
creciendo
En la banda segura inyectar si tasa de crecimiento constante o
creciente
En banda no deseable inyectar de acuerdo a la tasa de
crecimiento
134
Lenguaje de Especificacin Z
Se han desarrollado diversos lenguajes y herramientas
para la especificacin (y verificacin) de software.
Z (Hayes 87, Spivey 92) est basado en la teora de
conjuntos tipados
modela un sistema en base a conjuntos y sus relaciones
introduce elementos que facilitan la especificacin de pre y post
condiciones asociadas a estados
los modelos se construyen a partir de esquemas
Esquema: Introducen variables de estado y definen

restricciones y operaciones sobre los estados
Una especificacin es representada como un conjunto
de esquemas
Los esquemas pueden ser combinados y usados en
otros esquemas
135
Schema
name
Schema
signature
Schema
predicate
Container
contents:
capacity:
contents <= capacity
Schema signature:
Declara nombres y tipos de las entidades
Schema predicate:
Define relaciones entre las entidades de la signature
mediante expresiones lgicas que deben ser
verdaderas (invariantes)
136
Nombres seguidos por ? son entradas y por ! ,
salidas
Nombre seguido por significa el valor despus
de la operacin
precediendo a un nombre significa que los
valores no son cambiados por la operacin
precediendo a un nombre significa que los
valores son cambiados por la operacin
Incluir el esquema A en el esquema B significa
que B hereda los nombres y predicados de A
137
Z para la bomba de insulina

Conjunto de variables de estado:
reading? : Lectura del sensor de glucosa en la sangre
dose, cumulative_dose: dosis a suministrar y dosis acumulada
en un perodo
r0, r1, r2: 3 ltimas lecturas, se usa para calcular la razn del
cambio de glucosa en la sangre
Capacity: capacidad del depsito
alarm!: alarma
pump!: seal de control enviada a la bomba
display1!, display2! : msg de estado y dosis a administrar
Para la bomba de insulina:

dosis<=contenido del depsito
dosis<=5 unidades y suma de dosis en perodo <=50
display1! muestra el estado del depsito
138
Esquema para la bomba de insulina

Insulin_pump
reading? :
dose, cumulative_dose:
r0, r1, r2:
// para registrar las 3 ltimas lecturas tomadas
capacity:
alarm!: {off, on}
pump!:
display1!, display2!: STRING
dose<=capacity dose<= 5 cumulative_dose<= 50
capacity>= 40 display1! = " "
capacity<= 39 capacity >=10 display1! = "Insulina baja
capacity<= 9 alarm! = on display1! = "Insulina muy baja
r2 = reading?
139
Clculo de la dosis
DOSAGE
Insulin_Pump
Delta indica que

cambia el estado
(
dose = 0
(
r1>=r0) ( r2 = r1))
(( r1 > r0) (r2<= r1))
(( r1 < r0) ((r1-r2) > (r0-r1)))
)
dose = 4
(
(( r1<=r0) (r2=r1))
(( r1 < r0) ((r1-r2) <=(r0-r1)))
)
dose =(r2 -r1) * 4
(
(( r1<=r0) (r2 > r1))
(( r1 > r0) ((r2 - r1) >=(r1 - r0)))
)
)
capacity ' =capacity - dose
cumulative_dose' = cumulative_dose + dose
r0' = r1 r1' = r2
El programa:
Compara el valor actual
del nivel de azcar con
los dos anteriores
si est subiendo, la
bomba inyecta insulina
mantiene total de
insulina inyectada para
controlar el mximo
seguro
aplicado a una variable

refiere al valor luego
de cambiar el estado
140
Esquemas de Salida
Modelan lo que despliega el sistema:
La pantalla muestra la dosis calculada y un mensaje de advertencia
La alarma suena si el azcar en la sangre es muy baja -debe ingerir azcar
DISPLAY
Insulin_Pump
display2!' = Nat_to_string (dose)
(reading? < 3 display1! ' = "Azcar baja
reading? > 30 display1! ' = "Azcar muy baja
reading? >=3 and reading?<=30 display1!' = "OK")
ALARM
Insulin_Pump
( re ading? < 3 re ading? > 30 ) alarm!' = on
reading? >= 3 reading?<=30 ) alarm!' = off
141

Ingeniería de Requisitos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingeniería de Requisitos

Cargado por

Copyright:

Formatos disponibles

Ingeniera de Requisitos

Obtencin de Requisitos - Tcnicas

Administracin de los Requisitos

IEEE Recommended Practice for Software Requirements Specifications

Requisitos del Sistema

Requisitos del Software

Requisitos vs. Diseo

Reporte CHAOS de Standish Group `94

Falta de Soporte de Ejecutivos

Costos de Errores en los Requisitos

Requisitos Funcionales y No Funcionales

De la Organizacin: Se derivan de las polticas y

Externos: Se derivan de factores externos, como:

Requisitos - Tipos (1)

Usuarios y Factores Humanos

Funcionalidad y Restricciones asociadas

Requisitos - Tipos (2)

Requisitos - Tipos (3)

Proceso de los Requisitos

Administracin de los Requisitos

Lnea base corregida

Supervisores del Contrato, sugieren:

Gerentes del Negocio, entienden:

Obtencin & Anlisis de Requisitos

Brecha en la Comunicacin (Scharer 90)

no saben lo que quieren

no captan las necesidades operativas

no pueden articular lo que quieren

ponen excesivo nfasis en aspectos meramente

muchas necesidades por motivos polticos

pretenden indicarnos cmo hacer nuestro trabajo

no son capaces de traducir necesidades claramente

son incapaces de definir prioridades entre

siempre dicen que no

rehsan asumir responsabilidades por el

siempre estn pasados del presupuesto

incapaces de dar un enunciado utilizable de

siempre estn atrasados

no estn comprometidos con los proyectos

nos exigen tiempo y esfuerzo an a costa de las

no aceptan soluciones de compromiso

establecen estndares no realistas para la definicin

no pueden mantener el cronograma

son incapaces de responder rpidamente a cambios

Obtencin & Anlisis de Requisitos

product vision statement

Documento de visin. Sirve para establecer una visin

Criterios de xito. Pe.:

Entrevista Individual / Grupal

Pasos para las Entrevistas

Entender el problema de negocio

Enviar un memo con

Entrevista Patrn para conducirla

Datos: entradas y salidas clave, datos ya existentes

Procesos: propsito, objetivos y metas

Ubicaciones: lugares involucrados, contexto de los usuarios

Entrevista Patrn para conducirla (2)

Cules son las expectativas respecto a la confiabilidad?

Factores crticos de xito:

Su principal uso es para validar asunciones y obtener

Determinar informacin necesaria

Tormenta de Ideas (Brainstorming)

No se permite criticar ni debatir

Tormenta de Ideas Fase de Generacin