Los requerimientos de un proyecto

Por Joaquín Ibáñez, PMP® [ Acerca del autor]

El propósito de la gestión de requerimientos es asegurar que el proyecto cumple con las
expectativas de sus clientes y de sus interesados, tanto externos como internos, siendo el proceso
que garantiza el vínculo entre lo que esperan los clientes y usuarios, y lo que los equipos de
proyecto tienen que desarrollar.
Si bien muchos de sus principios pueden ser adaptados a todo tipo de proyectos, es en los
proyectos de desarrollo de software donde adquieren todo su sentido, garantizando el proceso y
sirviendo de referencia para asegurar y controlar los cambios que en el proyecto puedan surgir
(trazabilidad). A menudo, incluye la elaboración de planes específicos para diferentes aspectos
como la recolección, gestión e integración de los requerimientos.
Definición de requerimiento y Stakeholders (Interesados)
Según la definición del PMBOK®, un requerimiento es la condición o capacidad que debe tener
un sistema, producto, servicio o componente para satisfacer un contrato, estándar, especificación,
u otros documentos formalmente establecido.
Son todas aquellas características observables que cualquier interesado desea que estén
contenidas en el sistema. Como requisitos se incluyen las necesidades, deseos y expectativas del
patrocinador, cliente, usuarios, y otros interesados.
Como requerimiento se podría establecer:
• Una capacidad necesaria para un cliente o usuario que soluciona un problema o consigue
un objetivo.
• Una capacidad que debe incluirse en un sistema para satisfacer los objetivos del proyecto.
• Una restricción impuesta por algún interesado
Definiendo el concepto de stakeholder (interesado) como alguien que está afectado por el
proyecto que se desarrolla, podremos encontrar que hay de dos tipos:
• Usuarios: Aquellos que utilizaran el sistema.
• Clientes: aquellos que requieren el sistema y son los responsables de su validación o
aprobación.
Es importante distinguir entre estos dos grupos de interesados, dado que muchas veces podremos
encontrarnos que hay un conflicto entre los requerimientos de ambos. En la mayoría de los casos,
los requerimientos de los clientes tienen prioridad sobre los requerimientos de los usuarios.
Características de los requerimientos
Un requerimiento debe cumplir ciertos criterios y características:
• Único: El requerimiento debe poder ser interpretado inequívocamente de una sola
manera.
• Verificable: Su implementación debe poder ser comprobada. El test debe dar como
resultado CORRECTO o INCORRECTO.
• Claro: Los requerimientos no deben contener terminología innecesaria. Deben ser
establecidos de forma clara y simple.
• Viable (realístico y posible): El requerimiento debe ser factible según las restricciones
actuales de tiempo, dinero y recursos disponibles.
• Necesario: Un requerimiento no es necesario si ninguno de los interesados necesita el
requerimiento o bien si la retirada de dicho requerimiento no tiene ningún efecto
Además de los criterios para los requerimientos individuales, para el conjunto de ellos debe
cumplirse:
• Independiente: Para comprender el requerimiento no debe ser necesario el conocimiento
de otro.
• Consistente: No debe existir ningún conflicto entre requerimientos. Los conflictos pueden
ser:

- Directos: Cuando ante una misma situación, cabe esperar comportamientos diferentes.
- Indirectos: Se produce cuando no es posible cumplir con dos requisitos al mismo
tiempo, aunque describan funcionalidades distintas.

• No redundante: Cada requerimiento debe ser formulado una sola vez, y no sobreponerse
con otros requerimientos.
• Completo: Un requerimiento debe ser especificado teniendo en cuenta todas las
condiciones que puedan ocurrir.
Organización y estructura de la gestión de requerimientos

Según el origen y características, los requisitos pueden dividirse en diferentes tipos., que pueden
representarse en forma de pirámide, en cuyo nivel superior se sitúan las necesidades de los
interesados. En los niveles más bajos son características, casos de uso y requisitos
complementarios tal como se muestra en la figura:

• Necesidad: Un interesado demanda un requerimiento.

