Software Requirements Wiegers 3ed (034-057) .En - Es
Software Requirements Wiegers 3ed (034-057) .En - Es
Software Requirements Wiegers 3ed (034-057) .En - Es
com
PARTE I
Software
requisitos: qué,
porque y quien
1
CAPÍTULO 1
“¿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?"
“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").
-- Distinguirproductorequisitos deproyectorequisitos
-- Esté alerta a varios problemas relacionados con los requisitos que pueden surgir.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
FIGURA 1-2Relaciones entre las características, los requisitos del usuario y los requisitos funcionales.
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.
FIGURA 1-3Un ejemplo de cómo las diferentes partes interesadas participan en el desarrollo de requisitos.
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.
-- Recursos físicos que necesita el equipo de desarrollo, como estaciones de trabajo, dispositivos de hardware
videoconferencia.
-- Documentación del usuario, incluidos materiales de formación, tutoriales, manuales de referencia y notas de la
versió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).
-- 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.
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.
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.
-- Trabajar con personas que representan a cada clase de usuario para comprender sus necesidades de
funcionalidad y sus expectativas de calidad.
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.
-- Identificar lagunas en los requisitos o requisitos innecesarios en relación con el alcance definido
-- 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.
-- 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
-- Seguimiento del estado de los requisitos y actividad de cambio a lo largo del 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.
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.
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.
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).
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.
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.
(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
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.
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:
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.
-- 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