Ingeniería de Software V Ingeniería de requerimientos Notas de clase Panorama de la Ingeniería de Requisitos: sus fundamentos y avances

Transcripción

1 Facultad de Tecnología Informática Ingeniería en Informática Ingeniería de Software V Ingeniería de requerimientos Notas de clase Panorama de la Ingeniería de Requisitos: sus fundamentos y avances Recopilación: Dra. Graciela D. S. Hadad

2

3 Facultad de Tecnología Informática Ingeniería de Software V Ingeniería de Requerimientos Notas de Clase Panorama de la Ingeniería de Requisitos: sus fundamentos y avances Dra. Graciela D. S. Hadad 2011

4 Índice Pág. 1 La importancia de los requisitos en el desarrollo del software Evolución de los errores en el proceso de desarrollo de software Evolución de los requisitos La Ingeniería de Requisitos en el contexto de la Ingeniería de Software Puntos clave de la Ingeniería de Requisitos Principales iniciativas en la Ingeniería de Requisitos Estándares para especificar requisitos Estándares de calidad en el proceso de IR Congresos dedicados a esta disciplina Revistas y libros dedicados al tema Herramientas comerciales que soportan actividades de la IR El proceso de Ingeniería de Requisitos Referencias UB FTI Ingeniería de Requerimientos

5 1 La importancia de los requisitos en el desarrollo del software La clave del éxito o fracaso de un proyecto de software depende fuertemente de resolver el problema correcto (Rumbaugh, 1994), es decir, encontrar el conjunto de soluciones adecuadas al problema en el universo de discurso 1. Para lo cual, se debe primero capturar las demandas, necesidades y problemas existentes en el universo de discurso y luego determinar que los requisitos especificados sean los correctos. Ya en la década anterior Frederick Brooks anunciaba en su artículo No Silver Bullet (Brooks, 1987): «The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.» Los errores en los requisitos incrementan altamente los costos de desarrollo y mantenimiento de los sistemas de software, dado que la corrección de los mismos puede involucrar desde simples adaptaciones al código, el rediseño de algún componente o hasta reformular total o parcialmente la solución propuesta. Los costos por corrección de errores en los requisitos se incrementan en cada fase de desarrollo del software. La incidencia del costo de 1 Universo de discurso: todo el contexto en el cual el software se desarrolla e incluye todas las fuentes de información y toda la gente relacionada con el software. Es la realidad acotada por el conjunto de objetivos establecidos por quienes demandan una solución de software. Las personas involucradas en el proceso de desarrollo son principalmente: usuarios, clientes, ingenieros de software, expertos del dominio. UB FTI Ingeniería de Requerimientos

6 corrección de requisitos erróneos ha sido ampliamente estudiada por autores como Michael Fagan (1974), Barry Boehm (1976), Bell y Thayer (1976), Edmund Daly (1977), Basili y Weiss (1981) y Alan Davis (1993) entre otros. Barry Boehm (1981) estudió varios proyectos de desarrollo de software de gran envergadura para determinar el costo de corrección de errores en los requisitos, errores que eran descubiertos tardíamente en el proceso de desarrollo (ver Tabla 1). Como se observa en la Tabla 1, el costo relativo de reparar un requisito erróneo que permanece sin ser detectado hasta la etapa de operación puede costar hasta 100 veces más que si fuera detectado y corregido en la fase de requisitos. En un estudio más reciente, Joseph Carr (2000) mostró que la mayoría de estos números siguen siendo válidos. Fase donde se detectó el error Costo promedio Definición de Requisitos 1 Diseño 3-6 Codificación 10 Pruebas de desarrollo Prueba de aceptación Operación Tabla 1. Costo relativo de corrección de un error, Boehm (1981) Se puntualiza a continuación los aspectos a considerar en los errores en los requisitos, Alan Davis (1993): i) Cuanto más tarde en el ciclo de vida se detecta un error, más costoso es repararlo. El crecimiento de los costos de reparación es producto de la catarata de errores que se producen: errores originados en una etapa se arrastran en fases sucesivas más nuevos errores que se originan en cada una de ellas. Modelo Mizuno (1983) (ver Figura 1) UB FTI Ingeniería de Requerimientos