• Característica: Un servicio proporcionado por el sistema, por lo general formulado por un
analista de negocios.
• Caso de uso: Una descripción del comportamiento del sistema descrito como una
secuencias de acciones.
• Requisito complementario: Otro requisito (generalmente no funcional) que no puede ser
contemplado en los casos de uso.
 • Caso de prueba: Una especificación de las entradas necesarias para una prueba, las
condiciones de ejecución y resultados esperados. Tiene el papel de comprobar si los casos
de uso derivados de los casos de prueba y los requisitos complementarios se aplican
correctamente.
• Escenario: Una secuencia específica de acciones o una ruta de acceso específica a través
de un caso de uso. Ayudan a derivar en casos de uso a partir de los casos de prueba y
facilitan el diseño e implementación a través de los casos de uso.
Con bastante frecuencia, a diferentes niveles de los requisitos, se especifican diferentes niveles
de detalle. Cuanto menor sea el nivel, más detallado es el requisito. Sin embargo, corresponde a
los analistas de negocio decidir el nivel de detalle en cada nivel, aunque no sería incorrecto
establece requisitos muy detallados en el nivel de necesidades.
Trazabilidad
La trazabilidad de los requerimientos se refiere a la documentación de la vida de cada uno de
ellos, y debe permitir seguir el historial desde su formulación original hasta el momento actual.
Cada cambio realizado debe por tanto ser documentado para conseguir dicha trazabilidad.
Incluso la implementación de las características determinadas por los requerimientos debe poder
ser trazada.
Los requerimientos surgen de diversas fuentes: el cliente, el manager, el usuario final, etc...
Todas y cada una de ellas tienen diferentes requerimientos para el producto. Utilizando la
trazabilidad, puede seguirse el historial de una característica implementada hasta las personas o
grupos que la solicitaron durante la generación de los requerimientos, permitiendo un rápido
análisis en cada fase del proyecto para:
• Determinar la visión original y permitir una discusión controlada de los cambios en el
alcance.
• Determinar qué elementos se verán afectados cuando consideramos agregar un nuevo
requerimiento o modificar uno ya existente.
• Verificar que el requerimiento contempla todos lo que el interesado solicitó.
• Evitar el Gold Platting: Verificar que la aplicación no implementa funcionalidades no
demandadas por el cliente.
Actividades en la Gestión de Requerimientos
Por Joaquín Ibáñez Marimón, PMP® [ Acerca del autor]
La gestión de requerimientos, entendida como el conjunto de actividades que abarcan la
recopilación, control, análisis, filtrado y documentación de los requisitos del sistema, consiste en
tres actividades fundamentales:
Generación de requerimientos:
Es la habilidad de entender las necesidades de los interesados, y recopilarlos en un repositorio
para futuros análisis. Las necesidades pueden ser expresadas de forma abstracta y en términos de
problemas (Quiero reducir mis ratios de error en un 35%) o bien concretos y en términos de una
solución (Debe haber un botón rojo de paro en la consola).
En ambos casos las necesidades son conocidas como características
Evaluación de requerimientos:
Es la habilidad de discernir qué características son apropiadas para incluir en el producto, dado
que raramente es posible satisfacer todas las características demandadas por cada uno de los
interesados. La evaluación tiene en consideración todas las realidades del mercado y toma la
decisión acerca de qué características se implementarán, cuales lo serán en la próxima versión, y
cuales se aplazarán hasta más tarde.
Especificación de requerimientos:
Es la habilidad de detallar el comportamiento de un sistema. En cada estadio del proceso de
desarrollo, variaran la forma y el nivel de detalle en la especificación de los requerimientos. Para
ilustrarlo, considérese un proceso estándar de desarrollo en cinco fases: Investigación,
Viabilidad, diseño, construcción y test, lanzamiento.

