En 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] Esta práctica también se denomina a veces " recopilación de requisitos ".
El término obtención de requisitos se utiliza en libros e investigaciones para plantear el hecho de que los buenos requisitos no pueden simplemente obtenerse del cliente, como lo indicaría el nombre recopilación de requisitos. La obtención de requisitos no es trivial porque nunca se puede estar seguro de obtener todos los requisitos del usuario y del cliente con sólo preguntarles qué debe hacer o no hacer el sistema (para 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 del análisis y especificación de los requisitos.
Los procesos de obtenció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 sobre los requisitos.
El proceso de obtención de requisitos puede parecer simple: preguntar al cliente, a los usuarios y a otros cuáles son los objetivos del sistema o producto, qué se debe lograr, cómo se adapta el sistema o producto a las necesidades del negocio y, finalmente, cómo se adapta el sistema o producto a las necesidades del negocio. o producto se va a 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' . Los límites del sistema están mal definidos 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, no comprenden bien las capacidades y limitaciones de su entorno informático, no comprenden completamente el dominio del problema, tienen problemas para comunicar sus necesidades al ingeniero de sistemas, omiten información. que se cree que es " obvio ", especifica requisitos que entran en conflicto con las necesidades de otros clientes/usuarios, o especifica requisitos que son 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 . Utilizar herramientas que promuevan una mejor comprensión del producto final deseado, como la visualización y la simulación.
- Lenguaje consistente . Usar definiciones simples y consistentes para los requisitos descritos en lenguaje natural y utilizar la terminología comercial que prevalece en la empresa.
- Pautas . Seguir lineamientos organizacionales que describan las técnicas de recolección y los tipos de requisitos a recolectar. Luego, estas pautas se utilizan de manera consistente en todos los proyectos.
- Uso consistente de plantillas . Producir un conjunto consistente de modelos y plantillas para documentar los requisitos.
- Documentar dependencias . Documentar dependencias e interrelaciones entre requisitos.
- Análisis de cambios . Realizar análisis de causa raíz de cambios en los requisitos y realizar acciones correctivas.
Pautas
En 1997, Sommerville y Sawyer sugirieron un conjunto de pautas 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.
- Definir el entorno técnico (por ejemplo, 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 requerimientos 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, oportunidad o desafío real.
- Identificar las medidas actuales que demuestran que el problema es real.
- Identificar la(s) medida(s) objetivo para mostrar que se ha abordado el problema y el valor de resolverlo.
- Identificar las causas "tal cual" del problema, ya que son las causas las que deben resolverse, no el problema directamente.
- Definir los "deseos" comerciales que se deben cumplir para cumplir con las medidas del objetivo.
- Especificar el diseño de un producto para satisfacer los requisitos reales del negocio.
Sin embargo, Goldsmith señala que identificar el problema real "es sumamente difícil". [6]
Enfoques complementarios
En 2008, Alexander y Beus-Dukic propusieron un conjunto de enfoques complementarios para descubrir requisitos: [7]
Alexander y Beus-Dukic sugirieron que estos enfoques podrían llevarse a cabo con individuos (como en entrevistas ), con grupos (como en reuniones enfocadas conocidas como talleres, o mediante sistemas de reuniones electrónicos ), o a partir de "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 es construir un perfil de las partes interesadas y luego entrevistarlas exhaustivamente. Las preguntas se agrupan en tres apartados, todos ellos centrados en las necesidades de los usuarios: [8]
- Operación: ¿qué tan bien se usa [necesita edición]?
- 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 principales o básicos. [9]
Bibliografía
- Alejandro, Ian F.; Beus-Dukic, Ljerka (marzo de 2009). Descubrimiento de requisitos: cómo especificar productos y servicios . Juan Wiley. ISBN 978-0-470-71240-5.
- Orfebre, Robin F. (2004). Descubrimiento de requisitos comerciales reales para el éxito de un proyecto de software . Casa Artech. ISBN 1-58053-771-5.
- Molinero, Roxanne E. (2009). La búsqueda de requisitos de software: preguntas de sondeo para centrar la atención en los requisitos no funcionales; Técnicas comprobadas 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 . Juan 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.
Ver también
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". Formación 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 sobre requisitos de PMI sobre requisitos. Calidad".
- ^ Sommerville y Sawyer, 1997.
- ^ ab Goldsmith, 2004. Página 12
- ^ ab Beus-Dukic, Ljerka; Alejandro, Ian (2008). "Aprender a descubrir requisitos". 2008 Requisitos Educación y formación en ingeniería . Barcelona, España: IEEE. págs. 12-14. doi :10.1109/REET.2008.3.
- ^ ab 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.
