Requisitos de software: conceptos, tipos y propiedades

Tema 1
Requisitos de Software:
Conceptos, Tipos y Propiedades

Tema 1: Requisitos: Conceptos, Tipos y Propiedades
• El Modelado de Negocios (MN) y la Ingeniería de Requisitos
(IR) son dos sub-disciplinas de la Ingeniería de Software (IS)
– La primera – MN - está relacionada con el estudio del espacio del
problema en IS
– La segunda –IR- está asociada al problema de los requisitos y al
espacio de la solución
• Cuando se aplican al desarrollo de software como procesos,
el MN precede a la IR
3
Modelado del
Negocio
Ingeniería de
Requisitos

Tema 1: Requisitos: Conceptos, Tipos y Propiedades
• Una vez modelado el sistema de negocio
donde se ubicará la aplicación, el proceso de
Ingeniería de Requisitos se encarga de:
– Especificar las características de la aplicación
– Establecer los requisitos funcionales y no-
funcionales que la aplicación debe satisfacer
4

¿Qué es un requisito de software?
• Perspectiva del usuario
– Un requisito es una condición o capacidad de la aplicación
(o sistema de software) que necesita un usuario para
resolver un problema o alcanzar un objetivo
• Perspectiva del desarrollador:
– Es una condición o capacidad que debe ser satisfecha o
poseída por la aplicación, a fin de satisfacer un contrato,
estándar, especificación u otro documento formalmente
impuesto
• En ambos casos, es una representación documentada
de una condición o capacidad que debe mostrar la
aplicación en desarrollo
5

¿Qué es un requisito de software?
• Los requisitos expresan lo que una aplicación
debe hacer para satisfacer necesidades de
información de su dominio
– Este dominio puede ser:
• Un sistema hardware/software
– Dispositivo electrónico
– Celular
– Procesador dedicado, etc.
• Un sistema de negocios
– Empresa
– Unidad organizacional
– Proceso de negocio, etc.
6
Sistema de Negocios
Sistema H/S
Aplicación

Requisitos de software
• Los requisitos definen:
– Lo que la aplicación debe hacer
• Funciones que debe ejecutar
• Datos que debe capturar y almacenar
• Información que debe producir
– Las interacciones usuarios-aplicación y aplicación-aplicación
• Interfaz gráfica usuario-aplicación (GUI)
• Interfaz de la aplicación con otras aplicaciones o sistemas
– Las restricciones bajo las cuales la aplicación debe operar
• Plataforma de operación de la aplicación(Hardware/Software)
• Tecnología de información que debe usar
– Los atributos de calidad que la aplicación debe satisfacer
• Seguridad, facilidad de uso, documentación, utilidad, etc.
7

Requisitos de Software
• Clasificación de los requisitos [Wiegers, 2003]
8
Requisito
Requisito
Funcional
Requisito
No-Funcional
Requisito del
Negocio
Requisito del
Usuario
Requisito del
Sistema
Requisito de
Comportamiento
Restricción Atributo de
Calidad
Requisito de
Interface
Regla del
Negocio

NO-FUNCIONALES
– No están relacionados
directamente con el
comportamiento de la
aplicación
– Restringen el diseño de la
aplicación (la solución)
• Establecen las limitaciones
para su desarrollo
– Definen la calidad que la
aplicación debe tener
FUNCIONALES
– Establecen:
• los objetivos del negocio
con respecto a la aplicación
• los servicios que la
aplicación debe
proporcionarle al negocio
– Determinan la funcionalidad
de la aplicación
• Qué funciones debe
ejecutar la aplicación
Tipos de requisitos de software
9

NO-FUNCIONALES
– Describen:
• las restricciones que se le
imponen a la aplicación
• las cualidades o atributos
de calidad que la
aplicación debe satisfacer
• Las reglas del negocio que
la aplicación debe respetar
o implementar
• Las interfaces con otros
sistemas
FUNCIONALES
– Describen lo que la
aplicación deberá hacer, esto
es:
• Su comportamiento
• Su interacción con los
usuarios y su dominio de
aplicación (negocio)
• Sus respuestas a eventos
Diferencias entre los tipos de requisitos
10

Tipos de Requisitos Funcionales
• Requisitos del Negocio
– Se expresan desde la perspectiva de la empresa:
• Describen porque la empresa o el cliente desea
desarrollar la aplicación
• Expresan que objetivos, metas o necesidades la
empresa espera alcanzar con el uso de la aplicación
11

• Requisitos del Usuario
– Se expresan desde la perspectiva del usuario:
• Describen las necesidades que los usuarios tienen y las
tareas que los usuarios realizarán con la aplicación
• Expresan lo que el usuario será capaz de hacer con la
aplicación
– Se modelan mediante casos de uso
– Ejemplos:
• Hojear la mapoteca digital
• Visualizar un mapa
• Comprar un mapa
12

• Requisitos del Sistema
– Están asociados a productos que tienen componentes
de hardware y software
– Asumen que la aplicación es parte de un sistema
mayor, p.ej.:
• Videojuegos, equipos de audio, etc.
• Sistemas de información gerencial
• Sistemas de control (Ej. Sensores/actuadores)
– Ejemplos de requisitos del sistema:
• El sistema de control deberá disparar una alarma cada vez
que el sensor detecte una presión fuera del rango
permisible
• La interfaz del celular debe bloquearse cada vez que el
usuario presione simultáneamente el botón “Llamar” y la
tecla *
13

• Requisitos de Comportamiento
– Se expresan desde la perspectiva del desarrollador:
• Son requisitos funcionales propiamente dichos
• Describen los servicios que la aplicación presta a todos sus
usuarios directos
• Expresan que hace la aplicación bajo ciertos estímulos o
eventos (comportamiento del sistema)
– Ejemplos:
• mimapa.com deberá permitir que el cliente efectúe el pago
de su pedido en línea usando tarjetas de crédito o un
sistema de pagos en línea (Ej. paypal)
• El sistema debe permitirle al usuario visualizar el mapa
seleccionado por el usuario de aquellos contenidos en el
catálogo de mapas
14

Tipos de Requisitos NO-Funcionales
• Restricciones:
– Expresan las limitaciones que se le imponen al desarrollo
la aplicación
– Describen aspectos tales como:
• Plataforma de desarrollo y operación (H/S)
• Uso de estándares, prácticas, métodos de desarrollo,
herramientas, etc.
• Tiempo máximo de desarrollo
• Costo máximo del proyecto
– Ejemplos:
• mimapa.com debe ser desarrollada:
– Bajo una plataforma LAMP: Linux, Apache, MySQL y PHP
– En un tiempo no mayor a seis meses
– Con costo no superior a los Bs.F 300.000
15

• Atributos de calidad
– Son las cualidades o propiedades de calidad que
la aplicación debe satisfacer, por ejemplo:
• El rendimiento que la aplicación debe mostrar
• La confiabilidad que debe poseer
• La seguridad que debe proveer
• La utilidad que debe garantizar
– La calidad de una aplicación se mide en función
de sus atributos de calidad
16

• Atributos de calidad
– Para facilitar su medición durante la verificación,
deben expresarse cuantitativa o cualitativamente
• Ejemplo:
– mimapa.com debe tener una confiabilidad igual o mayor al 95%
– Los atributos cualitativos se miden usando escalas
cualitativas, tales como la Escala de LIKERT
– 1: muy bajo, 2: bajo, 3:medio, 4: alto, 5: muy alto
• Ejemplo:
– mimapa.com debe ser fácil de usar:
» Debe medir un mínimo de 4 puntos en una escala de 5
puntos
17

18
Atributos de Calidad del Software (según norma ISO 9126)
Atributos de
Calidad del
Software (ISO
9126)
Funcionalidad
Utilidad
(Usability)
Confiabilidad
Eficiencia
Portabilidad
Mantenibilidad

• Atributos de Calidad asociados a la Funcionalidad
• Grupo de atributos que permiten calificar si una aplicación maneja
adecuadamente las funciones para las cuales fue diseñada
– Adecuación:
• Capacidad de la aplicación para realizar funciones apropiadas a las tareas
o procesos del negocio que ejecutan los usuarios
– Interoperabilidad:
• Habilidad de la aplicación para interactuar con otros sistemas o
aplicaciones
– Seguridad:
• Habilidad de la aplicación para prevenir el acceso no autorizado
(accidental o premeditado) a sus programas y datos
– Conformidad:
• Evalúa si la aplicación se adhiere a estándares y regulaciones establecidas
19

• Atributos de Calidad asociados a la Confiabilidad
• Miden la capacidad de la aplicación para mantener un nivel
de rendimiento aceptable bajo condiciones normales y en
un tiempo establecido
– Nivel de Madurez:
• Mide la frecuencia de fallas ocasionada por errores en el
software
– Tolerancia a fallas:
• Habilidad de la aplicación para mantener un nivel específico
de funcionamiento en caso de fallas
– Facilidad de Recuperación:
• Habilidad de la aplicación para restablecer su nivel de
operación y recuperar sus datos ante una falla
20

• Atributos de Calidad asociados a la Utilidad
• Permiten evaluar el esfuerzo que los usuarios invierten en
utilizar el sistema
– Comprensibilidad:
• Capacidad que tiene la aplicación para que sus usuarios
reconozcan la estructura lógica de la aplicación y los
conceptos relativos a ella
– Facilidad de Aprendizaje:
• Capacidad que tiene la aplicación para que sus usuarios
aprendan a usarlo
– Operatividad:
• Capacidad de la aplicación para que sus usuarios la operen y
controlen
21

• Atributos de Calidad asociados a la Eficiencia
• Evalúan la relación entre el nivel de funcionamiento de la
aplicación y la cantidad de recursos utilizados
– Uso de recursos:
• Mide la cantidad de recursos usados y la duración de su uso
durante la ejecución de sus funciones
– Rendimiento:
• Especifican qué tan bien o tan rápido debe la aplicación
ejecutar una función dada en términos de:
– Velocidad (tiempo promedio de acceso a datos)
– Volumen de transacciones por minuto
– Capacidad (carga de uso concurrente)
– Tiempo (demanda de tiempo real)
22

