Universidad Bolivariana de Venezuela Programa de Formacin de Grado en Informtica para la Gestin Social UC Ingeniera de Software

Material Complementario

Elicitacin de Requerimientos

Versin 1.2 21 septiembre 2005

Contenido
Elicitacin de Requerimientos...................................................................................4 1. Problemas en la Elicitacin de requerimientos.....................................................4 2. Cosas que elicitar..................................................................................................5 3. Tcnicas de Elicitacin..........................................................................................8 3.1. Entrevistas...................................................................................................9 3.1.1. Tipos de entrevistas:..........................................................................9 3.1.2 Fases de la entrevista:........................................................................9 3.2 Desarrollo Conjunto de Aplicaciones (Joint Application Development).....13 3.2.1 Participantes del JAD........................................................................13 3.2.2 Fases del JAD...................................................................................14 3.3. Tormenta de ideas (Brainstorming)...........................................................16 3.3.1. Fases de la Tormenta de ideas.......................................................16 3.4 Estudio de documentos..............................................................................18 3.5 Observacin...............................................................................................18 3.6 Cuestionarios..............................................................................................18 3.7 Talleres (workshop)....................................................................................18 3.8 Prototipaje...................................................................................................19 3.9 Pruebas pilotos...........................................................................................19 3.10Estudiar organizaciones similares.............................................................20 3.11Negociacin...............................................................................................20 3.12Anlisis orientado a las metas...................................................................21 3.13Despliegue de funciones de calidad (QFD por sus siglas en ingls)........21 3.14Grupos focalizados ...................................................................................21 4. Planillas para elicitacin de requerimientos........................................................24 4.1 Plantillas para objetivos..............................................................................27 4.2 Plantilla para requerimientos (funcionales y no funcionales).....................28 4.3 Plantilla para requerimientos de informacin.............................................28 4.4 Plantilla para conflictos...............................................................................30 5. Bibliografa...........................................................................................................30 2

6. Actividades propuestas al estudiante..................................................................31

Este material se basa en los siguientes libros:

Ian Sommerville y Pete Sawyer. Requirements Engineering. A Good Practice

Guide. Cap. 4. Lancaster University. Ed. Jhon Wiley &sons,1998.

Soren Lauesen. Software Requirements. Styles and Techniques. Cap.4

Samfundslitteratur, 1999

Realizndose una traduccin (adaptada) de los captulos sealados, y del siguiente Informe Tcnico:

Durn A. y Bernrdez B. Metodologa para la Elicitacin de Requisitos de Sistemas Software Versin 2.3. Informe Tcnico LSI-2000-10 (revisado). Universidad de Sevilla. Abril 2002. URL: http://www.lsi.us.es/~amador/publicaciones/metodologia_elicitacion_2_3.pdf.zip.

Del cual se realiz un resumen

Elicitacin de Requerimientos
La elicitacin de requerimientos es el proceso mediante el cual se descubren las necesidades y propiedades de un sistema a partir de la comunicacin con los usuarios y todos los beneficiarios del sistema (stakeholder)1. Es la conceptualizacin del sistema en funcin de lo quieren los usuarios y otros beneficiarios y lo que realmente necesitan. Esto requiere del conocimiento del dominio de la aplicacin y de los problemas especficos de la organizacin o comunidad a la cual va dirigida la aplicacin. Los requerimientos deben expresarse en forma concisa, precisa, identificables y verificables a fin de que puedan contribuir a la solucin y, en particular deben ser entendibles por los usuarios y otros beneficiarios del sistema. La elicitacin no es un proceso de un paso. Tpicamente, primero se investiga el dominio del problema y se recoge la informacin acerca del trabajo actual y la situacin presente, luego se detectan los problemas. Posteriormente, se muestran posibles soluciones y finalmente se establecen los requerimientos a partir de la informacin recolectada. El propsito del nuevo sistema es servir a los usuarios y otros beneficiarios, generalmente de una organizacin2 entonces Porqu no preguntarle, a ellos, que necesitan?, desafortunadamente esto no es tan fcil, y de all que se proponen diversas tcnicas. 1. Problemas en la Elicitacin de requerimientos En la mayora de los casos, muchos de los usuarios no tienen claro lo que necesitan. En general sienten que tienen problemas. Hay tambin una tendencia a exagerar problemas cotidianos y olvidar otros problemas ms serios. Incluso si ellos detectan bien los problemas, hay un proceso largo para formular las necesidades. Como primer paso, el analista puede simplificar la formulacin de necesidades descartando los problemas no relevantes, en unin con los usuarios y otros beneficiarios del sistema. Muchos usuarios pueden tener grandes dificultades para explicar las tareas que ejecutan. An ms difcil es explicar porque las hacen.

Una interpretacin del trmino stakeholder pudiera ser usuarios y otros beneficiarios en el sistema (clientes, directivos, desarrolladores, equipo de soporte tcnico, etc.). En alguna literatura se le traduce como actores, pero entra en conflicto con el significado del mismo trmino en el modelo de casos de uso, sin embargo puede utilizarse, entendiendo el contexto. 2 A lo largo del tema nos referimos a las organizaciones en forma genrica, ello puede significar empresas, instituciones, dependencias gubernamentales, educativas, etc., as como organizaciones ms informales: de las comunidades, grupo de personas que se unen para fines especficos, etc.

A menudo los usuarios y otros beneficiarios especifican una solucin en lugar de un requerimiento. Puede suceder que los usuarios encuentren difcil imaginar nuevas formas de hacer cosas, o imaginar las consecuencias de hacerlo de una manera diferente. Por ejemplo, tom tiempo internalizar que el problema de conectar personas a travs del telfono poda solventarse, en parte, a travs de una nueva tecnologa: el correo electrnico. Adems, la introduccin del correo electrnico cambi los patrones de trabajo en una forma que nadie haba imaginado. A menudo diferentes actores tienen visiones en conflicto. Por ejemplo, para un equipo de mercadotecnia los tiempos de entrega ptimos es un requerimiento importante, mientras que para el equipo de produccin ello puede incidir en sobre tiempos de trabajo. Los usuarios pueden rechazar propuestas debido a una resistencia al cambio. Por ejemplo, cuando el procesador de texto se introdujo como herramienta de trabajo, las secretarias eran renuentes (dado que esto cambiaba la forma tradicional de trabajo y era difcil de aprender). Sin embargo, posteriormente se transform en una herramienta indispensable. Parte de la resistencia era simplemente la dificultad de imaginar una nueva forma de trabajo. Una vez que el analista logra involucrar a los distintos grupos de usuarios y otros beneficiarios en el proceso de identificacin de los requerimientos, puede surgir otro problema. Cada grupo establece requerimientos diferentes. algunos de ellos son esenciales, otros son no relevantes. Puede ser difcil que todos los actores estn de acuerdo en lo que es esencial y lo que no es. Son diferentes visiones. Las demandas cambian con el tiempo, los factores externos cambian y las prioridades tambin. Una vez que una necesidad es satisfecha, nuevas demandas aparecen.

