Traducido del inglés al español - www.onlinedoctranslator.

com

PARTE I

Software
requisitos: qué,
porque y quien

CAPÍTULO 1 El requisito esencial del software. . . . . . . . . . . . . .3

CAPITULO 2 Requisitos del cliente

perspectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

CAPÍTULO 3 Buenas prácticas para requisitos

ingeniería. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

CAPÍTULO 4 El analista de negocios. . . . . . . . . . . . . . . . . . . . . . . . . .61

1
CAPÍTULO 1

El requisito esencial del software

“¿Hola, Phil? Esta es María en Recursos Humanos. Tenemos un problema con el sistema de personal que nos
programó. Una empleada acaba de cambiar su nombre a Sparkle Starlight y no podemos hacer que el sistema
acepte el cambio de nombre. ¿Puede usted ayudar?"

"¿Se casó con un tipo llamado Starlight?"

“No, ella no se casó, solo cambió su nombre”, respondió María. "Ese es el problema. Parece que
podemos cambiar un nombre solo si cambia el estado civil de alguien”.

“Bueno, sí, nunca pensé que alguien podría simplemente cambiar su nombre. No recuerdo que me hablaras
de esta posibilidad cuando hablamos del sistema”, dijo Phil.

“Supuse que sabías que las personas podían cambiar su nombre legalmente cuando quisieran”, respondió María.
“Tenemos que arreglar esto para el viernes o Sparkle no podrá cobrar su cheque de pago. ¿Puedes arreglar el error para
entonces?

"¡No es un error!" Phil replicó. “Nunca supe que necesitabas esta capacidad. Estoy ocupado con el nuevo
sistema de evaluación del desempeño. Probablemente pueda arreglarlo para fin de mes, pero no para el
viernes. Lo lamento. La próxima vez, dime estas cosas antes y escríbelas”.

"¿Qué se supone que debo decirle a Sparkle?" exigió María. “Se enfadará si no puede cobrar su cheque”.

“Oye, María, no es mi culpa”, protestó Phil. “Si me hubieras dicho en primer lugar que tenías que poder
cambiar el nombre de alguien en cualquier momento, esto no habría sucedido. No puedes culparme por no leer
tu mente.

Enojada y resignada, María espetó: “Sí, bueno, este es el tipo de cosas que me hacen odiar las
computadoras. Llámame tan pronto como lo arregles, ¿quieres?

Si alguna vez ha estado del lado del cliente en una conversación como esta, sabe lo frustrante que es cuando un
sistema de software no le permite realizar una tarea esencial. Odias estar a merced de un desarrollador quepodría
llegue a su solicitud de cambio crítico eventualmente. Por otro lado, los desarrolladores se sienten frustrados al
enterarse de la funcionalidad que un usuario esperaba solo después de haber implementado el sistema. También es
molesto para un desarrollador que su proyecto actual sea interrumpido por una solicitud para modificar un sistema
que hace precisamente lo que se le dijo que debería hacer en primer lugar.

3
 Muchos problemas en el mundo del software surgen de deficiencias en la forma en que las personas aprenden,
documentan, acuerdan y modifican los requisitos del producto. Al igual que con Phil y Maria, las áreas problemáticas
comunes son la recopilación de información informal, la funcionalidad implícita, las suposiciones mal comunicadas, los
requisitos mal especificados y un proceso de cambio casual. Varios estudios sugieren que los errores introducidos
durante las actividades de requisitos representan del 40 al 50 por ciento de todos los defectos encontrados en un
producto de software (Davis 2005). La entrada inadecuada del usuario y las deficiencias en la especificación y gestión de
los requisitos del cliente son los principales contribuyentes a los proyectos fallidos. A pesar de esta evidencia, muchas
organizaciones aún practican métodos de requisitos ineficaces.

En ninguna parte más que en los requisitos se cruzan los intereses de todos los interesados en un proyecto. (Consulte
el Capítulo 2, "Requisitos desde la perspectiva del cliente", para obtener más información sobre las partes interesadas).
Estas partes interesadas incluyen clientes, usuarios, analistas comerciales, desarrolladores y muchos otros. Bien manejada,
esta intersección puede conducir a clientes satisfechos y desarrolladores satisfechos. Si se maneja mal, es la fuente de
malentendidos y fricciones que socavan la calidad y el valor comercial del producto. Debido a que los requisitos son la base
tanto para el desarrollo de software como para las actividades de gestión de proyectos, todas las partes interesadas deben
comprometerse a aplicar prácticas de requisitos que se sabe que producen productos de calidad superior.

¡Pero desarrollar y administrar requisitos es difícil! No hay atajos simples ni soluciones mágicas. En el lado positivo,
tantas organizaciones luchan con los mismos problemas que puede buscar técnicas en común que se apliquen a muchas
situaciones diferentes. Este libro describe docenas de tales prácticas. Las prácticas se presentan como si estuviera
construyendo un sistema completamente nuevo. Sin embargo, la mayoría de ellos también se aplican a proyectos de
mejora, reemplazo y reingeniería (consulte el Capítulo 21, “Proyectos de mejora y reemplazo”) y a proyectos que
incorporan soluciones empaquetadas comerciales listas para usar (COTS) (consulte el Capítulo 22, “Proyectos
empaquetados”). proyectos de solución”). Los equipos de proyecto que construyen productos de manera incremental
siguiendo un proceso de desarrollo ágil también deben comprender los requisitos que se incluyen en cada incremento
(consulte el Capítulo 20, "Proyectos ágiles").

Este capítulo le ayudará a:

-- Comprender algunos términos clave utilizados en el dominio de requisitos de software.

-- Distinguirproductorequisitos deproyectorequisitos

-- Distinguir requisitosdesarrollode los requisitosgestión.

-- Esté alerta a varios problemas relacionados con los requisitos que pueden surgir.

ImportanteUsamos los términos "sistema", "producto", "aplicación" y "solución" indistintamente

en este libro para referirnos a cualquier tipo de software o elemento que contenga software que
cree, ya sea para uso corporativo interno, para venta comercial, o por contrato.

4 PARTE IRequisitos de software: qué, por qué y quién

 Tomando el pulso a sus requerimientos

Para una revisión rápida de las prácticas de requisitos actuales en su organización, considere cuántas de
las siguientes condiciones se aplican a su proyecto más reciente. Si más de tres o cuatro de estos
elementos describen su experiencia, este libro es para usted:

-- Los objetivos comerciales, la visión y el alcance del proyecto nunca se definieron claramente.

-- Los clientes estaban demasiado ocupados para dedicar tiempo a trabajar con analistas o desarrolladores en

los requisitos.

-- Su equipo no pudo interactuar directamente con los usuarios representativos para comprender sus necesidades.

-- Los clientes afirmaron que todos los requisitos eran críticos, por lo que no los priorizaron.

-- Los desarrolladores encontraron ambigüedades e información faltante al codificar, por lo que tuvieron que
adivinar.

-- Las comunicaciones entre los desarrolladores y las partes interesadas se centraron en las funciones o las pantallas
de la interfaz de usuario, no en lo que los usuarios necesitaban lograr con el software.

-- Sus clientes nunca aprobaron los requisitos.

-- Sus clientes aprobaron los requisitos para una versión o iteración y luego los cambiaron
continuamente.