7 ii) Muchos errores permanecen latentes y no son detectados hasta bastante después de la etapa en que se cometieron. El 54% de los errores se detectan después de la fase de codificación y prueba. Estos errores provienen en un 45% de la fase de requisitos y en un 9% de la fase de codificación. Barry Boehm (1975) iii) Se están cometiendo demasiados errores. El 56% de los errores tienen su origen en la etapa de requisitos. Informado por Tom DeMarco, citado en Tavolato y Vincena (1984) iv) Los errores de requisitos responden a una clasificación típica. hechos incorrectos 49% omisiones 31% inconsistencias 13% ambigüedades 5% otros (requisitos mal ubicados) 2% Basili y Weiss (1981) v) Los errores en los requisitos pueden detectarse. La detección puede realizarse a través de distintas técnicas: ad hoc, inspecciones (muy alta efectividad), testeos (pruebas individuales), pruebas de integración, evaluación (pruebas de aceptación), otros. Las inspecciones detectan el 65% de errores, el testeo de unidades: 10%, integración: 6%, evaluación: 10%, otros: 10% Alan Davis (1993) UB FTI Ingeniería de Requerimientos

8 Los puntos recién mencionados se pueden resumir en las siguientes conclusiones, Davis (1993): Se cometen muchos errores de requisitos. Muchos de esos errores se detectan tardíamente. Sin embargo, muchos de esos errores pueden detectarse tempranamente. El no detectar errores contribuye al incremento de costos en el software. Diversas estadísticas realizadas a lo largo de las últimas décadas referidas a fracasos en proyectos de software (Alford y Lawson, 1979) (Boehm, 1981) (GAO, 1992) (Faulk, 1992) (Lutz, 1993) (CHAOS, 1995) concluyen que los requisitos son la fuente principal de problemas en la mayoría de dichos proyectos: requisitos inadecuados, cambios en los requisitos durante el ciclo de vida, requisitos no bien comprendidos, requisitos incompletos, etc. En 1987, el Departamento de Defensa de los Estados Unidos generó un informe (Brooks, 1987b) sobre los problemas de calidad y productividad en el desarrollo de software militar, que abrió las puertas para la investigación de la llamada crisis del software, ya reconocida desde fines de la década del 60. Paralelamente, acaecieron en la práctica industrial fracasos paradigmáticos en proyectos de gran envergadura, tales como el Sistema de Control del Tráfico Aéreo de la Administración Federal de Aviación (Gibbs, 1994) (Stix, 1994), el Sistema de Administración de Equipaje del Nuevo Aeropuerto Internacional de Denver (GAO, 1994), el Sistema de Ambulancias de Londres (Finkelstein y Dowell, 1996), el Sistema de tiempo real de Paramax System Corporation (Lindstrom, 1993). Algunos de los casos más recientes que se pueden mencionar son: el Sistema de Reservas del Ferrocarril Nacional francés (dos días fuera de uso por defectos en la actualización de un programa, 2004), el Sistema de Gestión de Energía de General Electric (causó un apagón en el noreste de Estados Unidos UB FTI Ingeniería de Requerimientos

9 y parte de Canadá, debido a un error de programación en el sistema de gestión y monitoreo de energía de un proveedor, 2003), el software de la Estación Espacial Internacional (varios problemas como la operación de un brazo del robot de la estación, 2001), el programa de simulación del puente Millenium en Londres (falló debido a una incorrecta estimación de la cantidad de peatones, 2000), entre otros muchos. 2 Evolución de los errores en el proceso de desarrollo de software Habitualmente cuando se hace referencia a errores en los requisitos de los sistemas se desliza en forma tácita la idea de que el profesional de software o el proceso de captura han sido el origen de los mismos. Esta suposición, si bien muy difundida, probablemente sea parcialmente falsa ya que muchos de los errores, discrepancias y omisiones que aparecen en los requisitos y naturalmente se propagan al sistema final, ya existían en la fuente de información. En realidad existe una responsabilidad compartida, ya que en los casos en que el defecto está empotrado en la fuente de información, el ingeniero de requisitos tiene algún grado de responsabilidad al no ponerlo en evidencia, especialmente en relación con las discrepancias y omisiones. Mizuno (1983) propuso un modelo para las cataratas de errores que se presenta en la Figura 1. Este gráfico es notoriamente ilustrativo para comprender el problema de la propagación y la ampliación de los errores a lo largo del proceso de desarrollo de software, aunque contiene varias simplificaciones que enmascaran algunos aspectos relevantes de la problemática de la Ingeniería de Requisitos (IR). El punto más importante parece ser la visión del problema real como una entidad fuente de todo saber y verdad. No existe un problema real perfecto que determine unívocamente los requisitos del sistema de software. Por el UB FTI Ingeniería de Requerimientos