2. Cosas que elicitar No es posible obtener los requerimientos directamente al inicio del proceso de elicitacin. Los requerimientos son el resultado final del proceso de elicitacin, y usualmente se requieren resultados intermedios. Esta es una lista de resultados a obtenerse desde el inicio, durante y al final de la elicitacin: a) Comprensin del dominio del problema. b) Una lista de problemas presentes en el dominio. c) Una lista de exigencias y las metas crticas (requerimientos preliminares). d) Ideas para el sistema futuro. e) Posibilidades realistas.

f) Compromiso de los usuarios y otros beneficiarios. g) Resolucin de conflictos entre los usuarios y otros beneficiarios. h) Requerimientos finales. i) Priorizar los requerimientos. j) Comprobar que los requerimientos son necesarios, estn completos. Como analista, no se puede obtener todo en un solo paso. Inicialmente, incluso pueden encontrarse algunos problemas aparentemente crticos y despus cambiarse esta prioridad. En la prctica, en el proceso se realizan muchos cambios. Un producto de este trabajo muy importante es la lista de exigencias y metas crticas. Estos son los requerimientos informales que sern luego sern verificados. Lineamientos para la elicitacin de requerimientos. Para realizar el proceso de la elicitacin se sugieren una serie de lineamientos: 1) Evaluar previamente la factibilidad del sistema. Antes de realizar el anlisis de los requerimientos del sistema, previamente se ha debido realizar un estudio de factibilidad, A fin de evaluar si el sistema es en realidad necesario y tecnolgicamente realizable y si puede ser integrado al ambiente de la organizacin. Los beneficios de este estudio, para la realizacin del anlisis de requerimientos, son: Para realizar un estudio de factibilidad, necesitan plantearse los objetivos del sistema de forma explcita. Los objetivos representan los motivos fundamentales para el desarrollo de sistema. Los requerimientos que son descubiertos durante el proceso de elicitacin deben ser compatibles con estos objetivos. El estudio probablemente revela las fuentes de informacin sobre el sistema que deberan consultarse durante la elicitacin de requerimientos.

Esta actividad es previa al anlisis de los requerimientos y existen tcnicas sencillas y poco costosas para su realizacin. 2) Ser Sensible a las consideraciones polticas y organizacionales Cuando realice la elicitacin de los requerimientos, debe ser sensible a los factores polticos y organizacionales ya que ello ayuda a comprender la cultura de la organizacin, sus valores, la moral y otros aspectos concretos. Ello va a permitir

entender el porqu de algunos requerimientos que son demandados, porqu se les da la mayor importancia, porqu otros son ocultados, etc.. La aplicacin exitosa de este lineamiento depende de la sensibilidad de los analistas involucrados en el proceso de elicitacin. Algunas personas parecen tener mayor conciencia acerca de las consideraciones polticas; otros tienen un punto de vista ms tcnico y encuentran difcil el hecho de relacionarse con la poltica intangible de organizacin. Cuando se realice la elicitacin de requerimientos, existen un nmero de cosas que se deben observar, en particular aspectos polticos y de la organizacin que pueden tener influencia sobre los requerimientos, puede sealarse: Metas conflictivas. Puede suceder que no todas las personas dentro de la organizacin tengan las mismas metas. Trate de entender las razones. Las relaciones de poder y el impacto del nuevo sistema. Puede suceder que este impacto signifique transferencias o prdidas- de responsabilidades en algunos actores, ello puede revelarse en la elicitacin de requerimientos por las sugerencias de stos. De all que debe tratarse de entender la estructura de poder en la organizacin. La Cultura Organizacional y si ella abarca a todo el colectivo o a partes de ste. Actitudes de la Direccin y la moral de la organizacin. Si la organizacin pasa por un perodo difcil, la gente puede ser hostil a esta Direccin y pueden estar indispuestos a participar en el proceso de cambio.

3) Identifique y Consulte a todos los beneficiarios del sistema Cuando se demanda un sistema, existen muchas personas, que de un modo directo o indirecto se relacionan o se benefician con el sistema que va a ser desarrollado, entre stos podemos nombrar a los usuarios finales. Otros pueden ser: gerentes, programadores, equipo tcnico, especialistas del dominio, educadores, etc. Como parte del proceso de elicitacin de requerimientos, hay que identificar a todos los potenciales beneficiarios y consultarlos para descubrir si ellos plantean requerimientos especficos o si imponen restricciones especficas al sistema. Los beneficios de seguir este lineamiento son: Si no se considera a cada uno de los afectados por la introduccin de un sistema, probablemente se omitirn requerimientos importantes. El sistema debera ser adaptado para incluir estos requerimientos en una etapa posterior o, peor aun, ignorarlos.

la identificacin de los distintos grupos de beneficiarios puede ayudar a descubrir puntos de vista distintos para estructurar los requerimientos del sistema. Identificando los grupos de beneficiarios e incorporndolos al proceso de anlisis, con mayor probabilidad se lograr que sean comprensivos a la introduccin del sistema y colaboren dando informacin de inters y aportando los requerimientos desde su punto de vista.

Cmo identificar a los grupos de beneficiarios? Descubriendo a los usuarios potenciales del sistema. Mediante discusiones iniciales con la direccin de organizacin donde se pregunte quin ser afectado por la introduccin del sistema. - Considerando a los usuarios de la organizacin que usar el sistema. - Considerando al personal de desarrollo y mantenimiento del sistema. - Considerando entes externos como reguladores y autoridades de certificacin que pueden desear colocar requerimientos sobre el sistema. Recomendamos que en la documentacin adems de identificar a estos grupos de beneficiarios, se explique porqu sus requerimientos probablemente sean importantes. 3. Tcnicas de Elicitacin Son un conjunto de tcnicas empleadas para realizar la obtencin de informacin necesaria para desarrollar un software de calidad. Obtener un software de calidad es una de las metas en el proceso de construccin de una aplicacin, y se expresa en trminos de las cualidades deseadas: eficiencia, flexibilidad, correccin, confiabilidad, mantenibilidad, portabilidad o usabilidad, entre otras. La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software. Aunque se explican muchas tcnicas, no significa que deban usarse todas, se eligen aquellas que respondan al propsito del sistema. Si dos tcnicas sirven para el mismo objetivo, se escoge la de menor costo. Si se quiere estar seguro de cubrir todo, pueden usarse varias tcnicas. Lo que pueda faltar en una, lo complementar la otra. Las tcnicas ms usuales en la elicitacin de requerimientos son: las entrevistas; el Desarrollo Conjunto de Aplicaciones (Joint Application Development o JAD); la tormenta de ideas (brainstorming) y la utilizacin de escenarios. A estas tcnicas, que se describen en las siguientes secciones, se las suele apoyar con otras tcnicas complementarias como la observacin in situ, el estudio de -

documentacin, los cuestionarios, la inmersin en el negocio del cliente, entre otras. 3.1. Entrevistas

