Anlisis de Requerimiento

Integrantes: Juan Jos cahuana Rios Jhann Frank Garca Mendoza Profesor: Curso: Algoritmos Avanzados

Introduccin
La etapa de Anlisis de Requerimientos, es la primera etapa en el desarrollo de un SI. Comienza despus de que el Cliente ha detectado una ausencia, falla o falta de oportunidad de la informacin o simplemente, luego que la organizacin ha determinado un c ambio en sus polticas, reglas o tecnologas a aplicar. En esta etapa, deberemos responder a una pregunta fundamental: Qu es lo que quiere el Cliente? y para ello, deberemos diagnosticar la Situacin Actual, recopilar los requerimientos del Cliente, tan to en relacin al Sistema, como generales respecto del rea Informtica, es decir la Situacin Ideal, para as poder definir Alternativas de Solucin, segn las cuales podremos avanzar desde lo que hoy se posee, hacia el punto que se pretende llegar. Como parte de nuestro trabajo, deberemos sealar cual de las alternativas, es a nuestro juicio la ms conveniente (y justificarlo) en la Propuesta. Hecho lo anterior, el Cliente evaluar nuestro trabajo, y si decide contratarnos, deberemos establecer un Contrato que nos asegure a ambas partes (cliente y desarrollador) una claridad respecto de qu, cmo, cundo y bajo qu condiciones trabajaremos en conjunto.

Anlisis de Requerimientos Qu son Requerimientos?

Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuacin se presenta la definicin que aparece en el glosario de la IEEE. 1. Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 2. Una condicin o capacidad que debe estar presente en un sistema o componentes de sistemapara satisfacer un contrato, estndar, especificacin u otro documento formal. 3. Una representacin do cumentada de una condicin o capacidad como en (1) o (2). Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, c omo por ejemplo, el rendimiento ( en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc.

Caractersticas de los requerimientos

Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aque llos que vayan a consultarlo en un futuro. Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin.

Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. Noambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.

Dificultades para definir los requerimientos

y y y y y y y y y

Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos e stn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Ingeniera de Requerimientos vs. Administracin de Requerimientos

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniera de Requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. A continuacin se darn algunas definiciones para ingeniera de requerimientos. "Ingeniera de Requerimi entos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucrad as y en dnde se describen las funciones que realizar el sistema" Boehm 1979. "Ingeniera de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987.

"Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987. "Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software

Importancia de la Ingeniera de Requerimientos Los principales beneficios que se obtienen de la Ingeniera de Requerimientos son:
y y

Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calid ad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.). Mejora la comunicacin entre equipos: La especificacin de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proy ecto no ser exitoso. Evita rechazos de usuarios finales: La ingeniera de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Personal involucrado en la Ingeniera de Requerimientos Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan ro les especficos dentro de la planificacin del proyecto; el conocimiento de cada papel desempeado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR. No conocer estos intereses puede ocasionar una comunicacin poco efectiva entre clientes y desarrolladores, que a la vez traera impactos negativos tanto en tiempo como en presupuesto. Los roles ms importantes pueden clasificarse como sigue:
y

Usuario final: Son las personas que usarn el sistema desarrollado. Ellos estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; estn familiarizados con los procesos especficos que debe realizar el software, dentro de los parmetros de su ambiente laboral. Sern quienes utilicen las interfaces y los manuales de usuario.

y y

