Comprension de Los Requerimientos CAP 5

CAPÍTULO
COMPRENSIÓN
LOS REQUERIMIENTOS
DE
5
CONCEPTOS ntender los requerimientos de un problema es una de las tareas más difíciles que enfrenta
E
CLAVE
administración de los el ingeniero de software. Cuando se piensa por primera vez, no parece tan difícil desarro-
requerimientos . . . . . . . . . . 105 llar un entendimiento claro de los requerimientos. Después de todo, ¿acaso no sabe el
casos de uso . . . . . . . . . . . . 113 cliente lo que se necesita? ¿No deberían tener los usuarios finales una buena comprensión de
colaboración . . . . . . . . . . . . 107 las características y funciones que le darán un beneficio? Sorprendentemente, en muchas ins-
concepción . . . . . . . . . . . . . 102 tancias la respuesta a estas preguntas es “no”. E incluso si los clientes y los usuarios finales
despliegue de la función explican sus necesidades, éstas cambiarán mientras se desarrolla el proyecto.
de calidad . . . . . . . . . . . . . . 111
En el prólogo a un libro escrito por Ralph Young [You01] sobre las prácticas eficaces respecto
elaboración . . . . . . . . . . . . . 117
de los requerimientos, escribí lo siguiente:
especificación . . . . . . . . . . . 104
indagación . . . . . . . . . . . . . 103 Es la peor de las pesadillas. Un cliente entra a la oficina, toma asiento, lo mira a uno fijamente a los
indagación de los ojos y dice: “Sé que cree que entiende lo que digo, pero lo que usted no entiende es que lo que digo
requerimientos . . . . . . . . . . 108 no es lo que quiero decir.” Invariablemente, esto pasa cuando ya está avanzado el proyecto, después
ingeniería de de que se han hecho compromisos con los plazos de entrega, que hay reputaciones en juego y mucho
requerimientos . . . . . . . . . . 102 dinero invertido.
modelo del análisis . . . . . . . 117
Todos los que hemos trabajado en el negocio de los sistemas y del software durante algunos años
negociación . . . . . . . . . . . . . 121
hemos vivido la pesadilla descrita, pero pocos hemos aprendido a escapar. Batallamos cuando trata-
participantes. . . . . . . . . . . . 106
mos de obtener los requerimientos de nuestros clientes. Tenemos problemas para entender la infor-
patrones de análisis . . . . . . 120
mación que obtenemos. Es frecuente que registremos los requerimientos de manera desorganizada y
productos del trabajo. . . . . . 112
que dediquemos muy poco tiempo a verificar lo que registramos. Dejamos que el cambio nos controle
puntos de vista . . . . . . . . . . 107
en lugar de establecer mecanismos para controlarlo a él. En pocas palabras, fallamos en establecer un
validación . . . . . . . . . . . . . . 105 fundamento sólido para el sistema o software. Cada uno de los problemas es difícil. Cuando se com-
validación de los binan, el panorama es atemorizador aun para los gerentes y profesionales más experimentados. Pero
requerimientos . . . . . . . . . . 122
hay solución.
UNA
MIRADA ¿Qué es? Antes de comenzar cualquier tra- a definir lo que se requiere. Después sigue la elaboración,
RÁPIDA
bajo técnico es una buena idea aplicar un donde se refinan y modifican los requerimientos básicos.
conjunto de tareas de ingeniería a los requeri- Cuando los participantes definen el problema, tiene lugar
mientos. Éstas llevarán a la comprensión de una negociación: ¿cuáles son las prioridades, qué es lo
cuál será el efecto que tendrá el software en el negocio, esencial, cuándo se requiere? Por último, se especifica el
qué es lo que quiere el cliente y cómo interactuarán los problema de algún modo y luego se revisa o valida para
usuarios finales con el software. garantizar que hay coincidencia entre la comprensión que
¿Quién lo hace? Los ingenieros de software (que en el usted tiene del problema y la que tienen los participantes.
mundo de las tecnologías de información a veces son lla- ¿Cuál es el producto final? El objetivo de los requeri-
mados ingenieros de sistemas o analistas) y todos los mientos de ingeniería es proporcionar a todas las partes
demás participantes del proyecto (gerentes, clientes y un entendimiento escrito del problema. Esto se logra por
usuarios) intervienen en la ingeniería de requerimientos. medio de varios productos del trabajo: escenarios de uso,
¿Por qué es importante? Diseñar y construir un elegan- listas de funciones y de características, modelos de reque-
te programa de cómputo que resuelva el problema equivo- rimientos o especificaciones.
cado no satisface las necesidades de nadie. Por eso es ¿Cómo me aseguro de que lo hice bien? Se revisan
importante entender lo que el cliente desea antes de con los participantes los productos del trabajo de la inge-
comenzar a diseñar y a construir un sistema basado en niería de requerimientos a fin de asegurar que lo que se
computadora. aprendió es lo que ellos quieren decir en realidad. Aquí
¿Cuáles son los pasos? La ingeniería de requerimientos cabe una advertencia: las cosas cambiarán aun después
comienza con la concepción, tarea que define el alcance y de que todas las partes estén de acuerdo, y seguirán cam-
la naturaleza del problema que se va a resolver. Va segui- biando durante todo el proyecto.
da de la indagación, labor que ayuda a los participantes
101
www.FreeLibros.me
05Pressman(101-125).indd 101 21/1/10 11:00:18

102 PAR T E DOS MO D E LADO
Es razonable afirmar que las técnicas que se estudiarán en este capítulo no son una “solu-
ción” verdadera para los retos que se mencionaron, pero sí proveen de un enfoque sólido para
enfrentarlos.
5. 1 INGENIERÍA DE REQUERIMIENTOS
El diseño y construcción de software de computadora es difícil, creativo y sencillamente diver-

Cita: tido. En realidad, elaborar software es tan atractivo que muchos desarrolladores de software
quieren ir directo a él antes de haber tenido el entendimiento claro de lo que se necesita. Argu-
“La parte más difícil al construir
un sistema de software es deci- mentan que las cosas se aclararán a medida que lo elaboren, que los participantes en el proyecto
dir qué construir. Ninguna parte podrán comprender sus necesidades sólo después de estudiar las primeras iteraciones del soft-
del trabajo invalida tanto al sis- ware, que las cosas cambian tan rápido que cualquier intento de entender los requerimientos
tema resultante si ésta se hace en detalle es una pérdida de tiempo, que las utilidades salen de la producción de un programa
mal. Nada es más difícil de que funcione y que todo lo demás es secundario. Lo que hace que estos argumentos sean tan
corregir después.”
seductores es que tienen algunos elementos de verdad.1 Pero todos son erróneos y pueden llevar
Fred Brooks un proyecto de software al fracaso.
El espectro amplio de tareas y técnicas que llevan a entender los requerimientos se denomina
ingeniería de requerimientos. Desde la perspectiva del proceso del software, la ingeniería de re-
querimientos 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. Debe adaptarse a las ne-
cesidades del proceso, del proyecto, del producto y de las personas que hacen el trabajo.
PU La ingeniería de requerimientos tiende un puente para el diseño y la construcción. Pero,
NT
O ¿dónde se origina el puente? Podría argumentarse que principia en los pies de los participantes
CLAVE en el proyecto (por ejemplo, gerentes, clientes y usuarios), donde se definen las necesidades del
La ingeniería de requerimientos negocio, se describen los escenarios de uso, se delinean las funciones y características y se
establece una base sólida para el identifican las restricciones del proyecto. Otros tal vez sugieran que empieza con una definición
diseño y la construcción. Sin ésta, el
más amplia del sistema, donde el software no es más que un componente del dominio del sis-
software resultante tiene alta
probabilidad de no satisfacer las tema mayor. Pero sin importar el punto de arranque, el recorrido por el puente lo lleva a uno
necesidades del cliente. muy alto sobre el proyecto, lo que le permite examinar el contexto del trabajo de software que
debe realizarse; las necesidades específicas que deben abordar el diseño y la construcción; las
prioridades que guían el orden en el que se efectúa el trabajo, y la información, las funciones y
CONSEJO los comportamientos que tendrán un profundo efecto en el diseño resultante.
La ingeniería de requerimientos proporciona el mecanismo apropiado para entender lo que
Espere hacer un poco de diseño al
recabar los requerimientos, y un desea el cliente, analizar las necesidades, evaluar la factibilidad, negociar una solución razona-
poco de requerimientos durante el ble, especificar la solución sin ambigüedades, validar la especificación y administrar los reque-
trabajo de diseño. rimientos a medida de que se transforman en un sistema funcional [Tha97]. Incluye siete tareas
diferentes: concepción, indagación, elaboración, negociación, especificación, validación y ad-
ministración. Es importante notar que algunas de estas tareas ocurren en paralelo y que todas
Cita: se adaptan a las necesidades del proyecto.
“Las semillas de los desastres Concepción. ¿Cómo inicia un proyecto de software? ¿Existe un solo evento que se convierte
enormes del software por lo en el catalizador de un nuevo sistema o producto basado en computadora o la necesidad evo-
general se vislumbran en los
luciona en el tiempo? No hay respuestas definitivas a estas preguntas. En ciertos casos, una
tres primeros meses del inicio
del proyecto.” conversación casual es todo lo que se necesita para desencadenar un trabajo grande de inge-
niería de software. Pero en general, la mayor parte de proyectos comienzan cuando se identifica
Coper Jones
una necesidad del negocio o se descubre un nuevo mercado o servicio potencial. Los partici-
1 Esto es cierto en particular para los proyectos pequeños (menos de un mes) y muy pequeños, que requieren re-
lativamente poco esfuerzo de software sencillo. A medida que el software crece en tamaño y complejidad, estos
argumentos comienzan a ser falsos.
www.FreeLibros.me
05Pressman(101-125).indd 102 21/1/10 11:00:19

C AP Í T UL O 5 COMPRENSIÓN DE LOS REQ U ERIMIENT OS 103
pantes de la comunidad del negocio (por ejemplo, los directivos, personal de mercadotecnia,
gerentes de producto, etc.) definen un caso de negocios para la idea, tratan de identificar el ritmo
y profundidad del mercado, hacen un análisis de gran visión de la factibilidad e identifican una
descripción funcional del alcance del proyecto. Toda esta información está sujeta a cambio, pero
es suficiente para desencadenar análisis con la organización de ingeniería de software.2
En la concepción del proyecto,3 se establece el entendimiento básico del problema, las per-
sonas que quieren una solución, la naturaleza de la solución que se desea, así como la eficacia
de la comunicación y colaboración preliminares entre los otros participantes y el equipo de
software.
Indagación. En verdad que parece muy simple: preguntar al cliente, a los usuarios y a otras
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 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 [Cri92] identificaron cierto número de problemas que se encuentran cuando
ocurre la indagación:
? ¿Por qué es difícil llegar

