Ingeniera de Software

Metodologas para la determinacin de requerimientos En uno de los prrafos ms citados en la bibliografa de la Ingeniera del Software, Frederick P. Brooks, dice "La parte ms difcil de construir un sistema es precisamente saber qu construir. Ninguna otra parte del trabajo conceptual es tan difcil como establecer los requerimientos tcnicos detallados, incluyendo todas las interfaces con gente, mquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difcil de corregir ms adelante. Entonces, la tarea ms importante que el ingeniero hace para el cliente es la extraccin iterativa y el refinamiento de los requerimientos del producto." Entonces tenemos que los requerimientos se deben descubrir antes de empezar a construir un producto, y que puede ser algo que el producto debe hacer o una cualidad que el producto debe tener. Un requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o cualidades, o porque el cliente quiere que ese requerimiento sea parte del producto final. As que si no se tienen los requerimientos correctos, no se puede disear o construir el producto correcto y, consecuentemente, el producto no permitir a los usuarios finales realizar su trabajo. Y esto est confirmado por estudios que demuestran que ms del 60% de los errores de diseo se originan durante las etapas de requerimientos y anlisis. Los requerimientos se pueden dividir en requerimientos funcionales y no-funcionales:

Los funcionales definen qu hace el sistema (describen todas las entradas y salidas), es decir, las funciones del sistema. Por su parte, los no-funcionales definen los atributos que le indican al sistema cmo realizar su trabajo (eficiencia, hardware, software, interfase, usabilidad, etc.); es el cmo, cundo y cunto del qu.

En el escenario planteado para este trabajo, la dificultad de establecer los requerimientos tcnicos se acenta ya que estamos posicionando al analista frente a un dominio que desconoce, y planteamos un cliente que no tiene claramente estructurados los procesos del negocio (incluyendo metas y objetivos), por lo que el analista puede enfrentarse a objetivos ambiguos y no operacionales; objetivos operacionales pero en conflicto entre s; o puede resultarle difcil determinar las variables que entran en juego en todos los procesos empresariales; todo lo cual dificulta la determinacin de las acciones que se deben seguir para cumplir con las expectativas del cliente. Ingeniera de Requerimientos La Ingeniera de Requerimientos se define, segn Otras, como un "conjunto de actividades en las cuales, utilizando tcnicas y herramientas, se analiza un problema y se concluye con la especificacin de una solucin (a veces ms de una)." Entonces, "Ingeniera de Requerimientos" se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requerimientos para un producto determinado. El uso del trmino "ingeniera" implica que se deben utilizar tcnicas sistemticas y repetibles para asegurar que los requerimientos del sistema estn completos y sean consistentes y relevantes. No existe un proceso nico que sea vlido de aplicar en todas las organizaciones. Cada organizacin debe desarrollar su propio proceso de acuerdo al tipo de producto que se est desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniera de requerimientos. Hay muchas maneras de
Apuntes recopilados por Vicente Aranda Pgina 1

Ingeniera de Software
organizar el proceso de ingeniera de requerimientos y muchas veces tenemos tambin que recurrir a consultores, ya que ellos tienen una perspectiva mas objetiva que las personas involucradas en el proceso. Actividades de la Ingeniera de Requerimientos Usualmente podemos dividir las prcticas de la Ingeniera de Requerimientos en 4 actividades, a saber:

Extraccin Anlisis Especificacin Validacin

Como toda divisin de tareas, no es una estricta representacin de la realidad, sino que se hace con el fin de sistematizar la realizacin de la IR. En general la delimitacin entre una actividad y la otra no es tan clara, ya que estn sumamente interrelacionadas, existiendo un alto grado de iteracin y retroalimentacin entre una y otra.

Extraccin Esta fase representa el comienzo de cada ciclo. Extraccin es el nombre comnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aqu, los AN deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. Esto no suele ser tarea fcil: muchas veces los clientes/usuarios no tienen una idea clara de sus necesidades reales, diversas personas dentro de la organizacin tienen necesidades encontradas, pueden existir limitaciones tcnicas o tecnolgicas para cumplir con algunos requerimientos, etc. Pero, en definitiva, descubrir los
Apuntes recopilados por Vicente Aranda Pgina 2

