Administrar los requerimientos significa poder establecer un mecanismo de registro y control de cada uno de los requisitos del sistema, su descripción, priorización y trazabilidad, tanto individualmente como en conjunto.
12.1 Asignación de atributos a los requerimientos
Los requerimientos deben ser descritos utilizando un lenguaje natural, es decir, con una redacción que describa de forma clara y completa las necesidades y expectativas que tenga el usuario final sobre el software.
Este tipo de documentación escrita requiere asignarle ciertos atributos para que ayuden a identificarla y estructurarla de forma lo más completa posible.
En opinión de Pohl y Rupp (2011), la forma más simple para definir los atributos de un requerimiento es a través de una platilla que exprese la información más relevante, que puede ser diferente para cada uno por la diversidad de características que existe. Por ejemplo, podrías crear una para los requerimientos funcionales y otra para los requerimientos no funcionales.
Un esquema del atributo es un conjunto de propiedades que pueden ser asignadas a un tipo de requisito. En cada proyecto es posible definir uno diferente según sus necesidades de información.
Asignación de los atributos del requerimiento
En el siguiente ejemplo se establece una plantilla con un esquema que las personas del equipo del proyecto están asignando. Observa como incluyen los siguientes atributos: identificador, nombre, descripción, estabilidad, responsabilidad, fuente y autor.
Haz clic en cada atributo para conocer la información.
Atributo |
Descripción |
ID |
Identificador del requerimiento. |
Nombre |
Nombre descriptivo. |
Dependencias |
Opcional, si existe dependencia de otros requerimientos. |
Descripción |
Descripción detallada y completa del requerimiento. |
Estabilidad |
Probabilidad de cambio. |
Importancia |
Importancia que tiene el requerimiento para el cliente. |
Estado |
Estado del ciclo de vida del requerimiento. |
Comentarios |
Comentarios adicionales. |
Autor |
Nombre de la persona que define el requerimiento. |
Ciclo de vida del requerimiento
Imagen obtenida de http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/409#Estabilidad Sólo para fines educativos.
Observa que un requerimiento puede pasar a un estado de Eliminado en cualquier momento si se encuentra en la etapa En desarrollo y cuando es parte del proyecto En línea de base sólo puede pasar a Eliminado desde el estado Bajo cambio. En este diagrama es posible tener subestatus: En conflicto o Sin conflicto en relación a otros requerimientos.
Los estados por los que pasa un requerimiento son acordados entre el equipo de desarrollo y el cliente desde el inicio del proyecto.
12.2 Priorización de requerimientos
En un grupo de requerimientos extenso, donde la mayoría de ellos son importantes para el cliente, el atributo de priorización puede ser bastante útil. Sobre todo para proyectos que utilicen un modelo de desarrollo ágil en el que se pueda dividir las funcionalidades por módulos. Los requerimientos de mayor prioridad serían incluidos en las primeras iteraciones, mientras las de menor prioridad pueden ser aplazadas en las siguientes iteraciones.
La prioridad debe ser establecida por el responsable del proyecto por parte del cliente. Para ello puede realizar algunas sesiones de negociación con los stakeholders y el equipo de desarrollo.
Métodos de priorización.
Las organizaciones pueden tomar diferentes criterios para priorizar los requerimientos, entre ellos se encuentran los siguientes:
- Plan estratégico.
Ciertos desarrollos de software pueden ser parte del plan estratégico de la organización. Considera por ejemplo una empresa que desea colocar sus productos a través de una tienda virtual con el fin de abrir un nuevo canal de ventas que incremente sus actuales ingresos.
Seguramente las funcionalidades de e-commerce serán una prioridad para cumplir con su plan.
- Costo:
El costo estimado para elaborar un requerimiento puede ser un mecanismo de priorización. Es posible que algunos requerimientos impliquen un precio muy grande, ya sea en tiempo o en inversión, así que la mejor forma sería agrupar los que son importantes, que puedan cumplir con los objetivos de la organización.
- Riesgo:
Todo proyecto tiene riesgos y parte de la administración será realizar un ejercicio de estimación de los mismos. En uno relacionado al software los riesgos pueden ser los siguientes:
- Volatilidad de los requerimientos por los constantes cambios.
- Poca experiencia del stakeholder en este tipo de proyectos.
- Resistencia del usuario al cambio.
- Tecnologías de información en constante transformación.
- Posibles modificaciones en la normatividad vigente.
- Time to market de los nuevos productos muy corto.
- Fracasar en la implementación del proyecto.
El riesgo puede ser también un factor de priorización de requerimientos, aquellos a los que se les asigne un factor de riesgo alto para el proyecto podrían tener menos prioridad para el desarrollo del software.
Técnicas de priorización
Las siguientes técnicas las puedes utilizar para priorizar los requerimientos de una forma muy simple, incluso se recomienda utilizar varias para obtener un mejor resultado.
La clasificación o también llamada ranking es una técnica que permite ordenar de mayor a menor los requerimientos utilizando un criterio previamente acordado por los stakeholders. La técnica de top ten permite elegir los requerimientos más importantes, no necesariamente tienen que ser 10.
Esta técnica permite clasificar los requerimientos en tres grupos.
Obligatorio: debe ser incluido a cualquier costo porque puede poner en riesgo el éxito del proyecto.
Opcional: no necesariamente debe ser incluido. Un requerimiento opcional no pone en riesgo el éxito del proyecto.
Deseable: también conocido como nice to have. Es un requerimiento que pudiera ser ignorado y no afecta en nada al resultado del proyecto.
La clasificación del modelo propuesto por Kano es una forma muy sencilla de priorizar los requerimientos. Utiliza tres factores y pueden ser utilizados dentro del plan de liberación del sistema:
Insatisfactorios: aquellos requerimientos que si el sistema no los tiene provocarían insatisfacción a los clientes, en otras palabras, estarían decepcionados del producto.
Satisfactorios: un factor satisfactorio es aquel que el cliente demanda conscientemente. Es lo mínimo que espera de un producto, entre más de estos factores tenga un artículo, mayor será la satisfacción del consumidor. De carecer de ellos podría provocar que el cliente no lo acepte.
Deleite: Son aquellos requerimientos de los que el cliente no está consciente del nivel de satisfacción que le provocarán. El agrado del cliente se incrementa exponencialmente cuando el producto presenta este tipo de factores.
Representación gráfica del modelo Kano
Fuente: Pohl, K. y Rupp, C. (2011). Requirements Engineering Fundamentals. EE. UU.: Rocky Nook.
- Matriz de priorización de acuerdo con Wiegers
Esta técnica está basada en la siguiente matriz, que permite ponderar cada requerimiento en cuatro aspectos: beneficio, perjuicio, costo y riesgo. La ventaja es que reduce significativamente la subjetividad en relación a la importancia que se le asigne directamente. Observa cómo priorizan los siguientes requerimientos utilizando esta técnica:
Ponderación |
A) Peso (Beneficio)
Valor=2 |
A) Peso (Perjuicio)
Valor=1 |
|
|
A) Peso (Costo)
Valor=1 |
|
A) Peso (Riesgo)
Valor=0.5 |
|
|
|
B) REQ |
Beneficio relativo |
Perjuicio relativo |
Total |
Valor
% |
Costo relativo |
Costo
% |
Riesgo relativo |
Riesgo % |
K)Prioridad |
L)Rank |
R1 |
5 |
3 |
13 |
16.8 |
2 |
13.3 |
1 |
9.1 |
0.941 |
1 |
R2 |
9 |
7 |
25 |
32.5 |
5 |
33.3 |
3 |
27.2 |
0.692 |
3 |
R3 |
5 |
7 |
17 |
22.1 |
3 |
20.0 |
2 |
18.2 |
0.759 |
2 |
R4 |
2 |
1 |
5 |
6.5 |
1 |
6.7 |
1 |
9.1 |
0.577 |
4 |
R5 |
4 |
9 |
17 |
22.1 |
4 |
26.7 |
4 |
36.4 |
0.489 |
5 |
Total |
C) 25 |
D) 27 |
E) 77 |
F) 100 |
G) 15 |
H) 100 |
I) 11 |
J) 100 |
|
|
Pasos para establecer la prioridad Wiegers:
-
|
Determinar los pesos relativos de beneficio, detrimento, costo y riesgo. |
-
|
Determinar la lista de requerimientos a ser priorizados. |
-
|
Estimar el beneficio relativo. |
-
|
Estimar el detrimento relativo. |
-
|
Calcular los valores totales y porcentuales para cada necesidad:
Total (Ri)= Peso del Beneficio * Beneficio Relativo (Ri) + Peso del Perjuicio + Perjuicio Relativo (Ri). |
-
|
Calcular el porcentaje de cada requerimiento (Valor %). |
-
|
Estimar el costo relativo. |
-
|
Calcular el porcentaje del costo relativo. |
-
|
Estimar el riesgo. |
-
|
Calcular el porcentaje de riesgo relativo. |
-
|
Calcular las prioridades de requerimientos individuales:
Prioridad (Ri) = Valor% (Ri) / (Costo% (Ri) × Peso del Costo +% Riesgo (Ri) × Peso del riesgo).
Prioridad (R1)= 16.8 / ((13.3 x 1)+(9.1 x 0.5))= 0.941 |
-
|
Establecer el rango de cada requerimiento según el cálculo de la prioridad. |
12.3 Trazabilidad de los requerimientos
La trazabilidad o rastreabilidad, es la habilidad de ubicar el origen de los requerimientos durante el ciclo de vida del desarrollo del sistema.
Según Pohl y Rupp (2011) las ventajas de la trazabilidad de los requerimientos son:
En el siguiente esquema puedes observar cómo la descripción de un requerimiento de un sistema de localización GPS tiene un origen, puede ser dependiente de otro requerimiento y consecuencia de procesos posteriores.
Tipos de trazabilidad de requerimientos. Adecuación
Fuente: Pohl, K. y Rupp, C. (2011). Requirements Engineering Fundamentals. EE. UU.: Rocky Nook.
Representación de la trazabilidad
La trazabilidad puede ser representada de diferentes maneras, por ejemplo:
Es posible incluir los identificadores de cada requerimiento en los documentos a los que se haga referencia. Por ejemplo, la información de un caso de prueba podría incluir el grupo de identificadores de los requerimientos involucrados en el proceso de verificación.
Usar hipervínculos es otra forma de representar la trazabilidad, ya que es posible marcar textos en los que haga referencia a un requerimiento en particular.
Una matriz de trazabilidad es muy útil cuando existen requerimientos relacionados con otros del mismo proyecto o uno diferente. Se marcan en la matriz junto con los requisitos dependientes. Un ejemplo es el siguiente:
|
P01.Req-01 |
P01.Req-02 |
P01.Req-03 |
P02Req-04 |
P02.Req-05 |
P01.Req-01 |
|
D |
|
|
|
P01.Req-02 |
|
|
R |
|
|
P01.Req-03 |
|
|
|
|
R |
P01.Req-04 |
|
|
R |
|
|
P01.Req-05 |
D |
|
|
|
|
Observa que algunos requerimientos dependientes se marcan con una D, mientras los relacionados son señalados con una R. En este caso, el requerimiento 01 del proyecto 01, está relacionado con el requerimiento 05 del proyecto 02.
La trazabilidad se puede dibujar utilizando grafos, cada nodo representa el contexto, el requerimiento y el componente, mientras las líneas definen la trazabilidad.
