La ingeniería de requisitos
puede ser un proceso largo y arduo para el que se requiere de habilidades
psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la
gente, así que es importante identificar a todos los actores involucrados,
considerar sus necesidades y asegurar que entienden las implicaciones de los
nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los
requisitos del cliente. Históricamente, esto ha incluido técnicas tales como
las entrevistas, o talleres con grupos para crear listas de requisitos.
Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando
sea necesario, el analista empleará una combinación de estos métodos para
establecer los requisitos exactos de las personas implicadas, para producir un
sistema que resuelva las necesidades del negocio.
Entrevistas
Las entrevistas son un método
común. Por lo general no se entrevista a toda la gente que se relacionará con
el sistema, sino a una selección de personas que represente a todos los
sectores críticos de la organización, con el énfasis puesto en los sectores más
afectados o que harán un uso más frecuente del nuevo sistema.
Talleres
Los requisitos tienen a menudo
implicaciones cruzadas desconocidas para las personas implicadas individuales y
que a menudo no se descubren en las entrevistas o quedan incompletamente
definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse
realizando en un ambiente controlado, talleres facilitados por un analista del
negocio, en donde las personas implicadas participan en discusiones para descubrir
requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es
útil la selección de un secretario dedicado a la documentación de la discusión,
liberando al analista del negocio para centrarse en el proceso de la definición
de los requisitos y para dirigir la discusión.
Forma de
contrato
En lugar de una entrevista, se
pueden llenar formularios o contratos indicando los requisitos. En sistemas muy
complejos éstos pueden tener centenares de páginas.
Objetivos
medibles
Los requisitos formulados por
los usuarios se toman como objetivos generales, a largo plazo, y en cambio se
los debe analizar una y otra vez desde el punto de vista del sistema hasta
determinar los objetivos críticos del funcionamiento interno que luego darán
forma a los comportamientos apreciables por el usuario. Luego, se establecen
formas de medir el progreso en la construcción, para evaluar en cualquier
momento qué tan avanzado se encuentra el proyecto.
Prototipos
Un prototipo es una pequeña
muestra, de funcionalidad limitada, de cómo sería el producto final una vez
terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos
aspectos antes de llegar al producto terminado.
Casos de uso
Un caso de uso es una
técnica para documentar posibles requisitos, graficando la relación del sistema
con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja
negra, y sólo se representa su interacción con
entidades externas, permite omitir dichos aspectos y determinar los que
realmente corresponden a las entidades externas. El objetivo de esta práctica
es mejorar la comunicación entre los usuarios y los desarrolladores, mediante
la prueba temprana de prototipos para minimizar cambios hacia el final del
proyecto y reducir los costes finales. Esta técnica se enfrenta a los
siguientes peligros potenciales.
- A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.
- Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.
- Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.
- Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.
No hay comentarios:
Publicar un comentario