Entender los requerimientos de un problema es una
de las tareas más difíciles que enfrenta el ingeniero de
CAPITULO
5
software. Cuando se piensa por primera vez, no
parece tan difícil desarrollar un entendimiento claro
de los requerimientos
La preguntas frecuentes que los ingenieros de
software presencias son ¿acaso no sabe el
cliente lo que se necesita? ¿No deberían tener los
usuarios finales una buena comprensión de
las características y funciones que le darán un
beneficio?
en muchas instancias la respuesta a estas preguntas
es “no”. E incluso si los clientes y los usuarios finales COMPRENSIÓN
DE
explican sus necesidades, éstas cambiarán mientras se
desarrolla el proyecto.
LOS
El diseño y construcción de software de computadora
es difícil, creativo y sencillamente divertido. En
realidad, elaborar software es tan atractivo que INGENIERÍA
DE
muchos desarrolladores de software
quieren ir directo a él antes de haber tenido el
entendimiento claro de lo que se necesita.
El espectro amplio de tareas y técnicas que llevan a
REQUERIMIEN
entender los requerimientos se denomina
ingeniería de requerimientos. Desde la perspectiva del
TOS
proceso del software, la ingeniería de requerimientos
es una de las acciones importantes de la ingeniería de
software que comienza
durante la actividad de comunicación y continúa en la
de modelado.
La ingeniería de requerimientos tiende un puente para el
diseño y la construcción. Pero, ¿dónde se origina el puente?
INGENIERÍA
Podría argumentarse que principia en los pies de los
participantes en el proyecto (por ejemplo, gerentes, clientes y
usuarios), donde se definen las necesidades del negocio, se
describen los escenarios de uso, se delinean las funciones y
características y se identifican las restricciones del proyecto.
DE
Incluye siete tareas
REQUERIMIEN
diferentes:
Concepción TOS
Indagación
Elaboración
Negociación
Especificación
validación y administración.
Es importante notar que algunas de estas tareas ocurren en
paralelo y que todas se adaptan a las necesidades del
proyecto.
Concepción. ¿Cómo inicia un proyecto de software? ¿Existe un
solo evento que se convierte
INGENIERÍA
en el catalizador de un nuevo sistema o producto basado en
computadora o la necesidad evoluciona en el tiempo? No hay
respuestas definitivas a estas preguntas
DE
Indagación. En verdad que parece muy simple: preguntar al
cliente, a los usuarios y a otras REQUERIMIEN
personas cuáles son los objetivos para el sistema o producto,
qué es lo que va a lograrse, cómo
se ajusta el sistema o producto a las necesidades del negocio
TOS
y, finalmente, cómo va a usarse el
sistema o producto en las operaciones cotidianas. Pero no es
simple: es muy difícil.
Christel y Kang identificaron cierto numero de problemas que
se encuentra cuando ocurre la indignación INGENIERÍA
Problemas de alcance
Problemas de entendimiento DE
REQUERIMIEN
Problemas de volatilidad
ELABORACIÓN. TOS
La información obtenida del cliente durante la concepción e
indagación se expande y refina durante la elaboración. Esta
tarea se centra en desarrollar un modelo refinado de
los requerimientos (véanse los capítulos 6 y 7) que identifique
distintos aspectos de la función
del software, su comportamiento e información.
Especificación. En el contexto de los sistemas basados en
computadora (y software), el término especificación tiene
diferentes significados para distintas personas. Una
especificación
puede ser un documento escrito, un conjunto de modelos
INGENIERÍA
gráficos, un modelo matemático formal, un conjunto de
escenarios de uso, un prototipo o cualquier combinación de DE
éstos.
Validación. La calidad de los productos del trabajo que se REQUERIMIEN
TOS
generan como consecuencia de la
ingeniería de los requerimientos se evalúa durante el paso de
validación. La validación de los
requerimientos analiza la especificación5 a fin de garantizar
que todos ellos han sido enunciados sin ambigüedades; que
se detectaron y corrigieron las inconsistencias, las omisiones y
los
errores, y que los productos del trabajo se presentan
conforme a los estándares establecidos para el proceso, el
proyecto y el producto.
Administración de los requerimientos. Los requerimientos
para sistemas basados en
computadora cambian, y el deseo de modificarlos persiste
durante toda la vida del sistema. IDENTIFICACI
Sommerville y Sawyer [Som97] definen participante como
“cualquier persona que se beneficie
ON DE LOS
en forma directa o indirecta del sistema en desarrollo”.
PARTICIPANTE
Ya se identificaron los candidatos habituales:
gerentes de operaciones del negocio S
gerentes de producto
personal de mercadotecnia,
clientes internos y externos
usuarios finales
Consultores
ingenieros de producto
ingenieros de software e ingenieros de apoyo y
mantenimiento
RECONOCER
Debido a que existen muchos participantes distintos, los
requerimientos del sistema se explorarán desde muchos LOS
puntos de vista diferentes. Por ejemplo, el grupo de
mercadotecnia se interesa en funciones y características que
estimularán el mercado potencial, lo que hará que el
MULTIPLES
nuevo sistema sea fácil de vender. Los gerentes del negocio
tienen interés en un conjunto de PUNTOS DE
características para que se elabore dentro del presupuesto y
que esté listo para ocupar nichos
de mercado definidos. Los usuarios finales tal vez quieran
VISTA
características que les resulten familiares y que sean fáciles de
aprender y usar
TRABAJAR
Si en un proyecto de software hay involucrados cinco
participantes, tal vez se tengan cinco (o HACIA LA
más) diferentes opiniones acerca del conjunto apropiado de
requerimientos. COLABORACI
ON
HACER LAS
Las preguntas que se hacen en la concepción del proyecto
deben estar “libres del contexto” PRIMERAS
[Gau89]. El primer conjunto de ellas se centran en el cliente y
en otros participantes, en las metas y beneficios generales.
Por ejemplo, tal vez se pregunte:
PREGUNTAS
• ¿Quién está detrás de la solicitud de este trabajo?
• ¿Quién usará la solución?
• ¿Cuál será el beneficio económico de una solución exitosa?
• ¿Hay otro origen para la solución que se necesita?
Se han propuesto muchos enfoques distintos para recabar los
requerimientos en forma colaborativa. Cada uno utiliza un escenario
un poco diferente, pero todos son variantes de los siguientes RECABACION
DE LOS
lineamientos básicos:
• Tanto ingenieros de software como otros participantes dirigen o
intervienen en las
reuniones.
• Se establecen reglas para la preparación y participación.
REQUERIMIEN
• Se sugiere una agenda con suficiente formalidad para cubrir todos
los puntos importantes, pero con la suficiente informalidad para que TOS EN FORMA
estimule el libre flujo de ideas.
• Un “facilitador” (cliente, desarrollador o participante externo)
controla la reunión.
COLABORATIV
• Se utiliza un “mecanismo de definición” (que pueden ser hojas de
trabajo, tablas sueltas, A
etiquetas adhesivas, pizarrón electrónico, grupos de conversación o
foro virtual).
El despliegue de la función de calidad (DFC) es una técnica de
administración de la calidad que
traduce las necesidades del cliente en requerimientos técnicos para DESPLIEGUE
DE LA
el software. El DFC “se concentra en maximizar la satisfacción del
cliente a partir del proceso de ingeniería del software”
Requerimientos normales. Objetivos y metas que se establecen para FUNCION DE
CALIDAD
un producto o sistema durante las reuniones con el cliente.
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.
Requerimientos emocionantes. Estas características van más allá de
las expectativas del cliente y son muy satisfactorias si están
presentes.
ESCENARIOS
A medida que se reúnen los requerimientos, comienza a
materializarse la visión general de funciones y DE USO
características del sistema. Sin embargo, es difícil avanzar
hacia actividades más técnicas de la ingeniería de software
hasta no entender cómo emplearán los usuarios finales
dichas funciones y características.
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 INDAGACION
se va a construir.
DE LOS
PRODUCTOS
DEL TRABAJO
ELABORACION
El objetivo del modelo del análisis es describir los dominios
de información, función y comportamiento que se
requieren para un sistema basado en computadora. El
modelo cambia en forma
dinámica a medida que se aprende más sobre el sistema
DEL MODELO
por construir, y otros participantes
comprenden más lo que en realidad requieren. Por esa DE LOS
razón, el modelo del análisis es una fotografía de los
requerimientos en cualquier momento dado. Es de esperar
que cambie.
REQUERIMIEN
TOS
Hay muchas formas diferentes de concebir los
requerimientos para un sistema basado en
ELEMENTOS
computadora. Algunos profesionales del software afirman
que es mejor seleccionar un modo de DEL MODELO
DE
representación (por ejemplo, el caso de uso) y aplicarlo
hasta excluir a todos los demás. Otros
piensan que es más benéfico usar cierto número de modos
de representación distintos para
ilustrar el modelo de requerimientos. Los modos diferentes
REQUERIMIEN
de representación fuerzan a considerar los requerimientos
desde distintos puntos de vista, enfoque que tiene una TOS
probabilidad
mayor de detectar omisiones, inconsistencia y
ambigüedades.
Elementos basados en el escenario. El sistema se describe
desde el punto de vista del
usuario con el empleo de un enfoque basado en el
escenario. ELEMENTOS
Elementos basados en clases. Cada escenario de uso
implica un conjunto de objetos que
DEL MODELO
se manipulan cuando un actor interactúa con el sistema.
Estos objetos se clasifican en clases: DE
conjunto de objetos que tienen atributos similares y
comportamientos comunes. REQUERIMIEN
Elementos de comportamiento. El comportamiento de un
sistema basado en computadora TOS
tiene un efecto profundo en el diseño que se elija y en el
enfoque de implementación que se
aplique. Por tanto, el modelo de requerimientos debe
proveer elementos de modelado que ilustren el
comportamiento.
Elementos basados en el escenario. El sistema se describe
desde el punto de vista del
usuario con el empleo de un enfoque basado en el
escenario. ELEMENTOS
Elementos basados en clases. Cada escenario de uso
implica un conjunto de objetos que
DEL MODELO
se manipulan cuando un actor interactúa con el sistema.
Estos objetos se clasifican en clases: DE
conjunto de objetos que tienen atributos similares y
comportamientos comunes. REQUERIMIEN
Elementos de comportamiento. El comportamiento de un
sistema basado en computadora TOS
tiene un efecto profundo en el diseño que se elija y en el
enfoque de implementación que se
aplique. Por tanto, el modelo de requerimientos debe
proveer elementos de modelado que ilustren el
comportamiento.
Cualquiera que haya hecho la ingeniería de los
PATRONES DE
requerimientos en varios proyectos de software
ha observado que ciertos problemas son recurrentes en ANALISIS
todos ellos dentro de un dominio de
aplicación específico.
Los patrones de análisis se integran en el modelo del
análisis, haciendo referencia al nombre
del patrón. También se guardan en un medio de
almacenamiento de modo que los ingenieros
de requerimientos usen herramientas de búsqueda para
encontrarlos y aplicarlos.
En un contexto ideal de la ingeniería de los requerimientos,
REQUERIMIEN
las tareas de concepción, indagación y elaboración
determinan los requerimientos del cliente con suficiente TO DE LAS
detalle como para
avanzar hacia las siguientes actividades de la ingeniería de
software.
NEGOCIACION
El objetivo de esta negociación es desarrollar un plan del ES
proyecto que satisfaga las necesidades del participante y
que al mismo tiempo refleje las restricciones del mundo
real (por
ejemplo, tiempo, personas, presupuesto, etc.) que se
hayan establecido al equipo del software.
Las mejores negociaciones buscan un resultado “ganar-
ganar”.
