2.

Captulo 2 Marco Terico 2.1.Antecedentes de la Ingeniera de Requerimientos Antes de la aparicin de la ingeniera de requisitos, stos eran competencia exclusiva del anlisis de sistemas. En esta rea se elaboraron algunos mtodos de desarrollo estructurado como SA/SD (anlisis y diseo estructurados) (De Marco, 1978), SADT (anlisis de sistemas y tcnica de diseo) (Ross y Schoman, 1977) o SSADM (anlisis estructurado de sistema y mtodo de diseo) (Downs et al., 1992). La idea general de todos estos mtodos consiste en comenzar analizando los requisitos mediante un enfoque divide y vencers que permita ir fraccionando el sistema en piezas ms pequeas y despus definir las funciones u objetivos que cada parte del sistema debera realizar. El anlisis de sistemas no era suficientemente bueno? Era realmente necesaria una nueva sub-disciplina como la ingeniera de requisitos? Parte de la respuesta hay que encontrarla en la comunidad acadmica. El anlisis de sistemas est profundamente enraizado con los sistemas de informacin, una comunidad centrada en las metodologas y el modelado conceptual, de modo que probablemente el concepto de anlisis de los requisitos surgi ligado a los esquemas tradicionales de descomposicin funcional top-down. Los requisitos eran capturados y listados como objetivos del usuario, y despus elaborados como un conjunto de funciones representadas en diagramas de flujo de datos, procesos SADT o cualquier otra tcnica de modelado. El enfoque de los mtodos estructurados para el anlisis de requisitos fue desafiado en los 80 por las tcnicas JAD (Joint Applications Development, Desarrollo Conjunto de Aplicaciones en espaol) (DSDM Consortium, 1995), que trataron de superar el incmodo y lento proceso de modelado involucrando a los usuarios en el diseo a travs de reuniones, tormentas de ideas y escenarios. El enfoque del anlisis funcional top-down sera tambin desafiado por la comunidad partidaria de la orientacin a objetos, ms inclinada por modelar el dominio del problema antes que establecer objetivos y funciones. Esto allan el camino a la generacin actual de mtodos orientados a objetos: ingeniera de sistemas orientados a objetos (Jacobson et al., 1992), la tcnica de modelado de objetos (Rumbaugh, 1991) y el anlisis y el diseo orientados a objetos (Coad y Yourdon, 1991), slo por citar algunos. Ms recientemente, la comunidad de la orientacin a objetos defini un estndar de desarrollo con la creacin de UML y del Proceso Unificado, aunque sin aportar nada en cuanto al anlisis de requisitos ms all de los casos de uso y escenarios. La otra influencia de la ingeniera de requisitos la encontramos en la ingeniera del software, una comunidad tradicionalmente interesada en la especificacin formal y en la entrega de productos software fiables, a menudo para sistemas de telecomunicaciones en tiempo real y aplicaciones crticas. 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 haban podido predecirse.

