Especificacin y

Anlisis de
Requerimientos
Ingeniera de Software
Especificacin y anlisis de
requerimientos
Qu es un Requerimiento?
Es un aspecto del contenido o comportamiento del
producto, requerido o deseado por el cliente.
Requerimientos funcionales. (Debe hacer)
Requerimientos no-funcionales.(Debe tener)

Una restriccin es un requerimiento que afecta a

todo el producto.
 Qu Ciclo
es un Concepto?
de vida V

Verificacin y Validacin
Porqu? Concepto Pruebas acept.

Qu? Anlisis Pruebas integ.

Cmo? Diseo Pruebas unit.

Hacer Cdigo

Concepto : conocimiento general del proceso del negocio.

Entrega: diag. de contexto, diag. de Entidad-Relacin, Casos de Uso
Modelo de Procesos Volere
Fases de la especificacin y
anlisis de requerimientos
Blastoff
Recoleccin de requerimientos
Prototipos
Verificacin y validacin
Revisiones
Post-Mortem
 Blastoff (Despegar)
Preparacin para el inicio del proyecto
Reunin entre los principales desarrolladores,
clientes y usuarios
Del Blastoff se obtienen:
El contexto
Propsito del proyecto
Lista de principales riesgos
Estimacin inicial del esfuerzo
Decisin de seguir adelante o no
Identificacin clara de los interesados
Compromiso con el proyecto
Formacin de equipos
 Blastoff (continuacin)

Determinar el propsito del producto:

1. Escribir en una frase el objetivo/propsito del
producto
2. Cul es la ventaja/solucin que ofrece?
3. Definir cmo medir el xito.
Adems:
4. Es realista / factible?
5. Lo desean todos los interesados (stakeholder)?
Propsito del producto:

Todos los dems requerimientos son

verificados/validados en torno a su
contribucin al propsito del producto.
Qu ventaja o solucin queremos que ofrezca
el producto?
El producto tiene un criterio de validacin
medible/verificable.
La satisfaccin es un factor en el valor del
producto.
Identificacin de las
personas interesadas:

Patrocinadores
Clientes
Usuarios
Especialistas
Ingeniero de requerimientos
Determinar el alcance:
Dominios y Contexto

Los dominios de inters son los

que influyen en el sistema que se
esta por estudiar
El dominio de la aplicacin
simular hasta cierto punto a los
dominios de inters.
Diagrama de contexto:

Por cada sistema adyacente se dibujan

interfases para identificar su relevancia en el
estudio.
Los sistemas adyacentes se derivan de los
dominios de inters que interactan con el
dominio de aplicacin.
Las interacciones deben ser comprensibles.
(graf)
 (cont.)
El contexto incluye todo lo que se debe saber para
construir el sistema.
El producto es la parte del contexto sobre la cual
tenemos control para adaptar / cambiar
Los sistemas adyacentes son las fuentes de
conocimiento sobre los dominios de informacin
Los sistemas adyacentes tienen conexiones con el
contexto. Es importante entenderlos para entender las
caractersttcas de las conexiones.
El contexto contiene polticas de procesamiento y
datos almacenados
Estimado inicial de costo/esfuerzo

Primera medicin del tamao del sistema:

Nmero de sistemas adyacentes
de dominios,
entradas y
salidas.
 Primer anlisis de riesgos

Identificar los riesgos ms probables para el

proyecto
Estimar el costo / impacto si el riesgo se vuelve un
problema
Identificar las seales que indiquen que el riesgo
se est volviendo un problema
La intencin es balancear los beneficios con sus
riesgos
Un riesgo no forzosamente es algo malo.
Evaluacin y toma de decisin de seguir
adelante

En base a lo anterior se analiza si:

Los objetivos son viables y medibles?
Son factibles?
Son los riesgos demasiado altos?
Es el costo de los objetivos razonable?
Las personas implicadas estn de acuerdo y
dispuestas?
Se justifica el proyecto?
Hay razones para cancelarlo?
Recoleccin de
Requerimientos
En esta etapa se deben
Extraer los requerimientos de los
usuarios
Descubrir el mayor nmero posible

