Diplomado en Informática

Aplicada
Actividad 2 Captura de requisitos

Dra. Anaisa Hernández González

Percepciones de un proyecto de SW
Fases-Flujos de trabajo de RUP
 Sumario
• Flujo de trabajo de Requisitos.
– Requisitos.
– Modelo de casos de uso del sistema.
• Organización en paquetes.
Flujo de trabajo de Requisitos
Definición de Requisitos
Es el proceso de averiguar, por lo general en
circunstancias difíciles, lo que se debe construir.

Los usuarios deben saber lo que quieren

•Cada uno sabe lo que hace, pero

ninguno tiene una visión global
•No saben cómo puede hacerse más eficiente
la operación en su conjunto.
•No saben qué parte de su trabajo puede
transformarse en software..
 Objetivo
Guiar el desarrollo hacia Necesidad de definir
el sistema correcto. objetivos generales
concretos

CON BENEFICIOS

Para el negocio
Para los actores
del negocio
 Flujo de trabajo
[Nueva entrada]
[sistema nuevo] [sistema existe]

Analizar el problema Entender las necesidades de

los Stakeholders

[Problema incorrecto]
Definir el sistema
Manejando cambios en
[Problema
los requerimientos
correctamente
direccionado]
[No se puede hacer
todo el trabajo]
Manejando el alcance
del sistema
[Trabajando en el alcance]

Diseñar realizaciones del proceso

 Trabajadores
Analista del sistema:
Define los alcances del sistema e identifica a
los actores y casos de uso que permiten
modelar completa y consistentemente el
sistema.
Especificador de casos de uso:
Describe detalladamente cada caso de uso de
acuerdo a las funcionalidades que engloba.
Arquitecto:
Describe la vista de la arquitectura del
modelo de casos de uso, definiendo la
prioridad de cada caso de uso para decidir en
qué iteración será desarrollado cada uno
 Artefactos

• Modelo de casos de uso

• Actor
• Caso de uso
• Descripción de la arquitectura
(vista del modelo de casos de
uso)
• Glosario de términos
• Prototipo de interfaz usuario
 Trabajadores Vs Actividades

Analista de Arquitecto Especificador Diseñador de

Sistemas interfaces

Encontrar
actores y CU Priorizar
los CU Detallar
Un CU
Prototipar
Estructurar la interfaz
El modelo CU
 Áreas de esfuerzo del análisis de requisitos

Evaluación del
Reconocimiento
problema y
del problema
síntesis de la
como lo ve el
solución
usuario
Modelado (Crear
modelos que ayuden
Revisión a entender la entidad
a construir) (DCU)
Firmar Especificación
(Prototipo de
contrato
alto nivel)
Pasos en el Flujo de trabajo de Requisitos

• Enumerar los requisitos candidatos.

• Comprender el contexto del sistema.
• Capturar los requisitos funcionales.
• Capturar los requisitos no funcionales.
Enumerar requisitos candidatos
Buenas ideas de los clientes, usuarios y
desarrolladores que pueden convertirse en
verdaderos requisitos.

Cada requisito candidato o característica

propuesta tiene:
• Nombre corto.
• Breve descripción.
• Estado (propuesto, aprobado, incluido o
validado).
• Coste estimado de implementación (por tipos de
recurso y horas-hombre).
• Prioridad (crítico, importante, secundario).
• Nivel de riesgo asociado (crítico, significativo,
ordinario).
Comprender el contexto del sistema
Los desarrolladores requieren un firme
conocimiento del contexto en el que se
desarrolla el sistema.

¿Cómo lograrlo? Con el modelado

del negocio

1. Diagrama de casos de uso del

negocio.
2. Descripción de los casos de uso.
3. Modelo de objetos del negocio.
4. Glosario.
Capturar requisitos funcionales
Identificando los casos de uso del
sistema
Para un usuario, un
caso de uso es un
modo de utilizar el
sistema

Si sabemos
Si sabemos describir
describir todos
todos los
los
casos de
casos de uso
uso que
que necesita
necesita un
un
usuario, entonces
usuario, entonces sabemos
sabemos lo lo
que debe
que debe hacer
hacer el
el sistema
sistema..
 Requisito funcional
“Una capacidad o condición que el
sistema cumplirá”

Co le s
mp sib
ren n
sib pre
les m
Co
Desarrolladores

Requisitos Clientes y Usuarios

 Clasificación de los requisitos funcionales

• Objetivos y metas para un sistema.

(Funcional) • Si están presentes  Cliente satisfecho

