Compresión de requerimientos

• Es un conjunto de tareas de ingeniería a los requerimientos. Éstas llevarán a la comprensión de

¿Qué es? cuál será el efecto que tendrá el software en el negocio, qué es lo que quiere el cliente y cómo
interactuarán los usuarios finales con el software.

¿Quién lo hace? • Los ingenieros de software y todos los demás participantes del proyecto intervienen en la
ingeniería de requerimientos.

¿Por qué es • Para saber que desea el cliente antes de comenzar a diseñar y a construir un sistema basado en

importante? computadora.

¿Cuáles son los pasos? • La ingeniería de requerimientos comienza con la concepción, indagación, elaboración y
negociación.

¿Cuál es el producto • El objetivo de los requerimientos de ingeniería es proporcionar a todas las partes un

final? entendimiento escrito del problema.

¿Cómo me aseguro de • Se revisan con los participantes los productos del trabajo de la ingeniería de requerimientos a fin

que lo hice bien? de asegurar que lo que se aprendió es lo que ellos quieren decir en realidad.
Ingeniería de requerimientos
Concepción
• Por lo general la mayo parte de los proyectos se inician cuando se identifica una necesidad de negocio o se descubre un nuevo
mercado o servicio potencial.

Indagación
• Problemas de alcance
• Problemas de entendimiento
• Problemas de volatilidad

Elaboración
• Desarrollar un modelo refinado de los requerimientos que identifiquen distintos aspectos de la función de software, su
comportamiento e información

Negociación

Especificación
• Puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático, un conjunto de escenarios de casos
de uso, un prototipo o cualquier combinación de estos.

Validación

Administración de requerimientos
Establecer las bases

Reconocer
Identificación de Trabajar hacia la Hacer las primeras
múltiples puntos
participantes colaboración preguntas
de vista

Cualquier persona que se Cada uno de los integrantes

Identificar las áreas de Libres de contexto- ¿Cuál
beneficie en forma directa o aportará información al
interés común y las de será el beneficio de una
indirecta del sistema en procesos de ingeniería de
conflicto solución exitosa?
desarrollo. requerimientos.

Ayudan a identificar el
problema - ¿Qué problemas
resolvería esta solución?

Metapreguntas -¿Debería
preguntarle algo más?
 Indagación de los requerimientos

Combina elementos de la solución de problemas, elaboración, negociación y

especificación. A fin de estimular un enfoque colaborativo y orientado al equipo, los
participantes trabajan juntos para identificar el problema, proponer elementos de la
solución, negociar distintas visiones y especificar un conjunto preliminar de
requerimientos para la solución
1. Recabar los requerimientos en forma colaborativa

Se utiliza un
Se sugiere una agenda
“mecanismo de
con suficiente
Tanto ingenieros de definición” (que pueden
formalidad para cubrir Un “facilitador” (cliente,
software como otros Se establecen reglas para ser hojas de trabajo,
todos los puntos desarrollador o
participantes dirigen o la preparación y tablas sueltas, etiquetas
importantes, pero con la participante externo)
intervienen en las participación. adhesivas, pizarrón
suficiente informalidad controla la reunión.
reuniones. electrónico, grupos de
para que estimule el libre
conversación o foro
flujo de ideas.
virtual).
2.Despliegue de la función de calidad

Es una técnica de administración de la calidad que traduce las

necesidades del cliente en requerimientos técnicos para el software:

Requerimientos normales. Objetivos y metas que se establecen para un producto o sistema durante las reuniones con el
cliente. Si estos requerimientos están presentes, el cliente queda satisfecho. Ejemplos de requerimientos normales son
los tipos de gráficos pedidos para aparecer en la pantalla, funciones específicas del sistema y niveles de rendimiento
definidos.

Requerimientos esperados. Están implícitos en el producto o sistema y quizá sean tan importantes que el cliente no los
mencione de manera explícita. Su ausencia causará mucha insatisfacción. Algunos ejemplos de requerimientos
esperados son: fácil interacción humano/máquina, operación general correcta y confiable, y facilidad para instalar el
software.

Requerimientos emocionantes. Estas características van más allá de las expectativas del cliente y son muy
satisfactorias si están presentes. Por ejemplo, el software para un nuevo teléfono móvil viene con características
estándar, pero si incluye capacidades inesperadas (como pantalla sensible al tacto, correo de voz visual, etc.) agrada a
todos los usuarios del producto
  A los escenarios comúnmente se los llama casos de uso, ya que
