Obtención de requisitos

En ingeniería de requisitos , la obtención de requisitos es la práctica de investigar y descubrir los requisitos de un sistema a partir de los usuarios, clientes y otras partes interesadas. ^{[ 1 ]} Esta práctica también se conoce a veces como " recopilación de requisitos ".

El término elicitación se utiliza en libros e investigaciones para destacar que los buenos requisitos no se pueden obtener simplemente del cliente, como lo indicaría el nombre de recopilación de requisitos. La elicitación de requisitos no es trivial porque nunca se puede estar seguro de obtener todos los requisitos del usuario y del cliente simplemente preguntándoles qué debe o no debe hacer el sistema (en términos de seguridad y confiabilidad). Las prácticas de elicitación de requisitos incluyen entrevistas, cuestionarios, observación de usuarios, talleres, lluvia de ideas , casos de uso , juegos de rol y creación de prototipos .

Antes de que los requisitos puedan ser analizados, modelados o especificados, deben recopilarse mediante un proceso de obtención de requisitos, un paso inicial esencial en la ingeniería de requisitos.

Los procesos de obtención de información más utilizados son las reuniones o entrevistas con las partes interesadas. ^{[ 2 ]} Por ejemplo, una primera reunión importante podría ser entre ingenieros de software y clientes, donde discuten su perspectiva de los requisitos.

El proceso de obtención de requisitos puede parecer sencillo: preguntar al cliente, a los usuarios y a otros interesados ​​cuáles son los objetivos del sistema o producto, qué se pretende lograr, cómo se adapta el sistema o producto a las necesidades del negocio y, finalmente, cómo se utilizará en el día a día. Sin embargo, pueden surgir problemas que compliquen el proceso.

En 1992, Christel y Kang identificaron problemas que indican los desafíos para la obtención de requisitos: ^{[ 3 ]}

1. ' Problemas de alcance' . Los límites del sistema están mal definidos o los clientes/usuarios especifican detalles técnicos innecesarios que pueden generar confusión, en lugar de aclarar, sobre los objetivos generales del sistema.
2. Problemas de comprensión . Los clientes/usuarios no están completamente seguros de lo que se necesita, tienen una comprensión deficiente de las capacidades y limitaciones de su entorno informático, no comprenden completamente el dominio del problema, tienen dificultades para comunicar sus necesidades al ingeniero de sistemas, omiten información que consideran " obvia ", especifican requisitos que entran en conflicto con las necesidades de otros clientes/usuarios o especifican requisitos que son ambiguos o imposibles de comprobar.
3. Problemas de volatilidad . Los requisitos cambian con el tiempo. La tasa de cambio a veces se denomina nivel de volatilidad de los requisitos.

La calidad de los requisitos se puede mejorar mediante estos enfoques: ^{[ 4 ]}

1. Visualización . Utilizar herramientas que promuevan una mejor comprensión del producto final deseado, como la visualización y la simulación.
2. Lenguaje coherente . Utilizar definiciones sencillas y coherentes para los requisitos descritos en lenguaje natural y emplear la terminología empresarial habitual en la empresa.
3. Directrices . Se siguen las directrices organizativas que describen las técnicas de recopilación y los tipos de requisitos que se deben obtener. Estas directrices se aplican de forma coherente en todos los proyectos.
4. Uso coherente de plantillas . Elaboración de un conjunto coherente de modelos y plantillas para documentar los requisitos.
5. Documentación de dependencias . Documentación de dependencias e interrelaciones entre requisitos.
6. Análisis de cambios . Realizar un análisis de la causa raíz de los cambios en los requisitos y tomar medidas correctivas.

En 1997, Sommerville y Sawyer sugirieron un conjunto de directrices para la obtención de requisitos, para abordar preocupaciones como las identificadas por Christel y Kang: ^{[ 5 ]}