Las entrevistas son la tcnica de elicitacin ms utilizada, y de hecho son prcticamente inevitables en cualquier desarrollo ya que es una de las formas de comunicacin ms natural entre personas. La entrevista es buena para obtener conocimientos acerca del trabajo actual en el dominio dado y los problemas presentes. No es tan buena para la identificacin de las metas crticas. Pueden dar, tambin, algunas ideas sobre el sistema futuro. 3.1.1. Tipos de entrevistas: a) Entrevistas no estructuradas: permite que el entrevistador formule preguntas no previstas durante la conversacin. El entrevistador inquiere sobre diferentes temas a medida que se presentan. En este tipo de entrevistas el entrevistador tiene poco control sobre el proceso y las conversaciones son enfocadas hacia un tema particular. b) Entrevistas estructuradas: se basan en un marco de preguntas predeterminadas. Las preguntas se establecen antes de que inicie la entrevista y todo solicitante debe responderla. Este enfoque mejora la calidad de la entrevista, pero no permite que el entrevistador explore las respuestas interesantes o poco comunes. Por eso la impresin del entrevistado y entrevistador es la de estar sometidos a un proceso mecnico. Es posible incluso que muchos solicitantes se sientan desalentados al participar en este tipo de proceso. c) Entrevistas semiestructuradas: es una estrategia mixta, con preguntas estructurales y con preguntas no estructurales. La parte estructurada proporciona una base informativa. La parte no estructurada aade inters al proceso y permite un conocimiento inicial de caractersticas especficas. 3.1.2 Fases de la entrevista: En las entrevistas se pueden identificar tres fases: preparacin, realizacin y anlisis. 1) Preparacin de entrevistas Las entrevistas no deben improvisarse, por lo que conviene realizar las siguientes tareas previas:

Estudiar el dominio del problema:

Conocer las categoras y conceptos de los usuarios y la comunidad interesada es fundamental para poder entender las necesidades de dicha comunidad y su forma de expresarlas. Para conocer el dominio del problema se puede recurrir a tcnicas de estudio de documentacin, a bibliografa sobre el tema, documentacin de proyectos similares realizados anteriormente, la inmersin dentro de la organizacin para la que se va a desarrollar o a periodos de aprendizaje por partes de los analistas de requerimientos.

Seleccionar a las personas a las que se va a entrevistar: Se debe minimizar el nmero de entrevistas a realizar, por lo que es fundamental un proceso de seleccin. Normalmente se comienza por los actores que puedan ofrecer una visin global, y se contina con los futuros usuarios, que pueden aportar informacin ms detallada, y con el personal tcnico, que aporta detalles sobre el entorno operacional de la organizacin. Conviene tambin estudiar el perfil de los entrevistados, buscando puntos en comn con el entrevistador que ayuden a romper el hielo. A quin entrevistar para obtener informacin acerca del trabajo actual y los problemas presentes?. Preferiblemente algunos miembros de cada grupo de actores. Hay que entrevistar no solo a representantes oficiales, la experiencia demuestra que muchos de estos representantes desconocen lo que realmente sucede en la organizacin diariamente. Obtener informacin del verdadero usuario final es importante.

Determinar el objetivo y contenido de las entrevistas: Para minimizar el tiempo de la entrevista es fundamental fijar el objetivo que se pretende alcanzar y determinar previamente su contenido. Previamente a su realizacin, se pueden enviar cuestionarios que los futuros entrevistados deben rellenar y devolver, y un pequeo documento de introduccin al proyecto de desarrollo, de forma que el entrevistado conozca los temas que se van a tratar y el entrevistador recoja informacin para preparar la entrevista. Es importante que 10

los cuestionarios, si se usan, se preparen cuidadosamente teniendo en cuenta quin los va a responder y no incluir conceptos que se asuman conocidos cuando puedan no serlo.

Planificar las entrevistas: La fecha, hora, lugar y duracin de las entrevista deben fijarse teniendo en cuenta siempre la agenda del entrevistado. En general, se deben buscar sitios agradables donde no se produzcan interrupciones y que resulten naturales a los entrevistados. La puntualidad es importante. 2) Realizacin de entrevistas Dentro de la realizacin de las entrevistas se distinguen tres etapas: Apertura, desarrollo y terminacin. Apertura: el entrevistador debe presentarse e informar al entrevistado sobre la razn de la entrevista, qu se espera conseguir, cmo se utilizar la informacin, la mecnica de las preguntas, etc. Si se va a utilizar algn tipo de notacin grfica o matemtica que el entrevistado no conozca, debe explicarse antes de utilizarse. Es fundamental causar buena impresin en la primera entrevista. Desarrollo: la entrevista debe tener un lapso prefijado, distribuyendo el tiempo en un 20% para el entrevistador y un 80% para el entrevistado. Se deben evitar los monlogos y mantener el control por parte del entrevistador, contemplando la posibilidad de que una tercera persona tome notas durante la entrevista o grabar la entrevista en cinta de vdeo o audio, siempre que el entrevistado est de acuerdo. Hay aspectos ticos a considerar: si se va a grabar la entrevista, se debe tener muy presente que el equipo de grabacin debe estar en perfecto estado y el entrevistador debe saber manejarlo y cuando se reproduce la grabacin no se pueden cambiar ni corregir las respuestas suministradas por los entrevistas, bajo ninguna circunstancia. Qu preguntar?. Inicialmente, formular preguntas abiertas acerca del trabajo diario, y otros aspectos de la lista de cosas a elicitar. Asegurndose de preguntar sobre las tareas crticas: cundo es realmente importante que los resultados sean 100% correctos?. Difcilmente se pueden identificar estos detalles con la observacin, hay que preguntarles a los usuarios. Durante esta fase se deben considerar los siguientes aspectos:

11

Realizar preguntas abiertas, tambin denominadas de libre contexto, estas preguntas no pueden responderse con un "s" o un "no", permiten una mayor comunicacin y evitan la sensacin de interrogatorio. Estas preguntas se suelen realizar al comienzo de la entrevista, pasando posteriormente a preguntas ms concretas. En general, se debe evitar la tendencia a anticipar una respuesta a las preguntas que se formulan. Utilizar palabras apropiadas, evitando tecnicismos que no conozca el entrevistado y palabras o frases que puedan perturbar la comunicacin. Mostrar inters en todo momento, cuidando la comunicacin gestual durante la entrevista: movimiento, expresin facial, etc. Por ejemplo, para animar a alguien a hablar puede asentirse con la cabeza, decir "ya entiendo", "s", repetir algunas respuestas dadas, hacer pausas, poner una postura de atencin, etc. Debe evitarse bostezar, reclinarse en el silln, mirar hacia otro lado, etc.

Terminacin: al terminar la entrevista se debe recapitular para confirmar que no ha habido confusiones en la informacin recogida, agradecer al entrevistado su colaboracin y citarle para una nueva entrevista si fuera necesario, dejando siempre abierta la posibilidad de volver a contactar para aclarar dudas que surjan al estudiar la informacin o al contrastarla con otros entrevistados.

3) Anlisis de las entrevistas Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas en limpio, reorganizar la informacin, contrastarla con otras entrevistas o fuentes de informacin, entre otros. Una vez elaborada la informacin, se puede enviar al entrevistado para confirmar los contenidos. Tambin es importante evaluar la propia entrevista para determinar los aspectos mejorables. Una variante es la entrevista en grupos. Un grupo de usuarios de la misma rea puede decir ms del trabajo actual, problemas, situaciones crticas que las entrevistas individuales. El grupo inspira a los otros a recordar situaciones crticas, describir el trabajo diario, etc. Una cosa importante cuando se conduce esta clase de entrevistas es mantener un equilibrio entre participantes de modo que nadie domine y todos se sientan seguros dando su opinin.