3. Escenarios proporcionan un esquema y una descripción de la manera que se va
de uso a utilizar el sistema.

Indagación de
productos de
trabajo

Esta foto de Autor desconocido está bajo licencia CC BY-SA-NC

4. Escenarios de uso
Indagación de productos de trabajo

Los productos del trabajo generados como consecuencia de la indagación de

los requerimientos variarán en función del tamaño del sistema o producto
que se va a construir. Para la mayoría de sistemas, los productos del trabajo
incluyen los siguientes:

Un conjunto de
Una lista de
escenarios de uso
Una lista de requerimientos (de
que dan Cualesquiera
Un enunciado clientes, usuarios y preferencia
Un enunciado de la Una descripción perspectiva al uso prototipos
acotado del alcance otros participantes organizados por
necesidad y su del ambiente del sistema o desarrollados para
del sistema o que intervienen en función) y las
factibilidad. técnico del sistema. producto en definir
producto. la indagación de restricciones del
diferentes requerimientos
los requerimientos. dominio que se
condiciones de
aplican a cada uno.
operación.
Desarrollo de casos de uso
Los actores principales interactúan para lograr la función requerida del sistema y obtienen el beneficio
previsto de éste. Trabajan con el software en forma directa y con frecuencia. Los actores secundarios dan
apoyo al sistema, de modo que los primarios puedan hacer su trabajo
Una vez identificados los actores, es posible desarrollar casos de uso. Hay varias preguntas que debe
responder un caso de uso:
 ¿Quién es el actor principal y quién(es) el(los) secundario(s)?
 ¿Cuáles son los objetivos de los actores?
 ¿Qué precondiciones deben existir antes de comenzar la historia?
 ¿Qué tareas o funciones principales son realizadas por el actor?
 ¿Qué excepciones deben considerarse al describir la historia?
 ¿Cuáles variaciones son posibles en la interacción del actor?
 ¿Qué información del sistema adquiere, produce o cambia el actor?
 ¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo?
 ¿Qué información desea obtener el actor del sistema?
 ¿Quiere el actor ser informado sobre cambios inesperados
Descripción casos de uso
Elaboración de modelo de
requerimientos
 Elementos del modelo de requerimientos
 Elementos básicos en el escenario (Diagramas de actividad).
 Elementos basados en clases (Diagramas de clases)
 Elementos de comportamiento(Diagrama de estado)
 Elementos orientados a flujo (Diagrama de flujo de datos)
Requerimientos de las negociaciones

Identificación de los participantes clave del sistema o subsistema.

Determinación de las “condiciones para ganar” de los participantes

Negociación de las condiciones para ganar de los participantes a fin de

reconciliarlas en un conjunto de condiciones ganar-ganar para todos los que
intervienen (incluso el equipo de software).
Validación de requerimientos
 La revisión del modelo de requerimientos aborda las preguntas siguientes:
 ¿Es coherente cada requerimiento con los objetivos generales del sistema o producto?
 ¿Se han especificado todos los requerimientos en el nivel apropiado de abstracción? Es decir,
¿algunos de ellos tienen un nivel de detalle técnico que resulta inapropiado en esta etapa?
 El requerimiento, ¿es realmente necesario o representa una característica agregada que tal vez no
sea esencial para el objetivo del sistema?
 ¿Cada requerimiento está acotado y no es ambiguo?
 ¿Tiene atribución cada requerimiento? Es decir, ¿hay una fuente (por lo general una individual y
específica) clara para cada requerimiento?
 ¿Hay requerimientos en conflicto con otros?
 ¿Cada requerimiento es asequible en el ambiente técnico que albergará el sistema o
producto?
 Una vez implementado cada requerimiento, ¿puede someterse a prueba?
 El modelo de requerimientos, ¿refleja de manera apropiada la información, la función y el
comportamiento del sistema que se va a construir?
 ¿Se ha “particionado” el modelo de requerimientos en forma que exponga información
cada vez más detallada sobre el sistema?
 ¿Se ha usado el patrón de requerimientos para simplificar el modelo de éstos? ¿Se han
validado todos los patrones de manera apropiada? ¿Son consistentes todos los patrones con
los requerimientos del cliente