10 contrario, el problema real reside en que las organizaciones no son completas ni coherentes (Godel, 1962). Además, las fuentes de información introducen sus propias contradicciones, sesgos, errores y extemporalidades que obscurecen un poco más la percepción de las necesidades del negocio. Problema Real Definición de Requisitos Especificación correcta Especificación errónea Diseño Diseño correcto Diseño erróneo Diseño basado en especificación errónea Implementación Programas correctos Programas con Programas basados Programas basados en diseño erróneo en especificación errores errónea Prueba Funciones correctas Errores corregibles Errores incorregibles Errores escondidos Producto con Programas Imperfectos Figura 1. Catarata de Errores según el Modelo Mizuno (1983) El meta-modelo conceptual que supone un problema real perfecto, asigna además todas las dificultades a: i) la inhabilidad de las fuentes de información para revelar el conocimiento profundo, y ii) la inhabilidad del ingeniero de requisitos para capturar la información relevante y sin omisiones. El problema real es un agregado de certezas, contradicciones, dudas y aspectos no planteados. En otras palabras, sí hay información directamente UB FTI Ingeniería de Requerimientos

11 transformable en requisitos del sistema de software, pero hay mucho más que eso. La tarea del ingeniero de requisitos es mucho más compleja que meramente sonsacar los requisitos, también debe colaborar con el esclarecimiento de las dudas, debe detectar las contradicciones y visualizar las circunstancias no consideradas, entre otras. Adicionalmente, el ingeniero de requisitos contribuye con propuestas de servicios del sistema que en algunos casos complementan la información adquirida y en algunos otros ofrece algún antagonismo con la misma. Los requerimientos, pedidos y demandas de los usuarios son idealmente realizados en el contexto del objetivo de obtener una mejora en los procesos del negocio. Decimos idealmente porque pueden insertarse intereses personales no claramente explicitados o eventualmente cuidadosamente ocultos. Por otro lado, las propuestas del ingeniero de requisitos están guiadas por la aspiración de facilitar el desarrollo del artefacto de software, ya sea simplificando el sistema o dotándolo de propiedades que lo acerquen a modelos conceptuales preconcebidos. En la Figura 2 2, se presenta un esquema que extiende el modelo de Mizuno, visualizando el problema real como un agregado de certezas, contradicciones, dudas y aspectos no considerados. En este esquema además se representa el hecho de que las fuentes de información aportan su propia distorsión dificultando, en alguna medida, aún más el proceso de definición de los requisitos del sistema de software. La Figura 2 fue confeccionada siguiendo el estilo de la figura original de Mizuno, por lo que conserva las mismas simplificaciones que la original, excepto las ya indicadas modificaciones en la visión del problema real. En ese sentido, el esquema no refleja que sobre los requisitos erróneos se puedan además acumular errores de diseño (sólo se comenten errores de diseño sobre los requisitos correctos) y que los errores de programación se concentran en los fragmentos del sistema correctamente diseñados. Por otra parte, en ambas 2 En la Figura 2 solo se muestra la apertura en actividades de la fase Definición de Requisitos por razones de espacio. UB FTI Ingeniería de Requerimientos