12

3.2 Desarrollo Conjunto de Aplicaciones (Joint Application Development)

La tcnica denominada Joint Application Development, Desarrollo Conjunto de Aplicaciones JAD en lo sucesivo-, desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales que se desarrolla a lo largo de un conjunto de reuniones en grupo durante un periodo de uno o varios das. En estas reuniones se ayuda a los usuarios y otros beneficiarios a formular problemas y explorar posibles soluciones, involucrndolos y hacindolos sentirse partcipes del desarrollo. Esta tcnica se base en cuatro principios [Raghavan et al. 1994]: dinmica de grupo, el uso de ayudas visuales para mejorar la comunicacin (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional una filosofa de documentacin WYSIWYG (What You See Is What You Get, lo que tu ves es lo que tu encuentras), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.

El JAD tiene dos grandes pasos, el JAD/Plan cuyo objetivo es elicitar y especificar requerimientos, y el JAD/Design, en el que se inicia el proceso de diseo del software. En este documento slo se ver con detalle el primero de ellos. Debido a los aspectos de organizacin que requiere y a que no suele adaptarse bien a los horarios de trabajo de los clientes y usuarios, esta tcnica no suele emplearse con frecuencia, aunque cuando se aplica suele producir buenos resultados, especialmente para elicitar requerimientos en el campo de los sistemas de informacin. En comparacin con las entrevistas individuales, presenta las siguientes ventajas: Ahorra tiempo al evitar que las opiniones de los usuarios y otros beneficiarios se contrasten por separado. Todo el grupo revisa la documentacin generada, no slo los analistas de requerimientos. Implica ms a los usuarios y otros beneficiarios en el desarrollo.

3.2.1 Participantes del JAD Se pueden distinguir seis clases de participantes, con roles diferentes:

13

Facilitador: es el responsable de todo el proceso y asume el control durante las reuniones. Debe tener dotes de comunicacin y liderazgo. Algunas habilidades importantes que debe poseer: entender y promover la dinmica de grupo, iniciar y centrar discusiones, reconocer cundo la reunin se est desviando del tema y reconducirla, manejar las distintas personalidades y formas de ser de los participantes, evitar que decaiga la reunin aunque sea larga y difcil, etc. Analista: es el responsable de la produccin de los documentos que se deben generar durante las sesiones. Debe tener la habilidad de organizar bien las ideas y expresarlas claramente por escrito. En el caso de que se utilizan herramientas software durante las sesiones, debe ser capaz de manejarlas eficientemente. Gerente o Directivo: es el que tiene la decisin final de que se lleve a cabo el desarrollo. Debe proporcionar a los dems participantes informacin sobre la necesidad del nuevo sistema y los beneficios que se espera obtener de l. Los usuarios: las personas que utilizarn el sistema Representantes de sistemas similares: son personas expertos en sistemas que deben ayudar a los usuarios a comprender qu es o no factible con la tecnologa actual y el esfuerzo que implica. Especialistas: son personas que pueden proporcionar informacin detallada sobre aspectos muy concretos, tanto del punto de vista de los usuarios, porque conocen muy bien el funcionamiento de una parte de la organizacin, como desde el punto de vista de los desarrolladores porque conocen ciertos aspectos de la tecnologa de la organizacin.

3.2.2 Fases del JAD Se distinguen tres fases: 1) Adaptacin: es responsabilidad del facilitador, ayudado por uno o dos analistas, adaptar la tcnica del JAD para cada proyecto. La adaptacin debe comenzar por definir el proyecto a alto nivel, para lo cual pueden ser necesarias entrevistas previas con algunos clientes y usuarios. Tambin suele ser necesario recabar informacin sobre la organizacin para familiarizarse con el dominio del problema, por ejemplo utilizando tcnicas complementarias como el estudio de documentacin o la observacin in situ. Una vez obtenida una primera idea de los objetivos del proyecto, es necesario seleccionar a los participantes, citarles para las reuniones y proporcionarles una lista con los temas que se van a tratar en las reuniones para que las puedan preparar. El facilitador debe decidir la duracin y el nmero de sesiones a celebrar, definir el formato de la documentacin sobre la que se trabajar y preparar transparencias introductorias y todo el material audiovisual que considere oportuno.

14

2) Celebracin de las sesiones JAD: Durante las sesiones, los participantes exponen sus ideas y se discuten, analizan y refinan hasta alcanzar un acuerdo. Los pasos que se recomienda seguir para este proceso son los siguientes: a) Presentacin: se presenta y se da la bienvenida a todos los participantes por parte del Directivo y del facilitador. El Directivo expone brevemente las necesidades que han llevado al desarrollo y los beneficios que se esperan obtener. El facilitador explica la mecnica de las sesiones y la planificacin prevista. b) Definir objetivos y requerimientos: el facilitador promueve la discusin para elicitar los objetivos o requerimientos de alto nivel mediante preguntas como: Por qu se construye el sistema?, Qu beneficios se esperan del nuevo sistema?, Cmo puede beneficiar a la organizacin en el futuro?, Qu restricciones de recursos disponibles, normas o leyes afectan al proyecto?, Es importante la seguridad de los datos?. A medida que se van elicitando requerimientos, el analista los escribe en transparencias o en algn otro medio que permita que permanezcan visibles durante la discusin. Una posibilidad es utilizar para ello las plantillas descritas en la presente gua. c) Delimitar el mbito del sistema: una vez obtenido un nmero importante de requerimientos, es necesario organizarlos y llegar a un acuerdo sobre el mbito del nuevo sistema. Es til identificar a los usuarios potenciales y determinar qu tareas les ayudar a realizar. d) Documentar temas abiertos: aquellas cuestiones que hayan surgido durante la sesin que no se han podido resolver, deben documentarse para las siguientes sesiones y ser asignadas a una persona responsable de su solucin para una fecha determinada. e) Concluir la sesin: el jefe del JAD concluye la sesin revisando con los dems participantes la informacin elicitada y las decisiones tomadas. Se da la oportunidad a todos los participantes de expresar cualquier consideracin adicional, fomentando por parte del jefe del JAD el sentimiento de propiedad y compromiso de todos los participantes sobre los requerimientos elicitados. 3) Conclusin Una vez terminadas las sesiones es necesario transformar las transparencias, notas y dems documentacin generada en documentos formales. Se distinguen tres pasos: a) Completar la documentacin: los analistas recopilan la documentacin generada durante las sesiones en documentos conformes a las normas o estndares vigentes en la organizacin para la que se desarrolla el proyecto.

15

