stringtranslate.com

Ingeniería de requisitos

La ingeniería de requisitos ( RE ) [1] es el proceso de definir, documentar y mantener los requisitos [2] en el proceso de diseño de ingeniería . Es una función común en la ingeniería de sistemas y la ingeniería de software .

El primer uso del término ingeniería de requisitos fue probablemente en 1964 en el artículo de la conferencia "Mantenimiento, mantenibilidad e ingeniería de requisitos del sistema", [3] pero no entró en uso general hasta fines de la década de 1990 con la publicación de un tutorial de la IEEE Computer Society [4] en marzo de 1997 y el establecimiento de una serie de conferencias sobre ingeniería de requisitos que evolucionó hasta convertirse en la Conferencia Internacional de Ingeniería de Requisitos .

En el modelo en cascada , [5] la ingeniería de requisitos se presenta como la primera fase del proceso de desarrollo. Los métodos de desarrollo posteriores, incluido el Proceso Unificado Racional (RUP) para software, suponen que la ingeniería de requisitos continúa durante toda la vida útil de un sistema.

La gestión de requisitos , que es una subfunción de las prácticas de ingeniería de sistemas, también está indexada en los manuales del Consejo Internacional de Ingeniería de Sistemas (INCOSE).

Actividades

Las actividades involucradas en la ingeniería de requisitos varían ampliamente, dependiendo del tipo de sistema que se esté desarrollando y las prácticas específicas de la organización involucradas. [6] Estas pueden incluir:

  1. Creación o elicitación de requisitos : los desarrolladores y las partes interesadas se reúnen; a estas últimas se les pregunta sobre sus necesidades y deseos con respecto al producto de software.
  2. Análisis y negociación de requisitos: se identifican los requisitos (incluidos los nuevos si el desarrollo es iterativo) y se resuelven los conflictos con las partes interesadas. Se utilizan con éxito como ayuda tanto herramientas escritas como gráficas (estas últimas se utilizan habitualmente en la fase de diseño, pero algunas personas las encuentran útiles también en esta etapa). Ejemplos de herramientas de análisis escritas: casos de uso e historias de usuario . Ejemplos de herramientas gráficas: UML [7] y LML .
  3. Modelado de sistemas : algunos campos de ingeniería (o situaciones específicas) requieren que el producto esté completamente diseñado y modelado antes de que comience su construcción o fabricación. Por lo tanto, la fase de diseño debe realizarse con anticipación. Por ejemplo, los planos de un edificio deben elaborarse antes de que se pueda aprobar y firmar cualquier contrato. Muchos campos pueden derivar modelos del sistema con el lenguaje de modelado del ciclo de vida , mientras que otros pueden usar UML . Nota: En muchos campos, como la ingeniería de software, la mayoría de las actividades de modelado se clasifican como actividades de diseño y no como actividades de ingeniería de requisitos.
  4. Especificación de requisitos : los requisitos se documentan en un artefacto formal llamado Especificación de requisitos (ER), que se convertirá en oficial solo después de la validación. Una ER puede contener información escrita y gráfica (modelos) si es necesario. Ejemplo: Especificación de requisitos de software (ER).
  5. Validación de requisitos: verificación de que los requisitos y modelos documentados sean coherentes y satisfagan las necesidades de las partes interesadas. Solo si el borrador final pasa el proceso de validación, el RS se vuelve oficial.
  6. Gestión de requisitos : gestionar todas las actividades relacionadas con los requisitos desde el inicio, supervisando a medida que se desarrolla el sistema e incluso hasta después de su puesta en uso (por ejemplo, cambios, ampliaciones, etc.).

A veces se presentan como etapas cronológicas, aunque en la práctica hay una intercalación considerable de estas actividades.

Se ha demostrado que la ingeniería de requisitos contribuye claramente al éxito de los proyectos de software. [8]

Problemas

Un estudio limitado realizado en Alemania presentó posibles problemas en la implementación de la ingeniería de requisitos y preguntó a los encuestados si estaban de acuerdo en que se trataba de problemas reales. Los resultados no se presentaron como generalizables, pero sugirieron que los principales problemas percibidos eran los requisitos incompletos, los objetivos móviles y el time boxing, y que los problemas menores eran las fallas de comunicación, la falta de trazabilidad, los problemas terminológicos y las responsabilidades poco claras. [9]

Crítica

Se ha especulado que la estructuración de problemas, un aspecto clave de la ingeniería de requisitos, reduce el rendimiento del diseño. [10] Algunas investigaciones sugieren que es posible que, si existen deficiencias en el proceso de ingeniería de requisitos que resulten en una situación en la que los requisitos no existen, se puedan crear requisitos de software como una ilusión que tergiverse las decisiones de diseño como requisitos [11].

Véase también

Referencias

  1. ^ Nuseibeh, B.; Easterbrook, S. (2000). Ingeniería de requisitos: una hoja de ruta (PDF) . ICSE '00. Actas de la conferencia sobre el futuro de la ingeniería de software . pp. 35–46. CiteSeerX  10.1.1.131.3116 . doi :10.1145/336512.336523. ISBN . 1-58113-253-0.
  2. ^
  3. ^ Dresner, KH Borchers (1964). Mantenimiento, mantenibilidad e ingeniería de requisitos del sistema . SAE World Congress & Exhibition 1964. Documento técnico SAE 640591. doi : 10.4271/640591.
  4. ^ Thayer, Richard H.; Dorfman, Merlin, eds. (marzo de 1997). Ingeniería de requisitos de software (2.ª ed.). IEEE Computer Society Press . ISBN 978-0-8186-7738-0.
  5. ^ Royce, WW (1970). Gestión del desarrollo de grandes sistemas de software: conceptos y técnicas (PDF) . ICSE '87. Actas de la 9.ª conferencia internacional sobre ingeniería de software . pp. 1–9.
  6. ^ Sommerville, Ian (2009). Ingeniería de software (novena edición). Addison-Wesley . ISBN 978-0-13-703515-1.
  7. ^ "Descubrimiento de requisitos con diagramas de clases UML, parte 1". tynerblain.com . 7 de marzo de 2008 . Consultado el 14 de marzo de 2018 .
  8. ^ Hofmann, HF; Lehner, F. (2001). "Ingeniería de requisitos como factor de éxito en proyectos de software". IEEE Software . 18 (4): 58–66. doi :10.1109/MS.2001.936219. ISSN  0740-7459.
  9. ^ Méndez Fernández, Daniel; Wagner, Stefan (2015). "Nombrando el dolor en la ingeniería de requisitos: Un diseño para una familia global de encuestas y primeros resultados de Alemania". Tecnología de la información y el software . 57 : 616–643. arXiv : 1611.04976 . doi :10.1016/j.infsof.2014.05.008. S2CID  1924926.
  10. ^ Ralph, Paul; Mohanani, Rahul (mayo de 2015). "¿La ingeniería de requisitos es inherentemente contraproducente?". IEEE. doi :10.13140/2.1.3831.6321. {{cite journal}}: Requiere citar revista |journal=( ayuda )
  11. ^ Ralph, P. (septiembre de 2013). "La ilusión de los requisitos en el desarrollo de software". Ingeniería de requisitos . 18 (3): 293–296. arXiv : 1304.0116 . Código Bibliográfico :2013AIPC.1516..293R. doi :10.1007/s00766-012-0161-4. S2CID  11499083.

Enlaces externos