12 figuras también se ignora que una actividad de validación forzaría, con un alto costo, la corrección de los errores incorregibles ; así como descubriría en mayor o menor grado los errores escondidos, también con altos costos de corrección. Problema Real Certezas Inconsistencia Dudas Aspectos no considerados Elicitación Demandas correctas Demandas erróneas Demandas inconsistentes Demandas omitidas Modelado Requisitos candidatos correctos Propuestas correctas Requisitos candidatos erróneos Propuestas erróneas Requisitos basados en demandas erróneas Requisitos basados en demandas inconsistentes Requisitos omitidos Especificación Especificación correcta Especificación errónea Especificación basada en requisitos erróneos Especific. basada en propuestas erróneas Especific. basada en demandas erróneas Especific. basada en demandas inconsistentes Especificación omitida Producto con Programas Imperfectos Figura 2. Catarata de Errores extendiendo el Modelo Mizuno 3 Evolución de los requisitos La Ingeniería de Software desde sus comienzos ha propuesto métodos para facilitar los cambios en el software (Lehman y Belady, 1985) (Lehman, 1991), desde los métodos estructurados, ocultando información en módulos hasta los métodos orientados a objetos encapsulando comportamiento en clases. Los cambios no son algo ocasionales sino que, muy por el contrario, ocurren constantemente durante todo el ciclo de vida del software. Como bien UB FTI Ingeniería de Requerimientos

13 menciona Leite (1997): «el cambio es una propiedad intrínseca al software», y por lo tanto merece una consideración especial en el proceso de desarrollo, que es la administración de dichos cambios. Desde la perspectiva de la IR, esta actividad se denomina gestión de requisitos. Los requisitos evolucionan registrando los cambios que el universo de discurso impone al software. Estadísticas realizadas marcan que el 50% o más de los requisitos van a cambiar antes que el sistema de software se ponga en operación (Kotonya y Sommerville, 1998). Es por esta razón que se pone énfasis en especificaciones dinámicas de requisitos precisos y claros que acompañen los cambios del universo de discurso y que permitan el seguimiento de los mismos desde cualquier punto del proceso de producción del software hasta sus orígenes. Debe considerarse cuál es el origen de estos cambios en el software. Son estos cambios realmente genuinos, es decir, surgen como consecuencia de cambios en el universo de discurso o provienen de requisitos descubiertos tardíamente? Es frecuente que algunos requisitos se descubran parcialmente o no salgan a la luz hasta avanzado el desarrollo, cuando los diseñadores o inclusive los programadores deben realizar tareas a muy bajo nivel de detalle y se chocan con ambigüedades, contradicciones u omisiones. En estos casos, la esencia del cambio no corresponde a un mundo en evolución sino a requisitos no descubiertos oportunamente. Con respecto a los cambios reales en el universo de discurso, no sólo se deben a cambios externos o internos a la organización como consecuencia de factores políticos, económicos, legales, sociales o tecnológicos, sino muchas veces a un cambio en las expectativas de los mismos clientes y usuarios una vez que ven más claramente las posibilidades que permitirá el sistema de software. Lehman (1980) va más allá expresando que un sistema una vez instalado se convierte en parte del universo de discurso alterándolo y, por ende, él mismo (el software) altera sus propios requisitos. UB FTI Ingeniería de Requerimientos

14 En general, las estadísticas realizadas sobre la evolución de los requisitos no discriminan adecuadamente el origen de los cambios en el desarrollo del software, y simplemente lo adjudican a la evolución del universo de discurso (Yeh y Ng, 1990) (Kotonya y Sommerville, 1996) (Madhavji, 1997) (Goedicke et al., 1999). Lientz y Swanson (1978) determinaron que los cambios en el software durante su mantenimiento se debían en un 80% a cambios en los requisitos y el restante 20% a correcciones de errores. Sin embargo, no se discrimina en estos valores cuántas de las correcciones de errores se debían a requisitos con defectos ni cuántos de los cambios en los requisitos eran por la naturaleza evolutiva del universo de discurso o por defectos en los requisitos (requisitos descubiertos tardíamente o requisitos mal interpretados). Un estudio más reciente sobre mantenimiento de software (Pigoski, 1996) informa que alrededor del 55% de los pedidos de cambio corresponden a requisitos nuevos o cambios en requisitos por mejoras, mientras que un 25% son cambios técnicos por adaptaciones. Desde ya que existen universos de discurso donde predomina una evolución constante, tal es el caso por ejemplo del dominio de las telecomunicaciones. También es el caso de desarrollos de sistemas grandes, complejos donde es inevitable que haya múltiples versiones que derivan tanto de cambios planeados por mejoras como de cambios no planeados por evolución del universo de discurso. Por otro lado, el descubrimiento tardío de requisitos se debe en muchos casos a procesos de producción débiles con pocas guías y poca disciplina, donde se requiere la generación rápida del artefacto de software y los requisitos se descubren a medida que se implementa parcialmente el software, tal es el caso en el dominio del comercio electrónico donde hay una fuerte competencia. Es también muy común que el descubrimiento tardío corresponda a requisitos no funcionales, cuando éstos no son atendidos adecuadamente durante la definición de requisitos (Cysneiros y Leite, 1999). Un requisito no funcional no capturado oportunamente puede obligar a muchos cambios en otros requisitos tanto funcionales como no funcionales. UB FTI Ingeniería de Requerimientos