Usuario Lder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde ser empleado el software desarrollado. Ellos proporcionan al equipo tcnico los detalles y requerimientos de las interfaces del sistema. Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son las responsables de la administracin de cambios, de la implementacin y resolucin de anomalas. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado. Analistas y programadores: Son los responsables de l desarrollo del producto en s; ellos interactan directamente con el cliente. Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condicione s presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de pr oyecto, documentadores, diseadores de base de datos, entre otros. Puntos a considerar durante la Ingeniera de Requerimientos Aunque la lista no est completa, se enumer an los puntos ms importantes. Objetivos del negocio y ambiente de trabajo Aunque los objetivos del negocio estn definidos frecuentemente en trminos generales, son usados para descomponer el trabajo en tareas especficas. En ciertas situaciones IR se enfoca en la descripcin de las tareas y en el anlisis de sistemas similares. Esta informacin proporciona la ba se para especificar el sistema que ser construido; aunque frecuentemente se aadan al sistema tareas que no encajan con el ambiente de trabajo planificado. El nuevo sistema cambiar el ambiente de trabajo, sin embargo, es muy difcil anticipar los efectos actuales sobre la organizacin. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en produccin; tambin ocurren cuando cambia el ambiente que lo rodea ( nuevas soluciones a problemas, nuevo equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de mantenimiento; aunque existen diversas razones que dificultan el mantenimiento del software, la falta de atencin a la IR es la principa l. Frecuentemente la especificacin inicial es tambin la especificacin final, lo que obstaculiza la comunicacin y el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen sistemas inadecuados.

Punto de vista de los clientes Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y, diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten procesos que causan conflictos con los solicitados por el usuario.

Diferentes puntos de vistas tambin pueden tener consecuencias negativas, tales como datos redundantes, inconsistentes y ambiguos. El tamao y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un solo aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos.
y

Barreras de comunicacin

La ingeniera de requerimientos depende de una intensa comunicacin entre clientes y analistas de requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicacin. Para remediar esto, se deben abordar nuevas tcnicas operacionales que ayuden a superar estas barreras y as ganar experiencia dentro del marco del sistema propuesto.
y

Evolucin e integracin del sistema

Pocos sistemas son construidos desde cero. En la prctica, los proyectos se derivan de sistemas ya existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo general son una integracin de componentes de varios proveedores. Para encontrar una solucin a problemas de este tipo, es muy importante hacer planeamientos entre los requerimientos y la fase de diseo; esto minimizar la cantidad de fallas directas en el cdigo.

Documentacin de requerimientos

Los documentos de ingeniera de requerimientos son largos. La mayora estn compuestos de cientos o miles de pginas; cada pgina contiene muchos detalles que pueden tener efectos profundos en el resto del sistema. Normalmente, las personas se encuentran con dificultades para comprender documentos de este tamao, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificacin de gran tamao, pues difcilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta despus de haberse construido el sistema.

Usos y Aplicaciones

EL PROCESO DE REQUERIMIENTOS El proceso del establecimiento de requerimientos de un sistema de software, como ya mencionamos, es el primer paso esencial en entregar lo que el cliente desea. A pesar de esto, la insuficiencia de tiempo y esfuerzo son a menudo encontrado en esta actividad y existen pocos mtodos sistemticos para soportarlo. Entre los mtodos conocidos se puede citar a los siguientes: Para Pressman, en el proceso de anlisis de requerimientos del software se puede identificar cinco tareas o etapas fundamentales: 1. Reconocimiento del problema Se deben de estudiar inicialmente las especificaciones del sistema y el plan del proyecto del software. Realmente se necesita llegar a comprender el software dentro del contexto del sistema. El analista debe establecer un canal adecuado de comunicacin con el equipo de trabajo involucrado en el pro yecto. En esta etapa la funcin primordial del analista en todo momento es reconoce r los elementos del problema tal y como los percibe el usuario. 2. Evaluacin y sntesis En esta etapa el analista debe centrarse en el flujo y estructura de la informacin, definir las funciones del so ftware, determinar los factores que afectan el desarrollo de nuestro sistema, establecer las caractersticas de la interfaz del sistem a y descubrir las restricciones del diseo. Todas las tareas ante riores conducen fcilmente a la determinacin del problema de forma sintetizada. 3. Modelizacin Durante la evaluacin y sntesis de la solucin, se crean modelos del sistema que servirn al analista p ara comprender mejor el proceso funcional, operativo y de contenido de la informacin. El modeloservir de pilar para el diseo d el software y como base para la creacin de una especificacin del software. 4. Especificacin Las tareas asociadas con la esp ecificacin intentan proporcionar una representacin del software. Esto ms adelante permitir llegar a determinar si se ha llegado a comprender el software, en lo s casos que se lleguen a modelar se pueden dejar plasmados manuales. 5. Revisin Una vez que se han descrito la informa cin bsica, se especifican los criterios de validacin que han de servir para demostrar que se ha llegado a un buen entendimiento de la forma de implementar con xito el software. La documentacin d el anlisis de requerimientos y manuales, permitirn una revisin por parte del cliente, la cual posiblemente traer consigo modificaciones en las funciones delsistema por lo que debern revisarse el plan de desarrollo y lasestimaciones previstas inicialmente. Mtodo CORE

El mtodo ControlledRequirementsE xpression (CORE) [Norris] es un conjunto de notaciones textuales y grficas, con guas especificadas par a la captura y validacin de requerimientos del siste ma, en las etapas iniciales del diseo del sistema. CORE ha sido, por tradic in, pensado como puramente una tcnica de captura y anlisis de requerimientos (RCA), aunque soporta algunos aspectos de diseo tales como estructuras de datos. CORE est basada en el principio de primero definir el problema a ser analizado (definicin de l problema), y luego dividirlo en unidades o puntos de vista a considerar. 1. Definicin del problema. El propsito de la definicin del problema es identificar los lmites del mismo. Contiene detalles de los objetivos de la empresa de los usuarios del sistema, la base para la necesidad de un nuevo sistema, limitaciones de costo y tiempo, y qui n va a ser el responsable de la revisin y aceptacin de los resultados finales. 2. Estructuracin del punto de vista. El propsito de esta etapa es desc omponer el ambiente del sistema en los elementos para que el sistem a propuesto pueda ser analizado desde los puntos de vista de todas las entidades que se comunican con l, la ms importante de las c uales son los usuarios. Durante esta etapa, todas las entidades que son fuentes potenciales de informacin deben ser identificadas 3. Coleccin tabular. Esta etapa es cuando la informacin sobre los flujos de datos entre los puntos de v ista y el procesamiento de stasesreunida . Esto ayuda a establecer la totalidad y consistencia. 4. Estructuracin de datos. En la etapa previa, los elementos de informacin que pasan entre los puntos de vista son referidos por sus nombres generales. En esta etapa, se da una vista ms cercana al contenido, a la estructura y a la deri vacin de datos, al producir diagramas de estructura de datos.

5. Modelacin individual de puntos de vista. Esta etapa puede dividirse en dos partes. Lo nico concerniente a la primera es convertir las TCF'S en una notacin diferente para producir los d iagramas individuales del modelo de punto de vista. La segunda parte se refiere a agregar alguna informacin nueva perteneciente a flujos de datos internos, control de acciones y tiempo de acciones. 6. Modelacin combinada de punto de vista. Esta etapa facilita el anlisis de una secuencia de eventos de ms de un punto de vista. Cada diagrama de modelo combinado de punto de vista producido durante esta

etapa es una representacin del procesamiento de informacin que ocurre entre puntos de vista. 7. Anlisis de restricciones. En esta etapa, se consideran restricciones adicionales tales como desempeo y seguridad. stas pueden afectar los diagramas de puntos de vista ya producidos. Las restricciones se documentan en una especificacin de restriccin del si stema. Segn Loucopoulos El proceso de ingeniera de requerimi entos en el que se basara este trabajo de tesis es el que propone Loucopoulos [Loucopoulos], en el que seplantea que en esta fase hay que considerar por lo menos tres aspectos fundamentales:
y y y

Comprender el problema Describir formalmente el problema Obtener un acuerdo sobre la naturaleza del problema

Esto nos llevara a simplificar el proceso a tres etapas para obtener los requerimientos del problema que estamos atacando, estas etapas son las siguientes [Loucopoulos]:
y y y

Elicitacin de requerimientos Especificacin Validacin

Elicitacin de requerimientos El propsito de la elicitacin de requerimientos es ganar conocimientos relevantes del problema, que se utilizarn pa ra producir una especificacin formal del software necesario para resolverlo. Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean1 . Aqu vemos nuevamente la importancia que tiene una buena comunicacin entre desarrolladores y client es; de esta comunicacin con el cliente depende que entendamos sus necesidades. Al final de la fase de anlisis de requerimientos el analista podr a llegar a tener un conocimiento extenso en el dominio del problema. Especificacin Una especificacin puede ser vista co mo un contrato entre usuarios y desarrolladores de software, que define el compo rtamiento funcional deseado del artefacto de software (y otras propiedades de ste, tales como perfomance, confiabilidad, et c.), sin mostrar como ser alcanzada tal funcionalidad. Validacin

La validacin es el proceso que certifica que el modelo de los requerimientos es consistente con las intenciones de los clientes y los usuarios; sta es una visin ms general que el concepto comn de validacin, pues se produce en paralelo con la elicitacin y la espec ificacin, tratando de asegurar que tanto las ideas como los conceptos presentados en una descripcin se identifican y explican con claridad La necesidad de validacin aparece cuando:
y y

Se incorpora una nueva pieza de informacin al modelo actual. Cuando diferentes piezas de infor macin se incorporan en un todo coherente.

La validacin no slo se aplica al modelo fi nal de los requerimientos, sino tambin a los modelos intermedios. En la figura 1 podemos ver el esquema del proceso planteado

Entrevistas

Usada la mayor parte de las veces y es prcticamente inevitable el uso de esta tcnica. Y se pueden identificar en tres fases: preparacin, realizacin y anlisis PREPARACIN DE ENTREVISTAS Se procede a hacer la preparacin de la entrevistas; Aqu no se debe improvisar. Estudio del dominio del problema: se debe conocer la terminologa bsica del dominio del problema, evitando que el cliente tenga que explicar trmi nos que para el son obvios. Para ello se recurre a una tcnica auxiliar de estudio de documentacin, a bibliografa sobre el tema, documentacin de proyectos similares hechos anteriormente. Seleccionar a las personas a las que se va entrevistar: se debe minimizar el nmero de entrevistas a realizar, por lo que es fundamental seleccionar a las personas a entrevistar. El orden de realizacin de las entrevistas tambin es importante. Normalmente se aplica un enfoque top -down, comenzando por directivos, que pu eden ofrecer una visin global, ayudar a determinar los objetivos y reducir ciertas reticencias a en sus subordinados, y terminando por los futuros usuarios, que pueden aportar informacin detallada. Determinar el objeti vo 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. PLANIFICAR LAS ENTREVISTAS La fecha, hora, lugar y duracin de las entrevista deben fijarse teniendo en cuenta siempre la agenda del entrevistado. Realizacin de entrevistas Dentro de la realizacin de las entrevistas se distinguen tres etapas: Apertura: el entrevistador debe presentarse e informar el entrevistado sobre la razn de la entrevista, que se espera conseguir , como se utilizara la informacin, la mecnica de las preguntas Desarrollo: la entrevista en si no debera dura mas de dos horas 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 video o audio, siempre que el entrevistado este de acuerdo. Terminacin: se debe recapitular sobre la entrevista 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 conta ctar para aclarar dudas que surjan al estudiar la informacin o al contrastarla con otros entrevistados.

ANLISIS DE LAS ENTREVISTAS

Una vez realizada es necesario leer las notas tomadas, pasarlas a limpio, reorganizarlas la informacin, contrastarla con otras entrevistas o fuentes de informacin, etc. Una ve elaborada la informacin, se puede enviar al entrevistado para confirmar los contenidos. Tambin es importante evaluar la propia entrevista para determinar los aspectos mejorables.

BrainStorming
O tambin llamada tormenta de ideas es una tcnica de reuniones en cuyo grupo objetivo es la generacin de ideas en una ambiente libre de crticas o juicios. Las secciones de brainstorming suelen estar formadas por un nmero de cuatro a diez participantes, uno de los cuales es el jefe de la sesin, encargado ms de comenzar la sesin que de controlarla. Ayuda 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 requer imientos son todava muy difusos. PREPARACION: la preparacin para una sesin de brainstorming requiere que se seleccione a los participantes y al jefe de la sesin, citarlos y preparar la sala donde se llevara a cabo la sesin. Los participantes en una sesin de brainstorming para e licitacin de requerimientos son normalmente clientes, usuario, ingenieros de requerimientos, desarrolladores y, si es necesario algn experto en temas relevantes para el proyecto. GENERACION: el jefe 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 jefe de la sesin, bien aleatoriamente. El jefe es siempre el responsable de dar la palabra a un participante. Este proceso contina hasta que el jefe decide parar, bien porque no se estn generando s uficientes ideas, en cuyo caso la reunin se pospone, bien porque el nmero de ideas sea suficiente para pasar a la siguiente fase.
y y y y

Se prohbe la crtica de ideas, de forma que los participantes se sientan libres de formular cualquier idea. Se fomentan las ideas ms avanzadas, que aunque no sean factibles, estimulan a los dems participantes a explorar nuevas soluciones ms creativas. Se debe generar un gran nme ro de ideas, ya que cuantas ms ideas se presenten ms probables ser que se generen mejores ideas. Se debe alentar a los participa ntes a combinar o completar las ideas de otros participantes.

CONSOLIDACION: en esta fase se deben organizar y evaluar las ideas generadas durante ideas similares, en cuyo caso se unifican en un solo enunciado. Revisar ideas: se revisan las ideas generadas para clasificarlas. Es habitual identificar ideas similares, encuyo caso se unifican en un solo enunciado.

Descartar ideas: aquellas ideas que los participantes consideren excesivamente avanzadas se descartan. 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 apropiadas para una prxima versin del sistema a desarrollar. Documentacin: despus de la sesin, el jefe produce la documentacin oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidacin.

Casos de Uso
Un caso de uso es la descripcin de una secuencia de interacciones entre el sistema y uno o ms actores en la que se considera al sistema como una caja negra. Los casos de uso son una tcnica para especificar el comportamiento de un sistema: Un caso de uso es una secuencia de interacciones entre un sistema y actores que usan alguno de sus servicios. Los actores son personas u otros sistemas que interactan con el sistema cuyos requerimientos se estn describiendo. Un actor puede participar en varios casos de uso y un caso de uso puede estar relacionado con varios actores. Los casos de uso combinan el concepto de evento del anlisis estructurado con otra tcnica de especificacin de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los requerimientos de un sistema es escribir su manual de usuario antes de c onstruirlo [Howes]. De esta forma, es ms fcil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que stos comprendern fcilmente la forma en la que estn expresados. Los casos de uso y UML Esta tcnica, si bien gan pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al sistema desde el punto de vista de aqul que lo va a usar, y no desde el punto de vista del que lo va a construir. De esta forma, es ms fcil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que stos comprendern fcilmente la forma en la que estn expresados. Los casos de uso como una excelente forma de especificar el comportamiento ex terno de un sistema. De esta forma, la notacin de los casos de uso fue incorporada al lenguaje estndar de modelado UML (UnifiedModelingLanguage) A partir de la publicacin del libro de Jacobson, gran parte de los ms reconocidos especialistas en mtodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema. De esta forma, la notacin de los casos de uso fue incorporada al lenguaje estndar de modelado UML (Unifie dModelingLanguage) propuesto por Ivar Jacobson, James Rumbaugh y Grady Booch

Definiciones y Notaciones

Actores Un actor es una agrupacin uniforme de personas, sistemas o mquinas que interactan con el sistema que estamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma telefnica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer las mismas cosas con el sistema, son considerados un nico actor: "Empleado de Ven tas". Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer objetivo de todo analista, ya que un proyecto sin alcance definido nunca podr alcanzar sus objetivos. Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al sistema como distintos actores. La forma ms simple de entender esto es pensar en perfiles de usuario de un sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas. Los perfiles son en este caso equivalentes a los actores. Otro sistema que interacta con el que estamos construyendo tambin es un actor. Por ejemplo, si nuestro sistema deber generar asientos contables para ser procesados por el sistema de contabilidad, este ltimo sistema ser un actor, que usa los servicios de nuestro sistema. Tambin puede ocurrir que el actor sea una mquina, en el caso en que el software controle sus movimientos, o sea operado por una mquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo de un robot, el hardware del robot ser un actor, asumiendo que dentro de nuestro sistema estn las rutinas de bajo nivel que controlan al hardware. Los actores se representan con dibujos simplificados de personas, llamado s en ingls "stickman" (hombres de palo).

Si bien en UML los actores siempre se representan con "hombres de palo", a veces resulta til representar a otros sistemas con alguna representacin ms clara.

El Proceso de Ingeniera de Requerimientos con Casos de Uso A continuacin, se describen los pasos a seguir para aplicar la tcnica con casos de uso a la IR. Identificar los Actores Si la primera pregunta que un analista debe hacer a sus usuarios es Para qu es este sistema?, la segunda es claram ente Para quines es este sistema? Como mencionamos al hablar sobre los actores, identificar a todos ellos es crtico para un buen anlisis de requerimientos. Por lo tanto, antes de avanzar con los casos de uso, debo tratar de identificar todos los tipos de usuario diferentes que tiene el sistema. Si el sistema ser implementado en una empresa, debo preguntar cules de las reas afectadas usarn o actualizarn su informacin. A pesar de hacer una identificacin inicial de los actores, tambin debo repetirl a a medida que empiezo a describir los casos de uso, ya que al conocer ms detalles del sistema, pueden aparecer nuevos tipos de usuarios. Identificar los Principales Casos de uso de cada Actor El siguiente paso es enunciar los nombres de los principales c asos de uso de cada uno de los actores que se identificaron en el paso anterior. No es necesario especificar cules son las acciones dentro del caso de uso. Tampoco debo preocuparme si no aparecen muchos casos, ya que existen tcnicas para encontrar nuevos casos de uso a partir de los existentes. Identificar Nuevos Casos a Partir de los Existentes Uno de los principales errores que se pueden cometer al identificar requerimientos es algo que parece obvio, pero que muchas veces ocurre: olvidarse de algn requerimiento! Como los requerimientos estn en la cabeza de los usuarios, el xito de esta tarea depende de la habilidad del analista. Para ayudarnos a identificar nuevos casos de uso a partir de los casos existentes, podemos aplicar las mismas tcnicas utilizadas para identificar eventos segn el anlisis estructurado. Algunas de las preguntas que debemos hacernos son:

y y y

Cules son las tareas de un actor? Necesita el actor estar informado de ciertas ocurrencias del sistema? Necesita el actor informar al sistema de cambios externos sbitos?

y y y y

Proporciona el sistema el comportamiento correcto al negocio? Pueden ser todos los requerimientos funcionales, desarrollados por los casos de uso? Qu casos de uso soportarn y mantendrn al sistema? Qu informacin debe ser modificada o creada?

Documentacin de Casos de Uso Una vez que identificamos todos los casos de uso, empezamos a documentar sus pasos; este documento se crea para cada caso de uso, detallando lo que el sistema debe proporcionar al actor cuando el caso de uso es ejecutado. Esta tarea no es estrictamente secuencial de la anterior: es posible que, mientras empezamos a documentar los casos, sigamos buscando otros nuevos. Un contenido tpico de un documento de caso de uso sera:
y y y y

Describir cmo comienza el caso de uso y cmo termina. Realizar un flujo normal de eventos. Realizar un flujo alterno de eventos. Detallar las excepciones al flujo de eventos.

Definir Prioridades Una vez documentados los casos de uso, es conveniente definir las prioridades de lo s distintos requerimientos, expresados como casos de uso. Para los escenarios claves y los casos de uso que sern analizados en su iteracin, se debe:
y y y

Representar la funcionalidad central de cada caso de uso. Cubrir varios aspectos de arquitectura. Poner bajo estrs un punto delicado de la arquitectura.

Grficos a Utilizar Dependiendo del tamao del sistema, es probable que un nico grfico con todos los casos de uso nos quede chico. No olvidemos que los modelos grficos son para aclarar el texto, y no para confundir. Si el grfico de casos de uso es una maraa indescifrable, no est cumpliendo su objetivo. Por lo tanto, podemos usar las siguientes reglas para incluir grficos de casos de uso dentro de la SRS.
y y

Un grfico de casos de uso no debe mostrar ms de 15 casos Si es necesario particionar el grfico, debe hacerse por actor. La primera particin debe separar los casos centrales de los casos auxiliares, ya que probablemente les interesen a personas distintas. Si las relaciones de uso y las extensiones e ntran en el diagrama principal, sin dejar de cumplir con la regla 1, debo dejarlas ah. Lo mismo se aplica a los actores abstractos. Si las relaciones de uso no entran en el diagrama principal, debo mostrarlas en grficos teniendo en cuenta que siempre deb o mostrar todos los casos de uso que usan a otro en un mismo diagrama. Si tengo un caso de uso que es usado por gran parte de los otros casos, como por ejemplo el caso de uso "Identificndose ante el sistema", debo evitar mostrarlo en

el grfico principal, ya que las flechas sern imposibles de organizar. Es probable que no haga falta mostrar esta relacin de uso en un grfico.

JAD (Desarrollo conjunto de aplicaciones)

La tcnica denominada JAD (JointApplicationDevelopment), 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 2 a 4 das. En estas reuniones se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrndolos y hacindolos sentirse partcipes del desarrollo. Esta tcnica se base en cuatro principios dinmica de grupo, el uso de ayudas visuales para mejorar la comunicacin (diagramas, transparencias, multimedia, herramientas CASE, etc.), m antener un proceso organizado y racional y una filosofa de documentacin WYSIWYG (WhatYouSeeIsWhatYouGet, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar. Proceso de Desarrollo conjunto de aplicaciones Las sesiones de diseo conjunto de aplicaciones incluyen una variedad de participantes -analistas, usuarios, ejecutivos, etc. -, que aportaran su experiencia y habilidades, en diferente medida, a las sesiones. Aqu su principal inters es que todos los miembros del equipo que participaran en el proyecto se comprometan e involucren con el enfoque JAD. Escoja un patrocinador ejecutivo, una persona de experiencia que presentara y concluir la sesin de JAD. De preferencia, seleccione a u n ejecutivo del grupo de usuarios que tenga algn tipo de autoridad sobre las personas del rea de sistema de informacin que trabajen en el proyecto. Esta persona ser un smbolo visible e importante del compromiso de la organizacin con el proyecto de si stema. Por lo menos un analista del rea de sistema de informacin debe estar presente, pero a menudo el analista toma el rol pasivo, a diferencia de lo que ocurre en la entrevista tradicional en el cual el analista controla la interaccin. Como analista d el proyecto, usted debe estar presente en la sesin de JAD para escuchar lo que dicen los usuarios y lo que necesitan. Adems, usted tendrn que dar una opinin especializada en caso que en la sesin de JAD se proponga alguna solucin de un costo desproporcionado. Sin este tipo de retroalimentacin inmediata, las soluciones poco realistas con costos excesivos podran colarse en la propuesta y ser difciles de eliminar mas tarde. Es conveniente seleccionar de ocho a 12 usuario de cualquier nivel para partici par en las sesiones de JAD. Procure seleccionar a usuarios por encima del nivel operativo, que tenga capacidad para explicar que informacin requieren para realizar sus trabajos, as como las caractersticas que les agradaran en un sistema de cmputo nuevo o mejorado.

El lder de la sesin no debe ser un experto en el anlisis y diseo de sistema sino alguien que cuente con habilidad de comunicaciones excelentes para facilitar las interacciones apropiadas. Tome nota que no es conveniente designar a un lde r de sesin que le reporte a una persona del grupo. Para evitar esta posibilidad, una organizacin podra contratar a un consultorio externo que funja como lder de sesin. El punto es contar con una persona que atraiga la atencin del grupo para tratar la s cuestiones importantes de los sistemas, negociar satisfactoriamente y resolver los conflictos, y ayudar a los miembros del grupo a alcanzar un acuerdo general. Su sesin de JAD tambin debe incluir a uno a dos observadores que sean analistas o expertos tcnicos de otras reas funcionales para ofrecerles para ofrecer explicaciones y consejos tcnicos al grupo durante las sesiones. Adems, un miembro del departamento de sistemas de informacin debe asistir a las sesiones de JAD para redactar formalmente tod o lo que se haga. Conclusin Debido a las necesidades 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 tener bue nos resultados, especialmente para elicitar requerimientos en el campo de los sistemas de informacin .

Tcnica Ventajas Entrevistas y y Mediante ellas se obtiene Cuestionarios una gran cantidad de informacin adecuada a travs del usuario. y Pueden ser usadas para obtener una visin general del problema. y Son flexiblesPermiten combinarse con otras tcnicas. Tormenta de y Ideas
y

Desventajas y La informacin obtenida al principio puede ser redundante o incompleta. y Si el volumen de informacin manejado es alto, requiere mucha organizacin de parte del analista , as como la habilidad para tratar y comprender el comportamiento de todos lo involucrados
y

Casos de Uso y

La produccin de ideas en grupos puede ser mas efectiva que la individual Aflora una gran cantidad de ideas sin ataduras. Representan los requerimientos desde el punto de vista del usuario permiten representar mas de un rol para cada afectado. Identifica nuevos

Es necesaria una buna compenetracin del grupo participante.

En sistemas grandes toma mucho tiempo definir todos los casos de uso. El anlisis de calidad depende de la calidad con que se haya hecho la descripcin inicial.

requerimientos, dentro de un conjunto de requerimientos. JAD

y

y y

Ahorra tiempo, elimina y retrasos del proceso y mejora la calidad del sistema. Es una de las mejores maneras de reducir los errores arrastrados de los resultados de los requerimientos iniciales. Con la participacin de gerentes y usuarios apropiados, el riesgo cultural tpico se mitiga. Evita funcionalidad sobredimensionada. Evita que los requerimientos sean demasiado especficos o demasiados vagos, que son dos problemas comunes en el anlisis.

Es costoso involucrar al patrocinador del proyecto y gerente , experto en la tecnologa, y expertos en la materia, como parte del equipo del proyecto