al entendimiento claro • Problemas de alcance. La frontera de los sistemas está mal definida o los clientes o
de lo que quiere el usuarios finales especifican detalles técnicos innecesarios que confunden, más que clari-
cliente? fican, los objetivos generales del sistema.
• Problemas de entendimiento. Los clientes o usuarios no están completamente

seguros de lo que se necesita, comprenden mal las capacidades y limitaciones de su
ambiente de computación, no entienden todo el dominio del problema, tienen
problemas para comunicar las necesidades al ingeniero de sistemas, omiten información
que creen que es “obvia”, especifican requerimientos que están en conflicto con las
necesidades de otros clientes o usuarios, o solicitan requerimientos ambiguos o que no
pueden someterse a prueba.
• Problemas de volatilidad. Los requerimientos cambian con el tiempo.

Para superar estos problemas, debe enfocarse la obtención de requerimientos en forma organi-
zada.
Elaboración. La información obtenida del cliente durante la concepción e indagación se ex-

CONSEJO pande y refina durante la elaboración. Esta tarea se centra en desarrollar un modelo refinado de
La elaboración es algo bueno, pero los requerimientos (véanse los capítulos 6 y 7) que identifique distintos aspectos de la función
hay que saber cuándo detenerse. La del software, su comportamiento e información.
clave es describir el problema en La elaboración está motivada por la creación y mejora de escenarios de usuario que descri-
forma que establezca una base firme
ban cómo interactuará el usuario final (y otros actores) con el sistema. Cada escenario de usua-
para el diseño. Si se trabaja más allá
de este punto, se está haciendo rio se enuncia con sintaxis apropiada para extraer clases de análisis, que son entidades del
diseño. dominio del negocio visibles para el usuario final. Se definen los atributos de cada clase de
análisis y se identifican los servicios4 que requiere cada una de ellas. Se identifican las relaciones
y colaboración entre clases, y se producen varios diagramas adicionales.
Negociación. No es raro que los clientes y usuarios pidan más de lo que puede lograrse dado
lo limitado de los recursos del negocio. También es relativamente común que distintos clientes
2 Si va a desarrollarse un sistema basado en computadora, los análisis comienzan en el contexto de un proceso

de ingeniería de sistemas. Para más detalles de la ingeniería de sistemas, visite el sitio web de esta obra.
3 Recuerde que el proceso unificado (véase el capítulo 2) define una “fase de concepción” más amplia que incluye
las fases de concepción, indagación y elaboración, que son estudiadas en dicho capítulo.
4 Un servicio manipula los datos agrupados por clase. También se utilizan los términos operación y método. Si no
está familiarizado con conceptos de la orientación a objetos, consulte el apéndice 2, en el que se presenta una
introducción básica.
www.FreeLibros.me
05Pressman(101-125).indd 103 21/1/10 11:00:19

o usuarios propongan requerimientos conflictivos con el argumento de que su versión es “esen-

CONSEJO cial para nuestras necesidades especiales”.
En una negociación eficaz no debe Estos conflictos deben reconciliarse por medio de un proceso de negociación. Se pide a clien-
haber ganador ni perdedor. Ambos tes, usuarios y otros participantes que ordenen sus requerimientos según su prioridad y que
lados ganan porque un “trato” con después analicen los conflictos. Con el empleo de un enfoque iterativo que da prioridad a los
el que ambas partes pueden vivir es
requerimientos, se evalúa su costo y riesgo, y se enfrentan los conflictos internos; algunos re-
algo sólido.
querimientos se eliminan, se combinan o se modifican de modo que cada parte logre cierto
grado de satisfacción.
Especificación. En el contexto de los sistemas basados en computadora (y software), el tér-

mino especificación tiene diferentes significados para distintas personas. Una especificación
puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático for-
mal, un conjunto de escenarios de uso, un prototipo o cualquier combinación de éstos.
PU Algunos sugieren que para una especificación debe desarrollarse y utilizarse una “plantilla
NT
O estándar” [Som97], con el argumento de que esto conduce a requerimientos presentados en
CLAVE forma consistente y por ello más comprensible. Sin embargo, en ocasiones es necesario ser
La formalidad y el formato de una flexible cuando se desarrolla una especificación. Para sistemas grandes, el mejor enfoque puede
especificación varían con el tamaño y
ser un documento escrito que combine descripciones en un lenguaje natural con modelos grá-
complejidad del software que se va a
construir. ficos. No obstante, para productos o sistemas pequeños que residan en ambientes bien enten-
didos, quizá todo lo que se requiera sea escenarios de uso.
I NFOR MACIÓN
Formato de especificación de requerimientos de software
Una especificación de requerimientos de software (ERS) es 2.2 Características del producto
un documento que se crea cuando debe especificarse una 2.3 Clases y características del usuario
descripción detallada de todos los aspectos del software que se va a 2.4 Ambiente de operación
elaborar, antes de que el proyecto comience. Es importante notar que 2.5 Restricciones de diseño e implementación
una ERS formal no siempre está en forma escrita. En realidad, hay 2.6 Documentación para el usuario
muchas circunstancias en las que el esfuerzo dedicado a la ERS esta- 2.7 Suposiciones y dependencias
ría mejor aprovechado en otras actividades de la ingeniería de soft- 3. Características del sistema
ware. Sin embargo, se justifica la ERS cuando el software va a ser 3.1 Característica 1 del sistema
desarrollado por una tercera parte, cuando la falta de una especifica- 3.2 Característica 2 del sistema (y así sucesivamente)
ción crearía problemas severos al negocio, si un sistema es complejo
4. Requerimientos de la interfaz externa
en extremo o si se trata de un negocio de importancia crítica.
4.1 Interfaces de usuario
Karl Wiegers [Wie03], de la empresa Process Impact Inc., desa-
4.2 Interfaces del hardware
rrolló un formato útil (disponible en www.processimpact.com/
4.3 Interfaces del software
process_assets/srs_template.doc) que sirve como guía para
4.4 Interfaces de las comunicaciones
aquellos que deben crear una ERS completa. Su contenido normal es
el siguiente: 5. Otros requerimientos no funcionales
5.1 Requerimientos de desempeño
Tabla de contenido 5.2 Requerimientos de seguridad
Revisión de la historia 5.3 Requerimientos de estabilidad
5.4 Atributos de calidad del software
1. Introducción
1.1 Propósito 6. Otros requerimientos
1.2 Convenciones del documento Apéndice A: Glosario
1.3 Audiencia objetivo y sugerencias de lectura Apéndice B: Modelos de análisis
1.4 Alcance del proyecto Apéndice C: Lista de conceptos
1.5 Referencias Puede obtenerse una descripción detallada de cada ERS si se descar-
2. Descripción general ga el formato desde la URL mencionada antes.
2.1 Perspectiva del producto
www.FreeLibros.me
05Pressman(101-125).indd 104 21/1/10 11:00:20

Validación. La calidad de los productos del trabajo que se 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 enuncia-
dos 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 estableci-
dos para el proceso, el proyecto y el producto.
CONSEJO
El mecanismo principal de validación de los requerimientos es la revisión técnica (véase el
Un aspecto clave durante la capítulo 15). El equipo de revisión que los valida incluye ingenieros de software, clientes, usua-
validación de los requerimientos es rios y otros participantes, que analizan la especificación en busca de errores de contenido o de
la consistencia. Utilice el modelo de
interpretación, de aspectos en los que tal vez se requiera hacer aclaraciones, falta de informa-
análisis para asegurar que los
requerimientos se han enunciado de ción, inconsistencias (problema notable cuando se hace la ingeniería de productos o sistemas
manera consistente. grandes) y requerimientos en conflicto o irreales (no asequibles).
I NFOR MACIÓN
Lista de verificación para validar • ¿El requerimiento viola algunas restricciones del dominio?
requerimientos • ¿Puede someterse a prueba el requerimiento? Si es así, ¿es posible
especificar las pruebas (en ocasiones se denominan criterios de
Con frecuencia es útil analizar cada requerimiento en
validación) para ensayar el requerimiento?
comparación con preguntas de verificación. A continuación se pre-
sentan algunas:
• ¿Puede rastrearse el requerimiento hasta cualquier modelo del sis-
tema que se haya creado?
• ¿Los requerimientos están enunciados con claridad? ¿Podrían inter- • ¿Es posible seguir el requerimiento hasta los objetivos del sistema o
pretarse mal? producto?
• ¿Está identificada la fuente del requerimiento (por ejemplo, una per- • ¿La especificación está estructurada en forma que lleva a entender-
sona, reglamento o documento)? ¿Se ha estudiado el planteamiento lo con facilidad, con referencias y traducción fáciles a productos
final del requerimiento en comparación con la fuente original? del trabajo más técnicos?
• ¿El requerimiento está acotado en términos cuantitativos? • ¿Se ha creado un índice para la especificación?
• ¿Qué otros requerimientos se relacionan con éste? ¿Están compa- • ¿Están enunciadas con claridad las asociaciones de los requeri-
rados con claridad por medio de una matriz de referencia cruzada mientos con las características de rendimiento, comportamiento y
u otro mecanismo? operación? ¿Cuáles requerimientos parecen ser implícitos?
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. La
administración de los requerimientos es el conjunto de actividades que ayudan al equipo
del proyecto a identificar, controlar y dar seguimiento a los requerimientos y a sus cambios
en cualquier momento del desarrollo del proyecto.6 Muchas de estas actividades son idénticas
a las técnicas de administración de la configuración del software (TAS) que se estudian en el
capítulo 22.
5 Recuerde que la naturaleza de la especificación variará con cada proyecto. En ciertos casos, la “especificación”
no es más que un conjunto de escenarios de usuario. En otros, la especificación tal vez sea un documento que
contiene escenarios, modelos y descripciones escritas.
6 La administración formal de los requerimientos sólo se practica para proyectos grandes que tienen cientos
de requerimientos identificables. Para proyectos pequeños, esta actividad tiene considerablemente menos for-
malidad.
www.FreeLibros.me
05Pressman(101-125).indd 105 21/1/10 11:00:20

