Siguiendo la definición establecida por el PMI, la matriz de trazabilidad de requisitos es un cuadro que vincula los requisitos del proyecto desde su origen hasta los entregables que lo satisfacen (Definición de la guía del PMBOK).
La matriz de requisitos ayuda a asegurar que cada requerimiento agrega valor al negocio, mostrándote el vínculo entre requisitos, necesidades de negocio y objetivos de proyecto. De esta forma puedes hacer un seguimiento durante el ciclo de vida, mejorando la ingeniería de requisitos al asegurar que estos sean entregados según especificaciones.
Aquí te presentamos una matriz de trazabilidad de requisitos, con la que podrás documentar información de cada requisito, códigos y subcódigos, criterios de aceptación, oportunidades y metas de negocio, entregable que satisface el requisito, interesados (stakeholders), nivel de complejidad, estado actual y más.
>> Descargar la plantilla de matriz de trazabilidad de requerimientosMás abajo te presentamos la descripción de las columnas de la plantilla.
En proyectos de desarrollo de software o sistemas de información, los requisitos también pueden documentarse en un documento de requerimientos de software. A continuación te compartimos una plantilla:
> Documento de requerimientos de software La ingeniería de requisitos en un proyecto está íntimamente relacionada con la gerencia de los interesados (stakeholders), pues son quienes originan los requisitos y tienen mayor influencia en su aceptación.
Aquí te describimos el contenido de cada columna de la plantilla de matriz de requisitos e información que debes completar en cada una.
- Identificación: Código de identificación de mayor nivel definido para el requisito. Puede definirse con números, por ejemplo 001, 002, 003, y así sucesivamente.
- Sub identificación: Sub código de identificación que puede utilizarse para definir requisitos detallados y asociarlos a un requisito padre. De esta forma se define la trazabilidad entre requisitos de alto nivel con requisitos más detallados. Puede definirse según el número de requisito padre, por ejemplo para el caso de 001 podría definirse el requisito 1.1 y 1.2. Pueden también definirse niveles adicionales de detalle de requisito, por ejemplo el requisito 1.1.1 y 1.1.2 estarían asociados a 1.1.
- Descripción del requisito: Se proporciona una descripción de que comprende o en qué consiste el requisito. La descripción del requisito depende del tipo que sea, por ejemplo requisitos del negocio, requisitos de los interesados, requisitos funcionales, requisitos no funcionales, requisitos del proyecto o requisitos del producto (solución).
- Versión: Número de versión del requisito en su estado actual. De esta forma los requisitos se pueden ir detallando o modificando en versiones sucesivas.
- Estado actual: Puede ser solicitado, aprobado, asignado, completado, cancelado, diferido, aceptado, entre otros.
- Última fecha de estado registrado: Fecha en la que se realizó el último cambio de estado del requisito.
- Criterios de aceptación: Lista los criterios de aceptación, una lista de puntos o condiciones específicas que deben cumplirse para poder registrar que el requisito ha sido satisfecho.
- Nivel de complejidad: Puede definirse una complejidad de forma cualitativa, por ejemplo baja, moderada o alta. Esto dependerá del criterio del evaluador.
- Necesidad, oportunidades u objetivos de negocio: Vínculo del requisito con la estrategia de la organización, listando necesidades específicas que tenga el área de negocio, objetivos de la planificación estratégica que busca lograr u oportunidades de negocio o del mercado. Esto también se puede vincular con la Gerencia del portafolio al que pertenece el proyecto.
- Objetivos del proyecto: Vínculo del requisito con los objetivos del proyecto. Aquí se establece la trazabilidad entre el requisito y los objetivos específicos del proyecto definidos e su alcance.
- Entregables (EDT): Entregables de la estructura desagregada de tarea (EDT) en los cuales está inmerso el requisito. Puede especificarse tanto el nombre del elemento de la EDT como su código EDT.
- Diseño del producto: Implicaciones que tiene el requisito desde el punto de vista del diseño del producto. Aquí se especifica como el diseño del producto incorpora los componentes necesarios para poder satisfacer el requerimiento.
- Desarrollo del producto: Implicaciones del requisito en el desarrollo del producto. Describe como los procedimientos de trabajo, metodología o estándares usados incorporan el requisito. Esto aplica principalmente para requisitos que definen la forma de trabajar, estándares a cumplir, entre otros.
- Estrategia y escenarios de pruebas: Listado de las estrategias y escenarios de pruebas que se contemplarán para validar la aceptación del requisito. Estos se definen a partir de los criterios de aceptación.
- Interesado (Stakeholder) dueño del requisito: Nombre, departamento y cargo del interesado (Stakeholder) que originó la solicitud del requerimiento particular. Debe corresponder con el que es especificado en el registro de interesados del proyecto.
- Nivel de prioridad: Según la evaluación de la importancia del requisito para el logro de los objetivos del proyecto, se asigna un nivel de prioridad. Este nivel también puede depender del grado de influencia del interesado y estrategias que se estén empleando para gestionar la participación de los interesados.
Comentarios