Especificacin y Anlisis de Requerimientos

Dra. Ingrid Kirschning UDLA-P

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 es un Concepto?
Ciclo de vida V Why? Concepto What? Anlisis
Verificacin y Validacin Pruebas acept.

Pruebas integ.

How?

Diseo
Do! Cdigo

Pruebas unit.

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 Prototipos

de requerimientos

Verificacin
Revisiones

y validacin

Post-Mortem

Preparacin para el inicio del proyecto

Blastoff

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 el 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

Mind Maps Brainstorming 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.

Brainstorming

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 mucho5=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 (predefinidos 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 nofuncionales 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

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.

Mtricas
Tipo de requerimiento 10. Apariencia y sensacin 11. Usabilidad 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

12. Performance 13. Operabilidad 14. Mantenibilidad 15. Seguridad 16. Requerimientos Polticas 17. Requerimientos legales

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 restrucciones 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 intersados? 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
Cliente
1

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.