Ingeniera de Software
requerimientos del sistema no slo implica preguntar a las personas qu quieren: es un proceso delicado que involucra comprender el domino de aplicacin, es decir, obtener un conocimiento del rea general de aplicacin del sistema; comprender el problema en s, lo que implica que se debe extender y especializar el conocimiento sobre el dominio general para que se aplique al cliente en particular; comprender el negocio, por tanto, se debe entender en profundidad cmo es que este sistema interactuar afectar a las partes del negocio que estarn involucradas y cmo puede contribuir a lograr las metas de la empresa; finalmente, comprender las necesidades y restricciones de los usuarios del sistema, en particular, se deben entender los procesos de trabajo que se supone que el sistema apoyar y el rol de cualquier otro sistema que actualmente se involucre en dichos procesos. Es importante, entonces, que la extraccin sea efectiva, ya que la aceptacin del sistema depender de cuan bien ste satisfaga las necesidades del cliente y de cuan bien asista a la automatizacin del trabajo. Anlisis Sobre la base de la extraccin realizada previamente, comienza esta fase -que se presenta sumamente compleja en un proyecto donde el dominio es desconocido- en la cual sea apunta a descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un anlisis luego de haber producido un bosquejo inicial del documento de requerimientos; aqu se leen los requerimientos, se conceptan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos Debemos destacar que no es posible convertir el anlisis en un proceso estructurado y sistemtico, lo que convierte a esta etapa en "subjetiva" porque depende en gran medida del juicio y de la experiencia del AN. Especificacin En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la prctica, esta etapa se va realizando conjuntamente con el anlisis, pero podramos decir que la Especificacin es el "pasar en limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de documentacin, como la notacin UML. Validacin La validacin es la etapa final de la Ingeniera de Requerimientos. Su objetivo es, valga la redundancia, validar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripcin, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estn completos. La validacin representa un punto de control interno y externo; interno, porque se debe verificar internamente lo que se est haciendo, y externo, porque se debe validar con el cliente.

Apuntes recopilados por Vicente Aranda

Pgina 3

Ingeniera de Software
Preferentemente, el documento de requerimientos obtenido en la etapa anterior slo debera incluir los requerimientos que son aceptables para los usuarios. Pero es inevitable que durante la validacin se descubran algunos problemas relacionados con los usuarios, y esto se debe corregir antes de aprobarse el documento final de requerimientos. En definitiva, la validacin de especificaciones realmente significa asegurarse de que el documento de requerimientos represente una descripcin clara del sistema, y es una verificacin final de que los requerimientos cubren las necesidades de los usuarios. Esta etapa puede confundirse con la de anlisis, pero la diferencia es clara: mientras que en el anlisis se trabaja sobre el boceto del documento de requerimientos, en la validacin se utiliza el documento final, lo que equivale a decir, los requerimientos "depurados". Herramientas Ahora se describen las distintas tcnicas y herramientas que se utilizan para llevar a cabo cada una de las actividades del proceso de IR. Las herramientas que fueron seleccionadas son las consideradas ms pertinentes para el escenario planteado en este artculo.

Entrevistas y cuestionarios Las entrevistas y cuestionarios se emplean para reunir informacin proveniente de personas o grupos, informacin que se obtiene conversando con el encuestado. Para la realizacin de las entrevistas debemos coordinar previamente la fecha y hora, y debemos realizar un plan de agenda, en el cual hacemos un punteo del objetivo de la entrevista. Por ejemplo, en la primer entrevista estableceremos un plan de
Apuntes recopilados por Vicente Aranda Pgina 4

Ingeniera de Software
comunicacin, en el cual se intercambiarn los telfonos, celulares, direcciones de email y horarios de contacto. Para realizar las entrevistas, conviene llevar preparado un cuestionario. En trminos generales, un cuestionario consiste en un conjunto de preguntas presentadas a una persona para su respuesta. La forma de la pregunta puede influir en las respuestas, por lo que hay que planearlas cuidadosamente. Las preguntas suelen distinguirse en dos categoras: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados respondan con su propia terminologa. Generalmente estas son ms reveladoras, ya que los interrogados no estn limitados en sus respuestas. Son especialmente tiles en la etapa exploratoria de la investigacin, cuando el AN busca penetrar en el pensamiento del encuestado. A continuacin se presentan algunos ejemplos de preguntas abiertas:

