DIRECCIÓN ACADÉMICA

Formato de entrega de evidencias

FO-205P11000-14

División: (1) INGENIERÍA EN SISTEMAS COMPUTACIONALES Grupo: (2) 361-V

Asignatura: (3) LENGUAJES Y AUTÓMATAS II Docente: (4) SCHMA
Nombre y número de control: (5)
Fecha de entrega: (6)
Competencia No.: (7) Descripción: (8)
Indicador de alcance: (9)
Evidencia de aprendizaje: (10)

¿ que es ingenieria de requisitos?

es el proceso de desarrollar una especificación de Software. Las especificaciones

pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del
sistema. Trata de los principios, métodos, técnicas y herramientas que permiten
descubrir, documentar y mantener los requisitos para sistemas basados en
computadora, de forma sistemática y repetible.

Historia de la ingeneria de requisitos

Antes de la aparición de la ingeniería de requisitos, éstos eran competencia

exclusiva del análisis de sistemas. En esta área se elaboraron algunos
métodos de desarrollo estructurado como SA/SD (análisis y diseño
estructurados) (De Marco, 1978), SADT (análisis de sistemas y técnica de
diseño) (Ross y Schoman, 1977) o SSADM (análisis estructurado de
sistema y método de diseño) (Downs et al., 1992). La idea general de todos
estos métodos consiste en comenzar analizando los requisitos mediante un
enfoque “divide y vencerás” que permita ir fraccionando el sistema en
piezas más pequeñas y después definir las funciones u objetivos que cada
parte del sistema debería realizar.
El análisis de sistemas está profundamente enraizado con los sistemas
de información, una comunidad centrada en las metodologías y el
modelado conceptual, de modo que probablemente el concepto de análisis
de los requisitos surgió ligado a los esquemas tradicionales de
descomposición funcional top-down. Los requisitos eran capturados y
listados como objetivos del usuario, y después elaborados como un
conjunto de funciones representados en diagramas de flujo de datos,
procesos SADT o cualquier otra técnica de modelado.
El enfoque de los métodos estructurados para el análisis de requisitos fue
desafiado en los 80 por las técnicas JAD (Joint Applications Development,
Desarrollo Conjunto de Aplicaciones en español) (DSDM Consortium,
1995), que trataron de superar el incómodo y lento proceso de modelado
involucrando a los usuarios en el diseño a través de reuniones, tormentas de
ideas y escenarios. El enfoque del análisis funcional top-down sería también
desafiado por la comunidad partidaria de la orientación a objetos, más
inclinada por modelar el dominio del problema antes que establecer
objetivos y funciones. Esto allanó el camino a la generación actual de
métodos orientados a objetos: ingeniería de sistemas orientados a objetos
(Jacobson et al., 1992), la técnica de modelado de objetos (Rumbaugh,
1991) y el análisis y el diseño orientados a objetos (Coad y Yourdon, 1991),
sólo por citar algunos. Más recientemente, la comunidad de la orientación a
objetos definió un estándar de desarrollo con la creación de UML y del
Proceso Unificado, aunque sin aportar nada en cuanto al análisis de
requisitos más allá de los casos de uso y escenarios.
La otra influencia de la ingeniería de requisitos la encontramos en
la ingeniería del software, una comunidad tradicionalmente interesada en
la especificación formal y en la entrega de productos software fiables, a
menudo para sistemas de telecomunicaciones en tiempo real y aplicaciones
críticas. Los ingenieros de software se encontraron con que, a pesar de
contar con detalladas especificaciones formales, algunos sistemas no eran
aceptados o fallaban en circunstancias que no habían podido predecirse.
La ingeniería de requisitos ha crecido a partir de estas áreas, a las que
además ha contribuido de manera muy significativa. Asimismo, se ha
centrado en investigar técnicas y herramientas que complementen los
métodos de ingeniería del software.

La fundación de la ingeniería de requisitos puede encontrarse en una

colección de artículos (Thayer y Dorfman, 1990) y ediciones especiales
de Transactions on Software Engineering (IEEE-TSE, 1991) (Davies y
Hsai, 1994), seguidos por las conferencias del IEEE (Filkenstein y Fickas,
1993). Estos eventos revelaron una importante diversidad de temas de
investigación y prácticas industriales que estaban más relacionados con el
qué construir que con el cómo construirlo. En 1993 Lubas, Potts y Ritcher
(Lubars et al., 1993), en el marco de una investigación sobre las prácticas
de ingeniería de requisitos en las empresas, expusieron que los requisitos
ambiguos y cambiantes constituían un problema constante y que los
desarrolladores preferían soluciones organizacionales antes que
tecnológicas para hacer frente a los problemas relacionados con la
ingeniería de requisitos. Más recientemente, algunos estudios de campo (El
Emam y Madhavji, 1995) han determinado que la falta de personal
cualificado y los métodos inadecuados son responsables de posteriores
defectos en los sistemas.