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.