Cul es la razn por la que quiere resolver este problema? Cmo se resuelve el problema actualmente? Cul es el valor de una solucin exitosa? Quin usar el sistema que se va a construir? Cmo deseara llevar a cabo esta actividad?

Por su parte, las preguntas cerradas predeterminan todas las posibles respuestas y el interrogado elige entre las opciones presentadas. Estas preguntas las podemos utilizar cuando estamos estableciendo el criterio de priorizacin de los casos de uso con el cliente. Para cada uno preguntamos si es a corto plazo, a futuro, o Indispensable. Como vemos, la respuesta est acotada a tres opciones. Tambin podemos volver a utilizarla cuando tenemos que negociar algn requerimiento con el cliente. Sistemas existentes Esta tcnica consiste en analizar distintos sistemas ya desarrollados que estn relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfases de usuario, observando el tipo de informacin que se maneja y cmo es manejada. Esto puede ser til para descubrir informacin importante a tener en cuenta, informacin que tal vez el cliente/usuario haya fallado en comunicar. Tambin es til analizar las distintas salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas. Luego de este anlisis tambin podemos realizar una tormenta de ideas y as obtener requerimientos sumamente interesantes. Desde mi punto de vista y, aunque requiere de cierto grado de trabajo (investigacin y anlisis), la podemos realizar a priori sin que intervenga el cliente/usuario; para ello, existen en internet cantidad de demos de productos que pueden resultar similares y, tambin, podemos establecer contacto con profesionales que desarrollan sistemas de caractersticas comparables. Otra ventaja que presenta esta tcnica es que como estos sistemas ya estn en produccin, ya han pasado por la curva de aprendizaje del dominio del problema. Entonces, cuando analizamos estos sistemas, tenemos que tratar de pensar, por ejemplo, por qu manejan cierta informacin y para qu sirve, lo que resultar de suma utilidad para nuestro cliente.

Apuntes recopilados por Vicente Aranda

Pgina 5

Ingeniera de Software
Tambin es recomendable que luego de haber analizado el sistema, se lo mostremos al cliente/usuario, ya que por su experiencia puede sugerir importantes ideas nuevas. Grabaciones de video y de audio Bsicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las entrevistas, y para analizar algn proceso en particular. En cuanto a su funcin de apoyo, es importante por cuanto permite centrar la atencin en la entrevista en s en vez de distraerse tomando notas de todo lo que se dice. Cuando se est grabando la conversacin, basta con "puntear" en una libreta los temas tratados para despus tener una gua bsica de los temas tratados y saber en qu lugar de la grabacin buscar. Adems, permite analizar los temas con ms detenimiento y con una visin ms global, pues ya se ha conversado sobre todos los puntos necesarios y se han visto los procesos ad-hoc. Cuando se trata de analizar algn proceso en particular, su ayuda es inestimable (sobretodo las filmaciones de video) ya que permite ver y analizar en detalle ese proceso la cantidad de veces que sea necesario. Y no olvidemos que filmando el lugar de trabajo estamos capturando el proceso de trabajo, lo que evita que impongamos nuestras expectativas y preferencias. Para finalizar, mencionamos que siempre es conveniente comenzar las grabaciones con preguntas poco importantes que sirvan para "relajar el ambiente", ya que el entrevistado puede ponerse nervioso durante los primeros minutos de grabacin. Debemos darles tiempo a las personas para que se distiendan y se sientan cmodas con la idea de ser grabados o filmados. Brainstorming (tormenta de ideas) Este es un modelo que se usa para generar ideas. La intencin en su aplicacin es la de generar la mxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intencin de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irn eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", etc. Las reglas bsicas a seguir son:

Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtencin de una cantidad mayor de ideas creativas. Conviene suspender el juicio crtico y se debe permitir la evolucin de cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la generacin de ideas. Por ms locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente til. A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva. Escribir las ideas sin censura.

Arqueologa de documentos
Apuntes recopilados por Vicente Aranda Pgina 6