-- El alcance del proyecto aumentó a medida que se aceptaron los cambios en los requisitos, pero el cronograma se
retrasó porque no se proporcionaron recursos adicionales y no se eliminó ninguna funcionalidad.

-- Los cambios de requisitos solicitados se perdieron; nadie sabía el estado de una solicitud de cambio en
particular.

-- Los clientes solicitaron cierta funcionalidad y los desarrolladores la construyeron, pero nadie la usa nunca.

-- Al final del proyecto, se cumplieron las especificaciones pero no el cliente ni los objetivos
comerciales.

Requisitos de software definidos

Cuando un grupo de personas comienza a discutir los requisitos, a menudo comienzan con un problema de terminología.
Diferentes observadores pueden describir una declaración única como un requisito del usuario, un requisito de software,
un requisito comercial, un requisito funcional, un requisito del sistema, un requisito del producto, un requisito del
proyecto, una historia de usuario, una característica o una restricción. Los nombres que usan para varios entregables de
requisitos también varían. La definición de requisitos de un cliente puede sonar como un concepto de producto de alto
nivel para el desarrollador. La noción de requisitos del desarrollador puede sonar como un diseño de interfaz de usuario
detallado para el usuario. Esta diversidad de comprensión conduce a la confusión y la frustración.

CAPÍTULO 1El requisito esencial del software 5

 Algunas interpretaciones de "requisito"
Muchas décadas después de la invención de la programación de computadoras, los profesionales del software todavía tienen
debates furiosos sobre qué es exactamente un "requisito". En lugar de prolongar esos debates, en este libro simplemente
presentamos algunas definiciones que hemos encontrado útiles.

El consultor Brian Lawrence sugiere que unrequisitoes “cualquier cosa que impulsa las elecciones de
diseño” (Lawrence 1997). Esta no es una mala definición coloquial, porque muchos tipos de información encajan en esta
categoría. Y, después de todo, el objetivo principal de desarrollar requisitos es tomar decisiones de diseño apropiadas
que satisfagan las necesidades del cliente al final. Otra definición es que un requisito es una propiedad que debe tener
un producto para proporcionar valor a una parte interesada. Tampoco está mal, pero no es muy preciso. Sin embargo,
nuestra definición favorita proviene de Ian Sommerville y Pete Sawyer (1997):

Los requisitos son una especificación de lo que debe implementarse. Son descripciones de
cómo debe comportarse el sistema, o de una propiedad o atributo del sistema. Pueden ser
una restricción en el proceso de desarrollo del sistema.

Esta definición reconoce los diversos tipos de información que colectivamente se conocen como "los
requisitos". Los requisitos abarcan tanto la visión del usuario del comportamiento del sistema externo como la
visión del desarrollador de algunas características internas. Incluyen tanto el comportamiento del sistema en
condiciones específicas como aquellas propiedades que hacen que el sistema sea adecuado, y tal vez incluso
agradable, para que lo usen los operadores previstos.

TrampaNo asuma que todas las partes interesadas de su proyecto comparten una noción común de lo que son
los requisitos. Establezca definiciones desde el principio para que todos hablen de las mismas cosas.

El diccionario puro “requisito”

La gente de software no usa "requisito" en el mismo sentido que la definición de diccionario de la
palabra: algo exigido u obligatorio, una necesidad o una necesidad. Las personas a veces se
preguntan si necesitan priorizar los requisitos, porque tal vez nunca se implemente un requisito de
baja prioridad. Si no es realmente necesario, entonces no es un requisito, afirman. Tal vez, pero
entonces, ¿cómo llamarías a esa información? Si difiere un requisito del proyecto de hoy a una
versión futura no especificada, ¿aún se considera un requisito? Claro que lo es.

Los requisitos de software incluyen una dimensión de tiempo. Podrían estar en tiempo presente, describiendo
las capacidades del sistema actual. O podrían ser para el futuro a corto plazo (prioridad alta), mediano plazo
(prioridad media) o hipotético (prioridad baja). Incluso podrían estar en tiempo pasado, refiriéndose a necesidades
que una vez fueron especificadas y luego descartadas. No pierda el tiempo debatiendo si algo es o no un requisito,
incluso si sabe que es posible que nunca lo implemente por alguna buena razón comercial. Es.

6 PARTE IRequisitos de software: qué, por qué y quién

Niveles y tipos de requisitos
Debido a que hay tantos tipos diferentes de información de requisitos, necesitamos un conjunto consistente de adjetivos
para modificar el término sobrecargado "requisito". Esta sección presenta definiciones que usaremos para algunos
términos comúnmente encontrados en el dominio de requisitos (ver Tabla 1-1).

TABLA 1-1Algunos tipos de información de requisitos

Término Definición

Requisito de negocio Un objetivo comercial de alto nivel de la organización que crea un producto o de un
cliente que lo adquiere.

De reglas de negocio Una política, directriz, estándar o regulación que define o restringe algún aspecto del
negocio. No es un requisito de software en sí mismo, sino el origen de varios tipos de
requisitos de software.

Restricción Una restricción que se impone a las opciones disponibles para el desarrollador para el
diseño y construcción de un producto.

Requisito de interfaz externa Una descripción de una conexión entre un sistema de software y un usuario, otro sistema
de software o un dispositivo de hardware.

Característica Una o más capacidades del sistema relacionadas lógicamente que proporcionan valor a un usuario y se
describen mediante un conjunto de requisitos funcionales.

Requerimiento funcional Una descripción de un comportamiento que exhibirá un sistema bajo condiciones específicas.

Requisito no funcional Una descripción de una propiedad o característica que un sistema debe exhibir o una
restricción que debe respetar.

Atributo de calidad Un tipo de requisito no funcional que describe un servicio o una característica de
desempeño de un producto.

Requisitos del sistema Un requisito de nivel superior para un producto que contiene varios subsistemas, que
pueden ser todo software o software y hardware.

Requisitos de usuario Una meta o tarea que clases específicas de usuarios deben poder realizar con un sistema o un
atributo de producto deseado.

Los requisitos de software incluyen tres niveles distintos: requisitos comerciales, requisitos del usuario y
requisitos funcionales. Además, cada sistema tiene una variedad de requisitos no funcionales. El modelo de la
Figura 1-1 ilustra una manera de pensar acerca de estos diversos tipos de requisitos. Como dijo el estadístico
George EP Box: “Esencialmente, todos los modelos están equivocados, pero algunos son útiles” (Box y Draper
1987). Eso es ciertamente cierto en la Figura 1-1. Este modelo no lo incluye todo, pero proporciona un esquema
útil para organizar el conocimiento de los requisitos que encontrará.

Los óvalos en la Figura 1-1 representan tipos de información de requisitos y los rectángulos indican documentos en
los que almacenar esa información. Las flechas continuas indican que un determinado tipo de información
normalmente se almacena en el documento indicado. (Las reglas comerciales y los requisitos del sistema se almacenan
por separado de los requisitos de software, como en un catálogo de reglas comerciales o una especificación de
requisitos del sistema, respectivamente). Las flechas punteadas indican que un tipo de información es el origen o
influye en otro tipo de requisito. Los requisitos de datos no se muestran explícitamente en este diagrama. Las funciones
manipulan los datos, por lo que los requisitos de datos pueden aparecer en los tres niveles. El Capítulo 7, “Obtención de
requisitos”, contiene muchos ejemplos de estos diferentes tipos de información de requisitos.

