En la ingeniería de requisitos , la obtención de requisitos es la práctica de investigar y descubrir los requisitos de un sistema por parte de los usuarios, clientes y otras partes interesadas. [1] La práctica también se denomina a veces " recopilación de requisitos ".
El término obtención se utiliza en libros e investigaciones para plantear el hecho de que los buenos requisitos no pueden simplemente recopilarse del cliente, como lo indica la recopilación de requisitos de nombre. La obtención de requisitos no es trivial porque nunca puede estar seguro de obtener todos los requisitos del usuario y del cliente con solo preguntarles qué debe hacer o no hacer el sistema (por seguridad y confiabilidad). Las prácticas de obtención de requisitos incluyen entrevistas, cuestionarios, observación de usuarios, talleres, lluvia de ideas , casos de uso , juegos de roles y creación de prototipos .
Antes de que los requisitos puedan analizarse, modelarse o especificarse, deben recopilarse mediante un proceso de obtención. La obtención de requisitos es parte del proceso de ingeniería de requisitos, generalmente seguida por el análisis y la especificación de los requisitos.
Los procesos de elicitació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 los ingenieros de software y los clientes en la que discutan su perspectiva de los requisitos.
Problemas
El proceso de obtención de requisitos puede parecer simple: pregunte al cliente, a los usuarios y a otras personas cuáles son los objetivos del sistema o producto, qué se debe lograr, cómo el sistema o producto encaja en las necesidades del negocio y, finalmente, cómo el sistema o el producto 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]
- ' Problemas de alcance' . El límite del sistema está mal definido o los clientes / usuarios especifican detalles técnicos innecesarios que pueden confundir, en lugar de aclarar, los objetivos generales del sistema.
- 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 tienen una comprensión completa del dominio del problema, tienen problemas para comunicar sus necesidades al ingeniero de sistemas, omiten información que se cree que es " obvio " , especifique requisitos que entren en conflicto con las necesidades de otros clientes / usuarios, o especifique requisitos que sean ambiguos o no comprobables.
- 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]
- Visualización . Usar herramientas que promuevan una mejor comprensión del producto final deseado, como la visualización y la simulación.
- Lenguaje coherente . Usar definiciones simples y consistentes para los requisitos descritos en lenguaje natural y usar la terminología comercial que prevalece en la empresa.
- Directrices . Seguir las pautas organizativas que describen las técnicas de recolección y los tipos de requisitos a recolectar. Luego, estas pautas se utilizan de manera coherente en todos los proyectos.
- Uso constante de plantillas . Producir un conjunto coherente de modelos y plantillas para documentar los requisitos.
- Documentar dependencias . Documentar las dependencias e interrelaciones entre los requisitos.
- Análisis de cambios . Realización de análisis de la causa raíz de los cambios en los requisitos y realización de acciones correctivas.
Pautas
En 1997, Sommerville y Sawyer sugirieron un conjunto de pautas para la obtención de requisitos, para abordar inquietudes 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.
- Definir el entorno técnico (p. Ej., Arquitectura informática, sistema operativo, necesidades de telecomunicaciones) en el que se colocará el sistema o producto.
- Identificar "restricciones de dominio" (es decir, 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 construir.
- Definir uno o más métodos de obtención de requisitos (por ejemplo, entrevistas, grupos focales , reuniones de equipo)
- Solicitar 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
Secuencia de pasos
En 2004, Goldsmith sugirió una "pirámide de problemas" de "seis pasos que deben realizarse en secuencia": [6]
- Identificar el problema, la oportunidad o el desafío real
- Identificar las medidas actuales que muestran que el problema es real.
- Identificar la (s) medida (s) de la meta para demostrar que se ha abordado el problema y el valor de cumplirlo
- Identificar la (s) causa (s) "tal cual" del problema, ya que son las causas las que deben resolverse, no el problema directamente.
- Definir los "deseos" de la empresa que deben cumplirse para cumplir con las medidas del objetivo.
- Especificar un diseño de producto sobre cómo satisfacer los requisitos comerciales reales.
Sin embargo, Goldsmith señala que identificar el problema real "es sumamente difícil". [6]
Enfoques complementarios
En 2009, Alexander y Beus-Dukic propusieron un conjunto de enfoques complementarios para descubrir requisitos: [7]
- Identificación de las partes interesadas
- Objetivos de modelado
- Contexto de modelado
- Descubriendo escenarios (o casos de uso )
- Descubrir "cualidades y limitaciones" ( requisitos no funcionales )
- Modelado lógica y los supuestos
- Escribir definiciones de términos
- Analizar medidas (criterios de aceptación)
- Analizando 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 mediante sistemas de reuniones electrónicos ), o desde "cosas" (artefactos) como prototipos . [7]
requerimientos no funcionales
En 2009, Miller propuso una batería de más de 2000 preguntas para obtener requisitos no funcionales. [8] Su enfoque consiste en crear un perfil de partes interesadas y luego entrevistarlas ampliamente. Las preguntas se agrupan en tres secciones, todas centradas en las necesidades de los usuarios: [8]
- Operación: ¿Qué tan bien se usa [necesita editar]?
- Revisión: ¿qué tan fácil es corregir errores y agregar funciones?
- 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" connota "nunca funcional". En segundo lugar, estos requisitos de hecho cumplen con algunos requisitos que respaldan los requisitos de funcionalidad principal o central. [9]
Bibliografía
- Alexander, Ian F .; Beus-Dukic, Ljerka (marzo de 2009). Descubrimiento de requisitos: cómo especificar productos y servicios . John Wiley. ISBN 978-0-470-71240-5.
- Goldsmith, Robin F. (2004). Descubriendo los requisitos comerciales reales para el éxito de un proyecto de software . Casa Artech. ISBN 1-58053-771-5.
- Miller, Roxanne E. (2009). La búsqueda de requisitos de software: preguntas de sondeo para enfocar los requisitos no funcionales; Técnicas probadas para lograr la participación adecuada de las partes interesadas . Libros MavenMark. 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 TI de Ucrania: un estudio exploratorio. http://dx.doi.org/10.15439/2020F16 .
Referencias
- ^ Ingeniería de requisitos Una guía de buenas prácticas, Ramos Rowel y Kurts Alfeche, John Wiley and Sons, 1997
- ^ Kusiak, enero. "Cómo entrevistar a su jefe" . Entrenamiento IRM .
- ^ Christel, Michael y Kyo C. Kang (septiembre de 1992). "Problemas en la obtención de requisitos" . Informe técnico CMU / SEI-92-TR-012 . CMU / SEI . Consultado el 14 de enero de 2012 .
- ^ "Seminario web CoP de requisitos de PMI sobre requisitos. Calidad" .
- ^ Sommerville y Sawyer, 1997.
- ^ a b Goldsmith, 2004. Página 12
- ↑ a b Alexander y Beus-Dukic, 2009.
- ↑ a b Miller, 2009.
- ^ Chemuturi, M. (2013). Ingeniería y Gestión de Requisitos para Proyectos de Desarrollo de Software . doi : 10.1007 / 978-1-4614-5377-2 . ISBN 978-1-4614-5376-5. S2CID 19818654 .