Algunos Analistas, por ejemplo, intentamos obtener retroalimentación de los usuarios, mientras que otros acuden a distintos interesados o a fuentes alternas de los requisitos, pero cuando no tenemos ese privilegio, simplemente hacemos suposiciones. Estas últimas pueden ser implícitas o explícitas. Las suposiciones explícitas son preferibles a las implícitas porque podemos validar aquellas posteriormente, mientras que las implícitas llegan a las fases de diseño e implementación con una alta probabilidad de estar erradas.
Ya sabemos que los requisitos de
software deben ser: correctos, precisos, completos, consistentes, clasificados,
verificables, modificables y trazables. Las especificaciones de requisitos
completas y correctas son las requeridas por los desarrolladores para saber qué
construir y por los usuarios para saber qué esperar. Una especificación de
requisitos de software completa debe incluir toda la información necesaria,
incluyendo restricciones y condiciones.
Ahora bien, independientemente de las
técnicas de recolección de requisitos, el involucramiento del usuario es un elemento
importante, ya que los requisitos vienen principalmente de las personas, no de
los documentos o los sistemas existentes. Los usuarios deben ser escuchados
cuidadosamente y nunca debemos hacer suposiciones implícitas puesto que estas
no se comparten con los interesados aumentando así la incertidumbre en los
requisitos. De mi propia experiencia, de la de mis colegas, y de estudios en la materia, he llegado a la conclusión de que, nosotros, los Ingenieros de Requisitos, tendemos a ser más rigurosos en la especificación de requisitos cuando:
- El cliente es de corte militar, es decir, es un cliente rígido, con un proceso formal bien definido o es vigilado por entidades internas o externas a su organización y a las que debe rendir cuentas sobre sus acciones.
- El análisis de requisitos hace parte de la fase actual del ciclo de vida del software, por ejemplo, cuando estamos en las fases de Inicio (UP) o Visión (MSF) y en la fase de Elaboración (UP) o Planeación (MSF). Por razones obvias, a medida que el proyecto avanza, tenemos menos tiempo para encontrar y documentar requisitos y es cuando más suposiciones se hacen sobre lo que ya está identificado.
- Utilizamos herramientas de apoyo para la especificación y el modelado de requisitos, sobre todo herramientas que permitan realizar diagramas de casos de uso, diagramas de actividad, tableros de historias, simulaciones y prototipos, entre otros instrumentos de este tipo.
- Hemos asistido a entrenamiento en los días previos al proyecto o hemos estado involucrados en proyectos problemáticos recientemente. Cuando esto ocurre, muy seguramente hemos estado sometidos a mucha presión y estrés, además de una limpieza de cerebro sin antecedentes y no queremos volver a equivocarnos.
- Simplemente tenemos la experiencia suficiente y necesaria, hemos aprendido de nuestros aciertos y fallas del pasado y de las lecciones aprendidas en proyectos anteriores. Sin contar con que hemos consultado la gran cantidad de material que encontramos en este Gazafatonario IT sobre el tema.
- Los usuarios no pueden o no saben describir muchas de sus tareas
- Mucha información importante no llega a verbalizarse. Ocurre con frecuencia que de tanto ejecutar el proceso, este “desaparece”, se vuelve algo implícito y nadie es capaz de relatarlo.
- En sistemas orientados a miles de usuarios, como los sistemas de la Web 2.0, a veces hay que “inventar” los requisitos. En estos casos, las suposiciones están a la orden del día y muchas de ellas nunca llegan a documentarse.
- En general, la educción (extracción) de requisitos es un proceso pasivo, en el que el usuario espera del Analista Funcional la solicitud de conocer algo para él intentar entonces explicárselo de alguna manera.
Finalmente, algunas técnicas bien conocidas y que son de utilidad al momento de encontrar requisitos y de las que hablaremos en otros artículos, son:
Preliminares:
Utilizar preguntas libres
de contexto.
Tormenta
de ideas:
Seleccionar un grupo
variado de participantes.
Eliminar críticas, juicios
y evaluaciones mientras los participantes sugieren ideas.
Producir muchas ideas.
Recogerlas todas por
escrito.
Otro día, en otra sesión,
se evalúan las ideas (se puntúan).
Elaboración
de prototipos:
Útil cuando la
incertidumbre es grande acerca del futuro sistema
Entrevistas:
Es el método
“tradicional”, pero debe usarse en
complemento con otras técnicas, y no debe ser el primer paso de la educción. Es
fundamental:
Entrevistar a la(s)
persona(s) adecuadas.
Preparar las preguntas con
antelación.
Utilizar diagramas,
modelos, etc.
Observación
y análisis de tareas:
Esta es una técnica tan
antiquísima como la misma Ingeniería de Software. Un observador estudia a los
futuros usuarios en su entorno de trabajo. A veces se utiliza el video. Anota
todo aquello que es susceptible de mejora. Posteriormente, genera una serie de
requisitos tentativos.
Casos
de uso
Requisitos en contexto de
uso. Sobre este asunto he expuesto docenas de artículos en este Blog.
Finalmente, recordemos que el objetivo
de la Ingeniería de Requisitos es asegurar que se defina y desarrolle un
producto efectivo de alta calidad desde el punto de vista de los interesados,
así que si una especificación de requisitos de software incompleta es
inevitable, definitivamente deberíamos aceptarla como completa haciendo
suposiciones implícitas.