CAPÍTULO 1El requisito esencial del software 7

 FIGURA 1-1Relaciones entre varios tipos de información de requisitos. Las flechas continuas significan "están almacenados en"; las flechas
punteadas significan “son el origen de” o “influencia”.

ImportanteAunque nos referiremos a los requisitos como "documentos" a lo largo de este libro, como en la
Figura 1-1, no es necesario que sean documentos tradicionales en papel o electrónicos. En su lugar, piense en
ellos simplemente como contenedores en los que almacenar el conocimiento de los requisitos. Dicho contenedor
podría ser un documento tradicional, o podría ser una hoja de cálculo, un conjunto de diagramas, una base de
datos, una herramienta de gestión de requisitos o alguna combinación de estos. Para mayor comodidad,
utilizaremos el término "documento" para referirnos a dicho contenedor. Proporcionaremos plantillas que
identifiquen los tipos de información que se deben considerar almacenar en cada uno de esos grupos,
independientemente de la forma en que la almacene. Cómo llame a cada entregable es menos importante que
hacer que su organización acuerde sus nombres, qué tipo de información va en cada uno, y cómo se organiza esa
información.

Requisitos comercialesdescribirpor quéla organización está implementando el sistema: los beneficios comerciales que
la organización espera lograr. El foco está en los objetivos comerciales de la organización o del cliente que solicita el
sistema. Suponga que una aerolínea quiere reducir los costos de personal de mostrador del aeropuerto en un 25 por
ciento. Este objetivo podría llevar a la idea de construir un quiosco que los pasajeros puedan usar para registrarse para
sus vuelos en el aeropuerto. Los requisitos comerciales generalmente provienen del patrocinador de financiamiento de un
proyecto, el cliente adquirente, el gerente de los usuarios reales, el departamento de marketing o un visionario del
producto. Nos gusta registrar los requisitos comerciales en undocumento de visión y alcance.Otros documentos de
orientación estratégica que a veces se usan para este propósito incluyen un acta de constitución del proyecto, un caso de
negocios y un documento de requisitos de mercado (o marketing). La especificación de los requisitos comerciales es el
tema del Capítulo 5, “Establecimiento de los requisitos comerciales”. Para los fines de este libro, asumimos que ya se ha
identificado la necesidad comercial o la oportunidad de mercado.

8 PARTE IRequisitos de software: qué, por qué y quién

 Requisitos de usuariodescribir objetivos o tareas que los usuarios deben poder realizar con el producto que proporcionará valor
a alguien. El dominio de los requisitos del usuario también incluye descripciones de atributos o características del producto que son

importantes para la satisfacción del usuario. Las formas de representar los requisitos de los usuarios incluyen casos de uso (Kulak y

Guiney 2004), historias de usuarios (Cohn 2004) y tablas de respuesta a eventos. Idealmente, los representantes de los usuarios

reales proporcionarán esta información. Los requisitos del usuario describenquéel usuario podrá hacer con el sistema. Un ejemplo

de un caso de uso es "Registrarse para un vuelo" utilizando el sitio web de una aerolínea o un quiosco en el aeropuerto. Escrito

como una historia de usuario, el mismo requisito de usuario podría decir: "Como pasajero, quiero registrarme para un vuelo para

poder abordar mi avión". Es importante recordar que la mayoría de los proyectos tienen varias clases de usuarios, así como otras

partes interesadas cuyas necesidades también se deben obtener. El Capítulo 8, "Comprensión de los requisitos del usuario", aborda

este nivel del modelo. Algunas personas utilizan el término más amplio "requisitos de las partes interesadas" para reconocer la

realidad de que varias partes interesadas, además de los usuarios directos, proporcionarán los requisitos. Eso es ciertamente

cierto, pero enfocamos la atención en este nivel en comprender lo que los usuarios reales necesitan lograr con la ayuda del

producto.

Requerimientos funcionalesespecificar los comportamientos que exhibirá el producto bajo condiciones

específicas. Ellos describenquélos desarrolladores deben implementar para permitir que los usuarios realicen sus
tareas (requisitos del usuario), satisfaciendo así los requisitos comerciales. Esta alineación entre los tres niveles de
requisitos es esencial para el éxito del proyecto. Los requisitos funcionales a menudo se escriben en forma de las
declaraciones tradicionales "deberá": "El Pasajero podrá imprimir tarjetas de embarque para todos los segmentos
de vuelo para los que se haya registrado" o "Si el perfil del Pasajero no indica una preferencia de asiento, el
sistema de reservas asignará un asiento.”

El analista de negocios (BA)1documenta los requisitos funcionales en unEspecificación de Requerimientos de Software(SRS), que

describe tan completamente como sea necesario el comportamiento esperado del sistema de software. El SRS se utiliza en el

desarrollo, las pruebas, el aseguramiento de la calidad, la gestión de proyectos y funciones de proyectos relacionadas. La gente
llama a este entregable por muchos nombres diferentes, incluido el documento de requisitos comerciales, la especificación

funcional, el documento de requisitos y otros. Un SRS podría ser un informe generado a partir de información almacenada en una

herramienta de gestión de requisitos. Debido a que es un término estándar de la industria, usaremos “SRS” de manera consistente a
lo largo de este libro (ISO/IEC/IEEE 2011). Consulte el Capítulo 10, “Documentación de los requisitos”, para obtener más información

sobre el SRS.

Requisitos del sistemadescribir los requisitos para un producto que se compone de múltiples componentes o
subsistemas (ISO/IEC/IEEE 2011). Un “sistema” en este sentido no es cualquier sistema de información. Un sistema puede
ser todo software o puede incluir subsistemas de software y hardware. Las personas y los procesos también forman
parte de un sistema, por lo que ciertas funciones del sistema pueden asignarse a los seres humanos. Algunas personas
usan el término "requisitos del sistema" para referirse a los requisitos detallados para un sistema de software, pero no es
así como usamos el término en este libro.

Un buen ejemplo de un "sistema" es la estación de trabajo del cajero en un supermercado. Hay un escáner de código
de barras integrado con una báscula, así como un escáner de código de barras de mano. El cajero tiene un teclado, una
pantalla y una caja registradora. Verá un lector de tarjetas y un teclado PIN para su tarjeta de fidelización y tarjeta de
crédito o débito, y quizás un dispensador de cambio. Es posible que vea hasta tres impresoras por su compra

1"Analista de negocios" se refiere al rol del proyecto que tiene la responsabilidad principal de liderar las actividades relacionadas con los requisitos en un proyecto. El rol
de BA también tiene muchos otros nombres. Consulte el Capítulo 4, “El analista de negocios”, para obtener más información sobre el rol de analista de negocios.

CAPÍTULO 1El requisito esencial del software 9

 recibo, recibo de tarjeta de crédito y cupones que no le interesan. Todos estos dispositivos de hardware
interactúan bajo el control del software. Los requisitos para el sistema o producto como un todo, entonces, llevan
al analista de negocios a derivar funcionalidades específicas que deben asignarse a uno u otro de esos
subsistemas componentes, además de exigir una comprensión de las interfaces entre ellos.

Reglas del negocioincluyen políticas corporativas, regulaciones gubernamentales, estándares de la industria y