• Atributos de Calidad asociados a la Mantenibilidad
• Permiten medir el esfuerzo requerido para mantener la
aplicación, bien sea debido a fallas o a mejoras
– Facilidad de Modificación:
• Capacidad que tiene la aplicación para que sus mantenedores
puedan:
– Modificar aspectos o funciones
– Adaptar la aplicación a un ambiente diferente
– Capacidad de análisis:
• Capacidad de la aplicación para diagnosticar deficiencias o
causas de fallas o identificar partes que han de ser modificadas
– Facilidad de prueba:
• Capacidad de la aplicación para permitir ser validada, una vez
modificada
23

• Atributos de Calidad asociados a la Portabilidad
• Miden la habilidad de la aplicación para ser transferida de
un ambiente (plataforma de operación) a otro
– Facilidad de Instalación:
• Habilidad de la aplicación para instalarse en su ambiente de
operación
– Adaptabilidad:
• Capacidad de la aplicación para ser adaptada a diferentes
ambientes de operación sin que se requiera modificarla más
allá de lo requerido
– Coexistencia:
• Capacidad de la aplicación para coexistir con otras
aplicaciones compartiendo recursos comunes
24

• Requisitos de interfaz
– Expresan las características de la interacción usuario-
sistema o sistema-sistema
– Se dividen en:
• Requisitos de interfaz gráfica (GUI):
– Describen las propiedades generales del interfaz gráfica que
permitirá la interacción entre el usuario y la aplicación
– Ej.: La interfaz de la aplicación mimapa.com debe ser
implementada usando tecnología web
• Requisitos de interfaces con otros sistemas:
– Describen con qué o cómo la aplicación interactuará con otras
aplicaciones de software o sistemas de hardware
– Ej.: mimapa.com deberá interactuar con el sistema de pagos en
línea paypal
25

• Reglas del negocio
– Expresan regulaciones que la aplicación debe acatar, p.ej.:
• Regulaciones gubernamentales:
– Leyes, decretos, providencias, etc.
• Regulaciones de la empresa:
– Políticas, normas, procedimientos, estrategias, etc.
• Regulaciones propias de la aplicación:
– Estándares y mejores prácticas de desarrollo que deben seguirse
– Algoritmos que deben usarse, etc.
– Ejemplos:
• mimapa.com debe elaborarse siguiendo el método de WATCH
adoptado por la empresa VECTOR C.A.
• Un cliente puede descargar gratuitamente las actualizaciones de
un mapa adquirido por el/ella durante los 12 meses siguientes a
su compra
26

Niveles de requisitos (adaptado de [Wiegers, 2003])
• Los requisitos tienen tres niveles asociados que
determinan su origen y los aspectos que ellos tratan
27
Aspectos de la
visión y alcance
del producto
Aspectos de diseño
del producto
Aspectos de uso del
producto
Requisitos No-funcionalesRequisitos Funcionales
NiveldelUsuarioNiveldelProductoNiveldelNegocio
Requisitos
del Negocio
Requisitos de
Usuarios
Requisitos
del Sistema
Requisitos de
Comportamiento
Reglas del
Negocio
Atributos de
Calidad
Requisitos de
Interfaces
Restricciones

Propiedades de los requisitos
• La calidad de los requisitos se mide por sus
propiedades:
– Cada requisito debe expresarse de una manera sencilla,
clara y sin ambigüedades, usando:
• Lenguaje natural (Español),
• Lenguajes gráficos (Ej. UML) o
• Lenguajes formales (Ej. Notación Z)
– Preferiblemente, debe expresarse de manera cuantitativa
• Uso de métricas que faciliten la verificación
– Debe identificarse de manera única e inequívoca
• Uso de un sistema de numeración para facilitar su búsqueda y
manejo
– Debe ser correcto
• Debe estar validado por el cliente
28

Propiedades de los requisitos
• Propiedades (cont.):
– Los requisitos deben ser consistentes entre sí
• No debe haber conflictos o incompatibilidad entre requisitos
– Deben ser completos
• Deben describir toda la funcionalidad que la aplicación deberá
implementar
– Cada requisito debe ser factible (realista o alcanzable)
– Debe describir algo que el cliente o usuario necesita
• Resuelve algún problema del cliente
– Debe ser verificable
• Deben medibles y sin ambiguedad
– Se le puede hacer un seguimiento a través de todo el
desarrollo del sistema
29

Tema 2
Los problemas de los requisitos y sus soluciones

Tema 2: Problemas de los requisitos y sus soluciones
• Los requisitos son elementos críticos y fundamentales
del desarrollo de software
– Requisitos incompletos, mal especificados e
inconsistentes conducen al fracaso de un proyecto
• Es importante analizar estos problemas para no caer
en el error de desarrollar una aplicación mal
fundamentada
• Los objetivos instruccionales de este tema son:
– Analizar los problemas que los requisitos presentan
durante el desarrollo de aplicaciones
– Describir las principales soluciones que la Ingeniería de
Software ha establecido para resolver estos problemas
31

Los problemas de los requisitos
• De acuerdo a una encuesta realizada por el
Standish Group, los principales factores que
afectan a los proyectos de desarrollo de software
son:
• Requisitos incompletos (13.1%)
• Falta de participación del usuario (12.4%)
• Falta de recursos (10.6%)
• Expectativas poco realistas (9.9%)
• Falta de apoyo gerencial (9.3%)
• Cambios en los requisitos y las especificaciones (8.7%)
• Falta de planificación (8.1%)
• El sistema dejó de ser necesario (7.5%)
32

• Requisitos mal definidos
– No reflejan las necesidades reales de los actores del proyecto
– Son inconsistentes
– Son incompletos
– No son factibles
• El costo de cambiar los requisitos crece a medida que avanza el
proyecto
33
Análisis Diseño Implementación Pruebas Operación
Costo
Fase del
Proyecto

• El usuario o cliente no siempre sabe lo que
quiere del sistema
– Al inicio del proyecto, el usuario no sabe que
esperar del sistema
– Los requisitos tienden a surgir en la medida que
el usuario se familiariza con:
• las tecnología TIC
• el sistema de información
34

• El usuario no tiene tiempo para participar en
el proyecto
– Evita participar en el proyecto
– No está consciente de la importancia de su
participación
– No ve al sistema como algo que le pertenece
35

• Problemas de comunicación
– El cliente o usuario no entiende el lenguaje informático de
los analistas
– Los analistas no entienden el lenguaje del dominio de la
aplicación
• Múltiples interpretaciones de los requisitos
– El analista entiende y especifica de manera diferente los
requisitos del cliente
– El diseñador interpreta de otra manera los requisitos
especificados por el analista
36

Soluciones a los problemas de los requisitos
• Ya hemos identificado los problemas de los requisitos,
ahora bien:
– ¿qué soluciones existen?
– ¿Cómo podemos enfrentar estos problemas?
• La Ingeniería de Requisitos (IR) es una sub-disciplina
de la Ingeniería del Software que se encarga de:
– estudiar los problemas asociados a los requisitos y
– proponer soluciones a estos problemas
• La IR establece métodos, modelos, técnicas,
herramientas, prácticas, entre otros para resolver los
problemas de los requisitos
37

• ¿Cómo resolver los problemas de los requisitos?
– Entender la naturaleza del software
• La naturaleza del software promueve cambios frecuentes en
los requisitos
– Entender el espacio del problema antes de analizar el
espacio de la solución
• Modelar el negocio antes de identificar y especificar
requisitos
– Utilizar un proceso de Ingeniería de Requisitos bien
definido y probado
• Este proceso debe describir como identificar, analizar,
documentar, verificar y gestionar requisitos
• Debe ser parte del proceso de desarrollo de software
38

• ¿Cómo resolver los problemas de los requisitos?
– Utilizar prácticas reconocidas (mejores prácticas),
p.ej.:
• Incorporar al usuario en el desarrollo de la aplicación
(participación activa)
• Modelar los requisitos usando notaciones gráficas
estandarizadas
• Gestionar los requisitos
– Emplear personal especializado que entienda los
problemas de los requisitos
• Analistas de Negocios
• Analistas de Requisitos
39

Espacio del problema vs. espacio de la solución
• Los métodos tradicionales de desarrollo de software
subestiman la importancia del problema y su análisis
– Se centran en la solución y sus requisitos
– Por lo que la solución, generalmente, no se alinea al
negocio
40

• La separación del
espacio del
problema y el de la
solución es crucial
en toda Ingeniería
• La Ingeniería de
Sistemas Físicos
establece una clara
separación entre
ambos espacios
41
Formulación
del problema
Diseño
de la solución
Selección de la
mejor solución
Búsqueda
de soluciones
Análisis
del problema
Implementación
de la solución
Espacio
del
Problema
Espacio
de la
Solución

– Las necesidades ocurren en el espacio del problema
– Los requisitos tienen lugar en el espacio de la solución
42
Modelado de
Negocios
Ingeniería de
Requisitos
Espacio de la
Solución
Espacio
del
Problema
Necesi-
dades
Aspectos
(Features)
Requisitos de Software
Procedimientos de Pruebas
Diseño Doc. del
Usuario
La
Solución
(software)
Adaptado de [Rational Requirements Management with Use Cases v5.5, 2000]
El Problema

• Relaciones entre el Modelado de Negocios (MN) y la Ingeniería de
Requisitos (IR)
– MN se encarga del espacio del problema (el sistema de negocios)
– Mientras que lR se encarga del espacio de la solución (la aplicación)
43
Modelado de Negocios
(el problema)
Objetivos Procesos Objetos Reglas Actores Eventos…
Ingeniería de Requisitos
(la solución)
Requisitos No FuncionalesRequisitos Funcionales