de requerimientos
Utilizar diferentes mtodos para

los requerimientos conscientes,

inconscientes y los no-imaginados
Mtodos para la recoleccin de
requerimientos
Aprendiz
Escenciales
Entrevistas
Herramientas
Mapas Mentales
Lluvia de ideas

Particionamiento del contexto

Identificacin de eventos y Casos

de uso
Uso de Video
 Aprendiz:
El desarrollador se vuelve en el aprendiz de
usuario, aprende su trabajo por observacin y
preguntando.
La gente no siempre esta consciente de todas
las tareas que realiza
"Nadie describe mejor lo que hace y por qu lo
hace, que cuando lo esta haciendo."
[Beyer&Holtzblatt]
El aprendiz demuestra lo aprendido hacindolo
bajo la supervisin del usuario.
Aprendiz (continuacin)
El usuario generalmente no tiene
tiempo para entrevistas
El aprendiz ve la misma tarea
repetidamente
Captura de eventos en tiempo real
Retroalimentacin inmediata
Establece una relacin con los
usuarios y clientes
Requerimientos escenciales

Diferencia entre la implementacin

actual y el requerimiento escencial
Estan presentes
independientemente de la
tecnologa
Buscar al contenido de
informacin, no el medio.
Entrevistas

Ir a ellos para entrevistarlos en su

lugar de trabajo
Explicar la razn de la entrevista
Entrevistar primero al usuario ms
experimentado
Preguntar, escuchar la respuesta y
retroalimentar lo entendido
Entrevistas (cont.)

Dibujar modelos, utilizar la

terminologa del usuario
Guardar ejemplares de
documentos/artefactos
Agradecer al usuario su tiempo
Bsqueda de fallas potenciales: el
requerimiento es la falla
establecida de forma positiva.
 Lluvia de Ideas
El grupo de desarrolladores se reune para una
lluvia de ideas
Muchas ideas, ideas nuevas, toda idea es
buena
No deben evaluarse, debatir ni criticar
No limitarse por lo posible
Luego la lista de ideas es evaluada, ordenada
(votacin)
-> 60 ideas locas pueden contener 5 ideas
geniales.
Particionamiento del contexto

El contexto se divide entre los participantes

en unidades discretas (desde el punto de
vista del usuario)
Eventos distinguibles
Casos de uso
 Identificacin de eventos y
Casos de uso
Los eventos se identifican por las
entradas y salidas del trabajo
Los eventos son:
algo que sucede fuera del trabajo y a
lo que el trabajo debe responder.
Importante
Reconocible.
 Casos de uso:
Porcin de actividad: respuesta a un
estmulo externo o temporal
Coleccin nica de procesos y datos para
cada evento/ caso de uso
La respuesta es contnua
Cada proceso se puede describir
 Casos de uso (cont.)

Cada evento/caso de uso tiene un nmero de

requerimientos funcionales y no-funcionales
Algunos requerimientos no-funcionales se
aplican a todo el evento
Utilcense los eventos como puntos de partida
para determinar los requerimientos,
observaciones y entrevistas.
 Uso de Video
Grabar en video a los participantes y
desarrolladores durante las sesiones de
brainstorming y talleres de casos de uso.
Grabar las entrevistas y observaciones en el
trabajo.
Grabar a los usuarios durante su trabajo (ellos
describen cmo lo realizan).
Registro detallado de las prcticas de los usuarios
Grabar cada evento/caso de uso.
Los videos son una ayuda en la bsqueda de
requerimientos.
Tipos de Requerimientos

Restricciones globales
Requerimientos Funcionales
Requerimientos No-Funcionales
 Restricciones globales