H ERRAMIENTAS DE SOFTWARE
Ingeniería de requerimientos
Objetivo: Las herramientas de la ingeniería de los reque- EasyRM, desarrollada por Cybernetic Intelligence GmbH (www.
rimientos ayudan a reunir éstos, a modelarlos, administrar- easy-rm.com), construye un diccionario/glosario especial
los y validarlos. para proyectos, que contiene descripciones y atributos detallados
Mecánica: La mecánica de las herramientas varía. En general, éstas de los requerimientos.
elaboran varios modelos gráficos (por ejemplo, UML) que ilustran los Rational RequisitePro, elaborada por Rational Software (www-306.
aspectos de información, función y comportamiento de un sistema. ibm.com/software/awdtools/reqpro/), permite a los
Estos modelos constituyen la base de todas las demás actividades del usuarios construir una base de datos de requerimientos, represen-
proceso de software. tar relaciones entre ellos y organizarlos, indicar su prioridad y
rastrearlos.
Herramientas representativas:7
En el sitio de Volere Requirements, en www.volere.co.uk/tools. En el sitio de Volere ya mencionado, se encuentran muchas herra-
htm, se encuentra una lista razonablemente amplia (y actualizada) mientas adicionales para administrar requerimientos, así como en
de herramientas para la ingeniería de requerimientos. En los capítulos la dirección www.jiludwig.com/Requirements_
6 y 7 se estudian las herramientas que sirven para modelar aquéllos. Management_Tools.html
Las que se mencionan a continuación se centran en su administración.
5. 2 ESTABLECER LAS BASES
En el caso ideal, los participantes e ingenieros de software trabajan juntos en el mismo equipo.8
En esas condiciones, la ingeniería de requerimientos tan sólo consiste en sostener conversacio-
nes significativas con colegas que sean miembros bien conocidos del equipo. Pero es frecuente
que en la realidad esto sea muy diferente.
Los clientes o usuarios finales tal vez se encuentren en ciudades o países diferentes, quizá
sólo tengan una idea vaga de lo que se requiere, puede ser que tengan opiniones en conflicto
sobre el sistema que se va a elaborar, que posean un conocimiento técnico limitado o que dis-
pongan de poco tiempo para interactuar con el ingeniero que recabará los requerimientos.
Ninguna de estas posibilidades es deseable, pero todas son muy comunes y es frecuente verse
forzado a trabajar con las restricciones impuestas por esta situación.
PU En las secciones que siguen se estudian las etapas requeridas para establecer las bases que
NT
O
permiten entender los requerimientos de software a fin de que el proyecto comience en forma
CLAVE tal que se mantenga avanzando hacia una solución exitosa.
Un participante es cualquier persona
que tenga interés directo o que se
beneficie del sistema que se va a 5.2.1 Identificación de los participantes
desarrollar. Sommerville y Sawyer [Som97] definen participante como “cualquier persona que se beneficie
en forma directa o indirecta del sistema en desarrollo”. Ya se identificaron los candidatos habi-
tuales: gerentes de operaciones del negocio, 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, entre otros. Cada participante tiene un punto
de vista diferente respecto del sistema, obtiene distintos beneficios cuando éste se desarrolla
con éxito y corre distintos riesgos si fracasa el esfuerzo de construcción.
7 Las herramientas mencionadas aquí no son obligatorias sino una muestra de las que hay en esta categoría. En la
mayoría de casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores.
8 Este enfoque es ampliamente recomendable para proyectos que adoptan la filosofía de desarrollo de soft-
ware ágil.
www.FreeLibros.me
05Pressman(101-125).indd 106 21/1/10 11:00:20

Durante la concepción, debe hacerse la lista de personas que harán aportes cuando se reca-
ben los requerimientos (véase la sección 5.3). La lista inicial crecerá cuando se haga contac-
to con los participantes porque a cada uno se le hará la pregunta: “¿A quién más piensa que debe
consultarse?”
5.2.2 Reconocer los múltiples puntos de vista

Cita:
Debido a que existen muchos participantes distintos, los requerimientos del sistema se explora-
“Ponga a tres participantes en
un cuarto y pregúnteles qué rán desde muchos puntos de vista diferentes. Por ejemplo, el grupo de mercadotecnia se inte-
clase de sistema quieren. Es pro- resa en funciones y características que estimularán el mercado potencial, lo que hará que el
bable que escuche cuatro o más nuevo sistema sea fácil de vender. Los gerentes del negocio tienen interés en un conjunto de
opiniones diferentes.” características para que se elabore dentro del presupuesto y que esté listo para ocupar nichos
Anónimo de mercado definidos. Los usuarios finales tal vez quieran características que les resulten fami-
liares y que sean fáciles de aprender y usar. Los ingenieros de software quizá piensen en fun-
ciones invisibles para los participantes sin formación técnica, pero que permitan una infraes-
tructura que dé apoyo a funciones y características más vendibles. Los ingenieros de apoyo tal
vez se centren en la facilidad del software para recibir mantenimiento.
Cada uno de estos integrantes (y otros más) aportará información al proceso de ingeniería
de los requerimientos. A medida que se recaba información procedente de múltiples puntos de
vista, los requerimientos que surjan tal vez sean inconsistentes o estén en conflicto uno con
otro. Debe clasificarse toda la información de los participantes (incluso los requerimientos in-
consistentes y conflictivos) en forma que permita a quienes toman las decisiones escoger para
el sistema un conjunto de requerimientos que tenga coherencia interna.
5.2.3 Trabajar hacia la colaboración

Si en un proyecto de software hay involucrados cinco participantes, tal vez se tengan cinco (o
más) diferentes opiniones acerca del conjunto apropiado de requerimientos. En los primeros
capítulos se mencionó que, para obtener un sistema exitoso, los clientes (y otros participantes)
debían colaborar entre sí (sin pelear por insignificancias) y con los profesionales de la ingeniería
de software. Pero, ¿cómo se llega a esta colaboración?
El trabajo del ingeniero de requerimientos es identificar las áreas de interés común (por ejem-
plo, requerimientos en los que todos los participantes estén de acuerdo) y las de conflicto o in-
congruencia (por ejemplo, requerimientos que desea un participante, pero que están en con-
flicto con las necesidades de otro). Es la última categoría la que, por supuesto, representa un
reto.
I NFOR MACIÓN
Uso de “puntos de prioridad”
Una manera de resolver requerimientos conflictivos y, al con la asignación de uno o más puntos de prioridad. Los puntos gas-
mismo tiempo, mejorar la comprensión de la importancia tados ya no pueden utilizarse otra vez. Cuando un participante agota
relativa de todos, es usar un esquema de “votación” con base en pun- sus puntos de prioridad, ya no tiene la posibilidad de hacer algo con
tos de prioridad. Se da a todos los participantes cierto número de los requerimientos. El total de puntos asignados a cada requerimiento
puntos de prioridad que pueden “gastarse” en cualquier número de por los participantes da una indicación de la importancia general de
requerimientos. Se presenta una lista de éstos y cada participante cada requerimiento.
indica la importancia relativa de cada uno (desde su punto de vista)
La colaboración no significa necesariamente que todos los requerimientos los defina un co-
mité. En muchos casos, los participantes colaboran con la aportación de su punto de vista res-
pecto de los requerimientos, pero un influyente “campeón del proyecto” (por ejemplo, el director
www.FreeLibros.me
05Pressman(101-125).indd 107 21/1/10 11:00:21

del negocio o un tecnólogo experimentado) toma la decisión final sobre los requerimientos que
lo integrarán.
5.2.4 Hacer las primeras preguntas

Las preguntas que se hacen en la concepción del proyecto deben estar “libres del contexto”
[Gau89]. El primer conjunto de ellas se centran en el cliente y en otros participantes, en las me-
tas y beneficios generales. Por ejemplo, tal vez se pregunte:
• ¿Quién está detrás de la solicitud de este trabajo?

Cita: • ¿Quién usará la solución?
“Es mejor conocer algunas pre- • ¿Cuál será el beneficio económico de una solución exitosa?
guntas que todas las
respuestas.” • ¿Hay otro origen para la solución que se necesita?
Estas preguntas ayudan a identificar a todos los participantes con interés en el software que se
James Thurber
va a elaborar. Además, las preguntas identifican el beneficio mensurable de una implementa-
ción exitosa y las posibles alternativas para el desarrollo de software personalizado.
Las preguntas siguientes permiten entender mejor el problema y hacen que el cliente exprese
sus percepciones respecto de la solución:
• ¿Cuál sería una “buena” salida generada por una solución exitosa?
? ¿Cuáles preguntas
ayudarían a tener un • ¿Qué problemas resolvería esta solución?
entendimiento
preliminar del • ¿Puede mostrar (o describir) el ambiente de negocios en el que se usaría la solución?
problema? • ¿Hay aspectos especiales del desempeño o restricciones que afecten el modo en el que
se enfoque la solución?
Las preguntas finales se centran en la eficacia de la actividad de comunicación en sí. Gause
y Weinberg [Gau89] las llaman “metapreguntas” y proponen la siguiente lista (abreviada):
• ¿Es usted la persona indicada para responder estas preguntas? ¿Sus respuestas son
Cita: “oficiales”?
“El que hace una pregunta es • ¿Mis preguntas son relevantes para el problema que se tiene?
tonto durante cinco minutos; el • ¿Estoy haciendo demasiadas preguntas?
que no la hace será tonto para
siempre.” • ¿Puede otra persona dar información adicional?
Proverbio chino
• ¿Debería yo preguntarle algo más?
Estas preguntas (y otras) ayudarán a “romper el hielo” y a iniciar la comunicación, que es esen-
cial para una indagación exitosa. Pero una reunión de preguntas y respuestas no es un enfoque
que haya tenido un éxito apabullante. En realidad, la sesión de preguntas y respuestas sólo debe
usarse para el primer encuentro y luego ser reemplazada por un formato de indagación de re-
querimientos que combine elementos de solución de problemas, negociación y especificación.
En la sección 5.3 se presenta un enfoque de este tipo.
5. 3 INDAGACIÓN DE LOS REQUERIMIENTOS
La indagación de los requerimientos (actividad también llamada recabación de los requerimien-

tos) 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 visio-
nes y especificar un conjunto preliminar de requerimientos para la solución [Zah90].9
9 En ocasiones se denomina a este enfoque técnica facilitada de especificación de la aplicación (TFEA).
www.FreeLibros.me
05Pressman(101-125).indd 108 21/1/10 11:00:21

5.3.1 Recabación de los requerimientos en forma colaborativa

Se han propuesto muchos enfoques distintos para recabar los requerimientos en forma colabo-
rativa. Cada uno utiliza un escenario un poco diferente, pero todos son variantes de los siguien-
tes lineamientos básicos:
• Tanto ingenieros de software como otros participantes dirigen o intervienen en las