Investigación
En la fase de investigación, se recopilan requerimientos entre los usuarios y los miembros del
equipo de desarrollo. Para cada uno de ellos se formulan cuestiones similares acerca de cuáles
son los logros, las restricciones y las herramientas o procesos disponibles…Sólo cuando estos
requerimientos sean bien entendidos, se pueden desarrollar los requerimientos funcionales.
Hay que tener muy presente que los requerimientos no pueden ser completamente definidos al
inicio del proyecto. Algunos cambiarán, bien porque sean simplemente suprimidos, o debido a
los intereses y modificaciones que afecten al ciclo de vida del proyecto.
Por ello, la flexibilidad en los planteamientos y las operaciones, son condiciones para el éxito.
El entregable del estadio de investigación es un documento de requerimientos que haya sido
aprobado por todos los miembros del equipo. Después, y durante el desarrollo, este documento
será clave para prevenir la corrupción del alcance o los cambios innecesarios.
Mientras que muchas organizaciones todavía utilizan solo documentos para gestionar los
requerimientos, otras gestionan a partir de herramientas de software. Estas herramientas permiten
gestionar los requerimientos en una base de datos y acostumbran a tener funciones para
automatizar la trazabilidad, como por ejemplo permitir la vinculación electrónica entre la
jerarquía de requerimientos, el control de versiones y la gestión de cambios
Viabilidad
Durante el estudio de viabilidad, se determinan:
Los costes de los requerimientos: Para los requerimientos de usuario, se comparan los costes
actuales con los futuros, una vez se haya implementado el nuevo sistema.
Los costes de operación: Indicarán qué departamento tiene presupuesto para ello y cuál es el
retorno de inversión para este producto, incluyendo la reducción de costes si se desarrolla un
nuevo sistema más fácil de utilizar.
Los costes técnicos: Están relacionados con los costes de desarrollo de software y los costes del
hardware. El equipo debe indagar si los nuevos equipos y herramientas añadirán suficiente
potencia de procesamiento para transferir suficiente carga de trabajo del usuario al sistema que
permita un ahorro significativo de tiempo y costes al personal
El entregable para el estadio de estudio de viabilidad son la programación y el presupuesto para
el proyecto.
Diseño
Asumiendo que los costes han sido determinados con precisión y que los beneficios a obtener
son suficientemente importantes, el proyecto puede pasar al estadio de diseño. En dicho estadio,
la actividad principal de la gestión de requerimientos es comparar los resultados del diseño con
el documento de requerimientos, para asegurarse de que el trabajo está contemplado dentro del
alcance.
Implementación y test
En el estadio de implementación y test, la actividad principal de la gestión de requerimientos, es
asegurar que el trabajo y el coste se desarrollan de acuerdo con la programación y el presupuesto,
y que las nuevas herramientas cumplen de hecho con los requerimientos. La herramienta
principal utilizada en este estadio es la construcción de prototipos y el test iterativo. Para una
aplicación de software, la interfaz de usuario puede ser creada en papel y probada con los
usuarios potenciales, mientras está siendo creado el entorno de software. Los resultados de
dichos test son archivados en una guía de diseño de interfaz de usuario y trasladado al equipo de
diseño, cuando este esté listos para desarrollar la interface. Esto ahorra tiempo y hace el trabajo
mucho más fácil.
Lanzamiento
Podría pensarse que la gestión de requerimientos finaliza al entregar el producto, pero no es del
todo cierto. Desde este punto, se recopilan los datos provenientes de la aceptación de la
aplicación, y utilizados posteriormente en la fase de investigación de la nueva generación o
versión. Entonces, el proceso empieza de nuevo.

Pasos de la Gestión de Requerimientos