b) Revisar la documentacin: la documentacin generada se enva a todos los participantes para que la comenten. Si los comentarios son lo suficientemente importantes, se convoca otra reunin para discutirlos. c) Validar la documentacin: una vez revisados todos los comentarios, el facilitador enva el documento al patrocinador ejecutivo para su aprobacin. Una vez aprobado el documento se envan copias definitivas a cada uno de los participantes. 3.3 . Tormenta de ideas (Brainstorming) La tormenta de ideas es una tcnica de reuniones en grupo cuyo objetivo es la generacin de ideas en un ambiente libre de crticas o juicios. Las sesiones suelen estar formadas por un nmero de cuatro a diez participantes, uno de los cuales es el facilitador de la sesin, encargado ms de comenzar la sesin que de controlarla. Como tcnica de elicitacin de requerimientos, puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas, sobre todo al comienzo del proceso de elicitacin, cuando los requerimientos son todava muy difusos. El facilitador anota todas las ideas en una pizarra. Pronto cada idea generar otras ideas, algunas interesantes, otras prometedoras y otras sin sentido comn. Una regla importante del juego es no criticar ningn planteamiento. Incluso ideas aparentemente descartables pueden convertirse en la semilla de otras ideas interesantes. Durante la elicitacin, el inters est puesto en ideas para el nuevo sistema. Si la creatividad no surge en la sesin, el analista puede introducir ideas que han surgido mediante otras tcnicas.. El facilitador puede culminar la sesin con una ronda donde se prioricen las ideas. Frente al JAD, la tormenta de ideas tiene las ventajas siguientes Es muy fcil de aprender Requiere poca organizacin, de hecho, hay propuestas de realizacin de Tormentas de ideas por vdeo conferencia a travs de Internet .

Por otro lado, al ser un proceso poco estructurado, puede no producir resultados con la misma calidad o nivel de detalle que otras tcnicas. Pero estimula fuertemente la creatividad y pueden salir ideas innovadoras. 3.3.1. Fases de la Tormenta de ideas En la tormenta de ideas se distinguen las siguientes fases: 1) Preparacin: la preparacin para una sesin requiere que se seleccione a los participantes y al jefe de la sesin, citarlos y preparar la sala donde se llevar a cabo la sesin. Los

16

participantes en una sesin de tormenta de ideas para elicitacin de requerimientos son normalmente los usuarios y otros beneficiarios, y, si es necesario, algn experto en el dominio del problema. 2) Generacin: el facilitador abre la sesin exponiendo un enunciado general del problema a tratar, que hace de semilla para que se vayan generando ideas. Los participantes aportan libremente nuevas ideas sobre el problema semilla, bien por un orden establecido por el facilitador, bien aleatoriamente. El facilitador es siempre el responsable de dar la palabra a cada participante. Este proceso contina hasta que el facilitador decide parar, bien porque no se estn generando suficientes ideas, en cuyo caso la reunin se pospone, bien porque el nmero de ideas sea suficiente para pasar a la siguiente fase. Durante esta fase se deben observar las siguientes reglas: Se prohbe la crtica, de forma que los participantes se sientan libres de formular cualquier idea. Se fomentan las ideas ms innovadoras, que, aunque no sean factibles, estimulan a los dems participantes a explorar nuevas soluciones ms creativas. Se debe generar un gran nmero de ideas, ya que cuantas ms ideas se presenten, ms posibilidades de anlisis se tendr. Se debe alentar a los participantes a combinar o completar las ideas de otros participantes. Para ello, es necesario, al igual que en la tcnica del JAD, que todas las ideas generadas estn visibles a todos los participantes en todo momento. Una posibilidad es utilizar como semilla objetivos del sistema e ir identificando requerimientos. Estos requerimientos se deben recoger en plantillas para que los participantes tengan visibles las ideas que se van generando.

3) Consolidacin: en esta fase se deben organizar y evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos: a) Revisar ideas: se revisan las ideas generadas para clarificarlas. Es habitual identificar ideas similares, en cuyo caso se unifican en un solo enunciado. b) Descartar ideas: aquellas ideas que los participantes consideren no adecuadas se descartan. c) Priorizar ideas: se priorizan las ideas restantes, identificando las absolutamente esenciales, las que estaran bien pero que no son esenciales y las que podran ser descartarse. 4) Documentacin: despus de la sesin, el facilitador produce la documentacin oportuna, conteniendo las ideas priorizadas y comentarios generados durante la consolidacin.

17

3.4 Estudio de documentos El estudio de documentos es otra alternativa para obtener informacin. Es tambin una va rpida de conocer lo existente. El analista estudia documentos existentes tales como formas, documentacin del sistema existente, etc. 3.5 Observacin En las entrevistas el usuario puede dar explicaciones lgicas pero que no se corresponden a la realidad. La observacin sirve para comprobar la informacin obtenida en entrevistas. El analista puede pasar cierto tiempo con los usuarios, observando las tareas diarias. En algunos casos, los analistas usan grabadores o cmaras de vdeo (con el permiso de los usuarios) para prolongar el perodo de la observacin. Esto tiene la ventaja de que puede revisar las cintas con el usuario y aclarar cualquier duda. La observacin mejora los conocimientos del trabajo actual y de algunos problemas en el trabajo. Desafortunadamente, las situaciones y las tareas crticas frecuentemente se escapan de la observacin. Una variante de la entrevista y la observacin es la demostracin de tareas. Se le puede pedir al usuario que demuestre como ejecuta una tarea especfica. 3.6 Cuestionarios El cuestionario es una manera de obtener informacin de muchas personas. Puede usarse de varias formas: para obtener evidencia estadstica o reunir opiniones y sugerencias. En el segundo caso, formule preguntas abiertas. Esencialmente, puede hacer las mismas preguntas como en una entrevista, ejemplo Cul es el mayor problema en tu trabajo diario? o Cules son sus sugerencias para mejorar el soporte tecnolgico en tu trabajo diario?. Estos resultados pueden ser un poco difciles de interpretar. Las personas consultadas pueden haber mal interpretado las preguntas y de igual forma se puede mal interpretar las respuestas. Durante la entrevista, se puede comprobar si se est entendiendo lo planteado y reformular preguntas. Tambin es difcil clasificar los resultados de las preguntas abiertas si no ve conoce el contexto. El riesgo de no comprender bien es an mayor con preguntas de tipo cerradas. Para reducir el riesgo, es esencial conocer bien el dominio. 3.7 Talleres (workshop) Hay muchas clases de talleres y en ellos se pueden mezclar diversas tcnicas (tormenta de ideas, prototipaje, etc.). Se usan para cubrir casos donde los usuarios y los desarrolladores se renen para disear o perfilar el sistema futuro. El trmino trabajo cooperativo se aplica a esta tcnica. 18

El resultado de los talleres, puede ser un perfil o un prototipo, diagramas de casos de uso, etc. Usualmente, el analista debe finalizar convirtiendo los resultados en requerimientos. Como efecto secundario del taller, se pueden identificar las metas y situaciones crticas. Un problema con los talleres es que los participantes pueden comprometerse mucho con la solucin all planteada. Por qu esto es un problema?: porque en su entusiasmo, ellos pueden olvidar otros aspectos, tales como si la solucin es tcnicamente factible, o si otros actores entienden la solucin. Y ello puede causar conflictos con ellos. 3.8 Prototipaje Un prototipo es una versin simplificada de parte del sistema final. Los usuarios y otros beneficiarios experimentan con prototipos para tener una idea de cmo funcionara en la vida real. El prototipaje puede ser a nivel de la interfaz del sistema, en este sentido se exploran los elementos de la interaccin con el usuario. Este prototipaje puede ser de baja o alta fidelidad. En el primer caso se tendrn bocetos a lpiz y papel, en el segundo se tendra una interfaz elaborada con las herramientas en que se desarrollar el sistema, an cuando sea una versin simplificada de la interfaz de usuario del sistema. Otras partes del sistema pueden ser objeto de prototipaje. Como por ejemplo, si el sistema debe comunicarse con otro producto existente, el prototipaje de la comunicacin puede revelar mucho: cules son los tiempos de respuesta real?, etc. 3.9 Pruebas pilotos En muchos casos, el nuevo sistema puede ser un sistema estndar, quizs con algunas funcionalidades adicionales. El costo para introducir el sistema puede ser alto, pero el principal riesgo es si la organizacin puede adoptar el sistema y usarlo para incrementar su desempeo. Los cambios organizacionales propios son a menudo ms costosos que el sistema mismo. En este caso, la mayora de los riesgos pueden ser eliminados a travs de una prueba piloto. Una pequea parte de la organizacin usa el nuevo sistema en un perodo de prueba y cambia sus procedimientos de trabajo. El grupo de analistas observa el resultado y evala el costo y beneficio del nuevo sistema. Usualmente, dicho grupo sugiere tambin formas diferentes de hacerlo al ampliar su uso a toda la organizacin. Si el experimento es exitoso, se crea un acuerdo de compromiso. El grupo de analistas tambin ayuda a identificar los requerimientos faltantes y las prioridades.

