Está en la página 1de 112

EPS,Informtic

Tema 5

Anlisis de
Requisitos
1
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Educcin de Requisitos.
Anlisis de Requisitos.
Representacin de Requisitos.
Validacin de Requisitos.
Perfil del analista.
Principales errores del anlisis.
Documentacin final: ERS.
2

Resumen.
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Definicin.
Papeles.
Actividades principales.
Fuentes y Tcnicas.
Objetivos e importancia.
Definicin de Requisitos.
Entradas y Salidas.
Tareas Previas.
Principios.
Tareas
Educcin de Requisitos.
Anlisis de Requisitos.
Representacin de Requisitos.
Validacin de Requisitos.
Perfil del analista. 3
Principales errores del anlisis.
Documentacin final: ERS.
EPS,Informtic
a

Definicin (i)
Anlisis de requisitos:
Anlisis del problema y especificacin completa del
comportamiento externo que se espera del sistema
software que se va a construir, as como de los flujos de
informacin y control.

Requisitos de
Software
Requisitos del sistema

Requisitos del negocio


4
EPS,Informtic
a

Definicin
(ii)

Anlisis Diseo

5
EPS,Informtic
a

Papeles

Los clientes y usuarios plantean el


problema actual, el resultado que El ingeniero del software pregunta,
esperan obtener y las condiciones analiza, asimila y presenta la
que esperan. solucin adecuada.

6
EPS,Informtic
a

Actividades
principales
Necesidad Definicin
Idea Anlisis del problema Descripcin
del del
problema producto
Conjunto
de requisitos

DISEO
7
EPS,Informtic
a

Fuentes y
Tcnicas
Anlisis
del Por qu
Entorno
contexto Condiciones
(Aprendizaje Informacin
sobre el problema) Necesidades

Tareas

I.U.Restricciones
Entrevistas

REQUISITOS
(Comprensin de las 8
necesidades de los usuarios)
EPS,Informtic
a

Objetivos e
Importancia
Otros objetivos:
Proporcionar los medios de comunicacin entre todas las
partes: clientes, usuarios, jefe de proyecto, analistas y resto
del equipo de desarrollo.
Servir como base para las actividades de prueba y
validacin.
Ayudar al control de la evolucin del software.

Importancia:
El impacto de cometer errores en la fase de anlisis de
requisitos puede resultar en que el producto final no satisfaga
las necesidades de los usuarios. 9
EPS,Informtic
a

Definicin de
Requisitos
Para el usuario:
Son las condiciones o capacidades necesarias para que el
usuario pueda resolver un problema o alcanzar un objetivo.

Para el equipo de desarrollo:


Son las condiciones o capacidades que debe reunir un sistema
para satisfacer un contrato, estndar o cualquier otro documento
impuesto formalmente.

10
EPS,Informtic
a

Entradas y
Salidas
Peticin de los Aproximacin tecnolgica
por parte de los Ingenieros
usuarios
del Software

Anlisis de
requisitos

Salidas:
Especificacin de requisitos del software (ERS).
Definicin de lo que los usuarios quieren y lo que se les va a proporcionar.
Definicin de restricciones. 11
EPS,Informtic
a

Tareas previas
Definicin detallada de objetivos y alcance del sistema.

Descomposicin del problema en subproblemas.

Descripcin de la funcionalidad del sistema (funciones


bsicas).

Identificacin de la informacin (flujo, contenido y estructura).

Identificacin de las entradas y salidas del sistema.

Determinacin de las herramientas y tcnicas que se van a


12
utilizar en fases posteriores.
EPS,Informtic
a

Principios del
anlisis
Se debe comprender el problema y su entorno.
Los requisitos han de determinarse siguiendo una aproximacin
descendente, primero se analiza el problema globalmente, para
pasar posteriormente al detalle.
Se debe representar la informacin, funcin y comportamiento
del sistema.
Se debe separar el qudel cmo.
La especificacin de requisitos debe ser operativa.
La especificacin de requisitos debe poder ser ampliable.
13
EPS,Informtic
a

Tareas
Educcin de requisitos.
Identificar los requisitos que se obtienen de los usuarios y clientes.

Anlisis del problema y de los requisitos.


Razonar sobre los requisitos educidos, combinar requisitos relacionados,
establecer prioridades entre ellos, determinar su viabilidad,etc.

Representacin (modelizacin).
Registrar los requisitos de alguna forma, incluyendo lenguaje natural, lenguajes
formales, modelos, prototipos, maquetas, etc.

Validacin.
Examinar inconsistencias entre requisitos, determinar la correccin, ambigedad,
etc. Establecer criterios para asegurar que el software rena los requisitos cuando
se haya producido. El cliente, usuario y desarrollador se deben poner de acuerdo.
14
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Educcin de Requisitos.
Qu, Cmo.
Anlisis del problema.
Tipos de requisitos.
Tcnicas.
Anlisis de Requisitos.
Representacin de Requisitos.
Validacin de Requisitos.
Perfil del analista.
Principales errores del anlisis.
15
Documentacin final: ERS.
Resumen.
EPS,Informtic
a

Educcin de requisitos: Qu y
Cmo
Qu
Proceso a travs del cual, los clientes, compradores o usuarios de
un sistema software exponen, formulan, articulan y comprenden
sus requisitos.

Cmo
Reuniones, entrevistas, anlisis de las tareas, lectura de documentos
o manuales, etc.

16
EPS,Informtic
a

Procedimiento
bsico
1. Anlisis del problema.
2. Identificar usuarios potenciales.
3. Identificar fuentes relevantes de conocimiento/informacin.
4. Recopilar informacin y hechos.
5. Preparar y preguntar cuestiones concisas y directas.
6. Analizar la informacin obtenida.
7. Evaluar hallazgos (en funcin de coste, tcnicas).
8. Priorizar.
9. Comprobar el resultado con los usuarios.
10. Sintetizar la informacin en forma de especificaciones.
11. Determinar aspectos no analizados todava.