Ingeniera de Software
Con la aplicacin de esta herramienta se tratan de determinar posibles requerimientos sobre la base de inspeccionar la documentacin utilizada por la empresa; por ejemplo, boletas, facturas, remitos, etc. Esta herramienta sirve ms que nada como complemento de las dems tcnicas, y nos ayuda a obtener informacin que de otra manera sera sumamente difcil conseguir. Por ejemplo, en las facturas podemos encontrar informacin que no se pensaba manejar y que en definitiva resulta de suma utilidad, como un nmero propio de la empresa que se utiliza para saber el orden que tiene la factura en la carpeta y que permite encontrar las copias del documento con mayor rapidez. En definitiva, se debe recolectar cualquier formulario o documento que sea utilizado para registrar o enviar informacin. Para el anlisis de cada uno de estos documentos, debemos realizar algunas preguntas, como:

Cul es el propsito de este documento? Quin lo usa? Por qu? Para qu? Cules son las tareas que realizan con este documento? Se puede encontrar una relacin entre los documentos? Cul es el proceso que realiza la conexin? Cul es el documento que da ms problemas a los usuarios?

Aprendiz Esta herramienta se basa en la idea del maestro y el aprendiz, y es una buena forma de observar el trabajo real. Aqu, el aprendiz es representado por el AN, y el usuario/cliente cumple el rol de maestro. El aprendiz se sienta con el maestro a aprender por medio de la observacin, haciendo preguntas como por qu hizo eso? y qu significa eso?, y tambin realizando algn trabajo bajo la supervisin del maestro. Esta tcnica puede ser combinada con la herramienta de modelo conceptual. A medida que el trabajo es observado y explicado, el AN puede realizar bosquejos para cada una de las tareas realizadas, y tambin puede bosquejar como se conectan por medio de los distintos flujos de datos. La aplicacin de esta herramienta es muy til, ya que a veces es difcil para el cliente/usuario el explicar cmo realiza su trabajo. Es tambin una tcnica apropiada para un proyecto donde el problema no es estructurado, ya que es una de las mejores formas de obtener el conocimiento que se encuentra en la "cabeza" del cliente. Una de las posibles objeciones que se le pueden hacer a esta herramienta es que su implementacin requiere de mucho tiempo. Observacin Es sumamente difcil describir cmo hacer el nudo de un calzado deportivo, pero es sumamente fcil mostrar los pasos para hacerlo. Observar como se hacen las cosas es una buena manera de entender lo que estas requieren. Conectarse ntimamente con la cultura de la organizacin, vivirla, es una herramienta que debe ser tomada en cuenta. Tambin podemos realizar filmaciones del lugar de trabajo, para luego observarlas y analizarlas, buscando patrones, procesos,
Apuntes recopilados por Vicente Aranda Pgina 7

Ingeniera de Software
problemas, etc. Siempre tenemos que estar atentos a lo que sucede en el entorno de la organizacin; por ejemplo, ver cmo resuelven un problema que surge, como un llamado telefnico que puede ocurrir mientras estamos presentes. Dentro de la estrategia de observar tenemos que tratar de buscar estructuras y patrones. La estructura del trabajo para los usuarios suele ser invisible, por lo que ser nuestro trabajo realizar las abstracciones necesarias. Run Use Case WorkShop (Talleres de Trabajo basados en los Casos de Uso) Estos talleres de trabajo se realizan entre el cliente/usuario y el equipo de requerimientos. La primer parte del WorkShop consiste en generar los escenarios. Para esto se necesita la informacin que tiene para brindar el usuario/cliente. La idea es conversar por medio de los casos de uso y extraer de los usuarios las cosas esenciales que suceden cuando ocurre un evento determinado. As, tratamos de definir la serie de usuarios y reconocer los pasos que se realizan para el caso de uso en estudio. Luego preguntamos si los pasos registrados estn bien o si hay que cambiarlos o mejorarlos. Como resultado de este proceso obtenemos un excelente bosquejo del caso de uso. Una vez finalizada la etapa anterior, el equipo de requerimientos retorna a la oficina a especificar y deducir los requerimientos, a partir del conocimiento previamente adquirido. Prototipos Durante la actividad de extraccin de requerimientos, puede ocurrir que algunos requerimientos no estn demasiado claros o que no estemos muy seguros de haber entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final. Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitindonos conseguir una importante retroalimentacin en cuanto a si el sistema diseado en base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva. Anlisis FODA Con este anlisis se intentan identificar las principales fortalezas, oportunidades, debilidades y amenazas con las que se enfrenta una empresa. Entonces, por un lado, tenemos las oportunidades y las amenazas, que se refieren a los factores externos que pueden afectar el futuro del negocio. Por otro lado, se encuentran las fuerzas y debilidades que son factores internos; estas fuerzas sealan ciertas estrategias cuya aplicacin podra conducir al xito, mientras que las debilidades sealan aquello que la empresa debe corregir. Esta herramienta es sumamente til para analizar la situacin de una empresa y ver de qu forma podemos ayudar a disminuir las debilidades y amenazas, y cmo podemos aprovechar las oportunidades o cmo podemos crear nuevas oportunidades y cmo hacer an ms fuertes las fortalezas. Cadena de valor

