IMPORTANCIA DE LA ELICITACION DE REQUISITOS Y LAS DIFERENTES METODOLOGIAS

Giovanny Bedoya Lineis Jessica Jaramillo. Institucion Universitaria Tecnologico Metropolitano 2011

Profesor Luis Alfonso Lezcano Ing Sistemas Ingeniera de Software

Resumen Los requerimientos son importantes en el desarrollo de software puesto que es intil un sistema que no cumple con los requerimientos del cliente. . Aunque existen muchos mtodos para elicitar requisitos, pocos de ellos son especficos para elicitar Para descubrir estas necesidades se debe elegir a las fuentes adecuadas y relevar apropiadamente los requerimientos. Es importante tambin una vez establecidos los requerimientos rastrear sus fuentes para validar los requerimientos, resolver conflictos o ambigedades. Los mtodos y herramientas convencionales para la elicitacion de requisitos pueden, sin embargo, dejar de lado aspectos fundamentales de la organizacin debido a su inters por enfocarse en situaciones relativas a los problemas puntuales que aquejan el entorno del software. PALABRAS CLAVES Elicitacin de requerimientos, Tcnicas de elicitacin de requerimientos, Desarrollo de habilidades en el proceso enseanza aprendizaje, traceability ABSTRACT Elicitation techniques are the process of acquiring ("eliciting") all the relevant knowledge to produce a model of requirements of a problem1 domain. Over time the problem that has arisen is how users and customers express their needs and the difficulty for developers to interpret these requirements. Because of this, have been some techniques, such as: interview, workshop requirements ("workshop"), brainstorm

(brainstorm), scenarios (Storyboarding), use cases, JAD (Joint Application Development, Joint Application Development), in situ observation, the study documentation, questionnaires, immersion in the client's business or developers for a while are User apprentices. By applying these techniques, sometimes we get the expected results, however this is not always form.

INTRODUCCION