algoritmos computacionales. Como verá en el Capítulo 9, "Siguiendo las reglas", las reglas comerciales no son en sí
mismas requisitos de software porque tienen una existencia más allá de los límites de cualquier aplicación de software
específica. Sin embargo, a menudo dictan que el sistema debe contener funcionalidad para cumplir con las reglas
pertinentes. A veces, como sucede con las políticas de seguridad corporativas, las reglas comerciales son el origen de
atributos de calidad específicos que luego se implementan en la funcionalidad. Por lo tanto, puede rastrear la génesis de
ciertos requisitos funcionales hasta una regla comercial particular.

Además de los requisitos funcionales, el SRS contiene una variedad de requisitos no funcionales.Atributos de
calidadtambién se conocen como factores de calidad, requisitos de calidad de servicio, restricciones y las “-
ilidades”. Describen las características del producto en varias dimensiones que son importantes para los usuarios
o para los desarrolladores y mantenedores, como el rendimiento, la seguridad, la disponibilidad y la portabilidad.
Otras clases de requisitos no funcionales describeninterfaces externasentre el sistema y el mundo exterior. Estos
incluyen conexiones a otros sistemas de software, componentes de hardware y usuarios, así como interfaces de
comunicación. Diseño e implementaciónrestricciones imponer restricciones a las opciones disponibles para el
desarrollador durante la construcción del producto.

Si no son funcionales, entonces, ¿qué son?

Durante muchos años, los requisitos para un producto de software se han clasificado en términos
generales como funcionales o no funcionales. Los requisitos funcionales son evidentes: describen el
comportamiento observable del sistema bajo diversas condiciones. Sin embargo, a muchas personas no les
gusta el término "no funcional". Ese adjetivo dice cuales son los requisitosno, pero no dice lo queson.
Simpatizamos con el problema, pero nos falta una solución perfecta.

Los requisitos distintos a los funcionales pueden especificar que noquéel sistema lo hace, sino más bien Que
tan bienhace esas cosas. Podrían describir características o propiedades importantes del sistema. Estos incluyen
la disponibilidad, usabilidad, seguridad, rendimiento y muchas otras características del sistema, como se aborda
en el Capítulo 14, “Más allá de la funcionalidad”. Algunas personas consideran que los requisitos no funcionales
son sinónimo de atributos de calidad, pero eso es demasiado restrictivo. Por ejemplo, las restricciones de diseño
e implementación también son requisitos no funcionales, al igual que los requisitos de interfaz externa.

Aún otros requisitos no funcionales abordan el entorno en el que opera el sistema, como la plataforma, la
portabilidad, la compatibilidad y las restricciones. Muchos productos también se ven afectados por los requisitos de
cumplimiento, reglamentarios y de certificación. Podría haber requisitos de localización para productos que deben
tener en cuenta las culturas, los idiomas, las leyes, las monedas, la terminología, la ortografía y otras características
de los usuarios. Si bien tales requisitos se especifican en términos no funcionales, el analista de negocios
normalmente derivará numerosas partes de funcionalidad para garantizar que el sistema posea todos los
comportamientos y propiedades deseados.

10 PARTE IRequisitos de software: qué, por qué y quién

 En este libro, nos apegamos al término “requisitos no funcionales”, a pesar de sus limitaciones, por la falta de
una alternativa adecuadamente inclusiva. En lugar de preocuparse precisamente por cómo llama a este tipo de
información, simplemente asegúrese de que formen parte de sus actividades de obtención y análisis de requisitos.
Puede entregar un producto que tenga toda la funcionalidad deseada pero que los usuarios odien porque no
cumple con sus expectativas de calidad (a menudo no declaradas).

Acaracterísticaconsiste en una o más capacidades del sistema relacionadas lógicamente que proporcionan valor a un usuario

y se describen mediante un conjunto de requisitos funcionales. La lista de características deseadas del producto de un cliente no

es equivalente a una descripción de las necesidades relacionadas con la tarea del usuario. Los marcadores del navegador web, los

correctores ortográficos, la capacidad de definir un programa de entrenamiento personalizado para un equipo de ejercicio y la

actualización automática de firmas de virus en un producto antimalware son ejemplos de características. Una característica puede

abarcar múltiples requisitos de usuario, cada uno de los cuales implica que se deben implementar ciertos requisitos funcionales

para permitir que el usuario realice la tarea descrita por cada requisito de usuario. La Figura 1-2 ilustra unárbol de características,

un modelo de análisis que muestra cómo una característica puede descomponerse jerárquicamente en un conjunto de

características más pequeñas, que se relacionan con los requisitos específicos del usuario y conducen a la especificación de

conjuntos de requisitos funcionales (Beatty y Chen 2012).

FIGURA 1-2Relaciones entre las características, los requisitos del usuario y los requisitos funcionales.

CAPÍTULO 1El requisito esencial del software 11

 Para ilustrar algunos de estos diversos tipos de requisitos, considere un proyecto para desarrollar la próxima versión
de un programa editor de texto. Un requisito comercial podría ser "Aumentar las ventas fuera de EE. UU. en

25 por ciento en 6 meses”. Marketing se da cuenta de que los productos de la competencia solo tienen correctores
ortográficos en inglés, por lo que deciden que la nueva versión incluirá una función de corrector ortográfico en varios
idiomas. Los requisitos de usuario correspondientes pueden incluir tareas como "Seleccionar idioma para el corrector
ortográfico", "Buscar errores ortográficos" y "Agregar una palabra a un diccionario". El corrector ortográfico tiene muchos
requisitos funcionales individuales, que se ocupan de operaciones como resaltar palabras mal escritas, autocorrección,
mostrar reemplazos sugeridos y reemplazar globalmente palabras mal escritas con palabras corregidas. Los requisitos de
usabilidad especifican cómo se debe localizar el software para usarlo con idiomas y conjuntos de caracteres específicos.

Trabajando con los tres niveles

La figura 1-3 ilustra cómo varias partes interesadas pueden participar en la obtención de los tres niveles de requisitos.
Diferentes organizaciones usan una variedad de nombres para los roles involucrados en estas actividades; Piense en
quién realiza estas actividades en su organización. Los nombres de los roles a menudo difieren dependiendo de si la
organización de desarrollo es una entidad corporativa interna o una empresa que crea software para uso comercial.

FIGURA 1-3Un ejemplo de cómo las diferentes partes interesadas participan en el desarrollo de requisitos.

12 PARTE IRequisitos de software: qué, por qué y quién

 Con base en una necesidad comercial identificada, una necesidad del mercado o un concepto de producto nuevo e
interesante, los gerentes o el departamento de marketing definen los requisitos comerciales para el software que ayudarán
a su empresa a operar de manera más eficiente (para sistemas de información) o competir con éxito en el mercado (para
productos comerciales). ). En el entorno corporativo, un analista comercial suele trabajar con los representantes de los
usuarios para identificar los requisitos de los usuarios. Las empresas que desarrollan productos comerciales a menudo
identifican a un gerente de producto para determinar qué características incluir en el nuevo producto. Cada requisito y
característica del usuario debe alinearse con el cumplimiento de los requisitos comerciales. A partir de los requisitos del
usuario, el BA o gerente de producto deriva la funcionalidad que permitirá a los usuarios lograr sus objetivos. Los
desarrolladores utilizan los requisitos funcionales y no funcionales para diseñar soluciones que implementen la
funcionalidad necesaria, dentro de los límites que imponen las restricciones. Los evaluadores determinan cómo verificar si
los requisitos se implementaron correctamente.

Es importante reconocer el valor de registrar la información de requisitos vitales en una forma