• El Modelo de las 6P
contribuye, también,
a resolver el
problema de los
requisitos
• Este modelo
identifica factores
críticos de éxito del
desarrollo de
software
44
Entender la
naturaleza del
software
Producto
Utilizar las
mejores
prácticas
Prácticas
Gestionar el
desarrollo
como un
proyecto
Proyecto
Usar un
proceso de
desarrollo efectivo
Proceso
Emplear
el mejor
personal
Personas
Problema Entender primero el problema
antes de modelar la solución

Mejores prácticas de Ingeniería de Requisitos
• La Ingeniería de Requisitos (IR) propone un conjunto
de mejores prácticas que han probado ser efectivas*
• Prácticas asociadas al conocimiento de la IR
– Capacitar a los analistas en los temas técnicos de la IR
– Educar a los Representantes de Usuarios y Gerentes en la
problemática y soluciones de los requisitos
• Concientizar sobre la necesidad de una IR
– Capacitar a los desarrolladores en el dominio de la
aplicación (sistema de negocios)
– Crear un glosario de términos del sistema de negocios
* Adaptado de Wiegers (2003)
45

• Prácticas asociadas a la Gestión de Requisitos
– Definir un proceso para controlar los cambios de los
requisitos
– Establecer un Comité encargado del control de cambios
– Llevar a cabo el análisis del impacto que cada cambio en
los requisitos tiene sobre el proyecto
– Establecer una línea base de requisitos y llevar control de
las versiones
– Mantener históricos de cambios en los requisitos
– Hacerle seguimiento a los requisitos
• Llevar las matrices de trazabilidad
– Medir la variabilidad de los requisitos
– Usar herramientas para gestionar requisitos
46

• Prácticas asociadas a la Gestión del Proyecto
– Seleccionar un ciclo de vida o método de desarrollo
apropiado
– Definir claramente el proceso de Ingeniería de
Requisitos
– Basar los planes en los requisitos
• Planes iterativos
– Renegociar los acuerdos de requisitos
– Manejar los riesgos de los requisitos
– Aprender de proyectos pasados (lecciones
aprendidas)
47

• Prácticas asociadas al Descubrimiento de
Requisitos
– Definir la visión y el alcance del producto
– Identificar los tipos de usuarios
– Identificar casos de uso
– Identificar los eventos y respuestas de la
aplicación
– Observar a los usuarios realizando sus actividades
– Reutilizar requisitos de otros proyectos similares
48

• Prácticas asociadas al Análisis de Requisitos
– Establecer el contexto de la aplicación
• Definir las relaciones entre la aplicación y su dominio o sistema
de negocios
– Crear prototipos
– Analizar la factibilidad de los requisitos
– Establecer las prioridades de los requisitos
– Modelar los requisitos
• Crear modelos funcionales, estructural y dinámicos
– Crear un diccionario de datos
• Definir los elementos contenidos en los modelos
– Asignar requisitos a los subsistemas de la aplicación
• Relacionar los requisitos con la arquitectura de la aplicación
49

• Prácticas asociadas a la Especificación de Requisitos
– Adoptar una plantilla para elaborar el Documento de
Requisitos
• Usar preferiblemente los estándares y adaptarlo a las necesidades
de su organización
– Identificar las fuentes de los requisitos
• ¿Quién propuso este requisito?
– Identificar cada requisito de manera única
– Registrar las reglas del negocio
– Especificar los atributos de calidad
• Usar modelos de calidad para seleccionar los requisitos apropiados a
la aplicación
• Especificar las métricas para medir los atributos
50

• Prácticas asociadas a la Validación de
Requisitos
– Inspeccionar el Documento de Requisitos (DR)
• Realizar la Revisión Técnica del DR
– Probar los requisitos
• Diseñar las pruebas funcionales basadas en los
requisitos
– Definir los criterios de aceptación
• ¿Qué criterios usará el cliente o usuarios para aceptar
la aplicación?
51

Tema 3
La Ingeniería de Requisitos:
Productos, Procesos y Actores

Tema 3: IR - Productos, Procesos y Actores
• La Ingeniería de Requisitos (IR) es una sub-
disciplina de la Ingeniería de Software
– Se encarga del estudio de los requisitos en
sistemas automatizados (H/S)
• La IR produce:
– principios, modelos, métodos, mejores prácticas,
técnicas y herramientas automatizadas que
contribuyen a mejorar la identificación, análisis,
especificación, validación y gestión de los
requisitos
53

La Ingeniería de Requisitos
• La IR se ubica, junto al Modelado de
Negocios, al comienzo de la cadena de valor
del desarrollo de software
Gestión del Proyecto: Alcance, Tiempos, Costos, Recursos y Contratos
Gestión de Riesgos
Gestión de la Configuración
Gestión de la Calidad
Modelado del
Negocio
Ingeniería de
Requisitos
Diseño
Arquitectónico
Programación &
Integración
Pruebas de la
Aplicación
Entrega de la
Aplicación
Diseño
Detallado
54

• La aplicación de la IR al desarrollo de una
aplicación conduce a:
– Encontrar y definir las necesidades que tienen los
interesados de la aplicación
– Transformar la definición de necesidades en una
descripción completa y precisa de requisitos,
denominada:
• Especificación de requisitos
– Lograr un entendimiento común, entre
clientes/usuarios y desarrolladores, de los
requisitos que debe satisfacer la aplicación
55

• Los tres elementos fundamentales de la IR:
56
Agreed
requirements
System
specification
System
models
Requirements
engineering process
Stakeholder
needs
Organisational
standards
Domain
information
Regulations
Existing
systems
information
El proceso:
¿cómo
hacerlo?
Los
productos:
¿qué se hace?
El grupo:
¿quienes
lo hacen?

Los Productos de la Ingeniería de Requisitos
¿Qué productos se elaboran
durante el proceso de
Ingeniería de Requisitos?
57

• Principales productos generados por el
proceso IR
«programa»
Prototipo de la
Aplicación
«documento»
Documento de Especificación
de Requisitos (DER)
«documento»
Documento de Definición de
Requisitos (DDR)
«documento»
Plan de Gestión de
Requisitos
«modelo»
Modelo Funcional (casos
de uso + descripciones
textuales)
«modelo»
Modelo Dinámico
(diagramas de actividad,
estado y/o secuencias)
«modelo»
Modelo Estructural
(diagramas de
componentes y de clases)
«documento»
Documento de
Requisitos
Producto IR
58

• El Plan de Gestión de Ingeniería de Requisitos
– Es un documento de gestión elaborado por el Líder
del Proyecto o el Líder del Grupo de Requisitos
– Describe detalladamente las actividades, tiempos,
costos y recursos requeridos en el proyecto para
realizar los procesos IR
• El Prototipo de la Aplicación
– Es un programa que exhibe la interfaz gráfica de la
aplicación y demuestra su funcionalidad
– Es elaborado para verificar:
• Los requisitos de los usuarios
• Los requisitos de interfaz gráfica
59

• El Documento de Requisitos (DR) debe describir:
– Los requisitos funcionales que debe cumplir la
aplicación
• Requisitos del negocio
• Requisitos de los usuarios (servicios que ofrece)
• Funciones de la aplicación y su comportamiento
– Los requisitos no-funcionales de la aplicación
• Reglas de negocio que debe implementar la aplicación
• Restricciones bajo las cuales deberá operar la aplicación
• Atributos de calidad que deberá cumplir la aplicación
• Interfaces con otros sistemas
– El dominio de la aplicación (sistema de negocios) y las
relaciones entre ambos
60

• El Documento de Requisitos (DR)
– Es un documento manual o electrónico que describe y
comunica los requisitos de la aplicación
– Es utilizado por dos tipos de audiencias:
• Clientes, usuarios y gerentes
• Desarrolladores de la aplicación
• Es, también, denominado:
– Especificación de Requisitos de Software (ERS)
– Especificación del Sistema (ES)
• Por lo general, se divide en dos partes:
– Documento o Sección de Definición de Requisitos (DDR)
– Documento o Sección de Especificación de Requisitos
(DER)
61

• Documento de Definición de Requisitos (DDR)
– Está dirigido a los clientes/usuarios
– Identifica, describe, organiza y relaciona los requisitos
desde la perspectiva de los clientes/usuarios
– Cada requisito es debidamente identificado y
documentado usando formatos especiales, p.ej.:
• Plantilla VOLERE
62
«documento»
Documento de Definición de
Requisitos (DDR)
«documento»
Lista de
Requisitos
Identificados
«modelo»
Matriz Requisitos
.vs. Requisitos
«documento»
Lista de
Requisitos
Seleccionados

• Documento de Especificación de Requisitos (DER)
– Está dirigido a los desarrolladores del sistema
– Describe gráficamente los requisitos contenidos en el DDR
usando un lenguaje o notación de modelado, p.ej.:
• UML, ER, SADT, Notación Z
63
«documento»
Documento de Especificación
de Requisitos (DER)
«modelo»
Modelo Funcional (o de
Casos de Uso)
«modelo»
Modelo Dinámico (o de
Comportamiento)
«modelo»
Modelo Estructural (o de
Clases)
«diag. UML»
Diagrama de
Casos de Uso
«Document...
Descripción
Textual de Caso
de Uso
«diag. UML»
Diagrama de
Clase
«diag. UML»
Diagrama de
Componentes
«diag. UML»
Diagrama de
Actividad
«diag. UML»
Diagrama de
Estado
«diag. UML»
Diagrama de
Secuencia
1..* 0..*
0..* 0..* 0..*0..*
0..11 1
1..*

• Existen varios estándares y modelos (plantillas o
patrones) que ayudan a elaborar el Documento
de Requisitos
– El estándar IEEE 830-1993
• Propuesto por el Institute of Electrical and Electronics
Engineers (IEEE)
• Agrupa los documentos DDR y DER en un sólo documento
• Es, también, un estándar ANSI
– Adaptaciones del estándar IEEE 830-1993
• Adaptación de Wiegers(2003)
• Adaptación de Le Vie (2009)
http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html
64