Afectan a todo el producto y son determinadas por
el usuario y los que administran el
proyecto/producto.
1. Propsito del sistema
2. El cliente
3. El usurio
4. Convenciones para la nomenclatura y las
definiciones
5. Hechos relevantes
6. Restricciones del proyecto
7. Suposiciones
Requerimientos Funcionales
Lo que el producto debe hacer
8. Alcance del sistema
9. Requerimientos Funcionales y de datos
 Requerimientos No-Funcionales

Apoyan a las funciones, son las propiedades que

el producto debe tener.
10. Apariencia y sensacin
11. Usabilidad
12. Performance
13. Operabilidad
14. Mantenibilidad
15. Seguridad
16. Requerimientos Polticas
17. Requerimientos legales
 Otros temas importantes:
Puntos que salen eventualmente durante el
proyecto
18.Discusiones abiertas
19. Soluciones comerciales
20. Problemas nuevos
21. Tareas
22. Cutover
23. Documentacin del usuario
24. Sala de espera
 Registro de los requerimientos:
Para manejar los requerimientos, estos deben
tener:
Un nmero nico de ID
Tipo
Lista de los eventos y casos de uso que lo
contienen.
Descripcin: una frase que describe la intencin
del requerimiento.
Propsito: Por qu se considera importante?
Fuente: Quin determin este requerimiento
Registro de los requerimientos (cont.)

Criterio de evaluacin: Prueba no-ambigua que

indica si una solucin cumple este requerimiento
Satisfaccin del cliente: Grado de satisfaccin si
el criterio se cumple exitosamente (1=no importa
mucho-5=muy satisfecho)
Insatisfaccin del cliente: Grado de insatisfaccin
si el criterio no se cumple (1=no importa mucho-
5=muy molesto)
Registro de los requerimientos (cont.)

Dependencias: requerimientos que usan la

misma informacin o que ocasionan cambios.
Conflictos: requerimientos que estan en
conflicto con este
Materiales de apoyo: Indicacin a las
definiciones y documentos que lo ilistran.
Historia: Creacin, cambios y eliminacin
 Requerimientos Funcionales
Describir una accin que debe realizar el producto
No escribir soluciones
Cada evento/caso de uso tiene muchos requerimientos
funcionales
Algunos son parte tambin de otros eventos
Iniciar descomponiendo los casos de uso en pasos:
serie de pasos para completar el trabajo de un caso de uso
Acciones que puede reconocer el usuario
Posiblemente una interaccin entre usuario y mquina
nmero limitado de pasos

El uso del formato ayuda para determinar qu tan completa est la

especificacin de requerimientos.
Requerimientos Funcionales

Identificacin de los requerimientos:El darles un nmero

nico de identificacin permite recuperarlos y relacionarlos
con mayor facilidad.
Un requerimiento puede estar relacionado a varios eventos
Requerimientos globales se relacionan a todos los eventos
Utilizando los formatos para escribir requerimientos (pre-
definidos por la empresa), la informacin obtenida, las listas
de eventos y casos de uso conforman una vez terminadas
la especificacin de requerimientos.
Restricciones:

Restricciones globales son las propiedades que

aplican a todo el producto
Esta parte de la especificacin probablemente ser
escrita por la administracin del proyecto.
Propsito del sistema
El cliente para el producto
Usuarios del producto
Convenciones de nomenclatura y definiciones
Hechos/datos relevantes
Restricciones del proyecto
Suposiciones
 Restricciones (cont.)

Para las convenciones de nomenclatura se sugiere el uso de los

diccionarios estndar nacionales/internacionales para la industria
Buenos nombres son fcilmente distinguibles y no requieren muchas
explicacin.
Cada nombre deber tener una definicin.
Deben definirse todas las abreviaturas, trminos y siglas.
Hechos / datos relevantes: Estan confomados por fuerzas, sistemas,
actividade del mundo externo que pueden tener efecto en el producto.
Se identifican cambios que deben tomarse en consideracin.
Cambios probables en las fronteras del producto.
Cambios tecnolgicos, a otros productos, en la estructura organizacional, al
sistema legal, polticas, etc.
Restricciones del proyecto:

Tecnolgicas, de presupuesto, tiempo, etc. razones

por las que se restringe la manera en que se crea el
producto.
Siempre indagar el por qu de estas restricciones y
anotar todas las restricciones y sus razones para el
producto.
 Requerimientos No-Funcionales

Describen las propiedades o caractersticas que el producto debe

tener.
Cada requerimiento funcional tiene asociados requerimientos no-
funcionales
Algunos pueden afectar a nivel de eventos, otros a todo el producto.
Requerimientos no-funcionales:
Apariencia y sensacin: (Bosquejos)

Usabilidad: Depende de la definicin de los usuarios,

cuantificable por los criterios de evaluacin.

Performance: Requerimientos reales del performance, velocidad,

presicin, disponibilidad, seguridad, nivel de servicio, volmenes

de datos, etc.
Operacional: Ambiente en el que el usuario operar el producto y

productos con los que colabora.

 Requerimientos no-funcionales
Mantenibilidad: Tiempo esperado y tiempo permitido para
realizar cambios de mantenimiento, portabilidad.
Seguridad: requerimientos para permitir el acceso, pruebas de
integridad para prevenir mal -uso no intencionado por usuarios
autorizados, auditoras para detectar mal-uso, recuperacin
despues de un error, prueba de integridad despus de un hecho
anormal. Considerar involucrar a un experto en seguridad.
Polticas: Factores que podran hacer al producto inaceptable
por razone polticas, este requerimiento puede no ser medible,
puede ser especificado como restriccin.
Aspectos legales: Examinar sistemas adyacentes, considerar
sus requerimientos y derechos legales, cite leyes relevantes al
producto, contar con el apoyo de abogados, restriccione
impuestas por estndares.
 Verificacin y Validacin de
Requerimientos

Prevenir la infiltracin de requerimientos: los que entran

al producto depus del proceso de anlisis de
requerimientos.
Prevenir la fuga de requerimientos: aquellos cuya fuente
se desconoce
Estos incrementan desmesuradamente el costo y el
tamao del producto.
Se pueden usar mtricas de funcin para controlar la
infiltracin de requerimientos.
El nmero de function points puede ser una medida para
limitar el tamao del desarrollo.
 Quality Gateway (Calidad de
puerta de enlace)
Evaluacin de los requerimientos
Para incluirlos en la especificacin cada requerimiento debe pasar el
umbral de calidad.
Sirve para prevenir la infiltracin y la fuga de requerimientos.
Para pasar debe :
Tener un criterio de evaluacin
Tener una identificacin nica y referencias a los eventos y casos
de uso
Ser relevante
Ser viable
Tener un valor para el cliente
No ser adorno
Estar completo
Usar la tecnologa correcta
Los requerimientos rechazados se regresan al interesado
Ser mantendr una lista de requerimientos rechazados y la razn
Criterios de Validacin

Es una meta numrica que la solucin debe

cumplir.
No se puede disear una solucin a un
requerimiento sin una manera de saber si se ha
logrado resolverlo o no.
Para los requerimientos funcionales el criterio
especifica cmo establecer si cumple sus
objetivos.
Para los requerimientos no-funcionales
cuantifican el comportamiento resultante.

Tipo de requerimiento
10. Apariencia y sensacin
11. Usabilidad
12. Performance
13. Operabilidad
14. Mantenibilidad
15. Seguridad
16. Requerimientos Polticas
17. Requerimientos legales
Mtricas
Escalas de evaluacin
Cumple con el estndar?
especificar quin/cmo probarlo
Tiempo requerido para aprender
Tiempo de entrenamiento
Realizacin de funciones en tiempo
planteado
Tiempo para completar la accin
Cuantificacin del tiempo/facilidad de uso
Tiempo permitido
Esfuerzo requerido para portarlo
Cuantificar quin ha tenido acceso
Quin los acepta (no son cuantificables)
Opinin del abogado
 Prueba de los criterios

