Jose María González López
Project manager y co-fundador de Habilis Software
¿Qué es un requisito?
Un requisito, casi desde cualquier punto de vista, es una entidad que describe alguna característica en concreto que un producto, un proceso o un proyecto debe de cumplir para lograr la satisfacción de quien lo utiliza, compra o paga.
Aunque los requisitos, por su relación directa con el cumplimiento de necesidades del cliente, generalmente suelen estar centrados en su aplicación a un producto, pueden abarcar mucho más y también se emplean en la definición del cumplimiento de necesidades de un proyecto, de un proceso o simplemente de una estrategia definida.
Pero, aparte de su definición, ¿Qué es un requisito? O mejor aún: ¿Qué es un requisito de entre toda la información que normalmente un cliente pone en nuestras manos?
Modelo en V
La primera de las claves para poder extraer requisitos adecuadamente (y no unos cuantos...me refiero a TODOS) es saber involucrar a las partes adecuadas. Es necesario saber identificar a todas las partes proveedoras de requisitos y dotarles de herramientas y guías para poder expresar sus necesidades.
Al igual que en la gestión de las comunicaciones, cada parte interesada proveerá un nivel de exigencia y necesitará de un nivel adecuado de trabajo para que la gestión de sus necesidades sea efectiva. Es por eso que, a la hora de capturar información, es importante saber dar los pasos adecuados, al nivel adecuado.
Uno de los modelos más eficaces que conozco (y que, aparte de a la gestión de requisitos, puede aplicarse a casi cualquier forma de trabajo) es el modelo en V. En éste modelo, el flujo de trabajo se descompone en dos partes cuya forma gráfica componen una "V".
La vertiente izquierda o corriente de especificación, consiste en una especificación de grado de detalle creciente, orientada a la especificación del producto, sistema o proceso. La parte superior incluye procesos de carácter más general que la parte inferior. Aplicado a la captura de información y extracción de requisitos, ésta vertiente nos permite iniciar el proceso partiendo desde información (y requerimientos) más generales y que afectan a nivel de especificación e ir descendiendo por definiciones de arquitectura, hasta llegar a la base en la que estaríamos accediendo a diseños y especificaciones en detalle. Cada una de las cajas nos daría información y requisitos que se utilizarían en las siguientes cajas para iniciar el desglose de las mismas.
Ésta corriente se inicia desde la parte superior y finaliza en la base.
La vertiente derecha o corriente de pruebas, se inicia en la base y finaliza en la parte superior, permitiéndonos realizar las pruebas necesarias, las aceptaciones necesarias o las publicaciones necesarias como para que toda la información se pueda licitar.
Las dos vertientes son dependientes a nivel horizontal y permite relacionar cada una de los grados de especificación con cada uno de los grados de aceptación (o pruebas, según al ámbito al que se aplique). Cuanto más arriba nos encontremos en la V, más cerca estaremos de las partes más influyentes de nuestro proyecto, producto o proceso, mientras que, cuanto más abajo o cerca de la base, más cerca estaremos de la parte más técnica y con más capacidad de definición en detalle.
Obviamente, las partes interesadas se localizan en los niveles horizontales en función del grado de aportación que tengan.
Este sencillo modelo permite guiar y organizar la captura de información para la extracción de requisitos de manera muy eficaz, identificando en todo momento cual es el grado de información que estamos manejando. El modelo en V puede complicarse lo que se considere necesario.
Objetivos y consejos
Los objetivos de una correcta gestión de requisitos son, entre otros:
- Minimizar los riesgos del proyecto, producto o proceso.
- Mejorar y garantizar la calidad del mismo.
- Reducir los costes totales.
- Mejorar la comunicación entre las partes interesadas.
Algunos consejos a tener en cuenta:
- Un buen proceso de captura de requisitos debe de tener en cuenta que, los requerimientos deben de ser completos, consistentes y objetivos, así como testeables y viables en su realización.
- Utilizar un modelo estructural en la captura de información y usar técnicas de obtención de requisitos en el trato con el cliente.
- Formar a los analistas de requisitos en el ámbito de la información a analizar.
- Mantener viva la documentación de requisitos y su trazabilidad.
- Utilización de herramientas específicas para la gestión de requisitos.
Algunas herramientas para la gestión de requisitos
Hay muchas herramientas de Gestión de Requisitos, aunque la mayoría son soluciones comerciales y no integradas en el Ciclo de Vida de Desarrollo del proyecto. No obstante, gracias a las nuevas tecnologías, están haciendo aparición herramientas muy interesantes para la gestión de proyectos en plataformas móviles. Un ejemplo de estas herramientas lo tenemos en la familia PMP Mobile Suite para android, cuyo objetivo es acercar los dispositivos Android a la gestión de proyectos mediante herramientas independientes con una enorme capacidad de adaptación e integración y que, precisamente, están basadas en modelos en V y en la metodología PMI.
Enterprise architect (Herramienta CASE)
(http://www.sparxsystems.com/)
REM (Herramienta gratuíta experimental)
(http://www.lsi.us.es/descargas/descarga_programas.php?id=3)
PMP Mobile Suite, gestión de requisitos para Android
(https://play.google.com/store/apps/details?id=com.PMPMS.RM)