INGENIERA DE

REQUERIMIENTOS

NOTAS DEL CURSO
Ingeniera de Software I
DRA. MARIA DEL PILAR GMEZ GIL
Versin : 01-Oct-12

(C) P. Gmez-Gil, INAOEP 2009
INGENIERA DE
REQUERIMIENTOS*
Entender los requerimientos de una solucin basada en
software es una de las tareas mas difciles para un(a) Ing. de
software.
Como otras actividades de Ing. de Sw, sta debe adaptarse a
las necesidades del proceso, proyecto, producto y gente que
hace el software.
La Ing. de Requerimientos provee de un mecanismo apropiado
para entender que quiere el consumidor, analizar sus
necesidades, valorar la factibilidad de construccin, negociar
una solucin razonable, especificar de manera no ambigua
una solucin, validar la especificacin y administrar los
requerimientos conforme se transforman.

*Referencia: captulo 7 libro de texto (Pressman 2005)
(C) P. Gmez-Gil, INAOEP 2009
Tareas de la Ing. de
Requerimientos
Iniciacin (Inception)
Obtencin (Elicitation)
Elaboracin
Negociacin
Especificacin
Validacin (Validation)
Administracin
Algunas de estas funciones pueden ocurrir en
paralelo y ajustarse a las necesidades del
proyecto

(C) P. Gmez-Gil, INAOEP 2009
Iniciacin
Como se empieza un proyecto? Algunas veces inicia por
conversaciones informales, otras de manera mas formal;
normalmente como resultado de una necesidad
importante

En esta parte, los ingenieros de software realizan
preguntas libres de contexto (generales), para
establecer un entendimiento bsico del problema,
determinar las personas que quieren una solucin, la
naturaleza de la solucin, y la efectividad de las
colaboraciones y comunicaciones preeliminares que se
generan entre el consumidor y el desarrollador
(C) P. Gmez-Gil, INAOEP 2009
Obtencin de Requerimientos
Se refiere a definir formalmente los
requerimientos de la solucin. Es difcil
porque como ya se ha visto:
Hay problemas de definicin de alcances
Hay problemas de entendimiento entre los
involucrados
Hay problemas de volatilidad (los
requerimientos cambian con el tiempo)
(C) P. Gmez-Gil, INAOEP 2009
Elaboracin
Esta actividad expande y refina la informacin obtenida en la
tarea de iniciacin
Se enfoca en realizar modelos tcnicos refinados de las
funciones del software, caractersticas y limitantes.
Es bsicamente una funcin de modelado. Se conduce a
travs de la definicin de escenarios del usuario que
describen la interaccin del usuario final con el sistema
Se define el dominio del problema desde varios puntos de
vista: informacin, funciones y comportamiento
(C) P. Gmez-Gil, INAOEP 2009
Negociacin
Los usuarios y consumidores normalmente piden mas
de lo que se puede hacer con los recursos con que se
cuenta.
Casi siempre diferentes involucrados (stakeholders)
piden cosas diferentes, por lo que hay que conciliar
intereses a travs de negociaciones.
Hay varias maneras para negociar, y depende de la
cultura de la organizacin y tamao del proyecto
(C) P. Gmez-Gil, INAOEP 2009
Especificacin
Especificacin significa diferentes cosas para diferentes
personas en el rea de Ing. de software.
Este es el producto de trabajo final de la ingeniera de
requerimientos.
Sirve como base para actividades subsecuentes.
Describe la funcin y desempeo de un sistema y las
restriccin que tiene.
Hay muchas tcnicas para escribir especificaciones:
diagramas, narraciones en prosa, modelos matemticos,
dibujos, etc.
(C) P. Gmez-Gil, INAOEP 2009
Validacin
El producto generado por la ingeniera de
requerimientos debe ser evaluado en trminos de
congruencia y calidad. Se debe asegurar que la
especificacin concuerda con las expectativas del
usuario y que no es ambigua.
Deben detectarse y corregirse errores, omisiones e
inconsistencias con respecto a los estndares
establecidos en el proyecto.
El mecanismo comn de validacin es la revisin tcnica
formal.
(C) P. Gmez-Gil, INAOEP 2009
Administracin de
requerimientos
Actividades que ayudan al equipo de trabajo a identificar, controlar y
seguir los requerimientos y cambios que ocurren en ellos a travs
de todo el proceso de desarrollo.
La administracin empieza con la identificacin de cada
requerimiento. Posteriormente se generan tablas que permitirn
darles seguimiento. Algunas de stas son:
Tablas de caractersticas
Tablas de fuentes
Tablas de dependencias
Tablas de subsistemas
Tablas de interfaces
(C) P. Gmez-Gil, INAOEP 2009
Descripcin detallada de las Tareas de la
Ing. de Requerimientos
Iniciacin (Inception)
Obtencin (Elicitation)
Elaboracin
Negociacin
Especificacin
Validacin (Validation)
Administracin
(C) P. Gmez-Gil, INAOEP 2009
Pasos del proceso de Iniciacin.
1. Identificacin de involucrados
(Stakeholders).
2. Reconocimiento de diferentes puntos de
vista.
3. Desarrollo de un ambiente colaborativo.
Implica identificar puntos en comn,
reas de conflicto e inconsistencias.
4. Aplicacin de preguntas iniciales.
(C) P. Gmez-Gil, INAOEP 2009
Algunas preguntas Iniciales
tpicas
Primeras
Quin est detrs de la requisicin de este trabajo?
Quin usar la solucin ?
Cual es el beneficio econmico de una solucin exitosa?
Hay otras fuentes para obtener la solucin buscada que se
necesitarn?
Siguientes:
Qu sera una buena salida para generar una solucin
eficiente?
Que problemas aparecern con esta solucin?
Podra describirme el medio ambiente en que la solucin
funcionar?
Qu aspectos de desempeo o limitaciones afectan la
solucin?
(C) P. Gmez-Gil, INAOEP 2009
Algunas preguntas tpicas (2)
Siguientes:
Es Usted la persona correcta a
preguntarle? Son sus respuestas oficiales?
Considera mis preguntas relevantes al
problema que Usted tiene?
Le estoy preguntando demasiado?
Puede alguien mas darme informacin
adicional ?
(C) P. Gmez-Gil, INAOEP 2009
Caractersticas de un(a) buen(a) Ing.
de Requerimientos