• Implícitos al sistema.
(No Funcional) • Puede que el cliente no los declare,
pero si no están se siente
insatisfecho.

• Características que van más allá de la

(Funcional y no
expectativas del cliente.
funcionales)
Identificación de requisitos funcionales a partir del modelo
del negocio

• Descripciones textuales.
• Diagrama de clases del
modelo de objetos del
negocio.
• Diagrama de actividades.

Actividades que serán

automatizadas
Diagrama de casos de uso del negocio

(Ejemplo: Empresa constructora)

Proyectista Atender proyecto nuevo

Diagrama de Actividad.
 Requisito funcional
• Registrar características de un
proyecto
• Analizar viabilidad económica
1.1 Evaluar factibilidad económica
1.2 Registrar resultados de la
evaluación.
3. Analizar viabilidad técnica
1.1 Evaluar factibilidad técnica
1.2 Registrar resultados de la
evaluación.
4. Registrar aprobación/rechazo de un
proyecto
 Capturar requisitos no funcionales

Requisito no funcional
“Propiedades o cualidades que el producto de
software debe tener”
 Requisitos no funcionales
• Apariencia o interfaz externa
• Usabilidad • Software
• Rendimiento • Hardware
• Soporte • Restricciones en
• Portabilidad el diseño y la
• Legales implementación
• Políticas culturales
• Confiabilidad
• Interfaz interna
• Ayuda y documentación en línea
• Seguridad
 Requisito de apariencia o
interfaz externa
• Muy legible.
• Simple de usar.
• Autoritario, para que los usuarios se
sientan confiados.
• Discreto para que los usuarios no lo noten.
• Colorido y atractivo para los niños.
• Interactivo.
• Profesional o tipo ejecutivo.
Requisitos de seguridad

• Confidencialidad
• Integridad
• Disponibilidad

SISTEMA
AUTOMATIZADO

SEGURIDAD FÍSICA

CONTROLES ADMINISTRATIVOS

AMBIENTE SOCIAL Y LEGAL

. Requisitos de seguridad
<
• Validar el ingreso al sistema de un
usuario
• Actualizar usuarios.
• Actualizar perfiles de usuario.
• Asignar perfil a usuario.
• Actualizar opciones del sistema.
• Asignar opciones a perfil.
• Cambiar contraseña.
• Hacer copia de seguridad.
• Configurar copia de seguridad.
• Registrar transacción en bitácora.
• Consultar transacciones realizadas.
 Pasos y artefactos en el flujo de requisitos

Paso Artefacto resultante

Enumerar requisitos Lista de

candidatos. características.
Comprender Modelo del negocio.
contexto.
Requisitos Modelo de CU
funcionales
Requisitos no Requisitos
funcionales. adicionales (muchos
aparecen en los CU).
 Actores
 No son parte del sistema
 Puede intercambiar información con el
sistema.
 Puede ser un recipiente pasivo de
información.
Actores
 Casos de Uso
Establece un acuerdo entre clientes y
desarrolladores sobre las condiciones y
posibilidades (requisitos) que debe
cumplir el sistema.
Artefacto narrativo que describe, bajo la forma de
acciones y reacciones, el comportamiento del sistema
desde el punto de vista del usuario (Jacobson).

Descripciones de la funcionalidad del sistema

independientes de la implementación.
Identificación de los CU del sistema a partir
del modelo del negocio

CASO DE USO = PROCESO QUE OBTIENE

UN RESULTADO DE
VALOR
 ¿Cómo identificar los casos de uso del
sistema?

Comenzar con los trabajadores del

negocio. Para cada uno:
• Decidir si el trabajador del negocio va a utilizar el
sistema de información.
• De ser así, identificar un actor en el modelo de casos de
uso del sistema.
• Para cada caso de uso del negocio en el que participe el
trabajador del negocio, crear un caso de uso del
sistema.
• Repetir estos pasos para todos los trabajadores del
negocio.
 Resumiendo...
• Cada forma en que los actores usan el
sistema se representa con un caso de uso
• Los CU son fragmentos de funcionalidad
que el sistema ofrece para aportar un
resultado de valor para los sus actores.
• Un CU especifica una secuencia de acciones
que el sistema puede llevar a cabo
interactuando con sus actores, incluyendo
alternativas dentro de la secuencia.
 Resumiendo...

•Un caso de uso entrega un resultado que añade

valor a un actor en concreto.

A usuarios
Al actor iniciador individuales reales

Evita CU muy grandes

Evita CU muy pequeños
 Casos de uso
Ejemplo

Jefe de obra Económico