? ¿Cuáles son los
lineamientos básicos reuniones.
para conducir una • Se establecen reglas para la preparación y participación.
reunión a fin de recabar
los requerimientos en • Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos impor-
forma colaborativa? tantes, pero con la suficiente informalidad para que estimule el libre flujo de ideas.
• Un “facilitador” (cliente, desarrollador o participante externo) controla la reunión.

• Se utiliza un “mecanismo de definición” (que pueden ser hojas de trabajo, tablas sueltas,
etiquetas adhesivas, pizarrón electrónico, grupos de conversación o foro virtual).
La meta es identificar el problema, proponer elementos de la solución, negociar distintos

Cita: enfoques y especificar un conjunto preliminar de requerimientos de la solución en una atmós-
fera que favorezca el logro de la meta. Para entender mejor el flujo de eventos conforme ocu-
“Dedicamos mucho tiempo —la
mayor parte de todo el esfuerzo rren, se presenta un escenario breve que bosqueja la secuencia de hechos que llevan a la re-
del proyecto— no a implemen- unión para obtener requerimientos, a lo que sucede durante ésta y a lo que sigue después de
tar o hacer pruebas, sino a ella.
tratar de decidir qué construir.” Durante la concepción (véase la sección 5.2), hay preguntas y respuestas básicas que esta-
Brian Lawrence blecen el alcance del problema y la percepción general de lo que constituye una solución. Fuera
de estas reuniones iniciales, el desarrollador y los clientes escriben una o dos páginas de “soli-
citud de producto”.
Se selecciona un lugar, fecha y hora para la reunión, se escoge un facilitador y se invita a
asistir a integrantes del equipo de software y de otras organizaciones participantes. Antes de la
fecha de la reunión, se distribuye la solicitud de producto a todos los asistentes.
WebRef Por ejemplo,10 considere un extracto de una solicitud de producto escrita por una persona de
La solicitud conjunta de desarrollo mercadotecnia involucrada en el proyecto CasaSegura. Esta persona escribe la siguiente narra-
(SCD) es una técnica popular para ción sobre la función de seguridad en el hogar que va a ser parte de CasaSegura:
recabar requerimientos. En la dirección
www.carolla.com/wp-jad.htm Nuestras investigaciones indican que el mercado para los sistemas de administración del hogar crece
se encuentra una buena descripción a razón de 40% anual. La primera función de CasaSegura que llevemos al mercado deberá ser la de
de ella.
seguridad del hogar. La mayoría de la gente está familiarizada con “sistemas de alarma”, por lo que
ésta deberá ser fácil de vender.
La función de seguridad del hogar protegería, o reconocería, varias “situaciones” indeseables,

CONSEJO como acceso ilegal, incendio y niveles de monóxido de carbono, entre otros. Emplearía sensores ina-
lámbricos para detectar cada situación. Sería programada por el propietario y telefonearía en forma
Si un sistema o producto servirá a
muchos usuarios, asegúrese de que automática a una agencia de vigilancia cuando detectara una situación como las descritas.
los requerimientos se obtengan de
En realidad, durante la reunión para recabar los requerimientos, otros contribuirían a esta
una franja representativa de ellos. Si
sólo uno define todos los narración y se dispondría de mucha más información. Pero aun con ésta habría ambigüedad,
requerimientos, el riesgo de no sería probable que existieran omisiones y ocurrieran errores. Por ahora bastará la “descripción
aceptación es elevado. funcional” anterior.
Mientras se revisa la solicitud del producto antes de la reunión, se pide a cada asistente que
elabore una lista de objetos que sean parte del ambiente que rodeará al sistema, los objetos
10 Este ejemplo (con extensiones y variantes) se usa para ilustrar métodos importantes de la ingeniería de software
en muchos de los capítulos siguientes. Como ejercicio, sería provechoso que el lector realizara su propia reunión
para recabar requerimientos y que desarrollara un conjunto de listas para ella.
www.FreeLibros.me
05Pressman(101-125).indd 109 21/1/10 11:00:21

que producirá éste y los que usará para realizar sus funciones. Además, se solicita a cada asis-
tente que haga otra lista de servicios (procesos o funciones) que manipulen o interactúen con
los objetos. Por último, también se desarrollan listas de restricciones (por ejemplo, costo, ta-
maño, reglas del negocio, etc.) y criterios de desempeño (como velocidad y exactitud). Se in-
forma a los asistentes que no se espera que las listas sean exhaustivas, pero sí que reflejen la
percepción que cada persona tiene del sistema.
Entre los objetos descritos por CasaSegura tal vez estén incluidos el panel de control, detec-
Cita: tores de humo, sensores en ventanas y puertas, detectores de movimiento, alarma, un evento
(activación de un sensor), una pantalla, una computadora, números telefónicos, una llamada
“Los hechos no dejan de existir
porque se les ignore.” telefónica, etc. La lista de servicios puede incluir configurar el sistema, preparar la alarma, vigilar
los sensores, marcar el teléfono, programar el panel de control y leer la pantalla (observe que los
Aldous Huxley
servicios actúan sobre los objetos). En forma similar, cada asistente desarrollará una lista de
restricciones (por ejemplo, el sistema debe reconocer cuando los sensores no estén operando,
debe ser amistoso con el usuario, debe tener una interfaz directa con una línea telefónica están-
dar, etc.) y de criterios de desempeño (un evento en un sensor debe reconocerse antes de un
segundo, debe implementarse un esquema de prioridad de eventos, etcétera).
Las listas de objetos pueden adherirse a las paredes del cuarto con el empleo de pliegos de
CONSEJO
papel grandes o con láminas adhesivas, o escribirse en un tablero. Alternativamente, las listas
Evite el impulso de desechar alguna podrían plasmarse en un boletín electrónico, sitio web interno o en un ambiente de grupo de
idea de un cliente con expresiones conversación para revisarlas antes de la reunión. Lo ideal es que cada entrada de las listas pueda
como “demasiado costosa” o
manipularse por separado a fin de combinar las listas o modificar las entradas y agregar otras.
“impráctica”. La intención aquí es
negociar una lista aceptable para En esta etapa, están estrictamente prohibidos las críticas y el debate.
todos. Para lograrlo, debe tenerse la Una vez que se presentan las listas individuales acerca de un área temática, el grupo crea una
mente abierta. lista, eliminando las entradas redundantes o agregando ideas nuevas que surjan durante el
análisis, pero no se elimina ninguna. Después de crear listas combinadas para todas las áreas
temáticas, sigue el análisis, coordinado por el facilitador. La lista combinada se acorta, se alarga
o se modifica su redacción para que refleje de manera apropiada al producto o sistema que se
va a desarrollar. El objetivo es llegar a un consenso sobre la lista de objetos, servicios, restric-
ciones y desempeño del sistema que se va a construir.
En muchos casos, un objeto o servicio descrito en la lista requerirá mayores explicaciones.
Para lograr esto, los participantes desarrollan miniespecificaciones para las entradas en las lis-
tas.11 Cada miniespecificación es una elaboración de un objeto o servicio. Por ejemplo, la corres-
pondiente al objeto Panel de control de CasaSegura sería así:
El panel de control es una unidad montada en un muro, sus dimensiones aproximadas son de 9 por 5
pulgadas. Tiene conectividad inalámbrica con los sensores y con una PC. La interacción con el usuario
tiene lugar por medio de un tablero que contiene 12 teclas. Una pantalla de cristal líquido de 3 por 3
pulgadas brinda retroalimentación al usuario. El software hace anuncios interactivos, como eco y
funciones similares.
Las miniespecificaciones se presentan a todos los participantes para que sean analizadas. Se
hacen adiciones, eliminaciones y otras modificaciones. En ciertos casos, el desarrollo de las
miniespecificaciones descubrirá nuevos objetos, servicios o restricciones, o requerimientos de
desempeño que se agregarán a las listas originales. Durante todos los análisis, el equipo debe
posponer los aspectos que no puedan resolverse en la reunión. Se conserva una lista de aspectos
para volver después a dichas ideas.
11 En vez de crear una miniespecificación, muchos equipos de software eligen desarrollar escenarios del usuario
llamados casos de uso. Éstos se estudian en detalle en la sección 5.4 y en el capítulo 6.
www.FreeLibros.me
05Pressman(101-125).indd 110 21/1/10 11:00:22

C ASA S EGURA
Conducción de una reunión para recabar los requerimientos
La escena: Sala de juntas. Está en marcha la pri- Facilitador: ¿Agrega eso algunas restricciones?
mera reunión para recabar los requerimientos. Jamie: Sí, tanto técnicas como legales.
Participantes: Jamie Lazar, integrante del equipo de software; Representante del producto: ¿Qué significa eso?
Vinod Raman, miembro del equipo de software; Ed Robbins, miem-
Jamie: Nos tendríamos que asegurar de que un extraño no pueda
bro del equipo de software; Doug Miller, gerente de ingeniería de
ingresar al sistema, desactivarlo y robar en el lugar o hacer algo
software; tres trabajadores de mercadotecnia; un representante de
peor. Mucha responsabilidad sobre nosotros.
ingeniería del producto, y un facilitador.
Doug: Muy cierto.
La conversación:
Mercadotecnia: Pero lo necesitamos así… sólo asegúrense de
Facilitador (apunta en un pizarrón): De modo que ésa es la
impedir que ingrese un extraño.
lista actual de objetos y servicios para la función de seguridad del
hogar. Ed: Eso es más fácil de decir que de hacer.
Persona de mercadotecnia: Eso la cubre, desde nuestro punto Facilitador (interrumpe): No quiero que debatamos esto ahora.
de vista. Anotémoslo como un aspecto y continuemos.
Vinod: ¿No dijo alguien que quería que toda la funcionalidad de (Doug, que es el secretario de la reunión, toma debida nota.)
CasaSegura fuera accesible desde internet? Eso incluiría la función Facilitador: Tengo la sensación de que hay más por considerar
de seguridad, ¿o no? aquí.
Persona de mercadotecnia: Sí, así es… tendremos que añadir (El grupo dedica los siguientes 20 minutos a mejorar y aumentar los
esa funcionalidad y los objetos apropiados. detalles de la función de seguridad del hogar.)
5.3.2 Despliegue de la función de calidad

PU El despliegue de la función de calidad (DFC) es una técnica de administración de la calidad que
NT
O traduce las necesidades del cliente en requerimientos técnicos para el software. El DFC “se con-
CLAVE centra en maximizar la satisfacción del cliente a partir del proceso de ingeniería del software”
El DFC define los requerimientos de [Zul92]. Para lograr esto, el DFC pone el énfasis en entender lo que resulta valioso para el cliente
forma que maximicen la satisfacción
y luego despliega dichos valores en todo el proceso de ingeniería. El DFC identifica tres tipos de
del cliente.
requerimientos [Zul92]:
Requerimientos normales. Objetivos y metas que se establecen para un producto o sis-