17
EPS,Informtic
a

Anlisis del
problema

El problema se realiza actualmente y necesita ser


mejorado.

El problema no se realiza actualmente.

18
EPS,Informtic
a

Anlisis del problema:


Estructuracin
Modos de estructuracin:

Particin (parte de).


Agrega relaciones estructurales entre objetos, funciones y
estados, simplifica las estructuras a ser analizadas.

Abstraccin (general/especfico, ejemplo de).


Identifica relaciones general/especfico entre objetos,
funciones y estados.

Proyeccin (diferentes puntos de vista, visin de).


Identifica relaciones visin de entre objetos, funciones y
estados.
19
EPS,Informtic
a

Tipos de requisitos
(i)
Requisitos funcionales
Acciones fundamentales que tienen que tener lugar en la ejecucin del software.

Requisitos de interfaz y usabilidad.


Mens, Ventanas, Mensajes de error, Formatos de Pantalla, etc.

Requisitos operacionales.
Modos de operacin, back-ups, funciones de recuperacin, etc.

Requisitos de documentacin.
Idiomas, tipos de usuario, ayuda on-line, web, tutoriales, etc.

Requisitos de seguridad.
Diferentes niveles de acceso al sistema, proteccin, mantenimiento de histricos,
20
claves, etc.
EPS,Informtic
a

Tipos de requisitos
(ii)
Requisitos de mantenibilidad y portabilidad.
Grado en que debe ser fcil cambiar el software o portarlo.

Requisitos de recursos.
Limitaciones sobre memoria, almacenamiento, etc.

Requisitos de verificacin y fiabilidad.


Sobre situaciones anmalas o de error.

Requisitos de rendimiento.
Tiempo de respuesta, n de usuarios, terminales soportadas, etc.

Requisitos de comportamiento.

... 21
EPS,Informtic
a

Tcnicas de
Educcin
Brainstorming.

Entrevistas.

JAD (Joint Application Design).

...

22
EPS,Informtic
a

Tcnicas de Educcin:
Brainstorming
1. Preparacin:
Identificacin de participantes.
Designacin de un moderador.
Designacin de un secretario.
Acotacin del tema.

2. Desarrollo.
Expresin libre de ideas.
Discusin.
Registro de ideas.
Finalizacin cuando haya suficientes ideas.

3. Consolidacin:
Revisin de ideas. 23
Discusin.
Acuerdo y definicin de prioridades.
EPS,Informtic
a

Tcnicas de Educcin: Entrevistas


(i)1. Preparacin:
Identificacin de participantes y roles.
Definicin de objetivos.
Formulacin de preguntas estructuradas.
Agrupacin de preguntas.

2. Desarrollo.
Revisin de objetivos y aspectos logsticos.
Realizar las preguntas.
Tomar notas.

3. Consolidacin:
Revisin de errores.
Revisin de aspectos esenciales.
Finalizar la entrevista.
24
4. Posteriormente se redacta el acta de reunin que se enva a los
usuarios para su revisin y aprobacin.
EPS,Informtic
a

Entrevistas, Aspectos prcticos


(i)
Si la respuesta no convence, seguir explorando:
Sintetizando la informacin.
Reformulando la respuesta.
Argumentando contradicciones.

No pasar errores detectados.

Tomar notas a la vez que se escucha.

Mantener el control de la entrevista.

25
EPS,Informtic
a

Entrevistas, Aspectos prcticos


(ii)
Asegurarse que se entiende la pregunta.

Distinguir entre tipos de preguntas:

Genricas (Cul es el resultado que se quiere obtener?)


Abiertas (Explcame tu comportamiento ante este problema).
Cerradas (La interfaz de usuario tiene que ser grfica?).
En profundidad (Cul es el propsito de esa accin?).

Resumir y recordar el objetivo de vez en cuando.

26
EPS,Informtic
a

JAD (Joint Application Design)


(i)
Orientada a favorecer cooperacin y comprensin.
Fases:
(Jefe JAD, direccin,
Definicin
usuarios)
del
Alcance y
proyecto
objetivos
(Jefe JAD, Investigacin
desarrolladores, Especificaciones preliminares
usuarios) de
Preparacin entradas, salidas y flujos
(Jefe JAD)
Especificacin
preliminar
Desarrollo de de requisitos
(participantes sesin JAD
JAD) Especificaciones
finales

(seleccin de participantes Generacin de


27
JAD) documento
final
EPS,Informtic
a

JAD (Joint Application Design)


(ii)1: Definicin del proyecto.
Fase
1.1. Entrevistas a la direccin Requisitos de alto
nivel
Propsito del proyecto
Alcance.
1.2. Adquisicin de informacin
Objetivos de la direccin.
Objetivos de los usuarios.
Funciones.
Restricciones.
Requisitos adicionales de recursos de
usuario.
Supuestos de partida
Participantes
Jefe JAD, desarrolladores, jefe
1.3. Seleccin del equipo JAD. Cuestiones abiertas.
usuarios, usuarios principales y de
consulta.
1.4. Construccin de Gua de Definicin de Gestin. Informacin de
1.2.
28
1.5. Planificacin de la sesin. Fases, actividades y
duracin.
EPS,Informtic
a

JAD (Joint Application Design)


(iii)
Fase 2: Investigacin.
Funcionamiento del
2.1. Familiarizacin con el sistema. sistema, tareas
(reuniones con
usuarios y
desarrolladores)
2.2. Investigacin y documentacin del flujo de datos. DFDs