1. Introducción
1. Propósito
2. Convenciones utilizadas
3. Audiencia y lecturas sugeridas
4. Alcance del proyecto
5. Referencias
2. Descripción general
1. Perspectiva del producto
2. Aspectos del producto
3. Tipos de usuarios y sus características
4. Ambiente operativo
5. Restricciones de diseño e
implementación
6. Documentación del usuario
7. Supuestos y dependencias
3. Aspectos de la aplicación
1. Aspecto A
1. Descripción y prioridad
2. Estímulo/respuesta
3. Requisitos funcionales
2. Aspecto B …
4. Requisitos de Interfaces
1. Interfaces de usuarios
2. Interfaces de hardware
3. Interfaces de software
4. Interfaces de comunicación
5. Otros requisitos no-funcionales
1. Requisitos de rendimiento
2. Requisitos de seguridad
3. Atributos de calidad
4. …
6. Otros requisitos
Apéndice A: Glosario
Apéndice B: Modelos de Requisitos
1. Modelo Funcional
2. Modelo Estructural
3. Modelo Dinámico
Estructura del Documento de Requisitos según Wiegers (2003)
65

Modelo de
Negocios
BMM
Modelo de
Eventos
Modelo de
Actores/
Unidades
Modelo de
Objetos de
Negocio
Modelo de
Reglas de
Negocio
Modelo de
Procesos de
Negocio
Modelo de
Objetivos
Documento
de
Requisitos
Vista General
del
Sistema
Requisitos
Funcionales
Requisitos
No
Funcionales
Modelo
Funcional
(Casos de
Uso)
Modelo
Estructural
(Clases)
Modelo
Dinámico
• Relaciones de
Dependencia entre el
Modelo de Negocios y el
Documento de
Requisitos
66
EspaciodelProblema
EspaciodelaSolución

Los Procesos de la Ingeniería de Requisitos
¿Qué procesos
requiere la Ingeniería
de Requisitos?
67

El proceso de la Ingeniería de Requisitos
68
Ingeniería de
Requisitos (IR)
«objetivo»
Determinar los
requisitos que la
aplicación debe
satisfacer
«actor»
Líder del Grupo
de Análisis
«actor»
Grupo de Análisis
«actor»
Usuarios
«recurso»
Herramientas, técnicas,
patrones, métricas,
prácticas, plantillas para
IR
«Regla»
Métodos, Modelos,
Estándares y
Procedimientos de
Desarrollo de
Software
«modelo»
Modelo del Negocio
«documento»
Plan del Proyecto
«documento»
Plan de Gestión de
Requisitos
«Documento»
Plan del Proyecto
actualizado
«documento»
Documento de Inicio
del Proyecto
Información de
aplicaciones
similares
Necesidades de
los usuarios
«programa»
Prototipo de la
Aplicación
«documento»
Documento de
Requisitos
«documento»
Caso de Negocios
(Visión del Producto)
«persigue»
«ejecuta» «apoya»
«regula»
«controla»
«apoya» «apoya»

• La Ingeniería de Requisitos es un proceso compuesto por:
– Procesos de Desarrollo de Requisitos
• Se encargan de capturar, organizar, filtrar y documentar los requisitos
– Procesos de Gestión de Requisitos
• Planifican y controlan los procesos de desarrollo y controlan los cambios
a los requisitos
69
Ingeniería de
Requisitos
Descubrimiento
de Requisitos
Análisis de
Requisitos
Especificación de
Requisitos
Validación de
Requisitos
Gestión de
Requisitos
Desarrollo de
Requisitos

• El proceso de Descubrimiento de Requisitos (DR)
• Denominado, también, Captura de Requisitos
– En qué consiste:
• En la búsqueda y recolección de requisitos
– Qué actividades principales requiere:
• Establecer los objetivos de la aplicación
– Analizar el Caso de Negocios, Documento de Inicio y Plan del Proyecto
• Analizar el modelo de negocios
– Analizar el problema que la aplicación debe resolver
– Identificar a los usuarios
• Recolectar los requisitos que tienen los usuarios
– Usar la plantilla VOLERE y/o herramientas de gestión de requisitos
• Organizar los requisitos recolectados
70

• El proceso de Descubrimiento de Requisitos (DR)
– Qué técnicas se utilizan para descubrir requisitos:
• Entrevista
• Prototipos
• Reuniones
• Observación directa
• Reutilización de requisitos
• Uso de modelos de negocios
• Ingeniería en Reverso
• Encuestas (cuestionarios)
• Torbellino de ideas
• Análisis de documentos
72

• El proceso de Análisis de Requisitos (AR)
– En que consiste:
• En analizar los requisitos recolectados durante el
proceso anterior (DR) a fin de:
– Determinar y resolver posibles conflictos entre estos
requisitos
– Refinar los requisitos recolectados y establecer prioridades
– Establecer acuerdos entre usuarios y desarrolladores sobre
los requisitos que se pueden implementar
73

– Qué actividades principales requiere:
• Refinar y clasificar los requisitos
– Verificar necesidad, consistencia, completitud y factibilidad
• Negociar requisitos con el cliente y/o usuarios
– Discutir, priorizar y acordar requisitos
• Modelar los requisitos
– Elaborar los modelos funcional, estructural y dinámico de la
aplicación
• Construir un prototipo de la interfaz gráfica
74

– Qué técnicas se utilizan para analizar requisitos:
• Análisis de los procesos del negocio
• Análisis Orientado a Objetos
– Modelado de funciones mediante Diagramas de Casos de Uso
– Modelado de flujos de trabajo a través de Diagramas de Actividad
– Modelado estructural de la aplicación usando Diagramas de Clases
– Modelado del comportamiento mediante Diagramas de Secuencia
• Análisis Estructurado de Sistemas
– Modelado de procesos usando Diagramas de Flujo de Datos (DFD)
– Modelado de transiciones empleando Diagramas de Estados
– Modelado de entidades por medio de Diagramas Entidad-Interrelación
(ER)
• Prototipos
• Técnicas de negociación
75

• El proceso de Especificación de Requisitos (ER)
• En la documentación de los requisitos
• Está relacionado con la estructura, calidad y verificabilidad del
Documento de Requisitos
• Premisa:
– “La documentación de requisitos es la precondición fundamental para el
manejo exitoso de requisitos” [Kotonya and Sommerville, 2000]
– Que actividades principales requiere:
• Seleccionar el estándar de documentación
• Documentar los requisitos del cliente
– Elaborar el Documento de Definición de Requisitos (DDR)
• Documentar los requisitos del desarrollador
– Elaborar el Documento de Especificación de Requisitos (DER)
76

• El proceso de Especificación de Requisitos (ER)
– Qué técnicas se utilizan para especificar los requisitos:
• Uso de estándares de documentación de requisitos
– IEEE P1233/D3
– IEEE 830-1998
– ISO/IEC 12119-1994
– IEEE 1362-1998 (ConOps)
• Indicadores de calidad
– Modelos de calidad del software
• Lenguajes y notaciones
– Lenguajes de modelado gráfico
» Lenguajes OO: UML
» Lenguajes estructurados: DFD, SADT, IDEF
» Lenguajes dinámicos: Redes de Petri, Diagramas de Estado
– Lenguajes formales de especificación
» Notación Z
77

• El proceso de Validación de Requisitos (VR)
– En qué consiste:
• En examinar los productos elaborados durante la Ingeniería
de Requisitos para:
– determinar si son válidas y aceptables las descripciones de los
requisitos del sistema que se desea construir
– Qué productos de la IR se validan en este proceso:
• Lista de requisitos recolectados
• Modelos de Requisitos
– Modelos funcional, estructural y dinámico
• Prototipo
• Documento de Requisitos
– Documento de Definición de Requisitos (DDR)
– Documento de Especificación de Requisitos (DER)
78

– Los productos de la IR se validan para determinar si
sus requisitos son:
• Correctos
– Satisfacen las necesidades reales de los usuarios
• Completos
– Incluyen todos los requisitos que los usuarios demandan
• Consistentes
– No hay conflictos entre requisitos
• Libres de errores
• Cumplen con los estándares establecidos
• Precisos
– No hay requisitos ambiguos
79

– Qué actividades y técnicas se utilizan para validar
requisitos:
• Revisar técnicamente los modelos y documentos
– Inspección de modelos
– Inspección de documentos
• Validar el Prototipo
– Evaluación de prototipos de interfaces gráficas
• Diseñar pruebas funcionales
– Definición de criterios de aceptación
» Qué criterios emplearán los usuarios para aceptar la
aplicación
– Diseño de casos de pruebas para validar las funciones de la
aplicación
80

• El proceso de Gestión de Requisitos (GR)
• En establecer y mantener, a lo largo de todo el proyecto, un
acuerdo con el cliente o usuarios sobre los requisitos de la
aplicación
– Qué actividades principales se requieren:
• Planificar y controlar las actividades de Ingeniería de
Requisitos
• Controlar los cambios a los requisitos acordados
– Definición de la línea base de requisitos
– Control de cambios en requisitos
• Manejar las relaciones entre requisitos
• Manejar las dependencias entre el Documento de
Requisitos y los otros documentos del desarrollo
– Seguimiento o trazabilidad de requisitos
81

• El proceso de Gestión de Requisitos (GR)
– Qué técnicas se utilizan:
• Planificación y control de proyectos
• Control de cambios
• Gestión del almacenamiento de requisitos
– Identificación de requisitos
– Uso de bases de datos para requisitos
• Rastreo o trazabilidad de Requisitos
82

Los Actores de la Ingeniería de Requisitos
83
¿Quienes participan
en el proceso IR?

El grupo de requisitos
• En la elaboración del Documento de Requisitos
participan un conjunto de interesados o actores
– Para garantizar el éxito del proceso IR, este grupo debe
estar debidamente organizado y estructurado
– A este conjunto organizado de actores se le denomina
Grupo de Requisitos
84

