TAREAS DE LA INGENIERÍA DE

REQUERIMIENTOS
 INGENIERÍA DE REQUERIMIENTOS*
 Entender los requerimientos de una solución basada en software es

una de las tareas mas difíciles 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 construcción, negociar una solución razonable,

especificar de manera no ambigua una solución, validar la

especificación y administrar los requerimientos conforme se

transforman. *Referencia: capítulo 7 libro de texto (Pressman 2005)

 Tareas de la Ing. de Requerimientos

 Iniciación (Inception)

 Obtención (Elicitation)

 Elaboración

 Negociación

 Especificación

 Validación (Validation)

 Administración

 Algunas de estas funciones pueden ocurrir en paralelo y

ajustarse a las necesidades del proyecto

 Iniciación
 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 básico del problema, determinar las personas

que quieren una solución, la naturaleza de la solución, y la

efectividad de las colaboraciones y comunicaciones

preliminares que se generan entre el consumidor y el

desarrollador
Obtención de Requerimientos
 Se refiere a definir formalmente los requerimientos

de la solución. Es difícil porque como ya se ha visto:

 Hay problemas de definición de alcances

 Hay problemas de entendimiento entre los

involucrados

 Hay problemas de volatilidad (los requerimientos

cambian con el tiempo)
 Elaboración
 Esta actividad expande y refina la información obtenida
en la tarea de iniciación

 Se enfoca en realizar modelos técnicos refinados de las

funciones del software, características y limitantes.

 Es básicamente una función de modelado. Se conduce

a través de la definición de escenarios del usuario que
describen la interacción del usuario final con el sistema

 Se define el dominio del problema desde varios puntos

de vista: información, funciones y comportamiento
 Negociación

 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 través de negociaciones.

 Hay varias maneras para negociar, y depende de la

cultura de la organización y tamaño del proyecto

Los empleados, los proveedores, los accionistas o incluso el Gobierno

pueden considerarse stakeholders de las empresas.
 Especificación
 Especificación significa diferentes cosas para diferentes

personas en el área de Ing. de software.

 Este es el producto de trabajo final de la ingeniería de

requerimientos.

 Sirve como base para actividades subsecuentes.

 Describe la función y desempeño de un sistema y las

restricción que tiene.

 Hay muchas técnicas para escribir especificaciones:

diagramas, narraciones en prosa, modelos matemáticos,

dibujos, etc.
 Validación
 El producto generado por la ingeniería de
requerimientos debe ser evaluado en términos de
congruencia y calidad. Se debe asegurar que la
especificación concuerda con las expectativas del
usuario y que no es ambigua.

 Deben detectarse y corregirse errores, omisiones e

inconsistencias con respecto a los estándares
establecidos en el proyecto.

 El mecanismo común de validación es la revisión

técnica formal.
 Administración de requerimientos

 Actividades que ayudan al equipo de trabajo a

identificar, controlar y seguir los requerimientos y

cambios que ocurren en ellos a través de todo el

proceso de desarrollo.

 La administración empieza con la identificación de

cada requerimiento. Posteriormente se generan tablas

que permitirán darles seguimiento. Algunas de éstas

son:
 Tablas de características

 Tablas de fuentes

 Tablas de dependencias

 Tablas de subsistemas

 Tablas de interfaces
Descripción detallada de las Tareas de
la Ing. de Requerimientos

 Iniciación (Inception)

 Obtención (Elicitation)

 Elaboración

 Negociación

 Especificación

 Validación (Validation)

 Administración
 Pasos del proceso de Iniciación.

1. Identificación de involucrados (Stakeholders).

2. Reconocimiento de diferentes puntos de vista.

3. Desarrollo de un ambiente colaborativo.

Implica identificar puntos en común, áreas de
conflicto e inconsistencias.

4. Aplicación de preguntas iniciales.

 Algunas preguntas Iniciales típicas

1. Primeras
 ¿Quién está detrás de la requisición de este trabajo?
 ¿Quién usará la solución ?
 ¿ Cual es el beneficio económico de una solución
exitosa?
 ¿ Hay otras fuentes para obtener la solución buscada
que se necesitarán?
2. Siguientes:
 ¿ Qué sería una “buena salida” para generar una
solución eficiente?
 ¿ Que problemas aparecerán con esta solución?
 ¿ Podría describirme el medio ambiente en que la
solución funcionará?
 ¿ Qué aspectos de desempeño o limitaciones afectan
la solución?
 Algunas preguntas típicas (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 información adicional ?

 Características de un(a) buen(a)
Ing. de Requerimientos

 Habilidad para captar conceptos abstractos

sintetizándolos y reorganizándolos en divisiones lógicas.

 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 través de las hojas".

 Generación de las Necesidades del
Cliente
 Herramientas para obtener información de las
necesidades del Cliente:

 Cuestionarios

 Entrevistas

 Estudio de campo

Revisión de documentos en la base de datos de

conocimiento de la organización

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

 El diseño de un cuestionario requiere de tiempo y

dedicación, ya que un cuestionario deficiente produce
frustración y pérdida de interés en el usuario.

 El cuestionario debe ser fácil 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.
 Entrevistas
 La entrevista es una herramienta muy útil para obtener
información.

 Se puede llevar a cabo en cualquier nivel dentro de la

organización, desde el presidente hasta el obrero en la
línea de ensamble.
 La entrevista debe prepararse adecuadamente.
 Consejos para Realizar una Entrevista
1) Preparación 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
dárselo a conocer al entrevistado.
c) Identificar de antemano la posición del entrevistado en la
organización, 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.
 Consejos Para Realizar Una