Aprobar/rechazar proyecto
Evaluar un proyecto
económicamente
Evaluar un proyecto
técnicamente
 Casos de uso
Casos especiales: Manejo del tiempo
En algunos sistemas se tienen actividades
que se ejecutan periódicamente, como por
ejemplo, el cálculo de intereses de los
clientes de un banco se realizan todas la
noches. Para modelar esto se puede realizar
lo siguiente:

Calcular intereses
Reloj
 Perfeccionar la definición de
casos de uso

CASOS GENERALIZACIÓN/
MÚLTIPLES ESPECIALIZACIÓN
DE USO DE ACTORES
GENERALIZACIÓN/E
SPECIALIZACIÓN
DE CASOS DE USO
 ¿Cuándo escribir un caso de uso
independiente?

 Se duplica comportamiento en otros CU.

 Un CU es complejo y largo, y su
separación facilita que sean manejables y
comprensibles.
 Crear casos de uso independientes (Representar relaciones
<<include>> o <<extend>> entre los casos de uso).
 Reescribir los casos de uso de las actividades ramificadas.
 Relación de inclusión
Ejemplo
• Casos de uso que tienen una parte común en sus
funcionalidades.
<<include>>

Pagar un servicio
por Internet
Usuario
<<include>> Verificar
permiso
Chequear pagos
realizados
 Relación de inclusión
Ejemplo
• Se observa una relativa independencia en una parte del
flujo de trabajo que se describe, aún cuando no se
reutilice. De ese subproceso solo interesa el resultado.

<<include>>

Pagar un servicio
por Internet
Usuario
Redefinir deuda
pendiente
 Relación de extensión
Ejemplo
• Comportamiento opcional.
<<extend>>
Enviar e-mail a
superior
<<extend>>
Analizar
Especialista discrepancias
del banco
Resolver
discrepancia
 Relación de extensión
Ejemplo
• Comportamiento que es ejecutado solamente bajo
ciertas condiciones.

<<extend>>

Pagar un servicio
por Internet
Especialista
del banco Buscar cuentas
alternativas
 Relación de extensión
Ejemplo
• Flujos distintos y diferentes que pueden ejecutarse
sobre la base de la selección del actor.

<<extend>>

Chequear pagos
realizados
Usuario
Reportar
discrepancias
 Casos de uso múltiples
Ejemplo

Usuario Pagar un servicio por

internet
<<include>> <<extend>>
<<include>>

Reportar
Verificar permiso Redefinir deuda
incongruencias
Generalización/ Especialización entre
casos de uso
Ejemplo

Usuario Pagar

Pagar con Pagar en

tarjeta de crédito efectivo
 Generalización/ Especialización entre
actores
Ejemplo

Especialista Consultor Usuario

del banco de cuentas

Analizar Chequear pagos

discrepancias Chequear realizados
estado de una
cuenta bancaria
 Descripción de los casos de uso en
formato de alto nivel
Caso de uso: <Nombre>
Actores: <Nombre de los actores>
Descripción: <Frases que describan las
acciones indicando los actores
involucrados, debe quedar claro
cómo se inicia y termina el
proceso y de que forma
intervienen los actores>
Referencias: <Listado de requerimientos y
casos de uso asociados,
indicando tipo de asociación
(include o extend)>
 Descripción de los casos de uso en
formato de alto nivel

Precondiciones: <Cosas que tienen que

cumplirse en el sistema para
que se ejecute el CU>
Poscondiciones: <Condiciones en las que
queda el sistema cuando
termina la ejecución del CU>
Requerimientos especiales: <Precisar de qué
manera restricciones de tiempo
de respuesta, seguridad,
velocidad, disponibilidad,
exactitud o uso de memoria
afectan al caso de uso>
 Descripción de casos de uso
Ejemplo
Caso de uso: Aprobar/rechazar un proyecto

Actores: Jefe de obra

