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.
Los prototipos pueden ser: diagramas, aplicaciones
operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde
se espera que el software final tenga diseño gráfico, se realizan en una
variedad de documentos de diseño gráficos y a menudo elimina todo el color del
diseño del software (es decir utilizar una gama de grises). Esto ayuda a
prevenir la confusión sobre la apariencia final de la aplicación.
Bibliografia:
No hay comentarios:
Publicar un comentario