• Evaluar la viabilidad comercial y técnica del sistema propuesto.
• Identificar a las personas que ayudarán a especificar los requisitos y comprender su sesgo organizacional.
• Defina el entorno técnico (por ejemplo, arquitectura informática, sistema operativo , necesidades de telecomunicaciones) en el que se ubicará el sistema o producto.
• Identificar las "restricciones del dominio" (es decir, las características del entorno empresarial específicas del dominio de la aplicación) que limitan la funcionalidad o el rendimiento del sistema o producto que se va a desarrollar.
• Defina uno o más métodos de obtención de requisitos (por ejemplo, entrevistas, grupos focales , reuniones de equipo).
• Solicite la participación de muchas personas para que los requisitos se definan desde diferentes puntos de vista; asegúrese de identificar la justificación de cada requisito que se registre.
• Identificar requisitos ambiguos como candidatos para la creación de prototipos.
• Cree escenarios de uso o casos de uso para ayudar a los clientes/usuarios a identificar mejor los requisitos clave.

En 2004, Goldsmith sugirió una "pirámide de problemas" de "seis pasos que deben realizarse en secuencia": ^{[ 6 ]}

1. Identificar el problema, la oportunidad o el desafío real.
2. Identifique la(s) medida(s) actual(es) que demuestren que el problema es real.
3. Identificar la(s) medida(s) de objetivo para demostrar que el problema se ha abordado y el valor de alcanzarlo.
4. Identifique la(s) causa(s) "tal como está" del problema, ya que son las causas las que deben resolverse, no el problema en sí.
5. Defina los "deseos" del negocio que deben cumplirse para alcanzar la(s) medida(s) objetivo.
6. Especificar un diseño de producto que satisfaga los requisitos reales del negocio.

Sin embargo, Goldsmith señala que identificar el problema real "es sumamente difícil". ^{[ 6 ]}

En 2008, Alexander y Beus-Dukic propusieron un conjunto de enfoques complementarios para descubrir requisitos: ^{[ 7 ]}

• Identificación de las partes interesadas
• Objetivos del modelo
• Contexto del modelado
• Descubrimiento de escenarios (o casos de uso )
• Descubriendo "cualidades y limitaciones" ( requisitos no funcionales )
• Fundamentos y supuestos del modelo
• Escribir definiciones de términos
• Análisis de mediciones (criterios de aceptación)
• Análisis de prioridades

Alexander y Beus-Dukic sugirieron que estos enfoques podrían llevarse a cabo con individuos (como en entrevistas ), con grupos (como en reuniones focalizadas conocidas como talleres, o a través de sistemas de reuniones electrónicas ), o a partir de "cosas" (artefactos) como prototipos . ^{[ 7 ]}

En 2009, Miller propuso un conjunto de más de 2000 preguntas para obtener requisitos no funcionales. ^{[ 8 ]} Su enfoque consiste en crear un perfil de las partes interesadas y luego entrevistarlas exhaustivamente. Las preguntas se agrupan en tres secciones, todas centradas en las necesidades del usuario: ^{[ 8 ]}

1. Operación: ¿qué tan bien se utiliza [necesita edición]?
2. Revisión: ¿Qué tan fácil es corregir errores y agregar funciones?
3. Transición: ¿Qué tan fácil es adaptarse a los cambios en el entorno técnico?

En 2013, Murali Chemuturi sugirió el uso de Requisitos de Funcionalidad Auxiliar en lugar de Requisitos No Funcionales, ya que "No Funcional" implica "nunca funcional". En segundo lugar, estos requisitos, de hecho, satisfacen algunos requisitos que son de apoyo a los Requisitos de Funcionalidad Principales o Centrales. ^{[ 9 ]}

• Alexander, Ian F.; Beus-Dukic, Ljerka (marzo de 2009). Descubriendo requisitos: Cómo especificar productos y servicios . John Wiley. ISBN 978-0-470-71240-5.
• Goldsmith, Robin F. (2004). Descubriendo los requisitos empresariales reales para el éxito de un proyecto de software . Artech House. ISBN 1-58053-771-5.
• Miller, Roxanne E. (2009). La búsqueda de los requisitos de software: Preguntas clave para definir los requisitos no funcionales; técnicas probadas para lograr la participación adecuada de las partes interesadas . MavenMark Books. ISBN 978-1-59598-067-0.
• Sommerville, Ian ; Sawyer, Pete (mayo de 1997). Ingeniería de requisitos: una guía de buenas prácticas . John Wiley. ISBN 0-471-97444-7.
•  Gobov, Denys, Huchenko, Inna. (2020). Técnicas de obtención de requisitos para proyectos de software en el sector de TI ucraniano: un estudio exploratorio. http://dx.doi.org/10.15439/2020F16 .

• Elaboración progresiva