Entradas, Datos
2.3. Recopilacin de especificaciones preliminares. utilizados, Salidas
(pantallas,
informes)
2.4. Preparacin de la agenda de la sesin (en funcin
de 1.4, 2.1, 2.2 y 2.3).

29
EPS,Informtic
a

JAD (Joint Application Design)


(iv)
Fase 3: Preparacin.
3.1. Recopilacin de toda la documentacin anterior
en el Documento de Trabajo.

Resumir la metodologa
3.2. Reunin previa a JAD. JAD, obtener compromiso
de la empresa

3.3. Preparacin de la sala, medios audiovisuales, etc.

30
EPS,Informtic
a

JAD (Joint Application Design)


(v)
Fase 4: Desarrollo de sesin JAD.
Definicin del objetivo de
4.1. Introduccin. la reunin, visin global
del sistema.

4.2. Discusin de cada uno de los puntos del


Documento de trabajo.

Decisin de quin revisar


4.3. Cierre de la sesin. el
documento final.

31
EPS,Informtic
a

JAD (Joint Application Design)


(vi)5: Generacin del documento final.
Fase
5.1. Produccin del documento final.
Agenda de la sesin.
Participantes de la sesin.
Supuestos.
Objetivos y alcance del proyecto.
Funciones existentes.
Funciones nuevas.
Requisitos generales.
Restricciones.
Entradas y salidas.
Flujo de datos.
5.2. Revisin del documento.
5.3. Aprobacin final.
5.4. Cambio de especificaciones del JAD. El documento supone un punto en32
el tiempo que contiene especificaciones aprobadas.
EPS,Informtic
a

JAD (Joint Application Design)


(vii)para adquisicin de Informacin segn tcnica JAD
Formulario

Propsito del
sistema.
Alcance del
sistema.
Objetivos/Beneficios del
proyecto.
Funciones y
Entradas/Salidas.
Restricciones
.
Requisitos
generales.
Supuestos de
partida.
Cuestiones
abiertas.
Participantes 33
.
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Educcin de Requisitos.
Anlisis de Requisitos.
Representacin de Requisitos.
Validacin de Requisitos.
Perfil del analista.
Principales errores del anlisis.
Documentacin final: ERS. 34

Resumen.
EPS,Informtic
a

Anlisis de
requisitos
Qu
Proceso a travs del cual se determina qu requisitos son
aceptables y se definen cules van a formar parte del
producto.

Cmo
Evaluacin de viabilidad tcnica y econmica.
Valoracin de riesgos.
Clasificacin de requisitos en categoras:
Obligatorios.
Deseables.
Accesorios.
...
35
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Educcin de Requisitos.
Anlisis de Requisitos.

Representacinde Requisitos.
Prototipado/Maquetado.
Anlisis estructurado.
Diagramas de flujo de datos (DFD).
Diccionario de datos.
Diagramas Entidad-Relacin (ERD).
Diagramas de transicin de estados (DTE).
Anlisis Orientado a Objetos con UML.
Diagramas de Casos de Uso.
Diagramas de Secuencia del Sistema.
Diagramas de Clases Conceptuales.
Modelado adicional de Anlisis.
Especificacin Formal: Lenguaje Z
Validacin de Requisitos. 36
Perfil del analista.
Principales errores del anlisis.
EPS,Informtic
a

Representacin de
requisitos
Qu
Proceso de registrar los requisitos de una o ms formas y de
especificar aquellos requisitos todava no educidos.

Cmo
Lenguaje natural.
Lenguaje formal.
Modelos
Diagramas.
Maquetas.
...
37
EPS,Informtic
a

Prototipado/Maquetad
oEs un proceso iterativo.

Construir/revisar
maqueta

Definir nuevos Evaluar con los


requisitos usuarios

Tirar
38
EPS,Informtic
a

Tcnicas de representacin
de requisitos
Anlisis estructurado.
Tcnicas de anlisis orientadas a datos.
Tcnicas de anlisis orientadas a funciones.
Tcnicas de anlisis orientadas a estados.

Anlisis orientado a objetos.

Lenguajes formales.
39
EPS,Informtic
a

DFD (i)
Muestra el flujo de informacin y las transformaciones que se
aplican a los datos al moverse desde la Entrada a la Salida.

Est compuesto de:


Flujos de datos:
Representa un conjunto de valores del sistema en un momento
determinado.
Procesos:
Representa una transformacin de los flujos de entrada en los flujos de
salida.
Almacenes de datos:
Representa un conjunto de datos que se guardan para ser usados por uno
o ms procesos.
Entidades
Representaexternas:
un productor o consumidor de datos que reside fuera del
sistema que refleja el DFD, pero que est relacionado con l. 40
EPS,Informtic
a

DFD (ii)

Flujo de
datos
Proceso

Almacn de datos Entidad externa

41
EPS,Informtic
a

DFD (iii)
Elemento Campos tpicos en una Herramienta CASE Smbolo

Cada proceso tiene: Etiqueta (nombre)


Un nmero Tipo (proceso)
Un nombre o frase verbal Descripcion (qu es)
Una descripcin Nmero de proceso <nmero>
Uno o ms flujos de datos de salida. Descripcin de proceso (lenguaje estructurado).
Normalmente uno o ms flujos de Notas <Nombre
entrada. >
Cada flujo de datos tiene: Etiqueta (nombre).
Un nombre (sustantivo). Tipo (flujo).
Una descripcin. Descripcin.
Una o ms conexiones a un proceso Alias (otros nombres) <Nombre>
Composicin (descripcin de los elementos de
datos). Notas

Cada Almacn de datos tiene: Etiqueta (nombre)


