Please enable JavaScript.
Coggle requires JavaScript to display documents.
Ingeniería de Requerimientos - Coggle Diagram
Ingeniería de Requerimientos
1.Ingeniería de Requerimientos
Definición 2
Un requerimiento es una característica del sistema o una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito del sistema, lo que ha sido apropiadamente documentado y validado por el solicitante. Los requerimientos tratan exclusivamente sobre los fenómenos del dominio de aplicación y no sobre la máquina que los implementa.
Definición 3
Un requerimiento funcional describe una interacción entre el sistema y su ambiente. Los requerimientos funcionales describen cómo debe comportarse el sistema ante un estímulo.
Definición 1
El proceso para establecer los servicios que el sistema debería proveer y las restricciones bajo las cuales debería operar y ser desarrollado, se llama Ingeniería de Requerimientos.
Definición 4
Un requerimiento no funcional es una restricción sobre el sistema o su proceso de producción.
¿Qué es?
La ingeniería de Requerimientos es la segunda fase estipulada en el ciclo de vida de cascada. Según este modelo de ciclo de vida, es necesario contar con los requerimientos para poder definir el Modelo Estructural del sistema (es decir, la arquitectura y el diseño). Sin embargo, usualmente es imposible contar con todos los requerimientos del sistema en un tiempo razonable, por lo que en la mayoría de los desarrollos se comienza a definir el Modelo Estructural teniendo en cuenta solo algunos requerimientos.
1.1.Relación de los requerimientos con otros documentos
Se refiere a
El diseño y la especificación del sistema se obtienen a partir de los requerimientos. A su vez, el diseño y la especificación se utilizan para implementar el programa. Finalmente, los requerimientos son el documento esencial para llevar adelante el testing de aceptación. De estas relaciones surge claramente que la calidad de los requerimientos tiene una influencia enorme sobre el éxito o fracaso del proyecto, puesto que de ellos dependen los documentos claves del desarrollo.
por lo tanto
En consecuencia, cuanto mayor calidad tengan los requerimientos mayores son las posibilidades de que el proyecto sea un éxito. De esta observación podría concluirse que cuanto más tiempo y recursos se dediquen a esta etapa, mejor será para el proyecto.
1.3.La importancia de los requerimientos
Se refiere a
Si bien la importancia de los requerimientos es bastante obvia creemos que es conveniente resaltar algunas cuestiones específicas por lo que reproducimos aquí, casi textualmente. En 1994 el Standish Group realizó un estudio sobre 8.000 proyectos de software con el objetivo de determinar el grado de éxito de cada uno de ellos. Los resultados fueron bastante desalentadores: el 31 % de los proyectos fueron cancelados antes de ser terminados, en las grandes compañías solo el 9 % de los proyectos fueron entregados dentro del plazo y presupuesto predefinidos y el 16 % en las pequeñas y medianas. A raíz de estos descubrimientos, un año más tarde Standish Group realizó otro estudio para determinar las causas de semejante fracaso.
Los resultados fueron los siguientes:
Requerimientos incompletos (13,1 %)
Falta de compromiso del usuario (12,4 %)
Falta de recursos (10,6 %)
Expectativas no realistas (9,9 %)
Falta de soporte ejecutivo (9,3 %)
Requerimientos y especificaciones cambiantes (8,7 %)
Falta de planeamiento (8,1 %)
Fin de la necesidad del sistema (7,5 %)
1.2.El límite de la Ingeniería de Requerimientos
Existe un límite fundamental, y sobre todo inherente a la construcción de software, que afecta a la Ingeniería de Requerimientos. Este límite puede expresarse de la siguiente forma: es virtualmente imposible iniciar la construcción de un sistema de software teniendo la lista completa y consistente de todos los requerimientos, en un tiempo razonable.
Justificantes
Usualmente se requiere que los grandes sistemas de software constituyan una superación del estado del arte en cierto dominio de aplicación.
Los grandes sistemas normalmente son utilizados por una comunidad de usuarios muy diversos. Esto implica que cada grupo de usuarios planteará expectativas y requerimientos diferentes sobre el sistema.
En general la gente que paga por el sistema y quienes lo usan no son los mismos, lo que genera conflictos entre lo que se puede pagar y lo que se necesita.
La introducción de un sistema de software importante en una organización es tan disruptiva que suele producir cambios igualmente importantes en la organización lo que, a su vez, genera nuevos requerimientos sobre el sistema.
El entorno en el cual se instala y opera el sistema cambia por lo que el sistema debe cambiar también.
El negocio de la empresa productora del software suele cambiar por lo que sus ejecutivos solicitan nuevas funciones o cualidades al sistema.
