INGENIERÍA DE

REQUERIMIENTOS

Ingeniería de Software ll
LAUDYT M. LAMBRAÑO PEREZ
¿Qué es un Requerimiento?

 Puede variar desde unos estatutos abstractos en alto nivel de un

servicio o unas restricciones del sistema hasta una especificación
funcional matemática detallada.
 Los Requerimientos pueden servir como una función dual
 Puede ser la base para la declaración de un contrato, por lo
tanto, deber estar abierto a interpretación.
 Puede ser la base para el contrato en sí, por lo tanto, debe ser
definido en detalle.
 Ambas declaraciones serán llamadas Requerimientos.

Sommerville, Diapositiva
2
¿Qué es un Requerimiento?
 Un requerimiento de software define las funciones, capacidades
o atributos de cualquier sistema de software.
 También representan:
 Factores de calidad del sistema que permitirán evaluar su
utilidad a un cliente o usuario.
 Los datos de entrada al proceso de desarrollo de software y
representan lo que se requiere implementar.
 Una descripción de cómo el sistema deberá comportarse,
describe información del dominio de la aplicación, describe
restricciones de la operación del sistema y especifica
atributos ó propiedades del sistema.
 Un problema por resolver.

Sommerville,
¿Qué es un Requerimiento?
 No se deben incluir aspectos de diseño, que especifiquen como
deben implementarse tales requerimientos, ni detalles de
planeación del proyecto o de las pruebas.
 Es importante separar lo que se requiere (que se detalla con los
requerimientos) de como se requiere que el sistema sea diseñado
(que se detalla en la etapa del diseño).
 Todo software tiene requerimientos que lo definen y quizás la parte
más difícil de la construcción del software es la decisión de que es
lo que se debe construir

Sommerville, Mejia-Alvarez
Introduccion a los Requerimientos
Diapositiva 4
 Los Requerimientos pueden ser Funcionales o No-
Funcionales

 Los Requerimientos funcionales describen servicios o

funciones
 Los Requerimientos No-funcionales son un límite en el
sistema o en el proceso de desarrollo.

 Requerimientos de Dominio
 Requerimientos que se obtienen de el dominio de la
aplicacion del sistema y que reflejan sus caracteristicas.
Requerimientos
Definición/Especificación
• Definición de Requerimientos
• Una declaración en un Lenguaje Natural incluye los
diagramas de los servicios del sistema y sus límites
operacionales. Escrito para clientes.
• Especificación de Requerimientos
• Un documento estructurado con descripción o detalle de los
servicios del sistema. Escrito como un contrato entre el
cliente y el contratista.
• Especificación de Software
• Descripción detallada de software, la cual, puede servir
como una base para diseño o implementación. Escrito para
desarrolladodres.

Diapositiva 6
 Definición de Requerimientos
1. El Software proporciona significado de representación y acceso a
archivos externos creados por otras herramientas.

Especificación de Requerimientos
1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos.
1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será
aplicada para el archivo.
1.3 Cada tipo de archivo externo será representado como un icono específico mostrado al
usuario.
1.4 Las facilidades proporcionadas para la representación del icono en un tipo de archivo
externo será definido por el usuario.
1.5 Cuando un usuario selecciona una representación de icono de un archivo externo, el
efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo ex-
terno al archivo representado por la selección del icono.
 Lectores de Requerimientos
Gerencia de Cliente
Definición de Usuarios Finales del Sistema
Requerimientos Ingenieros de Clientes
Gerencia de Contratistas
Arquitectos del Sistema

Usuarios Finales del Sistema

Especificacion de
Ingenieros de Cliente
Requerimientos
Arquitectos del Sistema
Desarrolladores de Software

Especificación de Ingenieros de Clientes

Sommerville,
Mejia-Alvarez
Software Arquitectos del Sistema
Introduccion a
Desarrolladores de Software
los
Requerimiento
s
Diapositiva 8
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)

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".
Tareas de la Ing. de Requerimientos

 Iniciación
 Obtención
 Elaboración
 Negociación
 Especificación
 Validación
 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 preeliminares que se generan entre el consumidor
y el desarrollador
Pasos del proceso de Iniciación.

1. Identificación de involucrados.
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

 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?
 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 ?
 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.
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.
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.
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

 Obtención
 Elaboración
 Negociación
 Especificación
 Validación
 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

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

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)
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
 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
 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
 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?

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

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. Alvarez, V. et al.Otoño 04

Escenarios

 Cada ovalo en el diagrama de casos de

uso debe ser descrito detalladamente, a
través de un escenario.

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

Información principal a Incluir en la
descripción de un escenario
 Nombre del caso de uso
 Actor principal
 Objetivo
 Pre-condiciones
 Iniciador del caso de uso
 Descripción del Escenario
 Excepciones
 Prioridades
 Disponibilidad
 Frecuencia de Uso
 Canales de comunicación con actores
 Canales con actores secundarios
 Puntos aún no resueltos
Descripción
escenarios
 [Larman,99]
Otra Plantilla para
describir escenarios
 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
 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
Gracias…