CONSEJO tema durante las reuniones con el cliente. Si estos requerimientos están presentes, el
Todos desean implementar muchos cliente queda satisfecho. Ejemplos de requerimientos normales son los tipos de gráficos pe-
requerimientos emocionantes, pero didos para aparecer en la pantalla, funciones específicas del sistema y niveles de rendi-
hay que tener cuidado. Así es como miento definidos.
empiezan a “quedar lisiados los
requerimientos”. Pero en Requerimientos esperados. Están implícitos en el producto o sistema y quizá sean tan
contrapartida, los requerimientos importantes que el cliente no los mencione de manera explícita. Su ausencia causará mu-
emocionantes llevan a un avance cha insatisfacción. Algunos ejemplos de requerimientos esperados son: fácil interacción
enorme del producto… humano/máquina, operación general correcta y confiable, y facilidad para instalar el soft-
ware.
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 ines-
peradas (como pantalla sensible al tacto, correo de voz visual, etc.) agrada a todos los
usuarios del producto.
WebRef Aunque los conceptos del DFC son aplicables en todo el proceso del software [Par96a], hay téc-
En la dirección www.qfdi.org se nicas específicas de aquél que pueden aplicarse a la actividad de indagación de los requerimien-
encuentra información útil sobre el tos. El DFC utiliza entrevistas con los clientes, observación, encuestas y estudio de datos histó-
DFC.
ricos (por ejemplo, reportes de problemas) como materia prima para la actividad de recabación
www.FreeLibros.me
05Pressman(101-125).indd 111 21/1/10 11:00:22

de los requerimientos. Después, estos datos se llevan a una tabla de requerimientos —llamada
tabla de la voz del cliente— que se revisa con el cliente y con otros participantes. Luego se em-
plean varios diagramas, matrices y métodos de evaluación para extraer los requerimientos es-
perados y tratar de percibir requerimientos emocionantes [Aka04].
5.3.3 Escenarios de uso

A medida que se reúnen los requerimientos, comienza a materializarse la visión general de
funciones y 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. Para lograr esto, los desarrolladores y usuarios crean un
conjunto de escenarios que identifican la naturaleza de los usos para el sistema que se va a
construir. Los escenarios, que a menudo se llaman casos de uso [Jac92], proporcionan la des-
cripción de la manera en la que se utilizará el sistema. Los casos de uso se estudian con más
detalle en la sección 5.4.
C ASA S EGURA
Desarrollo de un escenario preliminar de uso
La escena: Una sala de juntas, donde continúa la Vinod (interrumpe): La página web tendría que ser segura,
primera reunión para recabar los requerimientos. encriptada, para garantizar que estuviéramos seguros y…
Participantes: Jamie Lazar, integrante del equipo de software; Facilitador (interrumpe): Ésa es buena información, Vinod,
Vinod Raman, miembro del equipo de software; Ed Robbins, miem- pero es técnica. Centrémonos en cómo emplearía el usuario final
bro del equipo de software; Doug Miller, gerente de ingeniería de esta capacidad, ¿está bien?
software; tres personas de mercadotecnia; un representante de inge- Vinod: No hay problema.
niería del producto, y un facilitador.
Persona de mercadotecnia: Decía que entraría a un sitio web
La conversación: y daría mi identificación de usuario y dos niveles de clave.
Facilitador: Hemos estado hablando sobre la seguridad para el Jamie: ¿Qué pasa si olvido mi clave?
acceso a la funcionalidad de CasaSegura si ha de ser posible el Facilitador (interrumpe): Buena observación, Jamie, pero no
ingreso por internet. Me gustaría probar algo. Desarrollemos un entraremos a ella por ahora. Lo anotaremos y la llamaremos una
escenario de uso para entrar a la función de seguridad. excepción. Estoy seguro de que habrá otras.
Jamie: ¿Cómo? Persona de mercadotecnia: Después de que introdujera las
Facilitador: Podríamos hacerlo de dos maneras, pero de momento claves, aparecería una pantalla que representaría todas las funcio-
mantengamos las cosas informales. Díganos (señala a una persona nes de CasaSegura. Seleccionaría la función de seguridad del hogar.
de mercadotecnia), ¿cómo visualiza el acceso al sistema? El sistema pediría que verificara quién soy, pidiendo mi dirección o
número telefónico o algo así. Entonces aparecería un dibujo del
Persona de mercadotecnia: Um… bueno, es la clase de cosa
panel de control del sistema de seguridad y la lista de funciones que
que haría si estuviera fuera de casa y tuviera que dejar entrar a
puede realizar —activar el sistema, desactivar el sistema o desacti-
alguien a ella —por ejemplo, una trabajadora doméstica o un técni-
var uno o más sensores—. Supongo que también me permitiría
co de reparaciones— que no tuviera el código de seguridad.
reconfigurar las zonas de seguridad y otras cosas como ésa, pero no
Facilitador (sonríe): Ésa es la razón por la que lo hace… díga- estoy seguro.
me, ¿cómo lo haría en realidad? (Mientras la persona de mercadotecnia habla, Doug toma muchas
Persona de mercadotecnia: Bueno… lo primero que necesita- notas; esto forma la base para el primer escenario informal de uso.
ría sería una PC. Entraría a un sitio web que mantendríamos para Alternativamente, hubiera podido pedirse a la persona de mercado-
todos los usuarios de CasaSegura. Daría mi identificación de usuario tecnia que escribiera el escenario, pero esto se hubiera hecho fuera
y… de la reunión.)
5.3.4 Indagación de los productos del 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:
www.FreeLibros.me
05Pressman(101-125).indd 112 21/1/10 11:00:22

• Un enunciado de la necesidad y su factibilidad.

? ¿Qué información se
produce como conse- • Un enunciado acotado del alcance del sistema o producto.
cuencia de recabar los
requerimientos? • Una lista de clientes, usuarios y otros participantes que intervienen en la indagación de
los requerimientos.
• Una descripción del ambiente técnico del sistema.

• Una lista de requerimientos (de preferencia organizados por función) y las restricciones
del dominio que se aplican a cada uno.
• Un conjunto de escenarios de uso que dan perspectiva al uso del sistema o producto en
diferentes condiciones de operación.
• Cualesquiera prototipos desarrollados para definir requerimientos.

Cada uno de estos productos del trabajo es revisado por todas las personas que participan en la
indagación de los requerimientos.
5. 4 DESARROLLO DE CASOS DE USO
En un libro que analiza cómo escribir casos de uso eficaces, Alistair Cockburn [Coc01b] afirma
que “un caso de uso capta un contrato […] [que] describe el comportamiento del sistema en
distintas condiciones en las que el sistema responde a una petición de alguno de sus participan-
tes […]”. En esencia, un caso de uso narra una historia estilizada sobre cómo interactúa un
usuario final (que tiene cierto número de roles posibles) con el sistema en circunstancias espe-
cíficas. La historia puede ser un texto narrativo, un lineamiento de tareas o interacciones, una
descripción basada en un formato o una representación diagramática. Sin importar su forma,
un caso de uso ilustra el software o sistema desde el punto de vista del usuario final.
PU El primer paso para escribir un caso de uso es definir un conjunto de “actores” que estarán
NT
O involucrados en la historia. Los actores son las distintas personas (o dispositivos) que usan el
CLAVE sistema o producto en el contexto de la función y comportamiento que va a describirse. Los
Los casos de uso se definen desde el actores representan los papeles que desempeñan las personas (o dispositivos) cuando opera el
punto de vista de un actor. Un actor
sistema. Con una definición más formal, un actor es cualquier cosa que se comunique con
es un papel que desempeñan las
el sistema o producto y que sea externo a éste. Todo actor tiene uno o más objetivos cuando
personas (usuarios) o los dispositivos
cuando interactúan con el software. utiliza el sistema.
Es importante notar que un actor y un usuario final no necesariamente son lo mismo.
Un usuario normal puede tener varios papeles diferentes cuando usa el sistema, mientras
que un actor representa una clase de entidades externas (gente, con frecuencia pero no
siempre) que sólo tiene un papel en el contexto del caso de uso. Por ejemplo, considere al ope-
rador de una máquina (un usuario) que interactúa con la computadora de control de una celda
de manufactura que contiene varios robots y máquinas de control numérico. Después de una
revisión cuidadosa de los requerimientos, el software para la computadora de control requiere
cuatro diferentes modos (papeles) para la interacción: modo de programación, modo de prueba,
modo de vigilancia y modo de solución de problemas. Por tanto, es posible definir cuatro acto-
res: programador, probador, vigilante y solucionador de problemas. En ciertos casos, el opera-
dor de la máquina desempeñará todos los papeles. En otros, distintas personas tendrán el papel
de cada actor.
WebRef Debido a que la indagación de los requerimientos es una actividad evolutiva, no todos los
Un artículo excelente sobre casos de actores son identificados en la primera iteración. En ésta es posible identificar a los actores
uso puede descargarse desde la
dirección www.ibm.com/ principales [Jac92], y a los secundarios cuando se sabe más del sistema. Los actores principa-
developerworks/ les interactúan para lograr la función requerida del sistema y obtienen el beneficio previsto de
webservices/library/ éste. Trabajan con el software en forma directa y con frecuencia. Los actores secundarios dan
codesign7.html
apoyo al sistema, de modo que los primarios puedan hacer su trabajo.
www.FreeLibros.me
05Pressman(101-125).indd 113 21/1/10 11:00:23

Una vez identificados los actores, es posible desarrollar casos de uso. Jacobson [Jac92] su-
giere varias preguntas12 que debe responder un caso de uso:
• ¿Quién es el actor principal y quién(es) el(los) secundario(s)?

? ¿Qué se necesita saber
a fin de desarrollar un • ¿Cuáles son los objetivos de los actores?
caso de uso eficaz?
• ¿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?
En relación con los requerimientos básicos de CasaSegura, se definen cuatro actores: pro-
pietario de la casa (usuario), gerente de arranque (tal vez la misma persona que el propie-
tario de la casa, pero en un papel diferente), sensores (dispositivos adjuntos al sistema) y
subsistema de vigilancia y respuesta (estación central que vigila la función de seguridad de
la casa de CasaSegura). Para fines de este ejemplo, consideraremos sólo al actor llamado pro-
pietario de la casa. Éste interactúa con la función de seguridad de la casa en varias formas
distintas con el empleo del panel de control de la alarma o con una PC:
• Introduce una clave que permita todas las demás interacciones.