El grupo de requisitos
• Responsabilidades y funciones del Grupo de
Requisitos:
– Seleccionar un modelo de procesos apropiado para
ejecutar la IR
– Adaptar el modelo de procesos IR a las características del
proyecto y de la empresa
– Planificar el proceso de requisitos
– Elaborar el Documento de Requisitos siguiendo el proceso
– Mantener actualizado el Documento de Requisitos
– Hacerle seguimiento a los requisitos (mantener la
trazabilidad)
– Proporcionar soporte técnico al grupo de desarrollo del
sistema en relación a los requisitos
85

Tema 4: Modelado Funcional de Requisitos
• La Identificación de Requisitos describe cada requisito
separadamente
– Sin embargo, para comunicar, analizar y validar los
requisitos de una aplicación es más conveniente
modelarlos gráficamente
• Por esta razón, durante el Análisis de Requisitos se
elaboran tres modelos de requisitos diferentes:
– Modelo Funcional
• Representa los requisitos funcionales de la aplicación
– Modelo Estructural
• Representa la estructura de la aplicación
– Modelo Dinámico
• Representa el comportamiento de la aplicación
86

Tema 4: Modelado Funcional de Requisitos
• Los modelos de requisitos son elaborados
usando el lenguaje UML
– UML provee las notaciones necesarias para
modelar :
• Los requisitos funcionales
• La estructura y comportamiento de la aplicación
• Los requisitos funcionales se modelan usando
los Diagramas de Casos de Uso del lenguaje
UML
87

Modelado Funcional de Requisitos
• El Modelado Funcional es un proceso mediante
el cual se representa gráficamente la
funcionalidad de una aplicación
• La funcionalidad es el conjunto de funciones o
servicios que una aplicación provee a sus
usuarios
– Determina que operaciones pueden los usuarios
realizar con el sistema
– La funcionalidad dice que hace el sistema, pero no
dice como lo hace
• El producto principal del Modelado Funcional de
requisitos es un Modelo de Casos de Uso
88

Modelado Funcional de Requisitos
• Componentes de un Modelo de Casos de Uso
– Un Modelo de Casos de Uso consta de uno o más
Diagramas de Casos de Uso y un conjunto de
descripciones textual
• Una descripción textual está asociada a un caso de uso
89

Retirar efectivo
Validar tarjeta
Transferir entre
cuentas
Consultar saldo
Usuario ATM
Cambiar clave
Diagramas de Casos de Uso
• Los Diagramas de Casos de Uso especifican requisitos
funcionales
– Cada requisito funcional es representado por un caso de uso
– Cada caso de uso es documentado mediante una
Descripción Textual
90
Caso de uso: Validar tarjeta
Actor: Usuario
Flujo de eventos:
1.- El usuario introduce la tarjeta
2.- El sistema valida la tarjeta
3.- El sistema presenta el menú
de opciones
Descripción Textual
Diagrama de
Casos de Uso

uc CasoUsoPrincipal
Servicio de Transporte Aéreo
Gestionar
Vuelos
Gestionar
reservaciones
Consultar
productos y
servicios
Administrar
recursos
UsuarioNoRegistrado
Administrador
Aerolinea
Registrar
usuarios
Pasajero
• Los diagramas de casos de uso
modelan:
– Los actores de un sistema
– Los casos de uso
– Las relaciones entre actores
– Las relaciones entre casos de
uso
– Las relaciones de comunicación
entre actores y casos de uso
– Los límites del sistema
– El refinamiento o
descomposición de los casos
de uso
91

• Forma general de un diagrama de casos de
uso
92
relación de extensión
<<extiende>>
relación de inclusión
<<incluye>>
asociación
Caso de uso
especializado
relación de generalización
límite del sistema
Caso
de uso
Actor
Caso de
uso
extendido
Caso de
uso incluido
relación de extensión
<<extiende>>
relación de inclusión
<<incluye>>
asociación
Caso de uso
especializado
relación de generalización
límite del sistema
Caso
de uso
Actor
Caso de
uso
extendido
Caso de
uso incluido

• Actor
– Símbolo usado para representar el rol que
objetos externos, de una misma clase, juegan
cuando interactúan con el sistema
• Un objeto externo puede ser una persona
interesada (stakeholder), un dispositivo u
otro sistema
• No se refieren a un individuo particular,
sino a una clase de individuos que tienen
un rol común
– Representan a entes externos al sistema
– Un actor intercambia señales y datos con el
sistema
– Un actor es un clasificador y no una ocurrencia
93
Icono creado por el modelador
Clasificador con estereotipo
«actor»
rol
rol
Representación icónica
Rol
Icono creado por el modelador
Clasificador con estereotipo
«actor»
rol
rol
Rol
Rol

• Relaciones entre
Actores
– Se pueden
establecer
relaciones de
generalización entre
los actores
– Un rol general
puede ser heredado
por uno o más roles
específicos
94
uc Actores
PasajeroPilotoAerolinea
PasajeroFrecuente
(PF)
UsuarioNoRegistrado
Administrador

• Relaciones entre Actores y Casos de Uso
– Los actores se relacionan con los casos de uso mediante
asociaciones
– Un asociación modela la comunicación bidireccional entre
un actor y un caso de uso
• Envío de señales
– Ej. activación del caso de uso
• Envío de datos e información
95
Actor
Caso de Uso
Actor
Caso de Uso

• Relaciones entre casos de uso
– Los casos de usos se asocian entre sí usando tres
tipos de relaciones:
• Relaciones de extensión
• Relaciones de inclusión
• Relaciones de generalización
96
Caso Uso 1
Caso Uso 2
Caso Uso 3
Caso Uso 4
«incluye»
«extiende»
Caso Uso 1
Caso Uso 2
Caso Uso 3
Caso Uso 4
«incluye»
«extiende»

• Relación de extensión
– Modelan relaciones en las cuales un caso de uso base incluye el
comportamiento de un caso de uso extendido en uno o más puntos de su
flujo de eventos
• Estos puntos se denominan puntos de extensión
• Tienen asociado una condición que determina cuando el caso de uso
extendido es invocado por el caso de uso base
– El caso de uso extendido se activa cuando la condición se cumple
97

• Relación de extensión
– Usadas para modelar separadamente el comportamiento excepcional del
caso de uso base
– Este tipo de relación es unidireccional y va desde el caso de uso extendido al
caso de uso base usando el estereotipo <<extend>> o << extiende>>
98
uc CasosURelaciónExtensión
Realizar reservación Reservar múltiples
destinos
Condición: {modo="multiples destinos"}
Punto de extensión: Verificar modo
Caso de uso base Caso de uso
extendido
«extiende»

• Relación de inclusión
– Modelan relaciones en las cuales uno o más casos de uso incluyen (usan) el
comportamiento de un caso de uso común
– Son usados para compartir comportamiento común entre varios casos de uso
– Este tipo de relación es unidireccional y va desde el caso de uso base al caso
de uso incluido usando el estereotipo <<include>> o <<incluye>>
99
uc CasosUsoRelaciónInclusión
Usar
reservación
Registrar el
vuelo«incluye»

• Relación de generalización en casos de uso
– Modela las relaciones en las cuales el comportamiento de un caso de uso
general (padre) es heredado por uno o más casos de uso especializados
(hijos)
100
uc CasosUsoRelaciónGeneralización
Actualizar
reservación
Realizar
reservación
Modificar
reservación
Eliminar
reservación
Caso de uso
General
Casos de uso
específicos

• Reglas de estilo para elaborar Diagramas de Casos de Uso
– Cada actor y caso de uso debe tener un nombre único
– Los actores deben tener nombres y/o íconos
representativos
• Los nombres deben indicar roles
– El nombre de un caso de uso debe indicar acción y
debe ser claro y conciso
• Forma general: Verbo + predicado
• Ejemplos:
– Actualizar itinerarios
– Realizar reservación
– Gestionar vuelos
101

• Reglas de estilo para Diagramas de Casos de Uso
– Los casos de uso de un diagrama deben estar todos a
un mismo nivel de abstracción
– Evite el cruce de líneas
– Evite tener demasiados casos de uso en un mismo
diagrama
• Use la regla del 7 2:
– El número apropiado de casos de uso por diagrama está en el
rango de 5 a 9
– Evite el uso complejo de relaciones de extensión e
inclusión
• No más de tres niveles de relaciones consecutivas
102

• Ejemplos de Diagramas de Casos de Uso: Servicio de Transporte Aéreo
103
uc CasoUsoPrincipal
Servicio de Transporte Aéreo
Gestionar
Vuelos
Gestionar
reservaciones
Consultar
productos y
servicios
Administrar
recursos
UsuarioNoRegistrado
Administrador
Aerolinea
Registrar
usuarios
Pasajero
uc Actores
PasajeroPilotoAerolinea
PasajeroFrecuente
(PF)
UsuarioNoRegistrado
Administrador

104
uc CasoUsoGestionarVuelos
Actualizar
Aerolineas
Actualizar
Aviones
Actualizar
itinerarios
Actualizar
Pilotos
Actualizar
Aeropuertos
Aerolinea
uc GestionarReservaciones
Realizar
reservación
Modificar
reservación
Eliminar
reservación
Usar
reservación
Consultar
promociones
Actualizar
reservación
Registrar el
vuelo
Consultar
promociones de
PF
Aerolinea
Pasajero
PasajeroFrecuente
(PF)
Consultar
itinerarios
Reservar múltiples
destinos
«extend»
«incluye»
«extiende»

Descripción textual de casos de uso
• La simplicidad de los diagramas de casos de uso
tienen un costo asociado:
– Baja expresividad:
• Las acciones que ocurren entre un actor y el caso de uso no
se pueden capturar con los símbolos de los casos de uso
– Cada caso de uso tiene asociado un flujo de eventos
que indica el orden en que sus acciones se ejecutan
– Ejemplo:
1. El sistema presenta la forma “Registro de Cliente”
2. El usuario ingresa los datos de la forma y pulsa “enter”
3. El sistema valida el nombre de la empresa y el RIF
4. El sistema crea un nuevo registro de cliente en la base de datos
5. El sistema notifica al usuario el número de registro
105