Un nmero Tipo (almacn)
Un nombre (un sustantivo). Descripcin (alias) D<numero>
Uno o ms flujos de entrada. Composicin (descripcn de los elemento de Nombre
Normalmente uno o ms flujos de salida datos). Notas

Cada entidad externa tiene: Etiqueta (nombre)


Un nombre (sustantivo) Tipo (entidad)
Una descripcin Descripcin <Nombre>
Alias (otros nombres)
Descripcin de la entidad.
Notas 42
EPS,Informtic
a

DFD (iv)
Entidad Entidad
Entidad
Entidad
externa externa
externa
externa

Sistema
Sistema Entidad
Entidad
informtico
informtico externa
externa

Entidad Entidad
Entidad
Entidad
externa externa
externa
externa
43
Diagrama de contexto o de Nivel 0
EPS,Informtic
a

DFD (v)
Reglas de construccin de un DFD:
Todos los nombres deben ser nicos.
Un DFD no establece el orden de los sucesos.
Se deben suprimir las decisiones lgicas.
No hay que entrar en detalles de diseo fsico.
No pueden existir flechas (flujos de datos) entre dos agentes
externos.
Todos los procesos tienen que tener flechas de entrada y de salida.
El diagrama de contexto (nivel 0) tiene que tener un solo proceso que
recibe y genera flujos de datos de/hacia agentes externos.
Nivelado o equilibrado: Refinamiento del flujo de informacin. La
entrada y salida de cada refinamiento debe ser la misma. 44
EPS,Informtic
a

Diccionario de datos
(i)
Qu es:
Un depsito en el que se almacena el contenido de todos los
elementos de datos definidos en los DFDs.

Propsito:
Describir todos los datos y comprobar la consistencia.

45
EPS,Informtic
a

Diccionario de datos
(ii) la siguiente informacin:
Contienen

Nombre del elemento de datos.

Alias del nombre.

Descripcin del contenido.

Procesos que generan o reciben el elemento de datos, y


propsito.

Informacin adicional: elementos de datos relacionados,


rango de valores, restricciones, etc. 46
EPS,Informtic
a

Diccionario de datos
(iii)
Para la definicin de valores, se usa una
notacin similar a BNF:
Smbolo Significado
:= Compuesto de
+ Concatenacin
() Datos opcionales
{}n N iteraciones
[...|...|...] Seleccin de una
alternativa
*...* Delimita comentarios

47
EPS,Informtic
a

Diccionario de datos
(iv)
Ejemplo: Nmero de telfono.
Telefono:= [interno|movil|nacional|extranj] interno := {digito} 4

nacional:= 9+{digito} movil := 6+{digito} extranj := ++


7 8

{digito} digito := [0|1|2|3|4


11

|5|6|7|8|9]

48
EPS,Informtic
a

Diccionario de datos
(iv)
Ejemplo: Un libro est descrito por su autor,
ttulo, edicin y precio. Adems, opcionalmente
se puede incluir la editorial, el ISBN y el ao.

49
EPS,Informtic
a

ERD (i)
Propuesto por Chen en 1976.
Objetivo:
Representar los datos y sus relaciones.

Elementos bsicos:
Entidades.
Elementos distinguibles en la empresa o problema.
Relaciones.
Interacciones entre entidades.
Atributos.
Propiedades de las entidades y de las relaciones.
50
EPS,Informtic
a

ERD (ii) Conjunto


Conjunto
de empleados de proyectos

Javier HIT

Elena ENCITEC

INTEREDU
Pedro

No es til para el modelado.


51
Se necesita una notacin ms
concisa.
EPS,Informtic
a

ERD (iii)

Empleado Trabaja
Proyecto
Nombre Nombre
DNI Fecha de
Direccin inicio
... ...

Tambin se indica:
Cardinalidad: 1, Muchos.
Opcionalidad.
Normalmente, uno o ms de los atributos se subrayan
(clave).
52
EPS,Informtic
a

ERD (iv)
Construccin de diagramas E-R.

Definir las entidades.

Definir las relaciones.

Definir los atributos.

Especificar la cardinalidad de las relaciones.

Especificar la participacin de las entidades en la relacin.


53
EPS,Informtic
a

Diagramas de transicin
de estados (i)
Estado.
Conjunto de valores de los atributos de un objeto/entidad en
un momento dado. El estado de las entidades cambia con el
tiempo.

Evento.
Suceso que ocurre en un determinado momento de tiempo,
sin duracin apreciable, y que provoca un cambio de estado
en un objeto o entidad.
Las entidades generan eventos hacia otras como forma de
comunicacin. La respuesta de la entidad depender del 54
estado que tenga.
EPS,Informtic
a

Diagramas de transicin
de estados (ii)
Diagrama de transicin de estados (DTE).
Un DTE relaciona estados (nodos) y eventos (arcos,
transiciones de estados) en un grafo.
Estado
Estado evento Estado
Estado
Origen
Origen Destino
Destino

Modelo dinmico.
Est formado por el conjunto de diagramas de estados de cada
uno de los objetos o entidades que existen en el dominio (y que
55
no tienen un comportamiento trivial).
EPS,Informtic
a

Diagramas de transicin
de estados (iii)
Notacin.
Nombre del
Estado (origen y destino). estado

Evento. Nombre del


evento
Inicio Final
Estados inicial y final.

Parmetros del evento. Nombre del evento (par1,


par2, ...)

Guarda de la transicin Nombre del evento (par1, ...)


Condicin que hace que se [condicin]
56
dispare el evento.
EPS,Informtic
a

Diagramas de transicin
de estados (iv)
Actores.
Personas o interfaces con otros
sistemas..

Lmites del sistema.