15 De lo mencionado hasta ahora, cabe destacar dos cuestiones: i) La visión del Modelo de Mizuno (Figura 1) y la visión extendida del mismo (Figura 2) son estáticas. Ambas consideran que los procesos del negocio no cambian durante el período de desarrollo del software. ii) La visión muy difundida de la evolución de los requisitos se basa en un único componente: el cambio del universo de discurso, pero prácticamente omite un segundo componente: los requisitos descubiertos o comprendidos tardíamente. Es obvio que este último componente produce también modificaciones en los requisitos, y lo hace con mucha mayor frecuencia de lo mencionado en la literatura. Michael Jackson (1994) afirma que sobre los requisitos se saben dos cosas: 1) van a cambiar y 2) van a ser mal comprendidos. Problema Real Certezas Dudas Inconsistencias Aspectos no considerados Tiempo de desarrollo Elicitación Modelado Requisitos Propuestas candidatos correctas correctos Especificación Especificación correcta Especificación errónea Demandas correctas Requisitos candidatos erróneos Demandas erróneas Propuestas erróneas Especificación Especific. basada basada en en propuestas requisitos erróneos erróneas Demandas inconsistentes Requisitos basados en demandas erróneas Especific. basada en demandas erróneas Demandas omitidas Requisitos basados en demandas inconsistentes Especific. basada en demandas inconsistentes Requisitos omitidos Especificación omitida Producto con Programas Imperfectos Figura 3. Evolución de los Errores + Evolución de los Requisitos UB FTI Ingeniería de Requerimientos

16 En la Figura 3 se muestra la incorporación de la noción de evolución de requisitos a la Figura 2, donde se presenta un eje relativo al tiempo de desarrollo del software y otro relativo al tiempo de los cambios durante el desarrollo mismo. El proceso de la IR (ver sección 7) tiene sentido en organizaciones con una estabilidad aceptable en sus procesos del negocio. En organizaciones con estrategias o procesos del negocio inestables a muy inestables, hay que pensar en métodos ágiles de desarrollo de software, pues cuál es el sentido de modelar requisitos que cambian más rápido que el tiempo necesario para documentarlos. Los sistemas de software son un factor de estabilización de los procedimientos de la organización, por lo tanto, es natural que el proceso de desarrollo del software tenga un cierto grado de conflicto con la tendencia a la variación de estas organizaciones. En organizaciones con cambios constantes, los sistemas de software se ven sumidos en un mantenimiento permanente e incremental a medida que nuevos componentes de software se van instalando. 4 La Ingeniería de Requisitos en el contexto de la Ingeniería de Software La Ingeniería de Requisitos (IR) es una disciplina que procura sistematizar el proceso de definición de requisitos. Es decir, apunta a mejorar la forma en que comprendemos y definimos sistemas de software complejos. La complejidad de los sistemas exige que se preste más atención al correcto entendimiento del problema antes de comprometer una solución. La IR cubre todas las actividades involucradas en descubrir, documentar, analizar y mantener un conjunto de requisitos para un sistema de software. UB FTI Ingeniería de Requerimientos

