Técnicas de recopilación de requisitos
| ||||||
Técnicas de recopilación de requisitos. Técnicas que posibilitan que el proceso de recopilación de requisitos se realice de forma más eficiente.
Sumario
Introducción
La obtención de requisitos es el proceso mediante el cual los interesados en un sistema de software descubren, revelan, articulan y entienden sus requisitos (Raghavan et al., 1994). En muchos casos, se requiere tiempo para llegar a especificar claramente lo que el interesado espera de la aplicación de software, por lo que se hace necesario por parte de los analistas el empleo de técnicas que permitan establecer una buena comunicación con los interesados del producto y así lograr la satisfacción del cliente. A continuación se enuncian las principales técnicas utilizadas durante el proceso de desarrollo del Software para recopilar los requisitos de software.
Entrevistas
Es la más tradicional de las técnicas de obtención y consiste en reuniones analista-interesado en las cuales se suceden preguntas y respuestas para extraer el dominio de la aplicación (Goguen y Linde,1993). En Pressman (2005) se presentan conjuntos de preguntas que se pueden utilizar en el desarrollo de esta técnica, que tiene una alta participación del analista y se realiza en conjunto con otras técnicas.
Técnicas para facilitar las especificaciones de una aplicación (TFEA)
Constituye una variación de las entrevistas buscando identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución (Pressman, 2005). A pesar de ir un paso más allá de las entrevistas convencionales, precisan aún de una alta participación del analista.
Despliegue de la función de calidad (DFC)
Esta técnica incluye entrevistas y documentación de la organización con las cuales se construye la tabla de opinión del interesado. Esta tabla se analiza con diagramas, matrices y métodos de evaluación para extraer los requisitos esperados e intentar obtener requisitos innovadores (Pressman, 2005). También esta técnica requiere una alta interacción con el analista.
Tormenta de ideas (brainstorming)
Es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas, sobre todo al comienzo del proceso de captura, cuando los requisitos son todavía muy difusos (Raghavan et al., 1994). También se requiere participación intensiva del analista.
Juego de roles
En su forma más simple, consiste en que el desarrollador, el analista y cada uno de los miembros del equipo de desarrollo del software toman el lugar del interesado y ejecutan la actividad de trabajo que éste desempeña. Ellos experimentan las inexactitudes y problemas ligados con el sistema que se está especificando. Se busca suministrarle al analista una perspectiva nueva del problema que le permita la obtención de los requisitos del sistema por construir (Raghavan et al., 1994). Esta técnica también presenta alta participación de los involucrados.
Introspección
Esta técnica recomienda que el analista se ponga en el lugar del interesado y trate de imaginar cómo desearía éste la aplicación de software. Basado en estas suposiciones, el analista entrega recomendaciones al interesado sobre la funcionalidad que debería tener dicha aplicación (Goguen y Linde, 1993). El problema radica en que un analista no es un tipo normal de interesado, pues posee un conocimiento técnico más elevado; por ello, es posible que entre las recomendaciones haya cosas que el interesado aún no necesita o que incluso no sabe que necesitará en un futuro. En este caso, el discurso se refiere más a la solución que al dominio del problema.
Casos de uso o escenarios
Son descripciones que incluyen actores, eventos, operaciones y objetivos de esas operaciones, generalmente ligados con el funcionamiento de una solución informática (Leffingwell y Widrig, 1999; Raghavan et al , 1994;Pressman, 2005; Sommerville 2001). Los escenarios como técnica de obtención poseen dos limitaciones: exigen una alta participación del interesado en su elaboración y necesitan que él realice una concepción completa de la solución informática , que sólo sería posible al final del proceso de obtención de requisitos.
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.
Cuestionario
Es una técnica para recopilar información por medio de preguntas escritas, que se responden en ausencia del analista. No es muy confiable, ya que las respuestas obtenidas no pueden ser fácilmente verificadas o pueden estar "elaboradas por motivos propios o de grupo". Se recomienda su uso:
- Cuando las personas que posean la información se encuentren dispersas geográficamente
- Cuando se requiere obtener información al mismo tiempo de numerosas personas.
Fuente
- Rumbaugh, J.; Jacobson, I. y Booch, G.; “El Lenguaje Unificado de Modelado”.
- JACOBSON, Ivar; RUMBAUGH, James; BOOCH, Grady, “El proceso unificado de desarrollo”.2000.