• Pregunta sobre el estado de una zona de seguridad.
• Interroga acerca del estado de un sensor.
• En una emergencia, oprime el botón de pánico.
• Activa o desactiva el sistema de seguridad.
Considerando la situación en la que el propietario de la casa usa el panel de control, a continua-
ción se plantea el caso de uso básico para la activación del sistema:13
1. El propietario observa el panel de control de CasaSegura (véase la figura 5.1) para determinar si el
sistema está listo para recibir una entrada. Si el sistema no está listo, se muestra el mensaje no está
listo en la pantalla de cristal líquido y el propietario debe cerrar físicamente ventanas o puertas de
modo que desaparezca dicho mensaje [el mensaje no está listo implica que un sensor está abierto;
por ejemplo, que una puerta o ventana está abierta].
2. El propietario usa el teclado para introducir una clave de cuatro dígitos. La clave se compara con
la que guarda el sistema como válida. Si la clave es incorrecta, el panel de control emitirá un sonido
una vez y se reiniciará para recibir una entrada adicional. Si la clave es correcta, el panel de control
espera otras acciones.
3. El propietario selecciona y teclea permanecer o fuera (véase la figura 5.1) para activar el sistema. La
entrada permanecer activa sólo sensores perimetrales (se desactivan los sensores de detección de
movimiento interior). La entrada fuera activa todos los sensores.
4. Cuando ocurre una activación, el propietario observa una luz roja de alarma.
12 Las preguntas de Jacobson se han ampliado para que den una visión más completa del contenido del caso de
uso.
13 Observe que este caso de uso difiere de la situación en la que se accede al sistema a través de internet. En este
caso, la interacción es por medio del panel de control y no con la interfaz de usuario gráfica (GUI) que se da
cuando se emplea una PC.
www.FreeLibros.me
05Pressman(101-125).indd 114 21/1/10 11:00:23

FIGURA 5.1
Panel de control CASASEGURA apagar fuera permanecer
de CasaSegura
1 2 3
fuera
permanecer max probar desvío
alarma de instantáneo 4 5 6
comprobación desvío
instantáneo código repicar
de incendio no está listo
7 8 9
listo
activada energía
* 0 #
pánico
El caso de uso básico presenta una historia de alto nivel que describe la interacción entre el
CONSEJO
actor y el sistema.
Es frecuente que los casos de uso se En muchas circunstancias, los casos de uso son más elaborados a fin de que brinden muchos
escriban de manera informal. Sin más detalles sobre la interacción. Por ejemplo, Cockburn [Coc01b] sugiere el formato siguiente
embargo, utilice el formato que se
para hacer descripciones detalladas de casos de uso:
presenta aquí para asegurar que se
incluyen todos los aspectos clave. Caso de uso: IniciarVigilancia
Actor principal: Propietario.
Objetivo en contexto: Preparar el sistema para que vigile los sensores cuando el propietario salga
de la casa o permanezca dentro.
Precondiciones: El sistema se ha programado para recibir una clave y reconocer distintos

sensores.
Disparador: El propietario decide “preparar” el sistema, por ejemplo, para que encienda
las funciones de alarma.
Escenario:
1. Propietario: observa el panel de control
2. Propietario: introduce una clave
3. Propietario: selecciona “permanecer” o “fuera”
4. Propietario: observa una luz roja de alarma que indica que CasaSegura ha sido activada.
Excepciones:
1. El panel de control no está listo: el propietario verifica todos los sensores para determinar cuáles
están abiertos; los cierra.
2. La clave es incorrecta (el panel de control suena una vez): el propietario introduce la clave co-
rrecta.
3. La clave no es reconocida: debe contactarse el subsistema de vigilancia y respuesta para reprogra-

mar la clave.
4. Se elige permanecer: el panel de control suena dos veces y se enciende un letrero luminoso que dice
permanecer; se activan los sensores del perímetro.
5. Se selecciona fuera: el panel de control suena tres veces y se enciende un letrero luminoso que dice
fuera; se activan todos los sensores.
www.FreeLibros.me
05Pressman(101-125).indd 115 21/1/10 11:00:23

Prioridad: Esencial, debe implementarse
Cuándo estará disponible: En el primer incremento
Frecuencia de uso: Muchas veces por día
Canal para el actor: A través de la interfaz del panel de control
Actores secundarios: Técnico de apoyo, sensores
Canales para los actores secundarios:
Técnico de apoyo: línea telefónica
Sensores: interfaces cableadas y frecuencia de radio
Aspectos pendientes:
1. ¿Debe haber una forma de activar el sistema sin usar clave o con una clave abreviada?
2. ¿El panel de control debe mostrar mensajes de texto adicionales?
3. ¿De cuánto tiempo dispone el propietario para introducir la clave a partir del momento en el que se
oprime la primera tecla?
4. ¿Hay una forma de desactivar el sistema antes de que se active en realidad?
Los casos de uso para otras interacciones de propietario se desarrollarían en una forma simi-
lar. Es importante revisar con cuidado cada caso de uso. Si algún elemento de la interacción es
ambiguo, es probable que la revisión del caso de uso lo detecte.
C ASA S EGURA
Desarrollo de un diagrama de caso de uso de alto nivel
La escena: Sala de juntas, continúa la reunión el caso de uso…—; ¡ah! usé el cuadrado para representar un actor
para recabar los requerimientos. que no es persona… en este caso, sensores.
Participantes: Jamie Lazar, miembro del equipo de software; Doug: ¿Es válido eso en UML?
Vinod Roman, integrante del equipo de software; Ed Robbins, inte- Facilitador: La legalidad no es lo importante. El objetivo es comu-
grante del equipo de software; Doug Miller, gerente de ingeniería de nicar información. Veo que usar una figura humana para represen-
software; tres miembros de mercadotecnia; un representante de inge- tar un equipo sería erróneo. Así que adapté las cosas un poco. No
niería del producto; un facilitador. pienso que genere problemas.
La conversación: Vinod: Está bien, entonces tenemos narraciones de casos de uso
Facilitador: Hemos pasado un buen tiempo hablando de la fun- para cada óvalo. ¿Necesitamos desarrollarlas con base en los for-
ción de seguridad del hogar de CasaSegura. Durante el receso hice matos sobre los que he leído?
un diagrama de caso de uso para resumir los escenarios importantes Facilitador: Es probable, pero eso puede esperar hasta que haya-
que forman parte de esta función. Veámoslo. mos considerado otras funciones de CasaSegura.
(Todos los asistentes observan la figura 5.2.) Persona de mercadotecnia: Esperen, he estado observando
Jamie: Estoy aprendiendo la notación UML.14 Veo que la función de este diagrama y de pronto me doy cuenta de que hemos olvidado
seguridad del hogar está representada por el rectángulo grande con algo.
óvalos en su interior, ¿verdad? ¿Y los óvalos representan los casos de Facilitador: ¿De verdad? Dime, ¿qué hemos olvidado?
uso que hemos escrito?
(La reunión continúa.)
Facilitador: Sí. Y las figuras pegadas representan a los actores
—personas o cosas que interactúan con el sistema según los describe
14 En el apéndice 1 se presenta un breve método de aprendizaje de UML para aquellos lectores que no estén fami-
liarizados con dicha notación.
www.FreeLibros.me
05Pressman(101-125).indd 116 21/1/10 11:00:24

FIGURA 5.2
Diagrama de Sistema
caso de uso de que activa o
UML para la desactiva
función de Accede
seguridad del al sistema Sensores
hogar de por internet
CasaSegura Propietario
Responde
a un evento
de alarma
Encuentra
una condición
de error
Administrador
del sistema
Reconfigura
sensores y
características
del sistema
relacionadas
H ERRAMIENTAS DE SOFTWARE
Desarrollo de un caso de uso Herramientas representativas15
Objetivo: Ayudar a desarrollar casos de uso proporcio- La gran mayoría de herramientas de análisis del modelado basadas
nando formatos y mecanismos automatizados para eva- en UML dan apoyo tanto de texto como gráfico para el desarrollo y
luar la claridad y consistencia. modelado de casos de uso.
Mecánica: La mecánica de las herramientas varía. En general, las Objects by Design

herramientas para casos de uso dan formatos con espacios en blanco (www.objectsbydesign.com/tools/umltools_byCompany.
para ser llenados y crear así casos eficaces. La mayor parte de la fun- html) proporciona vínculos exhaustivos con herramientas de este
cionalidad de los casos de uso está incrustada en un conjunto más tipo.
amplio de funciones de ingeniería de los requerimientos.
5. 5 ELABORACIÓN D E L M O D E L O D E L O S R E Q U E R I M I E N T O S 16
El objetivo del modelo del análisis es describir los dominios de información, función y compor-
tamiento 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 por construir, y otros participantes
comprenden más lo que en realidad requieren. Por esa razón, el modelo del análisis es una fo-
tografía de los requerimientos en cualquier momento dado. Es de esperar que cambie.
A medida que evoluciona el modelo de requerimientos, ciertos elementos se vuelven relati-
vamente estables, lo que da un fundamento sólido para diseñar las tareas que sigan. Sin em-
bargo, otros elementos del modelo son más volátiles, lo que indica que los participantes todavía
no entienden bien los requerimientos para el sistema. En los capítulos 6 y 7 se presentan en
15 Las herramientas mencionadas aquí no son obligatorias, sino una muestra de las que hay en esta categoría. En la
mayoría de casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores.
16 En este libro se usan como sinónimos las expresiones modelar el análisis y modelar los requerimientos. Ambos se
refieren a representaciones de los dominios de la información, funcional y de comportamiento que describen los
requerimientos del problema.
www.FreeLibros.me
05Pressman(101-125).indd 117 21/1/10 11:00:24

detalle el modelo del análisis y los métodos que se usan para construirlo. En las secciones si-
guientes se da un panorama breve.
5.5.1 Elementos del modelo de requerimientos

Hay muchas formas diferentes de concebir los requerimientos para un sistema basado en
computadora. Algunos profesionales del software afirman que es mejor seleccionar un modo 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 de representación fuerzan a consi-
derar los requerimientos desde distintos puntos de vista, enfoque que tiene una probabilidad
mayor de detectar omisiones, inconsistencia y ambigüedades.
Los elementos específicos del modelo de requerimientos están determinados por el método
de análisis de modelado (véanse los capítulos 6 y 7) que se use. No obstante, la mayoría de mo-
delos tiene en común un conjunto de elementos generales.
Elementos basados en el escenario. El sistema se describe desde el punto de vista del