que se pueda compartir, en lugar de tratarla como una tradición oral alrededor de la fogata del
proyecto. Una vez estuve en un proyecto que había experimentado un elenco rotativo de equipos de
desarrollo. El cliente principal estaba harto de que cada nuevo equipo viniera y dijera: "Tenemos que
hablar sobre sus requisitos". Su reacción a nuestra solicitud fue: “Ya les di a sus predecesores mis
requisitos. ¡Ahora constrúyeme un sistema!” Desafortunadamente, nadie nunca había documentado
ningún requisito, por lo que cada equipo nuevo tenía que empezar desde cero. Proclamar que "tiene
los requisitos" es una ilusión si todo lo que realmente tiene es una pila de mensajes de correo
electrónico y de correo de voz, notas adhesivas, actas de reuniones y conversaciones vagamente
recordadas en los pasillos.

La figura 1-1, que se muestra anteriormente en este capítulo, identificó tres entregables de requisitos principales: un
documento de visión y alcance, un documento de requisitos del usuario y una especificación de requisitos de software. No
es necesario que cree necesariamente tres entregables de requisitos discretos en cada proyecto. A menudo tiene sentido
combinar parte de esta información, particularmente en proyectos pequeños. Sin embargo, reconozca que estos tres
entregables contienen información diferente, desarrollada en diferentes puntos del proyecto, posiblemente por
diferentes personas, con diferentes propósitos y audiencias objetivo.

El modelo de la Figura 1-1 mostraba un flujo simple de información de requisitos de arriba hacia abajo. En realidad,
debe esperar ciclos e iteraciones entre los requisitos comerciales, de usuario y funcionales. Cada vez que alguien propone
una nueva característica, un requisito de usuario o un poco de funcionalidad, el analista debe preguntar: "¿Está esto dentro
del alcance?" Si la respuesta es "sí", el requisito pertenece a la especificación. Si la respuesta es "no", no es así, al menos no
para el próximo lanzamiento o iteración. La tercera respuesta posible es "no, pero respalda los objetivos comerciales, así
debería ser". En ese caso, quienquiera que controle el alcance del proyecto (el patrocinador del proyecto, el administrador
del proyecto o el propietario del producto) debe decidir si aumenta el alcance del proyecto actual o de la iteración para
adaptarse al nuevo requisito. Esta es una decisión comercial que tiene implicaciones para el cronograma y el presupuesto
del proyecto y puede exigir compensaciones con otras capacidades. Un proceso de cambio efectivo que incluya análisis de
impacto garantiza que las personas adecuadas tomen decisiones comerciales informadas sobre qué cambios aceptar y que
se aborden los costos asociados en tiempo, recursos o compensaciones de funciones.

CAPÍTULO 1El requisito esencial del software 13

 Requisitos del producto frente al proyecto
Hasta ahora hemos discutido los requisitos que describen las propiedades de un sistema de software que se va a
construir. Llamemos a esosproductorequisitos Los proyectos ciertamente tienen otras expectativas y resultados
que no son parte del software que implementa el equipo, pero que son necesarios para completar con éxito el
proyecto como un todo. Estos sonproyectorequisitos pero noproductorequisitos Un SRS contiene los requisitos del
producto, pero no debe incluir detalles de diseño o implementación (aparte de las restricciones conocidas), planes
de proyecto, planes de prueba o información similar. Separe dichos elementos para que las actividades de
desarrollo de requisitos puedan centrarse en comprender lo que el equipo pretende construir. Los requisitos del
proyecto incluyen:

-- Recursos físicos que necesita el equipo de desarrollo, como estaciones de trabajo, dispositivos de hardware

especiales, laboratorios de prueba, herramientas y equipos de prueba, salas de equipos y equipos de

videoconferencia.

-- Necesidades de formación del personal.

-- Documentación del usuario, incluidos materiales de formación, tutoriales, manuales de referencia y notas de la
versión.

-- Documentación de soporte, como recursos de la mesa de ayuda e información de servicio y mantenimiento de

campo para dispositivos de hardware.

-- Cambios de infraestructura necesarios en el entorno operativo.

-- Requisitos y procedimientos para liberar el producto, instalarlo en el entorno

operativo, configurarlo y probar la instalación.

-- Requisitos y procedimientos para la transición de un sistema antiguo a uno nuevo, como los requisitos de
migración y conversión de datos, configuración de seguridad, transición de producción y capacitación para cerrar
las brechas de habilidades; estos a veces se llamanrequisitos de transición(IIBA 2009).

-- Certificación de productos y requisitos de cumplimiento.

-- Políticas revisadas, procesos, estructuras organizativas y documentos similares.

-- Abastecimiento, adquisición y concesión de licencias de software y componentes de hardware de terceros.

-- Requisitos de pruebas beta, fabricación, empaque, mercadeo y distribución.

-- Acuerdos de nivel de servicio al cliente.

-- Requisitos para obtener protección legal (patentes, marcas registradas o derechos de autor) para la
propiedad intelectual relacionada con el software.

Este libro no aborda más este tipo de requisitos del proyecto. Eso no significa que no sean importantes, solo
que están fuera del alcance de nuestro enfoque en el desarrollo y la gestión de requisitos de productos de
software. La identificación de estos requisitos del proyecto es una responsabilidad compartida del BA y el director
del proyecto. A menudo surgen al obtener los requisitos del producto. La información de los requisitos del
proyecto se almacena mejor en el plan para la dirección del proyecto, que debe detallar todas las actividades y
productos esperados del proyecto.

14 PARTE IRequisitos de software: qué, por qué y quién

 Particularmente para las aplicaciones comerciales, las personas a veces se refieren a una "solución" que abarca tanto
los requisitos del producto (que son principalmente responsabilidad del analista comercial) como los requisitos del
proyecto (que son principalmente responsabilidad del gerente del proyecto). Podrían usar el término "alcance de la
solución" para referirse a "todo lo que se debe hacer para completar el proyecto con éxito". En este libro, sin embargo,
nos estamos enfocando en los requisitos del producto, ya sea que su entrega final sea un producto de software comercial,
un dispositivo de hardware con software incorporado, un sistema de información corporativo, software gubernamental
contratado o cualquier otra cosa.

Desarrollo y gestión de requisitos.

La confusión sobre la terminología de los requisitos se extiende incluso a cómo llamar a toda la disciplina. Algunos
autores llaman a todo el dominioingeniería de requisitos(nuestra preferencia).Otros se refieren a todo como gestión de
requerimientos.Aún otros se refieren a estas actividades como un subconjunto del amplio dominio del análisis
empresarial.

Encontramos útil dividir la ingeniería de requisitos endesarrollo de requisitos(abordado en la Parte II

de este libro) ygestión de requerimientos(abordado en la Parte IV), como se muestra en la Figura 1-4.
Independientemente del ciclo de vida de desarrollo que siga su proyecto, ya sea en cascada, por fases,
iterativo, incremental, ágil o híbrido, estas son las cosas que debe hacer con respecto a los requisitos.
Según el ciclo de vida, realizará estas actividades en diferentes momentos del proyecto y con diversos
grados de profundidad o detalle.

FIGURA 1-4Subdisciplinas de la ingeniería de requisitos de software.