Por Joaquín Ibáñez Marimón, PMP® [ Acerca del autor]
Una descripción simplificada de la gestión de requerimientos contiene los siguientes pasos
principales:
Establecer un plan de gestión de requisitos
Una de las primeras tareas en el proyecto es desarrollar un Plan de gestión de requerimientos
(RMP son sus siglas en ingles). El RMP describe el enfoque general para gestionar los
requerimientos del proyecto. El documento detalla cómo se generan, organizan, modifican y
trazan los requerimientos en el ciclo de vida del proyecto. También describe todos los tipos de
requerimientos y los atributos utilizados en el proyecto. Algunas cuestiones que debe clarificar el
RPM son:
• ¿Cómo deben usarse las herramientas de gestión de requerimientos?
• ¿Qué tipos de requerimientos serán trazados en el proyecto?
• ¿Cuáles son los atributos de estos requerimientos?
• ¿Dónde se crearan los requerimientos-en una base de datos o solo en documentos?
• ¿Entre cuales requerimientos necesitamos implementar trazabilidad?
• ¿Qué documentos se requieren?
• ¿Qué requerimientos y documentos serán utilizados como contrato con un proveedor?
¿Qué metodología será utilizada?
• ¿El cliente necesita algún documento específico para cumplir con su proceso de
desarrollo?
• ¿Cómo se implementará la gestión de cambios?
• ¿Qué proceso garantizará que todos los requerimientos serán implementados y
comprobados?
• Qué requerimientos u opiniones necesitamos para generar informes?
Técnicas para la recopilación de requerimientos
La recopilación de requerimientos es un paso muy importante. Un error o mala interpretación de
un requisito en esta etapa propagará el problema a través del ciclo de vida de desarrollo.
En muchos proyectos es más fácil agrupar todas las entradas de los interesados en un mismo tipo
de requerimiento,. En otros proyectos, puede haber la necesidad de distinguir entre "necesidades
de los interesados", que describen los requisitos iniciales, y "solicitudes de los interesados ", que
pueden incluir las solicitudes de cambio posterior.
Entrevistas: Son utilizadas para recopilar información de los interesados. Sin embargo, la
predisposición y experiencias de la persona entrevistada influirán en la obtención de resultados.
Es conveniente la utilización de preguntas abiertas que no sugieran una determinada respuesta.
Análisis de Documentos: Todo establecimiento de requisitos implica un cierto estudio de los
documentos que definen la razón de ser del proyecto, tales como planes de negocio, estudios de
mercado, contratos, etc.…
Tormenta de ideas: Es una técnica eficaz porque las ideas más creativas y efectivas, son a
menudo, el resultado de la combinación de ideas aparentemente inconexas. Además, esta técnica
alienta el pensamiento de ideas inusuales.
Talleres de Requisitos: Pueden estar diseñados para alcanzar la unificación de criterios en cuanto
a los requisitos de una capacidad en concreto. Conviene que sean dirigidos y coordinados por un
experto, y son normalmente cortos (uno o varios días). Otras ventajas que a menudo consiguen
es alentar el compromiso de los participantes con el proyecto, fomentando el espíritu de grupo
Creación de prototipos: Consiste en la creación de una versión rápida y poco depurara de un
sistema o partes del mismo. Con dicho prototipo, los usuarios y diseñadores tendrán una idea
clara de las capacidades del sistema., aunque podría tener la percepción de que los
desarrolladores están en un estadio del diseño más avanzado de lo que realmente están,
sugiriendo una impresión de los plazos de finalización demasiado optimista.
Casos de uso: Es una representación gráfica de las acciones que debe realizar un sistema. Deben
complementarse siempre con atributos de calidad y otras informaciones tales como
características de la interfaz.
Los casos de uso por sí sola no proporcionan suficiente información que permita actividades de
desarrollo.
Guiones gráficos: Son un conjunto de dibujos que representan un conjunto de actividades de
usuario que describen las que se producen en un sistema o capacidad existente o prevista. Los
guiones gráficos son una especie de prototipos de papel. Los clientes, usuarios o desarrolladores
dibujan pantallas, cuadros de diálogo, barras de herramientas y otros elementos que creen que
deberá proporcionar el software. Los guiones gráficos son baratos y permiten eliminar los riesgos
y costos más elevados de creación de prototipos.
Análisis de interfaces: El diseño incorrecto de las interfaces es a menudo una de las principales
causas de sobrecoste y fracaso del producto. La identificación temprana de las características de
las interfaces externas clarifica el ámbito de aplicación de producto, ayuda en el proceso de
evaluación del riesgo, reduce los costos de desarrollo del producto, y mejora la satisfacción del
cliente.
Modelado: Es una representación de la realidad que pretende facilitar la comprensión. El uso de
prototipos y modelos ayuda a eliminar ambigüedades y contradicciones, contribuyendo de forma
notable al éxito del proyecto.
Desarrollo el documento de visión
Es un documento de visión es un documento que describe la 'visión', o plan general, para un
determinado proceso de software. Pretende ser un documento de alto nivel más breve y general
que un documento de requisitos de producto, y en él se describe lo que se espera llevar a cabo y
las características que no están en el alcance, pero que se prevé agregarán al producto en
posteriores etapas del desarrollo de éste
El propósito del documento es recopilar y analizar las ideas que han surgido para el futuro del
producto, y asegurarse de que los interesados clave tienen una visión clara y compartida de los
objetivos y alcance del proyecto. Identifica alternativas y los riesgos asociados con el proyecto.
Por último, presenta un presupuesto para la fase de planificación.

