Tipos de requerimientos a tener en cuenta

14 05 2008

Hace varios días leí un artículo de Tyner Blain donde mencionaba que existían formas de calificar o verificar los requerimientos, pero que sin embargo no existían formas de verificar que estuvieran todos los requerimientos especificados, es decir que todos los requerimientos de alguna manera estuvieran escritos (bien o mal).

Aunque no podemos garantizar que les extraeremos el total de información o requerimientos a los usuarios podemos establecer pautas básicas que sobre cualquier sistema debemos cubrir, y estos son:

Configuración

Configuración

En todo sistema los usuarios de alguna manera necesitarán realizar configuraciones al mismo. Es en esta parte donde debemos incluir aquellos requerimientos que se focalizan en los denominados “maestros”. Dependiendo del tipo sistema pueden ser simples o complejos, pero independiente de esto se tendrá alguna configuración que realizar para el adecuado comportamiento funcional del sistema.

Mantenimiento

Algo que muy a menudo pasa es que pensamos en sistemas desechables, es decir, creamos sistema para 2 o 3 años de vida, y decimos que en ese tiempo seguramente ya no existirá o lo habrán cambiado. Sin embargo nos olvidamos que a los sistemas hay que realizarles mantenimiento para que su funcionamiento sea el adecuado.

Es bastante difícil que los usuarios expresen estos requerimientos y mas que sepan que decir si se les pregunta al respecto, pero dependiendo (como siempre del negocio) es necesario evaluar a que se le debe hacer mantenimiento. Ejemplos:

  • Si tenemos un requerimiento no funcional, en el cual se diga que toda transacción debe dejar un LOG con XXXX, YYY, ZZZ información, un requerimiento de mantenimiento es que el sistema realice una limpieza cada T tiempo de dicha información.
  • Si se tiene un requisito de manejo de seguridad (usuarios y contraseñas) y que se debe registrar cada vez que el usuario ingresa a la aplicación, se puede tener un requerimiento de mantenimiento donde el sistema evalúe cuales usuarios no han ingresado en un determinado tiempo y los puede borrar o inactivar

Soporte

Muchos de los requisitos de soporte son tomados como requisitos no funcionales. Estos requisitos se refieren a las formas en el que el sistema puede apoyar las novedades sobre el mismo y sobre el “negocio”. Dentro de este tipo de requerimientos podemos encontrar requisitos de seguridad (encriptación y desencriptacion de cadenas de conexión), manejo de mensajes de error detallados (archivos de texto, visor de sucesos, base de datos), manejo de diferentes idiomas, alertas ante caídas del sistema, etc. Por lo general este tipo de requisitos no se discuten con el usuario funcional, sino con el usuario técnico asociado.

Negocio

Pues si cubrimos ya la parte “no importante” de un sistema, no hay que dejar de lado la esencia del negocio, y es aquí donde podemos fallar en la no elicitación de lo requisitos. Para este tipo de requerimientos no existe sino pegarnos de las diferentes técnicas de elicitación. También hay que ser responsables y que dependiendo de la magnitud del proyecto una persona con poca experiencia vaya a una reunión de elicitación solo. Para este tipo de requerimientos lo que se puede hacer para cubrir todos los requerimientos es hacer listas de verificación de completitud de entrega de información y estas deberían ser llenadas al final de cada reunión de elicitación

Más adelante trataré de dar más ejemplos sobre cada uno de estos tipos de requerimientos

Cuídense


Acciones

Información

Un comentario

26 06 2008
igarcerant

Un segundo… ¿no son estos requerimientos no funcionales recogidos en el documento de requisitos suplementarios?

Un proceso de identificación de requisitos no puede limitarse a los requerimientos funcionales contenidos en los casos de uso activados por los principales y más evidentes actores.

En cualquier caso, en una organización seria se tienen marcos de referencia que definen muchas (aún más que las comentas) categorías de requisitos que deben ser evaluados para ver si en un proyecto especifico hay algo que decir al respecto.

Ejemplos? Seguridad, recuperación de errores, capacidad de carga de trabajo, velocidad, tiempos mínimos y máximos, criterios de calidad, etc.

Ahora que eso sí, el post te ha quedado muy bien. Mis felicitaciones.

Deja un comentario