Desarrollo de requisitos
Como muestra la figura 1-4, subdividimos el desarrollo de requisitos ensonsacamiento,análisis,especificación, y
validación(Abran et al. 2004). Estas subdisciplinas abarcan todas las actividades relacionadas con la exploración,
evaluación, documentación y confirmación de los requisitos de un producto. Las siguientes son las acciones
esenciales en cada subdisciplina.

CAPÍTULO 1El requisito esencial del software 15

 Sonsacamiento

La elicitación abarca todas las actividades relacionadas con el descubrimiento de requisitos, como entrevistas, talleres,
análisis de documentos, creación de prototipos y otros. Las acciones clave son:

-- Identificar las clases de usuarios esperadas del producto y otras partes interesadas.

-- Comprender las tareas y objetivos de los usuarios y los objetivos comerciales con los que se alinean esas tareas.

-- Conocer el entorno en el que se utilizará el nuevo producto.

-- Trabajar con personas que representan a cada clase de usuario para comprender sus necesidades de
funcionalidad y sus expectativas de calidad.

¿Centrado en el uso o centrado en el producto?

La obtención de requisitos suele adoptar un enfoque centrado en el uso o centrado en el producto, aunque
también son posibles otras estrategias. La estrategia centrada en el uso enfatiza la comprensión y exploración de
los objetivos del usuario para derivar la funcionalidad necesaria del sistema. El enfoque centrado en el producto se
enfoca en definir las características que usted espera que conduzcan al éxito comercial o del mercado. Un riesgo
de las estrategias centradas en el producto es que podría implementar características que no se usan mucho,
incluso si parecían una buena idea en ese momento. Recomendamos comprender primero los objetivos
comerciales y los objetivos del usuario, y luego usar esa información para determinar las funciones y
características apropiadas del producto.

Análisis
Analizar los requisitos implica alcanzar una comprensión más rica y precisa de cada requisito y
representar conjuntos de requisitos de múltiples maneras. Las siguientes son las principales
actividades:

-- Analizar la información recibida de los usuarios para distinguir los objetivos de sus tareas de los requisitos
funcionales, las expectativas de calidad, las reglas comerciales, las soluciones sugeridas y otra información.

-- Descomponer los requisitos de alto nivel en un nivel apropiado de detalle

-- Derivación de requisitos funcionales a partir de otra información de requisitos

-- Comprender la importancia relativa de los atributos de calidad

-- Asignación de requisitos a los componentes de software definidos en la arquitectura del sistema

-- Negociación de prioridades de implementación

-- Identificar lagunas en los requisitos o requisitos innecesarios en relación con el alcance definido

dieciséis PARTE IRequisitos de software: qué, por qué y quién

Especificación
La especificación de requisitos implica representar y almacenar el conocimiento de los requisitos recopilados de
manera persistente y bien organizada. La actividad principal es:

-- Traducir las necesidades del usuario recopiladas en requisitos escritos y diagramas adecuados para su
comprensión, revisión y uso por parte de sus audiencias previstas.

Validación
La validación de requisitos confirma que tiene el conjunto correcto de información de requisitos que permitirá a
los desarrolladores crear una solución que satisfaga los objetivos comerciales. Las actividades centrales son:

-- Revisar los requisitos documentados para corregir cualquier problema antes de que el grupo de
desarrollo los acepte.

-- Desarrollar pruebas y criterios de aceptación para confirmar que un producto basado en los requisitos
satisfaría las necesidades del cliente y lograría los objetivos comerciales.

La iteración es la clave para el éxito del desarrollo de requisitos. Planifique múltiples ciclos de exploración
de requisitos, refinando progresivamente los requisitos de alto nivel con mayor precisión y detalle, y
confirmando la corrección con los usuarios. Esto toma tiempo y puede ser frustrante. No obstante, es un
aspecto intrínseco de lidiar con la incertidumbre difusa de definir un nuevo sistema de software.

ImportanteNunca obtendrá requisitos perfectos. Desde un punto de vista práctico, el objetivo del
desarrollo de requisitos es acumular una comprensión compartida de los requisitos que es
suficientemente buenopara permitir que la construcción de la siguiente parte del producto, ya sea el 1
por ciento o el 100 por ciento del producto completo, proceda con un nivel de riesgo aceptable. El
principal riesgo es tener que realizar un exceso de reelaboración no planificada porque el equipo no
entendió suficientemente los requisitos para la siguiente parte del trabajo antes de comenzar el diseño y
la construcción.

Gestión de requerimientos
Las actividades de gestión de requisitos incluyen lo siguiente:

-- Definición de la línea de base de los requisitos, una instantánea en el tiempo que representa un conjunto de requisitos
funcionales y no funcionales acordados, revisados y aprobados, a menudo para una iteración de desarrollo o
lanzamiento de un producto específico.

-- Evaluar el impacto de los cambios de requisitos propuestos e incorporar los cambios

aprobados en el proyecto de forma controlada

-- Mantener los planes del proyecto actualizados con los requisitos a medida que evolucionan.

-- Negociar nuevos compromisos basados en el impacto estimado de los cambios en los requisitos

CAPÍTULO 1El requisito esencial del software 17

 -- Definición de las relaciones y dependencias que existen entre los requisitos.

-- Seguimiento de requisitos individuales a sus correspondientes diseños, código fuente y pruebas

-- Seguimiento del estado de los requisitos y actividad de cambio a lo largo del proyecto

El objeto de la gestión de requisitos no es sofocar el cambio o dificultarlo. Es anticipar y adaptarse

a los cambios muy reales que siempre puede esperar para minimizar su impacto disruptivo en el
proyecto.

La figura 1-5 proporciona otra vista del límite entre el desarrollo de requisitos y la gestión
de requisitos. Este libro describe docenas de prácticas específicas para realizar la elicitación, el
análisis, la especificación, la validación y la gestión de requisitos.

FIGURA 1-5El límite entre el desarrollo de requisitos y la gestión de requisitos.

Todo proyecto tiene requisitos.

Frederick Brooks declaró elocuentemente el papel fundamental de los requisitos para un proyecto de software en su
ensayo clásico de 1987, "No Silver Bullet: Essence and Accidents of Software Engineering":

La parte más difícil de construir un sistema de software es decidir con precisión qué
construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los
requisitos técnicos detallados, incluidas todas las interfaces con personas, máquinas y otros
sistemas de software. Ninguna otra parte del trabajo paraliza tanto el sistema resultante si
se hace mal. Ninguna otra parte es más difícil de rectificar después.

18 PARTE IRequisitos de software: qué, por qué y quién

 Cada sistema que contiene software tiene partes interesadas que confían en él. El tiempo dedicado a comprender sus
necesidades es una inversión de alto apalancamiento en el éxito del proyecto. Si un equipo de proyecto no tiene representaciones
escritas de los requisitos que las partes interesadas acuerdan, ¿cómo pueden estar seguros los desarrolladores de satisfacer a esas
partes interesadas?

A menudo, es imposible, o innecesario, especificar completamente los requisitos funcionales antes de

comenzar el diseño y la implementación. En esos casos, puede adoptar un enfoque iterativo o incremental,
implementando una parte de los requisitos a la vez y obteniendo comentarios de los clientes antes de pasar al
siguiente ciclo. Esta es la esencia del desarrollo ágil, aprender lo suficiente sobre los requisitos para realizar una
priorización cuidadosa y una planificación de versiones para que el equipo pueda comenzar a entregar software
valioso lo más rápido posible. Sin embargo, esta no es una excusa para escribir código antes de contemplar los
requisitos para el próximo incremento. Iterar el código es más caro que iterar los conceptos.