CONSEJO usuario con el empleo de un enfoque basado en el escenario. Por ejemplo, los casos de uso
Siempre es buena idea involucrar a básico (véase la sección 5.4) y sus diagramas correspondientes de casos de uso (véase la figura
los participantes. Una de las mejores 5.2) evolucionan hacia otros más elaborados que se basan en formatos. Los elementos del mo-
formas de lograrlo es hacer que cada delo de requerimientos basados en el escenario con frecuencia son la primera parte del modelo
uno escriba casos de uso que narren
en desarrollo. Como tales, sirven como entrada para la creación de otros elementos de mode-
el modo en el que se utilizará el
lado. La figura 5.3 ilustra un diagrama de actividades UML17 para indagar los requerimientos y
software.
representarlos con el empleo de casos de uso. Se aprecian tres niveles de elaboración que cul-
minan en una representación basada en el escenario.
Elementos basados en clases. Cada escenario de uso implica un conjunto de objetos que
CONSEJO se manipulan cuando un actor interactúa con el sistema. Estos objetos se clasifican en clases:
Una forma de aislar las clases es conjunto de objetos que tienen atributos similares y comportamientos comunes. Por ejemplo,
buscar sustantivos descriptivos en un para ilustrar la clase Sensor de la función de seguridad de Casa Segura (véase la figura 5.4),
caso de usuario expresado con texto. puede utilizarse un diagrama de clase UML. Observe que el diagrama enlista los atributos de los
Al menos algunos de ellos serán
sensores (por ejemplo, nombre, tipo, etc.) y las operaciones (por ejemplo, identificar y permitir)
candidatos cercanos. Sobre esto se
habla más en el capítulo 8. que se aplican para modificarlos. Además de los diagramas de clase, otros elementos de mode-
lado del análisis ilustran la manera en la que las clases colaboran una con otra y las relaciones
e interacciones entre ellas. Esto se analiza con más detalle en el capítulo 7.
Elementos de comportamiento. El comportamiento de un sistema basado en computadora

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 ilus-
tren el comportamiento.
PU El diagrama de estado es un método de representación del comportamiento de un sistema que
NT
O ilustra sus estados y los eventos que ocasionan que el sistema cambie de estado. Un estado es
CLAVE cualquier modo de comportamiento observable desde el exterior. Además, el diagrama de es-
Un estado es un modo de
tado indica acciones (como la activación de un proceso, por ejemplo) tomadas como conse-
comportamiento observable desde el
exterior. Los estímulos externos cuencia de un evento en particular.
ocasionan transiciones entre los Para ilustrar el uso de un diagrama de estado, considere el software incrustado dentro del
estados. panel de control de CasaSegura que es responsable de leer las entradas que hace el usuario. En
la figura 5.5 se presenta un diagrama de estado UML simplificado.
Además de las representaciones de comportamiento del sistema como un todo, también es
posible modelar clases individuales. Sobre esto se presentan más análisis en el capítulo 7.
17 En el apéndice 1 se presenta un instructivo breve sobre UML, para aquellos lectores que no estén familiarizados
con dicha notación.
www.FreeLibros.me
05Pressman(101-125).indd 118 21/1/10 11:00:24

FIGURA 5.3
Diagramas de
actividad del
UML para Efectuar
indagar los reuniones
requerimientos
Elaborar listas de
funciones y clases
Hacer listas de
restricciones, entre otras
¿Se dan prioridades
Indagación de formales?
los requerimientos Sí No
Definir
Usar el DFC Dar prioridad a actores
para asignar los requerimien-
prioridad a los tos de manera
requerimientos informal Hacer un Escribir
diagrama del el escenario
caso de uso
Terminar
Crear casos
el formato
de uso
FIGURA 5.4
Sensor
Diagrama de
clase para un Nombre
sensor
Tipo
Ubicación
Área
Características
Identificar()
Activar()
Desactivar()
Reconfigurar()
FIGURA 5.5
Comandos
Notación UML del
de lectura
diagrama de Nombre del estado
estado
Estado del sistema = “Listo”
Mensaje en la pantalla = “introducir comando” Variables del estado
Estado de la pantalla = estable
Entrar /subsistemas listos

Hacer: panel de entradas del grupo de usuarios Actividades del estado
Hacer: lectura de la entrada del usuario
Hacer: interpretación de la entrada del usuario
www.FreeLibros.me
05Pressman(101-125).indd 119 21/1/10 11:00:24

C ASA S EGURA
Modelado preliminar del comportamiento
La escena: Sala de juntas, continúa la reunión de Persona de mercadotecnia: Esto parece un poco técnico. No
requerimientos. estoy seguro de ser de ayuda aquí.
Participantes: Jamie Lazar, integrante del equipo de software; Facilitador: Seguro que lo serás. ¿Qué comportamiento se obser-
Vinod Raman, miembro del equipo de software; Ed Robbins, inte- va desde el punto de vista de un usuario?
grante del equipo de software; Doug Miller, gerente de ingeniería de Persona de mercadotecnia: Mmm... bueno, el sistema estará
software; tres trabajadores de mercadotecnia; un representante de vigilando los sensores. Leerá comandos del propietario. Mostrará su
ingeniería del producto, y un facilitador. estado.
La conversación: Facilitador: ¿Ves?, lo puedes hacer.
Facilitador: Estamos por terminar de hablar sobre la funcionalidad Jamie: También estará interrogando a la PC para determinar si hay
de seguridad del hogar de CasaSegura. Pero antes, quisiera que alguna entrada desde ella, por ejemplo, un acceso por internet o
analizáramos el comportamiento de la función. información sobre la configuración.
Persona de mercadotecnia: No entiendo lo que quiere decir Vinod: Sí, en realidad, configurar el sistema es un estado por dere-
con comportamiento. cho propio.
Ed (sonríe): Es cuando le das un “tiempo fuera” al producto si se Doug: Muchachos, lo hacen bien. Pensemos un poco más... ¿hay
porta mal. alguna forma de hacer un diagrama de todo esto?
Facilitador: No exactamente. Permítanme explicarlo. Facilitador: Sí la hay, pero la dejaremos para la próxima reunión.
(El facilitador explica al equipo encargado de recabar los requeri-
mientos y los fundamentos de modelado del comportamiento.)
Elementos orientados al flujo. La información se transforma cuando fluye a través de un

sistema basado en computadora. El sistema acepta entradas en varias formas, aplica funciones
para transformarla y produce salidas en distintos modos. La entrada puede ser una señal de
control transmitida por un transductor, una serie de números escritos con el teclado por un
operador humano, un paquete de información enviado por un enlace de red o un archivo grande
de datos recuperado de un almacenamiento secundario. La transformación quizá incluya una
sola comparación lógica, un algoritmo numérico complicado o un enfoque de regla de inferen-
cia para un sistema experto. La salida quizá encienda un diodo emisor de luz o genere un in-
forme de 200 páginas. En efecto, es posible crear un modelo del flujo para cualquier sistema
basado en computadora, sin importar su tamaño y complejidad. En el capítulo 7 se hace un
análisis más detallado del modelado del flujo.
5.5.2 Patrones de análisis

Cualquiera que haya hecho la ingeniería de los requerimientos en varios proyectos de software
ha observado que ciertos problemas son recurrentes en todos ellos dentro de un dominio de
aplicación específico.18 Estos patrones de análisis [Fow97] sugieren soluciones (por ejemplo, una
clase, función o comportamiento) dentro del dominio de la aplicación que pueden volverse a
utilizar cuando se modelen muchas aplicaciones.
Geyer-Schulz y Hahsler [Gey01] sugieren dos beneficios asociados con el uso de patrones de
análisis:
En primer lugar, los patrones de análisis aceleran el desarrollo de los modelos de análisis abstracto
que capturan los principales requerimientos del problema concreto, debido a que proveen modelos de
análisis reutilizables con ejemplos, así como una descripción de sus ventajas y limitaciones. En se-
18 En ciertos casos, los problemas vuelven a suceder sin importar el dominio de la aplicación. Por ejemplo, son
comunes las características y funciones usadas para resolver problemas de la interfaz de usuario sin importar el
dominio de la aplicación en consideración.
www.FreeLibros.me
05Pressman(101-125).indd 120 21/1/10 11:00:25

gundo lugar, los patrones de análisis facilitan la transformación del modelo de análisis en un modelo
del diseño, sugiriendo patrones de diseño y soluciones confiables para problemas comunes.
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. La informa-
ción sobre el patrón de análisis (y otros tipos de patrones) se presenta en un formato estándar
[Gey01]19 que se estudia con más detalle en el capítulo 12. En el capítulo 7 se dan ejemplos de
patrones de análisis y más detalles de este tema.
5. 6 REQUERIMIENTOS DE LAS NEGOCIACIONES
En un contexto ideal de la ingeniería de los requerimientos, las tareas de concepción, indaga-

ción y elaboración determinan los requerimientos del cliente con suficiente detalle como para
Cita: avanzar hacia las siguientes actividades de la ingeniería de software. Desafortunadamente, esto
rara vez ocurre. En realidad, se tiene que entrar en negociaciones con uno o varios participan-
“Un compromiso es el arte de
dividir un pastel en forma tal tes. En la mayoría de los casos, se pide a éstos que evalúen la funcionalidad, desempeño y otras
que todos crean que tienen el características del producto o sistema, en contraste con el costo y el tiempo para entrar al mer-
trozo mayor.” cado. El objetivo de esta negociación es desarrollar un plan del proyecto que satisfaga las nece-
Ludwig Erhard sidades 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”.20 Es decir, los participantes
WebRef ganan porque obtienen el sistema o producto que satisface la mayoría de sus necesidades y
Un artículo breve sobre la negociación usted (como miembro del equipo de software) gana porque trabaja con presupuestos y plazos
para los requerimientos de software realistas y asequibles.
puede descargarse desde la dirección
Boehm [Boe98] define un conjunto de actividades de negociación al principio de cada itera-
www.alexander-egyed.com/
publications/Software_ ción del proceso de software. En lugar de una sola actividad de comunicación con el cliente, se
Requirements_Negotiation- definen las actividades siguientes:
Some_Lessons_Learned.html
1. Identificación de los participantes clave del sistema o subsistema.
2. Determinación de las “condiciones para ganar” de los participantes.
I NFOR MACIÓN
El arte de la negociación
Aprender a negociar con eficacia le servirá en su vida bable que obtenga conocimientos que lo ayuden a negociar
personal y técnica. Es útil considerar los lineamientos que mejor su posición.
siguen: 4. Centrarse en los intereses de la otra parte. Si quiere evitar con-
flictos, no adopte posiciones inamovibles.
1. Reconocer que no es una competencia. Para tener éxito, ambas 5. No lo tome en forma personal. Céntrese en el problema que
partes tienen que sentir que han ganado o logrado algo. Las necesita resolverse.
dos tienen que llegar a un compromiso. 6. Sea creativo. Si están empantanados, no tenga miedo de pen-
2. Mapear una estrategia. Decidir qué es lo que le gustaría lograr; sar fuera de los moldes.
qué quiere obtener la otra parte y cómo hacer para que ocu- 7. Esté listo para comprometerse. Una vez que se llegue a un
rran las dos cosas. acuerdo, no titubee; comprométase con él y cúmplalo.
3. Escuchar activamente. No trabaje en la formulación de su res-
puesta mientras la otra parte esté hablando. Escúchela. Es pro-
19 En la bibliografía existen varias propuestas de formatos para patrones. Si el lector tiene interés, consulte [Fow97],
[Gam95], [Yac03] y [Bus07], entre muchas otras fuentes.
20 Se han escrito decenas de libros acerca de las aptitudes para negociar (por ejemplo [Lew06], [Rai06] y [Fis06]).
Es una de las aptitudes más importantes que pueda aprender. Lea alguno.
www.FreeLibros.me
05Pressman(101-125).indd 121 21/1/10 11:00:25