Durante el desarrollo del documento de visión, uno de los logros principales del análisis de
negocio es que se deriven características para las necesidades de los interesados. Las
características deben tener todos los atributos de un buen requerimiento: Verificable, no
redundante, claro….
El documento de visión debe contener la información esencial acerca del sistema que está siendo
desarrollado. Además de listar todas sus características, debe contener:
• Una descripción general del producto.
• Un sumario con las capacidades del sistema.
• Toda la información que pueda ser requerida para comprender el propósito del sistema.
También pueden listarse todas las necesidades de los interesados que no fueron recogidas en
otros documentos
Crear casos de uso
Los requerimientos funcionales se describen mejor en forma de casos de uso, que se derivan de
las características. Un caso de uso es una descripción de un sistema en términos de una secuencia
de acciones. Debe ser un resultado observable o un valor para el actor (un actor es alguien o algo
que interactúa con el sistema).
Los casos de uso:
• Son iniciados por un actor
• Modelan la interacción entre el interesado y el sistema
• Describen una secuencia de acciones
• Capturan los requerimientos funcionales
• Proporcionan algún valor para un actor
• Representan un completo y significativo flujo de eventos.
Especificación suplementaria
Las especificaciones suplementarias recogen aquellos requerimientos no funcionales (usabilidad,
fiabilidad, rendimiento,..) y algunos requerimientos funcionales internos del sistema que, por
tanto, son difíciles de contemplar en los casos de uso.
Creación de casos de prueba a partir de casos de uso
Tan pronto como se recopilan todos los requisitos, deberíamos diseñar una forma de comprobar
si se implementan correctamente en el producto final. Los casos de prueba mostrarán a los
evaluadores qué pasos deben realizarse para probar todos los requisitos. En este paso nos
concentraremos en la creación de casos de prueba a partir de casos de uso.
Creación de casos de prueba a partir de especificaciones complementarias
El enfoque utilizado en el paso anterior no se aplica a las pruebas de los requisitos
complementarios. Dado que estos requisitos no se expresan como una secuencia de acciones, el
concepto de escenarios no se les aplica, y debe desarrollarse un enfoque individual a cada uno de
los requisitos complementarios.
En este paso, también se diseñarán pruebas de infraestructura y cuestiones relacionadas con la
plataforma.
Diseño del sistema
Los requisitos son la base para el diseño del sistema, que a menudo se ve facilitada por el uso del
lenguaje unificado de modelado (UML)
ntroducción a la Recopilación de Requerimientos