19

3.10

Estudiar organizaciones similares

Una de las mejores fuentes de ideas es estudiar que hacen otras organizaciones para manejar problemas similares. Un estudio de sus procedimientos y la comparacin con los de la organizacin actual puede dar muchas ideas. Otras organizaciones similares pueden tambin tener experiencia con el sistema que se considera. Ms importante, una visita a esas organizaciones hace ms fcil imaginar como podra trabajar el nuevo sistema. Un problema que se puede presentar es si las otras organizaciones estn dispuestas a compartir sus conocimientos. Hay otras formas de obtener informacin acerca de los procedimientos de los competidores. Algunas auditorias internacionales y compaas de consulta tienen una enorme base de datos de patrones de prueba con el desempeo de otras compaas en el mismo dominio. 3.11 Negociacin

El propsito de la negociacin es resolver conflictos. Estos puede ser conflictos entre el proveedor y el usuario, pero los conflictos ms difciles se presentan frecuentemente entre los distintos grupos de beneficiarios del sistema, dentro de la misma organizacin. Los conflictos entre los proveedores y el usuario estn usualmente relacionados con costos, beneficios, y quin corre el riesgo. Los conflictos dentro de la organizacin pueden ser de otra ndole, como por ejemplo, conflictos de poder, conflictos con otros proyectos. En un grupo de discusin que trabaje en la resolucin de los conflictos tiene que participar miembros de cada grupo que interviene en el conflicto. Para que sea productivo el encuentro, las partes en conflicto deben estar dispuestas a dialogar y entenderse unos a otros, de otra manera el trabajo preliminar debe ser elaborado en trminos individuales o asignarles todas las responsabilidades a personas de un nivel superior en la organizacin. Hay muchas estrategias disponibles para resolver conflictos, por ejemplo que cada grupo explique lo que ellos creen que los otros participantes quieren y porqu. Desde el punto de vista de los requerimientos, lo ms importante es analizar las metas de cada grupo. Habitualmente, los conflictos se centran en las soluciones, auque cada grupo puede aceptar las metas de los otros grupos. La estrategia es encontrar la solucin que no genere conflicto, pero que apoye las metas de todos (una situacin de ganar-ganar).

20

3.12

Anlisis orientado a las metas

El anlisis de las metas comprende la relacin entre las metas de alto nivel, las metas de nivel bajo y los requerimientos. En general, el anlisis de las metas responde a estas preguntas: Para cada meta, se tienen los requerimientos que aseguren el logro de ella? Se explica por cada requerimiento cual el su propsito? Estn los requerimientos en el nivel adecuado o la meta debe ser un requerimiento?

Esto puede denominarse tcnica de chequeo, pero es una parte importante de la elicitacin que puede cambiar drsticamente los requerimientos. En muchos casos, las metas importantes se olvidan durante la elicitacin, incluso si se ha hecho prototipaje. Lo que origina que los requerimientos no estn completos y como resultado el sistema final no los asocia con meta alguna. El anlisis permitir nuevas ideas en cuanto a las prioridades de los requerimientos. Esto sucede cuando no se distingue el propsito de los requerimientos. Pueden eliminarse requerimientos, si ninguna tarea parece necesitarlo. En otros casos el propsito del requerimiento no es tan importante, luego se le puede dar una prioridad baja. 3.13 Despliegue de funciones de calidad (QFD por sus siglas en ingls)

QFD usa una notacin sistemtica para relacionar metas y soluciones. La notacin se fundamenta en una matriz donde las metas se colocan en un eje y las soluciones en otro eje. En cada celda de la matriz, se especifica el grado de relacin entre la meta y la solucin. Una extensin de la matriz especifica el grado de conflicto o soporte entre dos soluciones. Otras extensiones especifican los valores percibidos de las metas y costos de la solucin. La prioridad y la relacin costo/beneficio de cada solucin puede ser calculado desde una base de datos. Este enfoque es un buen complemento a otras tcnicas. El problema principal es mantener bajo el nmero de metas y soluciones, por ejemplo, diez metas y diez soluciones permiten tener una matriz de 10*10 la cual es fcil de manejar, pero una matriz de 20*20 puede convertirse en un problema. 3.14 Grupos focalizados

Los grupos de trabajo son similares a la tormenta de ideas, pero son ms estructurados. Los grupos de trabajo comienzan con una fase donde los participantes identifican los problemas relacionados con el modo actual de hacer las tareas. Luego viene la fase donde los participantes imaginan la forma ideal de hacer las tareas. El grupo tambin trata de explicar porque esas ideas son buenas. Esto ayuda a formular los objetivos del nuevo sistema. Muchos actores participan, y al final de la sesin, cada grupo identifica sus prioridades. Luego cuando se da 21

prioridad a los requerimientos, es importante que cada grupo de beneficiarios aporten soluciones para algunas de sus necesidades prioritarias. En est tcnica se motiva a las personas a plantear los problemas actuales que tienen en cuanto al modo de hacer las cosas, las necesidades reales, y la forma idnea de hacerlas. Los usuarios y otros beneficiarios participan e identifican los problemas prioritarios por cada grupo. Estos grupos deben formarse en los inicios del proyecto. El analista debe conocer el rea de aplicacin (dominio) e identificar los grupos de posibles beneficiarios del sistema. Organizando un grupo focalizado El grupo trabaja entre 2 y 5 horas. Los usuarios y otros beneficiarios ms importantes deben participar en este grupo. Si se est tratando de reunir ideas para un nuevo producto, stos podran ser: usuarios finales, compradores potenciales, distribuidores del producto, equipo soporte y programadores. Si est tratando de reunir ideas para un sistema interno, ellos podran ser: usuarios de los departamentos afectados por el sistema, gerentes de esos departamentos, personal de computacin y de soporte al usuario. Pasos a realizar: 1) Invitar participantes: Invitar entre 6 y 18 personas para un taller. Asegrese que cada grupo de beneficiarios est representado (si invita a proveedores no debe sobrepasar la tercera del parte del grupo de trabajo. 2) Iniciar la reunin: Al comienzo de la reunin presentar el tema, presentar a los participantes y lograr un ambiente en el que se sientan cmodos. 3) Identificar malas experiencias: Conduzca la discusin hacia la discusin de las malas experiencias apoyndose en productos, actividades del dominio, etc. Registre los planteamientos. Su rol principal como facilitador es asegurar que nadie domine al grupo y que todos tengan la oportunidad de formular su planteamiento. Su propio equipo debe tener una participacin discreta. 4) Imaginar el futuro: Cambie el escenario para imaginar la solucin ideal. Si usted pudiese obtener lo que desea en sta rea, que solicitara? Permita ideas extravagantes. Trate de obtener una visin de porqu las personas desean las metas planteadas, especialmente en caso de ideas extravagantes. Pregunte: desde cundo desea eso?, ello puede llevar a descubrir la verdadera necesidad que envuelve la idea formulada. Registre las ideas y su justificacin. 5) Liste las necesidades: En esta etapa se pueden recolectar muchas necesidades. Elabore una lista de necesidades que sean requeridas por todos, que contenga: ideas, aspectos negativos, requerimientos y justificacin.