Actividad.
Operacin que para ser completada
hace falta cierto tiempo. Asociada a Estado
un estado. Comienza al activarse y origen Estado dest.
continua hasta el cambio. actividad-1 actividad-2
Accin. E: accin 1 E: accin 3
S: accin 2 S: accin 4
Operacin instantnea. Normalmente
asociadas a transiciones, se ejecutan 57
si la transicin se dispara. Evento(par.,...)[condicin ]/accin-
5
EPS,Informtic
a

Diagramas de transicin
de estados (v)
Statecharts = Estados + Jerarqua + Ortogonalidad + Broadcasting

SS W
AD
EE k
BB
FF ZZ
g n
f/g e
n
CC GG e

H n/f
II JJ
m/e
58
EPS,Informtic
a

Diagramas de transicin
de estados (vi):
Ejemplo
Dibujar el DTE de los estados por los que pasa una letra
de cambio. Una vez impresa, si se acepta pasa al estado
aceptada. Posteriormente, la letra se va abonando
progresivamente (suponemos que se puede abonar a
plazos), pasando al estado parcialmente pagada, donde
se va actualizando el importe que queda por pagar. Si se
acaba de pagar la letra, se llega al estado final pagada.
Si la letra no se abona totalmente, se llega al estado final
cancelada.
59
EPS,Informtic
a

Anlisis Orientado a Objetos


con UML
Unified Modeling Language.

Estndar que combina los mtodos de


http://www.omg.org
modelado ms conocidos:
Booch -OOD.
Rumbaugh -OMT.
Jacobson -OOSE y Objectory.
Lenguaje grfico para visualizar, especificar, construir y
documentar las partes de un sistema de
software.

NO es una metodologa.

Puede utilizarse a lo largo de todo el ciclo 60


de vida.
EPS,Informtic
a

Anlisis Orientado a Objetos


con UML
Diagramas Diagramas de
Estructurales Comportamiento
D. de Clases D. Casos de Uso
D. de Objetos D. de Secuencia
D. de Componentes D. de Colaboracin
D. de Instalacin D. de Estados
D. de Actividad

61
EPS,Informtic
a

Anlisis Orientado a Objetos


con UML

Anlisis Diseo
Anlisis Diseo

D. Casos de Uso. D. Clases y Objetos.


D. Secuencia del D. Colaboracin.
Sistema.
D. Secuencia.
D. Clases
Conceptuales. D. Estados.
62
EPS,Informtic
a

Anlisis Orientado a
Objetos:
Casos de Uso
Actor = Algo con comportamiento (persona, otro
programa, organizacin...), que interactua con el sistema.

Escenario (instancia de caso de uso) = Secuencia de


acciones e interacciones entre los actores y el sistema.

Caso de Uso = Coleccin de escenarios (xito y fracaso)


que describen actores que usan el sistema para conseguir
un objetivo.
63
EPS,Informtic
a

Anlisis Orientado a
Objetos:
Casos de Uso
Pasos:

Identificar los lmites del sistema.

Identificar los actores principales.

Para cada uno, identificar sus objetivos.

Definir casos de uso que satisfagan sus objetivos.


64
EPS,Informtic
a

Anlisis Orientado a
Objetos:
Casos de Uso

Cajero Terminal
Punto de
Venta
(TPV)
65
EPS,Informtic

Casos de Uso:
a

Ejemplo
CASO DE USO 1: Procesar venta

Actor Primario:
Cajero.
Interesados y objetivos:
Cajero: Quiere anotaciones precisas y rpidas de precios, sin errores.
Cliente: Quiere que el pago sea rpido con el mnimo esfuerzo. Quiere una
prueba de compra para justificar devoluciones.
Compaa: Quieren almacenar las transacciones y satisfacer los intereses
de los clientes.
Comercial: Quiere que se le actualicen sus comisiones por venta.
Agencias de impuestos gubernamentales: Quieren recolectar impuestos de
cada venta. Puede que haya varias agencias (nacionales, regionales, etc.)
Servicios de Autorizacin de Pagos (por tarjetas de crdito): Quiere recibir
peticiones digitales de autorizaciones en el formato y protocolocorrecto.
Precondiciones:
El cajero se ha identificado y autentificado.
66
EPS,Informtic

Casos de Uso:
a

Ejemplo
Garanta de xito (Postcondiciones):
Se registra la compra en el sistema. Se calcula el impuesto aplicable. Se
actualizan los sistemas de inventario y de contabilidad. Se registran las
comisiones. Se genera un recibo. Se registran las aprobaciones de pago por
tarjeta.
Escenario principal de Exito:
1. Llega un clienta al TPV con bienes o servicios que comprar.
2. El cajero comienza una nueva compra.
3. El cajero introduce un identificador de producto.
4. El sistema registra el elemento y presenta una descripcin del mismo,
su precio y total actual. Se calcula el precio de una lista de reglas.
El cajero repite los pasos 3-4 hasta que no hay ms elementos.
5. El sistema presenta el total con los impuestos calculados.
6. El cajero le dice el total al cliente, y le pide que pague.
7. El cliente paga y el sistema procesa el pago.
8. El sistema registra la venta completada y manda la informacin a los 67
9. El sistema genera el recibo.
sistemas externos de inventario y contabilidad.
EPS,Informtic

Casos de Uso:
a

Ejemplo
Extensiones (Flujos alternativos):
a*. En cualquier momento, el sistema falla.

3a. Identificador invlido.


1. El sistema seala un error y rechaza la entrada.
7a. Pago en efectivo.
...
7b. Pago con tarjeta.
...

Requisitos especiales:
Pantalla tctil en panel grande y plano. El texto debe ser visible desde un metro.
Respuesta de autorizacin de crdito en menos de 30 secs, el 90% de las veces.
Recuperacin robusta cuando el acceso a sistemas externos (tales como el
inventario, impuestos, etc.) falla.
Posibilidades de internacionalizacin de texto.
... 68
Reglas de negocio insertables en los pasos 3 y 7.
EPS,Informtic

