Ingeniería de Software | Obtención de requisitos

La obtención de requisitos es quizás el desarrollo de software más difícil, más propenso a errores y más intensivo en comunicación. Solo puede tener éxito a través de una asociación efectiva entre el cliente y el desarrollador. Se necesita saber qué es lo que realmente necesitan los usuarios. 

 Actividades de obtención de
requisitos: La obtención de requisitos incluye las actividades subsiguientes. Algunos de ellos se enumeran a continuación: 

• Conocimiento del área general donde se aplica el sistema.
• Deben entenderse los detalles del problema preciso del cliente donde se va a aplicar el sistema.
• Interacción del sistema con requerimientos externos.
• Investigación detallada de las necesidades del usuario.
• Definir las restricciones para el desarrollo del sistema.

Métodos de obtención de requisitos:
Hay una serie de métodos de obtención de requisitos. Algunos de ellos se enumeran a continuación: 

1. Entrevistas
2. Sesiones de lluvia de ideas
3. Técnica de especificación de aplicación facilitada (FAST)
4. Despliegue de la función de calidad (QFD)
5. Enfoque de caso de uso

El éxito de una técnica de elicitación utilizada depende de la madurez del analista, los desarrolladores, los usuarios y el cliente involucrado. 

1. Entrevistas: 
El objetivo de realizar una entrevista es comprender las expectativas del cliente con respecto al software. 
Es imposible entrevistar a todas las partes interesadas, por lo que los representantes de los grupos se seleccionan en función de su experiencia y credibilidad. 

Las entrevistas pueden ser abiertas o estructuradas. 

1. En las entrevistas abiertas no hay una agenda preestablecida. Se pueden hacer preguntas libres de contexto para comprender el problema.
2. En entrevista estructurada, se prepara agenda de preguntas bastante abiertas. A veces se diseña un cuestionario adecuado para la entrevista.

2. Sesiones de lluvia de ideas: 

• es una tecnica de grupo
• Su objetivo es generar muchas ideas nuevas y, por lo tanto, proporcionar una plataforma para compartir puntos de vista.
• Se requiere un facilitador altamente capacitado para manejar los prejuicios y conflictos grupales.
• Cada idea está documentada para que todos puedan verla.
• Finalmente, se elabora un documento que consta de la lista de requisitos y su prioridad si es posible.

3. Técnica de especificación de aplicaciones facilitada: 
su objetivo es cerrar la brecha de expectativas: la diferencia entre lo que los desarrolladores creen que deben construir y lo que los clientes creen que obtendrán. 

Se desarrolla un enfoque orientado al equipo para la recopilación de requisitos. 
Se le pide a cada asistente que haga una lista de objetos que son- 

1. Parte del entorno que rodea al sistema.
2. producido por el sistema
3. Utilizado por el sistema

Cada participante prepara su lista, luego se combinan diferentes listas, se eliminan las entradas redundantes, el equipo se divide en sub-equipos más pequeños para desarrollar mini-especificaciones y finalmente se escribe un borrador de especificaciones utilizando todos los aportes de la reunión. 

4. Despliegue de la función de calidad: 
en esta técnica, la satisfacción del cliente es la principal preocupación, por lo tanto, enfatiza los requisitos que son valiosos para el cliente. 
Se identifican 3 tipos de requisitos: 

• Requisitos normales: 
  en esto, el objetivo y las metas del software propuesto se discuten con el cliente. Ejemplo: los requisitos normales para un sistema de gestión de resultados pueden ser el ingreso de calificaciones, el cálculo de resultados, etc.
• Requisitos esperados: 
  estos requisitos son tan obvios que el cliente no necesita declararlos explícitamente. Ejemplo: protección contra el acceso no autorizado.
• Requisitos emocionantes: 
  incluye características que van más allá de las expectativas del cliente y demuestran ser muy satisfactorias cuando están presentes. Ejemplo: cuando se detecta un acceso no autorizado, debe hacer una copia de seguridad y cerrar todos los procesos.

Los principales pasos involucrados en este procedimiento son:  

1. Identifique a todas las partes interesadas, p. Usuarios, desarrolladores, clientes, etc.
2. Enumere todos los requisitos del cliente.
3. A cada requisito se le asigna un valor que indica el grado de importancia.
4. Al final, la lista final de requisitos se clasifica como: 
   • Es posible lograr
   • Debe ser diferido y la razón de ello
   • Es imposible de lograr y debe dejarse

5. Enfoque de caso de uso: 
esta técnica combina texto e imágenes para proporcionar una mejor comprensión de los requisitos. 
Los casos de uso describen el ‘qué’ de un sistema y no el ‘cómo’. Por lo tanto, solo dan una visión funcional del sistema. 
Los componentes del diseño de casos de uso incluyen tres cosas principales: actor, casos de uso, diagrama de casos de uso. 

1. Actor: 
   es el agente externo que se encuentra fuera del sistema pero que interactúa con él de alguna manera. Un actor puede ser una persona, una máquina, etc. Se representa como una figura de palo. Los actores pueden ser actores primarios o actores secundarios. 
   • Actores primarios: requiere la asistencia del sistema para lograr un objetivo.
   • Actor secundario: es un actor del que el sistema necesita asistencia.
2. Casos de uso: 
   describen la secuencia de interacciones entre los actores y el sistema. Capturan quién (actores) hacen qué (interacción) con el sistema. Un conjunto completo de casos de uso especifica todas las formas posibles de usar el sistema.
3. Diagrama de casos de uso: 
   un diagrama de casos de uso representa gráficamente lo que sucede cuando un actor interactúa con un sistema. Captura el aspecto funcional del sistema. 
   • Se utiliza una figura de palo para representar a un actor.
   • Se utiliza un óvalo para representar un caso de uso.
   • Una línea se utiliza para representar una relación entre un actor y un caso de uso.

Para obtener más información sobre el diagrama de casos de uso, consulte – Diseño de casos de uso para un proyecto