Cumple con los objetivos y la intencin del

producto?
Provoca el comportamiento correcto?
Puede ser probado?
Las pruebas son eficientes (costo)?
Es subjetivo el criterio?
Esta definida la terminologa?
Es ambiguo?
Pruebas de Relevancia

Se encuentra dentro del contexto

del proyecto?
Cumple con las restricciones
globales y el plan estratgico del
producto?
Es consistente con el producto?
 Pruebas de viabilidad

Los usuarios son capaces de usar el producto?

Tenemos la habilidad tecnolgica para construir
el producto?
Se tienen los medios y el tiempo para ello?
Es aceptable a todos los interesados?
Se puede hacer de manera eficiente?
Cules son las consecuencias del
requerimiento?
Prototipos y Modelado de Situaciones

Por qu usar prototipos?

Algunos requerimientos no son obvios o no estn
completos
Algunos usuarios tienen dificultades para formular sus
deseos
Algunos desarrolladores tienen dificultades para
entender los que se est pidiendo
Darles a los usuarios la oportunidad de "usar" el
requerimiento
Determinar la factibilidad o necesidad del requerimiento
Permite encontrar mas requerimientos escondidos.
 Situaciones

Prototipos son generales, situaciones son especficas

Situaciones: relatos que ilustran acciones para un caso
especifico
Cada situacin debe tratar un punto especfico
Trata un (o parte de uno) evento / caso de uso a la vez
Esclarecen implicaciones de un requerimiento
Ayudan a encontrar requerimientos faltantes
Utilizar medios flexibles (texto, figuras, modelos)
Prototipos de baja fidelidad

Baratos
No requiere habilidades de programacin
Util medio de comunicacin
Identifica mercado y requerimientos de
usuario
Genera ideas de funcionalidad
Demostracin general del funcionamiento del
producto
Construccin de un prototipo
de baja fidelidad

Se hace en una etapa temprana en el ciclo de

desarrollo
Restringir el prototipo a las tareas ms
comunes
La meta es evaluar alternativas-no invierta
mucho ego
Enfoque de brocha ancha
Enfoque en aspectos del producto no del
prototipo
 Prototipos de alta fidelidad
Navegacin y flujo
Interactivo
Demostracin fiel del comportamiento
Provoca el surgimiento de requerimientos de usabilidad
Pretenden ser como el producto final
Completa funcionalidad de la interfaz
"La interfaz es el producto"
Exploracin interactiva de las funciones del producto
Se realiza junto con una especificacin escrita
Sin embargo es un prototipo desechable
No hay compromiso de entregar exactamente la misma
interfaz
Reutilizacin de Requerimientos
Reutilizacin de Requerimientos

Generalmente los sistemas no son completamente nicos

en todos sus componentes
Hay oportunidad de reutilizar requerimientos
Aunque puede ser difcil reconocer los componentes
reusables
Con la ayuda de abstraccin y el uso de patrones re
requerimientos es mas fcil
Patrones: guas reusables que se pueden adaptar a
circunstancias especficas, se pueden abstraer de
cualquier tipo de sistema.
Estos patrones se pueden basar en los casos de uso.
 Ejemplo:
Un patrn de requerimientos contiene el nombre del patrn, una
descripcin del contexto, las razones o fuerzas que mandan este
requerimiento, la solucin y una lista de patrones relacionados.
Esto se acompaa de un diagrama de contexto, especificacin,
diagramas de los sub-patrones, modelos de datos y definiciones
de datos.
 Para que los patrones se puedan reutilizar es necesario
abstraerlos.
Existen diversos niveles de abstraccin.
Primero hay que encontrar el patrn:
Buscando similitudes entre cosas aparentemente diferentes.
Usar: palabras clave, nombres de procesos y polticas, entradas
y salidas de procesos, eventos / casos de uso, topologa,
nombres de flujo de datos, almacenamientos y sus contenidos.
Analizar el dominio (area de aplilcacin) y encontrar
caractersticas generalizadas dentro del dominio, identificar y
especificar objetos y operaciones comunes, modelando el
dominio.
 Revisin de requerimientos