Las personas a veces se resisten a gastar el tiempo que se necesita para escribir los requisitos del software.
Pero escribir los requisitos no es la parte difícil. la parte dificil esdeterminandolos requisitos. Escribir requisitos es
una cuestión de aclarar, elaborar y registrar lo que ha aprendido. Una sólida comprensión de los requisitos de un
producto garantiza que su equipo trabaje en el problema correcto y diseñe la mejor solución para ese problema.
Sin conocer los requisitos, no puede saber cuándo finalizó el proyecto, determinar si cumplió con sus objetivos o
tomar decisiones de compensación cuando es necesario realizar ajustes en el alcance. En lugar de resistirse a
dedicar tiempo a los requisitos, la gente debería resistirse al dinero desperdiciado cuando el proyecto no presta
suficiente atención a los requisitos.

Cuando los malos requisitos le suceden a la gente buena

La principal consecuencia de los problemas de requisitos es la reelaboración, es decir, volver a hacer algo que pensaba
que ya se había hecho, al final del desarrollo o después del lanzamiento. La reelaboración suele consumir del 30 al 50 por
ciento del costo total de desarrollo (Shull, et al. 2002; GAO 2004), y los errores de requisitos pueden representar del 70 al
85 por ciento del costo de la reelaboración (Leffingwell 1997). Algunas reelaboraciones agregan valor y mejoran el
producto, pero las reelaboraciones excesivas son inútiles y frustrantes. ¡Imagínese lo diferente que sería su vida si pudiera
reducir a la mitad el esfuerzo de reelaboración! Los miembros de su equipo podrían crear mejores productos más rápido
y tal vez incluso volver a casa a tiempo. Crear mejores requisitos es una inversión, no solo un costo.

Puede costar mucho más corregir un defecto que se encuentra tarde en el proyecto que
arreglarlo poco después de su creación. Suponga que cuesta $ 1 (en una escala relativa) para
encontrar y corregir un requisito defectuoso mientras todavía está trabajando en los requisitos. Si
descubre ese error durante el diseño, debe pagar $ 1 para corregir el error del requisito, más otros $
2 o $ 3 para rehacer el diseño que se basó en el requisito incorrecto. Sin embargo, suponga que
nadie encuentra el error hasta que un usuario llama con un problema. Dependiendo del tipo de
sistema, el costo de corregir un defecto de requisito encontrado en funcionamiento puede ser de
$100 o más en esta escala relativa (Boehm 1981; Grady 1999; Haskins 2004).

CAPÍTULO 1El requisito esencial del software 19

 (Wiegers 2002). Por el contrario, gastaron un promedio deps4200para corregir un solo defecto informado por el usuario, un factor
de amplificación de 21. La prevención de errores de requisitos y su detección temprana claramente tiene un gran efecto de
apalancamiento en la reducción del retrabajo.

Las deficiencias en las prácticas de requisitos plantean muchos riesgos para el éxito del proyecto, dondeéxito
significa entregar un producto que satisfaga las expectativas funcionales y de calidad del usuario al costo y
tiempo acordados. El Capítulo 32, "Requisitos de software y gestión de riesgos", describe cómo gestionar dichos
riesgos para evitar que descarrilen su proyecto. Algunos de los riesgos de requisitos más comunes se describen
en las siguientes secciones.

Insuficiente participación del usuario

Los clientes a menudo no entienden por qué es tan esencial trabajar duro para obtener los requisitos y garantizar su
calidad. Es posible que los desarrolladores no enfaticen la participación de los usuarios, quizás porque creen que ya
entienden lo que necesitan los usuarios. En algunos casos, es difícil obtener acceso a las personas que realmente usarán el
producto, y los sustitutos de los usuarios no siempre entienden lo que los usuarios realmente necesitan. La participación
insuficiente del usuario conduce a requisitos de última hora que generan reelaboración y retrasos en la finalización.

Otro riesgo de la participación insuficiente del usuario, particularmente cuando se revisan y validan los
requisitos, es que el analista comercial podría no comprender y registrar adecuadamente las verdaderas
necesidades del negocio o del cliente. A veces, un BA sigue el camino de especificar lo que parecen ser los
requisitos "perfectos", y los desarrolladores los implementan, pero luego nadie usa la solución porque no se
entendió bien el problema comercial. Las conversaciones en curso con los usuarios pueden ayudar a mitigar este
riesgo, pero si los usuarios no revisan los requisitos con suficiente cuidado, aún puede tener problemas.

Planificación imprecisa
“Esta es mi idea para un nuevo producto; ¿cuándo terminarás? Nadie debe responder a esta pregunta hasta que
se sepa más sobre el problema que se está discutiendo. Los requisitos vagos y mal entendidos conducen a
estimaciones demasiado optimistas, que vuelven a atormentarte cuando ocurren los inevitables excesos.
La conjetura rápida de un estimador se parece mucho a un compromiso con el oyente. Los principales factores que
contribuyen a una estimación deficiente del costo del software son los cambios frecuentes en los requisitos, la falta de
requisitos, la comunicación insuficiente con los usuarios, la especificación deficiente de los requisitos y el análisis de
requisitos insuficiente (Davis 1995). Estimar el esfuerzo y la duración del proyecto en función de los requisitos significa
que necesita saber algo sobre el tamaño de sus requisitos y la productividad del equipo de desarrollo. Véase el Capítulo 5
deMás sobre los requisitos de software(Wiegers 2006) para obtener más información sobre la estimación basada en
requisitos.

Crecientes requisitos de los usuarios

A medida que los requisitos evolucionan durante el desarrollo, los proyectos a menudo exceden sus cronogramas y presupuestos planificados

(que, de todos modos, casi siempre son demasiado optimistas). Para gestionar el aumento del alcance, comience con una declaración clara de

los objetivos comerciales, la visión estratégica, el alcance, las limitaciones y los criterios de éxito del proyecto. Evalúe todas las características

nuevas propuestas o los cambios en los requisitos con respecto a esta referencia. Requisitosvoluntad

20 PARTE IRequisitos de software: qué, por qué y quién

cambiar y crecer. El gerente del proyecto debe incorporar reservas de contingencia en los cronogramas para que el primer
requisito nuevo que se presente no descarrile el cronograma (Wiegers 2007). Los proyectos ágiles adoptan el enfoque de
ajustar el alcance de una determinada iteración para que se ajuste a un presupuesto y una duración definidos para la
iteración. A medida que surgen nuevos requisitos, se colocan en la cartera de trabajos pendientes y se asignan a
iteraciones futuras en función de la prioridad. El cambio puede ser fundamental para el éxito, pero el cambio siempre tiene
un precio.

Requisitos ambiguos
Un síntoma de la ambigüedad en los requisitos es que un lector puede interpretar una declaración de
requisitos de varias maneras (Lawrence 1996). Otro signo es que múltiples lectores de un requisito llegan a
diferentes interpretaciones de lo que significa. El Capítulo 11, “Redacción de requisitos excelentes”, enumera
muchas palabras y frases que contribuyen a la ambigüedad al poner la carga de la interpretación sobre el
lector.

La ambigüedad conduce a diferentes expectativas por parte de las distintas partes interesadas. Algunos de ellos se sorprenden
de lo que se entrega. Los requisitos ambiguos provocan una pérdida de tiempo cuando los desarrolladores implementan una
solución para el problema equivocado. Los probadores que esperan que el producto se comporte de manera diferente a lo que
construyeron los desarrolladores pierden tiempo resolviendo las diferencias.

