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 un rol 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, mantenimiento e ingeniería de requisitos del sistema", [3] pero no se generalizó hasta finales de la década de 1990 con la publicación de una IEEE Computer Society. tutorial [4] en marzo de 1997 y el establecimiento de una serie de conferencias sobre ingeniería de requisitos que se ha convertido 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, según el tipo de sistema que se está desarrollando y las prácticas específicas de la organización involucradas. [6] Estos pueden incluir:

  1. Inicio de requisitos o obtención de requisitos : los desarrolladores y las partes interesadas se reúnen; a estos últimos 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. Tanto las herramientas escritas como las gráficas (estas últimas comúnmente utilizadas en la fase de diseño, pero algunos también las encuentran útiles en esta etapa) se utilizan con éxito como ayudas. Ejemplos de herramientas de análisis escritas: casos de uso e historias de usuarios . Ejemplos de herramientas gráficas: UML [7] y LML .
  3. Modelado de sistemas : algunos campos de la 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 tanto, la fase de diseño debe realizarse con antelación. Por ejemplo, se deben elaborar planos de un edificio antes de que se pueda aprobar y firmar cualquier contrato. Muchos campos pueden derivar modelos del sistema con Lifecycle Modeling Language , 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 (RS), que se volverá oficial solo después de la validación. Un RS puede contener información tanto escrita como gráfica (modelos) si es necesario. Ejemplo: especificación de requisitos de software (SRS).
  5. Validación de requisitos: verificar que los requisitos y modelos documentados sean consistentes y satisfagan las necesidades de las partes interesadas. Sólo 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, supervisar a medida que se desarrolla el sistema e incluso hasta después de su puesta en uso (por ejemplo, cambios, extensiones, etc.)

A veces se presentan como etapas cronológicas aunque, en la práctica, hay un considerable entrelazamiento 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 requisitos incompletos, objetivos móviles y limitaciones de tiempo, siendo los problemas menores fallas de comunicación, falta de trazabilidad, problemas terminológicos y 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 hay deficiencias en el proceso de ingeniería de requisitos que resultan en una situación en la que los requisitos no existen, los requisitos de software pueden crearse independientemente como una ilusión que tergiversa las decisiones de diseño como requisitos [11]

Ver también

Referencias

  1. ^ Nuseibeh, B.; Easterbrook, S. (2000). Ingeniería de requisitos: una hoja de ruta (PDF) . CISE '00. Actas de la conferencia sobre el futuro de la ingeniería de software . págs. 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 . Congreso y exposición mundial SAE 1964. Documento técnico SAE 640591 . doi :10.4271/640591.
  4. ^ Thayer, Richard H.; Dorfman, Merlín, eds. (Marzo de 1997). Ingeniería de requisitos de software (2ª ed.). Prensa de la Sociedad de Computación IEEE . ISBN 978-0-8186-7738-0.
  5. ^ Royce, WW (1970). Gestión del desarrollo de grandes sistemas de software: conceptos y técnicas (PDF) . CISE '87. Actas de la novena conferencia internacional sobre ingeniería de software . págs. 1–9.
  6. ^ Sommerville, Ian (2009). Ingeniería de software (9ª ed.). Addison-Wesley . ISBN 978-0-13-703515-1.
  7. ^ "Descubrir 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). "La ingeniería de requisitos como factor de éxito en proyectos de software". Software IEEE . 18 (4): 58–66. doi :10.1109/MS.2001.936219. ISSN  0740-7459.
  9. ^ Méndez Fernández, Daniel; Wagner, Stefan (2015). "Nombrar los problemas de la ingeniería de requisitos: un diseño para una familia global de encuestas y los primeros resultados de Alemania". Tecnología de la información y 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). "¿Es la ingeniería de requisitos inherentemente contraproducente?". IEEE. doi :10.13140/2.1.3831.6321. {{cite journal}}: Citar diario requiere |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 Bib : 2013AIPC.1516..293R. doi :10.1007/s00766-012-0161-4. S2CID  11499083.

enlaces externos