• El flujo de eventos establece los detalles de la
comunicación entre el caso de uso y sus actores
• Los flujos de eventos se describen separadamente
usando Descripciones Textuales de Casos de Uso
– Flujo de eventos principal (flujo feliz)
– Flujos de eventos alternativos
106
Flujoprincipal

• Plantilla para descripción de casos de uso
107
Caso de uso: <nombre del caso de uso>
Actores participantes: <lista de actores que participan>
Condiciones de entrada: <precondiciones>
Flujo de eventos principal:
<evento 1> (los eventos son del tipo: “El actor hace esto” o “El sistema hace aquello”)
<evento 2>
…
<evento n>
Flujos alternativos:
<flujo alternativo asociado al flujo de eventos normal i>
Condiciones de salida: <postcondiciones>
Requisitos especiales: <requisitos no-funcionales asociados al caso de uso>
Notas: <notas adicionales o aclaratorias>

108
Caso de uso: Realizar Reservación
Actores participantes: Pasajero
Condiciones de entrada: El pasajero es un usuario registrado
Flujo de eventos principal:
1. El usuario selecciona la opción "Realizar reservación"
2. El sistema muestra un formulario con los criterios de búsqueda de vuelos
3. El usuario ingresa los criterios (modo, origen, destino, periodo y pasajeros) y pulsa la tecla "buscar vuelos"
4. El sistema busca todos los vuelos que cumplen con los criterios
5. El sistema muestra los vuelos (aerolínea, monto, tasa, impuestos)
6. El usuario selecciona el vuelo y pulsa la tecla "reservar"
7. El sistema muestra un formulario de ingreso de datos de los pasajeros
8. El usuario ingresa los datos de los pasajeros y pulsa la tecla "guardar"
9. El sistema agrega la reservación al vuelo de la aerolínea
10. El sistema emite un comprobante de la reservación
Condiciones de salida:
El pasajero obtiene la reservación mediante un comprobante de confirmación

109
Flujo de eventos alternativos:
 3.1 El usuario ingresa los criterios de búsqueda incompletos
3.1.1 El sistema muestra un mensaje de advertencia
 3.2 El usuario ingresa el modo: “múltiples destinos”
3.2.1 El sistema muestra un formulario para seleccionar múltiples destinos
3.2.2 El usuario selecciona los destinos y pulsa la tecla "continuar"
3.2.3 El sistema guarda los destinos y regresa al formulario de criterios del vuelo
 4. El sistema no encuentra disponibilidad de vuelos
4.1 El sistema muestra un mensaje indicando que no existe disponibilidad de vuelos para los criterios seleccionados
 6. El usuario no selecciona ningún vuelo
6.1 El usuario pulsa la tecla "Regresar"
6.2 El sistema regresa a la página anterior
 8. El usuario ingresa los datos de los pasajeros incompletos
8.1 El sistema muestra un mensaje de datos de pasajeros incompletos
Requisitos especiales:
El sistema debe mostrar los resultados de vuelos en un tiempo no mayor a 10 segundos

• Reglas para la descripción textual de casos de uso
(1)
– Narre el flujo de eventos usando voz activa, en tiempo
presente y desde la perspectiva del actor
• Evite el uso de voz pasiva:
– “La clave es introducida por el usuario”
• Prefiera el uso de la voz activa:
– “El usuario introduce la clave”
– “El sistema valida la clave”
– Exprese cada paso del flujo usando la forma “llamada y
respuesta”:
• El texto debe reflejar el hecho de que el actor ejecuta algo y el
sistema responde a la solicitud del actor
– “El [actor] hace [esto]” y “El sistema hace [aquello]”
110

• Reglas para la descripción textual de casos de uso (2)
– El caso de uso que se describe debe expresar un solo
requisito funcional
• Pero, pueden haber uno o más requisitos no-funcionales asociados
al requisito funcional descrito
– Establezca el contexto inicial del actor
• Especifique la ubicación del actor en el contexto de la interfaz de
usuario del sistema
– Ej. El Cliente introduce su clave de identificación en la ventana de
identificación al inicio del sistema
– Asegúrese que el caso de uso produzca un resultado visible y
de valor para el cliente
– Establezca todos los posibles flujos alternativos al flujo
principal (flujo feliz)
111

Tema 5: Modelado Estructural de Requisitos
• Toda aplicación tiene una estructura asociada
• La aplicaciones orientadas a objetos (OO) representan
mediante objetos de software a los objetos del
dominio de la aplicación (sistema de negocios)
– Cada objeto relevante del sistema de negocios es
representado en la aplicación por un objeto de software
– Familiarizarse con el proceso de modelado estructural de
requisitos
– Adquirir habilidades en el modelado de la estructura de
una aplicación usando Diagramas de Clases en UML
112

Modelado Estructural de Requisitos
• Una actividad importante del Análisis de
Requisitos es la elaboración del Modelo
Estructural de la aplicación
• Un Modelo Estructural es una representación
gráfica de la estructura que debe tener la
aplicación
– En aplicaciones OO, esta estructura se expresa en
términos de clases de objetos y relaciones entre estas
clases
– Cada clase de objetos representa a un conjunto de
objetos del dominio de la aplicación que tienen todos
las mismas propiedadesMapa
representa
113

UML: Diagramas de Clases
• Los Diagramas de Clases permiten
representar diferentes aspectos de la
estructura de un sistema o aplicación
• En Ingeniería de Requisitos se usan para:
– Facilitar la identificación y modelado de los
requisitos estructurales de una aplicación, es
decir
• Las clases del negocio
– Esto es, clases que representan a los objetos del negocio
• Las relaciones entre estas clases
114

• Los diagramas de clases se pueden elaborar
mediante el análisis de los diagramas de casos
de uso
– Cada sustantivo del nombre de un caso de uso
representa un tipo o clase de negocio
115
Comprar un mapa Mapa

• Un Diagrama de Clase en UML consta de:
– Una o más clases de objetos
– Una o más relaciones entre clases
116
Operaciones
(Métodos)
Diagrama de
Clases
Agregación DependenciaComposiciónAsociaciónGeneralizaciónAtributos
Relación
Clases de Objeto
**
*
*

• Una CLASE representa
una colección de
entidades u objetos que
tienen un conjunto
común de propiedades
• Es un constructo que
define la estructura
(atributos) y el
comportamiento
(operaciones) de un
conjunto de objetos
denominados instancias
117
Avión
+id
+nombre
+marca
+modelo
+capacidadMax
+estado
+...
+cambiarEstado()
+actualizarDatos()
+obtenerDatos()
+obtenerEstado()
+...()
Nombre de
la clase
Atributos
(estructura)
Métodos u
Operaciones
(comportamiento)