Casos de Uso:
a

Ejemplo
Lista de variaciones de tecnologa y datos:
3a. Se introduce el identificador del elemento mediante escner de cdigo de barras
o mediante el teclado.
3b. Distintos esquemas de identificadores: UPC, EAN, JAN o SKU.
7a. La informacin sobre el pago con tarjeta se puede introducir mediante el teclado
o lector.
7b. Se pide firma en papel. En dos aos, creemos que muchos clientes van a querer
captura de firma digital.

Frecuencia de ocurrencia:
Puede ser casi continua.

Temas abiertos:
Cules son las posibles variaciones en las leyes sobre impuestos?
Explorar el tema de recuperacin en caso de fallo de sistemas externos.
Qu modificaciones se necesitan para negocios distintos?
Debeelelcliente
Puede cajerousar
extraer el cajn con
directamente el la recaudacin
lector al oterminar?
de tarjetas es el cajero el que lo
69
hace?
EPS,Informtic

Casos de Uso:
a

DiagramasTPV
TPV
Procesar
Procesar
Venta
Venta
Servicio
cajero de
Procesar
Procesar Autorizacin
de Pagos
Devolucione
Devolucione
ss
actor
actor
actor
actor
Analizar
Analizar
Analizador
Analizador Actividad
Actividad Calculador
de
Actividad Calculador
de
Actividad de
deImpuestos
Impuestos
deVentas
de Ventas
...
...
actor
actor
Gestionar
Gestionar Sistemadede
Sistema
Seguridad
Seguridad contabilida
contabilida
dd
Gestionar
Gestionar
Administrado Usuarios
Usuarios
r del sistema 70
EPS,Informtic
a

Casos de Uso:
Diagramas
Cancel
Cancel
Appointment
Appointment

Make Scheduler
Make
Appointment
Appointment <<includes>>
<<includes>> CheckPatient
Patient
Check
Record
Record
Patient Request
Request
Medication
Medication
Defer Payment Doctor
<<extends>>
Defer Payment
Pay Bill
Pay Bill
Extensions
Extensions Clerk
Points
MoreTreatment
Points
More Treatment
Bill Insurance 71
Bill Insurance
EPS,Informtic
a

Diagramas de Secuencia
del Sistema
Aisla e ilustra las operaciones que los actores externos
piden al sistema.

Muestra los eventos que los actores externos generan,


su orden y los eventos entre sistema.

Los sistemas se muestran como una caja negra.

Se deben construir DSS por cada escenario de xito del


casos de uso y para escenarios alternativos frecuentes o
complejos. 72
EPS,Informtic
a

Diagramas de Secuencia
del Sistema
: Sistema

: Cajero
hacerNuevaCompra()

introducirElemento(ID, cantidad)

Descripcion, total
* [ ] es una
* [ms elementos] marca de
iteracin

finCompra()

Total con impuestos

realizarPago(cantidad)
73
Cambio, recibo
EPS,Informtic
a

Diagramas de
Actividad Comenzar nueva

compra

Introducir ID del
producto
Obtener
descripcin, precio
y total actual
[ms
elementos]
[no ms
elementos]
Obtener Total

Realizar Pago

Procesar Pago

Informar
Sistemas
Externos
Obtener
Recibo 74
EPS,Informtic
a

Diagramas de Actividad:
Carriles Cajero
Sistema

Comenzar nueva

compra

Introducir ID del
producto
Presentar
descripcin,
precio y total
actual
[ms
elementos]
[no ms
elementos]
Presentar Total

Realizar Pago Procesar Pago

Informar
Sistemas
Externos
Presentar
Recibo 75
EPS,Informtic
a

Diagramas Conceptuales
de Clases
Sirven para realizar modelos del dominio de la aplicacin.

Identifica las clases conceptuales en el dominio.

Es una representacin de las clases del mundo real, no


describen clases Software (esto se deja para la fase de
diseo).

Se representa mediante diagramas de clases con:


Objetos de domino (clases conceptuales).
Asociaciones entre clases conceptuales. 76

Atributos de las clases conceptuales.


EPS,Informtic

Diagramas Conceptuales
a

Concepto u

de Clases Objeto del


dominio

ElementoVent
ElementoVent Especific.Product
Especific.Product
aa
cantidad registra-ventas-
o
oDescripcio
cantidad Descripcio 3 contiene
0..1 de n
Precio
Precio
n 1..*
1..* 1..* ID
ID 1
Producto
Producto 1 Catlogo
Catlogo
1..*
contenido-en
1..* 3
describe 3 Usado-por 1
1
*
Venta 3 almacena Tienda
Venta Tienda
* capturada-en 1
fecha
fecha direccin
direccin Atributos
Iniciada-por
hora
hora 1 nombre
nombre
pagada-por

1 1 1
Cliente
Cliente contiene

1 1..* Asociacin
Pago 1 Registro
Pago Cajero Registro
Cajero
cantidad registra-ventas- 77
cantidad
en 1
EPS,Informtic
a

Modelado adicional de
Anlisis
Clases de entidad: <<entidad>
> Nombre-
Informacin que maneja la aplicacin. clase
Nombre-
clase

Clases de contorno: <<contorno>


Modela la interaccin entre los actores y > Nombre-
el sistema. clase
Nombre-
clase

Clases de control
<<control>
Modela computaciones y algoritmos. > Nombre-
clase
Nombre-
clase 78
EPS,Informtic
a

Modelado adicional de
Anlisis Diagrama de clases
de anlisis del Caso
Cajero TPV GUI Procesar
de Uso
Venta

actor actor actor


actor actor actor