Habilidad para captar conceptos abstractos sintetizndolos y
reorganizndolos en divisiones lgicas.
Habilidad para obtener hechos importantes de situaciones
confusas.
Habilidad para entender el medio ambiente.
Habilidad para comunicarse bien en forma verbal y escrita.
Habilidad para "ver el bosque a travs de las hojas".
(C) P. Gmez-Gil, INAOEP 2009
Generacin de las Necesidades del Cliente
Herramientas para obtener informacin de las
necesidades del Cliente:
Cuestionarios
Entrevistas
Estudio de campo
Revisin de documentos en la base de datos de
conocimiento de la organizacin
Autoaprendizaje

(C) P. Gmez-Gil, INAOEP 2009

Cuestionarios
Los cuestionarios son tiles especialmente cuando hay una gran
cantidad de usuarios finales.


El diseo de un cuestionario requiere de tiempo y dedicacin, ya
que un cuestionario deficiente produce frustracin y prdida de
inters en el usuario.

El cuestionario debe ser fcil de procesar

En caso de que el cuestionario no se aplique a todos los
usuarios, se debe seleccionar correctamente al grupo que
realice el cuestionario.
(C) P. Gmez-Gil, INAOEP 2009
Entrevistas

La entrevista es una herramienta muy til para
obtener informacin.

Se puede llevar a cabo en cualquier nivel
dentro de la organizacin, desde el presidente
hasta el obrero en la lnea de ensamble.

La entrevista debe prepararse
adecuadamente.
(C) P. Gmez-Gil, INAOEP 2009
Consejos para Realizar una
Entrevista
1) Preparacin de la entrevista:

a) Buscar el apoyo del gerente de departamento o jefe donde
se llevar a cabo la entrevista.
b) Preparar la entrevista para un tiempo determinado, y
drselo a conocer al entrevistado.
c) Identificar de antemano la posicin del entrevistado en la
organizacin, sus responsabilidades y actividades.
d) Acordar de antemano la hora y el lugar de la entrevista.
Evitar las interrupciones.
e) Preparar el contenido de la entrevista: temas, preguntas
etc.

(C) P. Gmez-Gil, INAOEP 2009
Consejos Para Realizar Una
Entrevista (continuacin)

2) Conduciendo la entrevista:

a) Presentarse al entrevistado y presentar al proyecto en el que se trabaja.
b) Asegurarse de se entendieron correctamente las responsabilidades del
entrevistado. Realizar preguntas de la forma: "tengo entendido que... ".
c) Estudiar el mtodo de decisin del entrevistado.
d) Evitar palabras tcnicas o rebuscadas.
e) Darse una idea del "sentimiento" del entrevistado con respecto al
sistema.
f) Escuchar al entrevistado.
g) Preguntar al entrevistado sobre algunas ideas propias que pudieron
olvidarse.
h) Al final de la entrevista resumir las conclusiones y escribir una bitcora.
i) No tomar demasiadas notas.
j) Grabar la entrevista la mayora de las veces resulta anti-productivo.

