Ingeniería de requerimientos

de software: “Análisis”

Dpto. de Ingeniería de Sistemas y

Computación
Universidad de los Andes
Referencias

 El Lenguaje Unificado de Modelado. Grady Booch, James Rumbaugh e Ivar

Jacobson. Addison Wesley, 1999 Capítulos 16 y 17

 Object Oriented Software Engineering. Bernd Bruegge y Allen H.Dutoit.

Prentice Hall, 2000. Capítulo 4, pág. 100–106, 118-119

 Software Requirements. Karl. E.Wiegers. Microsoft Press, 1999. Capítulo 9,

pág. 153-162. Capítulo 11

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 2
Qué es Ingeniería de requerimientos
de software?
 Es el proceso de:

 Recopilar, descubrir (Elicitation),

 Analizar,

 Documentar (Especificar) y

 Validar (LograrMaterial
un preparado
acuerdo)
por Rubby Casallas.
rcasalla@uniandes.edu.co 3
Anarizar: determinar si los requerimientos son los
indicados, claros, completos, coherentes, se podrán
probar (testable) y resolver los conflictos aparentes.
Técnicas: abstraer, modelar, identificar funcionalidad,
identificar restricciones, características, prototipar,
simular, discutir, …

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 4
Modelamiento del mundo del
problema
 Abstraer de la realidad los conceptos de
interés para el problema
 Representarlos en el modelo utilizando un
lenguaje

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 5
Modelamiento del mundo del
problema
 Diagrama de clases de UML 2
 Modelar los conceptos y las relaciones en
los elementos del mundo del problema.
 Propósito:
 Ayudar a entender.
 Definir un vocabulario.
 Ayudar a elaborar preguntas.

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 6
 Ver material diagramas de clases …

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 7
Requerimientos basados en casos de
uso
Los usuarios, cuando utilizan una
aplicación lo hacen con un propósito
en mente.
Siempre esperan obtener algo
concreto de la aplicación como:
• Registrar un nuevo pedido
• Calcular el total vencido
• Ver la colección de canciones
• Enviar un correo …
• …

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 8
Requerimientos basados en casos de
uso
Los usuarios se pueden clasificar, desde el
punto de vista de un software, en roles o
grupos de personas que esperan cosas
particulares de la aplicación.

Un Actor representa un rol de un usuario.

Identificar los Actores es el primer paso para

identificar qué se espera de la aplicación.

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 9
Requerimientos basados en casos de
uso

Usos que cada Actor obtiene de la aplicación.

…
… … … …
… … … …
… … …

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 10
Actor

 Cualquier cosa con comportamiento, como

una persona (identificada por un rol), sistema
informatizado u organización.

 La misma persona física puede interpretar

varios roles como actores distintos

 El nombre del actor describe el papel

desempeñado Material preparado por Rubby Casallas.
rcasalla@uniandes.edu.co 11
Identificar Actores

 ¿Cuáles usuarios el sistema apoya para

desarrollar su trabajo?
 ¿Cuáles usuarios ejecutan las funciones
principales del sistema?
 ¿Cuáles usuarios desempeñan funciones
secundarias, como mantenimiento y
administración?
 ¿El sistema interactúa con hardware externo
o software?
Material preparado por Rubby Casallas
rcasalla@uniandes.edu.co 12
Ejemplo: Actores que utilizan Banner. Cada uno tiene propósitos distintos

• Crear
cursos
• Establecer
horarios de
los cursos
• …

• Agregar
estudiantes a
un curso
• Ver
desempeño
global de un
• Ver nota de
estudiante
un curso
• …
• …

• Registrar
notas de los
estudiantes
• …

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 13
Caso de uso

 Capturar el comportamiento deseado del

sistema en desarrollo, sin tener que
especificar cómo se implementa este
comportamiento
 Los casos de uso proporcionan un medio
para que los desarrolladores, los usuarios
finales del sistema y los expertos del
dominio lleguen a una comprensión
común del sistema
Material preparado por Rubby Casallas.
rcasalla@uniandes.edu.co 14
Casos de Uso

 Identificar los casos de uso para los actores

 Representarlo en un diagrama de casos de
uso
 Se utilizan verbos en infinitivo que
representan las acciones del usuario con el
sistema, por lo que siempre debe existir un
tipo de usuario(actor) que lo utilice

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 15
Ejemplo Diagrama de Casos de Uso

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 16
Especificar un Casos de Uso

 Es una descripción de un conjunto de

secuencias de acciones, incluyendo
escenarios o variantes, que ejecuta un
sistema para producir un resultado
observable de valor para un Actor

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 17
Escenario 1: Básico (todo sale bien)

Nombre del Consultar listado de cursos

escenario

Actor Profesor

Flujo de eventos 1. El Profesor ingresa al sistema indicando sus datos.

2. El sistema despliega cada una de las posibilidades del
sistema.
3. El Profesor indica que quiere sacar un listado de un
curso.
4. El sistema solicita ingresar la información del código,
sección y semestre de la materia.
5. El Profesor ingresa 21251, 02, 2018-1.
6. El sistema devuelve la información correspondiente al
curso indican el nombre, carnet, carrera y correo
electrónico de cada uno de los alumnos.

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 18
Escenario 2: Hay un problema, no termina
bien (no se obtiene lo que se requería)
Nombre del Consultar listado de cursos
escenario

Actor Profesor

Flujo de eventos 1. El Profesor ingresa al sistema indicando sus datos.

