Por Ana Bescós Domínguez
La extracción o captura de los requisitos del sistema es una de las fases más críticas e importantes en el desarrollo de software.
"Lo más difícil en la construcción de un sistema software es decidir precisamente qué construir".
F.P. Brooks, 1987.
Importancia
Cuando se entrevista a un candidato para el puesto de analista funcional y se le pregunta por las cualidades más importantes del puesto; muy pocas personas mencionan la captura de requisitos y sus técnicas de extracción como uno de los momentos más importantes en la definición de los requisitos del software. Muchos se centran en hablar más de cómo se plasman y definen los requisitos: mediante lenguaje natural, diagramas de casos de uso, historias de usuario, etc., pero ninguno o casi ninguno menciona la importancia de extraer todos y cada uno de los requisitos de los distintos usuarios o personas implicadas en el sistema.
Distintos estudios y expertos en la ingeniería de requisitos coinciden en que la captura de requisitos es una de las fases más críticas para el éxito de un proyecto de software. Esto se debe a que el coste de subsanación de un error en los requisitos o malinterpretación de estos en la fase de análisis requiere viente veces menos esfuerzo que la subsanación del error en fase de pruebas unitarias, cincuenta veces menos que subsanarlo durante las pruebas de integración, y del orden de doscientas veces menos esfuerzo que tener que subsanarlo una vez que el sistema se encuentra en fase de explotación.
Objetivos
La fase de captura de requisitos tiene como objetivo descubrir y recoger todos y cada uno de los requisitos funcionales y no funcionales de la aplicación a definir de forma clara y concisa. Entendiendo esta tarea de captura de requisitos como un proceso proactivo por parte del analista funcional, para entender los requisitos del sistema a desarrollar, ya que para ello necesitará extraer los requisitos de los usuarios y ayudarles a visualizar las posibilidades de la solución.
Hay que resaltar que esta actividad de descubrimiento de los requisitos es una tarea más "humana" que técnica, ya que la mayor parte de las veces los usuarios no serán capaces de definir todos los requisitos, o de definirlos completamente. De ahí que la capacidad del analista funcional para extraer el qué del cómo y detectar aquellos requisitos implícitos o que se dan por hecho por parte de sus interlocutores es clave, además de que esta tarea no es sólo responsabilidad del analista funcional, sino que se trata de una tarea de colaboración entre éste y los distintos implicados en la definición del sistema.
Técnicas
Para el éxito en la captura de requisitos el analista funcional necesitará poner en práctica distintas técnicas y probablemente varias iteraciones de este proceso, de forma que se vayan refinando y completando los requisitos obtenidos.
- Estudio de documentación existente: análisis de la documentación existente sobre el proyecto y su alcance (RFP, oferta y cualquier otra información o documento existente sobre el producto a construir: manuales, informes, etc.) La documentación es un buen punto de partida para entender el sistema a implementar e identificar áreas a clarificar. También nos ayuda a familiarizarnos con la aplicación y su terminología, y hará que nuestras entrevistas y talleres con los usuarios sean más eficientes y enfocadas a aclarar ciertos aspectos.
- Entrevistas con las distintas personas y roles involucrados en el proyecto: en estas sesiones se entrevistará individualmente a roles distintos de entre los interlocutores del proyecto. Es importante entrevistar a las personas adecuadas y preparar las preguntas o temas a tratar con antelación. En momentos iniciales de la captura de requisitos utilizaremos preguntas abiertas para ir paulatinamente hacia preguntas más cerradas.
- Talleres o sesiones de trabajo en grupo: se pueden utilizar cuando el tiempo del que disponemos para capturar los requisitos es ajustado, ya que mediante esta técnica podemos entrevistarnos con más personas al mismo tiempo. Aunque habrá que asegurarse de que todos los involucrados participan y se sienten confiados para expresar sus opiniones, preocupaciones, problemas, etc.
- Observación: consiste en observar las distintas tareas y procesos ejecutados por distintos roles en su día a día. De esta manera, se confirma el modo real en que se siguen los procesos establecidos, confirmando que se ejecutan todos sus pasos.
- Prototipado: consiste en una demo o versión reducida de la aplicación a desarrollar. Suele ser útil cuando la solución es muy novedosa y los implicados en el proyecto son incapaces de definir sus requisitos. Los prototipos se suelen usar como punto de partida sobre el que presentar una posible solución, e ir refinándola y obteniendo más requisitos de los usuarios tras su revisión. Es importante que le traslademos al cliente que los wireframes no son un reflejo de cómo serán los interfaces a nivel de diseño ni de experiencia de usuario.
- Cuestionarios: el uso de cuestionarios permite cubrir a un grupo más grande de personas para reunir información sobre el sistema. El anonimato de los encuestados ayuda a obtener respuestas más honestas, y es un buen método para solicitar la opinión de los encuestados sobre los problemas, limitaciones y mejoras posibles. Normalmente, se necesita que el promotor del proyecto se involucre para asegurar que obtenemos el mayor número de respuestas posible. Se deben seleccionar encuestados de distintas áreas de conocimiento del sistema y con distinta experiencia y roles.
- Inception sprint: Es una de las técnicas que usamos en atSistemas para definir conjuntamente un nuevo producto o solución. Más información en este artículo.