Este proceso demanda trabajo colaborativo entre ingenieros, analistas y usuarios expertos en el dominio del problema, para descubrir las necesidades reales y llegar a un acuerdo en cuanto a la visión y objetivos del producto a desarrollar. La intervención de un analista experto en el negocio es una buena práctica, para asegurar la definición y especificación de requisitos con alta calidad.
Algunas fuentes de información que sirven como insumo en el proceso de elicitación son:
- Stakeholders: conformados por clientes, usuarios, expertos del dominio, además de grupos formales e informales. Incluye a todos los interesados e impactados con la implantación de una solución basada en software.
- Documentos del negocio: constituido por actas de reunión, políticas, procedimientos, instrucciones de trabajo, formatos, etc.; relacionados con el área de negocio que demanda el producto software.
- Documentos externos: formado por manuales de otro software similar, libros y artículos sobre temas relacionados, regulaciones y normativa legal, entre otros.
¿Qué técnicas de elicitación de requisitos son las más comunes?
Entrevistas, encuestas/cuestionarios, JAD (Joint Application Development), brainstorming, casos de uso, historias de usuarios y prototipos. Estos últimos son esenciales para especificar y acordar el comportamiento visible del sistema (interfaz de usuario), por lo que pueden ser prototipos de baja fidelidad (mockups) o de alta fidelidad (funcionales).
Nota: el
diccionario de la RAE no registra la palabra “elicitar”. En el campo de la Ingeniería de Software el término es común. En http://lema.rae.es/dpd/srv/search?key=elicitar
dice:
*elicitar. Adaptación innecesaria del verbo inglés to elicit, que aparece a veces en textos de psicología con el sentido que corresponde a los verbos españoles provocar, suscitar u obtener...
*elicitar. Adaptación innecesaria del verbo inglés to elicit, que aparece a veces en textos de psicología con el sentido que corresponde a los verbos españoles provocar, suscitar u obtener...