05.03.- Recogida y desarrollo de requisitos
1.- OBJETIVOS
El objetivo del proceso de recogida y desarrollo de requisitos es comprender las necesidades de los usuarios y trasladarlos a un conjunto de especificaciones que permitan valorar con suficiente precisión el tamaño y los costes del proyecto.
Lo ideal es que el resultado sea indiferente a la tecnología concreta (sistema gestor de base de datos, lenguaje de programación, sistema operativo del servidor e incluso arquitectura del sistema) sobre la que se va a desarrollar el proyecto.
A partir de los requisitos desarrollados, también llamado diseño funcional, hay que poder medir el tamaño del software a desarrollar en puntos función, estimar las inversiones en hardware, software y comunicaciones requeridos por el sistema, y por tanto el coste económico y los plazos de entrega.
2.- DEFINICIONES
Requisito (s/DRAE): Circunstancia o condición necesaria para algo.
Requisitos funcionales: Comportamientos que debe tener el sistema ante cada estímulo externo. También denominados "casos de uso". Incluimos también las características de usabilidad, presentación u otras que sean relevantes desde el punto de vista del usuario final.
Requisitos técnicos u operativos: Características que debe tener el sistema relativas a su operación en producción. Pueden ser de disponibilidad, flexibilidad, tiempos de respuesta, soporte, etc..
3.- PRINCIPIOS
Impacto. Un error o laguna en la recogida de los requisitos va a tener un impacto en el coste y plazo del proyecto mucho mayor que otro que se produzca en fases posteriores de desarrollo, prueba o implantación.
Trazabilidad. Es esencial mantener la trazabilidad entre los requisitos y los "artefactos" que deberán darles cobertura. De esta forma será más fácil evaluar el impacto de un cambio en los requisitos o de una dificultar en la incorporación de un determinado artefacto.
4.- SUBPROCESOS / PRACTICAS / ACTIVIDADES / TAREAS
4.1.- Recogida de requisitos funcionales
Consiste en averiguar el resultado que los usuarios relevantes o las áreas de negocio esperan del proyecto, en términos de funcionalidad o comportamiento del sistema a desarrollar o integrar.
Para ello se utilizarán procedimientos como:
- las entrevistas a las personas significativas
- el análisis crítico del sistema anterior (si lo hay)
- la búsqueda de información sobre sistemas de competidores, colegas u otras industrias
El resultado se documentará en un documento de requerimientos preliminar que se distribuirá a los interesados para su revisión.
4.2.- Análisis de alternativas de soluciones que puedan cumplir los requisitos y las infraestructuras tecnológicas para el desarrollo, integración y explotación.
A medida que se van recogiendo y comprendiendo los requisitos funcionales, hay que ir evaluando las posibles fórmulas alternativas, como son:
- Evolucionar los sistemas existentes en la organización
- Adquirir productos software (y/o en su caso hardware) ya existentes, en las variantes de "software libre" o comercial
- Realizar un desarrollo propio
- Una combinación de los tres anteriores
El análisis de las diferentes alternativas puede llegar a ser muy complejo pero es siempre crítico para un enfoque óptimo del proyecto.
Simultáneamente a la búsqueda de la mejor solución (normalmente software), se analizarán las infraestructuras necesarias para cada una de las posibles soluciones, de forma que se pueda evaluar su disponibilidad, coste, fiabilidad, necesidades de formación, y demás características relevantes para el proyecto.
4.3.- Estudio de viabilidad o anteproyecto
A partir de los requerimientos preliminares y del análisis de alternativas e infraestructuras se confeccionará un documento de anteproyecto. En él se deberá verificar la viabilidad en términos de resultados y costes esperados frente a los requisitos planteados y las disponibilidades de recursos.
En su caso se deberá elevar a la dirección u órganos de gobierno procedentes para su aprobación, adecuación o cancelación.
4.4.- Diseño del modelo de datos , entradas y salidas e interfases
Dentro de este proceso es fundamental disponer de un diseño suficientemente detallado de estos elementos de un sistema de información que incluya el desarrollo de software. En ocasiones puede ser necesario añadir algún otro componente crítico como pueden ser algoritmos especialmente complejos u otros.
El nivel de detalle ha de ser suficiente para poder estimar con razonable precisión el coste y plazo de desarrollo. En el proceso de diseño de la solución se llegará al detalle completo.
Por ejemplo, en el caso del modelo de datos habrá que conocer las principales entidades de datos, sus atributos esenciales y relaciones entre ellas, pero no hará falta asignar el nombre final de cada dato, su tipo exacto, etc..
4.5.- Definición de requisitos de seguridad y operación
Algunas de las características que hay que identificar en este proceso serían:
- Volúmenes esperados de datos, transacciones, y demás parámetros de operación
- Necesidades de encriptación de datos y comunicaciones
- Requisitos de disponibilidad y continuidad de negocio
- Tiempos de respuesta
- Escalabilidad ante incrementos súbitos de operación
- Necesidad de soporte a usuarios
4.6.- Análisis de riesgos
Se documentarán los riesgos de las soluciones evaluadas, no del proyecto en sí, dado que se incluye en el proceso de Gestión de Proyectos. Por ejemplo, si se evalúa la posibilidad de adquirir una aplicación comercial, hay que valorar el riesgo de que el fabricante pueda dejar de mantenerlo o evolucionarlo.
4.7.- Prototipado
Aunque no siempre es posible, la construcción de un prototipo del sistema que simule de una forma verosímil el funcionamiento previsto es una herramienta muy útil para asegurar que los requisitos funcionales se han captado correctamente.
Ayuda a prevenir en gran medida posteriores cambios en los requisitos o decepciones de los usuarios.
4.8.- Determinación del tamaño del software
Un objetivo básico del proceso consiste en llegar a determinar el tamaño del software a crear o modificar (en los proyectos que incluyen desarrollo o mantenimiento de software). El tamaño se medirá en puntos funcion, métrica que no es perfecta, pero es la menos mala de las conocidas a la fecha.
Una vez conocidos los puntos-función a desarrollar, modificar o sustituir, se realizará la planificación del proyecto (ver proceso de Planificación y Gestión del Proyectos).
En pequeños proyectos (normalmente de menos de 100 puntos-función) la exactitud de esta métrica es insuficiente, por lo que resulta inevitable estimar en términos de "componentes". Para ello hay que disponer de un catálogo de componentes estándar con la experiencia histórica de lo que cuesta crearlos o modificarlos en la organización.
4.9.- Aprobación de los requisitos por los interesados y la dirección
Como paso final del proceso se obtendrá (y documentará formalmente) la aprobación de los requisitos y la planificación del proyecto de parte de la dirección de la organización, los usuarios, clientes o personas interesadas en el proyecto que proceda.
Según las circunstancias de coste, criticidad y riesgos, puede ser necesario obtener esta aprobación en dos pasos, primero con el anteproyecto y luego con el proyecto completo.
4.10.- Gestión de cambios en los requisitos en fases posteriores de los proyectos
Este es un aspecto vital de este proceso, dado que los cambios en requisitos cuando ya se está desarrollando (y no digamos si se está probando o implantando) son el factor que más incrementa el coste, plazo y riesgo de fracaso de un proyecto.
Cuando se produce un cambio de requisitos hay que asegurar que se documenta, evalúa y aprueba (o no) con un procedimiento firmemente establecido.
Se debe vigilar el volumen de estos cambios en el conjunto de proyectos que ejecuta la organización de TI, asegurando un porcentaje de cambios acotado.
Sería utópico pensar que ningún proyecto sufriera un cambio de requisitos en fases posteriores, pero en nuestra experiencia, un límite del 10 % de promedio en los cambios resulta razonable.
5.- HERRAMIENTAS / PRODUCTOS
- Plantillas de documentación
Anteproyecto
Requisitos funcionales
Modelo de datos
Entradas y salidas
Interfases
Matriz de trazabilidad de requisitos con componentes del diseño
- Actas de reuniones y entrevistas
- Gestor de contenidos con versiones, autorizaciones y workflows (Drupal, Joomla, etc..)
6.- METRICAS
El aspecto más importante a medir es la variación de los requisitos finales respecto a los iniciales en términos de impacto en el coste (revisado vs. inicial).
7.-EN LOS MODELOS
7.1.- En CMMI
En el modelo CMMI/DEV y en el CMMI/SRV se incluye el área de proceso de nivel 2 "REQM - Gestión de requisitos".
Las prácticas de este área son:
- Obtener y comprender los requisitos
- Obtener el compromiso con los requisitos
- Gestionar los cambios
- Mantener la trazabilidad bidireccional
- Identificar inconsistencias entre el trabajo del proyecto y los requisitos
En nuestra opinión este último objetivo es un poco dudoso, dado que será objetivo de los procesos de diseño e ingeniería ajustarse a los requisitos.
En el modelo CMMI/DEV se incluye además el area de proceso de nivel 3 "RD - Desarrollo de requisitos"
Aunque no queda demasiado claro, este proceso pretende profundizar en el análisis de requisitos para trasladarlos a componentes concretos del sistema de manera que si en "gestión de requisitos" había que "obtener" los requisitos de sus "proveedores", aquí dice que hay que "extraerlos".
Los objetivos y prácticas definidos son notablemente redundantes y confusos, definiendo por ejemplo que hay que identificar los requisitos de interfases pero no los de datos ni entrada/salida, lo que nos parece una inconsistencia.
7.2.- En ITIL
En el libro II de ITIL V3 se recoge la "actividad relacionada con la tecnología" denominada "Ingeniería de Requerimientos" (capítulo 5.1). No lo considera un proceso de gestión de TI sino una actividad técnica, con lo que parece darle una importancia menor.
Divide los requerimientos en tres tipos, funcionales, operaciones y de gestión y, por último, de usabilidad. En nuestra opinión los requisitos que denomina de usabilidad estarían perfectamente entre los funcionales. Entre los requisitos operacionales incluye tanto algunos acertados (disponibilidad, seguridad, etc..) con otras cuestiones que normalmente no se plantean como tales requisitos, sino que se calculan a partir de ellos. Por ejemplo, el esfuerzo requerido para la instalación o las necesidades de recursos.
Acertadamente, incluye los requerimientos de soporte a los usuarios, que es algo que frecuentemente se olvida.
Describe someramente algunas técnicas para la recogida y desarrollo de requisitos, así como los problemas que ocasiona una práctica deficiente.
Enuncia la conveniencia de numerar los requerimientos para permitir la trazabilidad y las referencias cruzadas, así como la gestión de la documentación y sus cambios.
7.3.- En COBIT
No existe un proceso con este mismo nombre. Es asimilable el proceso "AI1 - Identificar Soluciones Automatizadas", que incluye no sólo recoger los requisitos del negocio, sino también evaluar las diferentes alternativas, hacer un análisis coste-beneficio y adoptar la decisión fundamental de comprar o desarrollar.
Como es típico, enfoca el proceso en el análisis de alternativas, riesgos y controles.
7.4.- Otros modelos o normas
Sin referencias significativas
8.- REFERENCIAS
8.1.- Bibliografía
Sin referencias significativas
8.2.- Legislación
Sin referencias significativas
8.3.- Sitios web
Sin referencias significativas
Versión en PDF