Hispanopedia Wiki
Articulo de referencia

Ingeniería de requisitos

En el modelo de cascada , [ 1 ] la ingeniería de requisitos se presenta como la primera fase del proceso de desarrollo de software. Los métodos de desarrollo posteriores, inclui...

Hispanopedia WikiContenido en espanolLectura gratuita

En el modelo de cascada , [ 1 ] la ingeniería de requisitos se presenta como la primera fase del proceso de desarrollo de software. Los métodos de desarrollo posteriores, incluido el proceso racional unificado (RUP) para software, asumen 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 de las prácticas específicas de la organización. [ 2 ] Estas pueden incluir:

  1. Recopilación o obtenció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 herramientas tanto escritas como gráficas (estas últimas se usan comúnmente en la fase de diseño, pero algunos también las encuentran útiles en esta etapa). Ejemplos de herramientas de análisis escritas: casos de uso e historias de usuario . Ejemplos de herramientas gráficas: Lenguaje Unificado de Modelado [ 3 ] (UML) y Lenguaje de Modelado del Ciclo de Vida (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 lo tanto, la fase de diseño debe realizarse con antelació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 LML , 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 documento formal llamado Especificación de Requisitos (ER), que solo se oficializará tras su validación. Una ER puede contener información tanto escrita como gráfica (modelos), si es necesario. Ejemplo: Especificación de requisitos de software (ERS).
  5. Validación de requisitos : Comprobar que los requisitos y modelos documentados sean coherentes y satisfagan las necesidades de las partes interesadas. Solo si el borrador final supera el proceso de validación, el documento de requisitos se convierte en oficial.
  6. Gestión de requisitos : Gestionar todas las actividades relacionadas con los requisitos desde su concepción, supervisando el desarrollo del sistema e incluso después de su puesta en funcionamiento (por ejemplo, cambios, ampliaciones, etc.).

En ocasiones, estas actividades se presentan como etapas cronológicas, aunque, en la práctica, existe una considerable interconexión entre ellas.

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

Problemas

Un estudio limitado realizado en Alemania presentó posibles problemas en la implementación de la ingeniería de requisitos y preguntó a los participantes si consideraban 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 cambiantes y la limitación del tiempo, siendo problemas menores las fallas de comunicación, la falta de trazabilidad, los problemas terminológicos y la falta de claridad en las responsabilidades. [ 5 ]

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. [ 6 ] Algunas investigaciones sugieren que es posible que, si existen deficiencias en el proceso de ingeniería de requisitos que resultan en una situación donde no existen requisitos, se pueden crear requisitos de software de todos modos como una ilusión que presenta erróneamente las decisiones de diseño como requisitos. [ 7 ]

Véase también

Referencias

  1. ↑ Royce, WW (1970). Managing the Development of Large Software Systems: Concepts and Techniques (PDF) . International Conference on Software Engineering (ICSE) '87. Proceedings of the 9th international conference on Software Engineering . pp. 1–9 . 
  2. ↑ Sommerville, Ian (2009). Ingeniería de software (9.ª ed.). Addison-Wesley . ISBN  978-0-13-703515-1.
  3. ↑ "Descubriendo requisitos con diagramas de clases UML, parte 1" . tynerblain.com . 7 de marzo de 2008. Consultado el 14 de marzo de 2018 .
  4. ↑ Hofmann, HF; Lehner, F. (2001). "Ingeniería de requisitos como factor de éxito en proyectos de software". IEEE Software . 18 (4): 58– 66. Bibcode : 2001ISoft..18d..58H . doi : 10.1109/MS.2001.936219 . ISSN 0740-7459 . 
  5. ↑ 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". Information and Software Technology . 57 : 616–643 . arXiv : 1611.04976 . doi : 10.1016/j.infsof.2014.05.008 . S2CID 1924926 . 
  6. ↑ 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}}: Para citar una revista se requiere |journal=( ayuda )
  7. ↑ Ralph, P. (septiembre de 2013). "La ilusión de los requisitos en el desarrollo de software". Requirements Engineering . 18 (3): 293– 296. arXiv : 1304.0116 . Bibcode : 2013AIPC.1516..293R . doi : 10.1007/s00766-012-0161-4 . S2CID 11499083 . 
  • Ingeniería de sistemas y software - Procesos del ciclo de vida - Ingeniería de requisitos . 2011. págs. 1–94 . doi : 10.1109/IEEESTD.2011.6146379 . ISBN  978-0-7381-6591-2.("Esta norma reemplaza a IEEE 830–1998, IEEE 1233–1998, IEEE 1362-1998 - https://standards.ieee.org/ieee/29148/5289/ ")
  • Cuerpo de conocimientos de ingeniería de sistemas
  • Manual de gestión de ingeniería de requisitos de la FAA
  • Junta Internacional de Ingeniería de Requisitos (IREB)
  • Biblioteca de recursos IBM Rational de IEEE Spectrum
Lecturas relacionadas
6 articulos
Modelo de cascadaModelo de cascadaEl modelo en cascada es una descomposición de las actividades de desarrollo en fases secuenciales lineales , lo que significa que se transmiten una...Proceso unificado racionalProceso unificado racionalEl Proceso Unificado de Rational ( RUP ) es un marco de proceso iterativo para el desarrollo de software creado por Rational Software Corporation, ...Gestión de requisitosLa gestión de requisitos es el proceso de documentar, analizar , rastrear , priorizar y acordar los requisitos, para luego controlar los cambios y ...Consejo Internacional de Ingeniería de SistemasEl Consejo Internacional de Ingeniería de Sistemas ( INCOSE ; pronunciado / ɛn - koʊsi / ) es una organización sin fines de lucro y una sociedad pr...Obtención de requisitosEn ingeniería de requisitos , la obtención de requisitos es la práctica de investigar y descubrir los requisitos de un sistema a partir de los usua...Análisis de requisitosAnálisis de requisitosEn ingeniería de sistemas e ingeniería de software , el análisis de requisitos se centra en las tareas que determinan las necesidades o condiciones...