• Una clase describe los atributos de sus instancias
• Los atributos son las propiedades comunes que
las instancias de una clase tienen
• Formato de un atributo:
• visibilidad / nombre: tipo [multiplicidad] = valor de defecto
{propiedad}
– La visibilidad puede ser pública (+), protegida(#), privada (-) o
sólo para el paquete (~)
– Las propiedades pueden ser: {readOnly}, {sequence}, {ordered}
– / indica que el atributo es derivado o calculado a partir de otros
• Ejemplos:
– + capacidadMax: Integer = 45
– + estado: String = “activo”
– - / edad: Integer {readOnly}
118

• Una clase describe, también, las operaciones
(métodos) que se le pueden aplicar a sus instancias
• Formato de una operación:
• visibilidad nombre (lista de parámetros): valor de retorno
{propiedad}
– La visibilidad puede ser pública (+), protegida(#), privada (-) o paquete
(~)
– Las propiedades pueden ser: {isQuery}, {sequential}, {concurrent},...
– La lista de parámetros tiene el siguiente formato:
» dirección nombre: tipo [multiplicidad] = valor de defecto
» Dirección indica si el parámetro es de entrada (in), salida (out) o
ambos (inout)
• Ejemplos:
– +obtenerEstado():String
– +actualizarDatos( in marca: String, in modelo: String)
– #cambiarCapacidad( in nueva: Integer) {sequential}
119

• Entre las clases se establecen RELACIONES de
varios tipos:
– Generalización y herencia
– Asociación
– Agregación
– Composición
– Dependencia
120
A B
A B+rol2+rol1
A B
A B
A B

• Generalización y herencia
• Establece una relación del tipo ”es_un” entre dos o
más clases
• Una o más clases específicas, denominadas subclases,
heredan la estructura y comportamiento de una clase
genérica
• Las subclases tienen (heredan) los mismos atributos y
operaciones que tiene su superclase
121
subclases
superclase
Persona
Profesor
Estudiante

• Asociación
– Establece una relación funcional y bidireccional
entre dos o más clases
– Cada instancia de una clase se asocia a cero, uno
o más instancias de la otra clase asociada
122
CursoEstudiante inscribe +es_cursado+cursa
0..*0..*
nombre de la asociación
multiplicidad
rol

• Agregación
– Establece una relación “todo-partes” en la cual
una clase (el todo) está conformada por otra u
otras clases (las partes)
– La existencia de las instancias de las partes no
depende de la existencia de las instancias de la
clase agregada
123
Equipo de Trabajo
Estudiante
parte
todo

• Composición
– Establece una relación “es_parte_de” entre dos
clases
– Es un tipo particular de agregación en la cual la
existencia de las instancias de las partes depende
de la existencia de la instancia compuesta
124
Curso
Objetivo Contenido Actividad
1..* 1..* 0..*
Clase compuesta
Clases componentes

• Dependencia
– Establece una relación entre una clase
dependiente y otra independiente
– No establece un tipo específico de dependencia
• Simplemente se indica que hay una dependencia entre
dos clases
125
Curso Institución
Clase independienteClase dependiente

• Casos especiales
126
Clase de Asociación
Clase Abstracta
Paciente
+id
+nombre
+...
Médico
+id
+nombre
+especialidad
#consultorio
+...
Cita
+fecha
+hora
0..*0..*
Equipo
<<abstract>>
+id
+nombre
+marca
+modelo
+serial
+obtenerSerial()
+...()
PDA
+memoria
+tipoCPU
PC
+memoria
+tipoCPU
+capDD
Teléfono
+protocoloCOM

• Casos especiales
127
Asociación Recursiva
Actividad
+id
+nombre
+descripción
+duración
+estructurada_por
0..*
1
Departamento
Persona Proyecto
Asociación Ternaria

• Usos de los Diagramas de Clases
– En la especificación de requisitos, se usan para
representar:
• Los objetos de negocio del dominio de aplicación y
• Las relaciones entre estos objetos
– Ejemplo 1: Modelo de Objetos de Negocio en un
Sistema de Reservaciones Aéreas
128
Reservación
Cliente Vuelo Aerolínea
+reservado_por+reserva
0..*0..*
+coordina+coordinado_por
11..*
Avión
asignación
1
1

129
Reservación
+fecha
+hora
+localizador
+estado
Cliente
+id
+cédula
+nombre
+teléfono
+e-mail
+...
Vuelo
+id
+número
+origen
+destino
+cupoDisponible
+estado
+...
Aerolínea
+id
+nombre
+e-mail
+estadoActual
+...
+reservado_por+reserva
0..*0..*
+coordina+coordinado_por
11..*
Avión
+id
+nombre
+marca
+modelo
+capacidadMax
+estado
+...
asignación
1
1
clase de negocio
clase de asociación
asociación
atributo
roles
multipicidad
Sistema de
Reservaciones Aéreas

• Ejemplo 2: Sistema de ordenes de compra
– Identificación de objetos de negocios:
• Cliente
• Producto o ítem
• Orden de compra
– Encabezado
– Líneas de pedido (ítems solicitados)
• Pago
– Pago en efectivo
– Pago a crédito
– Pago con cheque
– Identificación de relaciones
• Un Cliente coloca una o más Ordenes de Compra
• Una Orden de Compra está compuesta por un Encabezado y una o más
líneas de pedido
• Una Orden de Compra es pagada en efectivo, cheque o a crédito
130

Resumen del Tema 5
• Qué es el Modelado Estructural de
Requisitos
• Porqué es importante modelar la
estructura de la aplicación durante
la IR
• Cómo se elabora un Diagrama de
Clases
• Qué diferencias existen entre:
– Clases y objetos
– Atributos y métodos
– Generalización y especialización
– Composición y agregación
– Clase de asociación y asociación
recursiva
132

Ejercicios Prácticos del Tema 5
• Objetivo de la actividad:
– Elaborar el Modelo Estructural de los requisitos de su
aplicación
• Duración:
– 15 minutos presenciales + 1-2 horas a distancia
• Pasos a seguir:
Usando el Modelo Funcional de Requisitos elaborado en
durante el Tema 4:
1. Identifique las clases del negocio que debe manejar su
aplicación
2. Identifique las relaciones entre estas clases
3. Identifique los principales atributos de cada clase
4. Elabore y valide el Modelo Estructural de su aplicación
133

Tema 6
Modelado Dinámico
Diagramas de Actividad y Estado

Tema 6: Modelado Dinámico de Requisitos
• Toda aplicación tiene una dinámica asociada
– Esta dinámica está determinada por el comportamiento
de la aplicación ante eventos
– Los eventos hacen que la aplicación responda o reaccione
– Estos eventos pueden ocurrir debido a:
– La interacción del usuario con la aplicación
– Una transición de estado en un objeto de la aplicación
– Una falla de la aplicación
– Familiarizarse con el modelado dinámico de una
aplicación
– Adquirir habilidades en el uso de diagramas de actividad y
diagramas de estado del UML
135

Modelado Dinámico de Requisitos
• Para modelar la dinámica o el comportamiento
de una aplicación existe un conjunto amplio de
técnicas:
– UML:
• Diagramas de actividad
• Diagramas de Interacción
– Diagramas de secuencia
– Diagramas de comunicación
• Diagramas de estado
– Otros:
• Diagramas de flujo
• Redes de Petri
• Notación de Modelado de Procesos de Negocios BPMN
136

Modelado Dinámico de Requisitos
• Los diagramas de actividad del UML son útiles para :
– modelar los flujos de trabajo en los que interviene la
aplicación
– Representar la interacción de la aplicación con los procesos
del sistema de negocios
• Los diagramas de estado del UML son útiles para
modelar:
– los eventos que ocasionan cambios en el estado de los
objetos de una aplicación
– las transiciones de estado que pueden tener los objetos de
cierta clase en una aplicación
• Los diagramas BPMN son una alternativa a los
diagramas de actividad
– Permiten modelar flujos de trabajo de una aplicación
137

UML: Diagramas de Actividad
• Los diagramas de actividad son usados para
modelar flujos de trabajo (workflow) de una
aplicación
– Expresan que acciones se requieren y en que orden
– Qué hacen estas acciones y/o que producen
– Quien es responsable de ejecutarlas (partición de
actividades)
Recibo
de la orden
Cierre
de la orden
Factura
Llenar
orden
Enviar
orden
Enviar
factura
Hacer
pago
Aceptar
pago
[orden
aceptada]
[orden
rechazada]
Orden de
requerimiento
138

Diseñar
Estructura del
Producto
Diseñar
Forma del
Producto
Especificar
Componentes
«información»
Características
del Producto
«información»
Estructura
del Producto
«información»
Forma
del Producto
«información»
Modelo
del Producto
• Los diagramas de actividad capturan las
acciones de un proceso del negocio y sus
resultados
– Enfatizan la secuencia de actividades (acciones)
– Modelan dos tipos de flujos de un proceso del
negocio:
• el flujo de control y/o
• el flujo de objetos
Modelo de flujo de control
Modelo de flujo de objetos
Diseñar
Estructura del
Producto
Diseñar
Forma del
Producto
Especificar
Componentes
139

• Concepto de “acción” o “tarea” en un
diagrama de actividad
– Una acción (o tarea) es la unidad fundamental de
especificación de comportamiento
– Una acción es atómica
• No puede ser descompuesta en otras acciones
– Una acción toma uno o más objetos de entrada
(tokens) y las transforma en uno o más objetos de
salida (tokens)
tokens
acción
Diseñar
Forma del
Producto
«información»
Estructura
del Producto
«información»
Forma
del Producto
140

• Un diagrama de actividad es un grafo dirigido
que está compuesto de:
– Un conjunto de nodos de cuatro tipos:
• Nodos de actividad que representan acciones
– Transforman objetos que entran en objetos que salen
• Nodos de control usados para controlar flujos
• Nodos de objetos que representan objetos de datos
• Nodos de señal que modelan eventos que activan la
ejecución de acciones
– Un conjunto de ejes
• Cada eje conecta a dos nodos
• A través de los ejes circulan objetos denominados tokens
141

• Formato de un diagrama de actividad
Pre y postcondiciones
Ejes de actividad
Nodos de actividad
Parámetro de la actividad
Nombre de la actividad
Nodos de parámetros
…
…
…
Nombre de la actividad o proceso <<precondición>> restricción
Nombre del parámetro: Tipo <<poscondición>> restricción
142

• Ejemplo 1: “Procesar Ordenes de Compra”
Orden de
compra
Nota de
despacho
Revisar orden
de compra
Rechazar orden
Actualizar inventario
Elaborar
nota de despacho
Verificar existencia
de producto
A
A
[Orden
completa]
[Orden incompleta]
No
Si
Procesar Orden de Compra <<precondición>> Orden válida
<<postcondición>> Orden atendida
Nombre de la actividad o proceso Nodo Objeto
parámetro
de salida
Pre y postcondiciones
Nodo objeto
parámetro
de entrada
Join
Fork
Nodo
de mezcla
Nodo
de decisiónConector
Nodo
fin de
actividad
Acción
Nodo
inicio de
actividad
143

Nodos de parámetros
Anotación de
flujo continuo
Anotaciones de
excepción
Materiales de
producción
Computadores
Ensamblados
Tableros de
circuitos
impresos
Computadores
aceptados
Computadores
rechazadosProducir tableros
de circuitos
impresos
Ensamblar
computadores
Probar
computadores
{flujo}
• Ejemplo 2: Flujo de objetos de la actividad
“Producir computadores”
144

• Nodos de señales
– Permiten modelar eventos o señales que activan
la ejecución de acciones
nodos de señal de envío
nodo de señal de aceptación
(Ventas)
Crear orden
(almacén)
Facturar orden
Entregar
orden
Notificar al
Cliente
Cancelar
orden
Solicitud
de cancelación
de orden
145

• Los diagramas de actividad modelan flujos de trabajo mediante:
• Secuencias de acciones (secuenciación)
• Secuencias de acciones paralelas (paralelismo)
• Secuencias de acciones alternativas (decisión)
• Sincronización de acciones paralelas (concurrencia)
Cancelar
servicio
Cancelar
transacción
Notificar
inactividad
Notificar
rechazo
Rechazar
Aprobar
servicio
Someter
a aprobación
Aprobar
automáticam
Cronometrar
inactividad
[cantidad<200]
[cantidad>=200]
[decisión=rechazar]
[decisión=aceptar]
146

• Partición de actividades y carriles (swimlanes)
– Permiten agrupar las acciones de acuerdo a los
actores o unidades organizacionales responsables
de su ejecución
– Útiles para establecer relaciones entre la
aplicación y sus usuarios
a) Partición usando la notación “swimlane”
Nombrede
partición
Partición
Nombre-4
Partición
Nombre-1
Partición
Nombre-2
c) Partición usando la notación
“swimlane” jerárquica y multidimensional
Nombre de dimensión
Nombrededimensión
Partición
Nombre-3
b) Partición usando la notación “swimlane” jerárquica
Nombrededimensión
Nombredepartición
Nombrede
subpartición
Nombrede
subpartición
147