Sistema
Sistema Servicio
Servicio Calculador
Calculador
Contabilida Autorizaci Impuestos Calculo Registro Busqueda
Contabilida Autorizaci Impuestos Venta Elemento
Precio
dd nn Pagos
Pagos

1..*

Venta Elemento
Venta
79
EPS,Informtic
a

Modelado adicional de
Anlisis actor
: Busqueda e : Elemento : Calculo : Calculador
: Cajero : TPV GUI : Registro v : Venta
Elemento Venta Precio Impuestos
Venta
Nueva Compra
Nueva Compra
v := nuevo

Preparado

Elemento(ID, q)
registrar(ID, q)
buscar(ID)

descripcion e = Nuevo
(ID, q)

aadir(e)

precio(v, e, q)
total
total
* [mas elementos]
Fin compra
Calcula tasas (total, v)
Total con tasas
Total con tasas

80
...
EPS,Informtic
a

Especificacin
Formal
Uso de notaciones matemticas para describir
de manera precisa las propiedades que debe
tener un sistema de informacin, sin restringir
excesivamente la manera en que estas
propiedades se obtienen.

Permite responder de manera precisa a


preguntas sobre el comportamiento del sistema.

81
EPS,Informtic
a

Especificacin
Formal
Riesgos del uso de enfoques menos
formales (lenguaje natural o notaciones
grficas):
Contradicciones.
Ambigedad, vaguedades.
Incompletitud.
Grados mixtos de abstraccin.

82
EPS,Informtic
a

Lenguaje Z

Descomponer la especificacin en esquemas.

Representan aspectos estticos y dinmicos:


Estados por los que puede pasar el sistema
Relaciones invariantes que se matienen de un estado
al siguiente.
Operaciones posibles.
La relacin entre sus entradas y salidas.
Los cambios de estado que pueden suceder.

83
EPS,Informtic
a

Lenguaje Z. Ejemplo:
Agenda
[NAME, DATE]

BirthdayBook
known: NAME birthday:
NAME DATE known =
dom birthday

84
EPS,Informtic
a

Lenguaje Z. Ejemplo:
Agenda
Posible estado:

known = {Juan Carlos, Sofa, Leonor, Felipe}


birthday = { Juan Carlos 5 - Enero
Leonor 31 -Octubre
Sofa 2 Noviembre
Felipe 30 -Enero}

85
EPS,Informtic
a

Lenguaje Z. Ejemplo:
Agenda
AddBirthday
BirthdayBook name?: NAME date?:
DATE name? known birthday =
birthday {name? date?}

86
EPS,Informtic
a

Lenguaje Z. Ejemplo:
Agenda
FindBirthday
BirthdayBook name?:
NAME date!: DATE
name? known date! =
birthday(name?)

87
EPS,Informtic
a

Lenguaje Z. Ejemplo:
Agenda
Remind
BirthdayBook today?: NAME cards!:
DATE cards! = { n : known | birthday(n) =
today? }

88
EPS,Informtic
a

Lenguaje Z. Ejemplo:
Agenda
InitBirthdayBook
BirthdayBook
known =

89
EPS,Informtic
a

Lenguaje Z. Ejemplo:
Agenda
Mejorando la Especificacin
REPORT ::= ok | already_known | not_known

Success
result! : REPORT
result! = ok

AddBirthday Success

90
EPS,Informtic
a

Lenguaje Z. Ejemplo:
Agenda
Mejorando
AlreadyKnown la Especificacin
BirthdayBook name? :
NAME result! : REPORT
name? known result! =
already_known

RAddBirthday = (AddBirthday Success) AlreadyKnown

91
EPS,Informtic
a

Lenguaje Z. Ejemplo:
Agenda
NotKnownMejorando la Especificacin
BirthdayBook
name? : NAME
result! : REPORT
name? known
result! = not_known

RFindBirthday = (FindBirthday Success) NotKnown

RRemind = Remind Success

92
EPS,Informtic
a

Especificacin
Formal
Ventajas:
Ventajas e Inconvenientes
Representacin precisa (consistente, ntegra, no
ambigua) de los requisitos.
Permite probar propiedades, simulacin.
Facilita la verificacin de la implementacin.

Inconvenientes:
Tcnicas complicadas, basadas en matemticas.
Preparacin de los Ingenieros del Software.
Pobre soporte por herramientas comerciales.
No rentable para todo tipo de proyectos.
93
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Educcin de Requisitos.
Anlisis de Requisitos.
Representacin de Requisitos.
Validacin de Requisitos.
Perfil del analista.
Principales errores del anlisis.
Documentacin final: ERS. 94

Resumen.
EPS,Informtic
a

Validacin de requisitos
(i)
Los requisitos deben ser:

Completos.
Todo lo que el software tiene que hacer est recogido en el conjunto de
requisitos.

No ambiguos.
Cada requisito debe tener una sola interpretacin.

Relevantes.
Importancia para el sistema software a implementar.

Traceables
Cada accin de diseo debe corresponderse con algn requisito, ydebe
poder comprobarse.
95
EPS,Informtic
a

Validacin de requisitos
(ii)
Los requisitos deben ser:
Correctos.
Cada requisito establecido debe representar algo requerido por el usuario
para el sistema que se construye.

Consistentes.
Ningn requisito puede estar en conflicto con otro. Tipos de inconsistencias:
Trminos conflictivos: Si dos trminos se usan en contextos
diferentes para la misma cosa.
Caractersticas en conflicto:Si en dos partes de la ERS se pide que el
producto muestre comportamientos contradictorios.
Inconsistencia temporal: Si dos partes de la ERS piden que el
producto obedezca restricciones de tiempo contradictorias.
96
EPS,Informtic
a