La ingeniera de requisitos ha crecido a partir de estas reas, a las que adems ha contribuido de manera muy significativa. Asimismo, se ha centrado en investigar tcnicas y herramientas que complementen los mtodos de ingeniera del software. La fundacin de la ingeniera de requisitos puede encontrarse en una coleccin de artculos (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 investigacin y prcticas industriales que estaban ms relacionados con el qu construir que con el cmo construirlo. En 1993 Lubas, Potts y Ritcher (Lubars et al., 1993), en el marco de una investigacin sobre las prcticas de ingeniera de requisitos en las empresas, expusieron que los requisitos ambiguos y cambiantes constituan un problema constante y que los desarrolladores preferan soluciones organizacionales antes que tecnolgicas para hacer frente a los problemas relacionados con la ingeniera de requisitos. Ms recientemente, algunos estudios de campo (El Emam y Madhavji, 1995) han determinado que la falta de personal cualificado y los mtodos inadecuados son responsables de posteriores defectos en los sistemas. 2.1.1 Historia, precursores y situaciones generadores de la IR 2.2. Estado del Arte 2.2.1 Requerimientos de proceso Requerimiento: atributo necesario dentro de un sistema que puede presentar una capacidad, una caracterstica o un factor de calidad del sistema de tal manera que le sea til a los clientes o a los usuarios finales. Los requerimientos pueden clasificarse como indicados o reales, los primeros son los entregados por el usuario al comienzo del proyecto y los reales son los que reflejan la satisfaccin de las necesidades del usuario La ingeniera de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solucin sin ambigedad, validando la especificacin y registrando los requisitos para que se transformen en un sistema operacional. Los requerimientos para un sistema de software determinan lo que har el sistema y definen las restricciones de su operacin e implementacin. El proceso de ingeniera de requisitos puede ser descrito en 5 pasos distintos: 1. Identificacin de requisitos. 2. Anlisis de requisitos y negociacin. 3. Especificacin de requisitos. 4. Modernizado del sistema. 5. Validacin y gestin de requisitos. El ingeniero en sistemas establece los servicios que el cliente requiere de un sistema y los lmites bajo los cuales operara y como se desarrolla este. Requerimiento: Es un rango de instrucciones abstractas de alto nivel de un servicio o de un sistema limitado a detallar una especificacin funcional.

Ingeniera de requerimientos: se define como un conjunto de actividades en las cuales, utilizando tcnicas y herramientas, se analiza un problema y se concluye con la especificacin de una solucin. Los requerimientos pueden ser funcionales o no funcionales. Los requerimientos funcionales describen servicios o funciones. Los requerimientos no funcionales son un lmite en el sistema o en el proceso de desarrollo. Procesos de la ingeniera de requerimientos: 1. Estudio de factibilidad. 2. Anlisis de requerimientos. 3. Definicin de requerimientos. 4. Especificacin de requerimientos. 2.2.2 Requerimientos de los usuarios (actores involucrados) Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar. Describen los requerimientos funcionales son los que mencionan las funciones que

el sistema va a hacer. Estos requerimientos dependen del tipo de software que se desarrolla, los posibles usuarios del software y del enfoque en la organizacin al redactar los requerimientos; los requerimientos funcionales del sistema describen con detalle la funcin de este, sus entradas y salidas, excepciones, etc. Y no funcionales son aquellos requerimientos que no se refieren directamente las funciones especificas que proporciona el sistema, si no a las propiedades emergentes, como son la fiabilidad, el tiempo de respuesta del sistema y la capacidad de almacenamiento. De forma alternativa define las restricciones del sistema de los dispositivos de entrada y salida. De tal forma que sean
comprensibles por los usuarios del sistema que no posean un conocimiento tcnico detallado. nicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las caractersticas de diseo del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementacin. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos. Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural: falta de claridad, confusin de requerimientos y conjuncin de requerimientos. Los requerimientos del sistema Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificacin funcional, debe ser preciso. ste sirve como un contrato entre el comprador del sistema y el desarrollador del software. Son descripciones ms detalladas de los requerimientos del usuario. Sirven como base para definir el contrato de la especificacin del sistema y, por lo tanto, debe

ser una especificacin completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseo del sistema. La especificacin de requerimientos del sistema incluye diferentes modelos del sistema como el de objetos o el de flujo de datos. En principio, los requerimientos del sistema debern establecer lo que ste har y no la manera en que se implementar. Sin embargo, en el nivel de detalle requerido para especificar el sistema completamente, es casi imposible excluir toda la informacin de diseo. Una especificacin del diseo del software Es una descripcin abstracta del diseo del software, que es una base para un diseo e implementacin detallados; agrega detalle a la especificacin de requerimientos del sistema. 2.2.3 Requerimientos para el anlisis y negociacin

2.2.4 Requerimientos para la gestin

La gestin de requisitos es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto. La gestin de requisitos comienza con la identificacin. Cada requerimiento se asigna a un solo identificador. Una vez identificados se desarrollan las tablas de rastreabilidad, cada una de ellas relacionan los requisitos con uno o mas aspectos del sistema. Entre las muchas tablas de rastreabilidad posibles estn las siguientes: Tablas de rastreabilidad de la fuente.- identifica la fuente de cada requisito. Tabla de rastreabilidad de dependencia.- indican la forma en que los requisitos estn relacionados entre si. Tabla de rastreabilidad del subsistema.- establece categoras entre los requisitos de acuerdo con los sistemas que gobiernan. Tabla de rastreabilidad de la interfaz.-muestra la forma en que los requisitos se relacionan con las interfaces internas y externas del sistema. En muchos casos, estas tablas de rastreabilidad se mantienen como parte de la base de datos de los requisitos de forma que pueda buscrseles con rapidez para entender como el cambio en un requisito afectara diferentes aspectos del sistema que se construir.

2.2.5 Herramientas en el mercado para el manejo de Requerimientos 2.2.6 Anlisis de Riesgo 2.2.6.1 Diferentes Metodo Requerimientos funcionales

Describen las funciones que el sistema va a hacer. Estos requerimientos dependen del tipo de software que se desarrolla, los posibles usuarios del software y del enfoque en la organizacin al redactar los requerimientos; los requerimientos funcionales del sistema describen con detalle la funcin de este, sus entradas y salidas, excepciones, etc. Requerimientos no funcionales Son aquellos requerimientos que no se refieren directamente las funciones especificas que proporciona el sistema, si no a las propiedades emergentes, como son la fiabilidad, el tiempo de respuesta del sistema y la capacidad de almacenamiento. De forma alternativa define las restricciones del sistema de los dispositivos de entrada y salida
logas de anlisis de riesgo 2.2.7 Aseguramiento de la Calidad (Control de Calidad) 2.2.7.1 Diferentes metodologas de aseguramiento y control de calidad 2.2.8 Estndar IEEE 830 REFERENCIAS 1. Para terminar, algunas referencias bibliogrficas interesantes que he citado durante el post: 2. Coad, P., y Yourdon, E. E. (1991). Object-oriented analysis. Englewood Cliffs, NJ: Yourdon Press. 3. Davies, A. M., y Hsai, P. (1994). Proceedings IEEE International Conference on Requirements Engineering . 4. De Marco, T. (1978). Structured analysis and systems specification.Englewood, NJ: Prentice Hall. 5. Downs, E., Clase, P., y Coe, I. (1992). Structured systems analysis and design method: Application and context (2 edicin ed.). Nueva York: Prentice Hall. 6. DSDM Consortium. (1995). Dynamic Systems Development Method.Farnham Surrey: Tesseract Publishers. 7. El Emam, K., y Madhavji, N. H. (1995). A field study of requirements engineering practices in information systems development. Proceedings on 1995 IEEE International Symposium on Requirements Engineering (RE95) . 8. Filkenstein, A. C., y Fickas, S. (1993). Proceedings on 1993 IEEE International Symposium on Requirements Engineering (RE93). 9. Lubars, M., Potts, C., y Ritcher, C. (1993). A review of the state of the proactive in requirement modeling. Proceedings 1st International Symposium on Requirements Engineering. 10. Ross, D. T., y Schoman, K. E. (1977). Structured analysis for requirements definition. IEEE Transactions on Software Engineering (3), 23-47. 11. Rumbaugh, J. (1991). Object oriented modelling and design. Englewood Cliffs, NJ: Prentice Hall.

12. Thayer, y Dorfman. Engineering. IEEE.

(1990). Systems

and

Software

Requirements