Apuntes recopilados por Vicente Aranda

Pgina 8

Ingeniera de Software
Todas las empresas son una coleccin de actividades que se llevan a cabo para disear, producir, distribuir, entregar y apoyar a su producto. La cadena de valor divide las empresas en nueve actividades estratgicas a fin de comprender el comportamiento de los costos en determinado negocio o industria y en las fuentes de diferenciacin presentes y futuras. En este anlisis se deben examinar los costos y el funcionamiento de cada una de las actividades productoras de valor, tratando de mejorarlos. Con esta herramienta podemos analizar los flujos de informacin que intervienen en las distintas actividades. Sirve tambin, por ejemplo, en el caso de que existan sistemas operacionales automatizados, para investigar qu tipo de informacin maneja y para qu se utiliza. Analizando este modelo, podemos buscar la forma en la cual el sistema puede ayudar a obtener mayor valor para la actividad o conjunto de actividades estudiadas. Modelo de clase conceptual | Diagrama Conceptual | Diagrama de Clases Conceptual Un modelo conceptual es una representacin de conceptos del dominio del problema. [Fowler96]. Permite mostrar conceptos, asociaciones entre conceptos y atributos de conceptos. La creacin del modelo tambin ayuda a comprender la terminologa del dominio y comunica cules son los trminos importantes y las relaciones existentes entre ellos. La intencin del concepto (categora de idea o cosas) es la descripcin de sus atributos, operaciones y significado. Para representar un concepto podemos basarnos en la metodologa orientada a objetos, utilizando las clases como forma de representar el concepto, dado que una clase representa un concepto del dominio del problema que abarca un amplio espectro, como un pedido, una mquina, una tarea, un trabajo, etc. Esta herramienta puede ser utilizada para capturar el vocabulario del sistema que se est desarrollando. Mediante ella podemos incluir abstracciones que forman parte del dominio. Para especificar el modelo conceptual utilizamos el diagrama de clases en el cual mostramos las relaciones existentes entre las clases. Es decir, mostramos los conceptos que se manejan en el negocio y como se relacionan entre s. Es una buena forma para obtener un idea general de cmo funciona el negocio (relaciones entre las clases/concepto), y capturar vocabulario y conceptos (clase). Tambin es de ayuda para incluir nuevos conceptos al glosario. Diagrama de pescado Es una antigua pero til herramienta que sirve, en el proceso de Ingeniera de Requerimientos, para analizar problemas y comprender cules son sus causas. Con esta herramienta podemos analizar cmo impacta la solucin planteada para un requerimiento dado. Por ejemplo, cmo afecta al trabajo diario del empleado. Tambin en el caso de que la solucin planteada interacte con otros sistemas existentes (modificando, consultando o intercambiando informacin) el diagrama de pescado nos permite analizar los posibles problemas que pueden surgir. Glosario

Apuntes recopilados por Vicente Aranda

Pgina 9

Ingeniera de Software
El glosario es una simple lista de trminos en donde se explica su significado. En esta lista se incluyen y definen todos los trminos que requieren explicacin, mejorando as la comunicacin intergrupal y la comunicacin con el cliente, y mitigando el riesgo de malos entendidos. Los trminos que se incluyen provienen de todas las reas del proyecto: casos de uso, terminologa propia del negocio, etc. El glosario se va actualizando durante el transcurso del proceso de IR, perfeccionndolo en cada nuevo ciclo. Diagrama de actividad El objetivo es el de comprender el entorno en el cual se encuentra el negocio, describiendo su funcionamiento interno y su relacin con el ambiente.

