A la hora de definir los requisitos de información de un sistema, cuando trabajamos en entorno no ágiles, es necesario definirlos teniendo en cuenta una serie de puntos. Si no se cumplen esos puntos nos podemos encontrar con que el sistema no cumple con las necesidades del cliente o que son difíciles de gestionar. ¿Te has encontrado alguna vez en esa situación? En caso afirmativo, seguro que te es interesante este post.
Índice de contenidos
¿Cómo debe ser la definición de los requisitos de información de un sistema?
Para evitar que un sistema no cumpla con las características exigidas por el cliente o que puedan surgir dificultades en la gestión de los mismos, es recomendable que cumpla con una serie de premisas o puntos.
Debe tener definido un código
Es recomendable que tenga un código asignado para hacer un seguimiento más efectivo de la trazabilidad de requisitos frente a casos de prueba. Es aconsejable indicar un código representativo tipo, por ejemplo: REQF001 o REQNF005. De esta forma podemos diferenciar los requisitos funcionales de los no funcionales (F=Funcional, NF= No funcional). Por ejemplo:
| REQNF-0001 | Visualización Acceso a área privada |
|---|---|
|
V.1.0 |
El sistema debe mostrar una pantalla en la que solo mostrará el menú legal y un formulario de acceso en la zona centrar de la pantalla con los campos de usuario y contraseña. Además, debe mostrar un enlace a Recordar contraseña y el botón de "iniciar sesión". |
|
RELACIONES |
REQF-0010 |
Completo
Debe especificar de forma completa toda la característica que se desea implementar en el desarrollo, incluyendo las posibles excepciones u opciones alternas en las que se pueden suceder. Por ejemplo:
| REQF-0030 | Visualización al inicio de sesión en el sistema |
|---|---|
|
V.1.2 |
Al iniciar sesión en el sistema, el usuario podrá ver las novedades de contenidos que puede visualizar según su rol, un mensaje emergente con las notificaciones del sistema y el listado de las comunicaciones y tareas pendientes. |
|
RELACIONES |
REQF-0001 |
|
EXCEPCIONES |
1) Si el usuario tiene una tarea crítica a realizar, se mostrará un mensaje emergente y se sombreará el resto del área privada con gris, permitiéndole solo realizar esa tarea crítica y ninguna acción más dentro del sistema.
2)Si el usuario no tiene definido su rol, se mostrará un mensaje emergente y se sombreará el resto del área privada con gris, permitiendo no hacer ninguna acción dentro del sistema y mostrándole un mensaje informativo para que contactar con el administrador para solucionar la incidencia. |
Requisitos de información de un sistema donde la versión no puede faltar
De igual forma, para hacer un seguimiento de la trazabilidad es necesario indicar la versión del requisito. De tal modo, se asegura poder hacer un correcto seguimiento de los cambios en los requisitos, para aplicar los cambios correspondientes en los casos de prueba asociados y evitar que se escape una especificación del sistema que ha sido modificado posteriormente. Como hemos podido ver en los ejemplos anteriores.
Debe tener indicadas las relaciones
Como he indicado en los puntos anteriores, es importante poder seguir la trazabilidad de los cambios necesarios a realizar en el desarrollo o en los casos de prueba cuando el cliente solicita cambios. Por ello, es relevante conocer las relaciones entre unos y otros requisitos y la relación que estos tienen con los casos de prueba u otros elementos de la descripción del sistema, como son los casos de uso o los bocetos de diseños. De esta forma, en la definición del requisito hay que añadir un elemento para las relaciones. Por ejemplo:
| REQF-0001 | Acceso a área privada |
|---|---|
|
|
El sistema debe permitir el acceso a área privada con credenciales de acceso: usuario y contraseña. |
|
RELACIONES |
REQF-0010, REQF-0011, REQF-0012, REQF-0013 |
Descripción clara, concreta, concisa y consistente
Se debe evitar la literatura y ser transparentes, específicos, concretos y objetivos en la definición del requisito. De esta forma, se evitan errores, dudas en cuanto a lo que se requiere. También debe ser consistentes con respecto a lo que se solicita, en relación con otros requisitos. En el siguiente ejemplo, puedes ver como sería.
| REQF-0010 | Credencial de acceso Consultas |
|---|---|
|
|
El sistema debe permitir que el usuario con el acceso de CONSULTAS pueda ver el contenido de todos los tipos de contenidos del sistema con NIVEL BAJO RESTRINGIDO. No podrá visualizar ningún contenido de tipo NIVEL MEDIO RESTRINGIDO, ni NIVEL ALTO RESTRINGIDO. |
|
RELACIONES |
REQF-0001, REQF-0050, REQF-0051, REQF-0052, REQF-0053 |
Y por último, es necesario que tenga un histórico
Aunque en este post he documentado los requisitos de información de un sistema en formato de tabla, la realidad es que hoy en día se suelen almacenar en formato digital. Por ello, es común que acompañando la versión del requisito se indique una nota especificando a qué fue debido y normalmente también almacena la fecha y hora en la que se realizó el cambio.
Conclusión: requisitos de información de un sistema deben estar cerrados para un desarrollo de calidad y éxito
Es vital que se tenga claro los requisitos de información de un sistema para lograr el éxito del desarrollo y que este sea de calidad. Por desgracia, son suficientes los proyectos que realizan un correcto análisis de los requisitos, para iterar sobre esta definición y con ello aclarar y concretar los mismos.
Desde la dirección de los proyectos se debe tener claro que esta falta de especificación acarrea mucho retrabajo que se traduce en pérdidas económicas. Se debe exigir al cliente una definición escrita lo más clara posible y planificar sesiones de trabajo para aclarar esos puntos. De igual forma, recomiendo la asistencia a esas reuniones del Equipo QA, ya que su visión puede ser un elemento de valor en el análisis de esos requisitos. Gracias al análisis estático de la documentación, podemos detectar errores de forma temprana y mejorar la productividad de nuestros equipos.