Despus de escribir la especificacin de requerimientos se
debe realizar una revisin, para asegurar la calidad y
completez de la especificacin
Hasta este punto los requerimientos individuales ya pasaron el
punto de control de calidad (quality gateway).
La revisin de la especificacin busca requerimientos
faltantes, checa consistencia, conflictos y ambigedad.
Uso de un filtro de requerimientos (conjunto de reglas para
determinar si los requerimientos van conforme a la
especificacin.
Anlisis de riesgos
Determinar el esfuerzo contando function points por cada
evento/caso de uso
 Revisin (cont.)

Determinar el valor para el cliente (suma de los valores de

satisfaccin del cliente)
Mantener una base de datos de los requerimientos
rechazados
Realizar un post-mortem al proceso de requerimientos

El proceso de revisin es iterativo hasta que se resuelven

todas las inconsistencias, conflictos y ambigedades.
 Post-Mortem

El objetivo es aprender del proyecto.

Revisar la eficiencia de les tcnicas de requerimientos
utilizadas
Qu aspectos deberan hacerse de manera diferente?
Usar un evaluador ?
Buscar los principales errores (sin buscar culpables)
Buscar los principales xitos (sin premiar a nadie)
Escribir un reporte que se distribuye entre los miembros
del equipo y administracin.
 Modelado de Requerimientos
Modelos de Contexto
Diagrama de contexto: Punto de partida para todo modelado
Representa al sistema y sus conexiones al mundo exterior.
contienen: sistema, sistemas adyacentes y la
informacin que provee cada uno o los datos que flujen entre
el sistema y cada uno de los sistemas adyacentes.
Cada proceso se escribe dentro de un crculo que recibe
datos, transfiere datos a otro proceso o sistema adyacente o
los almacena, su nombre refleja el proceso que realiza.
Almacenes de datos se dibujan con dos lneas paralelas
horizontales.
Por convencin no se muestran flujos de 'tiempo'
 IDENTIFICACIN DE EVENTOS
A partir del diagrama de contexto se pueden
identificar los eventos.
Se listan junto con sus datos asociados.
En el diagrama de contexto nos enfocamos al
objetivo (scope) del sistema identificando los flujos
de datos alrededor de los lmites del sistema.
Pero es difcil obtener un diagrama de contexto 100%
completo desde el principio - sin embargo es un
comienzo-se encuentra lo relevante y lo escencial.
 Modelado de Datos
Confirma y ayuda a completar el diagrama de
contexto.
Se utiliz la descripcin del negocio para construir el
contexto. Tambin es la fuente de informacin para
identificar entidades y sus relaciones.
Para ello se toman en cuenta diferentes puntos de
vista (Viewpoints) ya que ayudan a distinguir
diferentes aspectos del negocio.
 Puntos de Vista
Punto de vista del estado actual : Analiza la
situacin actual del proceso (necesario para
entender el negocio), documenta la realidad
existente.
Punto de vista escencial: es la visin perfecta del
sistema, slo muestra requerimientos y excluye todo
lo que existe actualmente slo por la manera en que
se implementa el sistema.
Punto de vista de datos: Representado con el
modelo de datos, ignora los procesos y se concentra
en modelar la informacin escencial del sistema.
Punto de vista de Datos
(Data Viewpoint)
El modelo de datos es una abstraccin
Muestra la informacin almacenada por el sistema
Descarta procesos que usan la informacin y la
manera en que se implementa
Se ven slo los datos reales, no cmo se organizan
por conveniencia de cierto tipo de base de datos
 Modelos de Datos
Tambin se conocen como los modelos entidad-relacin
Entidades: Coleccin de atributos que describen algo, real o
abstracto, que es importante para el sistema.
La abstraccin depende del punto de vista/dueo del sistema
Tienen un propsito definible
Tiene muchas instancias, un slo identificador
Atributos: Datos acerca las entidades y relaciones
Pertenecen a slo una relacin/entidad
Tienen un valor
No tienen un orden, pero las principales se escriben primero
Se pueden derivar
El mismo tipo de atributo en diferentes instancias de una
entidad no debera tener el mismo valor
 Modelos de Datos(cont.)

Relaciones: Asociaciones entre entidades

Pueden tener atributos
No tiene direccin
Se nombran utilizando verbos hechos sustantivos
Cardinalidad: Muestran cuantas instancias de cada entidad pueden
participar en una instancia de relacin.
cardinalidad
1 N
Cliente solicita Catlogo

entidad relacin entidad

 Modelos de Datos(cont.)

Diccionario de datos: Todos los flijos de datos se

describen en el diccionario de datos, as como todas
las entidades.
nombre_flujo_dato = *comentario* dato1+dato2+...
nombre_entidad = nombre_registro + fecha_registro +
compaa_registradora
opcionales (a)
repeticiones {a}
seleccionar uno [a | b ]
*comentario*
 Diagramas de Flujo de Datos
Construir modelos funcionales (que funcionan)
Cada proceso debe recibir datos suficientes y
necesarios
El modelo excluye todo tipo de mecanismos
Slo modela al sistema que contiene datos y
requerimientos funcionales.
Flujos de datos compuestos se unen con un signo +:
dato1 + dato2
Flujo de datos: representan el movimiento de datos de
un lugar a otro
Datos no pueden ir directamente de una base de
datos a un terminal o viceversa.
 Diagramas de Flujo de Datos
El diagrama del contexto se partiociona.
El mejor particionamiento es el que resulta en las
interfaces mas estrechas -> dnde hay slo un
mnimo nmero de datos conectando al proceso con
otros.
Todas las burbujas y los flujos de datos deben tener
nombres representativos (evitar algo como D1, D2)
Se numeran para su identificacin -> no indican
secuencia de procesamiento.
Deben tener entrada y salida de datos
DFDs de sistemas complejos se dividen en niveles.
 Modelos de Eventos
Descomposicin en eventos:
Partir un problema grande en partes pequeas
Particiones naturales con mnimas conexiones a otras partes, con
fronteras claras y cuantificables y encontrando usuarios que son
expertos para esa parte.
Una respuesta de un evento es iniciado por un evento del exterior del
sistema o por el paso del tiempo.
Un sistema responde a eventos
El caso de uso es el alcance de la respuesta limitado por los sistemas
adyacentes y bases de datos: coleccin nica de procesos y datos que
responden a cada evento
la respuesta es contnua (en tiempo)
cada proceso se puede describir
los datos se pueden definir por cada evento
luego se modelan:
 Modelos de Eventos(cont.)
Reglas para los eventos:
El sistema puede identificar el flujo de datos accionador y sabe
cmo responder
Eventos temporales se dan cuando es hora para que el sistema
haga algo, pero la hora de hacerlo puede ser determinada por un
sistema adyacente.
El evento se puede reconocer como un evento del sistema
La respuesta es nica para dado flujo de datos accionador
Un mismo sistema adyacente puede accionar diferentes eventos
La respuesta es contnua y se detiene con la escritura de datos a
almacenamiento y el envo de las salidas a los sistemas
adyacentes
Una entidad fsica puede ser un sistema adyacente para un
evento y parte de un proceso para otro evento.
 Modelos de Eventos (cont.)

Nomenclatura:
para eventos externos: [nombre del sistema adyacente]
+razn por la cual enva el flujo de datos al sistema
para eventos temporales: [Hora de producir]+ nombre del
flujo de datos o razn por la cual se enva el flujo de datos
al sistema adyacente
Cada evento se trata como un caso de uso
Cada evento es modelado
Cada evento es bien conocido por un usuario
Es conveniente numerar los eventos
Cada respuesta a estos eventos se modela tambin.