3. 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).
La realización exitosa de estos pasos iniciales lleva a un resultado ganar-ganar, que se convierte
en el criterio clave para avanzar hacia las siguientes actividades de la ingeniería de software.
C ASA S EGURA
El principio de una negociación
La escena: Oficina de Lisa Pérez, después de la Lisa: Doug, es el acceso por internet lo que da a CasaSegura su
primera reunión para recabar los requerimientos. “súper” atractivo. Toda nuestra campaña de publicidad va a girar
Participantes: Doug Miller, gerente de ingeniería de software, y alrededor de eso. Lo tenemos que tener…
Lisa Pérez, gerente de mercadotecnia. Doug: Entiendo la situación, de verdad. El problema es que para
La conversación: dar acceso por internet tendríamos que tener un sitio web por com-
pleto seguro y en operación. Esto requiere tiempo y personal. Tam-
Lisa: Pues escuché que la primera reunión salió realmente bien.
bién tenemos que elaborar mucha funcionalidad adicional en la pri-
Doug: En realidad, sí. Enviaste buenos representantes... contribuye- mera entrega… no creo que podamos hacerlo con los recursos que
ron de verdad. tenemos.
Lisa (sonríe): Sí; en realidad me dijeron que habían entrado y que Lisa (todavía frunce el ceño): Ya veo, pero tienes que imaginar
no había sido una “actividad que les despejara la cabeza”. una manera de hacerlo. Tiene importancia crítica para las funciones
Doug (ríe): La próxima vez me aseguraré de quitarme la vena tec- de seguridad del hogar y también para otras… éstas podrían espe-
nológica... Mira, Lisa, creo que tenemos un problema para llegar a rar hasta las siguientes entregas… estoy de acuerdo con eso.
toda esa funcionalidad del sistema de seguridad para el hogar en Lisa y Doug parecen estar en suspenso, pero todavía deben negociar
las fechas que propone tu dirección. Sé que aún es temprano, pero una solución a este problema. ¿Pueden “ganar” los dos en este caso?
hice un poco de planeación sobre las rodillas y... Si usted fuera el mediador, ¿qué sugeriría?
Lisa (con el ceño fruncido): Lo debemos tener para esa fecha,
Doug. ¿De qué funcionalidad hablas?
Doug: Supongo que podemos tener la funcionalidad completa en la
fecha establecida, pero tendríamos que retrasar el acceso por inter-
net hasta el segundo incremento.
5. 7 VA L I D A C I Ó N DE LOS REQUERIMIENTOS
A medida que se crea cada elemento del modelo de requerimientos, se estudia para detectar
inconsistencias, omisiones y ambigüedades. Los participantes asignan prioridades a los reque-
rimientos representados por el modelo y se agrupan en paquetes de requerimientos que se
implementarán como incrementos del software. La revisión del modelo de requerimientos
aborda las preguntas siguientes:
• ¿Es coherente cada requerimiento con los objetivos generales del sistema o producto?
? Cuando se revisan los
requerimientos, ¿qué • ¿Se han especificado todos los requerimientos en el nivel apropiado de abstracción? Es
preguntas deben
decir, ¿algunos de ellos tienen un nivel de detalle técnico que resulta inapropiado en
plantearse?
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 indi-
vidual y específica) clara para cada requerimiento?
• ¿Hay requerimientos en conflicto con otros?
www.FreeLibros.me
05Pressman(101-125).indd 122 21/1/10 11:00:25

• ¿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?
Éstas y otras preguntas deben plantearse y responderse para garantizar que el modelo de reque-
rimientos es una reflexión correcta sobre las necesidades del participante y que provee un fun-
damento sólido para el diseño.
5. 8 RESUMEN
Las tareas de la ingeniería de requerimientos se realizan para establecer un fundamento sólido
para el diseño y la construcción. La ingeniería de requerimientos ocurre durante las actividades
de comunicación y modelado que se hayan definido para el proceso general del software. Los
miembros del equipo de software llevan a cabo siete funciones de ingeniería de requerimientos:
concepción, indagación, elaboración, negociación, especificación, validación y administración.
En la concepción del proyecto, los participantes establecen los requerimientos básicos del
problema, definen las restricciones generales del proyecto, así como las características y fun-
ciones principales que debe presentar el sistema para cumplir sus objetivos. Esta información
se mejora y amplía durante la indagación, actividad en la que se recaban los requerimientos y
que hace uso de reuniones que lo facilitan, DFC y el desarrollo de escenarios de uso.
La elaboración amplía aún más los requerimientos en un modelo: una colección de elemen-
tos basados en escenarios, clases y comportamiento, y orientados al flujo. El modelo hace refe-
rencia a patrones de análisis: soluciones para problemas de análisis que se ha observado que
son recurrentes en diferentes aplicaciones.
Conforme se identifican los requerimientos y se crea su modelo, el equipo de software y otros
participantes negocian la prioridad, la disponibilidad y el costo relativo de cada requerimiento.
Además, se valida cada requerimiento y su modelo como un todo comparado con las necesida-
des del cliente a fin de garantizar que va a construirse el sistema correcto.
www.FreeLibros.me
05Pressman(101-125).indd 123 21/1/10 11:00:26

Comprension de Los Requerimientos CAP 5

Cargado por

Copyright:

Formatos disponibles

Comprension de Los Requerimientos CAP 5

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Comprension de Los Requerimientos CAP 5

Cargado por

Copyright:

Formatos disponibles

CAPÍTULO

05Pressman(101-125).indd 101 21/1/10 11:00:18

El diseño y construcción de software de computadora es difícil, creativo y sencillamente diver-

05Pressman(101-125).indd 102 21/1/10 11:00:19

? ¿Por qué es difícil llegar

• Problemas de entendimiento. Los clientes o usuarios no están completamente

• Problemas de volatilidad. Los requerimientos cambian con el tiempo.

Elaboración. La información obtenida del cliente durante la concepción e indagación se ex-

2 Si va a desarrollarse un sistema basado en computadora, los análisis comienzan en el contexto de un proceso

05Pressman(101-125).indd 103 21/1/10 11:00:19

o usuarios propongan requerimientos conflictivos con el argumento de que su versión es “esen-

Especificación. En el contexto de los sistemas basados en computadora (y software), el tér-

05Pressman(101-125).indd 104 21/1/10 11:00:20

Administración de los requerimientos. Los requerimientos para sistemas basados en

05Pressman(101-125).indd 105 21/1/10 11:00:20

5. 2 ESTABLECER LAS BASES

05Pressman(101-125).indd 106 21/1/10 11:00:20

5.2.2 Reconocer los múltiples puntos de vista

5.2.3 Trabajar hacia la colaboración

05Pressman(101-125).indd 107 21/1/10 11:00:21

5.2.4 Hacer las primeras preguntas

• ¿Quién está detrás de la solicitud de este trabajo?

5. 3 INDAGACIÓN DE LOS REQUERIMIENTOS

La indagación de los requerimientos (actividad también llamada recabación de los requerimien-

9 En ocasiones se denomina a este enfoque técnica facilitada de especificación de la aplicación (TFEA).

05Pressman(101-125).indd 108 21/1/10 11:00:21

5.3.1 Recabación de los requerimientos en forma colaborativa

• Tanto ingenieros de software como otros participantes dirigen o intervienen en las

• Un “facilitador” (cliente, desarrollador o participante externo) controla la reunión.

La meta es identificar el problema, proponer elementos de la solución, negociar distintos

La función de seguridad del hogar protegería, o reconocería, varias “situaciones” indeseables,

05Pressman(101-125).indd 109 21/1/10 11:00:21

05Pressman(101-125).indd 110 21/1/10 11:00:22

5.3.2 Despliegue de la función de calidad

Requerimientos normales. Objetivos y metas que se establecen para un producto o sis-

05Pressman(101-125).indd 111 21/1/10 11:00:22

5.3.3 Escenarios de uso

5.3.4 Indagación de los productos del trabajo

05Pressman(101-125).indd 112 21/1/10 11:00:22

• Un enunciado de la necesidad y su factibilidad.

• Una descripción del ambiente técnico del sistema.

• Cualesquiera prototipos desarrollados para definir requerimientos.

5. 4 DESARROLLO DE CASOS DE USO

05Pressman(101-125).indd 113 21/1/10 11:00:23

• ¿Quién es el actor principal y quién(es) el(los) secundario(s)?

• Introduce una clave que permita todas las demás interacciones.

05Pressman(101-125).indd 114 21/1/10 11:00:23

Actor principal: Propietario.

Precondiciones: El sistema se ha programado para recibir una clave y reconocer distintos

1. Propietario: observa el panel de control

2. Propietario: introduce una clave

3. Propietario: selecciona “permanecer” o “fuera”

3. La clave no es reconocida: debe contactarse el subsistema de vigilancia y respuesta para reprogra-

05Pressman(101-125).indd 115 21/1/10 11:00:23

Prioridad: Esencial, debe implementarse

Cuándo estará disponible: En el primer incremento

Frecuencia de uso: Muchas veces por día

Canal para el actor: A través de la interfaz del panel de control

Actores secundarios: Técnico de apoyo, sensores