2. El sistema despliega cada una de las posibilidades del
sistema.
3. El Profesor indica que quiere sacar un listado de un
curso.
4. El sistema solicita ingresar la información del código,
sección y semestre de la materia.
5. El Profesor ingresa 21251, 02, 2018-1.
6. El sistema informa que el curso no es válido

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 19
Requerimientos basados en casos de
uso
 Tener claros los siguientes conceptos:
 Escenarios
 Describen un ejemplo del uso del sistema en términos
de una serie de interacciones entre un actor y el sistema
 Instancia del Caso de Uso

 Casos de uso
 Colección de escenarios con éxito y fallo relacionados,
que describe a los actores utilizando un sistema para
satisfacer un objetivo

Material preparado por Rubby Casallas.

rcasalla@uniandes.edu.co 20
Especificación de un caso de uso

 El comportamiento de un caso de uso se puede especificar

describiendo un flujo de eventos en forma textual

 Además de incluir cómo y cuándo empieza y acaba el caso de uso

 Se incluye cuándo interactúa con los actores

 Se Indica qué información se intercambia

 Se describe el flujo básico

 Se describe los flujos alternativos y las excepciones

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 21
Ejemplo:

 Flujo de eventos principal

1. El sistema pide al cliente un número de

identificación personal
2. El cliente introduce su id.
3. El sistema comprueba entonces la id. Para ver si
es válido
4. Si la identificación es válida el sistema acepta la
entrada

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 22
Ejemplo:

 Flujo de eventos excepcional

 El cliente puede cancelar una transacción en
cualquier momento, reiniciando el caso de uso
 No se efectúa ningún cambio en la cuenta del
cliente

 Flujo de eventos excepcional

 Paso 2: El cliente puede borrar su id en cualquier
momento antes de introducirlo

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 23
Ejemplo:

 Flujo de eventos excepcional

 Paso 4: Si el cliente introduce un id inválido, el
caso de uso vuelve a empezar
 Paso 4: Si el cliente introduce tres veces seguidas
un id inválido, el sistema cancela la transacción
completa, impidiendo que el Cliente utilice el
cajero durante 24 horas

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 24
Relaciones entre casos de uso

 Inclusión  <<include>>
 Indica que en el flujo de eventos del caso de uso
base se incluye el comportamiento del otro caso
de uso
 Factorizar comportamiento común (NO hacer
descomposición funcional)
 SOLAMENTE se hace cuando la parte común es
utilizada por otro caso de uso o cuando es
utilizada por otro actor

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 25
Relaciones entre casos de uso

Ejemplo <<include>>:

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 26
Relaciones entre casos de uso

Ejemplo <<include>>:

<<include>>
Reintegro Cuenta Corriente

Cliente Verificar Operación

<<include>>

Reintegro Cuenta de Crédito

Material preparado por Rubby Casallas
rcasalla@uniandes.edu.co 27
Relaciones entre casos de uso

 Extensión  <<extends>>
 Un caso de uso extiende otro caso de uso, si el
caso de uso extendido incluye el comportamiento
del otro bajo ciertas condiciones
 Se utiliza para modelar la parte de un caso de uso
que el usuario puede ver como comportamiento
opcional del sistema
 Se separa el comportamiento opcional del
obligatorio

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 28
Relaciones entre casos de uso
Ejemplo <<extends>>:

Extiende el caso de uso

retirar efectivo si, por
ejemplo, el cajero no tiene
papel entonces envía una
notificación de error

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 29
Documentación de un Caso de Uso

Identificador: Indispensable/Deseable Prioridad

Nombre Caso de Uso:

Autor:
Fecha
Actores involucrados:
Resumen:
Curso Básico Eventos:
Caminos Alternativos:
Caminos de Excepción:
Puntos de Extensión:
Pre - Condiciones:
Post- Condiciones:
Criterios de Aceptación
Borrador de Interfaz Gráfica

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 30
Documentación de un Caso de Uso

 Identificación del caso de uso: Única

 Indispensable/Desable: Necesidad del
requerimiento
 Prioridad: Alta/Media/Baja definida por el
usuario
 Nombre de caso de uso: Iniciar con un verbo
en infinitivo

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 31
Documentación de un Caso de Uso

 Autores:
 Persona(s) que elabora(ron) el formato
 Fecha:
 Fecha de elaboración del documento
 Descripción/Resumen:
 Describe la interacción que ocurre en el caso de uso (contexto)
 Curso básico de eventos:
 Describe los pasos que los actores y el sistema deben seguir
para completar la meta del caso de uso (No ocurre ningún error)

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 32
Documentación de un Caso de Uso

 Caminos alternativos:
 camino correcto que ocurre como parte integral
del caso de uso
 Caminos de excepción:
 Muestran procesamiento no común, en especial
cuando ocurren errores
 Puntos de extensión:
 Cuando se utiliza la relación de extends. Indica en
que punto exacto se extiende la funcionalidad
bajo ciertas condiciones
Material preparado por Rubby Casallas
rcasalla@uniandes.edu.co 33
Documentación de un Caso de Uso

 Precondiciones:
 Cosas que han debido ocurrir antes de iniciar la
interacción. Parte del contrato entre el caso de
uso y el mundo de afuera.
 Postcondición:
 Cuando el caso de uso termina exitosamente se
debe satisfacer.
 Criterios de aceptación:
 Condiciones para que el cliente acepte el
requerimiento como válido.
Material preparado por Rubby Casallas
rcasalla@uniandes.edu.co 34
Ejemplo: La Tienda de Discos

Material preparado por Rubby Casallas

rcasalla@uniandes.edu.co 35
Material preparado por Rubby Casallas
rcasalla@uniandes.edu.co 36