Una forma de descubrir la ambigüedad es hacer que personas que representen diferentes perspectivas
inspeccionen los requisitos (Wiegers 2002). Como se describe en el Capítulo 17, “Validación de los requisitos”, las
revisiones informales por pares en las que los revisores simplemente leen los requisitos por su cuenta a menudo
no revelan ambigüedades. Si diferentes revisores interpretan un requisito de diferentes maneras pero tiene
sentido para cada uno de ellos, no encontrarán la ambigüedad. La obtención y validación colaborativa alienta a
las partes interesadas a discutir y aclarar los requisitos como grupo en un taller. Escribir pruebas contra los
requisitos y construir prototipos son otras formas de descubrir ambigüedades.

Oro platino
Oro platinotiene lugar cuando un desarrollador agrega una funcionalidad que no estaba en la especificación de requisitos
(o se consideró fuera del alcance) pero que el desarrollador cree que "a los usuarios les encantará". Si a los usuarios no les
importa esta funcionalidad, el tiempo dedicado a implementarla se desperdicia. En lugar de simplemente insertar nuevas
funciones, los desarrolladores y los BA deben presentar a las partes interesadas ideas creativas para su consideración. Los
desarrolladores deben esforzarse por la agilidad y la simplicidad, sin ir más allá de lo que solicitan las partes interesadas
sin su aprobación.

Los clientes a veces solicitan ciertas funciones o interfaces de usuario elaboradas que parecen atractivas pero agregan
poco valor al producto. Todo lo que construye cuesta tiempo y dinero, por lo que necesita maximizar el valor entregado.
Para reducir la amenaza del enchapado en oro, rastree cada parte de la funcionalidad hasta su origen y su justificación
comercial para que todos sepan por qué está incluida. Asegúrese de que lo que está especificando y desarrollando se
encuentra dentro del alcance del proyecto.

CAPÍTULO 1El requisito esencial del software 21

 Partes interesadas pasadas por alto
La mayoría de los productos tienen varios grupos de usuarios que pueden usar diferentes subconjuntos de funciones,
tener diferentes frecuencias de uso o tener diferentes niveles de experiencia. Si no identifica las clases de usuarios
importantes para su producto desde el principio, algunas necesidades de los usuarios no se cumplirán. Después de
identificar todas las clases de usuarios, asegúrese de que cada una tenga una voz, como se explica en el Capítulo 6,
“Encontrar la voz del usuario”. Además de los usuarios obvios, piense en el personal de mantenimiento y soporte de
campo que tiene sus propios requisitos, tanto funcionales como no funcionales. Las personas que tienen que convertir
datos de un sistema heredado tendrán requisitos de transición que no afectan al software del producto final, pero que sin
duda influirán en el éxito de la solución. Es posible que tenga partes interesadas que ni siquiera saben que existe el
proyecto, como agencias gubernamentales que exigen estándares que afectan su sistema,

Beneficios de un proceso de requisitos de alta calidad

Algunas personas creen erróneamente que el tiempo dedicado a discutir los requisitos simplemente retrasa la
entrega por la misma duración. Esto supone que no hay retorno de la inversión de las actividades de requisitos.
En realidad, invertir en buenos requisitos prácticamente siempre dará más de lo que cuesta.

Los procesos de requisitos sólidos enfatizan un enfoque colaborativo para el desarrollo de productos que involucra
a las partes interesadas en una asociación a lo largo del proyecto. La obtención de requisitos permite que el equipo de
desarrollo comprenda mejor su comunidad de usuarios o mercado, un factor crítico de éxito. Enfatizar las tareas del
usuario en lugar de características superficialmente atractivas ayuda al equipo a evitar escribir código que nadie
ejecutará nunca. La participación del cliente reduce la brecha de expectativas entre lo que el cliente realmente necesita
y lo que ofrece el desarrollador. Eventualmente obtendrá la opinión del cliente; es mucho más barato llegar a este
entendimiento antes de construir el producto que después de la entrega. El Capítulo 2 aborda la naturaleza de la
asociación de desarrollo de clientes.

La asignación explícita de los requisitos del sistema a varios subsistemas de software, hardware y humanos enfatiza
un enfoque de sistemas para la ingeniería de productos. Un proceso de control de cambios efectivo minimizará el
impacto adverso de los cambios en los requisitos. Los requisitos claros y documentados facilitan enormemente las
pruebas del sistema. Todo esto aumenta sus posibilidades de ofrecer productos de alta calidad que satisfagan a todas
las partes interesadas.

Nadie puede prometer un rendimiento específico de la inversión mediante el uso de prácticas de requisitos sólidas. Sin
embargo, puede pasar por un proceso de pensamiento analítico para imaginar cómo mejores requisitos podrían ayudar a
sus equipos (Wiegers 2006). El costo de mejores requisitos incluye el desarrollo de nuevos procedimientos y plantillas de
documentos, la capacitación del equipo y la compra de herramientas. Su mayor inversión es el tiempo que sus equipos de
proyecto dedican realmente a las tareas de ingeniería de requisitos. El pago potencial incluye:

-- Menos defectos en los requisitos y en el producto entregado.

-- Reducción del retrabajo de desarrollo.

-- Desarrollo y entrega más rápidos.

22 PARTE IRequisitos de software: qué, por qué y quién

-- Menos funciones innecesarias y sin usar.

-- Menores costos de mejora.

-- Menos errores de comunicación.

-- Deslizamiento de alcance reducido.

-- Reducción del caos del proyecto.

-- Mayor satisfacción de los clientes y miembros del equipo.

-- Productos que hacen lo que se supone que deben hacer.

Incluso si no puede cuantificar todos estos beneficios, son reales.

Próximos pasos

-- Escriba los problemas relacionados con los requisitos que haya encontrado en su proyecto
actual o anterior. Identifique cada uno como un problema de desarrollo de requisitos o de
gestión de requisitos. Describa la causa raíz de cada problema y su impacto en el proyecto.

-- Facilite una discusión con los miembros de su equipo y otras partes interesadas sobre los problemas
relacionados con los requisitos de sus proyectos actuales o anteriores, sus impactos y sus causas
fundamentales. Reúna sus ideas sobre los cambios en sus prácticas de requisitos actuales que podrían
abordar estos problemas. La guía de solución de problemas en el Apéndice B puede ser útil.

-- Asigne la terminología de requisitos y los entregables utilizados en su organización a los que se

muestran en este capítulo para ver si está cubriendo todas las categorías recomendadas aquí.

-- Realice una evaluación simple en solo unas pocas páginas de uno de sus documentos de requisitos
para ver dónde su equipo podría tener algunas áreas de mejora claras. Podría ser más útil que una
persona externa objetiva realice esta evaluación.

-- Organice una clase de capacitación sobre los requisitos de software para todo su equipo de proyecto. Invite a

participar a clientes clave, personal de marketing, gerentes, desarrolladores, probadores y otras partes

interesadas. La formación proporciona a los participantes del proyecto un vocabulario común. Proporciona una

apreciación compartida de técnicas y comportamientos efectivos para que todos los miembros del equipo puedan

colaborar de manera más efectiva en sus desafíos mutuos.

CAPÍTULO 1El requisito esencial del software 23