22

Fusione necesidades casi idnticas. Esto es un trabajo arduo y toma algn tiempo hacerlo. Permita a los participantes tomar un descanso entre tanto. 6) Priorizar las necesidades: Solicite a cada grupo de beneficiarios que seleccione las 10 necesidades ms importantes de la lista elaborada y las ordene segn la prioridad. Usted puede solicitarles elaborar una lista conjunta. La lista puede comprender ideas, problemas a resolver, requerimientos. 7) Repase la lista: Finalice la sesin comentando las prioridades designadas por los otros grupoide beneficiarios. Revise y combine los problemas y necesidades. Procesando los requerimientos En la sesin siguiente seleccione los asuntos con los que trabajar. Trate de plantear posibles soluciones a los problemas difciles o deseos imposibles. Es imposible satisfacer los diez primeras problemas, entonces cuales son importantes? El punto crucial es satisfacer las demandas por cada grupo de beneficiarios. Lo que no se debe hacer es sacar un promedio de las prioridades, pues se pueden omitir aspectos esenciales para cada grupo. La seleccin final de los asuntos debe basarse en ambas prioridades: las asignadas por los grupos de beneficiarios y el costo que implica solucionarlo. Estructurando los requerimientos Al principio, las tcnicas de elicitacin generan listas de problemas, metas. Estos tpicos son los aspectos preliminares, requerimientos informales. Usualmente, estos no son verificables, as que se deben transformar en buenos requerimientos. La informacin preliminar la constituyen los requerimientos informales que se obtienen a partir de las tcnicas de elicitacin. Como ejemplo, se pude tener un problema si un requerimiento es el sistema debe ser fcil de usar. Dado que esto no es un requerimiento verificable, se debe trasladar en buenos requerimientos. Una forma puede ser estructurando el requerimiento: R1: Despus de una prctica de X horas, el usuario debe ser capaz de desarrollar la tarea Y, en al menos Z minutos. El paso final es seleccionar los aspectos faltantes, por ejemplo los valores de X, Y, Z. A continuacin se presenta una matriz que muestra la relacin de las tcnicas de elicitacin y su efectividad respecto a lo que se va elicitar. Matriz tcnicas de elicitacin/ aspectos a elicitar

23

Metas/ y decisiones crticas

Resolucin de conflictos

Trabajo actual

Problemas presentes

ideas Sistema futuro

Posibilidades reales

Compromisos

Requerimientos

Prioridades

aspectos elicitar Tcnicas

Entrevista (en grupo) Observacin Demostracin de tareas Estudio de documentos Cuestionarios Tormenta de ideas Grupos principales Talleres Prototipos Pruebas pilotos Estudio de compaas similares Negociacin Anlisis de metas QFD NecesidadesRequerimientos

4. Planillas para elicitacin de requerimientos Las plantillas y patrones lingsticos que se presentan pueden utilizarse para describir los resultados, para registrar y gestionar los requerimientos, y servir de comunicacin entre los usuarios y otros beneficiarios en el sistema. Su objetivo es doble: por un lado intentar paliar la falta de propuestas concretas sobre cmo expresar los requerimientos. Por otro lado, tambin pueden usarse como elementos de elicitacin y negociacin durante las reuniones con los usuarios y otros beneficiarios.

Concluidas

24

Con el uso de patrones, se consigue que durante las sesiones de elicitacin los participantes manejan directamente la documentacin final, favorecindose as su implicacin en el proceso. Como fruto de la experiencia de su utilizacin, para algunos campos de las patrones se han identificado frases estndar que son habituales en las especificaciones de requerimientos y que se han parametrizado. Estas frases, a las que hemos denominado patrones lingsticos, pueden usarse para rellenar los campos de las plantillas dndole valores a los parmetros con la informacin oportuna. Las plantillas como elemento de elicitacin y negociacin Ambos aspectos, la estructuracin de la informacin en forma de plantilla y la propuesta de frases estndar, facilita la redaccin de los requerimientos, permitiendo a los participantes en las actividades de elicitacin centrarse en expresar sus necesidades y no en cmo expresarlas. En la notacin usada para describir los campos de cada plantilla, la frase entre los smbolos < x > deben ser convenientemente reemplazada, mientras que la frase que se encuentren entre los smbolos [y] son opcionales, es decir pueden aparecer o no. Las plantillas pueden ser de diversos tipos, de acuerdo a si se disean para: objetivos requerimientos funcionales requerimientos no funcionales requerimientos de informacin conflictos.

Parte comn de las plantillas para todos los tipos 25

Los campos que pueden estar presentes en todos los tipos de plantillas son 3,:

<tipo> <id> Versin Autores <nombre significativo> <n de la versin actual> <fecha versin actual> <autor de la versin actual> <organizacin del autor> .. Fuentes <fuente versin actual> <organizacin de la fuente> .. Descripcin Importancia Urgencia Estado Estabilidad Comentarios <<tipo> a cumplir por el sistema> <importancia del <tipo>> <urgencia del <tipo>> <estado del <tipo>> <Estabilidad del <tipo>> <Comentarios adicionales sobre el <tipo>>

Figura 1. Planilla campos comunesNote que la expresin <tipo> de la segunda columna, se reemplaza en cada tipo de plantilla por el tipo en cuestin (objetivo, requerimiento, etc). Explicacin adicional de cada campo: <tipo>: indica el tipo de la plantilla: objetivos (OBJ), requerimientos funcionales (Req-F), requerimientos no funcionales (Req-NF), requerimientos de informacin (Req-I), conflictos (C). Importancia: indica la importancia del objetivo (o requerimiento funcional o requerimiento no funcional o requerimiento de informacin o del conflicto). Se asigna un valor (vital, importante, quedara bien o por determinar). Urgencia: igual que el anterior en cuanto a su urgencia, se asigna un valor (inmediato, hay presin, puede esperar o por determinar). Estado: el estado en cuanto a su desarrollo del objetivo, del requerimiento, etc-. Se califica con: en construccin, pendiente de negociacin, pendiente de verificacin, pendiente de solucin.

no todos los campos son obligatorios, depende del problema y del nivel de la solucin- cuales considerar.

26