Validacin de requisitos
(iii)
Ejemplo:

1. ... hasta 15 autobuses se dibujarn dentro de la misma ventana.Si


excede el nmero se utilizar otra ventana diferente.

2. El sistema tendr una interfaz de usuario sencilla de utilizar.

3. Los usuarios deben escribir su contrasea en un tiempo menor de15


segundos desde que escribieron su identificacin.

4. El tiempo de respuesta para todos los comandos ser menor de 0.1


segundos. El tiempo de respuesta para el comando DELETEser menor
de 5 segundos.

5. El sistema tendr un tiempo de respuesta


97
aceptable.
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Educcin de Requisitos.
Anlisis de Requisitos.
Representacin de Requisitos.
Validacin de Requisitos.
Perfil del analista.
Principales errores del anlisis.
Documentacin final: ERS. 98

Resumen.
EPS,Informtic
a

Perfil del
analista
Personal de desarrollo con ms experiencia.

Dotes de comunicacin.

Capacidad de anlisis y de sntesis.

99
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Educcin de Requisitos.
Anlisis de Requisitos.
Representacin de Requisitos.
Validacin de Requisitos.
Perfil del analista.
Principales errores del anlisis.
Documentacin final: ERS. 100

Resumen.
EPS,Informtic
a

Principales errores del anlisis


(i)Alto riesgo de mal entendimiento entre cliente/usuario
e ingeniero del software.
Requisitos ambiguos.

Tendencia a acortar y minimizar la importancia de esta


etapa.
Se establecen los criterios de aceptacin del Software.
Es la base de qu se va a implementar.

Pobre estudio del problema.


El ingeniero del software debe conocer bien el dominio del
101
problema.
EPS,Informtic
a

Principales errores del anlisis


(ii)
No revisin de la especificacin de requisitos
por el cliente/usuario o el ingeniero del software.

Permitir el continuo cambio de requisitos por


parte del usuario.

Introducir conceptos de implementacin o


diseo.
102
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Educcin de Requisitos.
Anlisis de Requisitos.
Representacin de Requisitos.
Validacin de Requisitos.
Perfil del analista.
Principales errores del anlisis.
Documentacin final: ERS. 103

Resumen.
EPS,Informtic
a

ERS. Aspectos que


considera
ERS

Interfaces
Funcionalida Rendimient
Externas
d o Atributos Restriccione
s
Estndares de
Portabilidad. calidad.
Velocidad.
Interaccin del Traceabilidad. Lenguaje de
Qu se supone Disponibilidad.
SW con el en- Correccin. codificacin.
que ha de Tiempo de
torno, gente, Mantenibilidad Limitaciones
hacer el respuesta.
HW u otros SW. .
Calidad. de recursos.
software. ..
.. Econmicas.
...
104
EPS,Informtic
a

Documento final:
de
Especificacin
Requisitos Software (ERS)
(i)Propsito.

Proporcionar los medios de comunicacin entre todas


las partes: clientes, usuarios, analistas y diseadores.

Servir como base para las actividades de prueba y


verificacin.

Ayudar al control de la evolucin del sistema software.


105
EPS,Informtic
a

Documento final: ERS


(ii)
Atributos:
Correcto.
Completo.
Consistente.
No ambiguo.
Funcional.
Verificable.
Traceable.
Fcilmente modificable.
Comprensible para los usuarios.
Trazado.
Conciso. 106

Organizado.
EPS,Informtic
a

Documento final: ERS


1.(iii)
Introduccin.
1.1. Propsito.
1.2. Definiciones, acrnimos y abreviaturas.
1.3. Referencias.
1.4. Estructura.

2. Descripcin general.
2.1. Alcance.
2.2. Funciones del producto.
2.3. Restricciones generales.
2.4. Dependencias.
2.5. Caractersticas de usuario. 107
EPS,Informtic
a

Documento final: ERS


3.(iv)
Requisitos especficos.
3.1. Requisitos de interfaz.
3.2. Requisitos de rendimiento.
3.3. Requisitos operacionales.
3.4. Requisitos de recursos.
3.5. Atributos del sistema software: fiabilidad,
disponibilidad, seguridad, mantenimiento y
portabilidad.

4. Descripcin de la informacin.
4.1. Flujo de datos.
4.2. Flujo de control. 108
EPS,Informtic
a

Documento final: ERS


(v)
5. Descripcin funcional.
5.1. Particin funcional.
5.2. Diagramas de soporte.

6. Descripcin del comportamiento.

7. Criterios de validacin.
7.1. Lmites de rendimiento.
7.2. Clases de pruebas.
7.3. Respuesta esperada del producto.
7.4. Consideraciones especiales.
109
EPS,Informtic
a

Indice
Definiciones e Introduccin.
Educcin de Requisitos.
Anlisis de Requisitos.
Representacin de Requisitos.
Validacin de Requisitos.
Perfil del analista.
Principales errores del anlisis.
Documentacin final: ERS.
110

Resumen.
EPS,Informtic
a

Resumen (i)
Las dos actividades principales de la fase de anlisis
son el anlisis del problema y la descripcin del
producto.

La entrada de esta fase es el plan de proyecto. La


salida es el documento de Especificacin de Requisitos
Software.

111
EPS,Informtic
a

Resumen (ii)
Las tareas que hay que llevar a cabo son:
Educcin de requisitos (Identificacin).
Anlisis del problema y de los requisitos
(Razonamiento).
Representacin de los requisitos (Registro).
Validacin de los requisitos (Criterios).

Los dos grandes grupos de tcnicas de


representacin de requisitos son:
Anlisis estructurado (DFD, ERD, DTE).
Anlisis orientado a objetos (Casos de Uso, Clases 112
Conceptuales, Diag. Secuencia del Sistema).