INGENIERIA DE

REQUERIMIENTOS

Actividades del Proceso de

IR
 Actividades del Proceso de IR
La IR, es un proceso “social” y las técnicas y métodos que no reconocen esto
tienen menos oportunidad de obtener la información necesaria” [Leite1987].

La IR requiere:
De los Ingenieros de Requisitos: destrezas comunicacionales, habilidad para
escuchar y asimilar el vocabulario y problemas del cliente.
De los clientes: Destrezas comunicacionales, la facilidad para entender sus
componentes, y tener autoridad para comprometerse en el proceso
[Finkelstein1994].

Las actividades de IR son consumidoras de tiempo, intensivas, difíciles de

controlar y evaluar, y los desarrolladores se enfrentan a preguntas difíciles de
responder[Greenspan2001]:

• Qué actividades de IR son esenciales de realizar incluso cuando el tiempo es

corto.
• Qué tipo de información registrar.
• Cómo puede un proceso IR ser organizado y controlado para ahorrar tiempo.
• Qué actividades pueden evitarse en un proyecto particular.
Actividades del Proceso de IR
 Actividades del Proceso de IR
Flujo de actividades y productos de trabajo propuestos
 Actividades del Proceso de IR
Modelado del Negocio
Antes de identificar necesidades, es fundamental conocer el dominio del problema,
contexto organizacional y operacional del negocio

OBJETIVOS:
•Entender la estructura y dinámica de la organización
•Entender los problemas e identificar mejoras potenciales
•Asegurar que el cliente, usuario final y desarrollador tienen claro el objetivo de la
organización.
•Manejar los requisitos necesarios para lograr los objetivos
 Actividades del Proceso de IR
Elicitación
Estudia el dominio del problema e interactúa con clientes y
usuarios para obtener y registrar información, negociar los
requisitos que deben satisfacer el sistema a desarrollar, desde el
punto de vista de clientes y usuarios.(DURAN–2000)
•Identificar participantes
•Preparar y realizar sesiones
•Identificar requisitos de información
•Identificar fuentes de información
•Elaborar Documento Especificación de Requisitos de Software –
SRS (software requirement specification) MODELO NEGOCIO
 Actividades del Proceso de IR
Técnicas de Elicitación:
• Entrevistas
• Actas de reunión
• Análisis de textos (lenguaje natural)
• Cuestionarios
• CheckList
• Observación
• Reuniones, Lluvia de ideas
• Sistemas existentes
• Re-uso de requisitos
• Ingeniería de Reversa
• Casos de uso
Actividades del Proceso de IR
 Actividades del Proceso de IR
Análisis
• El Ingeniero de Requisitos y el equipo de trabajo, realizan
un completo y detallado entendimiento de las necesidades.
• Profundiza el conocimiento del dominio del problema,
establecer bases para el diseño
• Se clasifican y se modelan los requisitos.
– Req. Información / Req. Funcionales / Req. No Funcionales
• Se integran y analizan los requisitos.
• Se identifican los conflictos y documenta
– falta de requisitos, conflictos, inconsistencias entre requisitos
Conflictos de conducta / características / De Término /
Temporales
 Actividades del Proceso de IR
ESPECIFICACIÓN DE REQUISITOS
• Documentar características deseadas que el sistema
debe cumplir
• Desarrollar la visión general del sistema
• Documentar los requisitos del sistema
• Definir las posibilidades de integración del sistema
• Analizarlos requisitos del sistema
• Definir plantillas
Actividades del Proceso de IR
 Actividades del Proceso de IR
NEGOCIACIÓN (Resolución de Conflictos):
• Alcanzar acuerdos y/o entendimientos entre todos los participantes
sobre los requisitos propuestos en la fase anterior (nuevas peticiones,
incompatibilidad, falta de recursos)
• El requisito es necesario?
• Tiene un nivel de detalle apropiado?
• Está bien delimitado y sin ambigüedad?
• Se solapa con otros requisitos?
• Se puede probar una vez implementado el requisito?
• Se dispone de presupuesto?
 Actividades del Proceso de IR
Historias de Usuario
• Describe la funcionalidad que será más valiosa para un usuario o cliente del
producto de software
• Se compone de tres aspectos:
– Una descripción escrita usada para planear, como un recordatorio.
– Conversaciones respecto a la historia lo cual sirve para tener mayores
detalles de la historia.
– Pruebas y detalles que se puede utilizar para determinar cuando una
historia es completa
• Pueden estar escritas a mano.
• Pueden estar escritas en notas.
 Actividades del Proceso de IR
Historias de Usuario
• Debido a que las historias de usuario representan la funcionalidad que
será valorada por usuarios y clientes, los siguientes ejemplos no son
buenas historias de usuario:
– El software será escrito en Java
– El programa se conectará a la base de datos a través de un pool de
conexiones
• Para clientes y usuarios no son importantes los detalles técnicos de la
solución
• Pero hay formas de expresar este tipo de historias para que tengan valor
para el usuario
 Aproximación Ágil
Historias de Usuario
• El reverso de la nota o carta debe tener los criterios de aceptación
de la historia
 Aproximación Ágil
Por qué Historias de Usuario?

• Enfatizan la comunicación verbal más que la escrita.

• Son comprensibles para todos, clientes, usuarios, desarrolladores
• Son del tamaño adecuado para la planificación
• Sirven para el desarrollo iterativo
• Las historias de usuario alentan a aplazar los detalles hasta que
se tenga la mejor comprensión. Usted va a tener solo lo que
realmente necesita.
 Aproximación Ágil
Cómo escribir Historias de Usuario:
• Independientes: tratar en lo posible de evitar dependencias con
otras historias de usuario
• Negociables: no son contratos, son descripciones cortas y
valiosas para usuarios y clientes
• Estimables
• Cortas
• Factibles de ser probadas
 Actividades del Proceso de IR
Métodos Ágiles
• M-MUST: Requerimiento crítico para el éxito del proyecto. Debe
ser liberado en el timebox actual.
• S-SHOULD: Requerimiento importante pero no necesario de ser
liberado en el timebox actual.
• C-COULD: Requerimiento menos crítico y frecuentemente visto
como algo deseable.
• W-WON'T: Requerimiento que no va en el presente release, pero
tal vez sea considerado en un futuro.