(C) P. Gmez-Gil, INAOEP 2009
- Respuestas falsas por temor a admitir ignorancia
- El usuario tiende a decir lo que el entrevistador quiere or
- Boicoteo de informacin
- Actitud cerrada hacia cambios
- Pesimismo total
- Desvo del objetivo fundamental hacia otros problemas de la
organizacin
Algunos Problemas Durante las
Entrevistas
(C) P. Gmez-Gil, INAOEP 2009
Tareas de la Ing. de
Requerimientos
Iniciacin (Inception)
Obtencin (Elicitation)
Elaboracin
Negociacin
Especificacin
Validacin (Validation)
Administracin
(C) P. Gmez-Gil, INAOEP 2009
Continuando con el anlisis...
Segn [Larman 99] las principales
actividades asociadas al anlisis son:
Definir los casos de uso
Definir el modelo conceptual
Definir los diagramas de colaboracin
Definir diagramas de diseo de clases
(C) P. Gmez-Gil, INAOEP 2009
Obtencin de Requerimientos
Incluye juntas colaborativas de definicin, despliegue de funciones y
descripcin de escenarios
Los productos que genera son:
Una declaracin de necesidades y factibilidades
Una declaracin delimitada del alcance del sistema o producto
Una lista de consumidores, usuarios y otros involucrados
(stakeholders) que participaron en la definicin del documento
Una descripcin del medio ambiente tcnico del sistema
Una lista de requerimientos, de preferencia organizados por
funcin, y las restricciones de dominio que los afectan
Un conjunto de escenarios de uso que dan idea del uso del
producto en diferentes condiciones operativas
Prototipos desarrollados
(C) P. Gmez-Gil, INAOEP 2009
Desarrollo de casos de uso
Un caso de uso describe el comportamiento del sistema en
condiciones diferentes, as como la respuesta del sistema a las
requisiciones de uno o mas stakeholders
El primer paso es definir por escrito los actores que estarn
involucrados en el sistema. Los actores son personas o dispositivos
que usan el producto dentro de un contexto o funcin. Representan
los roles de las personas o dispositivos
De manera formal un actor es cualquier cosa que se comunica con
el sistema o producto y que es externa a ste. Cada actor puede
tener uno o mas objetivos cuando usa el sistema.
Se pueden identificar actores primarios, aquellos que interactan
directamente con el sistema, y secundarios, aquellos que de alguna
manera dan soporte al sistema, a fin de que lo primarios puedan
realizar su trabajo
(C) P. Gmez-Gil, INAOEP 2009
Desarrollo de casos de uso (2)
Una vez que se han identificado los actores, lo siguiente
es desarrollar el caso de uso. Jacobson sugiere hacer
las siguientes preguntas:
Quienes son los actores primarios y secundarios?
Cuales son las metas de los actores?
Que precondiciones deben existir antes de que la historia
empiece?
Que tareas principales son realizadas por el actor?
Que excepciones se pueden considerar con respecto a la
descripcin de la historia?
Contina...
(C) P. Gmez-Gil, INAOEP 2009
Desarrollo de casos de uso (2)
Que variaciones en las interacciones del actor son
posibles?
Qu sistemas de informacin adquirir, producir o
cambiar el actor?
El actor tendr que informar al sistema acerca de
cambios en el medio ambiente externo?
Que informacin desea el usuario del sistema?
Desea el actor ser informado acera de cambios
inesperados?

(C) P. Gmez-Gil, INAOEP 2009
Smbolos usados en los Diagrama de
Casos de Uso de UML*
Caso de
Uso
(C) P. Gmez-Gil, INAOEP 2009
Ejemplo de un Diagrama de Casos
de Uso
1

1. Sistema de control de registro para maquinas tragamonedas. Alvarez, V. et al.Otoo 04
(C) P. Gmez-Gil, INAOEP 2009
Escenarios
Cada ovalo en el diagrama de casos de
uso debe ser descrito detalladamente, a
travs de un escenario.

(C) P. Gmez-Gil, INAOEP 2009
Informacin principal a Incluir en la
descripcin de un escenario
Nombre del caso de uso
Actor principal
Objetivo
Pre-condiciones
Iniciador del caso de uso
Descripcin del Escenario
Excepciones
Prioridades
Disponibilidad
Frecuencia de Uso
Canales de comunicacin con actores
Canales con actores secundarios
Puntos an no resueltos
(C) P. Gmez-Gil, INAOEP 2009
D
e
s
c
r
i
p
c
i

n