• Ejemplo 1: Partición de actividadesCliente
<<externa>><<atributo>>dptoEjecutor:Departamento
Dpto.deOrdenesDpto.deContabilidad
Recibir
orden
Cerrar
orden
Factura
Llenar
orden
Enviar
orden
Enviar
factura
Hacer
pago
Aceptar
pago
[orden
aceptada]
148

• Ejemplo 2: Partición de actividades usando
carriles multidimensionales
Mérida Caracas
<<clase>>
Dpto.deContabilidad
<<clase>>
Dpto.deVentas
Recibir
orden
Cerrar
orden
Factura
Solicitar
despacho
Despachar
orden
Enviar
factura
Recibir
pago
Confirmar
pago
[orden
aceptada]
149

• Ejemplo 3: Otra manera de particionar
actividades es mediante la anotación
– Cada acción tiene una anotación específica que
indica el actor o unidad organizacional
responsable de ejecutarla
(Dpto.Orden)
Recibir
orden
(Dpto. Orden)
Cerrar
orden
Factura
(Dpto. Orden)
Llenar orden
(Dpto. Orden)
Enviar orden
(Contabilidad)
Enviar factura
<<externa>>
(Cliente)
Hacer pago
(Contabilidad)
Enviar pago
[orden
aceptada]
anotación
150

• Los Diagramas de Actividad modelan:
– el flujo de trabajo de un proceso del negocio y
– las relaciones entre los usuarios y la aplicación
• Ejemplo 1: Sistema de Facturación en línea
Recibir
orden
Cierre
de orden
Solicitar
Despacho
de orden
Despachar
orden
Enviar
factura
Hacer
pago
Aceptar
pago
[orden
aceptada]
Cliente
<<externo>>
Depto.de
Ventas
Sist.deFacturación
Factura
<<unidadorganizacional>>
GerenciadeVentas
151

• Ejemplo 2: Sistema de ordenes de compra
Verificar
datos cliente
Verificar
inventario
Rechazar
orden
Procesar
orden
Empacar
productos
Ingresar
orden
Enviar
pedido
válido
inválido
cantidad > 0
cantidad <= 0
<<producto>>
Pedido
<<información>>
Notificación
Cliente Sistema Ordenes de Compra Sistema Inventario Almacén
152

Diagramas de actividad
• Ejemplo 3:
Un cajero
automátic
o
153
[Borland, 2002]

• Ejemplo 4:
Descomposición
funcional en diagramas
de actividad
Descomposición
de la actividad
Usar
parte
Requerir
ID parte
Buscar
parte
Proveer
parte requerida
[else]
[encontrada]
[no encontrada]
[proveída]
Ingeniería
de Diseño
Ingeniería
de Estándares
Ejecutar
flujo de
trabajo
[flujo]
[flujo]
Investigar
posibilidades
de producción
[acepta]
[rechaza]
Proveer
información
adicional
Mod. parte
Búsqueda
experta
de la parte
Asignar
ingeniero
Revisar
requerimiento
Especificar
flujo de
trabajo
Mod. parte
Planificar
flujo de
trabajo
Mod. parte
Clarificar
requerimientos
Revisar
plan
[cancelar]
[replanificar]
[OK]
[flujo][flujo]
[no encontrada]
[encontrada]
Proveer parte requerida Ingeniería
de Diseño
Ingeniería
de Estándares
154

UML: Diagramas de Estado
• Las aplicaciones de software combinan tres procesos
computacionales:
– Comportamiento funcional (ejecución de funciones)
– Manipulación de datos
– Cambios de estado
• Una aplicación en ejecución, generalmente, se
encuentra en un determinado estado
– P.ej., en espera, procesando, cerrada, etc.
• Este estado es modificado cuando ocurre un cierto
evento o condición predeterminada
– La ocurrencia del evento o la presencia de la condición
ocasiona una transición o cambio de estado en la
aplicación
155

• Los diagramas de estado son ideales para
modelar las transiciones de estado que ocurren a
nivel de:
– Toda la aplicación, p.ej.:
• Cambios de estado de una aplicación interactiva o una de
tiempo real
– Una aplicación interactiva pasa del estado inactivo al estado
activo cuando el usuario selecciona cualquier opción de su
interfaz
– Objetos de la aplicación, p.ej.:
• Cambios en el estado de un objeto de negocio en una
aplicación empresarial
– En la aplicación mimapa.com, los objetos de la clase Carro de
Compras puede cambiar del estado “vacio” al estado
“agregando”
156

• Máquinas de Estado Finito
– Tanto una aplicación como un objeto de ella
pueden ser vistos como máquinas de estado
– Una máquina de estado es un modelo que
especifica las secuencias de estados que un
objeto puede recorrer durante su existenciaEstado 1
Inicial
Estado 2
Estado 3
Final
evento A
evento C[condición D]
evento B
157

• Máquinas de Estado Finito
– Una máquina de estado tiene tres tipos de
elementos:
• Estados representados por rectángulos
• Transiciones o cambios de estado representados por
flechas entre estados
• Eventos o condiciones que causan las transiciones
entre estados
Estado 1
Inicial
Estado 2
Estado 3
Final
evento A
evento C[condición D]
evento B
158

• Estados
– Un estado es una condición en la cual un objeto
de una determinada clase puede estar en cierto
momento de su existencia
– El estado de un objeto es determinado por los
valores de sus atributos y enlaces a otros objetos
– Durante su estadía en un estado, el objeto puede
ejecutar operaciones al momento de:
• Entrada al estado (entry)
• Permanencia en el estado (do)
• Salida del estado (exit)
<nombre del estado>
entry/<operación>
do/<operación>
exit/<operación>
159

• Transiciones (cambios de estado)
– Una transición es un cambio de estado que
ocurre en un objeto o sistema
• El objeto (o sistema) pasa de un estado actual a otro
estado
• La transición se representa mediante un arco
Estado
actual
Estado
destino
transición
160

• Eventos
– Una transición ocurre debido a un evento que la
dispara
• Un evento es algo que acontece en el sistema o en su
entorno y que ocasiona una transición
• Formato del evento:
<nombreDelEvento> [<condición>] / <acción>
Donde:
<condición>: Expresión booleana. Debe ser verdadera para que
ocurra la transición. Si la expresión es falsa, no hay
transición
<acción>: Operación que se ejecuta sobre el objeto en el
momento en que ocurre la transición
• Ejemplo:
Cuenta
suspendida
Cuenta activada
pago realizado [saldo < 0]
pago realizado [saldo >=0]
/eliminarSuspension
161

• Ejemplo 1: Un Sistema de Seguridad
Sistema activado
+ entry / encender sensores
Sistema desactivado
+ entry / apagar alarma
+ entry / apagar sensores
Alarma encendida
+ entry / encender alarma
Inicial
botón
encendido
clave correcta
clave incorrecta
[t > 30 seg]
movimiento detectado
clave correcta
[t <= 30 seg]
clave incorrecta
clave correcta
[t > 30 seg]
162

• Ejemplo 2: Diagrama de Estado de los objetos
de la clase Reservación del Sistema de
Reservaciones
163

Resumen del Tema 6
• Qué es el Modelado Dinámico de
requisitos
• Qué es el comportamiento de una
aplicación
• Qué aspectos dinámicos de una
aplicación se modelan durante la IR
• Cómo representar un flujo de
trabajo usando diagramas de
actividades
• Cómo modelar los cambios de
estado de un objeto del negocio
164

Tema 6: Actividades Prácticas
• Objetivo de la actividad:
– Elaborar el Modelo Dinámico de los requisitos de su aplicación
• Duración:
– 30 minutos presenciales + 2-3 horas a distancia
• Pasos a seguir:
1. Usando el modelo de negocios elaborado durante la Sesión 2.1:
1. Seleccione un proceso de negocio que sea apoyado por la aplicación
que usted está especificando
2. Elabore un Diagrama de Actividad que muestre el flujo de trabajo que
requiere el proceso y su relación con la aplicación
2. Usando el Modelo Estructural elaborado durante el Tema 5:
1. Seleccione una clase que tenga cambios de estado interesante
2. Elabore el diagrama de estado para la clase seleccionada
165

Conclusiones
• Un mal manejo de los requisitos de una aplicación
puede ocasionar el fracaso del proyecto
• La Ingeniería de Requisitos (IR) busca resolver los
problemas asociados a los requisitos
• La IR agrupa y organiza los procesos de:
– Identificación, análisis, especificación, validación y gestión
de requisitos
• La IR está estrechamente relacionada con el Modelado
de Negocios (MN)
– El MN estudia el problema; mientras que la IR se encarga
de especificar la solución, inmediatamente antes de
diseñarla
166

Referencias Bibliográficas
• Le Vie, D. (2009). Writing Software Requirement Specifications. [on-line]
http://www.techwr-
l.com/techwhirl/magazine/writing/softwarerequirementspecs.html
• Wiegers, K. E. (2003). Software Requirements. Microsoft Press. Redmond,
Washington.
• Scott, K. (2004). Fast Track UML 2.0. Spriger-Verlag, New York.
• Eriksson, Penker, M, Lyons, B. and Fado, D. (2004). UML 2 Toolkit. Wiley
Publishing. Indiana.
• Montilva, J., Barrios, J. y Rivero, M. (2008). Gray Watch: Método de Desarrollo de
Software para Aplicaciones Empresariales. Versión preliminar. Monografía
disponible en www.methodius.org.ve
167

Módulo 2
Fin de la Sesión 2.2
Derechos Reservados. Prohibida la reproducción total o parcial de este
documento, por cualquier medio manual o electrónico, sin la autorización
escrita de sus autores.
© Jonás A. Montilva C.
jmontilva@biosoftca.com
http://e-praxis.biosoftca.com

Requisitos de software: conceptos, tipos y propiedades

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Requisitos de software: conceptos, tipos y propiedades

Semelhante a Requisitos de software: conceptos, tipos y propiedades (20)

Mais de YAMILA GASCON

Mais de YAMILA GASCON (15)

Requisitos de software: conceptos, tipos y propiedades