17 Aunque el problema de cómo establecer sistemas no es nuevo, sólo recientemente la comunidad científica de computación, principalmente la comunidad de Ingeniería de Software, comenzó a prestar especial atención a la tarea de definición de requisitos. El término Ingeniería de Requisitos ( Requirements Engineering ) surgió formalmente publicado recién en Enero de 1977 en IEEE Transactions on Software Engineering. La primera conferencia internacional sobre este tema fue en 1993 (RE 93) y en 1995 se realizó la primera reunión del grupo de trabajo IFIP 2.9 (Ingeniería de Requisitos de Software). La Ingeniería de Software ha estado prestando demasiada atención al modelado e implementación de productos, pero la IR comenzó examinando los aspectos de la generación de requisitos y su intrínseca dependencia de los aspectos sociales que rodean la construcción del software y que rodearán su operación. La IR tiene una interacción muy fuerte con aquellos que demandan un producto de software. Por lo tanto, el proceso de la IR es un esfuerzo cooperativo que involucra a usuarios, clientes, ingenieros de software, consultores, expertos, entre otros, denominados en la literatura involucrados 3. La IR debe entonces achicar la brecha entre el usuario que tiene necesidades y requiere soluciones a sus problemas, pero que no tiene los conocimientos para especificar los requisitos, y el ingeniero de software que sí tiene dichos conocimientos técnicos pero desconoce el mundo del usuario con sus problemas y necesidades. De lo dicho, surgen dos aspectos ineludibles en un proceso de IR exitoso: i) garantizar una buena comunicación entre ambas partes, y ii) comprender cabalmente el mundo del usuario. Lo primero se logra cuando el ingeniero de software comprende el vocabulario que maneja el usuario. Para lo segundo, el ingeniero de software requiere utilizar técnicas específicas que ayuden a obtener información de ese mundo 3 Es la traducción en castellano que se emplea de la palabra stakeholders. UB FTI Ingeniería de Requerimientos

18 (técnicas de elicitación 4 ) y que faciliten determinar si la comprensión lograda es correcta (técnicas de Verificación y Validación). Cabe destacar que cuando la fuente de información son las personas, éstas muchas veces no saben o no pueden o no quieren expresar claramente sus necesidades, o lo que es peor aún, pueden ni siquiera ser concientes de ellas. En resumen, la necesidad de asegurar una buena comprensión entre los ingenieros de requisitos y los usuarios (en general, entre todos los involucrados) ha inducido al desarrollo de métodos que permitan la colaboración entre todos los participantes del proceso de definición de requisitos. Los ingenieros de requisitos deben comprender, modelar y analizar el universo de discurso donde el software operará y los usuarios deben confirmar que la visión de los ingenieros es correcta. Estos requisitos deben contemplar las necesidades de los usuarios, las reglas de la organización y las reglas externas próximas al universo de discurso. Debido a la baja calidad de los productos de software con altos costos de corrección y mantenimiento, los desarrolladores de software e investigadores han profundizado sus estudios y prácticas en el proceso previo al diseño del software. Se debe garantizar la producción de software de alta calidad y bajo costo estableciendo un punto de partida de alta confiabilidad, el que se logra mediante la detección lo más tempranamente posible de errores. Es necesario entonces contar con procesos de producción de requisitos confiables. Por otra parte, la IR enfatiza la necesidad de que los requisitos no sólo sean de la mayor calidad posible en el comienzo del proceso de desarrollo, sino que también se conserve la calidad a lo largo de todo el desarrollo. Para lograr esto, es necesario que los requisitos puedan evolucionar registrando los cambios que la realidad impone al desarrollo de la aplicación. 4 Elicitar: descubrir, tornar explícito, obtener el máximo de información para el conocimiento del objeto en cuestión. UB FTI Ingeniería de Requerimientos