Los requerimientos son de importancia en el desarrollo de un sistema de software puesto que la calidad del software depende de ellos. Garvin [Garvin 1984+ define calidad como un concepto complejo y multifactico que puede describirse desde cinco perspectivas: visin trascendental, del usuario, de manufactura, del producto y basada en el valor. Tanto la visin del usuario como la de la manufactura relacionan calidad a los requerimientos. Davis [Davis 1993] muestra un diagrama del ciclo de vida del software en el cual los requerimientos se colocan como la materia prima para realizar las pruebas de aceptacin del software. Esto significa que un producto de software es aceptado por el cliente (es de calidad para l) si cumple con los requerimientos establecidos. Boehm [Boehm 2001] establece el costo relativo de reparar errores a lo largo del ciclo de vida de desarrollo del software. Este costo tiene el valor ms bajo en la etapa de requerimientos y crece en forma exponencial en las sucesivas etapas. Un error que no se soluciona en la etapa de requerimientos puede costar entre 100 y 200 veces ms en la etapa de mantenimiento. Mizuno organiz los errores que se pueden producir a lo largo del desarrollo del software en un modelo de catarata de errores [Mizuno 1983]. El modelo muestra que una especificacin de requerimientos incorrecta puede

ocasionar errores ocultos dentro del sistema que son difciles de hallar. Pero las palabras de Ackoff [Ackoff 1974] son las que mejor sintetizan la importancia de los requerimientos: Fallamos ms a menudo porque resolvemos el problema incorrecto, que porque obtenemos una solucin inadecuada del problema correcto. Los requerimientos no son estticos. La realidad cambia al igual que lo hace el dominio que alojar el sistema de software. Si el dominio cambia, tambin lo deben hacer los requerimientos, para que el software se adapte a la nueva situacin. Los cambios de los requerimientos se deben propagar por todos los productos del ciclo de vida de desarrollo del software hasta la aplicacin. Para propagar estos cambios, es necesario rastrear las distintas transformaciones que sufren los requerimientos por todos los productos del desarrollo del software. Esto se conoce como rastreabilidad (traceability) de requerimientos: habilidad de describir y seguir la vida de los requerimientos en ambas direcciones hacia delante y hacia atrs (forward and backward traceability). Desde los orgenes, pasando por la especificacin y desarrollo, hacia su posterior entrega y uso, y a travs de todos los perodos de refinamiento e iteracin de cualquiera de estas etapas. *Gotel 1994+. La rastreabilidad de requerimientos es una caracterstica que deben poseer los requerimientos (la especificacin de requerimientos de software) y su gerenciamiento [Katonya 1998] [Davis 1993] [Hilburn 1999]. Se necesita rastreabilidad de requerimientos tanto para el cliente como para el equipo de desarrollo [Wieringa 1995]. El cliente necesita conocer en que parte del software se implementa cada requerimiento para validarlos. Y por su parte, el gerente del proyecto necesita conocer como se operacionalizan los requerimientos para administrar el proceso de desarrollo. Traceability se puede dar en ambos sentidos: hacia adelante (implementacin) y hacia atrs (fuentes) [Davis 1993] [Gotel 1994]. Al gerente del proyecto le resulta til traceability hacia las fuentes, puesto que permite conocer la justificacin de los requerimientos y de las decisiones tomadas [Wieringa 1995]. Rastreabilidad de requerimientos permanece como un rea de problema ampliamente reportada, a pesar de las muchas soluciones se han propuesto [Pinheiro 2000] [Katonya 1998] [Wieringa 1995] [Gotel 1994]. El problema se adjudica a una falla en los aspectos previos a la inclusin de los requerimientos en el documento de especificacin de requerimientos. Este problema se conoce como rastreabilidad preespecificacin de requerimientos hacia atrs (prerequirements specification backward traceability) [Gotel 1994]. Consideramos que es necesario realizar un anlisis de las fuentes de requerimientos utilizadas en los desarrollos de software como primer paso para poder construir un modelo de traceability hacia esas fuentes.

requerimientos. En el anexo I se sintetiza esta informacin en un cuadro. Jitnah [Jitnah 1995] considera que la principal fuente de informacin son los usuarios de una organizacin, a pesar de que considera que no son adecuados para elicitar requerimientos y de que los requerimientos se obtienen en una forma inapropiada para los desarrolladores. Valenti [Valenti 1998] utiliza en cambio a los expertos del dominio, de los cuales obtiene informacin en forma oral. Laguna [Laguna 2001] sigue la lnea de Valenti, elicita de los expertos del dominio informacin oral que no tiene ningn tipo de estructura. Bostrom [Bostrom 1983] tambin coincide en que la principal fuente son los expertos del dominio y l propone un formato de entrevista para llevar a cabo el proceso de elicitacin. Finkelstein [Finkelstein 1994] elicita de las personas, pero no solamente de los usuarios o los expertos del dominio, l considera que se debe elicitar de los usuarios, los clientes o cualquier otro beneficiario. Finkelstein encuentra un inconveniente al elicitar de las personas (al igual que Jitnah) que es la falta de consenso entre ellos. Para ello, Finkelstein considera imprescindible el trabajo colaborativo para lograr consenso y negociar los requerimientos. Land [Land 2001] tiene una visin similar a la de Finkelstein y propone elicitar de las personas, ya sea como individuos o grupos. l propone como tcnicas individuales: entrevistas estructuras y no estructuradas, anlisis de protocolo, cuestionarios y encuestas. Y como tcnicas colectivas propone: brainstorming, reuniones de inspeccin de software, aprendizaje de historias, sistemas de soporte de grupo y elicitacin de conocimiento basado en eventos. France [France 1995] sigue la lnea de elicitar desde los expertos del dominio. l utiliza entrevistas grupales en las que participan expertos con diferentes perspectivas. Sin embargo, no se limita a expertos, tambin considera incluir personal de reas de produccin y marketing. Sugiere entrevistas de una hora en la cual participen cuatro o cinco personas. A diferencia de Valenti y Laguna quienes elicitan informacin oral, France alienta a que los expertos modelen los conceptos utilizando su propia notacin. Esto permite lograr un mejor canal de comunicacin puesto que los desarrolladores aprenden el lenguaje del dominio.

Leite [Leite 1995] extrae requerimientos de los clientes del macrosistema a travs de entrevistas [Leite 1996]. Esta informacin es utilizada para construir el Client Oriented Requirements Baseline, el cual est compuesto por el LEL y Escenarios. LEL tiene como objetivo capturar el lenguaje del dominio, mientras que los escenarios se ocupan de los aspectos dinmicos. Miura reporta tres casos de estudio en los que desarrolla entrevistas con los clientes y usuarios [Miura 1995]. En cada caso realiz 3, 4 y 5 entrevistas, de aproximadamente 5, 12 y 4 horas de duracin. Como resultado se produjo 8, 7 y 15 hojas de reporte tamao A4.

personas en clientes y staff (junior y senior). Como documentacin de referencia menciona instrucciones, libros y artculos. Lubars en [Lubars 1997] describe un caso real que se ajusta al modelo propuesto por Drake. Lubars realiz un trabajo para el gobierno norteamericano en el cual comenzaron elicitando de un documento de 529 pginas escrito en ingls con algunos diagramas de pgina completa y muchas tablas. El documento no contena ningn diagrama de flujo de datos, diagramas entidad-relacin o alguna otra forma de notacin abstracta comnmente utilizada en ingeniera de software. Adems del documento, Lubars obtuvo informacin de un curso de entrenamiento dictado por un experto del dominio. Tanto el instructor del curso como otros miembros estuvieron disponibles a lo largo del proceso de captura de requerimientos para brindar ms informacin. Blyth [Blyth 1993] incorpora el sistema de software a las fuentes de requerimientos. Propone elicitar de los dueos de los problemas requerimientos en lenguaje natural sobre mejoras al sistema actual. Van Lamsweerde [Van Lamsweerde 2000] tambin propone elicitar en funcin de un sistema de software existente y entrevistar a los stakeholders. Holibaugh [Holibaugh 1992] sigue la lnea de utilizar el software existente. Comienza analizando el software, luego entrevista a los expertos del dominio para obtener informacin de alto nivel y verificar la informacin de los sistemas. Sin embargo, Holibaugh no slo analiza software, sino que lo hace con cualquier artefacto del desarrollo de software, aunque tambin utiliza cualquier material de referencia y de entrenamiento del dominio. Iscoe [Iscoe 1993] propone obtener conocimiento de sistemas y expertos como lo hacen Blyth, Van Lamsweerde y Holibaugh. Pero, a diferencia de ellos, propone primero entrevistar a los expertos (aunque reconoce que es un proceso laborioso, costoso y propenso a errores) para luego realizar ingeniera inversa de todas las aplicaciones (recurriendo a los expertos cuando sea necesario para resolver conflictos y proveer informacin faltante). Arango [Arango 1994] recomienda elicitar desde los expertos y de las aplicaciones. Coincide con Holibaugh en elicitar desde los expertos informacin general y recurrir a las aplicaciones para obtener informacin detallada. Lam [Lam 1997] propone

Goguen coincide en elicitar de las personas. Sin embargo, tiene una visin ms amplia de la informacin que se debe obtener, puesto que no captura solamente lo que expresan oralmente y se ocupa de lo que expresan tcitamente [Goguen 1993]. Instille [Instille 2002] sigue la lnea de Goguen. Si bien plantea que las necesidades se extraen de los usuarios personalmente a travs de entrevistas o focus group, considera que los usuarios saben ms de lo que pueden decir en una o varias entrevistas. Por lo tanto, hace falta realizar observacin de los mismos a travs de visitas a los sitios de trabajo o por medio del anlisis de fotografas y videos. Macaulay [Macaulay 1996] tambin sigue la lnea de Goguen, si bien elicita requerimientos de los usuarios a travs de entrevistas y cuestionarios, aconseja realizar observacin. Ransley [Ransley 2003] propone elicitar de los dueos o stakeholders, puesto que son ellos quienes imponen restricciones o necesitan el sistema. Pero reconoce que estas restricciones pueden venir de fuentes escritas, por ejemplo una regulacin (ley provincial o nacional, por ejemplo) o una business rule. Adems plantea distintos niveles de fuentes, puesto que una puede referenciar a otra en un estado ms puro. Por ejemplo, una persona o documento puede referenciar a un memo, a una reunin o una sesin de casos de usos. Rook [Rook 1988] tiene una concepcin similar a la de Ransley. Rook propone elicitar desde los expertos del dominio, doctrinas u otras fuentes de procedimientos, metodologas o lineamientos. Drake [Drake 1997] plantea elicitar de documentos y personas. Recomienda comenzar con los documentos para luego identificar las fuentes de los mismos. Drake propone una jerarqua de fuentes que contiene en un primer nivel a las personas, material crudo y documentacin de referencia. Subclasifica a las

abordar los requerimientos desde dos perspectivas: examinar la documentacin del sistema y hablar con los expertos del dominio. Chung [Chung 1995] reporta una experiencia en donde elicit requerimientos no funcionales. En una de sus prcticas elicit desde documentos de desarrollo de software: documentos de requerimientos, diseo e implementacin. En otra se bas en informacin de carga de trabajo (workload) e informacin de la organizacin (su operacin y sus sistemas). En un tercer trabajo, slo trabajaron con informacin pblica y general (por ejemplo reportes anuales). Hoffmann [Hoffmann 2001] tiene la visin ms amplia y l aconseja elicitar de cualquiera sea la fuente. Reconoce que tpicamente se elicita de expertos, repositorios o de aplicaciones de software. Loucopoulus [Loucopoulus 1995] clasifica las fuentes en: expertos del dominio, literatura sobre el dominio, software existente sobre el dominio, software sobre otro dominio, estndares nacionales e internacionales y otros stakeholders. Reconoce que las personas presentan varias dificultades. Pueden no tener una idea clara o no saber como describir lo que necesitan. Pueden utilizar una terminologa orientada al dominio que los analistas no comprenden por utilizar un lenguaje orientado a la computadora. O bien les puede disgustar la idea de tener que usar un nuevo sistema de software.

*Leite 1995+ Leite, J. C. S. P., Oliveira, A. P. A.: A Client Oriented Requirements Baseline, Proceedings of the Second IEEE International Symposium on Requirements Engineering (RE 95), 0-8186-7017-7/95, IEEE, (1995). [Leite 1996] Leite, J. C. S. P., Gilvaz, A. P. P.: Requirements Elicitation Driven by Interviews: The Use of Viewpoints, Proceedings of the 8th International Workshop on Software Specification and Design (IWSSD '96), 1063-6765/96 IEEE, (1996). [Loucopoulus 95] Loucopoulus, P., Karakostas, V.: System Requirements Engineering, [Miura 1995] Miura, N., Kaiya, H., Saeki, M.: Building the Structure of Specification Documents from Utterances of Requirements Elicitation Meetings, Proceedings of the 1995 Asia Pacific Software Engineering Conference (APSEC '95), 0-8186-7171-8/95 IEEE, (1995). *Mizuno 1983+ Mizuno Y.: Software Quality Improvement, IEEE Computer, Vol. 16, No. 3, March (1983), 66-72. *Pinheiro 2000+ Pinheiro, F. A. C.: Formal and Informal Aspects of Requirements Tracing, III Workshop de Engenharia de Requisitos, WER2000, Rio de Janeiro, Brasil, Julio (2000) *Ransley 2003+ Ransley, P., White Paper: A Primer on Requirements Engineering & Management, Version 0.2, Beaver Computer Consultants Ltds Requirements Engineering & Management Services Capability, www.beaver-consulting.co.uk/requirement_primer.pdf, Mayo (2003). [Rook 1988] Rook, F. W., Croghan, J. W.: Knowledge acquisition for AI system requirements analysis: A systems engineering methodology, International conference on Industrial and engineering applications of artificial intelligence and expert systems, Proceedings of the first international conference on Industrial and engineering applications of artificial intelligence and expert systems, Volume 2, Tullahoma, Tennessee, United States, ISBN:0-89791-271-3, ACM Press, (1988) 798 - 804. [Valenti 1998] Valenti, S., Panti, M., Cucchiarelli, A.: Overcoming communication obstacles in user -analyst interaction for functional requirements elicitation, ACM SIGSOFT Software Engineering Notes, Volume 23, Issue 1 January, ACM Press, ISSN:0163-5948, (1998), 50 55.

Referencias *Jitnah 1995+ Jitnah, D., Han, J., Steele, P. Software Requirements Engineering: An Overview, Technical Report 95-04, Peninsula School of Computing and Information Technology, Monash University, Melbourne, Australia, September (1995). [Katonya 1998] Katonya, G., Sommerville, I.: Requirements Engineering Processes and Techniques, Chichester, John Wiley & Sons (1998). [Laguna 2001] Laguna, M. A., Marqus, J. M., Garca, F. J.: A user requirements elicitation tool, ACM Press, Volume 26 , Issue 2 March, ISSN:0163-5948, (2001), 35 - 37. *Lam 1997+ Lam, W., McDermid, J. A.: Ten Steps Towards Systematic Requirements Reuse, Symposium on Software Reusability, Proceedings of the 1997 symposium on Software reusability, Boston, Massachusetts, United States, ACM Press, ISSN:01635948, (1997), 54 - 64. [Land 2001] Land, L. P. W., Aurum, A., Handzic, M.: Capturing Implicit Software Engineering Knowledge, Proceedings of the 13th Australian Software Engineering Conference (ASWEC01), 1530-0803/01 IEEE, (2001).