stringtranslate.com

Elicitación de requisitos

En ingeniería de requisitos , la elicitació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] La 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 plantear el hecho de que los buenos requisitos no pueden simplemente recopilarse 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 el cliente simplemente preguntándoles qué debería hacer o no hacer el sistema (para la seguridad y la 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 roles y creación de prototipos .

Antes de poder analizar, modelar o especificar los requisitos, es necesario recopilarlos mediante un proceso de obtención de requisitos. La obtención de requisitos es una parte del proceso de ingeniería de requisitos, que suele ir seguida del 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 ingenieros de software y clientes donde discuten su perspectiva de los requisitos.


El proceso de obtención de requisitos puede parecer simple: preguntar al cliente, a los usuarios y a otras personas cuáles son los objetivos del sistema o producto, qué se debe lograr, cómo se adapta el sistema o producto a las necesidades de la empresa y, por último, cómo se utilizará el sistema o producto 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' . 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.
  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 plenamente el dominio del problema, tienen problemas para comunicar sus necesidades al ingeniero de sistemas, omiten información que se considera “ 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 . Uso de herramientas que promuevan una mejor comprensión del producto final deseado, como la visualización y la simulación.
  2. Lenguaje coherente . Utilizar definiciones simples y coherentes de los requisitos descritos en lenguaje natural y utilizar la terminología empresarial predominante en la empresa.
  3. Pautas . Seguir las pautas organizativas que describen las técnicas de recopilación y los tipos de requisitos que se deben recopilar. Estas pautas se utilizan de forma coherente en todos los proyectos.
  4. Uso coherente de plantillas . Generació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 . Realización de análisis de causa raíz de cambios en los requisitos y toma de medidas correctivas.

Pautas

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]

Secuencia de pasos

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

  1. Identificar el verdadero problema, oportunidad o desafío
  2. Identifique las medidas actuales que muestran que el problema es real.
  3. Identificar las medidas objetivo para demostrar que se ha abordado el problema y el valor de cumplirlas.
  4. Identificar la(s) causa(s) "tal cual" del problema, ya que son las causas las que deben resolverse, no el problema directamente.
  5. Definir los "deseos" del negocio que se deben entregar para cumplir con las medidas objetivo.
  6. Especificar un diseño de producto que satisfaga los requisitos comerciales reales

Sin embargo, Goldsmith señala que identificar el problema real "es extremadamente 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 focalizadas conocidas como talleres, o mediante sistemas de reuniones electrónicas ), o a partir de "cosas" (artefactos) como prototipos . [7]

Requisitos no funcionales

En 2009, Miller propuso una batería de más de 2000 preguntas para obtener información sobre los 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 de los usuarios: [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 funcionales auxiliares en lugar de requisitos no funcionales, ya que "no funcional" connota "nunca funcional". En segundo lugar, estos requisitos de hecho cumplen algunos requisitos que respaldan los requisitos funcionales principales o básicos. [9]

Bibliografía

Véase también

Referencias

  1. ^ Ingeniería de requisitos: una guía de buenas prácticas, Ramos Rowel y Kurts Alfeche, John Wiley and Sons, 1997
  2. ^ Kusiak, Jan. "Cómo entrevistar a su jefe". Capacitación IRM .
  3. ^ Christel, Michael y Kyo C. Kang (septiembre de 1992). "Issues in Requirements Eliciitation". Informe técnico CMU/SEI-92-TR-012 . CMU / SEI . Consultado el 14 de enero de 2012 .
  4. ^ "Seminario web de la CoP de Requisitos del PMI sobre Requisitos.Calidad".
  5. ^ Sommerville y Sawyer, 1997.
  6. ^ de Goldsmith, 2004. Página 12
  7. ^ ab Beus-Dukic, Ljerka; Alexander, Ian (2008). "Aprender a descubrir requisitos". 2008 Educación y formación en ingeniería de requisitos . Barcelona, ​​España: IEEE. pp. 12–14. doi :10.1109/REET.2008.3.
  8. ^ por Miller, 2009.
  9. ^ 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  .