El líder de proyecto debe utilizar cualquier medio posible para obtener los requerimientos del
sistema. Esto lo realiza en especial durante la primera fase del proyecto. Aunque es normal que
siga haciéndolo en las demás fases en menor medida, pues difícilmente se podrán tener los
requerimientos totalmente estables ni completos desde un principio.
Una de las principales formas de obtener dicha información es mediante reuniones donde el
analista debe guiar la entrevista y documentar todos los puntos importantes que allí se vayan
mencionando.
Se deben de analizar los documentos con los que se cuente para preparar una agenda y
cuestionarios para cada entrevista y así obtener mejores resultados.
Debe de tomar en cuenta la opinión de los diferentes stakeholders del proyecto, desde el
responsable del área a la cual se le está desarrollando el sistema hasta el usuario final para
obtener los requerimientos más completos posible.
Durante las reuniones se deben de elaborar minutas con los acuerdos y enviarlas a los
participantes para su validación. Si no responden en un tiempo acordado con sus observaciones
se considerará como aceptado lo allí escrito.
Se recomienda utilizar mecanismos que faciliten la retroalimentación y participación de usuarios,
como es el caso de modelos, prototipos no funcionales y casos de uso.
La información documentada en las minutas no reemplaza a los documentos formales de
requerimientos, como podrían ser la visión, la especificación y matriz de requerimientos, las
especificaciones de casos de uso o la especificación suplementaria.
Durante la fase preliminar (Concepción en el caso del Proceso Unificado) hay que identificar los
requerimientos de alto nivel del sistema en un documento de Visión y detallarlos en
Especificaciones de casos de uso y especificación suplementaria durante la fase de Análisis (fase
de Elaboración para el caso de UP).
Los requerimientos documentados son la base para que el administrador realice las estimaciones
y el plan del proyecto en general. Para lo cual necesitará la validación del usuario a todos los
documentos donde se especifiquen los requerimientos.
El administrador no debería asumir nada. Es importante que se asegure que está entendiendo
correctamente lo que el usuario quiso decir, por lo que debe validar la información escrita y de
preferencia formalizarla por medio de firmas de aprobación de los usuarios.
Validar Requerimientos con el Usuario

Parte indispensable del proyecto consiste en asegurar que el equipo de desarrollo entiende
adecuadamente las necesidades del usuario para así desarrollar un sistema que cumpla con sus
expectativas. Para facilitar esto, el usuario debe revisar y firmar de autorizado los documentos
donde estén especificados los requerimientos, como son los casos de uso, el documento de
Visión y/o cualquier otro documento donde hayan quedado documentados.
El documento de visión debe validarlo el usuario al completarse la fase de concepción, y los
requerimientos a detalle al completar la fase de elaboración. El líder de proyecto debe asegurarse
que se realice dicha validación.

Control de Cambios a los Requerimientos

Dicen que lo único constante en los proyectos son los cambios. Debemos de acostumbrarnos a
ellos y aceptarlos como algo normal. Cambios que solicitan los usuarios porque comprenden
mejor lo que necesitan, o porque cambian las necesidades del negocio, porque se identifica una
mejor forma de hacer las cosas o por cualquier otra razón.
El problema no son los cambios a los requerimientos, sino el hecho de que se agreguen a la lista
de requerimientos del proyecto sin considerar el impacto que tendrán sobre el plan. No hacerlo
significa que cuando el proyecto se termine en una fecha posterior a la acordada originalmente, o
con un presupuesto mayor al considerado, se le podría achacar al líder del proyecto como un
fracaso.
El control de cambios es el proceso mediante el cual se asegura que no se realicen cambios que
afecten el éxito del proyecto, y que aquellos que se implementen sean analizados, negociados y
planeados de una manera adecuada.
Estando dentro de la fase de Elaboración o después de haber negociado el alcance y el plan de
trabajo, si el usuario llegara a solicitar un cambio a los requerimientos establecidos, el
administrador u otra persona debería de llenar una solicitud de cambio con la descripción del
cambio.
El cambio es analizado y se evalúa el impacto en costo y tiempo, y si es algo aceptable para los
recursos disponibles y el tiempo que se le puede asignar a dicho proyecto, además de ser
aceptado por el usuario y autorizado por la gerencia, entonces se acepta la solicitud. En caso
contrario debe registrarse como una solicitud rechazada.
El impacto del cambio debe ser estimado por lo recursos involucrados en las actividades
relacionadas con dicho cambio para después negociarlo con el cliente. Dicho impacto puede
significar tiempos o costos adicionales, por lo que requiere la aprobación correspondiente del
gerente y del cliente.
Independientemente de que la solicitud sea aceptada o rechazada debe registrarse en el control de
cambios del proyecto con un identificador único y algunos datos básicos de acuerdo al formato
establecido para ello, o de acuerdo a la herramienta de control de cambios que se utilice.