La gestión de requisitos es un enfoque sistemático para encontrar, documentar, organizar y hacer el seguimiento de los
requisitos cambiantes de un sistema.
Definimos un requisito como:
Una condición o capacidad que debe cumplir el sistema.
La definición formal de gestión de requisitos es: propuesta sistemática para lo siguiente:
-
Obtener, organizar y documentar los requisitos del sistema
-
Establecer y mantener un acuerdo entre el cliente y el equipo del proyecto sobre el cambio de requisitos del
sistema
Las claves para la gestión eficaz de requisitos incluyen el mantenimiento de una sentencia clara de los requisitos, junto con atributos aplicables para cada tipo de
requisito y rastreabilidad a otros requisitos y otros productos de trabajo del proyecto.
Puede que la recopilación de requisitos suene como una tarea bastante sencilla. Sin embargo, en los proyectos reales,
se encontrará con dificultades, porque:
-
Los requisitos no siempre son obvios y pueden tener muchos orígenes.
-
No siempre es fácil expresar los requisitos con claridad en palabras.
-
Hay muchos tipos diferentes de requisitos con niveles diferentes de detalle.
-
Si no se controla, el número de requisitos puede llegar a ser ingestionable.
-
Los requisitos están relacionados entre sí y también con otros productos de trabajo del proceso de ingeniería de
software.
-
Los requisitos tienen valores de propiedad o propiedades exclusivas. Por ejemplo, no tienen la misma importancia ni
resulta igual de fácil satisfacerlos.
-
Hay muchas partes interesadas, lo que implica que los requisitos deben gestionarse por grupos de personas de
funciones cruzadas.
-
Cambio de requisitos.
¿Qué habilidades es necesario desarrollar en la empresa para ayudarle a gestionar estas dificultades? Sabemos que es
importante dominar las siguientes habilidades:
El análisis de problemas se realiza para entender los problemas y las necesidades iniciales del interesado, y proponer
soluciones de alto nivel. Es un acto de razonamiento y análisis para encontrar "el problema que se esconde tras el
problema". Durante el análisis de problemas, se debe llegar a un acuerdo sobre cuál es el problema real y quiénes son
los interesados. También debe definir cuáles son, desde una perspectiva empresarial, los límites de la solución y las
restricciones empresariales de la solución. Además, debe haber analizado el caso de negocio del proyecto para que haya
un buen conocimiento de qué rentabilidad se espera de la inversión realizada en el sistema que se está construyendo.
Consulte también el apartado Actividad: Analizar el problema.
Los requisitos provienen de muchos orígenes; por ejemplo, clientes, socios, usuarios y expertos en dominios. Debe saber
cómo se determina mejor cuáles deberían ser los orígenes, cómo se obtiene acceso a estos orígenes y cómo se obtiene
información de ellos. Los individuales que proporcionan los orígenes principales de esta información se conocen como
interesados en el proyecto. Si va a desarrollar un sistema de información para uso interno de la empresa, puede incluir
personas con experiencia de usuario y especialista en dominios empresariales en el equipo de desarrollo. Con mucha
frecuencia, las discusiones empezarán en el nivel de modelo empresarial, en vez de en el nivel del sistema. Si va a
desarrollar un producto para venderlo en un mercado, recurra constantemente al personal de marketing para conocer mejor
las necesidades de los clientes de dicho mercado.
Las actividades de obtención pueden realizarse con técnicas como entrevistas, tormenta de ideas, creación de prototipos
conceptuales, cuestionarios y análisis competitivo. El resultado de esta actividad debe ser una lista de solicitudes o
necesidades descritas textual y gráficamente, y que se han priorizado relativamente entre sí.
Consulte también el apartado Actividad: Conocer las necesidades del
interesado.
Definir el sistema significa convertir y organizar el conocimiento de las necesidades del interesado en una descripción
significativa del sistema que se va a construir. Al principio de la definición del sistema, se toman decisiones sobre
qué constituye un requisito, formato de documentación, formalidad del lenguaje, grado de especificación de los
requisitos (cuántos hay y qué grado de detalle tienen), prioridad de solicitud y esfuerzo calculado (dos valoraciones
muy diferentes normalmente asignadas por personas diferentes en ejercicios separados), riesgos técnicos y de gestión y
ámbito inicial. Parte de esta actividad puede incluir primeros prototipos y modelos de diseño relacionados directamente
con las solicitudes de interesados más importantes. El resultado de la definición del sistema es una descripción del
sistema gráfica y en lenguaje natural.
Consulte también el apartado Actividad: Definir el sistema.
Para ejecutar eficazmente un proyecto, debe priorizar los requisitos cuidadosamente, en función de la entrada de todos
los interesados, y gestionar el ámbito. En muchos proyectos, los desarrolladores se dedican a trabajar en los conocidos
"huevos de pascua" (funciones que el desarrollador considera interesantes y desafiantes), en vez de centrarse en tareas
que mitiguen un riesgo del proyecto o estabilicen la arquitectura de la aplicación. Para asegurarse de que elimina o
mitiga los riesgos de un proyecto lo antes posible, debe desarrollar el sistema incrementalmente, escogiendo
cuidadosamente los requisitos de cada incremento que mitigue riesgos conocidos del proyecto. Para ello, debe negociar
el ámbito (de cada iteración) con los interesados en el proyecto. Esto suele requerir buenas habilidades para gestionar
las expectativas de resultado del proyecto en las diferentes fases. También debe controlar los orígenes de requisitos,
el aspecto que tienen los productos de trabajo del proyecto y el propio proceso de desarrollo.
Consulte también el apartado: Actividad: Gestionar el ámbito del
sistema.
La definición detallada del sistema debe presentarse de manera que los interesados la entiendan, estén de acuerdo con
ella y la den por terminada. La definición no debe incluir únicamente las funciones, sino también la conformidad con
los posibles requisitos legales o reguladores, la utilización, la fiabilidad, el rendimiento, la capacidad de soporte y
el mantenimiento. Uno de los errores que se cometen es creer que lo que es difícil de construir debe tener una
definición compleja. Esta idea lleva a dificultades a la hora de explicar el objetivo del proyecto y el sistema. Es
posible que las personas se quedan impresionadas, pero no aportarán nada adecuado porque no entienden la definición.
Debería esforzarse mucho en conocer a los receptores de los documentos que está creando para describir el sistema. Es
posible que a menudo considere necesario crear diferentes clases de descripciones para receptores diferentes.
Hemos visto que la metodología de casos de uso, a menudo combinada con prototipos visuales simples, es una manera muy
eficaz de comunicar el objetivo del sistema y definir sus detalles. Los casos de uso ayudan a colocar los requisitos en
un contexto; cuentan una historia sobre cómo se utilizará el sistema.
Otro componente de la definición detallada del sistema es la especificación de cómo se probará el sistema. Las
definiciones y los planes de prueba de qué pruebas se deben realizar nos indican las capacidades del sistema que se
verificarán.
Consulte también el apartado Actividad: Perfeccionar la definición del
sistema.
Independientemente de lo cuidadoso que sea a la hora de definir los requisitos, siempre tendrá que cambiar algo. Los
requisitos cambiantes son difíciles de gestionar no sólo porque un requisito cambiado implique más o menos tiempo
invertido en la implementación de una función nueva en particular, sino también porque un cambio en un requisito puede
afectar a otros requisitos. Debe asegurarse de que proporciona a los requisitos una estructura resistente a los cambios
y que utiliza enlaces de rastreabilidad para representar dependencias entre requisitos y otros productos de trabajo del
ciclo de vida de desarrollo. La gestión de cambios incluye actividades como establecer una línea base, determinar qué
dependencias es importante rastrear, establecer la rastreabilidad entre elementos relacionados y el control de cambios.
Consulte también el apartado Actividad: Gestionar requisitos cambiantes.
Puede encontrar más información sobre este tema en:
Concepto: Requisitos
Concepto: Tipos de requisitos
Concepto: Rastreabilidad
Documentación: Aplicación de la gestión de requisitos con casos de uso
|