Descripción:
El caso de uso se inicia cuando se han realizado las evaluaciones técnica y
económica de una propuesta de un proyecto y el Jefe de obra debe valorar si
se aprueba o no su ejecución. El sistema debe permitir ver los resultados de
estas evaluaciones y permitir que se registre las conclusiones del Jefe de
obra (aprobar/rechazar y alguna otra consideración que justifique su
decisión, culminando la ejecución del caso de uso.
 Descripción de casos de uso
Ejemplo

Referencias R4

Precondiciones Existan proyectos ya evaluados técnica y económicamente

y estén pendientes de aprobación o rechazo

Poscondiciones Se cambia el estado del proyecto a rechazado o

aprobado y se asocian las causas que motivaron la
decisión

Requerimientos -
especiales
 Prototipo visual

Visión del sistema a nivel de las

pantallas diseñadas para cada
caso de uso, pero con
comportamiento estático, que se
presenta al usuario para verificar
los requerimientos funcionales.
¿Qué casos de uso se desarrollará en
cada release de construcción?

Clasificar los CU de acuerdo a su impacto en la

arquitectura
• Críticos
• Secundarios
• Auxiliares
• Opcionales
Más importantes para los usuarios
porque cubren las principales tareas o
funciones que el sistema ha de
realizar. Definen la arquitectura básica.

• Sirven de apoyo a los casos de

uso críticos.
• Involucran funciones
secundarias.
• Tienen un impacto más modesto
sobre la arquitectura, pero
deben implementarse pronto
porque responden a
requerimientos de interés para
los usuarios.
• No son claves para la arquitectura.
• Completan casos de uso críticos o
secundarios.

Responden a funcionalidades
que pueden o no estar en la
aplicación, pero que no son
imprescindibles en las primeras
versiones.
Organización en paquetes
 Paquetes
Organización de los elementos
Tamaño
excesivo Necesidad de dividir en
subconjuntos más
pequeños

Paquetes
PARTICIONAN LOS
DIAGRAMAS
 Paquetes

COHESIVOS DÉBILMENTE ACOPLADOS

(Sus contenidos (Minimizar las
deben estar
dependencias entre
fuertemente
paquetes)
relacionados)
 Deben crearse basándose en los requisitos
funcionales y en el dominio del problema.
 Reconocibles por las personas con
conocimiento del dominio.
 Paquetes de servicio
SERVICIO: Conjunto coherente de acciones relacionadas
funcionalmente, que se utilizan en varios CU.

PAQUETE DE SERVICIO: Contiene un conjunto de

elementos relacionados
funcionalmente.

 Son altamente reutilizables.

 Pueden emplearse en varias
realizaciones de CU diferentes
 Identificación de paquetes

Asignar la mayor parte de un cierto

número de CU a una paquete concreto
 CU requeridos para dar soporte a un determinado proceso de
negocio.
 CU requeridos para dar soporte a un determinado actor del sistema.
 CU que están relacionados mediante relaciones de generalización y
extensión.
 CU que se ejecutan en un nodo
 Notación de los Paquetes
PAQUETES
SUBORDINADOS
Nombre del paquete

Nombre del Nombre del

paquete A paquete B

B depende de A, esto significa que B

conoce de alguna forma a A
 Paquetes
Ejemplo

SEGURIDAD AUTORIZACIÓN
DE PROYECTOS
 Paquete de seguridad

Actualizar información de Actualizar perfiles de usuario

usuarios Actualizar opciones del sistema

Establecer cuándo se harán las

copias de seguridad
Administrador
del sistema
Reloj

Cambiar contraseña
Usuario
Generar copia de seguridad

Acceder al sistema
Auditar el sistema
Auditor
 Paquete de autorización de
proyectos

Jefe de obra Económico

Aprobar/rechazar proyecto
Evaluar un proyecto
económicamente
Evaluar un proyecto
técnicamente
 Establecer un común
entendimiento con el cliente
sobre los requerimientos
del proyecto Casos de uso un
importante artefacto
que pone énfasis en
la vista del dominio a
partir de un proceso
 Bibliografía
LEFFINGWELL, Dean; “Features, Use Cases,
requirements, Oh My!”.2000. Rational Software.
Http://www.rational.com/media/whitepapers/featucreqom.pdf

RUMBAUGH, James, JACOBSON, Ivar; BOOCH,

Grady, “El lenguaje unificado de modelado”.2000.
Addison Wesley. Capítulo 5, 10 y 13 Páginas 55-58, 87-90,
156-162, 120-121, 399-402, 365.
 Bibliografía
JACOBSON, Ivar; BOOCH, Grady, RUMBAUGH,
James, “El Proceso Unificado de Desarrollo de
Software”.2000. Addison Wesley.
Capítulos 3, 6 Y 7páginas 31-54, 105-164

PRESSMAN,Roger “Ingeniería del Software. Un

enfoque práctico”.2002. McGraw-Hill/Interamericana
de España. Páginas 184-186 “Técnicas para facilitar las
especificaciones de la aplicación.

BOOCH, Grady, RUMBAUGH, James, JACOBSON,

Ivar; “El lenguaje unificado de modelado”.2000.
Addison Wesley. Capítulos 12, 16, 17 Páginas 147-158,
191-210.
¿Qué le pasa a un proyecto?