e
s
c
e
n
a
r
i
o
s

[Computer, 02]
(C) P. Gmez-Gil, INAOEP 2009
O
t
r
a

P
l
a
n
t
i
l
l
a

p
a
r
a

d
e
s
c
r
i
b
i
r

e
s
c
e
n
a
r
i
o
s

[Larman,99]
(C) P. Gmez-Gil, INAOEP 2009
Ejemplo de caso de uso del
proyecto Casa Segura
Involucrados:
Dueo de la casa
Administrador de la configuracin (probablemente la
misma persona que el dueo)
Sensores
Subsistema de monitoreo
Escogiendo como actor al dueo de la casa
(C) P. Gmez-Gil, INAOEP 2009
Sistema Casa Segura
(C) P. Gmez-Gil, INAOEP 2009
Interacciones de dueo de la
casa con el sistema
Introduce un password para permitir otras
interacciones
Pregunta sobre el status de una zona de
seguridad
Pregunta sobre el status de un sensor
Oprime el botn pnico en caso de una
emergencia
Activa o desactiva el sistema de seguridad
(C) P. Gmez-Gil, INAOEP 2009
Ejemplo de caso de uso del
proyecto Casa Segura
[Pressman 2004]
(C) P. Gmez-Gil, INAOEP 2009
Diagrama de actividades
Representa el flujo de interaccin con respecto
a un escenario especfico
Los rectngulos indican funciones, las flechas
indican flujo, los diamantes indican ramas de
decisin y las lneas horizontales indican que
ocurren actividades en paralelo.

(C) P. Gmez-Gil, INAOEP 2009
Diagrama de actividades para
Licitacin de Requerimientos
[Pressman 2004]
(C) P. Gmez-Gil, INAOEP 2009
Diagramas tipo Swimlane
(carriles)
Son una variacin de los de actividades.
Permiten representar el flujo de
actividades y al mismo tiempo indicar que
actor(a) o clase tiene la responsabilidad
de la accin descrita por el rectngulo. Se
divide con lneas verticales el diagrama,
una columna por cada actor (como los
canales de nado en una piscina).
(C) P. Gmez-Gil, INAOEP 2009
Diagrama tipo carriles
Fig. 8.8 [Pressman 04]
(C) P. Gmez-Gil, INAOEP 2009
Unified Modeling Language (UML)
1

UML es:
Un lenguaje que permite especificar,
visualizar y construir artefactos de software
Un lenguaje destinado a los sistemas que
utilizan conceptos orientados a objetos
Notacin estndar para construir modelos
orientados a objetos
Solo una notacin. No es un mtodo o
proceso de desarrollo

(C) P. Gmez-Gil, INAOEP 2009
Historia de UML
En el 2009 ya
se liber la versin 2.2
Diagramas de UML 2.0
Tres tipos, 13 diagramas:
1. Diagramas de estructura esttica. Incluyen Diagramas
de Clase, Diagramas de Objetos, Diagramas de Componente,
Diagramas de Estructura Compuesta, Diagramas de Paquete y
Diagramas de Entrega (Deployment)
2. Diagramas de Comportamiento. Incluyen Diagramas de
Caso de Uso, Diagramas de Actividades y Diagramas de
Estado de Mquina
3. Diagramas de Interaccin. Incluyen Diagramas de
Secuencia, Diagramas de Comunicacin, Diagramas de
Sincronizacin (timing) y Diagramas Generales de Interaccin
(Interaction Overview Diagram)



(C) P. Gmez-Gil, INAOEP 2009
(C) P. Gmez-Gil, INAOEP 2009

Consultar
Object Management Group: UML Resource
Page:
http://www.uml.org/


Consultar
Object Management Group: UML Resource
Page:
http://www.uml.org/

ANEXO.
EJEMPLO DE CASOS DE USO:
SISTEMA PRISCUS
(C) P. Gmez-Gil, INAOEP 2009
Diagrama de flujo de datos de
Priscus
[Perea-Centeno 2012]
Bibliografa Anexo
Perea Centeno Liliana. Interfaz web para el
reconocimiento de texto manuscrito y antiguo a travs
del proyecto Priscus. Tesis de Licenciatura. Instituto
de Estudios Superiores A.C, Benemrita Universidad
Autnoma de Puebla. 2012
Cuevas-Farfn E, Gmez-Gil P. PRISCUS:
Reconocedor ptico de caracteres manuscritos y
antiguos. Memorias tcnicas del 9 Encuentro de
Investigacin. Instituto Nacional de Astrofsica, ptica
y Electrnica. Tonantzintla, Puebla. 6 y 7 de
Noviembre 2008.