Casos de uso El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. [Jacobson]. Es una tcnica diseada para especificar el comportamiento de un sistema.

Apuntes recopilados por Vicente Aranda

Pgina 10

Ingeniera de Software
Este documento describe la posible secuencia de interacciones entre el sistema y uno o ms actores, en respuesta a un estmulo inicial proveniente de un actor. No es una simple historia especfica de eventos especficos intercambiados entre el sistema y los actores o escenario, sino que es una descripcin de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. Los requerimientos se pueden expresar de diferentes formas, desde texto sin formato estricto hasta expresiones en un lenguaje formal, pasando por todas las formas intermedias. La mayora de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso.

Casa de calidad o QFD El esquema QFD (Quality Function Deployment) es una matriz que representa las casas de calidad, en las cuales las filas representan los "qu", o sea, la lista de los requerimientos, mientras que las columnas representan los "cmo", es decir, cmo se llevan a cabo los requerimientos (casos de uso).

Checklist (lista de verificacin) Esta herramienta es muy fcil de utilizar y proporciona una gran utilidad. En general es una lista de preguntas que el AN debe usar para evaluar cada requerimiento. Los AN deben verificar y marcar los puntos de esta lista mientras leen el documento de

Apuntes recopilados por Vicente Aranda

Pgina 11

Ingeniera de Software
requerimientos. Cuando se descubren problemas potenciales, deben ser anotados, ya sea en los mrgenes del documento, ya sea en una lista de anlisis. Las checklist son tiles porque brindan un recordatorio de lo que se debe buscar y reducen las chances de pasar por alto alguna verificacin importante. Y no slo son tiles para verificar requerimientos; tambin se puede aplicar con los casos de uso y con los puntos a ser tratados en el plan de agenda. Conclusin Habiendo finalizado el estudio del Proceso de Ingeniera de Requerimientos y las herramientas que se pueden utilizar para realizar las distintas actividades implicadas en tal proceso, quisiera compartir algunas experiencias que pude obtener luego de su aplicacin prctica. Como se desprende del artculo previo, existen numerosas herramientas y tcnicas que se pueden utilizar en cada una de las actividades del proceso de IR. Y, como toda herramienta, es necesario practicar numerosas veces su manejo para lograr sacar el mejor provecho de ellas. Asimismo, no basta conque utilicemos una sola herramienta para lograr nuestros fines: cada una de ellas aporta diferente y vital informacin sobre el problema en cuestin. Con respecto al proceso, herramientas y tcnicas de extraccin, afirmo que, en definitiva, si somos capaces de comprender lo que el cliente/usuario est diciendo, entonces estamos realizando nuestro trabajo en buena forma. Las tcnicas de extraccin de requerimientos permiten establecer un dilogo con el cliente/usuario; es decir, permiten el flujo de conocimientos entre las partes. En este sentido, he podido concluir que una de las mejores formas de comunicacin que existen son las entrevistas "cara a cara"; esos pequeos "momentos de la verdad" en los que nos encontramos atendiendo al cliente, tratando de entender sus necesidades y problemas y viendo como podemos satisfacerlos y solucionarlos. Es imprescindible en estos momentos saber observar y escuchar. En cuanto a la especificacin del sistema, los casos de uso se me han revelado como una excelente va para su concrecin. Para llegar a determinar los casos de uso, podemos utilizar diferentes tcnicas y herramientas, que se corresponden a la actividad de extraccin, anlisis y validacin. Estas herramientas las utilizamos para entender el problema, los requerimientos, y, a su vez, nos ayudan a construir los casos de uso correspondientes. Pero a veces stos no son suficientes a la hora de entender el problema, es decir es necesario documentar correctamente todo el ciclo o proceso, obtener una trazabilidad desde la obtencin de los requerimientos a los casos de uso, para ser capaces de entender el problema.

Apuntes recopilados por Vicente Aranda

Pgina 12