19 5 Puntos clave de la Ingeniería de Requisitos En base a lo ya mencionado hasta aquí, los puntos claves que debe considerar un proceso de IR son: i) Involucrar a los clientes y usuarios en el proceso. Es decir, establecer la participación activa y constante de los clientes y usuarios. Esto implica entablar una buena comunicación con ellos para comprender cabalmente sus necesidades. ii) Asegurar la calidad de los requisitos. Esto involucra utilizar técnicas adecuadas de Verificación y Validación, las cuales deben formar parte de las actividades continuas del proceso de la IR y no como hitos estáticos. Por otro lado, la calidad de los requisitos debe conservarse a lo largo de todo el ciclo de vida del software. iii) Considerar la evolución de los requisitos durante el ciclo de vida del software. El proceso debe acompañar esta evolución. Esto involucra una adecuada gestión de los requisitos, asegurando la rastreabilidad 5 de los mismos. iv) Considerar aspectos sociales, organizacionales, políticos y legales del ambiente donde el software operará. Esto impone una inmersión de los desarrolladores en dicho ambiente y el uso de técnicas de modelado organizacional. v) Procurar la completitud de los requisitos 6. Esto es por un lado, un aspecto de la calidad y por otro lado, requiere de una comprensión adecuada del universo de discurso, ambos aspectos tratados en los puntos anteriores. Dados los graves problemas que los errores en los requisitos ocasionan sobre 5 La rastreabilidad de los requisitos ( requirements traceability ) se encarga de mantener vínculos entre los requisitos, el diseño y el código, y entre los requisitos y las fuentes de información que les dieron origen. 6 Falacia de la completitud: en un mundo real de gran complejidad, se aspira a obtener un conjunto de requisitos lo más completo posible (Leite, 1994). UB FTI Ingeniería de Requerimientos

20 el producto final (el sistema de software) y durante el proceso de producción del mismo, es que diversos centros de estudio, organismos gubernamentales y otras organizaciones se han dedicado en la última década a la investigación en el área de los requisitos de los sistemas de software. En tal sentido, se han propuesto diversos enfoques en el tratamiento de requisitos, estableciendo nuevos procesos, técnicas y métodos de producción de requisitos, creando herramientas de soporte a dichos procesos, fijando estándares en los procesos y productos, y estableciendo procesos para garantizar la calidad de los requisitos, procesos que permitan la evolución de los requisitos y su adecuada gestión durante todo el ciclo de vida del software. En la sección siguiente se enumeran algunos ejemplos importantes de estas iniciativas. 6 Principales iniciativas en la Ingeniería de Requisitos A pesar de ser la IR una disciplina reciente, cuyos comienzos datan de principios de la década del 90, existen abundantes evidencias de la dimensión que ha tomado en el desarrollo de sistemas de software. Esta evidencia se basa en la serie de estándares fijados para el documento de especificación de requisitos y para el proceso de producción de los requisitos, la variedad de productos comerciales que soportan de diversas formas las actividades involucradas en la IR, la profusión de congresos, revistas y libros específicos en esta área y las comunidades informáticas dedicadas al estudio de los diferentes aspectos que abarca la Ingeniería de Requisitos. Se detallan en las siguientes sub-secciones algunos de estos testimonios, tanto en el ámbito académico como profesional. UB FTI Ingeniería de Requerimientos

21 6.1 Estándares para especificar requisitos IEEE Std , IEEE Recommended Practice for Software Requirements Specifications, IEEE, New York, IEEE Std P1233/D3, IEEE Guide for Developing System Requirements for Specifications, IEEE, New York, DOD-STD-2167A, Defense System Software Development, US Department of Defense, Febrero Reemplazado en Diciembre de 1994 por MIL-STD-498 (el cual elimina la influencia del modelo de cascada). NCC, The STARTS Guide: A Guide to Methods and Software Tools for the Construction of Large Real-Time Systems, National Computing Centre, Manchester, MIL-STD-498, estándar requerido por el gobierno de Estados Unidos, Diciembre 1994, cancelado en Junio Este estándar implementa los procesos de desarrollo y documentación de ISO/IEC DIS 12207, e interpreta todas las cláusulas aplicables en MIL-Q-9858A (Quality Program Requirements) y en ISO 9001 (Quality Systems) para software. Establece una plantilla para el Documento de Especificación de Requisitos y describe un proceso de desarrollo de software incremental e iterativo y prácticas para la evolución de requisitos. ESA PSS-05-01, Guide to the software engineering standards, desarrollado por European Space Agency Board for Software Standardisation and Control, Octubre En particular presenta dos documentos referidos a requisitos: ESA PSS Guide to the User Requirements Definition Phase y ESA PSS Guide to the Software Requirements Definition Phase. DOD , estándar requerido por el gobierno de Estados Unidos, Este estándar reemplazó al MIL-STD-498, y también recomienda el uso de procesos incrementales e iterativos. UB FTI Ingeniería de Requerimientos