Entrevista (continuación)

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 método de decisión del entrevistado.

d) Evitar palabras técnicas o rebuscadas.

e) Darse una idea del "sentimiento" del entrevistado con

respecto al sistema.
2) Conduciendo la entrevista:

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 bitácora.

i) No tomar demasiadas notas.

j) Grabar la entrevista la mayoría de las veces resulta anti-

productivo.

(C) P. Gómez-Gil, INAOEP 2009

 Algunos Problemas Durante las
Entrevistas
- Respuestas falsas por temor a admitir ignorancia

- El usuario tiende a decir lo que el entrevistador quiere oír

- Boicoteo de información

- Actitud cerrada hacia cambios

- Pesimismo total

- Desvío del objetivo fundamental hacia otros problemas

de la organización
Tareas de la Ing. de Requerimientos

Iniciación (Inception)
Obtención (Elicitation)
Elaboración
Negociación
Especificación
Validación (Validation)
Administración
Continuando con el análisis...

 Según [Larman 99] las principales

actividades asociadas al análisis son:
 Definir los casos de uso

 Definir el modelo conceptual

 Definir los diagramas de colaboración

 Definir diagramas de diseño de clases

 Obtención de Requerimientos
 Incluye juntas colaborativas de definición, despliegue de

funciones y descripción de escenarios

 Los productos que genera son:

 Una declaración de necesidades y factibilidades

 Una declaración delimitada del alcance del sistema o

producto

 Una lista de consumidores, usuarios y otros involucrados

(stakeholders) que participaron en la definición del

documento
Obtención de Requerimientos
 Una descripción del medio ambiente técnico del

sistema

 Una lista de requerimientos, de preferencia

organizados por función, 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. Gómez-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

estarán involucrados en el sistema. Los actores son

personas o dispositivos que usan el producto dentro de un

contexto o función. 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

interactúan 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. Gómez-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 descripción de la “historia”?
 Desarrollo de casos de uso (2)

 Que variaciones en las interacciones del actor son

posibles?

 Qué sistemas de información adquirirá, producirá o

cambiará el actor?

 El actor tendrá que informar al sistema acerca de

cambios en el medio ambiente externo?

 Que información desea el usuario del sistema?

 Desea el actor ser informado acera de cambios

inesperados?
Símbolos usados en los Diagrama de
Casos de Uso de UML*

Caso de
Uso
Ejemplo de un Diagrama de Casos de Uso1

1. Sistema de control de registro para maquinas tragamonedas.

 Escenarios
 Cada ovalo en el diagrama de casos de uso debe ser
descrito detalladamente, a través de un escenario.
 Información principal a Incluir en la
descripción de un escenario

 Nombre del caso de uso  Prioridades

 Actor principal  Disponibilidad

 Objetivo  Frecuencia de Uso

 Pre-condiciones  Canales de comunicación

con actores
 Iniciador del caso de uso
 Canales con actores
 Descripción del Escenario
secundarios
 Excepciones
 Puntos aún no resueltos
Descripción
escenarios

(C) P. Gómez-Gil, INAOEP 2009

[Computer, 02]
 Otra Plantilla para
describir escenarios

[Larman,99]
Ejemplo de caso de uso del proyecto
“Casa Segura”
 Involucrados:
 Dueño de la casa
 Administrador de la configuración
(probablemente la misma persona que el
dueño)
 Sensores
 Subsistema de monitoreo
 Escogiendo como “actor” al dueño
de la casa…
Sistema Casa Segura
 Interacciones de “dueño 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 botón “pánico” en caso de una

emergencia

 Activa o desactiva el sistema de seguridad

Ejemplo de caso de uso del
proyecto “Casa Segura”

[Pressman 2004]
 Diagrama de actividades

 Representa el flujo de interacción con respecto a un

escenario específico

 Los rectángulos indican funciones, las flechas indican

flujo, los diamantes indican ramas de decisión y las
líneas horizontales indican que ocurren actividades
en paralelo.
Diagrama de actividades para
Licitación de Requerimientos

(C) P. Gómez-Gil, INAOEP 2009

[Pressman 2004]
Diagramas tipo Swimlane (carriles)

 Son una variación 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 acción descrita por el rectángulo. Se divide con
líneas verticales el diagrama, una columna por cada
actor (como los canales de nado en una piscina).
Diagrama tipo carriles

Fig. 8.8 [Pressman 04]

(C) P. Gómez-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

 Notación estándar para construir modelos

orientados a objetos

 Solo una notación. No es un método o proceso

de desarrollo
Historia de UML
En el 2009 ya
se liberó la versión 2.2

(C) P. Gómez-Gil, INAOEP 2009

 Diagramas de UML 2.0

 Tres tipos, 13 diagramas:

1. Diagramas de estructura estática. 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 Máquina

3. Diagramas de Interacción. Incluyen Diagramas de

Secuencia, Diagramas de Comunicación, Diagramas de
Sincronización (timing) y Diagramas Generales de
Interacción (Interaction Overview Diagram)

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