Estabilidad: este campo indica una estimacin de que pueda sufrir cambios en el futuro. Se califica como: alta, media, baja o por determinar. Es muy importante por cuando permite prever la anticipacin al cambio, favoreciendo el mantenimiento y la evolucin del software. Comentarios: cualquier otra informacin.

A continuacin se muestran los nuevos campos de acuerdo al tipo de plantilla, o se ejemplifica la frase estndar que facilita la redaccin (a fin que el participante se centre en expresar las necesidades y no en cmo expresarlas). Adicionalmente se presenta un ejemplo de cada tipo, considerando un caso de estudio simplificado, la gestin de un video club, indicando solamente los campos mas importantes. 4.1 Plantillas para objetivos Los objetivos del sistema pueden considerarse como requerimientos de alto nivel, de forma que los requerimientos propiamente dichos serian la forma de alcanzar los objetivos. Adicional a la plantilla comn (Figura 1), se agrega el campo subobjetivos:

OBJ .. Descripcin Sub-objetivos . El sistema deber..<objetivo a cumplir por el sistema> <nombre del sub-objetivo> ..

Figura 2. Planilla de objetivos El significado del campo es el siguiente: Subobjetivos: en este campo pueden indicarse los subobjetivos que dependen del objetivo que se est describiendo. En sistemas complejos puede ser necesario establecer una jerarqua de objetivos previa a la identificacin de los requerimientos. En caso que esto no sea necesario, puede ignorarse este campo. La frase estndar en el campo descripcin sugiere que se comience por el sistema deber...

Ejemplo.
objetivo O5 Descripcin Gestin de socios El sistema deber mantener la informacin de los socios: su inclusin, retiro y modificaciones

27

Estabilidad

alta

4.2 Plantilla para requerimientos (funcionales y no funcionales) Los sistemas deben proporcionar servicios. La plantilla de requerimientos funcionales ayuda a los clientes y usuarios a responder la pregunta qu debe hacer el sistema para alcanzar los objetivos?. Adicional a la plantilla comn (Figura 1), se agregan los siguientes campos:

Req-F o Req-NF

. <nombre del objetivo>

Objetivos asociados Requerimiento s asociados

<nombre del requerimiento>

..

Figura 3. Planilla para requerimientos (funcionales y no funcionales) Siguiendo con un ejemplo:

Req-NF 06 Descripcin Objetivos asociados Urgencia Portabilidad El sistema deber ser portable a linux Independizarse de plataformas (obj-07) alta

En el campo descripcin debe indicarse la capacidad que debe presentar el sistema. 4.3 Plantilla para requerimientos de informacin La plantilla para requerimientos de informacin, que puede verse en la figura 4, ayuda a los clientes y usuarios a responder a la pregunta qu informacin relevante debe ser almacenada por el sistema?. Qu restricciones deb cumplir dicha informacin

28

Adicional a la plantilla comn (Figura 1), se agregan los siguientes campos:

Req-I . Objetivos asociados Requerimientos asociados Descripcin Datos especficos Tiempo de vida Ocurrencias simultneas <nombre del objetivo>

<nombre del requerimiento>

.. El sistema deber almacenar la correspondiente a <concepto relevante> informacin

<datos especficos sobre el concepto relevante> <tiempo medio>, <tiempo mximo> <n medio de ocurrr.simult.>, < n mximo de ocurrr.simult.>

Figura 4. Planilla para requerimientos de almacenamiento Ejemplo:

Req-I 12 Objetivos asociados Req asociados Informacin sobre socios Gestin de socios (obj-o8) Retiro de socio (RF-04) Ingreso de socio (RF-09) Modificacin de los datos del socio (RF-10) Consulta sobre socios (RF-12) El sistema deber almacenar la informacin de los socios

Descripcin Datos especficos

Nmero del socio

C.I. nombre y apellido direccin telfono pelculas actualmente alquiladas alta

Estabilidad

29

Anotaciones importantes de algunos campos de la plantilla: Objetivos asociados: este campo debe contener una lista con los objetivos a los que est asociado el requerimiento. Esto permite conocer qu requerimientos harn que el sistema a desarrollar alcance los objetivos propuestos y justifican de esta forma la existencia o propsito del requerimiento. Requerimientos asociados: en este campo se indican otros requerimientos que estn asociados por algn motivo con el requerimiento que se est describiendo, permitiendo as tener una rastreabilidad horizontal Datos especficos: este campo contiene una lista de los datos especficos asociados al concepto relevante, de los que pueden indicarse todos aquellos aspectos que se considere oportunos (descripcin, restricciones, ejemplos, etc.). Tiempo de vida (el nmero medio o mximo que se espera para cada ocurrencia del concepto) y ocurrencias simultneas (el numero medio y mximo de ocurrencias simultneas del concepto relevante).

4.4 Plantilla para conflictos Para documentar los conflictos y las soluciones adoptadas, se propone una plantilla. Adicional a los campos de la plantilla de la Figura 1, se tienen::
Conflicto .. Objetivos asociados Requerimiento s asociados <nombre del objetivo> .. <nombre del requerimiento> ..

Figura 5. Planilla de conflictos

5. Bibliografa Ian Sommerville y Pete Sawyer. Requirements Engineering. A Good Practice Guide. Cap. 4. Lancaster University. Ed. Jhon Wiley &sons,1998. www.comp.lancs.ac.uk/computing/resources/re-gpg/ Soren Lauesen. Software Requirements. Styles and Techniques. Cap. 4. Samfundslitteratur, 1999

30

Durn A. y Bernrdez B. Metodologa para la Elicitacin de Requisitos de Sistemas Software Versin 2.3. Informe Tcnico LSI-2000-20 (revisado). Universidad de Sevilla. Abril 2002. URL: http://www.lsi.us.es/~amador/publicaciones/metodologia_elicitacion_2_3.pdf.zip Universidad de Texas. JAD: Austin. http://www.utexas.edu/hr/is/pubs/jad.html#what Caja de herramientas de Gestion MYPIME. Guatemala. Tormenta de ideas: http://www.infomipyme.com/Docs/GT/Offline/inicioempresa/brainstormi.htm Potenciacin Comunitaria. Tormenta de ideas: Phil Bartre phd. http://www.scn.org/mpfc/modules/brn-ints.htm Universidad de Sevilla. 2005. (Curso sobre anlisis de requerimientos): http://www.lsi.us.es/docencia/pagina_asignatura_doc.php?id=20&cur=2004

URL de inters: -

6. Actividades propuestas al estudiante 1. 2. 3. Investigar que son las entrevistas y sus tipos. Seleccione el tipo de entrevistas a realizar durante el mini proyecto. Planifique y redacte las entrevistas preliminares para mini proyecto.

4. Investigue el procedimiento para llevar acabo cada una de las siguientes tcnicas: Estudio de documentos, Observacin, Cuestionarios, talleres, Prototipaje pruebas pilotos, estudio de organizaciones similares, negociacin, anlisis orientado a metas QFD y grupos focalizados. 5. Determine cuales de las tcnicas estudiadas puede emplearse para la Elicitacin en su mini proyecto. 6. Elaborar un cuadro comparativo de todas las Tcnicas de Elicitacin estudiadas.

7.

Realice un anlisis de la siguiente figura:

31

32