Estrategia en La Ingenieria de Requisitos - 2013

Notas de Clase: Estrategia en la Ingeniera de Requisitos Orientada al Cliente
Dra. Graciela D.S. Hadad Marzo 2013
Reconocimiento
La Estrategia en Ingeniera de Requisitos Orientada al Cliente, que se presenta en estas Notas de Clase, ha sido desarrollada, refinada y probada por los investigadores: Dr. Julio C.S.P. Leite, Ing. Jorge H. Doorn, Lic. Gladys N. Kaplan y Dra. Graciela D.S. Hadad, a lo largo de varios proyectos, durante ms de una dcada y con la participacin de varios otros colaboradores.
Acrnimos Utilizados
DEOs EA EF IR LEL RF RNF SRS UdeD Discrepancias, Errores y Omisiones Escenarios Actuales Escenarios Futuros Ingeniera de Requisitos Lxico Extendido del Lenguaje Requisitos Funcionales Requisitos No Funcionales Software Requirements Specification Universo de Discurso
Estrategia en la Ingeniera de Requisitos Hadad GDS
-2-
ndice
Pg.
1. 2. 3. 3.1. 3.2. 3.3. 3.4. 4. 4.1. 4.2. 4.3. 5. 6. 6.1. 6.2. 7. 7.1. 7.2. 7.3. 7.4.
Introduccin................................................................................................. 4 Etapas de la Estrategia ............................................................................... 7 Modelos y registros utilizados ................................................................... 13 Modelo del LEL...................................................................................... 13 Modelo de Escenario ............................................................................. 15 Modelo de Especificacin de Requisitos ............................................... 20 Ficha de Informacin Anticipada ........................................................... 22 Comprensin del Vocabulario del UdeD ................................................... 24 Finalidad de Crear el LEL ...................................................................... 25 Proceso de Creacin del LEL ................................................................ 27 Actividades del Proceso ........................................................................ 29 Escenarios Actuales y Escenarios Futuros ............................................... 51 Comprensin del Universo de Discurso Actual ......................................... 55 Proceso de Construccin de Escenarios Actuales ................................ 55 Actividades del Proceso ........................................................................ 57 Definicin del Contexto del Software ........................................................ 90 Objetivos y Requisitos del Sistema........................................................ 90 Proceso de Construccin de Escenarios Futuros.................................. 94 Actividades del Proceso ........................................................................ 96 Enfoques en el Modelado de Escenarios Futuros ............................... 106 Enfoque Orientado a lo Procedural .................................................. 108 Enfoque Dirigido por Objetivos ........................................................ 110 Enfoque Hbrido ............................................................................... 113 Enfoque Basado en el LEL .............................................................. 115 Enfoque Top-Down Tradicional........................................................ 118 Observaciones sobre el Proceso de Escenarios Futuros .................... 119 Creacin del Documento de Requisitos .................................................. 121 Documento de Definicin de Requisitos .............................................. 121 Proceso de Creacin del Documento de Requisitos ........................... 124 Actividades del Proceso ...................................................................... 125
7.4.1. 7.4.2. 7.4.3. 7.4.4. 7.4.5. 7.5. 8. 8.1. 8.2. 8.3.
Referencias .................................................................................................... 142

Estrategia en la Ingeniera de Requisitos Hadad GDS -3-
1. Introduccin
La estrategia en la Ingeniera de Requisitos (IR) orientada al cliente se sustenta en la construccin y uso de dos modelos basados en lenguaje natural: el Lxico Extendido del Lenguaje (LEL), un glosario especial del vocabulario del dominio de la aplicacin, y Escenarios, descripciones de situaciones en el universo de discurso (UdeD). El principal propsito de este lxico es la captura del vocabulario del dominio de la aplicacin, mientras que la comprensin de la funcionalidad y caractersticas del UdeD se obtienen por medio de los escenarios. Cada escenario se describe usando los trminos definidos en el lxico. Los escenarios sirven tanto para describir situaciones que ocurren actualmente en el UdeD: situaciones observadas o reales, como as tambin, situaciones que ocurrirn cuando se incorpore el nuevo artefacto de software en el UdeD: situaciones proyectadas o esperadas. Esta incorporacin traer inevitablemente un cambio en el UdeD. Se destaca que los escenarios son descripciones de situaciones que evolucionan en el UdeD. Los escenarios comienzan describiendo situaciones en el UdeD y luego evolucionan a lo largo del proceso de desarrollo del software, describiendo cmo estas situaciones cambian en el UdeD. Ambos conjuntos de escenarios persisten a lo largo del desarrollo de software, ambos describen situaciones en el UdeD utilizando el vocabulario del UdeD, la nica diferencia aunque sustancial entre ambos conjuntos es el contexto que describen. En resumen, esta estrategia es un enfoque dentro de la IR dirigido por modelos basados en lenguaje natural, que produce un glosario del UdeD y aplica la tcnica de escenarios con el propsito de obtener conocimiento acerca del problema y capturar los requisitos del software. Los modelos que se construyen no slo sirven para registrar informacin y facilitar el anlisis de la misma, sino que poseen la gran ventaja de motivar la elicitacin de informacin. Es decir, el LEL y los escenarios no son meros instrumentos contenedores organizados de informacin sino que son en s mismos promotores de la captacin de informacin, estimulando adems la introspeccin de los ingenieros y
-4-
facilitando la transmisin de informacin por parte de los clientes y usuarios. Ambas representaciones no intentan reemplazar el documento de especificacin de requisitos, el objetivo de ellas es ayudar a la produccin de especificaciones.
Comprender el Vocabulario del UdeD LEL
Comprender el UdeD Actual
Escenarios Actuales
Definir el Contexto del Escenarios Futuros Software Crear el Documento de SRS Requisitos
Figura 1. Una estrategia en la IR Como se esquematiza en la Figura 1, la estrategia presenta un refinamiento del proceso de definicin de requisitos, que bsicamente consiste en cuatro etapas principales: i) ii) Comprender el vocabulario del UdeD, para ello se construye un LEL del UdeD; Comprender el UdeD actual, para ello se construye un conjunto de escenarios representando situaciones actuales (que se denominan Escenarios Actuales); iii) Definir el contexto del sistema de software, para ello se evoluciona el conjunto de escenarios previos en otro conjunto que represente las situaciones futuras que ocurrirn cuando se implante el nuevo sistema de software (conjunto que se denomina Escenarios Futuros); y iv) Explicitar los requisitos del software, derivndolos de los Escenarios Futuros y generando un documento de especificacin. La Figura 1 slo presenta las etapas de la estrategia y por ello no presenta los reciclos que existen entre las etapas por una mejor comprensin del UdeD,
-5-
donde se vuelve a refinar el LEL, los Escenarios Actuales y / o los Escenarios Futuros. En la cuarta etapa no hay un feedback a etapas anteriores, porque es una etapa que trata sobre reorganizar la informacin ya elicitada y modelada en la etapa anterior. Adems, existe un producto intermedio de las tres primeras etapas, denominado Fichas de Informacin Anticipada, donde se vuelca todo lo que se elicita y es importante pero no corresponde al modelo que se est construyendo en dicha etapa sino que es informacin til para alguna etapa posterior.
-6-
2. Etapas de la Estrategia
A continuacin se describe para cada etapa: el objetivo que cumple, los modelos que se generan, una breve descripcin del proceso que se sigue y su importancia en la estrategia.
1 Etapa: Comprensin del Vocabulario del UdeD Objetivo Conocer el vocabulario empleado en el UdeD. Productos Lxico Extendido del Lenguaje Fichas de Informacin Anticipada Breve Descripcin El proceso que se sigue en esta etapa comienza elicitando informacin general del UdeD para generar una lista de trminos relevantes o de uso especfico en dicho UdeD. Estos trminos luego se irn definiendo con la captura de ms informacin. Este proceso no mira especficamente a todo el UdeD ni ahonda en cada detalle de la funcionalidad del problema, por el contrario avanza y retrocede de las ideas generales al conocimiento detallado solamente para comprender el vocabulario usado en el UdeD y para registrarlo en un glosario denominado LEL. En esta actividad debe extremarse el cuidado en no insertar trminos o significados que el ingeniero de requisitos considera que debieran usarse, pero que efectivamente no son usados por los clientes y usuarios. Es comn obtener durante esta etapa ms informacin de la realmente necesaria para construir el LEL. Para evitar la prdida de esta informacin, se la vuelca en una Ficha de Informacin Anticipada. Justificacin de la etapa El LEL es un modelo de gran utilidad a lo largo de todo el proceso de desarrollo del software, pues facilita la comunicacin escrita y oral entre
-7-
los involucrados y reduce la ambigedad en los documentos producidos durante la IR (Escenarios Actuales, Escenarios Futuros y SRS), como as tambin en otros artefactos generados posteriormente que incluyan alguna descripcin textual y que deban ser comprendidos por los clientes y usuarios.
2 Etapa: Comprensin del UdeD actual Objetivo Conocer el UdeD tal cual es en la actualidad. Productos Escenarios Actuales Fichas de Informacin Anticipada Breve Descripcin El proceso en esta etapa comienza con la construccin de escenarios siguiendo las heursticas que extraen informacin del LEL y se obtienen escenarios cuyo nivel de detalle es mayor que el encontrado en el LEL. La informacin adicional se obtiene principalmente del UdeD. Durante este paso algunas partes comunes de diferentes escenarios se factorizan para crear sub-escenarios. Los sub-escenarios tambin son generados cuando uno o ms episodios de un escenario merecen un tratamiento independiente. Otros escenarios se descomponen en uno o ms escenarios para facilitar su comprensin. Estos ltimos pasos muestran un comportamiento descendente, as esta parte del proceso puede verse como top-down. En este punto, surge como una fuerte necesidad de los ingenieros el tener una visin global de los escenarios y un nuevo paso, ahora bottom-up, es requerido: se construyen los escenarios integradores que mencionan en sus episodios situaciones concretas descriptas por los escenarios obtenidos previamente. Todos los escenarios son descriptos utilizando el vocabulario del UdeD, esto implica entonces no slo obtener una mayor comprensin del UdeD sino tambin de su vocabulario, lo que provoca inevitablemente la evolucin del LEL. Esto no es porque cambia la forma de expresarse en
-8-
el UdeD sino que existe una mejor captacin por parte de los ingenieros de requisitos. En esta etapa se debe evaluar si alguna Ficha de Informacin Anticipada contiene informacin sobre las actividades actuales que no se incorpor en el LEL y que corresponde incluir en los escenarios actuales. Al igual que en la etapa previa, pero en mayor medida, la captura de informacin que excede la realidad actual es un hecho frecuente, y para evitar la prdida de dicha informacin anticipada o distraer al ingeniero en el anlisis de la misma, se vuelca dicha informacin en Fichas de Informacin Anticipada. Justificacin Algunas propuestas simplifican o descartan la necesidad de modelar el contexto actual y/o de conocer el vocabulario utilizado en l. Sin embargo, la construccin de los escenarios actuales es una tarea bsica para permitir una adecuada pre-trazabilidad de los requisitos, la cual hoy en da es considerada una medida de calidad de los sistemas y exigida por muchos estndares de desarrollo de software. Por otro lado, muchas veces los desarrolladores se desempean bajo la creencia de que conocen o comprenden ese contexto y/o ese vocabulario, pero en la mayora de los casos tienen un conocimiento parcial y, lo que es peor an, distorsionado de la realidad y de su lenguaje. Esto es especialmente cierto en proyectos de gran envergadura y/o con un grado importante de complejidad. Si el ingeniero de requisitos no conoce nada o muy poco del UdeD entonces procurar informarse en forma apropiada, pero si tiene algn conocimiento entonces tiene una tendencia natural de asociar la informacin que recibe con sus conocimientos previos, cometiendo en muchos casos errores de interpretacin o llenando huecos con hiptesis y detalles de su propio conocimiento previo que pueden conducirlo a errores. Desafortunadamente estas circunstancias son las ms frecuentes. Adicionalmente, esta etapa permite identificar problemas y oportunidades de mejoras en los procesos del negocio actual. Por lo tanto, es una etapa
-9-
esencial cuando se supone que los procesos del negocio son ineficientes, por ejemplo, cuando se est admitiendo una reingeniera de los procesos.
3 Etapa: Definicin del Contexto del Software Objetivo Definir los cambios necesarios en los procesos del negocio para hospedar y beneficiarse con el software a construir. Productos Escenarios Futuros Fichas de Informacin Anticipada Breve Descripcin Se comienza seleccionando la estrategia de construccin de escenarios propiamente dicha, que depende de los objetivos del sistema y del grado de mejoras esperado en los procesos del negocio. En el caso de un bajo nivel de cambio en los procesos del negocio, se sigue una estrategia donde se establecen mejoras a cada escenario actual convirtindolo en un escenario futuro, es decir se estudia la jerarqua de escenarios actuales siguiendo una modalidad post-order (en profundidad). En el caso de grandes cambios en los procesos del negocio, por el contrario, los escenarios actuales de mayor nivel en la jerarqua sufrirn una alta re-estructuracin y as hacia abajo en dicha jerarqua en funcin de los objetivos del sistema, es decir se sigue una estrategia pre-order (en amplitud). Para niveles medios de cambio, la estrategia a seguir es una combinacin de las anteriores. Durante esta etapa se tiene en consideracin la informacin registrada en las Fichas de Informacin Anticipada, adems de ser necesaria la elicitacin de ms informacin en el UdeD. A travs de la construccin de los escenarios futuros se presentan propuestas alternativas de solucin que son negociadas con los clientes y usuarios. Cabe mencionar que es una etapa donde se intensifica la elicitacin de RNF, algunos de los cuales por sus caractersticas generales (de
- 10 -
aplicacin a todo el sistema o a una buena parte del mismo) no pueden vincularse a un escenario futuro especfico, dado lo cual se los registra en las Fichas de Informacin Anticipada para su inclusin posterior en el SRS. Justificacin Los escenarios futuros albergan los requisitos del software en una forma altamente legible y comprensible por los clientes y usuarios, lo que facilita su negociacin y asignacin de prioridades. Dada su rica expresividad, son un medio que facilita la elicitacin de requisitos, la negociacin de los mismos y su validacin. Estimulan la imaginacin, facilitando la generacin de propuestas por parte de todos los involucrados. Permiten presentar sin grandes costos (por su facilidad de construccin) distintas alternativas de solucin a los problemas y necesidades manifestadas en el UdeD. A travs de los escenarios futuros los clientes y usuarios pueden priorizar los requisitos, evaluando la criticidad de las situaciones futuras y otorgndoles a stas prioridades. Los escenarios futuros sirven de ancla para la pre y post rastreabilidad, permitiendo el rastreo de los requisitos hacia sus orgenes (vinculando los escenarios futuros con los escenarios actuales y con el LEL) y hacia el diseo y el cdigo. Son un medio que facilita la gestin de los cambios en los requisitos a lo largo del ciclo de vida del software.
4 Etapa: Creacin del Documento de Requisitos Objetivo Establecer los requisitos del software en el contexto bajo estudio. Productos Documento de Definicin de Requisitos (SRS) Breve Descripcin Una vez acordado el conjunto de escenarios futuros que incluirn las funcionalidades y caractersticas del sistema de software, se extraen de dicho conjunto los requisitos funcionales y no funcionales del software.
- 11 -
Se redacta el Documento de Definicin de Requisitos, que puede ir desde una simple lista de requisitos hasta un documento ms formal basado en algn estndar que la organizacin utilice o se proponga de acuerdo al proyecto en particular. Justificacin La produccin del documento SRS es fcilmente derivable de los escenarios futuros y adems, dado que stos son previamente verificados y validados y anclados en el LEL, se asegura la obtencin de un SRS consistente, no ambiguo, completo, correcto, entendible, rastreable, verificable y abstracto. La rastreabilidad de los requisitos puede tambin manejarse a travs de este documento, que facilita la individualizacin de los requisitos.
Esta estrategia en la Ingeniera de Requisitos basada en modelos en lenguaje natural enfatiza la adquisicin de conocimiento sobre el contexto organizacional donde operar el sistema de software. La estrategia, aunque expuesta siguiendo un modelo en cascada, es adaptable a diversos procesos de software y es utilizable en una amplia variedad de problemas. La estrategia se basa en la elicitacin dirigida por modelos, es decir, en cada etapa se construye un modelo donde la captura de informacin est totalmente volcada a completar dicho modelo. Dado lo cual, la estrategia se apoya en un registro auxiliar para aquella informacin obtenida espontneamente y que no es transferible al modelo en curso de construccin. Ese registro auxiliar, denominado Ficha de Informacin Anticipada, evita la prdida de informacin capturada en forma adelantada al modelo receptor de la misma. Adicionalmente, es una estrategia orientada al cliente pues, por un lado, los modelos que se utilizan contienen descripciones en lenguaje natural correspondientes al vocabulario del UdeD y, por otro lado, el proceso requiere de la participacin de todos los involucrados durante todas sus etapas, tanto para la elicitacin de informacin, la validacin de la misma a travs de los modelos y la negociacin de la solucin del problema.
- 12 -
3. Modelos y registros utilizados

La estrategia utiliza modelos escritos en lenguaje natural para facilitar la comunicacin y validacin con los usuarios y clientes, adems ellos son herramientas fructferas de elicitacin. A continuacin se describen el modelo del LEL, el modelo de Escenario (que se utiliza tanto para producir Escenarios Actuales y Escenarios Futuros), el modelo de Especificacin de Requisito (que luego se vuelca en el Documento de Requisitos) y la plantilla de un registro auxiliar de informacin adelantada.
3.1.
Modelo del LEL
El Lxico Extendido del Lenguaje [Leite 93] es un modelo (ver Figura 2) diseado para ayudar en la elicitacin y representacin del lenguaje usado en el dominio de la aplicacin. El proceso de creacin se ancla en la idea de entender slo el lenguaje del dominio de la aplicacin, como un primer paso para mejorar la comprensin sobre el UdeD. Para apreciar esta idea cabalmente se debe notar que no se est desestimando la comprensin del problema, sino que se est solamente definiendo la precedencia del lenguaje sobre el problema mismo durante la creacin del LEL. El LEL es en s mismo un glosario con roles y estructura diferentes al usual, y contiene hipervnculos entre sus entradas. Est compuesto por un conjunto de smbolos que son, en general, palabras o frases peculiares y las ms usadas en el dominio de la aplicacin. Una sigla tambin puede ser el nombre de un trmino cuando se usa en el dominio de la aplicacin. Cada smbolo se identifica por un nombre o nombres (en caso de sinnimos) y tiene dos tipos de descripciones; este formato particular representa la diferencia con otros glosarios. El primer tipo, llamado Nocin, es el usual pues describe la denotacin de la palabra o frase, es decir, define lo que el smbolo es. El segundo, denominado Impacto, describe la connotacin de la palabra o frase, es decir, describe cmo el smbolo acta en el dominio de la aplicacin; esta descripcin no est presente normalmente y enriquece el conocimiento sobre el
- 13 -
smbolo y el contexto.
LEL: representacin de los smbolos en el lenguaje del dominio de la aplicacin. Sintaxis: <LEL> {<Smbolo>}1N Smbolo: entrada del lxico que tiene un significado especial en el dominio de la aplicacin. Sintaxis: <Smbolo> {<Nombre>}1N + <Nocin> + <Impacto> Nombre: identificacin del smbolo. Ms de uno indica la presencia de sinnimos. Sintaxis: <Nombre> <Palabra> | <Frase> | <Acrnimo> Nocin: denotacin del smbolo. Debe ser expresada usando referencias a otros smbolos y usando el vocabulario mnimo. Sintaxis: <Nocin> Nocin: + {<Oracin>}1N Impacto: connotacin del smbolo. Debe ser expresado usando referencias a otros smbolos y usando el vocabulario mnimo. Sintaxis: <Impacto> Impacto: + {<Oracin>}1N donde <Oracin> est compuesta solamente por Smbolos y No Smbolos, stos ltimos pertenecientes al vocabulario mnimo; <Palabra>, <Frase> o <Acrnimo> tienen el significado comn.
+ significa composicin, {x} significa cero o ms ocurrencias de x, | representa or
Figura 2. Modelo del Lxico Extendido del Lenguaje En la Figura 3 se presentan dos ejemplos de smbolos (extrados del caso Juzgado Laboral), donde los trminos subrayados representan vnculos a otras entradas del LEL. JUEZ
Nocin: Persona que tiene a cargo el juzgado. Impacto: Firma los expedientes. Dicta sentencias. Toma decisiones ante las distintas instancias del expediente. Resuelve las demandas. Firma los provedos.
INICIAR DEMANDA
Nocin: Es el acto por el cual el actor presenta una demanda ante el juzgado. Debe contar con el aval de un letrado. Impacto: Se genera un expediente. Se enva el expediente al juzgado asignado. Se aporta la documentacin necesaria para conformar el expediente.
Figura 3. Modelo del Lxico Extendido del Lenguaje
- 14 -
Dos principios [Leite 90] rigen la descripcin de los smbolos. El principio de circularidad declara la maximizacin del uso de smbolos en la descripcin de otros smbolos y el principio del vocabulario mnimo establece la minimizacin del uso de trminos que son externos al lxico. Estos trminos externos deben pertenecer a un pequeo subconjunto de un diccionario predefinido del lenguaje natural que no contiene ningn smbolo del LEL.
3.2.
Modelo de Escenario
El modelo de escenario [Leite 00] es una estructura compuesta por las siguientes entidades: ttulo, objetivo, contexto, recursos, actores, episodios y excepciones, y el atributo restriccin. Actores y recursos son dos componentes enumerativos. El ttulo, el objetivo, el contexto y las excepciones son componentes declarativos, mientras que los episodios son un conjunto de sentencias en un lenguaje simple que dan una descripcin operacional de comportamiento. La Figura 4 muestra el modelo de escenario donde se detalla la sintaxis de cada componente. El modelo de escenario debe interpretarse como pautas sintcticas y estructurales con el fin de: obtener un estilo de descripcin homogneo entre el conjunto de escenarios; mostrar los varios aspectos que los escenarios pueden cubrir; y facilitar la verificacin del escenario (principalmente mediante un proceso automatizado). Un escenario debe satisfacer un objetivo que se alcanza realizando sus episodios. Los episodios representan el curso principal de accin pero tambin incluyen variaciones o posibles alternativas. Mientras se realizan los episodios puede ocurrir una excepcin, indicando un obstculo en el logro del objetivo del escenario. El objetivo del escenario se describe desde el punto de vista del negocio, y no de algn inters en particular. Esto mismo se aplica al nombre del escenario, dado por el componente ttulo. Por ejemplo, en la Figura 10 el ttulo del
Estrategia en la Ingeniera de Requisitos Hadad GDS - 15 -
escenario, donde se muestra la situacin de un solicitante que paga un trmite, podra ser Pagar el trmite, pero es preferible mostrar el punto de vista del sistema bajo estudio Cobrar el trmite.
Escenario: descripcin de una situacin que ocurre en el contexto del problema. Sintaxis: Ttulo + Objetivo + Contexto + {Recursos}1N + {Actores}1N + {Episodios}2N + {Excepciones} Ttulo: identificacin del Escenario. En el caso de un sub-Escenario, el ttulo es el mismo que la sentencia episodio, sin las restricciones. Sintaxis: Frase | ([Actor | Recurso] + Verbo + Predicado) Objetivo: finalidad a ser alcanzada. El Escenario describe la forma de lograr el objetivo. Sintaxis: [Actor | Recurso] + Verbo + Predicado Contexto: compuesto por al menos uno de los siguientes tems: Ubicacin Geogrfica: lugar fsico donde se produce el Escenario. Ubicacin Temporal: especificacin de tiempo para el desarrollo del Escenario. Precondicin: estado inicial del Escenario. Sintaxis: {Ubicacin Geogrfica} + {Ubicacin Temporal} + {Precondicin} donde Ubicacin Geogrfica es: Frase | Nombre donde Ubicacin Temporal es: Frase | Nombre donde Precondicin es: [Sujeto | Actor | Recurso] + Verbo + Predicado Recursos: elementos fsicos o informacin relevantes que deben estar disponibles en el Escenario. Sintaxis: Nombre Actores: personas, dispositivos o estructuras organizacionales que tienen un rol en el Escenario. Sintaxis: Nombre Episodios: conjunto de acciones que detallan al Escenario y proveen su comportamiento. Un episodio tambin puede ser descripto como un Escenario. Sintaxis (usando BNF parcial): <episodios> ::= <serie grupo> | <serie episodios> <serie grupo> ::= <grupo> <grupo> | < grupo no secuencial> | <serie grupo> <grupo> <grupo> ::= <grupo secuencial> | < grupo no secuencial> <grupo secuencial> ::= <sentencia bsica> | <grupo secuencial > <sentencia bsica> <grupo no secuencial> ::= # <serie episodios> # <serie episodios> ::= <sentencia bsica> <sentencia bsica> | <serie episodios> <sentencia bsica> <sentencia bsica> ::= <sentencia simple> | <sentencia condicional> | <sentencia optativa> <sentencia simple> ::= <sentencia episodio> CR <sentencia condicional> ::= Si <condicin> entonces <sentencia episodio> CR <sentencia optativa>::= [ <sentencia episodio> ] CR donde <sentencia episodio> se describe: (([Actor] + Verbo + Predicado) | ([Actor] + [Verbo] +Ttulo)) + {Restriccin} donde Restriccin: es un requisito de calidad o alcance referido a una dada entidad, y se describe: ([Sujeto | Actor | Recurso] + [No] Debe + Verbo + Predicado) | Frase Excepciones: generalmente reflejan la falta o mal funcionamiento de un recurso. Una excepcin impide el cumplimiento del objetivo del Escenario. Se puede indicar el tratamiento de la excepcin a travs de un Escenario o de una accin simple. Sintaxis: Causa (Solucin) donde Causa es: (Frase | ([Sujeto | Actor | Recurso] + Verbo + Predicado)) + {Nro. Episodio} donde Solucin es: Ttulo | ([Sujeto | Actor | Recurso] + Verbo + Predicado)
+ significa composicin, {x} significa cero o ms ocurrencias de x, () para agrupar, | para or, [x] significa que x es opcional.
Figura 4. Modelo de Escenario
- 16 -
El contexto se describe detallando la ubicacin geogrfica, la ubicacin temporal y las precondiciones. Los dos ltimos sub-componentes pueden expresarse a travs de una o ms oraciones simples vinculadas por los conectores: y, o. Como la ubicacin geogrfica debe representar un nico lugar para que el escenario represente una situacin, entonces este subcomponente slo puede expresarse combinando lugares con el conector o. En el caso de ubicaciones o precondiciones alternativas, puede indicarse la condicin por la que se da una circunstancia u otra. Al menos uno de estos tres sub-componentes debe estar presente en el contexto. Los episodios pueden ser de tres tipos: simples, condicionales u opcionales. Los episodios simples son aquellos necesarios para concluir el desenvolvimiento del escenario. Los episodios condicionales son aquellos cuya ocurrencia dependen de una condicin especfica. La condicin puede ser interna o externa al escenario. Las condiciones internas pueden deberse a ubicaciones o precondiciones alternativas (es decir, que contienen el conector o) y a episodios previos. Los episodios opcionales (encerrados entre corchetes) son aquellos que pueden o no ocurrir dependiendo de condiciones que no pueden ser explicitadas. Para una mayor claridad, se recomienda numerar cada episodio en el orden en que se detalla en el componente. Independientemente del tipo, un episodio puede ser expresado como una accin simple o puede ser concebido en s mismo como un escenario, posibilitando entonces la descomposicin del escenario en sub-escenarios. Aunque dentro de un escenario se tratan cursos principales y alternativos de accin, su comprensin se facilita por el uso del lenguaje natural, el manejo de situaciones bien delimitadas y el uso de sub-escenarios. Un sub-escenario se usa cuando: se detecta un comportamiento comn en varios escenarios; aparece un curso de accin condicional o alternativo que es complejo en un escenario; o se detecta la necesidad de resaltar una situacin con un objetivo concreto y preciso dentro de un escenario.
- 17 -
El modelo de escenario provee la descripcin de comportamientos con diferentes rdenes temporales. Una secuencia de episodios implica en s mismo un orden de precedencia. Para indicar un orden no secuencial se debe agrupar dos o ms episodios utilizando el carcter numeral al comienzo y fin del grupo. Esta sintaxis se utiliza para expresar paralelismo u orden secuencial indistinto.
Ttulo: ANALIZAR UN INSUMO Objetivo: determinar si un insumo puede ser utilizado en el proceso de produccin. Contexto: Ubicacin Geogrfica: laboratorio Ubicacin Temporal: --Precondicin: El insumo debe tener la fecha de anlisis. Recursos: tcnica, muestra, cuaderno del analista, cuaderno del analista de microbiologa, vencimientos, cronograma de trabajo Actores: tcnico, Jefe de Control de Calidad Episodios: 1. [TOMAR UNA MUESTRA.] 2. APLICAR UNA TECNICA. 3. LLENAR EL CUADERNO DEL ANALISTA. 4. PREGENERAR EL PROTOCOLO. 5. #El tcnico entrega el cuaderno del analista al Jefe de Control de Calidad. 6. El tcnico entrega el cuaderno del analista de microbiologa al Jefe de Control de Calidad. 7. Si el anlisis tiene vencimiento entonces el tcnico registra en el cronograma de trabajo los vencimientos. # Excepciones: Ttulo: ASIGNAR FECHA DE ANLISIS Objetivo: asignar el momento en el que se realizar un anlisis Contexto: Ubicacin Geogrfica: Oficina tcnica Ubicacin Temporal: todos los lunes. Precondicin: debe haber un insumo para analizar Recursos: cronograma de trabajo, insumo, fecha probable de anlisis Actores: jefe de control de calidad, sistema Episodios: 1. El jefe de control de calidad ingresa al sistema la fecha probable de anlisis del insumo. 2. El sistema busca los anlisis a partir de la fecha ingresada. 3. El sistema muestra el cronograma de trabajo de la fecha ingresada. 4. El jefe de control de calidad determina una fecha de anlisis de acuerdo a la prioridad de anlisis y a la disponibilidad de cada tcnico. 5. Si la fecha determinada no tiene disponibilidad entonces REASIGNAR FECHA DE ANLISIS. 6. El jefe de control de calidad indica al sistema la fecha en el cronograma de trabajo. 7. El sistema actualiza el cronograma de trabajo. Excepciones:
Figura 5. Ejemplos de escenarios En la Figura 5 se muestran dos escenarios extrados del caso Planificacin y Seguimiento en un Laboratorio Farmacutico, donde en el escenario de la izquierda, se presentan un episodio opcional, un episodio condicional y un conjunto de episodios de orden no secuencial. El atributo restriccin se puede aplicar individualmente a los episodios, y se utiliza para caracterizar limitaciones o condiciones de calidad respecto a la realizacin del episodio, habitualmente estas restricciones se asocian a RNF. Un escenario puede ser interrumpido por excepciones. Cada excepcin se
- 18 -
describe con una sentencia simple que especifica la causa de la interrupcin, seguido de la lista de nmeros de episodios donde la excepcin puede ocurrir. Si no se especifica una lista, implica que la excepcin puede ocurrir en cualquier momento durante el desenvolvimiento de los episodios del escenario. La excepcin adems debe tener un tratamiento, que puede o no cumplir con el objetivo original del escenario. Cuando la excepcin tiene un tratamiento especial, ste se describe en otro escenario y en el componente Excepciones se incluye entre parntesis slo el ttulo de dicho escenario (ver el ejemplo en la Figura 6). Cuando la excepcin tiene un tratamiento simple, se puede describir en una oracin siguiendo el estilo de un episodio simple.
Ttulo: INSCRIBIRSE EN UN TUTORIAL Objetivo: Un participante se matricula para reservar un lugar para el tutorial. Contexto: Ubicacin Geogrfica: mostrador de registracin Ubicacin Temporal: Precondicin: El participante debe ser un profesional IT o estudiante de un curso IT. El participante debe estar registrado en la conferencia. Recursos: lista de tutorials, ID, mtodo de pago, talonario de recibos, talonario de inscripcin, formulario de inscripcin Actores: participante, agente de la conferencia Episodios: 1. El participante se presenta frente al mostrador de registracin de la conferencia. Restriccin: el agente de la conferencia debe estar en el mostrador. 2. El participante elige un tutorial de la lista de tutorials. 3. El participante completa el formulario de inscripcin con su ID y dems datos requeridos. 4. El participante paga la tarifa del tutorial. Restriccin: el mtodo de pago debe ser efectivo, tarjeta de crdito o cheque. 5. El agente de la conferencia gestiona la confirmacin. Restriccin: no debe tomar ms de 3 minutos. 6. El agente de la conferencia emite el recibo de pago y el comprobante de inscripcin. Excepciones: no hay suficientes vacantes (INSCRIBIRSE EN LISTA DE ESPERA)
Figura 6. Ejemplo de escenario con excepciones Como se ha mencionado ms arriba, existe una relacin jerrquica entre los escenarios, establecida mediante episodios que son en s mismos escenarios. Los sub-escenarios surgen cuando al descubrir una situacin inmersa dentro de otra se prefiere detallar a la primera en un escenario separado, probablemente con mayor nivel de detalle que en el escenario que la contiene. As mismo esta relacin se utiliza para construir escenarios integradores, los cuales agrupan escenarios temporalmente relacionados, permitiendo lograr una
- 19 -
visin global del UdeD. La Figura 10 muestra ejemplos de escenarios actuales y futuros, donde el escenario Trmite de Pasaporte Original hace referencia a otros escenarios en sus episodios, siendo uno de ellos el otro escenario de la misma Figura Cobrar el Trmite. El primer escenario es un ejemplo de escenario integrador, y el segundo es un ejemplo de sub-escenario. En el escenario de la derecha de la Figura 5 se muestra un episodio que menciona un sub-escenario Reasignar Fecha de Anlisis. Durante el proceso de construccin de los escenarios, se suele mantener en cada escenario un componente transitorio Dudas de texto libre, que se elimina antes de finalizar el proceso, pues debe quedar vaco previamente. Este modelo de Escenario permite representar tanto situaciones actuales que ocurren en el UdeD como situaciones esperadas con el nuevo sistema de software, haciendo hincapi en el contexto organizacional en el que se desarrollan los procesos del negocio. En resumen, permite representar todas las variantes posibles de una situacin, incluyendo casos alternativos y excepciones, permitiendo vincular restricciones a las actividades (episodios) que se desarrollan. Se encuadra cada situacin en un contexto temporal, geogrfico y de estado inicial, indicando los recursos necesarios y los actores involucrados.
3.3.
Modelo de Especificacin de Requisitos
El modelo de Especificacin de Requisito [Hadad 09] (ver Figura 7) es simple con descripciones en lenguaje natural. Incluye la descripcin del requisito; el tipo de requisito segn la clasificacin adoptada, que sirve para dar contexto al requisito; y el fundamento, que es de vital importancia cuando se solicita un cambio en el requisito. Opcionalmente, pueden considerarse en este modelo los atributos: volatilidad, prioridad, criticidad, factibilidad, riesgo y costo de implementacin. La Figura 8 muestra dos ejemplos de Especificaciones de Requisitos, una de un RF y la otra de un RNF de eficiencia.
- 20 -
Requisito: <texto estructurado> descripcin del requisito, ajustado a un patrn sintctico dependiente de su tipo. Tipo: <valor> una categora para agrupar y organizar requisito. Puede indicar si se trata de un RF o un RNF, o el tipo de RNF al que corresponde, o el tipo segn alguna otra clasificacin utilizada. Fundamento: <texto libre> propsito, necesidad o razn de la existencia del requisito. Volatilidad: <valor> grado de estabilidad del requisito segn su probabilidad de evolucin. Prioridad: <valor> importancia relativa que tiene el requisito para los clientes y usuarios. Criticidad: <valor> necesidad relativa de implementacin, puede indicarse si es obligatorio, deseable u opcional, o mediante un ranking de necesidad. Factibilidad: <valor> posibilidad de implementacin en el proceso del negocio, ya sea por razones sociales, tecnolgicas, ambientales, econmicas, etc. Riesgo: <valor> calificacin en funcin de las consecuencias en el proceso del negocio por su implementacin. Costo de implementacin: <valor> esfuerzo para implementar el requisito en el sistema de software. donde <valor> debe pertenecer a un rango o conjunto discreto y predeterminado.
Figura 7. Modelo de Especificacin de Requisito En este modelo se consideran exclusivamente atributos propios del requisito, independiente del sistema de versionado y de los mtodos de rastreabilidad utilizados, y sin incluir las dependencias con otros requisitos. Es por ello que no incluye atributos como autor, fechas de creacin y modificacin, estado, origen (fuente de informacin), versin, vinculacin con modelos (modelos de requisitos, modelos de diseo, modelos de implementacin, etc.), entre otros. Los RNF se caracterizan por contener en su descripcin informacin de muy diferente naturaleza entre ellos. Por ejemplo, un requisito de eficiencia incluye generalmente valores de tiempo mientras que un requisito de seguridad puede involucrar una caracterstica de encriptado. En general, los RNF necesitan un mecanismo preciso para verificar su cumplimiento. Para facilitar la descripcin en lenguaje natural de estos mecanismos, se incluyen patrones sintcticos basados en el tipo de RNF. Estos patrones sintcticos tambin pueden aplicarse a RF considerando los diferentes tipos de servicios que el sistema debe proveer o adaptndolos a dominios especficos.
- 21 -
Figura 8. Ejemplos de Especificaciones de Requisitos
3.4.
Ficha de Informacin Anticipada
Se debe tener presente que con gran frecuencia cierta informacin del futuro se filtra ya en las etapas de comprensin del vocabulario del UdeD y de comprensin del UdeD mismo. Para que dicha informacin no se pierda en el cmulo de informacin elicitada y no modelada, se propone el uso de una ficha (ver Figura 9) donde se registran individualmente requerimientos o requisitos candidatos, es decir necesidades y deseos del futuro, o simplemente la descripcin de un problema planteado por los usuarios sin una solucin establecida, o alguna propuesta de solucin presentada al vuelo por los usuarios o por los propios ingenieros.
- 22 -
Figura 9. Ficha de Informacin Anticipada El objetivo de las dos primeras etapas no es obtener informacin del futuro, pero es muy frecuente, principalmente cuando la fuente de informacin son los clientes y usuarios, que stos quieran expresar sus demandas hacia el futuro impulsados bsicamente en sus necesidades y deseos actuales insatisfechos. Dado que la recoleccin de esta informacin extra es un efecto colateral de las actividades de comprensin del vocabulario y del UdeD mismo, dicha informacin ser incompleta, parcializada, no verificada ni validada, respondiendo posiblemente al punto de vista o intereses del cliente o usuario, y debe ser considerada como tal, es decir como un posible requisito a contemplar en el UdeD futuro. Estas Fichas de Informacin Anticipada sern analizadas posteriormente durante la actividad de construccin de los escenarios futuros. Adicionalmente, estas fichas permiten guardar informacin actual, pues durante la creacin del LEL es factible la elicitacin de informacin actual que no corresponde incorporar al lxico por su nivel de detalle, pero que debe incluirse posteriormente en los escenarios actuales.
- 23 -
4. Comprensin del Vocabulario del UdeD

La comunicacin es una actividad compleja pero fundamental en cualquier relacin humana: permite que dos o ms personas con sus propios intereses puedan entenderse. Durante todo el proceso de desarrollo de software, la comunicacin es un elemento indispensable donde cada involucrado debe hacer uso de ella a diario [Gause 89]. Cuando los ingenieros de software se comunican con los clientes y usuarios, los primeros usan un vocabulario orientado a la computacin, mientras que los clientes y usuarios usan la terminologa proporcionada por su ambiente [Loucopoulos 95]. Una comunicacin basada en lxicos diferentes tiene una alta probabilidad de fracaso. Aunque usando el mismo idioma cada parte tiene su propio lxico; esto significa que el problema de comunicacin es intrnseco al contexto social y cultural del idioma [Malinowski Rubio 01]. Un ejemplo tpico es cuando se emplea el mismo trmino pero con significados diferentes. Si los ingenieros de software no perciben la ambigedad y no estn conscientes que algunos trminos de los clientes y usuarios pueden tener un significado diferente en su contexto particular de trabajo, entonces los ingenieros dejarn que se introduzcan errores ocultos en su comprensin del UdeD. Si los involucrados en un proyecto comparten el mismo lenguaje entonces la comunicacin entre ellos mejora, y una alternativa productiva se presenta cuando los ingenieros de software usan tanta jerga de los clientes y usuarios como sea posible. Como resultado aumenta el compromiso de los clientes y usuarios con el proyecto. Adems, en el proceso de IR, la validacin de los diferentes productos requiere una interaccin fuerte con los clientes y usuarios; esta actividad se facilita usando un vocabulario comn a todos los involucrados y que corresponda al dominio de la aplicacin. Este vocabulario del dominio de la aplicacin no slo debe usarse durante las interacciones entre los involucrados sino tambin en los modelos y documentacin del software que los desarrolladores produzcan.
- 24 -
4.1.
Finalidad de Crear el LEL
La creacin del LEL como el primer paso en la definicin de requisitos apunta a entender el vocabulario del dominio de la aplicacin. Por lo tanto, la manera de comunicarse con los clientes y usuarios, y de entender el problema tiene un obstculo menos: el vocabulario. El propsito de crear este lxico no slo es permitir una buena comunicacin y acuerdo entre los involucrados, sino tambin ser el puntapi inicial en el proceso de construccin de escenarios, ayudar en la descripcin de los mismos, y mejorar el proceso de validacin de los escenarios. Tanto los escenarios como las especificaciones de requisitos y el documento SRS se describen usando los smbolos del LEL. Esta caracterstica establece un vnculo natural entre estas tres estructuras de representacin. Hay tambin vnculos naturales dentro del lxico dado que en la descripcin de un trmino se hace uso de otros trminos (principio de circularidad). La Figura 10 (informacin extrada del caso Sistema Nacional para la obtencin de Pasaportes) muestra un ejemplo que ilustra ambos tipos de vnculos, con flechas llenas vnculos dentro del LEL y con flechas guionadas vnculos entre el LEL y los otros modelos. Adicionalmente, se presentan en la Figura dos tipos de vnculo entre escenarios con flechas punteadas, uno que se establece debido a la relacin jerrquica basada en el concepto de escenario-subescenario, y el otro como consecuencia de la relacin de excepcin entre un escenario y otro escenario que trata la excepcin. Como el vocabulario es un ancla, se puede hacer rastreo a travs de las palabras y frases que llevan a diferentes designaciones. Adems, el lxico permite el entrenamiento de miembros del equipo de desarrolladores que son incorporados en fases posteriores durante el desarrollo del software.
- 25 -
Smbolo del LEL
Smbolo del LEL
PASAPORTE
Nocin: documento emitido por la Polica Federal se requiere para salir del pas. tiene impreso un nmero de control. tiene un perodo de vigencia, a partir de la fecha de emisin o de la revlida de pasaporte. Impacto: lo controla un funcionario de la Divisin Documentos y Certificados. se le imprime el pulgar derecho del solicitante, su fotografa y su firma en la Cabina de Recepcin ...
SOLICITANTE / INTERESADO
Nocin: persona que inicia un trmite relativo al pasaporte. debe ser ciudadano argentino, hijo de funcionario argentino nacido en el exterior, extranjero casado con ciudadano argentino, habitante argentino carente de nacionalidad o ... Impacto: completa un formulario de solicitud. presenta la documentacin. paga el trmite. ...
Escenario Actual Ttulo: TRAMITE DE PASAPORTE ORIGINAL Objetivo: Dar un pasaporte al interesado por primera vez. Contexto: Ubicacin Temporal: -Ubicacin Geogrfica: -Precondicin: El solicitante nunca obtuvo un pasaporte. Recursos: formulario de solicitud, pasaporte vaco, formulario de donacin de rganos, ... Actores: Solicitante, Divisin Documentos y Certificados, Divisin ndice General,, ... Episodios: 1. LLENADO DE FORMULARIOS VACIOS 2. CONTROL DE DOCUMENTACION 3. SACAR FOTOGRAFIA 4. COBRAR EL TRAMITE 5. ... Excepciones: Escenario Actual Especificacin de Requisito Ttulo: COBRAR EL TRAMITE Objetivo: Cobrar el trmite al solicitante. Contexto: Ubicacin Temporal: -Ubicacin Geogrfica: Sector Caja Precondicin: El solicitante debi completar el formulario y pasar por el control de documentacin. Recursos: formulario, mquina timbradora Actores: Solicitante, Cajero Episodios: 1. El solicitante presenta el formulario al cajero. 2. El cajero informa el importe del trmite segn el tipo de trmite que figura en el formulario. 3. ... Excepciones: Mquina timbradora falla (GENERAR VALE DE COBRO MANUAL).
Escenario Futuro Ttulo: COBRAR EL TRAMITE Objetivo: Cobrar el trmite al solicitante. Contexto: Ubicacin Geogrfica: sector Caja Ubicacin Temporal: lunes a viernes de 8 a 18 hs Precondicin: El solicitante debi completar el formulario y pasar por el control de documentacin. Recursos: formulario. Actores: Solicitante, Cajero, Sistema de Software Episodios: 1. El solicitante se presenta con el formulario en la Caja. 2. El cajero ingresa el nmero del formulario al Sistema de Software. 3. El Sistema de Software informa el importe del trmite. Restriccin: El clculo no debe exceder los 10 seg. 4. ... Excepciones: El Sistema de Software no reconoce el nmero de formulario. Episodio 2. (CARGAR FORMULARIO PROVISORIO)
Requisito: El sistema debe verificar la existencia del nmero de control del pasaporte. Tipo: RF
Escenario Futuro
Ttulo: CARGAR FORMULARIO PROVISORIO Objetivo: Ingresar el formulario desde Caja. solicitante. Contexto: Ubicacin Geogrfica: Sector Caja Precondicin: El sistema no reconoce el nmero de formulario. Recursos: formulario Actores: Solicitante, Cajero, Sistema de Software Episodios: 1. El cajero carga los datos del formulario en el Sistema de Software. 2. ... Excepciones:
Figura 10. Ejemplo de la vista hipertexto entre el LEL, Escenarios y SRS
- 26 -
En resumen, los problemas que atiende el LEL son bsicamente problemas de comunicacin y problemas de comprensin, siendo entonces sus objetivos y sub-objetivos: Comprender el lenguaje del dominio de la aplicacin: asegurar una buena comunicacin entre los involucrados; facilitar la validacin con los clientes y usuarios de cualquier documento de requisitos escrito en lenguaje natural; preservar el mismo vocabulario durante el ciclo de vida del software; facilitar la comprensin del UdeD en las actividades de la IR. Ser un ancla para todas las fases del proceso de desarrollo del software: ser un punto de partida para las siguientes actividades de la IR; permitir la bsqueda de informacin acerca del UdeD en un modo no estructurado, es decir, convertirse en un repositorio de conocimiento sobre el UdeD; facilitar el entrenamiento de nuevos miembros del equipo de desarrollo sobre la terminologa en uso; ser una fuente para la convencin de nombres en el diseo y codificacin; ayudar durante la produccin de la documentacin de usuarios; ser un instrumento simple de rastreabilidad.
4.2.
Proceso de Creacin del LEL
El Lxico Extendido del Lenguaje se crea completando los casilleros en el Modelo del LEL (ver Figura 2) usando informacin obtenida del dominio de la aplicacin. La intuicin, apoyada con una buena comprensin del modelo del LEL, puede usarse para crear el lxico, pero esto puede o no llevar a un documento bien concebido. Con lo cual, se necesitan heursticas para permitir que cualquiera pueda llevar a cabo este proceso con xito y, adems, para evitar debilidades que normalmente se presentan en LELs de aparentemente buena calidad. Estas debilidades van desde smbolos relevantes omitidos hasta
- 27 -
la insercin innecesaria de algunos otros, as como la inclusin de exceso de detalles en las descripciones de smbolos o la falta de ellos.
tener informcin fehaciente de los cajeros que venden conocer los tiempos en cada paso de la gestin llevar un seguimiento de los servicios brindados a clientes
Nam e / Synonym N o tio n :
B e h a v io r a l R e s p o n s e :
Objetivos del Sistema
Modelo del LEL
Heursticas
LEL
CLIENT-USER
Notion: CLIENT-USER - Person or group of persons, belonging to UofD, who Notion: CLIENT-USER interacts with the requirements engineer - Person or group of persons, belonging to UofD, who Notion: Behavioral Response: interacts with the requirements engineer - Person or group of persons, belonging toin UofD, who - He supplies the documentation or he participates Behavioral Response: interacts with the requirements engineer the interviews - He supplies the documentation or he participates in Behavioral Response: - He participates in the LEL validation the interviews - He supplies documentation or he participates in - He participates in the the scenarios validation - He participates in the LEL validation the interviews - He participates in the scenarios validation - He participates in the LEL validation - He participates in the scenarios validation
Verificar Planear
UdeD
Plant Supervisor Personal Chief Contract
Recolectar Validar
Describir
Truck Dispatcher Enterprise Documents Legal Documentation
Lista de Fuentes de Informacin

FICHA DE REQUISITO CANDIDATO ESPONTANEO FICHA DE REQUISITO CANDIDATO Proyecto: ____________________ ESPONTANEO Fecha: __/__/____ FICHA DE REQUISITO CANDIDATO Ingeniero de Requisitos: ________ Proyecto: ____________________ ESPONTANEO Fecha: __/__/____ Ingeniero de Requisitos: ________ Proyecto: ____________________ Descripcin:___________________ Fecha: __/__/____ ______________________________ Ingeniero de Requisitos: ________ ______________________________ Descripcin:___________________ Prioridad: Obligatorio Deseado ______________________________ ______________________________ Descripcin:___________________ Tipo: Prioridad: : ____________ RF RNF Obligatorio Deseado ______________________________ Fuente de Informacin: ____________ ______________________________ Etapa Tipo: del Proyecto: : ____________ RF_______________ RNF Prioridad: Obligatorio Deseado Observacin: ____________________ Fuente de Informacin: ____________ Etapa Tipo: del Proyecto: RF_______________ RNF: ____________ Observacin: ____________________ Fuente de Informacin: ____________ Etapa del Proyecto: _______________ Observacin: ____________________
Fichas Informacin Anticipada
Figura 11. Proceso de creacin del LEL El LEL no es meramente una enumeracin de entradas; su proceso de creacin se concibe como un enfoque comprensivo. El proceso [Hadad 08], graficado en la Figura 11, consiste de cinco actividades independientes: 1) Planear, 2) Recolectar, 3) Describir, 4) Verificar y 5) Validar. Como se observa en la Figura 11, el proceso muestra un flujo principal compuesto de tres actividades: Planear, Recolectar y Describir, habiendo retroalimentaciones bien establecidas cuando la verificacin y la validacin tienen lugar. Despus de verificar y validar el LEL, el proceso retorna a la actividad Recolectar y/o a la actividad Describir, donde se hacen correcciones basadas en la lista de defectos producida (denominada lista de DEOs1). En el caso de Validar, el proceso puede tambin retornar a la actividad Planear si se descubren fuentes de informacin faltantes. Para una fcil lectura, el grfico de la Figura 11 no muestra todos los pasos de retroceso que pueden ocurrir durante el proceso de construccin. Por ejemplo, mientras se est describiendo un smbolo puede descubrirse que se le asign mal el tipo, luego un paso atrs
Una lista de DEOs contiene las discrepancias, errores y omisiones encontradas durante las actividades de verificacin y de validacin, donde se sugieren correcciones. Estrategia en la Ingeniera de Requisitos Hadad GDS - 28 1
ocurre para reclasificarlo (dentro de la actividad Recolectar). Otro ejemplo de retroceso puede deberse a la aparicin de un nuevo trmino mientras se est describiendo otro. Es decir, la estrategia no es lineal sino un proceso iterativo donde la retroalimentacin es un mecanismo constante. Adems de esta retroalimentacin continua, el flujo principal no sigue completamente un modelo de cascada dado que en la prctica real las tres actividades principales se superponen parcialmente. Por ejemplo, un smbolo puede describirse completamente mientras se identifican nuevas fuentes de informacin para clasificar o describir otros smbolos. El lxico debe adaptarse para que refleje la ltima comprensin lograda del dominio de la aplicacin; como tal evoluciona a medida que el proceso de la IR evoluciona. Las siguientes fases de la estrategia tambin pueden producir una lista de DEOs sugiriendo cambios y agregados en el LEL.
4.3.
Actividades del Proceso
A continuacin se detallan las actividades graficadas en la Figura 11.
(1) Planear
Para establecer cmo elicitar informacin del UdeD, se deben seguir tres pasos: primero identificar las fuentes de informacin, segundo evaluarlas, y finalmente seleccionar las estrategias para elicitar los smbolos. La Figura 12 muestra el flujo de estas tres actividades. Los productos de esta fase son una lista de fuentes de informacin con las estrategias seleccionadas.
- 29 -
Heursticas
Identificar Fuentes de Informacin

UdeD
Plant Supervisor
Evaluar Fuentes de Informacin
Seleccionar Estrategias
Personal Chief Contract Truck Dispatcher Enterprise Docum ents Legal Docum entation
Figura 12. Actividad Planear en el proceso del LEL
(1.1) Identificar Fuentes de Informacin

En este paso se identifican las fuentes de informacin para todas las actividades de la IR y no slo para la creacin del LEL. La heurstica general para identificar las fuentes de informacin indica primero establecer quines son los solicitantes del software, luego las personas que se presume sern impactadas por la operacin del software y finalmente a cualquier documento relacionado con el UdeD. Las fuentes de informacin estn contenidas en el UdeD, por lo tanto, el primer paso es definir el contexto dnde el proceso de IR tiene lugar, para ello se tiene como fuente inicial el documento de objetivos y alcance del sistema (de existir) y los solicitantes del sistema del software. A partir de stas comienza el descubrimiento de nuevas fuentes de informacin, armndose una lista con ellas. Al finalizar esta actividad deben poder responderse las siguientes preguntas:

Quin es el cliente? Quines sern los usuarios? Quines son usuarios claves? Existe alguna solucin (paquete) ya disponible en el mercado? Existe la posibilidad de reusar software?
- 30 -
Cules son los documentos ms referenciados por los actores del UdeD? Cules son los libros relacionados con la aplicacin?
(1.2) Evaluar Fuentes de Informacin

Despus de identificar las fuentes de informacin, deben darse prioridades a las mismas, principalmente cuando se dispone de un gran nmero de fuentes dado que en algunos casos es casi impracticable el acceso a todas ellas. Una fuente de informacin puede considerarse desde varios puntos de vista. Desde el punto de vista de la vigencia, se clasifica la informacin en actual y formal. La informacin formal es acerca de lo que debe hacerse o debe ocurrir, pero no necesariamente informacin actualizada o acerca de la prctica corriente. Mientras que la informacin actual involucra prcticas o estados corrientes, es decir, lo que realmente est en uso. Este tipo de punto de vista est muy cercano a la naturaleza de la fuente de informacin. Es decir, los usuarios, los formularios y el software actual son ciertamente fuentes que proporcionan informacin con un sesgo a lo actual, mientras que los manuales de procedimientos y las polticas del negocio presentan informacin con un sesgo formal. En este ltimo caso, debe controlarse la informacin para identificar cul es informacin actual (lo que es), informacin obsoleta (lo que ya no es) o un tercer tipo: informacin no obsoleta pero en desuso (lo que debe ser pero no es). La informacin obsoleta no debe ser completamente desechada pues un efecto de la etimologa puede existir en algunos smbolos que pueden facilitar la comprensin de su significado actual.
(1.3) Seleccionar Estrategias

Este paso apunta a seleccionar la estrategia o conjunto de estrategias ms adecuadas para elicitar los smbolos del dominio de la aplicacin. Las tcnicas principales para recolectar informacin son lectura de documentos, entrevistas, observaciones, encuestas, reuniones, enfoque antropolgico, reuso de
requisitos, recupero desde el diseo del software, entre otras. Pero para la creacin del LEL, algunas de ellas son menos tiles. La etnografa ayuda a los ingenieros de requisitos a sumergirse en la cultura del UdeD facilitando la comprensin del vocabulario pero agregando el riesgo de dificultar despus el establecer qu palabras o frases son peculiares o muy repetidas. El recupero desde el diseo del software puede contener mucho vocabulario computacional. La observacin es una tcnica excelente para capturar el comportamiento actual pero no tan apropiada para capturar el vocabulario. El uso del resto de las estrategias depende principalmente de las fuentes de informacin previamente identificadas y de los objetivos y alcance del sistema, aunque las entrevistas y la lectura de documentos son los mecanismos ms comunes para recolectar smbolos. Las entrevistas permiten a los ingenieros reconocer fcilmente el vocabulario que los clientes y usuarios emplean en su ambiente. Se recomienda el uso de entrevistas no estructuradas (tambin llamadas entrevistas abiertas), haciendo preguntas slo para motivar a que los clientes y usuarios hablen. La tcnica entrevista normalmente se combina con la lectura de texto, principalmente formularios, comprobantes, informes, manuales y polticas de la organizacin.
(2) Recolectar Smbolos

Para identificar y registrar los smbolos del lenguaje de la aplicacin, deben seguirse tres pasos: identificar los smbolos, organizarlos en una lista y finalmente clasificarlos. La Figura 13 muestra el flujo de estas tres actividades. El producto de esta fase es una lista de smbolos.
- 32 -
Plant Supervisor Personal Chief Contract Truck Dispatcher Enterprise Docum ents Legal Docum entation
Heursticas
Identificar Smbolos
UdeD
Organizar Lista
Clasificar Smbolos
Lista de Smbolos Clasificada

FICHA DE REQUISITO CANDIDATO ESPONTANEO FICHA DE REQUISITO CANDIDATO Proyecto: ____________________ ESPONTANEO Fecha: __/__/____ FICHA DE REQUISITO CANDIDATO Ingeniero de Requisitos: ________ Proyecto: ____________________ ESPONTANEO Fecha: __/__/____ Ingeniero de Requisitos: ________ Proyecto: ____________________ Descripcin:___________________ Fecha: __/__/____ ______________________________ Ingeniero de Requisitos: ________ ______________________________ Descripcin:___________________ Prioridad: Obligatorio Deseado ______________________________ ______________________________ Descripcin:___________________ Tipo: Prioridad: : ____________ RF RNF Obligatorio Deseado ______________________________ Fuente de Informacin: ____________ ______________________________ Etapa Tipo: del Proyecto: : ____________ Prioridad: RF_______________ RNF Obligatorio Deseado Observacin: ____________________ Fuente de Informacin: ____________ Etapa Tipo: del Proyecto: RF_______________ RNF: ____________ Observacin: ____________________ Fuente de Informacin: ____________ Etapa del Proyecto: _______________ Observacin: ____________________
Figura 13. Actividad Recolectar en el proceso del LEL
(2.1) Identificar Smbolos

Esta tarea apunta a capturar los smbolos del lxico del UdeD aplicando las estrategias seleccionadas a las fuentes de informacin identificadas. Los ingenieros de requisitos identifican esos smbolos y construyen una lista de smbolos candidatos. Como se ha mencionado, algunas tcnicas para la captura de informacin, como la observacin o el recupero desde el diseo del software, pueden no proporcionar la mejor informacin para recolectar smbolos. Este paquete de informacin puede examinarse con un criterio diferente en las restantes actividades de definicin de requisitos. Tambin, las entrevistas y la lectura de documentos pueden proporcionar ms informacin que la actualmente necesaria. Los documentos pueden estar disponibles al principio del proceso, sin embargo se obtienen habitualmente durante y despus de las primeras entrevistas. Generalmente, las primeras entrevistas son no estructuradas, dejando que los clientes y usuarios se expresen libremente. En las siguientes entrevistas, se recomienda generar una lista de preguntas guiadas para profundizar en los temas y ahorrar tiempo. El objetivo principal de las primeras entrevistas es
- 33 -
recoger palabras o frases con un significado especial en el dominio de la aplicacin, pero sin entender su semntica. Las entrevistas generalmente se llevan a cabo en el lugar de trabajo de los clientes y usuarios. El nmero de entrevistas depende principalmente de: la complejidad del problema; la experiencia de los ingenieros de requisitos creando un lxico; el conocimiento de los clientes y usuarios sobre el UdeD; el nmero de clientes y usuarios seleccionados para entrevistar. Cuando se usan fuentes de informacin humanas, toda la informacin capturada debe registrarse (grabando, filmando o transcribiendo) teniendo en cuenta una posible indisponibilidad de esa fuente posteriormente. Debajo se enumeran algunas reglas para seleccionar smbolos:
Seleccione exclusivamente palabras o frases pertenecientes al dominio de la aplicacin. Seleccione palabras o frases frecuentemente usadas por los clientes y usuarios o con alta repeticin en los documentos. Seleccione palabras o frases significativas en el dominio de la aplicacin. Excluya palabras o frases demasiado obvias que son de dominio pblico y no particulares del dominio de la aplicacin. Considere aquellas palabras o frases que parecen estar fuera de contexto, desconocidas o confusas como trminos dudosos para luego ahondar en ellos Identifique el nombre completo del trmino no importa cun largo sea. Sin embargo, una abreviatura o un acrnimo puede ser el nombre de un trmino. Tenga presente que una abreviatura, un acrnimo o un nombre parcial pueden ser un sinnimo de un smbolo con un nombre largo. En caso de vincular una abreviatura, un acrnimo o un nombre parcial como sinnimo de un smbolo con un nombre largo, asegrese de su existencia en el UdeD. Al emplear la tcnica de lectura de documentos, escoja los smbolos dentro del alcance de un prrafo, en lugar del texto entero.
- 34 -
La recomendacin principal para este paso es evite excluir trminos antes de tiempo, pues recin se est comenzando con la actividad de elicitar informacin. Aunque obvia, la siguiente recomendacin es siempre oportuna: tenga siempre presente el objetivo general del sistema. An cuando ste fuese concebido impreciso al inicio, sirve para guiar el proceso de captura de smbolos, concentrando la actividad en la adquisicin de informacin til para el estudio del UdeD con una visin orientada por dicho objetivo. Toda informacin extra que implique un pedido o necesidad referida al software, o un detalle de lo actual que excede la informacin de un glosario, debe registrarse en las Fichas de Informacin Anticipada.
(2.2) Organizar la Lista

El objetivo de este paso es obtener una nica lista de smbolos de las listas candidatas. Puede producirse ms de una lista candidata por varias razones, como ser, listas parciales de diferentes ingenieros de requisitos con la misma fuente de informacin o listas parciales obtenidas de diferentes fuentes de informacin. Por consiguiente, esas varias listas deben unificarse en una. Se debe recordar que todos los nombres dados a un trmino, es decir los sinnimos, son una sola entrada en el lxico. Por lo tanto, se debe organizar la lista de nombres del smbolo de manera tal que el nombre ms frecuentemente usado en el dominio de la aplicacin aparezca primero. Es decir, si uno de los nombres del smbolo raramente se usa, ste debe ubicarse al final. Luego, la lista de smbolos se clasifica alfabticamente para facilitar la bsqueda de smbolos.
- 35 -
(2.3) Clasificar Smbolos

La tarea de clasificacin ayuda a la integridad y homogeneidad de las descripciones de los smbolos. Los siguientes pasos deben realizarse: establecer una clasificacin, definir cada tipo de la clasificacin y aplicarlo a los smbolos, produciendo una lista de smbolos clasificada. Establecer una clasificacin significa adoptar la clasificacin estndar o crear una nueva adhoc. La segunda opcin no es necesaria en la mayora de los casos y slo debe aplicarse en tales dominios especficos que hacen inutilizable la clasificacin general. La Figura 14 describe en detalle la actividad Clasificar Smbolos.
S ujeto: xxxxxxxx O bjeto : xxxxxxxx V erb o: xxxxxxxx E stado : xxxxxxxx
Clasificacin General
Establecer Clasificacin
Definir Tipos
Aplicar Clasificacin
Lista de Smbolos Organizada
Lista de Smbolos Clasificada
Figura 14. Actividad Clasificar Smbolos en el proceso del LEL
(2.3.1) Establecer la Clasificacin

El criterio de clasificacin est dado por la clasificacin general propuesta en [Leite 90] o por una clasificacin particular dependiente del dominio de la aplicacin. En la mayora de los casos, la clasificacin general se adecua perfectamente dando suficiente soporte para producir un lxico homogneo con la informacin apropiada. La clasificacin general agrupa los smbolos en cuatro tipos: Sujeto, Verbo, Objeto y Estado. Estos tipos representan cada uno lo siguiente:
- 36 -
Tipo
Descripcin
Una entidad activa: una persona, organizacin, mquina o
Sujeto sistema que realiza actividades en el dominio de la

aplicacin.
Objeto
Una entidad pasiva a quien se le aplican acciones en el dominio de la aplicacin, sin realizar acciones por s misma. Una actividad o accin que ocurre en el dominio de la aplicacin. Una condicin o situacin en la cual sujetos, objetos o
Verbo
Estado actividades del dominio de la aplicacin estn o pueden estar

en un momento dado. Cuando se tiene un gran nmero de smbolos y/o un equipo de ingenieros de requisitos, puede considerarse refinar algunos tipos de la clasificacin general o crear algunos nuevos, ajustando la clasificacin al dominio especfico de la aplicacin. Esto ayuda a hacer ms precisa la definicin de cada smbolo y por consiguiente, a garantizar un lxico con una sintaxis ms homognea. En este caso, deben definirse cuidadosamente los tipos particulares basndose en la lista de smbolos. Esta circunstancia puede tener lugar cuando parte del equipo de ingenieros tiene poca experiencia en la tarea, por lo tanto, requieren ms ayuda, la cual puede proporcionarse introduciendo tipos basados en el dominio de la aplicacin. Por ejemplo, los smbolos que comparten algunos atributos pueden describirse mejor usando una plantilla diseada exclusivamente para ellos, en lugar de usar la plantilla del tipo general correspondiente.
(2.3.2) Definir los Tipos

Las plantillas para definir los cuatro tipos generales son:
- 37 -
Nocin: describir quin es el sujeto, a travs de su rol o
Sujeto
posicin. Impacto: responsabilidades y actividades que realiza o recibe. Nocin: describir qu representa, sus caractersticas e
Objeto
identificar otros objetos con los que se relaciona. Impacto: actividades y acciones que se le aplican o que se realizan con l. Nocin: describir la actividad que representa, su propsito e indicar quin lo ejecuta, cundo (cronolgicamente o relativo a otras actividades) y dnde se realiza.
Verbo Impacto:
acciones,
operaciones
procedimientos
involucrados en la actividad. Identificar situaciones que impiden su realizacin, y otras actividades o situaciones que desencadena. Nocin: describir qu representa e identificar qu estados o
Estado
actividades han conducido a este estado. Impacto: otros estados y actividades que pueden ocurrir a partir de este estado.
Si se ha elegido una clasificacin particular entonces se debe definir cada tipo particular. Esta definicin consiste en describir con precisin la plantilla de cada nuevo tipo, indicando la clase de contenido tanto en la nocin como en el impacto. Las plantillas de los tipos generales pueden usarse como gua para definir los tipos particulares. Estos deben ser al menos tan detallados como los tipos generales. En la Figura 15 se presenta un ejemplo de cada tipo de smbolo del LEL, extrado del caso Juzgado Laboral.
- 38 -
Smbolo Tipo SUJETO ACTOR / PARTE ACTORA Nocin: Es la persona que decide iniciar demanda. Impacto: Presenta un escrito contra el demandado. Puede ampliar la demanda. Puede apelar. Puede consultar un expediente en mesa de entradas.
Smbolo Tipo OBJETO EXPEDIENTE Nocin: Es el documento originado por la presentacin de una demanda. Impacto: Se le asigna por sorteo el juzgado. Se le asigna un nmero. Se registra el nombre del actor, del demandado, y la causa. Una vez ingresado en el juzgado, se le asigna un responsable.
Smbolo Tipo ESTADO EXPEDIENTE EN LETRA Nocin: Condicin por la cual un expediente se encuentra en mesa de entradas para su consulta. Impacto: El expediente puede ser consultado por un letrado, los peritos o las partes. Puede pasar a expediente no en letra a pedido del juez.
Smbolo Tipo VERBO AMPLIAR LA DEMANDA Nocin: Accin por la cual un actor agrega reclamos a una demanda. Debe ocurrir previo a que el juzgado notifique al demandado. Impacto: Se agrega informacin escrita al expediente a travs de la secretara general.
Figura 15. Ejemplo de smbolos de cada tipo
(2.3.3) Aplicar la Clasificacin

Una vez que la clasificacin ha sido fijada o adaptada, debe aplicarse un tipo a cada smbolo en la lista. A menudo, esta tarea se realiza mientras se define la clasificacin. Despus de esto, la lista de smbolos que fuera previamente organizada, presenta un tipo para cada smbolo. En la mayora de los casos, hay muy pocos smbolos que pertenecen al tipo Estado, dado que usualmente hay un bajo nivel de abstraccin dentro del dominio de la aplicacin. Generalmente, los calificadores de sujetos, objetos o verbos reemplazan a los estados y, por lo tanto, no son usados por los clientes y usuarios. Los ingenieros de requisitos no deben crear estados si realmente no existen. Si el dominio de la aplicacin ha creado por s mismo la abstraccin del estado, debe registrarse en el LEL, sino los ingenieros tienen que registrar los calificadores como parte del nombre de los sujetos, objetos o verbos.
- 39 -
Cuando un calificador se encuentra en ms de un smbolo del LEL, esto puede sugerir la existencia de un estado. El calificador podra ser un smbolo Estado por s mismo. Por otro lado, el calificador ms el sujeto / objeto / verbo puede genuinamente representar un nuevo tipo de sujeto / objeto / verbo. Se debe recordar que el LEL debe mostrar el uso del smbolo en el UdeD. Debe prestarse especial atencin tambin a los smbolos Verbo dado que pueden aparecer de diferentes maneras. A continuacin, se detallan reglas para ajustar los nombres de smbolos de verbos:

Use el modo infinitivo para el nombre de los smbolos Verbo. Transforme las frases verbales de la voz pasiva a la voz activa. Cuando el nombre de un smbolo Verbo puede ser un verbo o su forma sustantiva, incluya ambos nombres como sinnimos siempre que ambos se usen realmente en el dominio de la aplicacin.
Al tratar con un smbolo cuyo nombre es un sustantivo (independientemente de su tipo), use la forma singular siempre que sea posible. Esto no debe aplicarse en ciertos casos especiales:
Las versiones singulares y plurales no se usan con el mismo significado. La forma singular no tiene sentido en el UdeD.
(3) Describir los Smbolos

Describir los smbolos implica la definicin de su nocin y su impacto, usando el modelo del LEL y la plantilla del tipo al que pertenecen. Para describirlos, los ingenieros de requisitos pueden usar conocimiento previamente elicitado, aunque casi siempre deben retornar al UdeD para capturar ms informacin. En este caso, es recomendable conducir entrevistas estructuradas para indagar a los usuarios sobre el significado de los smbolos, aunque pueden usarse otras fuentes de informacin. A continuacin se detallan reglas para describir los smbolos en el lxico:
Cada smbolo debe tener al menos un nombre, una oracin en la nocin y una oracin en el impacto. Es decir, no se permite una
- 40 -
entidad nula.
Cada nombre del smbolo debe ser el usado en el dominio de la aplicacin, a pesar de su longitud. Los smbolos usados como sinnimos en el dominio de la aplicacin deben compartir una entrada en el LEL. Los smbolos que tienen tambin un significado comn deben contener slo el significado que se usa en el dominio de la aplicacin. Elimine del vocabulario mnimo los smbolos redefinidos en el LEL. As se usarn slo con el significado del dominio de la aplicacin. La nocin y el impacto deben describirse usando oraciones simples y directas. Las oraciones deben expresar una sola idea. Las oraciones deben contener un solo verbo. Las oraciones de la nocin y del impacto deben obedecer los principios de circularidad y de vocabulario mnimo. Cada oracin de la nocin o del impacto debe escribirse de forma tal que permita identificar la vigencia de la informacin involucrada: formal o actual. Se debe registrar ambos tipos de informacin. Respecto de informacin formal, debe quedar claro lo que debe ser y no se hace, para ello usar frases del estilo Se debera .. La descripcin de la nocin y del impacto de cada smbolo debe ajustarse a la plantilla del tipo de smbolo. Si dos smbolos comparten una misma oracin en la nocin o impacto, debe repetirse en ambas entradas. Toda nocin e impacto debe hacer referencia por lo menos a otro smbolo. Preferentemente toda oracin que describe un smbolo debera tener una referencia por lo menos a otro smbolo del LEL. Dado que un smbolo debe tener referencias a otros smbolos, dichas referencias deben marcarse (subrayando, resaltando o por cualquier otro medio). Todo smbolo debe ser referido por al menos otro smbolo. Cuando se hace referencia a otro smbolo, puede usarse cualquiera de sus nombres pero debe usarse el nombre completo.

- 41 -
Al agregar nuevos smbolos, por ejemplo debido a la retroalimentacin proporcionada por los procesos de verificacin o validacin, debe tenerse en cuenta cuidadosamente la siguiente regla:
Se debe repasar el LEL entero para que el nuevo smbolo sea referenciado por al menos otro smbolo.
Reglas de Completitud
Con respecto a la completitud deben considerarse las siguientes guas para obtener un LEL uniformemente detallado:
Tenga cuidado con el nivel de detalle utilizado en las descripciones de los smbolos. Registre todo impacto conocido. Describa los impactos acentuando el qu de las acciones, principalmente en los smbolos del tipo sujeto u objeto. Evite declaraciones sobre el cmo de las acciones en los impactos. Evite la generalizacin en las descripciones, porque se puede perder una referencia a otro smbolo, sobre todo a un smbolo Verbo. Aunque, por otro lado, use el mecanismo de abstraccin para describir los impactos, de manera tal de evitar un lxico orientado a los procedimientos.

Estas reglas requieren un cierto grado de abstraccin en la descripcin de los smbolos sin perder informacin pero tampoco sobre-especificndolos. Existe una tendencia a recargar de informacin el componente impacto por el afn de volcar en el modelo actual la mayor cantidad de informacin elicitada. Este exceso de informacin puede deberse a una elicitacin, a veces, no encauzada correctamente al objetivo de la etapa, donde el ingeniero de requisitos se aboca a entender el problema y sus detalles, o cuando se cuenta con usuarios que brindan ms informacin de la solicitada, ya sea por su personalidad o por desarrollar una actividad en niveles operativos bajos. Cuando esta informacin no ayuda a comprender mejor un smbolo, significa que ella debe registrarse en la Ficha de Informacin Anticipada. Cabe recordar que en estas fichas tambin debe volcarse informacin referida a problemas o necesidades de los usuarios. En sntesis, toda informacin referida a cmo se
desarrollan las actividades actualmente o relativa a los problemas existentes y las necesidades a satisfacer en el futuro debe quedar asentada en dichas fichas.
Nombres de Smbolos con ncleo y modificador

Los smbolos deben explorarse para descubrir ms smbolos o unificar sinnimos no detectados previamente como tales. La principal fuente en esta exploracin son los smbolos cuyo nombre se construye con una frase. En este caso, se debe identificar el sustantivo o verbo que constituye el ncleo del smbolo. La lista entera de smbolos debe explorarse buscando:

Smbolos con el mismo ncleo y diferente modificador. Smbolos con un ncleo solamente.
Si hay un grupo de smbolos que comparten el mismo ncleo, se debe considerar la existencia de una relacin jerrquica entre ellos:
Si no hay ningn smbolo con el ncleo solo, examine la existencia del ncleo en el vocabulario del UdeD. Si se encontr un smbolo con el ncleo solo, considere las siguientes variantes: o El smbolo con el ncleo solo es una generalizacin de algunos de los otros smbolos. o El smbolo con el ncleo solo se usa como sinnimo de algunos de los otros smbolos. Examine la existencia de smbolos no descubiertos en el dominio de la aplicacin con el mismo ncleo ms otros modificadores. Asegrese que no haya sinnimos entre estos smbolos.
Las reglas precedentes ayudan a descubrir omisiones de smbolos y a capturar sinnimos, pero no deben inducir a la creacin de trminos.
Jerarquas en el LEL
Pueden existir jerarquas de trminos en un LEL. Estas jerarquas estn principalmente compuestas por smbolos del tipo sujeto y objeto, y en una menor proporcin del tipo verbo, aunque es perfectamente posible una
- 43 -
jerarqua para smbolos del tipo estado. Es decir, se puede observa una relacin tipo / super-tipo entre los smbolos. La Figura 16 muestra cuatro ejemplos de jerarquas para smbolos de los tipos Sujeto, Objeto y Verbo. Caso A: Planes de Ahorro
Jerarqua del tipo Sujeto Jerarqua del tipo Verbo
Adjudicar el Bien
Adherente
Titular
Adherente Condicional
Adjudicar por Sorteo
Adjudicar por Licitacin
Caso B: Juzgado Laboral

Jerarqua del tipo Sujeto Oficial de Justicia Jerarqua del tipo Objeto Expediente
Audiencista
Responsable de Expedientes
Expediente en Prueba
Expediente en Ejecucin
Expediente Archivado
Figura 16. Ejemplos de jerarquas de smbolos La deteccin de esta relacin jerrquica debe ayudar a reducir los significados ambiguos de los trminos en un contexto dado y a completar o incrementar el conocimiento sobre aquellos trminos con menor abstraccin respecto de aqullos en los niveles altos de la jerarqua. Para cada smbolo en el lxico, siempre existe un trmino ms amplio, llamado gnero, que puede o no pertenecer al vocabulario del dominio de la aplicacin. Las jerarquas entre los smbolos de LEL aparecen cuando dos smbolos comparten el mismo gnero y ste adems es un smbolo del LEL. Incluso cuando el gnero de uno o ms smbolos no pertenece al lxico, debe ser tenido en cuenta en la descripcin de la nocin de los smbolos que lo contienen. Entonces utilizar las dos siguientes reglas de descripcin:

Incluya en la nocin el gnero al que pertenece el smbolo. Si el gnero es un smbolo del LEL, analice las descripciones de
- 44 -
todos los smbolos que componen la jerarqua para determinar la consistencia en dichas descripciones, respecto del smbolo gnero.
Smbolo
Expediente Expediente en Ejecucin Oficial de Justicia Responsable de Expedientes Pasaporte
Nocin del Smbolo

Es el documento originado por la presentacin de una demanda. Es un expediente sobre el que se ha dictado sentencia. Es un empleado que trabaja en el juzgado. Es un oficial de justicia que tiene asignado expedientes. Es un documento emitido por la Polica Federal para salir del pas. Es una persona que inicia un trmite relativo al pasaporte.
Gnero
documento
Gnero es Smbolo?
No
expediente
empleado oficial de justicia documento
No
No
Solicitante
persona
No
Tabla 1. Ejemplos del gnero en smbolos En la Tabla 1 se muestran ejemplos de smbolos del LEL con gneros que pertenecen o no al LEL. Los cuatro primeros smbolos pertenecen a la jerarqua del Caso B de la Figura 16 y los dos ltimos corresponden a smbolos mostrados en la Figura 10. En la columna Nocin del Smbolo se ha colocado una sola descripcin, aquella que presenta el gnero. Como se muestra en los ejemplos de la Figura 16, no toda jerarqua sigue el patrn: ncleo + modificador mencionado previamente. Es en general a travs del gnero que pueden detectarse las jerarquas.
Tratamiento de homnimos
Los homnimos raramente aparecen dentro del mismo contexto particular pero si esto ocurre debe aplicarse un tratamiento especial. Los homnimos no deben desecharse, pues la regla principal de la tcnica del LEL es preservar el vocabulario del dominio de la aplicacin. A veces los ingenieros de requisitos
se tientan a introducir nuevos nombres para evitar su propia confusin. Sin embargo, los usuarios seguirn utilizando estos nombres obligando a los ingenieros a reconocer sus diferentes significados.
ECODOPPLER(1)
Nocin: Es un aparato que realiza varios tipos de estudios, principalmente ecodoppler(2) y ecocardiograma. Impacto: Los mdicos lo utilizan para realizar estudios. Cada estudio lleva un transductor distinto. La secretaria coloca el transductor al aparato y al paciente.
ECODOPPLER(2)
Nocin: Es un estudio que permite evaluar el flujo sanguneo. Impacto: Se realiza utilizando el ecodoppler(1). Es evaluado por el mdico para la redaccin de un informe. Una vez realizado, produce la devolucin de un informe.
Figura 17. Ejemplo de homnimos Cuando el mismo trmino en el dominio de la aplicacin se usa con dos o ms significados, el trmino debe ser tratado como entradas diferentes en el lxico, dado que cada entrada muestra una definicin del smbolo de acuerdo a un nico significado dado por la nocin y el impacto. Obviamente los nombres de entradas deben ser nicos como claves, por lo tanto, una manera de resolver los homnimos consiste en indexar el nombre repetido para cada entrada que representa un significado diferente. Entonces, cada referencia a un homnimo en otros smbolos debe distinguirse segn su significado haciendo uso del ndice en el nombre. Si se adopta una solucin de indexado, las referencias al nombre deben ser siempre seguidas por el ndice. La Figura 17 (extrada del proyecto Servicio de Ecodoppler y Ecocardiografa de un sanatorio) muestra un ejemplo de dos smbolos con igual nombre donde cada uno tiene un significado diferente.
- 46 -
ASIGNAR TURNO / ATENDER AL PACIENTE(1)

Nocin: Es la accin de darle al paciente un da y horario para la realizacin de un estudio cardaco. Es realizado por la secretaria. Es necesario para atender al paciente(2). Impacto: Se registra en la agenda los datos del paciente y el horario asignado. El paciente puede solicitar el turno en forma personal o telefnica.
ATENDER AL PACIENTE(2)
Nocin: Es la accin que consiste en realizarle un estudio al paciente. Es realizado por el mdico o el tcnico. Se realiza en un da y horario acordado previamente al asignar turno. Impacto: El paciente debe presentar una orden de autorizacin. El mdico o tcnico realiza el estudio en el consultorio. El mdico o tcnico redacta un informe.
DEVOLVER INFORME / ATENDER AL PACIENTE(3)

Nocin: Es la accin de entregar al paciente el resultado de un estudio. Lo realiza la secretaria por la maana nicamente. Se realiza una vez que se atendi al paciente(2). Impacto: Se le entrega al paciente el informe elaborado por el mdico o el tcnico. Se registra la entrega del informe.
Figura 18. Ejemplo de homnimos con sinnimos Es frecuente que la aparicin de homnimos ocurra en distintas reas de la organizacin, donde en un sector se emplea el trmino con un cierto significado diferente al de otro sector. Se aconseja identificar en la nocin del smbolo el rea o mbito en el que dicho significado es empleado. Esto apunta a facilitar cada uno de los homnimos adecuadamente y dirigido a quienes as lo utilizan, y, por otro lado, ayuda a determinar con qu usuarios validar cada uno de estos homnimos. Tambin es frecuente que estos smbolos presenten sinnimos que los distingan (ver Figura 18). En tal caso es aconsejable el uso de los nombres distintivos para una mayor claridad en la lectura de la documentacin o
modelos que hagan referencia a ellos. En realidad esta facilidad est dirigida al grupo de desarrollo pues se debe asumir que los clientes y usuarios son los propietarios de estos trminos y por ende los entienden, los distinguen y saben utilizarlos apropiadamente.
(4) Verificar
La actividad de verificacin del LEL se realiza siguiendo heursticas que facilitan la deteccin de defectos. Se obtiene a partir de esta actividad una lista de DEOs. Los aspectos principales que cubre la verificacin son: Verificar la sintaxis:

detectar el uso de sintaxis no uniforme entre varios smbolos. controlar el nombre de los smbolos en singular. controlar el nombre de smbolos del tipo Verbo en modo infinitivo o en su forma sustantiva.
Verificar los componentes:

controlar la falta de nocin o impacto en los smbolos. controlar sinnimos ocultos: dos o ms smbolos con descripciones solapadas.
Verificar la clasificacin de smbolos:

controlar el tipo asignado a cada smbolo. comparar la nocin con la plantilla del tipo de smbolo asignado. comparar el impacto con la plantilla del tipo de smbolo asignado.
Verificar el uso de los smbolos del lxico:

controlar el marcado de todas las referencias a smbolos en cada nocin e impacto. controlar el uso del nombre completo del smbolo cuando se hace referencia a l. buscar oraciones sin ninguna referencia a smbolos. controlar la semntica del uso de smbolos al describir otros smbolos.

Verificar la adherencia a los principios:

cumplir el principio de circularidad en la descripcin de cada smbolo. cumplir el adherencia al principio de vocabulario mnimo en la descripcin de cada smbolo.
Verificar las relaciones jerrquicas:

controlar la inclusin de la nocin de un smbolo en otros smbolos. controlar la inclusin del impacto de un smbolo en otros smbolos. controlar la coherencia en las descripciones de un smbolo super-tipo respecto a sus smbolos sub-tipo.
Despus de verificar el LEL, la lista de DEOs retroalimenta las actividades Recolectar y/o Describir segn los defectos encontrados, donde los autores del lxico producen las correcciones necesarias. Se recomienda como tcnica de verificacin del LEL: la inspeccin2, ya que es un proceso formal de deteccin de defectos de alta efectividad.
(5) Validar
Mientras se identifican y describen smbolos tiene lugar una validacin informal. Posteriormente, la actividad formal de Validar permite que los ingenieros corrijan, ratifiquen o mejoren el conocimiento sobre el vocabulario del dominio de la aplicacin. Las validaciones informales apuntan a controlar la lista candidata. Validaciones posteriores se usan para controlar el conocimiento adquirido y para mejorar el lxico clarificando dudas, corrigiendo las definiciones de smbolos y excluyendo o agregando smbolos. La tarea de validacin normalmente consiste en entrevistas estructuradas o reuniones con los usuarios en su lugar de trabajo. No todos los smbolos se controlan contra cada usuario, slo se validan con l aquellos smbolos relacionados con el contexto del entrevistado. Se puede leer la descripcin de cada smbolo a los entrevistados, quienes confirman, corrija, hacen
Se aplica una variante de la tcnica de inspeccin de cdigo propuesta por Fagan [Fagan 76], adaptada a modelos de requisitos [Kaplan 00] [Leite 05].
Estrategia en la Ingeniera de Requisitos Hadad GDS - 49 2
observaciones o agregan informacin faltante. A veces, en lugar de leer las descripciones del smbolo durante la entrevista, el ingeniero entrega una copia del LEL entero o la parte de inters para el entrevistado antes de la entrevista. La validacin se lleva a cabo fcilmente con los usuarios porque no tienen dificultad en la comprensin del lxico dado que est escrito en lenguaje natural y empleando su propio vocabulario. Resumiendo, el proceso de validacin apunta bsicamente a: corregir nociones e impactos de smbolos ya descriptos; ratificar la definicin de los smbolos; identificar nuevos smbolos, sinnimos y homnimos. El proceso de validacin genera una lista de DEOs similar a la producida en la verificacin. La lista retroalimenta luego las actividades Recolectar y/o Describir, para hacer las correcciones necesarias. Si es necesario, este retroceso puede requerir elicitar nuevas fuentes de informacin en la actividad Planear.
- 50 -
5. Escenarios Actuales y Escenarios Futuros

Los ingenieros de requisitos deben comprender, modelar y analizar el UdeD donde el software operar y los usuarios deben confirmar que la visin de los ingenieros es correcta. Para lograr esto se requiere una tcnica de comunicacin atractiva para todos los participantes. En ese sentido, los escenarios pueden mantener mucha informacin de una forma que todos pueden utilizar. Los escenarios son narrativas estructuradas de situaciones del macro sistema. Los escenarios se construyen utilizando el lenguaje natural con un mnimo de formalismo. Este formalismo limita y ordena el uso del lenguaje natural de una manera tal que exige un cierto esfuerzo de los ingenieros de requisitos en su construccin pero no limita la lectura y comprensin por parte de los clientes y usuarios, reduciendo de esta manera en forma sensible la brecha semntica entre ambos grupos humanos. Si los escenarios se describen no slo en lenguaje natural sino intensificando el uso de los smbolos del LEL, se facilita ampliamente la validacin de los escenarios y se posibilita que los smbolos sean un vnculo natural entre ambas representaciones. Los escenarios se usan para entender la aplicacin y su funcionalidad: cada escenario describe una situacin especfica de la aplicacin [Zorman 95], centrando la atencin en su comportamiento. Aunque cada escenario describe una situacin particular, ninguno de ellos es completamente independiente del resto de los escenarios, sino que por el contrario cada uno guarda una relacin semntica con los otros [Booch 94]. Qu se entiende por situacin? Para considerar una situacin como tal, sta debe cumplir con las siguientes caractersticas [Breitman 01]: tener un fin establecido poder identificar actores y recursos para satisfacer el objetivo de la situacin
- 51 -
ocurrir en un tiempo dado continuo (sin interrupciones) tener un contexto geogrfico establecido poder ser restringida por ciertas condiciones ser independiente (comprensible aisladamente de otras situaciones aunque relacionada con ellas) ser concreta (anclada en la realidad) poder presentar cursos alternativos de accin Los escenarios no intentan reemplazar la especificacin de requisitos, son una fuente de provisin de conocimiento donde se pueden encontrar los requisitos y desde donde pueden derivarse las especificaciones. Los escenarios cumplen diferentes objetivos dependiendo de la fase del proceso de desarrollo donde se usen. En el proceso de la IR, sus objetivos son: facilitar la captura de requisitos; facilitar la captura de conocimiento del UdeD; proporcionar un medio de comunicacin entre los involucrados; y mantener un ancla para la rastreabilidad. Los escenarios actuales (EA) y los escenarios futuros (EF) no pueden distinguirse por su estructura, simplemente pueden diferenciarse por su contenido. Cada pieza de informacin en un escenario actual puede trazarse a situaciones que, en este momento, tienen lugar en el UdeD, mientras que los escenarios futuros factorizan la expectativa presente en el UdeD acerca del logro del proyecto de software. Es decir, los escenarios evolucionen de un contexto inicial a uno en prospectiva. Adems, las expectativas futuras cambian con el tiempo y los escenarios futuros deben reflejar estos cambios. La Figura 19 muestra la evolucin de un escenario actual a un escenario futuro, extrado del caso Sistema Nacional para la Obtencin de Pasaportes. Los escenarios actuales podran contener algunos requisitos del software pero los escenarios futuros contienen aqullos y muchos otros nuevos elicitados, definidos y negociados durante el proceso de proyeccin acerca de cmo ser el UdeD. Tambin puede decirse que hay algo as como un UdeD futuro. Cualquier
- 52 -
referencia al futuro debe entenderse como un futuro esperado. Esto no implica falta de exactitud, precisin o calidad. Significa que el escenario futuro modela cosas que no existen an, son slo planeadas y, por supuesto, evolucionarn a lo largo tiempo de desarrollo.
Escenario Futuro Escenario Actual
Ttulo: COBRAR TRAMITE Objetivo: Cobrar el trmite al solicitante. Contexto: Ubicacin Geogrfica: sector Caja Ubicacin Temporal: lunes a viernes de 8:00 a 18:00 horas Precondicin: El solicitante debi completar el formulario y pasar por el control de documentacin. El formulario debe tener los datos del solicitante y la marca del tipo de trmite. Recursos: Formulario, Mquina timbradora, planilla de cobranza. Actores: Solicitante, Cajero Episodios: 1. El solicitante se presenta con el formulario en la Caja. 2. El cajero informa el importe del trmite segn el tipo de trmite que figura en el formulario. 3. El solicitante paga el trmite. 4. El cajero timbra el formulario con el importe. 5. El cajero registra el cobro en la planilla de cobranza. 6. El cajero entrega el formulario al solicitante. Excepciones: La mquina timbradora falla. Ttulo: COBRAR TRAMITE Objetivo: Cobrar el trmite al solicitante. Contexto: Ubicacin Geogrfica: sector Caja Ubicacin Temporal: lunes a viernes de 8:00 a 18:00 horas Precondicin: El solicitante debi completar el formulario y pasar por el control de documentacin. El formulario debe tener los datos del solicitante y la marca del tipo de trmite. Recursos: Formulario Actores: Solicitante, Cajero, Sistema de Software Episodios: 1. El solicitante se presenta con el formulario en la Caja. 2. El cajero ingresa el nmero del formulario al Sistema de Software. 3. El Sistema de Software informa el importe del trmite. Restriccin: El clculo no debe exceder los 10 segundos. 4. El solicitante paga el trmite. 5. El cajero ingresa los datos de pago del formulario en el Sistema de Software. 6. El Sistema de Software actualiza los datos de pago del formulario. 7. El Sistema de Software imprime un recibo de pago del trmite. 8. El cajero entrega el formulario y el recibo al solicitante. Excepciones: El Sistema de Software no reconoce el nmero de formulario. (CARGAR FORMULARIO PROVISORIO)
Figura 19. Ejemplo de evolucin de un Escenario Actual a un Escenario Futuro Los actores en los escenarios actuales son principalmente sujetos del LEL o personas identificables en el UdeD. Los sistemas de software existentes tambin sern parte de los escenarios actuales. Sin embargo, en la visin del futuro, el sistema de software proyectado ser un actor principal. Entender el UdeD actual significa comprender lo que est pasando en l. Mientras que entender el UdeD futuro significa elicitar el conocimiento de lo que se necesita o se espera. Es decir, los escenarios futuros se relacionan estrechamente con los requisitos, mientras que los escenarios actuales competen ms con el conocimiento del contexto.
- 53 -
Se enfatiza la importancia del LEL y de los escenarios actuales pues son bsicos a la rastreabilidad. La gestin de requisitos es imposible sin la apropiada rastreabilidad. La disponibilidad de descripciones de situaciones y la capacidad de rastrear hacia adelante y hacia atrs en la evolucin de los artefactos es esencial para proporcionar un proceso de requisitos orientado a la calidad.
- 54 -
6. Comprensin del Universo de Discurso Actual

La estrategia aplica la tcnica basada en escenarios para obtener conocimiento acerca del contexto presente. Describir situaciones obliga a indagar sobre los detalles inmersos en ese contexto: procesos, caractersticas, restricciones, interacciones, actores, sistemas, entre otros elementos. Una de las dificultades ms notarias que se presenta habitualmente es decidir por dnde empezar: cmo identificar las situaciones del UdeD? Para ello, la estrategia sigue un conjunto de heursticas que guan la deteccin de situaciones y su posterior descripcin, atendiendo adems aspectos de calidad mediante tcnicas de verificacin y validacin.
6.1. Proceso de Construccin de Escenarios Actuales

El proceso de construccin de los Escenarios Actuales [Leite 00] [Leite 04] parte del lxico del dominio de la aplicacin pues el LEL contiene informacin que puede ser utilizada en los escenarios, produciendo entonces una primera versin de los escenarios derivados exclusivamente del LEL. Estos EA son completados y mejorados elicitando informacin de otras fuentes, y posteriormente organizados con el fin de obtener un conjunto consistente de escenarios que representen el dominio de la aplicacin. Durante o despus de estas actividades, los escenarios son verificados y validados para detectar Discrepancias, Errores y Omisiones (DEOs).
- 55 -
T itle : G o a l:
C o n te x t:
T e m p o r a l L o c a tio n : G e o g r a p h ic a l L o c a tio n : P r e c o n d itio n s :
A c to rs : R e s o u rc e s : E p is o d e s :
E x c e p tio n s :
Modelo de Escenario
Heursticas
CLIENT-USER
Notion: CLIENT-USER - Person or group of persons, belonging to UofD, who Notion: CLIENT-USER interacts with the requirements engineer - Person or group of persons, belonging to UofD, who Notion: Behavioral Response: interacts with the requirements engineer - Person or group of persons, belonging to UofD, who - He supplies the documentation or he participates in Behavioral Response: interacts with the requirements engineer the interviews - He supplies the documentation or he participates in Behavioral Response: - He participates in the LEL validation the interviews - He supplies documentation or he participates in - He participates in thethe scenarios validation - He participates in the LEL validation the interviews - He participates in the scenarios validation - He participates in the LEL validation - He participates in the scenarios validation
Verificar
Derivar Describir Organizar
Escenarios Actuales
Ttulo: Obtener la documentacin Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin para con que cuenta el cliente-usuario realice que el ingeniero de requisitos Obtener toda la informacin escrita Objetivo: Ttulo: Obtener la documentacin
Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su trabajo identificacin de fuentes de cliente-usuario su trabajo con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice
LEL UdeD
informacin Contexto: Se efecta en las la dependencias del Debe haberse realizado cliente-usuario identificacin de fuentes de Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Recursos: documentacin informacin Cliente-usuario Episodios:Actores: Ingeniero de requisitos Recursos: documentacin 1. El ingeniero de requisitos recibe toda Cliente-usuario la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 1. El ingeniero de requisitos recibe toda 2. El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el evala la con el cliente-usuario 1. El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario Excepciones: 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. Excepciones: documentacin recibida responde a las expectativas.
Actores:
Excepciones:
Validar
Figura 20. Proceso de construccin de Escenarios Actuales El proceso presenta las siguientes actividades: 1) Derivar, 2) Describir, 3) Organizar, 4) Verificar, y 5) Validar. Aunque en la Figura 20 se muestra un flujo principal compuesto de tres actividades: Derivar, Describir y Organizar, stas no son estrictamente secuenciales. Algunas actividades se realizan concurrentemente como condicin intrnseca del proceso mismo. Adicionalmente, existe un mecanismo de retroalimentacin entre ellas, que aporta una segunda instancia de paralelismo. Esto ocurre cuando se realizan las actividades Verificar y Validar, retornando a la actividad Describir, donde las correcciones son realizadas en base a las listas de DEOs3. La actividad Verificar ocurre despus de describir los escenarios y tambin despus de organizarlos, cuando aparecen nuevos escenarios o se generan los escenarios integradores. Los escenarios son validados con los usuarios despus de la verificacin. Se puede producir una tercera lista de DEOs, que acta como
retroalimentacin al proceso de creacin del LEL, para mantener la consistencia entre el vocabulario de los escenarios y el LEL mismo. Esto, en
Esta es una lista de DEO similar a la generada en el proceso de construccin del LEL pero referida a defectos descubiertos en los escenarios actuales.
general, no se debe a un cambio en el vocabulario del UdeD sino a que aumenta el conocimiento sobre dicho vocabulario durante la construccin de escenarios y se debe entonces rectificar el LEL. Incluso se pueden generar nuevos trminos, no a causa de su uso en los escenarios, sino porque realmente son parte del vocabulario del UdeD y que no haban sido detectados en la etapa anterior de la estrategia.
6.2. Actividades del Proceso

A continuacin se detallan las actividades graficadas en la Figura 20. Para las actividades Derivar y Organizar, se incluyen ms detalle descomponiendo cada una de ellas, ver las Figuras 21 y 23 respectivamente.
(1) Derivar
Esta actividad tiene como propsito generar escenarios candidatos utilizando informacin contenida en el LEL, basndose en el modelo de escenario y aplicando las heursticas apropiadas. El proceso de derivacin (ver Figura 21) consiste en tres pasos: identificar los actores del UdeD, identificar escenarios candidatos y por ltimo crearlos extrayendo informacin almacenada en el LEL.
(1.1) Identificar Actores

Se genera una lista preliminar de actores, a partir de informacin contenida en el LEL, con el fin de guiar las siguientes sub-actividades. Todo smbolo clasificado como Sujeto en el LEL se considera como un posible actor. Es esperado que esto ocurra salvo contadas ocasiones, como puede ser el caso de actores off-stage, es decir, aquellos que son mencionados en el curso de accin del escenario pero que no interactan directamente con otros actores. Es tambin factible que algn smbolo del tipo Objeto en el LEL pueda tratarse como un actor en un escenario, ejemplo de ello puede ser un sistema de software, una mquina o un sector de la organizacin, donde se quiere
- 57 -
mostrar su funcionamiento. En general, si este es el caso, dichos elementos ya son definidos en el LEL como Sujetos.
T itle : G o a l: C o n te x t:
T e m p o ra l L o c a tio n : G e o g ra p h ic a l L o c a tio n : P r e c o n d itio n s :
E x c e p tio n s :
Modelo de Escenario
Heurstica
CLIENT-USER
Notion: CLIENT-USER - Person or group of persons, belonging to UofD, who Notion: CLIENT-USER interacts with the requirements engineer - Person or group of persons, belonging to UofD, who Notion: Behavioral Response: interacts with the requirements engineer - Person or group of persons, belonging toin UofD, who - He supplies the documentation or he participates Behavioral Response: interacts with the requirements engineer the interviews - He supplies the documentation or he participates in - He participates Behavioral in the Response: LEL validation the interviews - He supplies documentation or he participates in - He participates in thethe scenarios validation - He participates in the LEL validation the interviews - He participates in the scenarios validation - He participates in the LEL validation - He participates in the scenarios validation
Identificar Actores Identificar Escenarios Crear Escenarios
Ttulo:
Obtener la documentacin
Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin con que cuenta el cliente-usuario para
que el ingeniero de requisitos realice Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin su trabajo Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su fuentes trabajo de identificacin de cliente-usuario informacin Contexto: Se efecta en lasla dependencias del Debe haberse realizado cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Recursos: documentacin informacin Cliente-usuario Episodios:Actores: Ingeniero de requisitos Recursos: documentacin 1. El ingeniero de requisitos recibe toda Cliente-usuario la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 1. El ingeniero de requisitos recibe toda 2. El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el evala la con el cliente-usuario 1. El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario Excepciones: 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. Excepciones: documentacin recibida responde a las expectativas.
LEL
Excepciones:
Escenarios Derivados
Figura 21. Actividad Derivar en el proceso de EA Puede ocurrir que dos o ms Sujetos del LEL compartan una responsabilidad o realicen la misma actividad. Considerar dos tratamientos posibles para su conversin en Actores de escenarios: i) ii) crear un rol que asuma la responsabilidad de esta actividad, o utilizar en el escenario correspondiente la lista de Sujetos que realizan dicha actividad. La primera alternativa involucra la creacin de un nombre de Actor, mientras que la segunda involucra tener como Actor una lista de Sujetos alternativos. Se debe elegir entre legibilidad (sujetos alternativos) o facilidad de escribir (rol). Se recomienda usar la creacin de un rol si el trmino utilizado est disponible en el UdeD o es fcilmente reconocido por los usuarios, sino ser conveniente mantener la lista de actores alternativos que puedan cumplir dicha actividad. Cuando el LEL involucra el lenguaje de toda o gran parte de la organizacin y el problema bajo estudio involucra un mbito ms acotado, entonces se debe determinar qu smbolos del tipo Sujeto tienen alguna participacin en dicho mbito y armar la lista de actores con ese grupo especfico de smbolos Sujeto.
- 58 -
(1.2) Identificar Escenarios

Se extraen del LEL los impactos de los smbolos elegidos como actores. Cada impacto representa un posible escenario y, por lo tanto, se crea un ttulo preliminar para el mismo y se lo incorpora a la lista de escenarios candidatos. El ttulo del escenario se compone con la accin (verbo) incluida en el impacto, expresada en infinitivo, ms un predicado tambin obtenido del impacto. Se debe descartar aqul impacto que involucra un punto de vista formal pues dicho impacto no representa un hecho de lo actual (ver heurstica correspondiente en Describir Smbolos en el proceso de creacin del LEL). Cuando diferentes actores ejecutan una misma actividad, es muy probable que dos o ms escenarios de la lista puedan compartir el ttulo. En este caso es recomendable no eliminar ninguno hasta asegurarse en pasos siguientes que realmente son iguales; es conveniente agregar el actor al ttulo de cada escenario similar de manera de diferenciarlos. Es recomendable redactar el ttulo del escenario desde el punto de vista del negocio, y no de agentes externos a la organizacin como clientes o proveedores, de modo tal de tener presente siempre los objetivos del negocio.
(1.3) Crear Escenarios

En este paso se construyen los escenarios con tanta informacin como sea posible extrada del LEL. El producto de este paso es un conjunto de escenarios candidatos derivados. Si el impacto mencionado contiene otros smbolos del LEL, los mismos son a su vez una fuente valiosa de informacin para componentes tales como el contexto, los actores y los recursos, entre otros. Se debe analizar adems el contenido de dicho impacto buscando smbolos del LEL del tipo Verbo. Si existe un smbolo Verbo en el impacto: i) El objetivo se define preliminarmente en base al ttulo del escenario y la nocin del smbolo Verbo. ii) La ubicacin geogrfica, la ubicacin temporal y la precondicin del
contexto puede extraerse de la nocin del smbolo Verbo. Para la precondicin, tambin puede haber informacin relevante observando semnticamente las relaciones con los restantes impactos del smbolo Sujeto origen. iii) Los actores y recursos se identifican a partir de la informacin del smbolo Verbo, buscando en l smbolos del tipo Sujeto, adems del Sujeto origen, y del tipo Objeto respectivamente. iv) Los episodios se derivan de cada impacto del smbolo Verbo. v) En el caso de detectarse un smbolo del tipo Estado en la descripcin del Verbo, existe la posibilidad de incluir como episodio alguna accin en la descripcin del smbolo Estado que tuviera relacin con el escenario. Si no existe un smbolo Verbo en el impacto: i) Se identifican otros tipos de smbolos del LEL en el impacto y se toman como posibles fuentes de informacin. ii) El objetivo se define preliminarmente en base al ttulo del escenario. iii) La ubicacin geogrfica, la ubicacin temporal y la precondicin del contexto pueden ser extradas del impacto del smbolo Sujeto que origin el escenario. Cuando este impacto contiene alguna condicin, esta puede corresponder a la Precondicin o a la Ubicacin Temporal del escenario derivado. Para la precondicin, tambin puede haber informacin relevante observando semnticamente las relaciones con los restantes impactos del mismo smbolo Sujeto. iv) Se seleccionan posibles actores y recursos a partir de los smbolos detectados previamente, adems del smbolo Sujeto que dio origen al escenario. Los actores se derivan de smbolos tipo Sujeto y los recursos de smbolos tipo Objeto. v) Solo es posible incluir como episodio alguna accin referida a este escenario contenida en la definicin de trminos tipo Objeto, tipo Estado u otros trminos Sujeto detectados previamente en el impacto. La Figura 22 ejemplifica la actividad Derivar usando el caso Sistema de Agenda de Reuniones y la Figura 23 muestra la versin final de este
escenario. Las palabras o frases subrayadas son smbolos del LEL. En la Figura 22 se muestran nmeros para explicar la actividad Derivar, cuyo significado se detalla a continuacin: 1 - de las entradas del LEL se genera una lista de actores; 2 - seleccionando un actor se tiene la correspondiente entrada del LEL; 3 - del impacto de esta entrada del LEL se produce una lista de escenarios candidatos; 4 - seleccionado un escenario candidato se encuentra el smbolo Verbo del LEL correspondiente al ttulo del escenario; 5 - se usa la nocin del smbolo Verbo para definir el objetivo, actor y recursos; 6 - el impacto del smbolo Verbo proveer las bases para describir los episodios; y 7 - del impacto originado en 3 (tipo Sujeto) se deriva informacin para el contexto.
- 61 -
Entradas del LEL

Agenda (O) anulacin de reunin (V) convocado (S) convocante (S) convocatoria / cita (V) diseo de la agenda de reuniones (V) espacio fsico (O) material fsico(O) ... Lista de Actores
Smbolo del LEL (tipo Sujeto)

CONVOCANTE
Nocin: persona que invita a los convocados a una reunin. puede ser un participante. Impacto: determina el objetivo de la reunin, los temas a tratar, los convocados, el material para repartir y el material a presentar. registra el objetivo y los convocados, en el esquema de base. realiza el diseo de la agenda de reuniones. organiza la reunin. registra en la agenda al reemplazante. determina la anulacin de la reunin.
Convocante Secretaria Convocado Participante Reemplazante
...
Lista de Escenarios Candidatos Definir el objetivo, temas, convocados, material para repartir y material para presentar. Registrar el objetivo y los convocados en el esquema base. Disear la agenda de reuniones. Organizar la reunin. Registra el reemplazante en la agenda. Anular la reunin.
Smbolo del LEL (tipo Verbo)

DISEO DE LA AGENDA DE REUNIONES
4 7
Nocin: actividad que realiza el convocante para determinar la fecha de convocatoria, el horario y el lugar de las reuniones, basndose en los horarios disponibles de los convocados, la disponibilidad de espacio y otras reuniones ya registradas en la agenda. tiene la finalidad de organizar los tiempos y evitar superposiciones y omisiones de reuniones. Impacto: se registra en la agenda: el objetivo, la fecha establecida, el horario y el lugar establecido para llevar a cabo la reunin. se confecciona el listado para convocatoria. se confecciona el temario. se registra en el cronograma de reuniones. se reserva el espacio fsico.
Escenario Candidato Derivado

Ttulo: DISEAR LA AGENDA DE REUNIONES Objetivo: Definir la fecha de convocatoria, el horario, el lugar y requerimientos de la reunin. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: -Precondicin: Fue definido previamente el objetivo, los convocados,... Recursos: agenda, listado para convocatoria, horarios disponibles, ... Actores: convocante, convocados, secretaria Episodios: 1. El convocante registra en la agenda: el objetivo, la fecha establecida, el horario y el lugar establecido para llevar a cabo la reunin. 2. El convocante confecciona el listado para convocatoria. 3. El convocante confecciona el temario. 4. El convocante registra en el cronograma de reuniones. 5. ...
Figura 22. Ejemplo de derivacin de un escenario actual
- 62 -
Sistema de Agenda de Reuniones

Ttulo: DISEAR LA AGENDA DE REUNIONES Objetivo: Definir la fecha de convocatoria, el horario, el lugar y requerimientos de la Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: -Precondicin: Debe presentarse previamente la necesidad de una reunin. Recursos: agenda, horarios disponibles, cronograma de reuniones, esquema de base Actores: convocante, secretaria Episodios:
reunin.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
[El convocante obtiene del esquema de base los datos de la reunin a disear.] # Si no se tienen registrados los horarios disponibles de los convocados, SOLICITAR HORARIOS DISPONIBLES. El convocante consulta sobre la disponibilidad de espacio. El convocante consulta la agenda para ver sus horarios disponibles en la misma. # ESTABLECER LA FECHA DE LA REUNION. [El convocante define el material para repartir.] #El convocante o la secretaria registra en la agenda: objetivo, temas a tratar, fecha establecida, horario, lugar, convocados, material a presentar y material para repartir. GENERAR EL LISTADO PARA CONVOCATORIA. [El convocante define el temario.] El convocante o la secretaria registra la reunin en el cronograma de reuniones. El convocante o la secretaria reserva el espacio fsico. [El convocante o la secretaria reserva el material fsico.] [El convocante o la secretaria registra el material fsico en la agenda.] #
Excepciones:
- Conflictos en la disponibilidad de espacio (SOLICITAR ESPACIO FISICO EN EDIFICIO ANEXO). - Conflictos en la disponibilidad de material fsico (El convocante solicita autorizacin al Sector Mantenimiento para obtener material fsico especial).
Figura 23. Versin final de un escenario actual
(2) Describir
Esta actividad tiene por objetivo completar la descripcin de los escenarios candidatos, agregando informacin del UdeD basndose en el modelo de escenario, utilizando en la descripcin los smbolos del LEL y aplicando las heursticas de descripcin. El resultado es un conjunto de escenarios descriptos completamente. El conjunto incompleto de escenarios candidatos obtenidos en el paso anterior debe extenderse en dos sentidos: agregando nuevos escenarios y completando el contenido de los escenarios. Entonces, los ingenieros de requisitos retornan a las fuentes de informacin identificadas durante la creacin del LEL para recolectar ms informacin. Adems, ahora se utiliza la
- 63 -
informacin recogida durante el proceso de construccin del LEL pero que no fuera incluida en l, es decir, se utilizan aquellas Fichas de Informacin Anticipada que contengan informacin actual. Esta actividad debe planearse y generalmente se realiza aplicando las tcnicas de entrevistas estructuradas, observacin y lectura de documentos, pero en general casi todas las tcnicas de elicitacin son aplicables4, lo que debe identificarse es la vigencia de la informacin que brinda la fuente, pues en esta etapa se requiere estrictamente informacin actual. Primero, la recoleccin de informacin apunta a confirmar y mejorar los cursos normales de eventos. Despus, deben descubrirse caminos alternativos y casos de excepcin. Algunas causas de excepcin se elicitan de las fuentes de informacin, mientras que otras pueden deducirse cuestionando la ocurrencia de episodios o la falta de disponibilidad o mal funcionamiento de los recursos. Al descubrir causas de excepcin, los ingenieros de requisitos deben averiguar sobre el tratamiento que recibe la excepcin en el UdeD, esto puede implicar una nueva situacin a ser descripta a travs de un escenario separado. En la precondicin del escenario excepcin se incluye la causa de la excepcin. Si el escenario excepcin se utiliza como tratamiento de ms de una excepcin, la precondicin puede expresarse por enunciacin como una lista alternativa de causas o por generalizacin de dichas causas. Tambin deben detectarse restricciones, algunas elicitadas del UdeD y otras examinando los episodios. Ya en el UdeD actual pueden existir RNF para el software existente, que deben ser considerados e incorporados en el atributo Restriccin. Una vez concluida la descripcin del escenario, deben repasarse los episodios cuidadosamente para confirmar si tienen un orden secuencial o no y para detectar si algn episodio se realiza bajo alguna condicin (episodio condicional) o si ste no siempre se realiza pero no hay una condicin explcita que se pueda especificar (episodio optativo). Toda cuestin dudosa que surja durante la escritura del escenario, debe volcarse en el componente transitorio Duda, para luego poder dilucidarlo en el
Tcnicas de elicitacin como por ejemplo: anlisis de dominios, reuso de requisitos o prototipos, no son tcnicas que sirvan para recolectar datos referidos a lo actual.
UdeD. Observando la Figura 20, se puede ver que existe un reciclo desde las actividades Verificar y Validar, debido a la generacin de las listas de DEOs. Estas listas pueden motivar cambios en las descripciones de los escenarios. Tambin la propia actividad Describir puede generar una lista de DEOs referidos al LEL. A continuacin se enuncian las heursticas generales para tener en cuenta durante la descripcin de los escenarios. Dado que al llegar a esta actividad, ya se cuenta con algunos escenarios parcialmente descriptos, estas guas deben usarse tambin para mejorar las descripciones ya existentes.

Escriba preferentemente usando oraciones cortas. Evite el uso de ms de un verbo por oracin. Escriba las oraciones maximizando el uso de los smbolos del LEL. Seleccione Actores y Recursos que sean preferentemente smbolos del LEL del tipo Sujeto y del tipo Objeto respectivamente. Escriba el objetivo en forma precisa y concreta. Debe completar al menos uno de los sub-componentes del contexto. Incluya en el componente Recursos todos aquellos recursos que se utilizan en los episodios o son referidos implcitamente por el verbo del episodio. Ejemplo: El cajero timbra el formulario, donde el recurso implcito es la Mquina Timbradora. Excluya recursos triviales del componente Recursos. Ejemplo: El contador firma el cheque, donde el elemento para firmar, ya sea una lapicera o birome, no es un recurso relevante para la accin. Recuerde que un recurso no puede ser aqul generado durante la realizacin de los episodios del escenario, s podr ser un recurso en otro escenario. Ejemplo: El convocante confecciona la lista para la convocatoria, donde lista para la convocatoria es un recurso en varios otros escenarios pero no en el escenario al que pertenece este episodio. Incluya tambin en el componente Recursos aquellos recursos utilizados en sub-escenarios del escenario. Incluya en el componente Actores aquellos involucrados en los
- 65 -

episodios que tienen alguna participacin en ellos. La mencin de un actor en un episodio no significa su participacin. Ejemplo: El contador analiza la cuenta corriente del cliente, donde el cliente no realiza ninguna accin en este episodio, an cuando es un actor en otros escenarios. Se dice que el cliente es un actor off-stage en este escenario.
Incluya tambin en el componente Actores aquellos actores que participan en sub-escenarios del escenario. Utilice un verbo en cada episodio que sea preciso y concreto, especificando la accin final y evitando posibles ambigedades. Asegrese que los episodios ocurren dentro de la ubicacin geogrfica y temporal descripta en el Contexto del escenario. Describa los episodios en tiempo presente. Evite usar en los episodios verbos tales como: podra, puede, debe, debera.

Toda informacin elicitada que no corresponda volcar en los escenarios actuales pues es informacin sobre lo esperado para el futuro, debe incluirse en las Fichas de Informacin Anticipada.
(3) Organizar
El conjunto de escenarios actuales obtenidos de la actividad Describir puede presentar dos tipos de debilidades: i) los ingenieros de requisitos estn sumergidos en detalles, perdiendo la visin global del UdeD, y ii) existe un riesgo de inconsistencias entre los escenarios, tales como la existencia de subescenarios irrelevantes o escenarios con alta similitud. La primera se encara por medio del uso de escenarios integradores actuales, los cuales describen situaciones artificiales presentadas slo con el propsito de hacer ms entendible y manejable el conjunto de escenarios. Los escenarios integradores brindan una visin global de la aplicacin. La segunda debilidad se maneja componiendo o descomponiendo escenarios, para atacar bsicamente problemas de falta de homogeneidad en la descripcin de las situaciones y algunos problemas menores de semntica.
- 66 -
Cuando se encaran aplicaciones medianas a grandes, la cantidad de escenarios suele tornarse inmanejable. Luego, los escenarios integradores dan un panorama de las relaciones entre varias situaciones, dado que cada episodio de un escenario integrador es el ttulo de un escenario ya descripto. El propsito principal de los escenarios integradores es vincular escenarios dispersos, proveyendo un panorama completo de la aplicacin.
T itle :
G o a l: C o n te x t:
T e m p o ra l L o c a tio n : G e o g ra p h ic a l L o c a tio n : P re c o n d itio n s :
E x c e p tio n s :
LEL
CLIENT-USER
Notion: CLIENT-USER - Person or group of persons, belonging to UofD, who Notion: CLIENT-USER interacts with the requirements engineer - Person or group of persons, belonging to UofD, who Notion: Behavioral Response: interacts with the requirements engineer - Person or group of persons, belonging toin UofD, who - He supplies the documentation or he participates Behavioral Response: interacts with the requirements engineer the interviews - He supplies the documentation or he participates in Behavioral Response: - He participates in the LEL validation the interviews - He supplies documentation or he participates in - He participates in thethe scenarios validation - He participates in the LEL validation the interviews - He participates in the scenarios validation - He participates in the LEL validation - He participates in the scenarios validation
Modelo de Escenario
Heurstica
Escenarios Actuales
Ttulo: Obtener la documentacin Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin para con que cuenta el cliente-usuario
que el ingeniero de requisitos realice Obtener toda la informacin escrita Objetivo: Ttulo: Obtener la documentacin su trabajo Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su fuentes trabajo de identificacin de cliente-usuario informacin Contexto: Se efecta en las la dependencias del Debe haberse realizado cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Recursos: documentacin informacin Cliente-usuario Episodios:Actores: Ingeniero de requisitos Recursos: documentacin 1. El ingeniero de requisitos recibe toda Cliente-usuario la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 1. El ingeniero de requisitos recibe toda 2. El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el evala la con el cliente-usuario 1. El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario Excepciones: 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. Excepciones: documentacin recibida responde a las expectativas.
Escenarios Actuales Descriptos

Ttulo: Obtener la documentacin Objetivo: Obtener toda la informacin escrita Ttulo: Obtener documentacin con que cuenta el la cliente-usuario para
que el Obtener ingenierotoda de requisitos realice la informacin escrita Objetivo: Ttulo: Obtener la documentacin su trabajo Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su trabajo identificacin de fuentes de cliente-usuario con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice informacin Contexto: Se efecta en las la dependencias del Debe haberse realizado cliente-usuario identificacin de fuentes de Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Recursos: documentacin informacin Cliente-usuario Episodios:Actores: Ingeniero de requisitos Recursos: documentacin 1. El ingeniero de requisitos recibe toda Cliente-usuario la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 1. El ingeniero de requisitos recibe toda 2. El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el evala la con el 1. cliente-usuario El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario Excepciones: 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. Excepciones: documentacin recibida responde a las expectativas.
Reorganizar Escenarios Definir Relaciones Integrar Escenarios
Excepciones:
Ttulo:
Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin con que cuenta el cliente-usuario para
que el ingeniero de requisitos realice Obtener toda la informacin escrita Objetivo: Ttulo: Obtener la documentacin su trabajo Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su fuentes trabajo de identificacin de cliente-usuario informacin Contexto: Se efecta en las la dependencias del Debe haberse realizado cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Recursos: documentacin informacin Cliente-usuario Episodios:Actores: Ingeniero de requisitos Recursos: documentacin 1. El ingeniero de requisitos recibe toda Cliente-usuario la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 1. El ingeniero de requisitos recibe toda 2. El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el evala la con el cliente-usuario 1. El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario Excepciones: 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. Excepciones: documentacin recibida responde a las expectativas.
Actores:
Excepciones:
UdeD
Escenarios Actuales Integradores
Excepciones:
Figura 24. Actividad Organizar en el proceso de EA Organizar los escenarios consiste en reorganizarlos e integrarlos, comenzando a partir de escenarios completamente descriptos. Aunque la actividad Organizar est ubicada como tercera caja en la Figura 20, las actividades Verificar y Validar deben realizarse tanto antes de comenzar a organizar los escenarios como luego de terminada esta actividad. Es decir, organizar escenarios es una tarea que se hace slo cuando se tiene una buena confianza en contar con un conjunto de escenarios bien definidos, idealmente cuando las listas de DEOs estn vacas. Luego, como consecuencia de esta actividad, se procede a una verificacin y validacin, afectando slo las partes modificadas y los nuevos escenarios creados. En esta actividad puede ser necesario volver al UdeD, utilizar el LEL y chequear las Fichas de Informacin Anticipada. Adems se utiliza una
- 67 -
taxonoma
de
operaciones
relaciones.
La
Figura
24
muestra
la
descomposicin de la actividad Organizar.
(3.1) Reorganizar Escenarios

Los escenarios pueden tener distinto grado de detalle o superposicin, especialmente cuando son construidos por ms de un ingeniero de requisitos. Esto se torna ms complejo a medida que se tienen ms escenarios y un grupo de trabajo ms grande. Bsicamente la reorganizacin de escenarios consiste en componer dos o ms escenarios en uno, o en fragmentar un escenario en dos o ms. La composicin se realiza cuando una nica situacin fue artificialmente repartida en varios escenarios durante las actividades Derivar o Describir. Por otro lado, se fragmenta o descompone un escenario cuando ste contiene ms de una situacin. Estas operaciones se agrupan de a pares composicin / descomposicin bajo tres aspectos (ver Tabla 2):
Granularidad
Los sub-escenarios obtenidos en pasos anteriores deben estudiarse para confirmar que son realmente necesarios y debe analizarse que no haya sub-escenarios ocultos en otros escenarios.
Situaciones con variaciones

En el UdeD puede haber situaciones muy similares entre s que presentan algunas diferencias o variantes en su realizacin, como por ejemplo, la existencia de ms una ubicacin geogrfica posible, ms de un actor ejecutando la misma tarea, entre otros.
Temporalidad
La duracin de un escenario es tambin una cuestin difcil de establecer. En algunos casos, dos escenarios estn tan relacionados que uno se produce inmediatamente despus del otro, por lo tanto, puede ser mejor describirlos en un solo escenario. Por otro lado, un escenario con un lapso de vida (contexto temporal) largo conteniendo episodios no muy compactos semnticamente pueden conducir a la creacin de dos o ms escenarios diferentes.
Dimensin Granularidad Variaciones Temporalidad
Composicin Aplanar Consolidar Fusionar
Descomposicin Factorizar Dividir Separar
Tabla 2. Tipos de operaciones en la reorganizacin de escenarios Las operaciones se sugieren como guas para mejorar la comprensin y administracin de los escenarios. Por lo tanto, la reorganizacin no debe asumirse como una actividad obligatoria sino como una buena prctica. A continuacin se describen las operaciones con sus correspondientes propiedades o relaciones entre escenarios:
Aplanar
Oportunidad Esta operacin se aplica cuando se detectan sub-escenarios no relevantes con poca ocurrencia en otros escenarios. Para aplicarla, debe cumplirse adems que los episodios del subescenario presenten la misma granularidad que los episodios de cada escenario que lo menciona. Se incorporan los episodios del sub-escenario dentro de cada escenario que lo menciona. Si el sub-escenario presentaba excepciones, stas deben trasladarse a los escenarios aplanados. El sub-escenario original se elimina cuando todas sus ocurrencias se han aplanado. Reducir la cantidad de escenarios no relevantes, facilitando la administracin del conjunto de escenarios. El conjunto resultante de escenarios decrece la profundidad de la jerarqua en todos los puntos de aplanamiento. Esta operacin es anloga a la caracterstica inline en la generacin de cdigo en algunos lenguajes de programacin.
Procedimiento
Propsito
Factorizar
Oportunidad Esta operacin se aplica cuando dentro de un escenario se detecta un conjunto de episodios muy relevantes o que presentan diferente nivel de detalle respecto al resto de los
- 69 -
episodios. Tambin se puede aplicar cuando se descubre la ocurrencia de un mismo conjunto de episodios en dos o ms escenarios con comportamientos comunes. Procedimiento Se crea un sub-escenario extrayendo de uno o ms escenarios el conjunto de episodios comunes detectados. El grupo de episodios en cada escenario origen se reemplaza por el ttulo del nuevo sub-escenario que los contiene. Esta operacin se pueda realizar slo si se encuentra un objetivo significativo para el conjunto de episodios a factorizar en el nuevo sub-escenario, sino se estara creando una situacin ficticia. Obtener escenarios ms fciles de comprender, pues todos los episodios del escenario quedan al mismo nivel de detalle. Fomentar la reusabilidad, dado que un sub-escenario posee un objetivo ms concreto y limitado, con mayor posibilidad de estar presente en otras situaciones.
Propsito
Consolidar
Oportunidad Esta operacin se aplicar a escenarios superpuestos. Dos o ms escenarios tienen una superposicin fuerte si sus objetivos y contextos son similares, y tienen varias coincidencias en sus episodios. Es decir, estos escenarios presentan el mismo ncleo de accin. Se copian los episodios comunes de los escenarios originales a un escenario nuevo y se crean nuevos episodios condicionales usando los episodios no compartidos, siendo la condicin parte de las precondiciones de los escenarios originales. El objetivo del nuevo escenario debe abarcar a todos los episodios incorporados. Se dice que el objetivo se extiende por generalizacin. Los escenarios originales usualmente tienen los mismos actores y muchos recursos comunes, por ende en el nuevo escenario debe incluirse la unin de los actores y de los recursos, como tambin la unin de las excepciones. Los escenarios originales se eliminan. Reducir redundancia en el conjunto de escenarios, facilitando el mantenimiento de los mismos.
Procedimiento
Propsito
Dividir
Oportunidad Esta operacin se aplica cuando se detecta la presencia de muchos episodios condicionales, dirigidos por el mismo tipo de condicin. sta puede presentarse por la negacin de la
- 70 -
condicin, o por los posibles valores de dicha condicin, denominada condicin disparadora. Procedimiento Se producen dos o ms nuevos escenarios, uno por cada valor de la condicin disparadora. Dicho valor suele formar parte del ttulo del nuevo escenario para distinguirse, y dependiendo del tipo de condicin formar parte de la precondicin del nuevo escenario o de su objetivo. Los episodios que no contienen esta condicin disparadora se trasladan tal cual a todos los nuevos escenarios. Por otro lado, los episodios con la condicin disparadora se trasladan slo al escenario correspondiente eliminando la condicin. El escenario original se elimina. Deben revisarse los componentes actores, recursos y excepciones de los nuevos escenarios, pues debido al movimiento de episodios, puede dejar de estar presente un recurso o un actor, o excluirse alguna excepcin de alguno de estos nuevos escenarios. Evitar escenarios confusos, facilitando su legibilidad y reduciendo as la complejidad.
Propsito
Fusionar
Oportunidad Esta operacin se aplica a escenarios que representan situaciones que ocurren una detrs de la otra sin una brecha temporal entre ellos, comparten la misma ubicacin geogrfica y temporal, y tienen objetivos acoplables. Una brecha temporal ocurre cuando existe un intervalo de tiempo largo entre dos escenarios. Se copian los episodios de cada escenario original a un nuevo escenario en el orden correspondiente. El objetivo del nuevo escenario debe abarcar ambos escenarios, en general se construye a partir del objetivo del ltimo escenario fusionado. Los actores, recursos y excepciones del nuevo escenario se obtienen uniendo los correspondientes componentes de los escenarios fusionados. La precondicin se construye a partir de la precondicin del primer escenario fusionado, agregndole precondiciones de carcter externo de los restantes escenarios fusionados. El contexto temporal se construye por generalizacin como suma de los contextos temporales originales. La ubicacin geogrfica debe ser la misma en todos los escenarios originales y, por ende, se traslada al nuevo escenario. Los escenarios originales son eliminados. Reducir la cantidad de escenarios y facilitar entonces su administracin.
Procedimiento
Propsito
- 71 -
Separar
Oportunidad Esta operacin se aplica a un escenario que tiene una brecha temporal entre episodios o tiene un contexto temporal muy extenso. Un contexto temporal largo puede detectarse por el contexto en s mismo o por la secuencia de los episodios. Esta operacin tambin puede considerarse cuando se descubre ms de una ubicacin geogrfica en un escenario. Es decir, el escenario est representando ms de una situacin contradiciendo la definicin misma de escenario. La descomposicin del escenario debe producir escenarios con un contexto temporal bien acotado. Se utiliza la brecha temporal como gua para la descomposicin del escenario en varios escenarios segn la cantidad de demoras detectadas. Se copia en un nuevo escenario todos los episodios que preceden a la brecha temporal y aquellos episodios que siguen a la brecha temporal se copian en otro nuevo escenario. El escenario original se elimina. Las precondiciones del segundo y siguientes nuevos escenarios reflejan el orden de precedencia establecido. Los componentes actores y recursos de cada nuevo escenario deben re-hacerse. Los objetivos de los nuevos escenarios sern ms acotados que el objetivo original, restringindose al conjunto de episodios que contienen. Reducir la complejidad y comprender mejor las situaciones.
Procedimiento
Propsito
La Figura 25 muestra la operacin Factorizar aplicada a dos escenarios con varios episodios comunes que tienen un objetivo especfico; se crea un nuevo escenario conteniendo estos episodios; los escenarios originales se reescriben, reemplazando los episodios comunes extrados por el ttulo del nuevo escenario. La Figura 26 ejemplifica la operacin Consolidar aplicada a dos escenarios superpuestos, produciendo un nico escenario que contiene los episodios comunes; los episodios no compartidos se incorporan con una sentencia condicional. Los escenarios graficados en ambas figuras corresponden al caso Sistema de Agenda de Reuniones.
- 72 -
Escenario original
Ttulo: DISEAR LA AGENDA DE REUNIONES Objetivo: Definir la fecha, la hora, el lugar y los requerimientos de la reunin. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: -Precondicin: Debe presentarse previamente la necesidad de una reunin. Recursos: agenda, horarios disponibles, cronograma de reuniones, esquema base ... Actores: convocante, secretaria Episodios: 1. [El convocante obtiene del esquema base los datos de la reunin a disear.] 2. # Si no se tienen registrados los horarios disponibles de los convocados, SOLICITAR HORARIOS DISPONIBLES. 3. El convocante consulta sobre la disponibilidad de espacio. 4. El convocante consulta la agenda para ver sus horarios disponibles en la misma. # 5. El convocante verifica la existencia de fechas comunes disponibles entre los horarios disponibles de los convocados y los suyos. 6. Si existen fechas comunes disponibles, el convocante selecciona la mejor fecha y hora segn un dado criterio. 7. El convocante elige el lugar segn los espacios disponibles. 8. [El convocante define el material para repartir.] 9. #El convocante o la secretaria registra en la agenda: objetivo, temas a tratar, fecha, hora, lugar, convocados, material a presentar y material para repartir. ... 14
Escenario original
Ttulo: TRASLADAR LA FECHA DE LA REUNION Objetivo: Actualizar la agenda por un cambio en la fecha de la reunin. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: -Precondicin: La reunin est en la agenda. Recursos: agenda, horarios disponibles, cronograma de reuniones, listado para convocatoria ... Actores: convocante, secretaria, convocados Episodios: 1. # Si no se tienen registrados los horarios disponibles de los convocados, SOLICITAR HORARIOS DISPONIBLES. 2. El convocante consulta sobre la disponibilidad de espacio. 3. El convocante consulta la agenda para ver sus horarios disponibles en la misma. # 4. El convocante verifica la existencia de fechas comunes disponibles entre los horarios disponibles de los convocados y los suyos. 5. Si existen fechas comunes disponibles, el convocante selecciona la mejor fecha y hora segn un dado criterio. 6. El convocante elige el lugar segn los espacios disponibles. 7. El convocante actualiza la fecha de la reunin en la agenda y en el cronograma de reuniones. 8. # Si se realiz la convocatoria, la secretaria avisa por algn medio de comunicacin el cambio de la fecha de la reunin a cada convocado, utilizando el listado para convocatoria. 9. ....
Nuevo sub-escenario
Ttulo: ESTABLECER LA FECHA DE LA REUNION Objetivo: Fijar la fecha, la hora y el lugar de la reunin. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: -Precondicin: Se tienen los horarios disponibles de los convocados y del convocante, y la disponibilidad de espacio. Recursos: horarios disponibles, espacios disponibles Actores: convocante Episodios: 1. El convocante verifica la existencia de fechas comunes disponibles entre los horarios disponibles de los convocados y los suyos. 2. Si existen fechas comunes disponibles, el convocante selecciona la mejor fecha y hora segn un dado criterio. 3. El convocante elige el lugar segn los espacios disponibles.
Escenario modificado
Ttulo: DISEAR LA AGENDA DE REUNIONES Objetivo: Definir la fecha, la hora, el lugar y los requerimientos de la reunin. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: -Precondicin: Debe presentarse previamente la necesidad de una reunin. Recursos: agenda, horarios disponibles, cronograma de reuniones, esquema base ... Actores: convocante, secretaria Episodios: 1. [El convocante obtiene del esquema base los datos de la reunin a disear.] 2. # Si no se tienen registrados los horarios disponibles de los convocados, SOLICITAR HORARIOS DISPONIBLES. 3. El convocante consulta sobre la disponibilidad de espacio. 4. El convocante consulta la agenda para ver sus horarios disponibles en la misma. # 5. ESTABLECER LA FECHA DE LA REUNION. 6. [El convocante define el material para repartir.] 7. #El convocante o la secretaria registra en la agenda: objetivo, temas a tratar, fecha, hora, lugar, convocados, material a presentar y material para repartir. ... 8
Escenario modificado
Ttulo: TRASLADAR LA FECHA DE LA REUNION Objetivo: Actualizar la agenda por un cambio en la fecha de la reunin. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: -Precondicin: La reunin ya ha sido agendada. Recursos: agenda, horarios disponibles, cronograma de reuniones, listado para convocatoria ... Actores: convocante, secretaria, convocados Episodios: 1. # Si no se tienen registrados los horarios disponibles de los convocados, SOLICITAR HORARIOS DISPONIBLES. 2. El convocante consulta sobre la disponibilidad de espacio. 3. El convocante consulta la agenda para ver sus horarios disponibles en la misma. # 4. ESTABLECER LA FECHA DE LA REUNION. 5. El convocante actualiza la fecha de la reunin en la agenda y en el cronograma de reuniones. 6. # Si se realiz la convocatoria, la secretaria avisa por algn medio el cambio de la fecha de la reunin a cada convocado, utilizando el listado para convocatoria. 7. ....
Figura 25. Ejemplo de la operacin Factorizar
- 73 -
Escenario original Escenario original

Ttulo: ANULAR LA REUNION ANTES DE LA CONVOCATORIA Objetivo: Liberar la agenda de la reunin que se cancela. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: debe realizarse antes de la fecha de la reunin. Precondicin: La reunin ya ha sido agendada. Los participantes no han sido convocados. Recursos: agenda, cronograma de reuniones, espacio fsico, material fsico, listado para convocatoria Actores: convocante, secretaria. Episodios: 1. El convocante o la secretaria registran la cancelacin en la agenda. 2. El convocante o la secretaria registran la cancelacin en el cronograma de reuniones. 3. La secretaria anula la reserva de espacio fsico. 4. [La secretaria anula la reserva de material fsico.] Ttulo: ANULAR LA REUNION DESPUES DE LA CONVOCATORIA Objetivo: Liberar la agenda de la reunin que se cancela. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: debe realizarse antes de la fecha de la reunin. Precondicin: La reunin ya ha sido agendada. Los participantes ya han sido convocados. Recursos: agenda, cronograma de reuniones, espacio fsico, material fsico, listado para convocatoria, medio de comunicacin. Actores: convocante, secretaria, convocados. Episodios: 1. El convocante o la secretaria registran la cancelacin en la agenda. 2. El convocante o la secretaria registran la cancelacin en el cronograma de reuniones. 3. # La secretaria da el aviso de cancelacin a cada convocado o reemplazante, a travs de algn medio de comunicacin, utilizando el listado para convocatoria. 4. La secretaria registra el aviso de cancelacin en el listado para convocatoria. 5. La secretaria anula la reserva de espacio fsico. 6. [La secretaria anula la reserva de material fsico.] #
Ttulo: ANULAR LA REUNION Objetivo: Liberar la agenda de la reunin que se cancela. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: debe realizarse antes de la fecha de la reunin. Precondicin: La reunin ya ha sido agendada. Recursos: agenda, cronograma de reuniones, espacio fsico, material fsico, listado para convocatoria, medio de comunicacin. Actores: convocante, secretaria, convocados. Episodios: 1. El convocante o la secretaria registran la cancelacin en la agenda. 2. El convocante o la secretaria registran la cancelacin en el cronograma de reuniones. 3. # Si se realiz la convocatoria, la secretaria da el aviso de cancelacin a cada convocado o reemplazante, a travs de algn medio de comunicacin, utilizando el listado para convocatoria. 4. Si se realiz la convocatoria, la secretaria registra el aviso de cancelacin en el listado para convocatoria. 5. La secretaria anula la reserva de espacio fsico. 6. [La secretaria anula la reserva de material fsico.] #
Escenario resultante
Figura 26. Ejemplo de la operacin Consolidar Tener en cuenta las siguientes recomendaciones al aplicar las operaciones:

No crear situaciones artificiales al descomponer. La descomposicin debe aplicarse slo cuando los escenarios resultantes describan mejor el UdeD.
Cuando se aplican las operaciones de composicin, el objetivo del escenario resultante debe extenderse para abarcar la situacin completa, especialmente al fusionar; en el caso de consolidar, el objetivo se extiende por generalizacin. Por el contrario, cuando se aplica descomposicin, el objetivo del nuevo escenario puede ser menos global que el original.
Dado que Consolidar y Dividir son operaciones opuestas, despus de consolidar, el escenario resultante puede ser considerado para una divisin, retornando al estado original y viceversa. Se requieren entonces criterios para decidir la aplicacin de esta operacin. Consolidar debe aplicarse si aparecen pocos episodios condicionales en el escenario resultante, de lo contrario debe evitarse. Por otro lado, Dividir debe elegirse slo si varios episodios con la misma condicin sern afectados por la operacin. Fusionar y Separar son operaciones opuestas tambin; por lo tanto, ambas requieren criterios de decisin sobre la mejor direccin a tomar. La clave es la brecha temporal, tanto respecto a escenarios como episodios. Una demora entre dos episodios puede considerarse como una brecha temporal slo si no puede ser abarcada por el contexto temporal del escenario. La aplicacin de estas dos operaciones es mucho ms sencilla que en las otras pues es ms evidente encontrar una brecha temporal o ms de una ubicacin geogrfica. Las operaciones relativas al aspecto de granularidad tambin requieren criterios de decisin para evitar ciclos infinitos pasando de un estado al opuesto. Aplanar debe aplicarse slo si los episodios una vez aplanados en el escenario resultante tienen el mismo nivel de detalle que el resto de los episodios y si efectivamente el sub-escenario original no representa l mismo una situacin, lo que puede confirmarse por la falta de significado de su objetivo. Por el contrario, Factorizar debe usarse slo si se puede encontrar un objetivo significativo para el nuevo sub-escenario como consecuencia de haber descubierto una situacin especfica y real dentro de un escenario ms abarcador.
(3.2) Definir Relaciones

Es necesario identificar diferentes relaciones entre los escenarios para luego integrarlos. A continuacin se describen los tipos de relaciones que se pueden establecer: relacin jerrquica, relacin de superposicin, relacin de orden (incluye relacin secuencial) y relacin de excepcin.
- 75 -
Relacin de Jerarqua
Se establece entre un escenario y un sub-escenario. Esta relacin ocurre naturalmente mientras se describen los escenarios o cuando se reorganizan. El comportamiento de un escenario se describe a travs de un conjunto de episodios, los cuales pueden ser acciones simples o sub-escenarios; el ltimo caso ocurre cuando la accin es ms compleja o es comn a varios escenarios. Un escenario puede contener ms de un sub-escenario o ninguno. Un subescenario puede ser incluido en uno o ms escenarios y l mismo puede contener sub-escenarios, permitiendo varios niveles de profundidad en la jerarqua. Entonces, se define una jerarqua como un conjunto compuesto por un escenario y sus sub-escenarios, siendo que el escenario raz de la jerarqua no sea a su vez un sub-escenario.
Escenario Raz
Escenario A
Ttulo: Objetivo: Contexto: Recursos: Actores: Episodios:
1. aaaaaaaaaaaaaaaaaaaaaaaaa 2. DDDDDDDDDDDDDDD bbbbbbbbbbbbbbbbbbbbbbb 3. cccccccccccccccccccccccccc 4. DDDDDDDDDDDDDDDDDDDDD SSSSSSSSSSSSSSSS 5. eeeeeeeeeeeeeeeeeeeeeeee 6. FFFFFFFFFFFFFFFFFFFFFFFFF AAAAAAAAAAAAAAAAAAA
..
Escenario D
Ttulo: Objetivo: Contexto: Recursos: Actores: DDDDDDDDDDDDDDDD
..
Su
Es b-
rio na e c
Episodios:
1. uuuuuuuuuuuuuuuuuuuuuu 2. HHHHHHHHHHHHHHHHHH 3. mmmmmmmmmmmmmmm
Excepciones:
..
Su b
-E
Excepciones:
.. XXXXXXXXXXXXXXXXXXX ..
sc en a
Escenario S
rio
1. yyyyyyyyyyyyyyyyyyyyyyyyyy 2. gggggggggggggggggggggggggg 3. wwwwwwwwwwwwwww
SSSSSSSSSSSSSSSSSSSS
..
Excepcin Escenario X
1. iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 2. tttttttttttttttttttttttttttttt 3. KKKKKKKKKKKKKKKKKKKK
XXXXXXXXXXXXXXXXX
..
Excepciones:
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Excepciones:
..
Figura 27. Esquema de Relacin Jerrquica y de Excepcin

En la Figura 27 se presenta una jerarqua compuesta por el escenario raz y dos sub-escenarios. Adems en ella se presenta una relacin de excepcin.
Relacin de Superposicin
Se establece entre escenarios con partes comunes (ver la Figura 28). Esta relacin se observa principalmente cuando varios episodios comunes estn presentes en diferentes escenarios y, por lo tanto, comparten actores y aparecen probablemente recursos comunes.
Escenario A
Ttulo: Objetivo: Contexto: Recursos: Actores: Episodios: yyyyyyyyyyyyyyyyyyyy 1. yyyyyyyyyyyyyyyyyyyyyyyyyy DDDDDDDDDDDDDDD 2. HHHHHHHHHHHHHHHHHH 3. wwwwwwwwwwwwwww mmmmmmmmmmmm 4. mmmmmmmmmmmmmmm ssssssssssssssssssss 5. sssssssssssssssssssssssssssssss 6. xxxxxxxxxxxxxxxxxxxxxxxxx Excepciones:
..
Escenario B
Ttulo: Objetivo: Contexto:
Comparten
AAAAAAAAAAAAAAAAA
..
BBBBBBBBBBBBBBB
Recursos: Actores: Episodios:
AA, BB, AA, BB, CC
AA, AA,BB, BB, DD
Comparten
yyyyyyyyyyyyyyyyyyyyy 1. yyyyyyyyyyyyyyyyyyyyyyyyy DDDDDDDDDDDDDDD 2. HHHHHHHHHHHHHHHHHHH 3. PPPPPPPPPPPPPPPPPPPPPPP mmmmmmmmmmmm 4. mmmmmmmmmmmmm ssssssssssssssssssss 5. ssssssssssssssssssssssssssss 6. . Excepciones:
..
Figura 28. Esquema de Relacin de Superposicin
Relacin de Orden
Se establece entre dos jerarquas cuando una precede a la otra. Una jerarqua que ocurre antes que otras determina una relacin de orden temporal parcial entre ellas. Una jerarqua puede tener cero o ms predecesores y cero o ms sucesores. Una secuencia se establece cuando una jerarqua est inmediatamente precedida por otra. Dado que la segunda puede estar tambin precedida por una tercera, un gran nmero de jerarquas pueden estar involucradas en una secuencia, la cual comienza por lo menos con una jerarqua cabecera. Una secuencia puede tener ms de una jerarqua cabecera y tambin ms de una jerarqua cola. La Figura 29 presenta, arriba, un esquema de orden parcial y orden secuencial y, abajo, una posible secuencia con una jerarqua cabecera y dos jerarquas cola.
- 77 -
SECUENCIA
Jerarqua Cola
Escenario B
Ttulo: Objetivo: Contexto: Recursos: Actores: BBBBBBBBBBBBBBBBBBBB
..
... ...
.. ..
Jerarqua Cabecera
Escenario B
1. 2. 3. 4. 5. 6. yyyyyyyyyyyyyyyyyyyyyyyyyyyy HHHHHHHHHHHHHHHHHHHHH wwwwwwwwwwwwwwwwww . ... ...
Escenario B
Ttulo: Objetivo: BBBBBBBBBBBBBBBBBBBB
..
... ...
BBBBBBBBBBBBBBBBBBBB
..
... ...
.. ..
ORDEN SECUENCIAL
Contexto: Recursos: Actores: Episodios:

1. 2. 3. 4. 5. 6.
.. ..
N L DE CIA R O EN CU SE
SE ORD CU E EN N CI AL
Episodios :
Excepciones:
.. ..
yyyyyyyyyyyyyyyyyyyyyyyyyyyy HHHHHHHHHHHHHHHHHHHHH wwwwwwwwwwwwwwwwww . ... ...
Jerarqua Cola
Escenario B
Ttulo: Objetivo: Contexto: Recursos: Actores: Episodios :
BBBBBBBBBBBBBBBBBBBB
..
... ...
Excepciones:
.. ..
Excepciones:
.. ..
.. ..
Excepciones:
.. ..
Jerarqua A
1. yyyyyyyyyyyyyyyyy 2. HHHHHHHHHHHH 3. wwwwwwwwwww
Jerarqua A
AAAAAAAAAAAAA
..
..
AAAAAAAAAAAAA
..
..
..
..
Excepciones:
..
Excepciones:
..
Escenario B
Ttulo: BBBBBBBBBBBBBBBBBBBB Escenario B Objetivo: .. Ttulo: Escenario B BBBBBBBBBBBBBBBBBBBB Contexto: ... Ttulo: Objetivo: BBBBBBBBBBBBBBBBBBBB ... .. Objetivo: Contexto: Recursos: ... .. ..
ORDEN PARCIAL
Contexto: Actores: ... .. Recursos: ... .. Episodios : Recursos: Actores: .. ..

1. yyyyyyyyyyyyyyyyyyyyyyyyyyyy Actores: Episodios : .. 2. HHHHHHHHHHHHHHHHHHHHH 3. wwwwwwwwwwwwwwwwww Episodios: 1. yyyyyyyyyyyyyyyyyyyyyyyyyyyy 4. . 2. HHHHHHHHHHHHHHHHHHHHH 1. yyyyyyyyyyyyyyyyyyyyyyyyyyyy 5. ... 3. wwwwwwwwwwwwwwwwww 2. HHHHHHHHHHHHHHHHHHHHH 6. ... 4. . 3. wwwwwwwwwwwwwwwwww 5. ... Excepciones: 4. . 6. ... 5. ... .. Excepciones: 6. ... ..
...
ORDEN SECUENCIAL
Excepciones: .. .. .. ..
Jerarqua B
Jerarqua B
BBBBBBBBBBBBB
..
..
BBBBBBBBBBBBB
..
..
..
..
Excepciones:
..
Excepciones:
..
Figura 29. Esquema de Relacin de Orden
Relacin de Excepcin
Se establece entre un escenario y los escenarios que tratan sus excepciones (ver la Figura 27). Cuando un escenario tiene una excepcin, se describe la causa de la misma y puede especificarse un tratamiento de la excepcin a travs de un escenario. Un escenario puede hacer referencia a uno o ms escenarios excepcin. Un mismo escenario excepcin puede tratar
- 78 -
excepciones ocurridas en diferentes escenarios.
(3.3) Integrar Escenarios

Esta actividad consta de cinco pasos (ver la Figura 30). Los primeros cuatro pasos manejan principalmente informacin sintctica, pero en el ltimo se requiere ms un conocimiento semntico. En esta actividad, primero, se agrupan los escenarios en jerarquas y luego stas se agrupan en secuencias. Finalmente, estas secuencias son usadas para construir los escenarios integradores. La integracin utiliza las relaciones de jerarqua, de orden y de excepcin identificadas en el paso anterior.
T itle :
E x c e p tio n s :
LEL
CLIENT-USER
Modelo de Escenario
Heurstica
Escenarios Actuales
que el ingeniero de requisitos realice Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin su trabajo Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su trabajo identificacin de fuentes de cliente-usuario con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice
Construir Jerarquas
Detectar
Orden Parcial
Ttulo:
Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin para con que cuenta el cliente-usuario
que el ingeniero de requisitos realice Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin su trabajo Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su trabajo identificacin de fuentes de cliente-usuario cliente-usuario identificacin de fuentes de Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Recursos: documentacin informacin Cliente-usuario con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice
informacin Contexto: Se efecta en las la dependencias del Debe haberse realizado
Actores:
Actores:
Actores: Ingeniero de requisitos Recursos: documentacin informacin

Cliente-usuario
cliente-usuario identificacin de fuentes de Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de
Construir Secuencias Construir Esqueletos Completar

Componentes
Episodios:Actores: Ingeniero de requisitos Recursos: documentacin 1. El ingeniero de requisitos recibe toda Cliente-usuario
la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 2. 1.
El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el
El ingeniero de requisitos recibe toda
Excepciones:
Excepciones:
evala la con el cliente-usuario 1. El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. documentacin recibida responde a las expectativas.
Excepciones:
la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 2. 1. El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el El ingeniero de requisitos recibe toda
Excepciones:
Excepciones:
evala la con el cliente-usuario 1. El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. documentacin recibida responde a las expectativas.
Excepciones:
Escenarios Actuales Integradores
UdeD
Figura 30. Actividad Integrar en el proceso de EA La Figura 31 muestra dos ejemplos de escenarios integradores extrados de distintos casos. Los escenarios integradores se construyen slo para organizar el conjunto disperso de escenarios. Los componentes Actores y Recursos de estos escenarios permanecen vacos dado que, en general, contendran la lista completa de actores y recursos participantes en todo el conjunto de escenarios.
- 79 -
Sistema de Agenda de Reuniones

Ttulo: ADMINISTRAR LA AGENDA DE REUNIONES Objetivo: Administrar la agenda de reuniones eficiente y efectivamente. Contexto: Ubicacin Geogrfica: -Ubicacin Temporal: -Precondicin: Existe un tema a tratar o resolver por dos o ms personas. Recursos: -Actores: -Episodios: 1. REQUERIR UNA REUNIN. 2. DISEAR LA AGENDA DE REUNIONES. 3. ORGANIZAR LA REUNIN. 4. Si la reunin no se cancel entonces ASISTIR A LA REUNIN. Excepciones:
Sistema Nacional para la obtencin de Pasaportes

Ttulo: SOLICITAR UN NUEVO PASAPORTE. Objetivo: Entregar un pasaporte a un solicitante por primera vez. Contexto: Ubicacin Geogrfica: Divisin Documentos y Certificados, Divisin ndice General, Divisin Dactiloscopa, Divisin Legajos y Antecedentes. Ubicacin Temporal: Precondicin: El solicitante nunca ha pedido un pasaporte. Actores: -Recursos: -Episodios: 1. LLENADO DE FORMULARIO. 2. CONTROL DE DOCUMENTACIN. 3. #SACAR FOTOGRAFA. 4. PAGAR TRMITE. 5. Si el solicitante tiene un nmero de identificacin entonces OBTENCIN DE HUELLAS DIGITALES PARA CONTROL. 6. Si el solicitante no tiene un nmero de identificacin entonces OBTENCIN DE HUELLAS DIGITALES PARA LEGAJO. # 7. DERIVACIN A CABINA DE RECEPCIN. 8. ARMADO DE PASAPORTE ORIGINAL. 9. CONTROL DE PRONTUARIO. 10. CONTROL DACTILOSCPICO. 11. VERIFICACIN FINAL Y CERTIFICACIN DE PASAPORTE. 12. ENTREGA DE PASAPORTE. 13. ENVO DEL LEGAJO DEL SOLICITANTE AL ARCHIVO GENERAL DE LEGAJOS. Excepciones: - El solicitante no retira el pasaporte en el perodo previsto (ENVIO A INCINERACIN DE PASAPORTES NO RETIRADOS). - Un pasaporte es observado (DERIVACIN DE PASAPORTES OBSERVADOS).
Figura 31. Ejemplos de Escenarios Integradores A continuacin se describen los cinco pasos de la actividad de integracin, graficados en la Figura 30.
(3.3.1) Construir Jerarquas de Escenarios

La actividad de integracin aspira a proveer una visin global del UdeD atenuando la importancia y la presencia de detalles. En el conjunto de escenarios a integrar, los sub-escenarios y los escenarios que atienden una excepcin deben ser opacados. Es as que se destacan los escenarios
cabecera constituyendo jerarquas de escenarios donde los sub-escenarios y los escenarios excepcin son absorbidos por los escenarios cabeceras de jerarquas. Una jerarqua es un conjunto de escenarios conectados por una relacin jerrquica. Toda jerarqua tiene un escenario raz o cabecera, el cual no debe estar mencionado como sub-escenario ni escenario excepcin por ningn otro escenario. Una jerarqua se identifica por su escenario raz. Un escenario aislado, aqul que no pertenece a ninguna jerarqua, puede ser en s mismo una jerarqua o puede corresponder al tratamiento de una excepcin de algn escenario de mayor nivel an no identificado. Debe evaluarse a cul de los dos casos incumbe. Si se trata de un escenario excepcin, apartarlo temporalmente para luego adosarlo en el paso (3.3.5) al componente Excepciones del escenario integrador que le corresponda. Adicionalmente, se debe determinar para cada sub-escenario si tiene sentido que ocurra aisladamente de otra situacin, es decir, que el sub-escenario tenga identidad propia como una situacin sin depender de otra ms abarcadora para su realizacin. En caso afirmativo, este sub-escenario debe considerarse tambin como una jerarqua. Para el siguiente paso se requiere construir ciertos componentes de las jerarquas: ttulo, objetivo, precondiciones, recursos y restricciones. En el caso de ttulo y objetivo, stos son directamente aquellos del escenario raz, pero los restantes componentes deben construirse a partir de la jerarqua completa, es decir, incluyendo informacin de los sub-escenarios. Las precondiciones, recursos y restricciones de la jerarqua no se obtienen del escenario raz sino que son parte de la jerarqua completa. Para establecer las precondiciones de una jerarqua, primero se deben unir las precondiciones de todos los escenarios de la jerarqua, y luego se eliminan de la unin las precondiciones requeridas por un sub-escenario pero satisfechas por otro subescenario de la jerarqua. Las restricciones de la jerarqua se obtienen de la misma forma. Los recursos de la jerarqua se determinan como la unin de todos los recursos de los escenarios de la jerarqua, eliminando aquellos
- 81 -
recursos que son a su vez generados por algn sub-escenario. Los episodios de la jerarqua se obtienen por aplanamiento de los episodios de los subescenarios.
(3.3.2) Detectar Orden Parcial entre Jerarquas

Esta actividad se basa en la comparacin entre las precondiciones, recursos o restricciones de una jerarqua, y el ttulo, objetivo o episodios de otra jerarqua. Si una precondicin de una jerarqua identifica un estado inicial que es satisfecho por otra jerarqua, entonces existe un orden parcial entre ambas jerarquas. Lo mismo puede ocurrir con un recurso requerido en una jerarqua y que es producido por otra jerarqua. Adems, las restricciones de los episodios pueden ser satisfechas por otra jerarqua, por lo tanto, se establece un orden parcial. Estas restricciones pueden usarse en la comparacin cuando se refieren a estados de los recursos o ciertas condiciones que deben resolverse previamente. La comparacin entre dos jerarquas termina cuando se detecta un orden parcial o la imposibilidad de lograrlo. Si el orden parcial entre dos jerarquas se establece slo bajo cierta condicin, la relacin se etiqueta con esta condicin. Para reducir la bsqueda de rdenes parciales, es mejor chequear primero contra el ttulo y el objetivo, y luego contra los episodios de ser necesario. Si una comparacin es exitosa, un orden parcial es encontrado, y se pasa a la comparacin con las restantes jerarquas. Si ninguna comparacin fue exitosa, entonces no hay orden parcial entre ambas jerarquas, continuando con las siguientes jerarquas. Las comparaciones usadas en este paso son en el siguiente orden: 1. Precondicin de una jerarqua contra el ttulo de la otra jerarqua. 2. Recursos de una jerarqua contra el ttulo de la otra jerarqua. 3. Restricciones de una jerarqua contra el ttulo de la otra jerarqua. 4. Precondicin de una jerarqua contra el objetivo de la otra jerarqua. 5. Recursos de una jerarqua contra el objetivo de la otra jerarqua. 6. Restricciones de una jerarqua contra el objetivo de la otra jerarqua. 7. Precondicin de una jerarqua contra los episodios de la otra
- 82 -
jerarqua. 8. Recursos de una jerarqua contra los episodios de la otra jerarqua. 9. Restricciones de una jerarqua contra los episodios de la otra jerarqua. Cuando el orden parcial se establece utilizando los episodios en la comparacin, se debe evaluar si la precedencia corresponde a todo el conjunto de episodios de la jerarqua o slo a partir del episodio donde se satisfizo la comparacin. En este ltimo caso, considerar si no debiera aplicarse la operacin Separar sobre el escenario al que pertenece este episodio, y luego re-armar la jerarqua y re-evaluar el orden parcial.
(3.3.3) Construir Secuencias de Jerarquas

Esta actividad comienza con la revisin de las relaciones de orden parcial detectadas entre las jerarquas, con el fin de clarificar cul es el conjunto de jerarquas que inmediatamente preceden a otra. Primero, se eliminan todos los rdenes parciales derivados por transitividad. Se dice que existe transitividad entre las jerarquas A, B y C, si A y B preceden a C pero adems A precede a B, ver la Figura 32. Las transitividades no son fciles de eliminar. Sin embargo, stas pueden eliminarse agrupando todas las relaciones de orden parcial con la misma jerarqua a la izquierda de la relacin. Cualquier orden parcial adicional entre las jerarquas sobre la parte derecha de la relacin se usa para identificar una transitividad. Nueva informacin proveniente del UdeD puede ser elicitada cuando se detectan brechas temporales entre las jerarquas. Esto sucede cuando dos jerarquas en secuencia no coinciden apropiadamente, debido a que, a una o a ambas jerarquas les faltan algunas acciones que realmente se ejecutan en el UdeD. Las jerarquas aisladas son secuencias en s mismas.
- 83 -
rdenes Parciales AC BC
Secuencia
A C B
rdenes Parciales AB AC BC A
Secuencia B C
Se elimina relacin A C por transitividad rdenes Parciales A Secuencia B c C
AB A C con condicin c BC
No se elimina relacin A C por la condicin Figura 32. Ejemplos de Construccin de Secuencias
(3.3.4) Construir Esqueletos Integradores

En este paso slo se construye el componente Episodios de los escenarios integradores. Primero se construye un escenario principal (el de ms alto nivel) y luego se pueden obtener niveles intermedios de escenarios integradores. Se le asigna un identificador a cada secuencia obtenida en el paso anterior. Cada secuencia ser un episodio del escenario integrador principal, pero no tiene establecida un orden de precedencia respecto a las restantes. Luego, todas las secuencias, a travs de su identificador, se incorporan al componente Episodios del escenario integrador principal marcando con indicadores de nosecuencia (#) al principio y al fin del conjunto de episodios.
- 84 -
Si una secuencia representa una jerarqua sola, entonces el identificador de la secuencia se reemplaza por el ttulo del escenario raz de la jerarqua. Si una secuencia est compuesta por ms de una jerarqua, se crea un escenario integrador de nivel intermedio, adosando el identificador al ttulo y las jerarquas de la secuencia pasan a formar parte del componente Episodios del escenario integrador intermedio, considerando sus precedencias o no secuencias. Esto se aplica cada vez que se detectan sub-secuencias dentro de grupos no secuenciales.
(3.3.5) Completar Componentes de Escenarios Integradores

En este paso es frecuente agregar nueva informacin semntica. Se analizan los episodios de los escenarios integradores para completar los restantes componentes, comenzando por los escenarios integradores de menor nivel, para ir propagando sus ttulos a los nombres usados en los episodios de mayor nivel. Este paso acta como una clase de verificacin final. El ttulo y el objetivo deben escribirse preservando cohesin, es decir, sin usar conjunciones en las acciones. Se escribe el contexto en funcin de los episodios involucrados; la precondicin correspondera a la precondicin del primer episodio. Las descripciones deben ser escritas utilizando los smbolos del LEL. Volver a cuestionarse qu podra fallar en cada episodio que ahora es un escenario, para detectar causas de excepciones. Si se haban apartado escenarios excepcin, vincularlos al escenario integrador correspondiente. Tener en cuenta la precondicin del escenario excepcin, sta podra ser la causa de la excepcin. Tambin buscar en los episodios que son escenarios, si stos a su vez tienen escenarios que atienden excepciones pero que no cumplen con el objetivo del escenario episodio. Si esto ocurre entonces en los episodios secuenciales siguientes encontrada.
del
escenario
integrador
todos
los
episodios
deben
ser
condicionales, siendo la condicin la negacin de la causa de la excepcin
Si alguna Ficha de Informacin Anticipada qued con informacin no utilizada, revisarla para determinar si dicha informacin puede volcarse en algn escenario integrador, como por ejemplo algn RNF con un mbito ms amplio que una situacin real ya descripta.
(4) Verificar
Esta actividad se realiza por lo menos dos veces durante el proceso de construccin de escenarios, la primera vez sobre el conjunto de escenarios completamente descriptos generados en la actividad Describir y la segunda despus de la actividad Organizar. Se heursticas de verificacin. Como consecuencia de esta actividad, se genera una lista de DEOs para modificar los escenarios en la actividad Describir. La verificacin se divide en dos pasos: Verificacin Intra-Escenarios y Verificacin Inter-Escenarios. La primera consiste en realizar una consistencia interna de cada escenario, contrastando sus distintos componentes. La segunda se ocupa de realizar una consistencia entre los escenarios, analizando la integridad del conjunto de escenarios producido. Es importante enfatizar que el proceso de verificacin est dirigido por controles sintcticos, referencias cruzadas con el LEL, el modelo de Escenarios y por una gua de control. A continuacin se detallan los tipos de consistencia interna y entre escenarios que se deben realizar. realiza siguiendo una gua con
Verificacin Intra-Escenario
Verificar la sintaxis

Controlar la completitud de cada componente. Controlar la existencia de ms de un episodio por escenario. Controlar la sintaxis de cada componente segn se establece en el modelo de Escenario.
Verificar la relacin entre componentes

Controlar que todo actor participe en al menos un episodio. Controlar que todo actor mencionado en loa episodios sea incluido en
- 86 -
el componente actores.

Controlar que todo recurso sea usado en al menos un episodio. Controlar que todo recurso mencionado en los episodios sea incluido en el componente recursos.
Verificar la semntica

Controlar la coherencia entre el ttulo y el objetivo. Asegurar que el conjunto de episodios satisfaga el objetivo y est dentro del contexto. Asegurar que las acciones presentes en las precondiciones ya han sido satisfechas. Asegurar que los episodios contengan solamente acciones a ser realizadas. Asegurar el mismo nivel de detalle en la descripcin del escenario. Controlar que todo smbolo del LEL es identificado al mencionarse en un escenario. Controlar el uso correcto de smbolos del LEL.
Verificacin de interrelacin con el LEL

Verificacin Inter-Escenario
Verificar la existencia de sub-escenarios
Controlar que cada episodio identificado como un sub-escenario exista dentro del conjunto de escenarios. Controlar que episodios del sub-escenario no estn incluidos en el componente Episodios del escenario. Controlar que toda excepcin sea tratada por un escenario que existe o mediante alguna accin simple.
Verificar el contexto
Controlar que toda precondicin sea un hecho incontrolable (externo) o satisfecho por otro escenario. Controlar la coherencia entre las precondiciones de los subescenarios y las de los escenarios correspondientes. Controlar que la ubicacin geogrfica y temporal de los subescenarios sea coherente con la de los escenarios que los contienen.
Verificar la equivalencia en el conjunto de escenarios
- 87 -
Controlar que la coincidencia de objetivos tenga lugar solo en situaciones diferentes. Controlar que la coincidencia de episodios tenga lugar solo en situaciones diferentes. Controlar que la coincidencia de contextos tenga lugar solo en situaciones diferentes.
Verificacin de cubrimiento del LEL

Controlar que los actores sean preferentemente smbolos del tipo Sujeto. Controlar que los recursos sean preferentemente smbolos del tipo Objeto. Controlar que los escenarios cubran todos los impactos de los smbolos Sujeto del LEL. Controlar smbolos del LEL no utilizados en ningn escenario.
Usando las listas de verificacin de DEOs, se modifican los escenarios y el LEL. Si se necesitan realizar correcciones mayores, entonces puede requerirse una nueva verificacin. Cuando el ciclo Describir-Verificar termina, la actividad Organizar puede proveer un conjunto ms grande de escenarios, los cuales a su vez deberan ser verificados, comenzando un posible ciclo DescribirOrganizar-Verificar. Aunque la verificacin de los EA puede realizarse siguiendo diversas tcnicas, se recomienda un proceso de inspeccin [Leite 05], basado en la propuesta original de Fagan [Fagan 76], pero utilizando una tcnica de lectura durante la preparacin adaptada de la propuesta de Porter [Porter 95] y ajustada al modelo de Escenario.
(5) Validar
Los escenarios son validados con los usuarios, generalmente realizando entrevistas estructuradas o reuniones. Durante la validacin, debe considerarse especialmente el componente Dudas de aquellos escenarios que lo presenten. Este componente del escenario pudo agregarse durante la actividad Describir y se debe eliminar durante la validacin.
Esta actividad se facilita pues los escenarios son escritos en lenguaje natural, empleando el vocabulario propio de los usuarios y describiendo una situacin especfica bien limitada en la que los propios usuarios estn involucrados. La actividad de validacin se realiza para detectar DEOs en los escenarios, pero tambin es posible detectar algn defecto en el LEL, aunque con mucha menor frecuencia. Los errores son detectados principalmente leyendo cada escenario al usuario, algunas omisiones aparecen durante la lectura pero otras surgen preguntando sobre la falta de informacin o de detalles en el escenario. Las discrepancias pueden aparecer durante las reuniones cuando existen diferencias entre los usuarios o cuando se analiza la informacin obtenida. La estrategia a seguir es:

Identificar los clientes y usuarios con los escenarios a validar. Durante la reunin: o Leer en voz alta los escenarios junto con los clientes y usuarios. o Preguntar el porqu. o Solicitar paso a paso confirmacin de cada componente del escenario. o Marcar cada escenario donde se present una duda para su futuro estudio. Confeccionar la lista de DEOs detectados.
Existen otras tcnicas para validar escenarios, tales como:

Ejercicios de Role playing con los participantes Ejemplificando situaciones concretas Proveyendo animacin por medio de representaciones pictricas Simulando el comportamiento de los episodios mediante ambientes orientados a mquinas de estado
El principal objetivo de la validacin es confirmar la informacin elicitada y detectar DEOs; sin embargo, un efecto colateral de este proceso es elicitar nueva informacin. La validacin de un conjunto de escenarios, despus del proceso de verificacin, permite confirmar que las situaciones del UdeD acontecen, y que han sido registradas con la percepcin de los actores del UdeD a cargo de la lectura y discusin de los escenarios.
7. Definicin del Contexto del Software

Las situaciones observadas son la base para el conocimiento del problema y las situaciones deseadas son el bosquejo para establecer los requisitos. Por lo tanto, los escenarios futuros (EF) son aquellos que modelan las situaciones proyectadas como solucin a los problemas, demandas y necesidades planteadas en el UdeD y de acuerdo a los objetivos propuestos para el sistema [Doorn 02]. Estos escenarios futuros incorporan naturalmente los requisitos del software en sus descripciones, siendo la mayor parte de los mismos requisitos funcionales.
7.1. Objetivos y Requisitos del Sistema

Los ingenieros de requisitos presentan habitualmente ms de una visin del futuro, proponiendo soluciones alternativas mediante distintos conjuntos de escenarios futuros (o soluciones alternativas parciales para una o ms situaciones futuras). Este proceso no slo involucra la captura de requisitos directamente de las fuentes de informacin, sino que requiere una tarea extra altamente creativa de los ingenieros de requisitos. Los escenarios actuales pueden presentar ya algunos requisitos del software. En la mayora de las organizaciones existe algn sistema de software de mayor o menor envergadura (desde un sofisticado paquete de software integrado hasta un simple conjunto de planillas de clculo), por lo tanto, muchos de los requisitos cumplidos por los escenarios actuales sern trasladados inalterados al nuevo sistema de software o, en algunos casos, adaptados o re-creados. Los escenarios futuros naturalmente reflejarn estos requisitos existentes e incorporarn nuevos requisitos elicitados, propuestos y/o negociados durante el proceso de proyeccin de cmo cambiar el UdeD. Este proceso de proyeccin corresponde a la cuarta etapa de la estrategia: Definir el contexto del software. Dado que algunos requisitos del software ya existen actualmente, o ciertos comportamientos del UdeD no se alterarn en el futuro, entonces algunos EA
- 90 -
pasarn a convertirse directamente en EF y otros sufrirn alteraciones menores. Es decir, se podr presentar una correlacin 1 a 1 entre algunos EA y algunos EF. En cambio, muchos otros EA sern reemplazados radicalmente y otros directamente desaparecern. El grado de mejoras a implementar en los procesos del negocio es sumamente importante debido a que en situaciones de baja reingeniera, el espacio para que el ingeniero de requisitos pueda hacer propuestas es reducido, ya que se desea introducir un sistema de software en una organizacin preservando los procesos actuales del negocio en gran medida. Por el contrario, si el sistema de software es concebido como una herramienta para modificar de alguna manera los procesos del negocio, entonces habr en el futuro una cantidad significativa de actividades que diferirn de las actuales. Es en este caso donde surgen espontneamente una gran cantidad de propuestas por parte del ingeniero de requisitos. Los requisitos del software son dependientes de los objetivos fijados para el sistema de software. Dichos objetivos son definidos en una etapa preliminar del proyecto. En algunos casos pueden ser vagos e imprecisos, pero a medida que el proyecto avanza y se tiene una mejor comprensin del UdeD estos objetivos deben definirse con mayor claridad. La precisin de los objetivos va acompaada en consecuencia de un ajuste en el alcance del sistema. Este ajuste puede corresponder simplemente a una definicin ms precisa de los lmites del sistema o inclusive a una ampliacin o reduccin de stos. Esta evolucin que sufren tambin los objetivos del sistema no slo obedece a una mejor comprensin de las necesidades del UdeD sino, entre otros, a cambios en la organizacin o en las polticas internas o externas (por ejemplo, un recorte presupuestario). En general los objetivos del sistema de software son ms estables (a largo plazo) y abstractos mientras que los requisitos son ms voltiles y ms dependientes del contexto. Cambiar un objetivo puede implicar cambiar la naturaleza misma del sistema. Cambiar un requisito puede implicar un cambio en la operacionalizacin de un objetivo [Finkelstein 01]. En la etapa preliminar del proyecto se tiene una definicin inicial de los
objetivos del sistema de software y su refinamiento ocurre en una modalidad bottom-up, teniendo en cuenta que dichos objetivos preliminares sirven como marco de referencia para crear los escenarios futuros (ver la Figura 33). Por lo tanto, el proceso se centra en situaciones guiado por los objetivos preliminares del software, los cuales quedan definidos con precisin una vez finalizado el proceso de construccin de los EF.
Describir situaciones observadas
marco
Definir Objetivos Generales del Sistema
Objetivos concretos
Evolucin marco
Describir situaciones proyectadas
Objetivos concretos
Refinamiento Figura 33. Evolucin proyectada de Escenarios Actuales a Escenarios Futuros en el marco de los Objetivos Como se observa en la Figura 33, se distinguen dos tipos de objetivos: los objetivos generales del sistema y los objetivos concretos para cada servicio del software, ya sea el software actual o futuro. Estos objetivos concretos responden a los procesos del negocio, pues los escenarios estn describiendo situaciones en el contexto organizacional. Adems, se debe distinguir entre los objetivos del negocio y los objetivos del software, estos ltimos no pueden estar en conflicto con los primeros, pero en algunos casos pueden llegar a alterar sutilmente los objetivos del negocio. Esto depender exclusivamente de la aceptacin de los clientes. Los objetivos del negocio a veces no estn explcitos, pudiendo permanecer ocultos a los desarrolladores y recin aflorar cuando los objetivos expresados del sistema de software entran en conflicto con ellos.
- 92 -
Automatizar el trfico de registros de recargas de celulares entre el sistema de recargas y el sistema de comisiones
Mejorar el tiempo de procesamiento de registros de recarga
Facilitar la compatibilidad y comunicacin entre ambos sistemas
Proveer seguridad en el manejo de transacciones
Asignar comisiones a operadores de ventas
Automatizar la vigencia de los archivos
Conservar histricos de las recargas
Realizar estadsticas y auditoras
Figura 34. Objetivos del Sistema de Gestin de Registros de Recarga de Celulares

Evitar el incremento de la deuda del cliente
Mantener el contacto con el cliente
Evitar la prescripcin de la garanta
Acordar facilidades de pago
Mantener el contacto con el empleador
Iniciar acciones judiciales a tiempo
Otorgar esperas en el cobro de cuotas
Notificar al cliente de su deuda
Decidir el Protesto de pagar
Formalizar arreglos extrajudiciales
Intimar judicialmente al cliente
Figura 35. Objetivos del Sistema de Seguimiento de Cartera Morosa En general se describe un objetivo general del sistema y varios objetivos especficos que deben satisfacer al objetivo general, estableciendo una relacin jerrquica entre los objetivos. La Figura 34 muestra los objetivos y subEstrategia en la Ingeniera de Requisitos Hadad GDS - 93 -
objetivos para un sistema de gestin de registros de recarga de celulares, mientras que la Figura 35 muestra un rbol de objetivos en tres niveles correspondiente a un sistema de seguimiento de cartera morosa.
7.2. Proceso de Construccin de Escenarios Futuros

La primera pregunta que debe contestarse antes de decidir cualquier accin relativa a los EF es: Qu grado de Reingeniera de los Procesos del Negocio se espera? Cuando el proyecto de software est envuelto en una reingeniera del negocio importante, siendo el sistema un factor clave del proyecto, se espera que muchas situaciones actuales se modifiquen durante la implantacin del artefacto de software. Como consecuencia tambin se espera que los EF tengan poco apareo con los EA. En el otro extremo, existen algunos proyectos de software que tienen el compromiso de mantener el proceso del negocio tan inalterado como sea posible. Esto puede deberse a varias razones, tales como regulaciones gubernamentales, polticas de la casa matriz, estndares industriales o meramente para preservar una forma exitosa de llevar el negocio. Se espera entonces que haya muchos apareos entre los EA y los EF. Los EF de proyectos de software inmersos en un nivel alto de cambios en el proceso del negocio deben construirse en un modo orientado a los objetivos, prestando menos atencin a los aspectos procedurales actuales. Por el contrario, proyectos de software con un marco de trabajo de baja reingeniera de los procesos del negocio deben construir sus EF usando un enfoque dirigido por consideraciones procedurales. Sin embargo, muchos proyectos de software se ubican entre ambos extremos. Para ellos, es necesario combinar ambos enfoques segn sus caractersticas. El proceso de construccin de los EF es similar en ciertos aspectos al proceso de construccin de los EA. La Figura 36 muestra el proceso de construccin de
los EF, donde las actividades operativas son tres: Seleccionar la estrategia constructiva, Describir los escenarios futuros y Organizar los mismos, mientras que las actividades de anlisis corresponden a: Verificar y Validar. Algunas actividades particulares se manifiestan utilizando las mismas heursticas y siguiendo procedimientos similares a la construccin de EA. Los productos de esta etapa son un conjunto de escenarios futuros y los objetivos del software refinados.
T it le :
FICHA DE REQUISITO CANDIDATO ESPONTANEO FICHA DE REQUISITO CANDIDATO Proyecto: ____________________ ESPONTANEO Fecha: __/__/____ FICHA DE REQUISITO CANDIDATO Ingeniero de Requisitos: ________ Proyecto: ____________________ ESPONTANEO Fecha: __/__/____ Ingeniero de Requisitos: ________ Proyecto: ____________________ Descripcin:___________________ Fecha: __/__/____ ______________________________ Ingeniero de Requisitos: ________ ______________________________ Descripcin:___________________ Prioridad: Obligatorio Deseado ______________________________ ______________________________ Descripcin:___________________ Tipo: Prioridad: : ____________ RF RNF ______________________________ Obligatorio Deseado Fuente de Informacin: ____________ ______________________________ Etapa Tipo: del Proyecto: _______________ : ____________ Prioridad: RF RNF Obligatorio Deseado Observacin: ____________________ Fuente de Informacin: ____________ Etapa Tipo: del Proyecto: RF_______________ RNF: ____________ Observacin: ____________________ Fuente de Informacin: ____________ Etapa del Proyecto: _______________ Observacin: ____________________
CLIENT-USER
Notion: CLIENT-USER - Person or group of persons, belonging to UofD, who Notion: CLIENT-USER interacts with the requirements engineer - Person or group of persons, belonging to UofD, who Notion: Behavioral Response: interacts with the requirements engineer - Person or group of persons, belonging toin UofD, who - He supplies the documentation or he participates Behavioral Response: interacts with the requirements engineer the interviews - He supplies the documentation or he participates in - He participates Behavioral in the Response: LEL validation the interviews - He participates in the the scenarios validation - He supplies documentation or he participates in - He participates in the LEL validation the interviews - He participates in the scenarios validation - He participates in the LEL validation - He participates in the scenarios validation
T e m p o r a l L o c a tio n : G e o g r a p h ic a l L o c a tio n : P r e c o n d i t io n s :
Escenarios Actuales
T tu lo : O b te n er la d o cu m e n tac i n O b jetiv o : O bt e n er to d a la in fo rm a c i n e s crita T tu lo co : n que Ocb la o -u cu m e np tac u te e nn taer el c lied n te su a rio a ra i n q uo e :e l in g e n ie roto d eare qu is ito s are a lic O b jetiv la in fo rm c i n e s crita T tu loO : bt e n er O bd te n er la do cu m e n tac i n be jetiv O bt an la in fo rm c i n e s crita q uo e :e en l in g ee n ie ro dd e re u is ito re a lic C o n tex to : O Se fe ct a la s dn eer p eto nd e cq ia s d e ls a
De b e: hS ab rs e rea aliza o C o n tex to ee e fe ct en d la s la d e p e nd e n c ia s d e l su t ra b a jo id en t ific ac i n -u de fu n te s d e clie n te su ae rio su t ra b a jo co n q u e c u e n ta e l c lie n te -u s u a rio p a ra co su t ra ba jon q u e c u e n ta e l c lie n te -u s u a rio p a ra clie n te -u su a rio q u e e l in g e n ie ro d e re q u is ito s re a lic e in o fon rm aD ce i ne: hS C tex to e ee fe en d la d e p e nd e n c ia s d e l b ab rs ect rea aliza os la
E x c e p tio n s :
Heursticas
LEL
Modelo de Escenario

T tu lo : O b te n er la d o cu m e n tac i n O b jetiv o : O bt e n er to d a la in fo rm a c i n e s crita T tu lo co : n que Oc b rl c la o -u cu m enp tac uten e n taee lied n te su a rio a rai n q uo e :e l in g e n ie ro d eare u is ito sare a lic e c rita O b je tiv r to laq in fo rm c i n m es T tu lo O : b te n eO bd te n er la do cu e n tac i n be jetiv O bt are in fo c i n e s crita q uo e g ee n ie ro dd ee u isito re a lic C o n tex to : O Se fe ct a :el e nin la s dn eer p eto nd nla cq ia s drm es la
ebe abe rea aliza C o n teD xto : hSe ers fee c t en d lao s la d e p e n d e n cia s d e l su t ra b a jo id en t ific ac ite n -u de fu n te s d e clien su ae rio clie n te -u su ae rio id e n c i nito ds e fu n te s d e In g e n iero dtifica e re qu is eb rm aD ci ne h a b e rs e re aliza d o la C lie n te in -ufo su a rio id en t ific ac i n d e fu e n te s d e A cto res : me In ec nie ro d e re q u isito s R ec u rs os: d o cu ng ta iin n fo rm a c i n C lie n te -u s u a rio su t ra b co a jo n q u e c ue n ta e l c lie n te -u su a rio p a ra co su tra ba jon q u e c u e n ta e l c lie n te -u s u a rio p a ra clie n te -u su a rio q u e e l in g e n ie ro d e re q u is ito s re a lic e
A cto re s:
A cto s: In ec ni iero d e re qu is ito s R ec u rs o s :re do cu m e ng ta n in fo rm a c i n

C lie n te -u su a rio
clie n te -u su ae rio id en ific ac i n ds e fu n te s d e In g e n iero dt e re qu is ito eb in fo rm aD c i ne h a b e rs e re aliza d o la C lie n te -u su a rio id en t ific ac i n d e fu e n te s d e
E p is o d io s :A cto re s: In g e n iero d e re qu is ito s R d ie o cu n ta cu i nito s re cib e to d a 1 . ec u rs Elo ins g: en ro m de e is C req lie n te -u su a rio
la d os cu m e n ta c i n c o n q u e cu e n ta e l E p is oR dec io u:rs o s : d o cu m e n ta c i n 2. El ge ie ro d u is ito n to E pin is on d io :e la d os cu mreq e n ta c i ns ce on nc qo un ejucu e n ta e l clie ua 1 . n te -u Es l in grio e n.ie ro d e req u is ito s re cib e to d a
E x ce p cio n e s :
co n e l c lie a rio a l lau is ito s re cib e to d a 1 . n Esu lu in g e n.ev ie ro da e si req clie nte te-u -u s a rio d.o cu m e n re c cu ib id sis p on dc e a la d o ma e re n ta c i ns on nc q u e e n ta e l 2 En l ta inc gi en ie ro de req u ito e o n jucu n to la s e x pco e cta tiva s. n clie nte te-u -usu s ua ario rio .ev a l a si la n e lc lie 2 En l ta inc gi e n ie ro d id ea req ito en d.o cu m e re c ib reu sis po ns de a c o n ju n to n e l cs lie la s e x p co e cta tiva . n te -u su a rio ev a l a si la E x ce p cio n e s : d o cu m e n ta c i n re c ib id a re s p o n d e a la s e x p e cta tiva s .
ino fon rm a ce i n C tex to e erse e fe ct en la s la d e p e nd e n c ia s d e l D b e: hS ab rea a liz ad o
A cto re s:
Objetivos Preliminares del Sistema

Verificar Seleccionar Describir Organizar
E p is o d io s :A cto re s: In g e n iero d e re qu is ito s R s: d ie o cu nreq ta ci nito s re cib e to d a 1 .ec u rs E lo in gen rom de e is C lie nu te -u su a rio
la d os: cu m e n ta c i n c o n q u e cu e n ta e l E p isoR dec io u rs o s : d o cu m e n ta c i n 2.
Ep l in go en ro u is ito en E is die io :e la d os cd u mreq e n ta ci nsco nc qo un eju cn uto en ta el
clie ua rio 1 . n te -u Elsin ge n.ie ro d e re q u is ito s re cib e to d a co n e l 1 c lie a rio ev a l lau is ito s re cib e to d a . n te E su l in g e n.ie ro da e si req clien te-u -u su a rio d.o cu m e n ta in nie re ccu ib id a re sis pi on dc e a la d o mre en c ns on nc q u e e n ta e l 2 El inc ge ro de qta u ito e o n jucu n to la s e x pco e cta tiva s. n clie nte te-u -usu s ua ario rio .e va l a si la n e l clie 2 En l ta inci g e n ie ro ib de req is o ito en d.o cu m e rec id a reu sp ns de a c o n ju n to la c lie la s e xp co e cn tae tiv s . n te -u su a rio ev a l a si la d o cu m e n ta c i n re c ib id a re s p o n d e a la s e x p e cta tiva s .
E x cep cio n e s :
Escenarios Futuros
Validar
F I C H A D E R E Q U I S I T O C A N D ID A T O E S PO N T AN E O F I C H A D E R E Q U I SI T O C A N D ID A T O P ro y ec :O _N __ _N _E __ _ ___ ___ ___ __ Eto SP T_ A O F e c h a : _ _ /__ /_ _A _ D E R E Q U I S I T O C A N D ID A T O FI C_ H I n g en ie ro yd R u_ is ito s: _ P ro ee c :eq _ _ _ _N _E __ _ ____ __ ____ __ _ ___ __ Eto SP O N T A O F e c h a : _ _ /_ _ /_ _ _ _ I n g e n ie e to R: eq_ u_ is P ro yd ec _ito _ _s _:__ __ __ __ __ __ __ __ _ ___ __ D e s c rip c i nF :_ ___/__ _ _ __ __ __ __ ___ e_ c_ h_ a_ : __ /_ _ _ _ _ _ _ _ _ _ _ _I_ __ _ro _ _d _e __ __ _ito _ _s: _ __ _ _ _ _ _ _ _ n_ g_ en ie R_eq u_ is _ _ _ _ _D __ _c _r_ _c __ _ ___ ___ ___ ___ ___ ___ es ip i__ n :_ P r io r id O D ea d_ o_ _ _ _ _ ad _ _:_ _ _ _b _lig _ _a _to _ _rio ___ ___ _ _es __ __ _ _ _ _ _D __ _c _rip _ _c _ i __ _ ___ ___ ___ _ __ _ _ _ _ _ _ es n_:_ __ T ip o : P r io r id R N F :_ _a __ _ _ __ __ __ __ _ _e ad O r__ io__ D ea d_ o_ _ _ _ _F _ _:_ R __ _b _lig _ _to _ _ _s_ __ F u en te d e In_fo rm a_ c_ i __ __ _n _:__ ___ __ __ ___ __ __ __ __ __ __ _ ___ ___ __ E tap a T d ip e l oP: ro y e c to : _ _ _ __ _ _ _ _ _ _ _ P r io r id ad : R O rio RF Nb Flig : _a _to __ __ __ __ _ __D _ _es ea d o O b s erv ite n : d_e_ In _ _fo __ __a__ _n _:_ _ _ __ __ _ __ __ _ _ _ _ _ F ac u en rm c i E ta p a T d ip elo P:ro y e c to : ___ __ RF R_ N F_ :_ __ __ __ __ __ __ __ _ ___ _ O b serv ite n :d _e _ In _ _fo __ _ _a_ _n _:_ _ __ _ _ __ _ __ __ __ _ _ _ _ Fa uc en rm c_ i E tap a d e l P ro y e c to : _ _ _ __ _ _ _ _ _ _ _ _ _ _ O b s erv ac i n : _ _ _ _ _ _ __ __ _ _ _ _ _ _ _ _ _ _
UdeD
Figura 36. Proceso de construccin de Escenarios Futuros La actividad Describir se basa en estrategias constructivas de EF consecuentes al grado de reingeniera de procesos requerido, pero aplica las mismas heursticas de descripcin empleadas para construir los EA con adaptaciones menores. Las actividades Organizar y Verificar son casi idnticas a las actividades homnimas del proceso de construccin de escenarios actuales, excepto la verificacin sobre el cubrimiento del LEL, que no se realiza, y el refinamiento de los objetivos del sistema, que es una nueva tarea dentro de organizar. En el caso de Validar se recomiendan otras tcnicas: la prototipacin o el uso de storyboards. Una vez construidos el LEL y el conjunto de EA, los ingenieros de requisitos cuentan con conocimiento suficiente para comprender el UdeD. Sobre esta base y en funcin de los objetivos del sistema, comienza la etapa de definicin
- 95 -
del contexto del sistema de software. Segn las caractersticas del sistema y el grado de reingeniera de procesos se aplicarn diferentes enfoques para construir los EF. Durante este proceso, se debe comprender lo que los clientes y los usuarios necesitan y desean para el nuevo software. Por otro lado, se realizan actividades paralelas, como generar propuestas de requisitos, analizar requisitos candidatos elicitados en etapas previas, negociar requisitos y generar soluciones alternativas. Despus de describir los EF, stos son verificados, corregidos de ser necesario, y luego, organizados. A partir de esta ltima actividad, se obtienen los escenarios futuros integradores, que dan una visin global del sistema de software y su contexto. Con los escenarios futuros y los escenarios futuros integradores se construye un prototipo o storyboards, que se utilizan para validar dicho conjunto de escenarios.

A continuacin se detallan las actividades graficadas en la Figura 36, que son 1) Seleccionar, 2) Describir, 3) Organizar, 4) Verificar y 5) Validar.
(1) Seleccionar la Estrategia

El objetivo de esta actividad es seleccionar la estrategia de construccin de los EF. Para ello, se revisan y precisan los objetivos del sistema y se determina el grado de reingeniera de procesos esperado. En base a ello, se opta por un enfoque orientado a los procedimientos, un enfoque dirigido por objetivos o un enfoque hbrido. Dado el conocimiento adquirido por los ingenieros de requisitos, stos pueden junto con los clientes y ciertos usuarios de niveles gerenciales mejorar los objetivos del sistema bosquejados durante el planeamiento del proyecto. El grado de mejoras a implementar puede evidenciarse en los objetivos del
- 96 -
sistema, aunque es una informacin que concierne a los objetivos del negocio y deben ser planteados por los clientes. Es decir, en este paso hay una actividad de elicitacin que bsicamente utiliza la tcnica de reuniones.
(2) Describir
El objetivo de esta actividad es elicitar y modelar conocimiento sobre las necesidades, demandas, deseos de los clientes y usuarios para el nuevo sistema de software, y/o sobre los problemas, oportunidades y normas no cumplimentadas que se detectan actualmente para solucionar en el futuro. En esta actividad, se realiza la descripcin de los EF siguiendo la estrategia seleccionada en el paso previo (se detalla en la sub-seccin siguiente), utilizando como informacin: los objetivos del sistema de software, los EA, las Fichas de Informacin Anticipada y la nueva informacin elicitada sobre el futuro, escribindolos haciendo uso del LEL. Durante el modelado de los EF, se realizan varias actividades en paralelo: Evaluar los requisitos candidatos que figuran en las Fichas de Informacin Anticipada para determinar su incorporacin a los EF. Estos requerimientos o requisitos potenciales se capturaron en etapas previas (durante la Comprensin del Vocabulario del UdeD y la Comprensin del UdeD Actual) y se registraron individualmente en fichas especficas para tal fin. La informacin volcada en estas fichas ser incompleta, parcial, no verificada, respondiendo posiblemente al punto de vista o intereses de ciertos clientes o usuarios. Es por ello, que en esta etapa, dicha informacin debe ser evaluada y chequeada para determinar su relevancia y oportunidad frente a los objetivos del software y en funcin del conocimiento adquirido del negocio. Elicitar informacin sobre lo futuro: necesidades, deseos y dificultades actuales de los clientes y usuarios. Se utiliza como principales tcnicas de elicitacin: entrevistas estructuradas, cuestionarios y lectura de documentacin. Las preguntas bsicas se pueden resumir en: Qu espera? Por qu?
- 97 -
Qu necesita? Por qu? Qu deseara? Por qu? Qu problemas / dificultades advierte? Esta informacin elicitada puede volcarse en las Fichas de Informacin Anticipada para tener la informacin ms organizada y facilitar su uso, o puede modelarse directamente en los EF. Elaborar propuestas de requisitos que los ingenieros de requisitos presentan a los clientes y usuarios. Dependiendo de la complejidad o alcance de la propuesta, sta puede presentarse directamente a los clientes y usuarios, o puede exhibirse a travs de uno o ms EF. En esta actividad se emplea la introspeccin como tcnica de elicitacin. Revisar el LEL buscando oraciones tanto en las nociones como en los impactos de los smbolos que presenten un punto de vista formal. Retornando al UdeD, se debe determinar si dichas sentencias deben cumplirse en el futuro. En tal caso debe incluirse dicha informacin en los EF. Negociar ciertos aspectos del software cuyas decisiones son incorporadas a los EF. La negociacin permite discutir y resolver conflictos de requisitos y establecer compromisos entre los involucrados. Durante la evaluacin de la informacin contenida en las Fichas de Informacin Anticipada, los ingenieros de requisitos detectan contradicciones, las que deben presentarse a los involucrados para su discusin y resolucin; en otros casos, la informacin contenida en dichas fichas debe ser confirmada mediante acuerdo. En la mayora de los casos, la deteccin de contradicciones, omisiones u otros inconvenientes ocurre al describir los EF. Entonces, la negociacin ocurre frente a descripciones de situaciones que son ms fciles de visualizar por los usuarios y, por lo tanto, se facilita la discusin. La negociacin no slo ocurre por conflictos en los requisitos sino tambin para evaluar las propuestas de los ingenieros de requisitos frente a determinadas situaciones. Estas propuestas pueden o no estar en conflicto con los requerimientos de los usuarios.
- 98 -
Las reuniones son el modo ms efectivo para negociar requisitos y resolver conflictos acerca de los mismos. Los ingenieros de requisitos encuentran contradicciones, omisiones y superposiciones, y llevan a cabo reuniones con clientes y usuarios que pueden ayudar a resolverlos. La reunin se suele dividir en tres etapas y consiste en: i) Una etapa informativa: se explican los problemas asociados con un EF. ii) Una etapa de discusin: los involucrados discuten cmo resolver el conflicto. En esta etapa se pueden dar prioridades a los EF5. Esto ayuda a decidir qu requerimientos sern eliminados (no sern requisitos del software) y cules se incluirn en la especificacin del sistema, es decir, sern parte del EF. iii) Una etapa de resolucin: se acuerdan acciones a tomar sobre los EF. Las acciones pueden ser: eliminar un EF, sugerir modificaciones especficas a un EF, o elicitar ms informacin acerca del EF. Generar distintas soluciones alternativas, es decir, se construyen distintos conjuntos de EF, o dentro de un nico conjunto de EF se presentan alternativas para una o ms situaciones particulares. Para ello se basan en distintas propuestas realizadas por ellos mismos, o distintos puntos de vista presentados por los usuarios. Entre las alternativas que se pueden presentar, estn por ejemplos distintas maneras de operacionalizar RNF. Durante la descripcin de los EF se aplican las mismas heursticas de descripcin indicadas para los EA, haciendo la siguiente salvedad respecto al uso del vocabulario descripto en el LEL:
Escribir las oraciones maximizando el uso de smbolos del lxico siempre que esto sea posible. Los Actores y Recursos deben ser preferentemente smbolos del lxico, de ser posible.
Se pueden dar prioridades a los EF o posteriormente priorizar por requisito individual en la siguiente etapa de la estrategia.
Esta salvedad se debe a que en la descripcin de los EF pueden surgir trminos nuevos como consecuencia de nuevas actividades, nuevas acciones, nuevos recursos, nuevos roles, nuevas condiciones; o pueden no usarse smbolos del LEL por ser obsoletos o carentes de sentido en el contexto una vez que ste haya evolucionado. Tambin puede ocurrir que un trmino permanezca pero con la nocin ligeramente actualizada y probablemente el impacto totalmente alterado, pero manteniendo el significado conceptual. En base a estas consideraciones, debemos hacer notar, que es casi inevitable que el vocabulario del UdeD evolucione junto con la evolucin del UdeD mismo. Por otro lado, se adicionan las siguientes recomendaciones:
Describir el qu se deber hacer, evitar al mximo el cmo se deber hacer. Evitar incorporar aspectos de diseo, salvo preferencias explcitas de los clientes y usuarios.
Durante esta actividad deben elicitarse RNF del software. Inicialmente, se determinar aquellos RNF que pueden y deben convertirse en acciones del sistema, convirtindose en uno o varios RF (operacionalizaciones). Los RNF que persisten como tales se incorporarn como restricciones en los episodios donde interviene el actor sistema de software, y aquellos de carcter ms general (no aplicables a un escenario o episodio de escenario) se podrn incorporar a las Fichas de Informacin Anticipada para ser tenidos en cuenta en la cuarta etapa de la estrategia. Si se hubiese optado por no realizar la cuarta etapa, se sugiere describir estos RNF como un agregado en el escenario integrador de mayor nivel, o en aquel escenario integrador que tuviera relacin directa con cada RNF. Bsicamente debe cuestionarse en los episodios donde interviene como actor el software la calidad con la que dicho actor debe participar, por ejemplo su eficiencia, confiabilidad y seguridad entre otros. Se pueden elicitar otros RNF en el UdeD siguiendo alguna estrategia especfica [Cysneiros 04] [Kerkow 05] o usando una lista gua de tipos de RNF a modo de checklist [Sommerville 05] [IEEE Std 830-1998] [ESA PSS-05-0] [ISO 25010:2011]. Muchos RNF se operacionalizan y, por lo tanto, desaparecen convirtindose en
- 100 -
RF empotrados en los escenarios. En algunos casos esto puede implicar tomar decisiones de diseo prematuramente, lo cual es conveniente evitar, salvo que dichas decisiones deban ser tomadas por clientes y no por los diseadores, ya sea porque involucran polticas organizacionales o preferencias de los clientes y de los usuarios, o decisiones presupuestarias (por ejemplo, invertir en determinado hardware o en un software ms sofisticado). No todos los RNF pueden operacionalizarse, tal es el caso de algunos requisitos de eficiencia, de portabilidad y de implementacin. Estos RNF se incluiran en los escenarios integradores (durante la actividad Organizar) o en los escenarios especficos respectivamente, en el atributo Restriccin del episodio correspondiente. Los RNF deben escribirse de tal forma que sean comprobables, sino sern requisitos incompletos o ambiguos. El sistema debe responder rpidamente frente a las consultas de los clientes.
El sistema debe responder antes de los 30 segundos frente a las

consultas de los clientes en el 90% de los casos, en el resto antes de los 40 segundos. El primer ejemplo es un RNF que no puede verificarse en el software. Debera redactarse como se expresa en el segundo ejemplo. No todos los RNF son mensurables, como por ejemplo los requisitos de seguridad pero s deben ser completos. El sistema debe mantener seguros los datos de la base
El sistema debe mantener seguros los datos de la base aplicando la

tcnica de integridad XYZ
El sistema debe mantener seguros los datos de la base manteniendo un

espejo de todas las transacciones realizadas. El primer ejemplo es un requisito incompleto pues puede haber muchas maneras de hacerlo y no puede ser comprobado. Debera escribirse como se expresa en el segundo o tercer ejemplo. Los RNF se deben elicitar y preferentemente deben buscarse alternativas para su conversin en comportamientos que satisfagan su cumplimiento. Estas
- 101 -
alternativas de operacionalizacin deben evaluarse con los clientes y usuarios, seleccionando la ms apropiada e incorporndola a los EF. Deben ser escasos aquellos RNF que permanezcan como tales adosados a los EF. En el ejemplo dado: El sistema debe mantener seguros los datos de la base manteniendo un espejo de todas las transacciones realizadas, esto involucra inmediatamente su operacionalizacin y por lo tanto desaparece como RNF. Para el ejemplo dado: El sistema debe responder antes de los 30 segundos frente a las consultas de los clientes en el 90% de los casos, en el resto antes de los 40 segundos, debe evaluarse con los clientes si esto debe cumplirse siempre o si al ocurrir tiempos excedentes de respuesta el sistema debe reportar el hecho al administrador de la base de datos. En el primer caso, el RNF permanecer como tal, en el segundo caso implica la operacionalizacin del requisito en las acciones que debe tomar el sistema. Este es el caso de un RNF de eficiencia que puede o no convertirse en RF segn la decisin de los clientes y usuarios. Siguiendo este ejemplo, si siempre debe cumplirse con los tiempos de respuesta, esto tambin puede involucrar la toma de decisin por parte de los clientes en esta fase de la IR, pues los ingenieros de requisitos pueden plantear la necesidad de inversin en hardware, en paquetes de comunicacin o en una determinada base de datos, o en producir un software ms sofisticado, y son los clientes que deciden, segn factores econmicos, cronogramas y recursos, cul opcin es la ms adecuada para la organizacin. Otros escenarios futuros que deben crearse estn relacionados con procesos bsicos de mantenimiento del sistema de software, como por ejemplo: procesos de Alta - Baja - Modificacin de entidades bsicas, procesos de depuracin y procesos de back-up. Algunos de estos procesos pueden ya estar presentes en EA y slo requerir una actualizacin. En esta etapa pueden generarse Fichas de Informacin Anticipada conteniendo RNF que no han podido adosarse a ningn EF especfico por tener un alcance ms amplio, y que debern incorporarse a los EF integradores en la siguiente actividad. Tambin puede surgir informacin referida a atributos de los requisitos, como volatilidad, prioridad, riesgo, etc. Este tipo de informacin no corresponde volcar en los EF y debe registrarse en las Fichas de Informacin Anticipadas.
(3) Organizar
Esta actividad utiliza las mismas heursticas para organizar escenarios actuales y comprende las sub-actividades graficadas en la Figura 37, que se describen a continuacin.
T itle :
FICHA DE REQUISITO CANDIDATO ESPONTANEO FICHA DE REQUISITO CANDIDATO Proyecto: ____________________ ESPONTANEO Fecha: __/__/____ FICHA DE REQUISITO CANDIDATO Ingeniero de Requisitos: ________ Proyecto: ____________________ ESPONTANEO Fecha: __/__/____
Objetivos del Sistema Precisados

Ingeniero de Requisitos: ________ Proyecto: ____________________ Descripcin:___________________ Fecha: __/__/____ ______________________________ Ingeniero de Requisitos: ________ ______________________________ Descripcin:___________________ Prioridad: Obligatorio Deseado ______________________________ ______________________________ Descripcin:___________________ Tipo: Prioridad: : ____________ RF RNF Obligatorio Deseado ______________________________ Fuente de Informacin: ____________ ______________________________ Etapa Tipo: del Proyecto: : ____________ RF_______________ RNF Prioridad: Obligatorio Deseado Observacin: ____________________ Fuente de Informacin: ____________ Etapa Tipo: del Proyecto: RF_______________ RNF: ____________ Observacin: ____________________ Fuente de Informacin: ____________ Etapa del Proyecto: _______________ Observacin: ____________________
E x c e p tio n s :
Modelo de Heurstica Lista de Fuentes de Informacin Escenario

Ttulo: Actores:
EF
Obtener la documentacin Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin para con que cuenta el cliente-usuario
que el ingeniero de requisitos realice Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin su trabajo Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su trabajo identificacin de fuentes de cliente-usuario con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice
CLIENT-USER
LEL
Reorganizar Escenarios Definir Relaciones Integrar Escenarios Refinar Objetivos
cliente-usuario identificacin de fuentes de Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Recursos: documentacin informacin Cliente-usuario Episodios:Actores: Ingeniero de requisitos Recursos: documentacin 1. El ingeniero de requisitos recibe toda Cliente-usuario la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 1. El ingeniero de requisitos recibe toda 2. El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el evala la con el cliente-usuario 1. El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario Excepciones: 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. Excepciones: documentacin recibida responde a las expectativas.
Excepciones:
EF Integradores
que el ingeniero de requisitos realice Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin su trabajo Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su fuentes trabajo de identificacin de cliente-usuario informacin Contexto: Se efecta en las la dependencias del Debe haberse realizado cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de Actores: Ingeniero de requisitos Recursos: documentacin informacin Cliente-usuario Episodios:Actores: Ingeniero de requisitos Recursos: documentacin 1. El ingeniero de requisitos recibe toda Cliente-usuario la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 1. El ingeniero de requisitos recibe toda 2. El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el evala la con el cliente-usuario 1. El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario Excepciones: 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. Excepciones: documentacin recibida responde a las expectativas.
EF Descriptos
Ttulo: Obtener la documentacin Objetivo: Obtener toda la informacin escrita Ttulo: Obtener documentacin para con que cuenta el la cliente-usuario
realice que el ingeniero de requisitos Objetivo: Obtener toda la informacin escrita Ttulo: Obtener la documentacin su trabajo Obtener toda la informacin escrita que el de requisitos Contexto: Objetivo: Se efecta eningeniero las dependencias del realice Debe haberse realizado Contexto: Se efecta en las la dependencias del su trabajo identificacin de fuentes de cliente-usuario con que cuenta el cliente-usuario para con que cuenta el cliente-usuario para su trabajo cliente-usuario que el ingeniero de requisitos realice informacin Contexto: Se efecta en las la dependencias del Debe haberse realizado
Actores:
Actores: Ingeniero de requisitos Recursos: documentacin informacin

Cliente-usuario
cliente-usuario identificacin de fuentes de Ingeniero de requisitos Debe haberse realizado la informacin Cliente-usuario identificacin de fuentes de
la documentacin con que cuenta el Episodios: Recursos: documentacin cliente-usuario. 2. 1. El ingeniero de requisitoscon en conjunto Episodios: la documentacin que cuenta el El ingeniero de requisitos recibe toda
Excepciones:
evala la con el cliente-usuario 1. El ingeniero de si requisitos recibe toda cliente-usuario. documentacin responde a conjunto la recibida documentacin con que cuenta el 2. El ingeniero de requisitos en las expectativas. cliente-usuario.evala si la con el cliente-usuario Excepciones: 2. El ingeniero de requisitos en documentacin recibida responde a conjunto con el cliente-usuario evala si la las expectativas. Excepciones: documentacin recibida responde a las expectativas.
Excepciones:
UdeD
Figura 37. Actividad Organizar en el proceso de EF Se aplican las operaciones de composicin / descomposicin para mejorar la homogeneidad, legibilidad y manejabilidad de los EF. En el caso de una baja reingeniera, es frecuente que haya pocas o nulas operaciones a realizar debido a que el mecanismo constructivo tiende a conservar gran parte de la estructura jerrquica de los EA en los EF. Se identifican las relaciones entre los EF: jerarqua, orden, superposicin y excepcin. Se integran los EF teniendo en cuenta las relaciones identificadas previamente, construyendo los escenarios futuros integradores, usando las mismas heursticas que para los escenarios actuales. Se debe tener en cuenta que en un enfoque orientado a lo procedural puro no sera necesario realizar este proceso, pues los escenarios futuros integradores seran
directamente los escenarios integradores actuales. En la prctica, siempre algn escenario integrador es factible que deba cambiarse, por ende, es factible la realizacin de la integracin. En este caso, tambin puede ser necesario retornar al UdeD para obtener informacin faltante que se vislumbra al vincular escenarios. Tambin se revisan aquellas Fichas de Informacin Anticipadas no procesadas an, que contengan bsicamente RNF de carcter general o ms abarcador y que no hayan sido incluidos en EF particulares. Estos RNF deben incluirse en los correspondientes EF integradores. Se refinan los objetivos del software a partir de los objetivos de los escenarios futuros integradores. Esta es una actividad nueva respecto a la construccin de EA, que tiene sentido bajo el concepto de escenario en un contexto organizacional. Los objetivos generales del sistema sirven de marco para obtener los objetivos de los EF, por integracin se obtienen los objetivos de los EF integradores, a partir de los cuales se refinan los objetivos generales del sistema.
(4) Verificar
Se aplica la tcnica de Inspeccin al conjunto de EF, para determinar su consistencia, completitud y la satisfaccin de los objetivos del sistema de software. Se realiza tanto la verificacin intra-escenario como la interescenarios. Respecto a la verificacin contra el LEL, slo se incluyen los siguientes aspectos:
Controlar que todo smbolo del LEL sea identificado al mencionarse en un escenario. Controlar el uso correcto de smbolos del LEL. En este caso, puede haber una alteracin del significado actual del trmino debido a la incorporacin del software. Esto no implica una actualizacin del LEL.
En cuanto a la verificacin intra-escenario, se adiciona un nuevo control:

Controlar que todo objetivo de un escenario est en concordancia con los objetivos del sistema.
- 104 -
Al finalizar cada tipo de verificacin, se genera una lista de DEOs para corregir los EF.
(5) Validar
Se pueden aplicar distintas tcnicas para validar los EF como por ejemplo: reuniones, entrevistas estructuradas, role playing y animacin, similares a las aplicadas para validar EA. Aunque para el caso de validar EF se recomienda aplicar la tcnica de prototipado o el uso de storyboards, pues el usuario se encuentra frente a una descripcin de una situacin que an no existe y por ende, debe hacer uso de su imaginacin para poder ratificar o corregir dicha descripcin. A pesar de estar escritas en lenguaje natural, respetando al mximo el uso de su propio vocabulario, debe brindarse al usuario una mayor ayuda para la comprensin de estas descripciones. En el caso de aplicar la tcnica de prototipado, se construye un prototipo que ser una representacin visual de cada escenario futuro. El prototipo no muestra la interfaz de usuario, sino los pasos que se siguen en dicha situacin. Se representa la informacin de entrada y de salida de cada escenario, las relaciones entre escenarios y los procesos que se llevan a cabo mediante la emisin de mensajes. Durante la ejecucin del prototipo de cada escenario frente a los usuarios se anotan los comentarios que los mismos van realizando, en una ventana anexa al prototipo. En caso de tener ms de un conjunto alternativo de EF, se deber construir un prototipo por cada conjunto, de manera tal que se pueda evaluar cada posible solucin y elegir la mejor o una combinacin de ellas. Los storyboards representan imgenes contextuales para visualizar un escenario, donde el texto complementa las limitaciones de la imagen y la imagen las limitaciones del texto, como se aprecia en la Figura 38, extrada del caso Proveedor integral de redes de televisin e Internet (desarrollado por R. Guatelli). Se logra condensar en una imagen el mensaje relevante de cada episodio del escenario. Los storyboards presentan ventajas muy interesantes, pues son fciles de mantener o adaptar a los cambios y, adems, permiten incorporar modificaciones durante la validacin.
Figura 38. Ejemplo de Storyboards de un Escenario Futuro Como resultado de la validacin es posible generar tres tipos distintos de listas de DEOs: una lista para corregir los EF, otra para corregir EA y una tercera menos frecuente para corregir el LEL. Esta ltima no debe incluir nuevos trminos o adaptaciones a significados de smbolos por el hecho de incorporar el software, slo se incluyen mejoras por una mejor comprensin del vocabulario utilizado actualmente en el UdeD. En cuanto a la lista de DEOs para EA, es posible determinar algn tipo de defecto no detectado previamente, principalmente en el caso de una baja reingeniera, donde hay una correlacin ms estrecha entre EA y EF, y el defecto detectado en el EF puede tambin estar presente en el EA.
7.4. Enfoques en el Modelado de Escenarios Futuros

La estrategia para encarar el modelado de los EF depende fuertemente del grado de reingeniera esperado en los procesos del negocio donde el software intervendr, por lo tanto, se pueden presentar tres estrategias principales para manejar la construccin de los EF: i) Derivando los EF directamente de los escenarios existentes.
ii) Derivando los EF a travs de los objetivos establecidos para el software a construir. iii) Derivando los EF mediante una combinacin de las estrategias precedentes. Si no se construyen escenarios actuales, slo podr elegirse el enfoque dirigido por objetivos aunque la construccin de los escenarios futuros no podr apoyarse en el rbol jerrquico de escenarios actuales. Existen dos alternativas: i) construir escenarios generales futuros capturando conocimiento general del problema bajo la perspectiva de los objetivos del sistema, o ii) derivar situaciones del LEL para considerarlas como escenarios futuros candidatos y evaluarlos frente a los objetivos del sistema. La segunda opcin da un punto de partida importante para describir escenarios siguiendo un enfoque middle-out, que es coincidente con el inicio para la construccin de escenarios actuales. En resumen, tenemos entonces cinco alternativas de construccin de Escenarios Futuros: i) Crear los Escenarios Futuros derivndolos directamente de los Escenarios Actuales existentes: enfoque orientado a los procedimientos. ii) Crear los Escenarios Futuros dirigido por los objetivos establecidos para el software, apoyndose en los Escenarios Actuales. iii) Crear los Escenarios Futuros mediante una combinacin de las dos estrategias precedentes: enfoque hbrido. iv) Crear los Escenarios Futuros utilizando la tcnica de derivacin del Lxico Extendido del Lenguaje. v) Crear los Escenarios Futuros siguiendo un enfoque top-down dirigido por los objetivos del sistema. La Figura 39 muestra un esquema de seleccin de enfoques considerando la posibilidad de disponer de un conjunto de EA o no.
- 107 -
Figura 39. Seleccin del Enfoque para construir EF Bsicamente los EA se estudian en bsqueda de episodios donde hay transferencia de informacin para evaluar la posible incorporacin de tecnologa de informacin que facilite, agilice o haga ms eficiente el proceso actual. A continuacin se presentan los tres enfoques para la construccin de los EF que se desarrollan durante la actividad Describir.
7.4.1.
Enfoque Orientado a lo Procedural
La hiptesis principal cuando se construyen EF en el contexto de procesos del negocio con cambios menores es que hay un mapeo casi completo de los EA a los EF. Tambin se supone que el objetivo del escenario es invariante, es decir, puede copiarse del EA al EF tal como es. Obviamente, sta es una situacin lmite, los proyectos reales introducen algunos cambios y no siempre cada EA tiene su correspondiente EF con exactamente el mismo objetivo. Sin embargo, ste es el punto de partida y podra introducirse la desviacin a lo largo del proceso. Luego, el EF se construye enfocndose en el componente Episodios del EA. Cada episodio debe analizarse en el marco de los objetivos del sistema de software para determinar si necesita ser modificado y cmo. Una vez que todos los episodios han sido estudiados, el resto de los componentes del escenario debe observarse para propagar los cambios introducidos en los episodios. Pueden necesitarse nuevos recursos o algunos recursos existentes pueden tornarse obsoletos. Si el EF est dentro del alcance del sistema de
- 108 -
software, un nuevo actor tiene que ser incluido: el propio artefacto de software. Finalmente, cambios menores en el ttulo y/o el objetivo pueden requerirse. Aunque cada EF se construye con un enfoque bottom-up, el conjunto completo se construye top-down. El conjunto de EA debe investigarse en el modo postorder. Esto significa que el primer EA que debe considerarse es el escenario integrador de mayor nivel en la jerarqua. El proceso contina con el primer escenario integrador del segundo nivel. Luego, la atencin se centra en el primer escenario raz mencionado en el primer escenario integrador del segundo nivel. En el contexto de una realmente baja reingeniera del negocio, se espera alguno o ningn cambio en los escenarios integradores. Debe recordarse que los escenarios integradores no contienen ninguna pieza propia de informacin. Por lo tanto, los escenarios integradores actan como marco para ayudar a realizar la autntica tarea de construccin de los EF, la cual se hace sobre los escenarios raz y los sub-escenarios. Por ello, se recomienda usar los escenarios integradores actuales sin cambiarlos durante la modificacin de los escenarios raz y los sub-escenarios. Una vez que se tuvieron en cuenta todos los escenarios raz y los sub-escenarios, deben reconstruirse los escenarios integradores futuros utilizando la misma tcnica aplicada en la generacin de los escenarios integradores actuales. En el cuadro siguiente se resume el proceso y la Figura 40 esquematiza el modo de recorrido de la jerarqua de escenarios actuales. PROCESO ORIENTADO A LO PROCEDURAL Recorrer el conjunto de escenarios integradores actuales usando el modo post-order (recorrer a partir del escenario integrador actual raz hacia abajo hasta encontrar un Escenario Actual, es decir, se evalan primero las hojas y luego los nodos padres). Se crean los escenarios integradores futuros copiando los escenarios integradores actuales. Por cada Escenario Actual: o Determinar si el Escenario Actual se modificar segn los objetivos del sistema.
- 109 -
o Si no se altera, incluir el Escenario Actual sin cambio en el conjunto de Escenarios Futuros. o Si se altera: Examinar los episodios y excepciones del Escenario Actual en el marco de los objetivos del sistema, y adaptarlos. Examinar los recursos como posible informacin a almacenar a travs del sistema, y ver la necesidad de incluir episodios a tal fin. Actualizar los actores y recursos. Examinar el ttulo, objetivo y contexto desde la perspectiva de las modificaciones introducidas.
Grado de Reingeniera?
Escenario Integrador
Escenario
Escenario
Escenario
Escenario
Escenario
SubEscenario
SubEscenario
SubEscenario
Figura 40. Recorrido del rbol en modalidad post-order
7.4.2.
Enfoque Dirigido por Objetivos
La hiptesis principal aqu es bsicamente la opuesta al enfoque orientado a lo procedural. Los EA comprendidos por el alcance del proyecto de software sern por lo menos ampliamente modificados. Es decir, escenarios apareados tendrn cambios importantes en los objetivos. Tambin es de esperar que varios EA se vuelvan totalmente obsoletos y que aparezcan nuevos escenarios.
- 110 -
La tarea en este caso es estudiar el objetivo del EA en el contexto de los objetivos del sistema y determinar cmo stos modifican al objetivo del escenario. Una vez obtenida una versin preliminar del objetivo del EF, debe determinarse si es posible cumplirlo con un slo EF o si se necesita ms de un EF. Tambin puede ocurrir que el objetivo del EA pierda sentido en el nuevo contexto, tornando obsoleto al EA. Hasta aqu se han obtenido algunos esqueletos de EF, teniendo una versin preliminar de sus objetivos y sus ttulos. Estos escenarios deben completarse sintetizando otros componentes basados en el objetivo. Cada EF y el conjunto ntegro se construyen usando un enfoque top-down. El conjunto de EA debe investigarse en un modo pre-order. Aqu, el primer EA que debe considerarse es tambin el escenario integrador de ms alto nivel. En este caso, se esperan muchos cambios en los escenarios integradores. stos se denominan escenarios generales y tambin actan como marco para ayudar a realizar la tarea efectiva de construccin de los EF, la cual se hace sobre los escenarios raz y los sub-escenarios. A medida que el proceso avanza, deben aplicarse los nuevos cambios a los escenarios generales para que se mantengan consistentes con los EF ya construidos. Se aconseja desechar los escenarios generales al final del proceso y construir los escenarios integradores futuros con la misma tcnica usada para los escenarios integradores actuales. Por cada situacin en estudio, debe preguntarse: La situacin es compatible con el objetivo del sistema? El sistema de software jugar un rol o nuevo rol en esta situacin? Es realmente necesaria la situacin en el UdeD futuro? En el cuadro siguiente se resume el proceso y la Figura 41 esquematiza el modo de recorrido de la jerarqua de escenarios. PROCESO DIRIGIDO POR OBJETIVOS Recorrer el conjunto de escenarios integradores actuales usando el modo pre-order. Por cada escenario integrador actual, construir escenarios futuros
- 111 -
generales modificando los escenarios integradores actuales: o Revisar el objetivo y ttulo del escenario integrador actual en el marco de los objetivos del sistema. o Definir el objetivo y ttulo del escenario futuro general. o Actualizar los episodios y excepciones del escenario futuro general (que sern los ttulos de los Escenarios Futuros). o Construir necesarios. Recorrer el conjunto de escenarios futuros generales usando el modo preorder. Por cada Escenario Actual existente (coincide el ttulo del Escenario Futuro con el ttulo del Escenario Actual): o Revisar el objetivo y ttulo del Escenario Actual en el marco de los objetivos del sistema. o Crear tantos Escenarios Futuros como sean necesarios, definiendo su ttulo y objetivo. o Elicitar o proponer los episodios y excepciones requeridos para cumplir los objetivos de los Escenarios Futuros. o Actualizar los actores y recursos del Escenario Futuro. o Revisar el contexto del Escenario Futuro. Describir todo nuevo Escenario Futuro creado (aqul sin apareo con algn Escenario Actual). Construir los escenarios futuros integradores aplicando la tcnica de integracin. tantos escenarios futuros generales como sean
- 112 -
Escenario
Escenario
Escenario
Escenario
Escenario
SubEscenario
SubEscenario
SubEscenario
Figura 41. Recorrido del rbol en modalidad pre-order
7.4.3.
Enfoque Hbrido
Cuando se encaran proyectos de software con un nivel intermedio de reingeniera del negocio, se debe aplicar un enfoque hbrido. Este puede llevarse a cabo reduciendo el alcance en que la pregunta sobre reingeniera debe contestarse. El proceso debe comenzar como si hubiera un nivel alto de reingeniera. De esta manera, los escenarios generales deben obtenerse de los escenarios integradores actuales y cuando el proceso llega a cada escenario raz o sub-escenario la pregunta: qu grado de reingeniera del negocio se espera? debe contestarse ahora en el alcance del EA bajo consideracin. Segn la respuesta, se deber aplicar a este escenario en particular una estrategia orientada a lo procedural o una orientada a los objetivos. Cambiando de una estrategia a otra en cada paso, se puede tratar con todos los posibles grados de reingeniera. Obviamente, un proceso hbrido se reduce a un proceso orientado a los objetivos si la respuesta es siempre alta reingeniera para cada EA. Esto no es precisamente verdad si la respuesta es siempre baja reingeniera. En este caso la construccin de los escenarios generales y el enfoque pre-order induce a realizar algunas tareas completamente innecesarias.
En el cuadro siguiente se resume el proceso y la Figura 42 esquematiza el modo de recorrido de la jerarqua de escenarios. PROCESO HBRIDO Recorrer el conjunto de escenarios integradores actuales usando el modo pre-order. Por cada escenario integrador actual: o Revisar el objetivo y ttulo del escenario integrador actual en el marco de los objetivos del sistema para determinar si el proceso del negocio que representa se modificar. o Si no se altera, copiar el escenario integrador actual sin cambio en el conjunto de escenarios futuros. o Si se altera: Definir el objetivo y ttulo del nuevo escenario futuro general. Actualizar los episodios y excepciones del escenario futuro general (que sern los ttulos de los Escenarios Futuros) en base al escenario integrador actual. Recorrer el conjunto de escenarios futuros generales usando el modo preorder. Por cada escenario actual existente: o Preguntar si es alta o baja la reingeniera para dicha situacin especfica. o Si es alta: seguir una estrategia top-down: (del objetivo del escenario a los episodios) Revisar el objetivo y ttulo del Escenario Actual en el marco de los objetivos del sistema. Crear tantos Escenarios Futuros como sean necesarios, definiendo su ttulo y objetivo. Elicitar o proponer los episodios y excepciones requeridos para cumplir los objetivos de los Escenarios Futuros. Actualizar los actores y recursos del Escenario Futuro. Revisar el contexto del Escenario Futuro.
- 114 -
o Si es baja: seguir una estrategia bottom-up: (de los episodios al objetivo) Examinar los episodios y excepciones del Escenario Actual en el marco de los objetivos del sistema, y adaptarlos. Actualizar los actores y recursos. Examinar el ttulo, objetivo y contexto desde la perspectiva de las modificaciones introducidas. Por cada nuevo Escenario Futuro seguir una estrategia top-down o Describir todo nuevo Escenario Futuro creado (aqul sin apareo con algn Escenario Actual). Construir los escenarios futuros integradores aplicando la tcnica de integracin.
Escenario
Escenario
Escenario
Escenario
Escenario
SubEscenario
SubEscenario
SubEscenario
Figura 42. Recorrido del rbol en modalidad hbrida
7.4.4.
Enfoque Basado en el LEL
En este enfoque el Lxico Extendido del Lenguaje da un punto de partida importante para describir escenarios siguiendo un enfoque middle-out, el cual es coincidente con el inicio para construir escenarios actuales. Esta misma tcnica de derivacin de informacin del lxico puede aplicarse para obtener un
bosquejo de escenarios futuros. Cuando no se han construido escenarios actuales, pero s se ha considerado apropiado crear el Lxico Extendido del Lenguaje, y adems se ha determinado que la innovacin esperada en el negocio no es alta, entonces es factible aplicar este enfoque middle-out para construir los escenarios futuros. Luego de la derivacin, estos escenarios son evaluados en el marco de los objetivos del sistema y es necesario elicitar informacin del dominio de la aplicacin siendo guiados por estos escenarios candidatos para completarlos o crear nuevos. Esta tcnica de derivacin de informacin del lxico es la misma que se aplica para construir Escenarios Actuales. Bsicamente este enfoque es una combinacin de derivacin de Escenarios Actuales con construccin de Escenarios Futuros en funcin de los objetivos del sistema. En el cuadro siguiente se resume el proceso. PROCESO BASADO EN EL LXICO EXTENDIDO DEL LENGUAJE Generar una lista de actores del dominio de la aplicacin, a partir de la identificacin de los trminos del tipo Sujeto en el Lxico Extendido del Lenguaje. Generar una lista de escenarios candidatos: o Identificar un escenario candidato por cada impacto de cada trmino Sujeto considerado actor. o Componer el ttulo del escenario con la accin (verbo) incluida en el impacto, expresada en infinitivo, ms un predicado tambin obtenido del impacto Crear cada escenario candidato: o Si el impacto contiene un trmino de tipo Verbo: El objetivo se define preliminarmente en base al ttulo del escenario y la nocin del trmino Verbo. La ubicacin geogrfica, la ubicacin temporal y la precondicin del contexto puede extraerse de la nocin del trmino Verbo. Para la precondicin, tambin puede haber informacin relevante observando semnticamente las relaciones con los restantes impactos del trmino tipo Sujeto
- 116 -
origen (actor). Los actores y recursos se identifican a partir de la informacin contenida en el trmino Verbo, buscando trminos del tipo Sujeto, adems del Sujeto origen, y del tipo Objeto respectivamente. Los episodios se derivan de cada impacto del trmino Verbo. En el caso de detectarse un trmino del tipo Estado en la descripcin del Verbo, existe la posibilidad de incluir como episodio alguna accin descripta en el trmino Estado que tuviera relacin con el escenario. o Si el impacto NO contiene un trmino tipo Verbo: Se identifican otros tipos de trminos en el impacto del Sujeto (actor) y se toman como posibles fuentes de informacin. El objetivo se define preliminarmente en base al ttulo del escenario. La ubicacin geogrfica, la ubicacin temporal y la precondicin del contexto pueden ser extradas del impacto del trmino Sujeto que origin el escenario (actor). Cuando este impacto contiene alguna condicin, esta puede corresponder a la Precondicin o a la Ubicacin Temporal del escenario derivado. Para la precondicin, tambin puede haber informacin relevante observando semnticamente las relaciones con los restantes impactos del mismo trmino Sujeto. Los actores se identifican a partir de trminos tipo Sujeto mencionados en el impacto, adems del Sujeto origen, y los recursos de trminos tipo Objeto. Solo es posible incluir como episodio alguna accin referida a este escenario contenida en la definicin de trminos tipo Objeto, tipo Estado u otros trminos Sujeto detectados previamente en el impacto. Examinar cada escenario derivado segn los objetivos del sistema o Evaluar la transferencia de responsabilidades de actores al
- 117 -
software. o Evaluar el uso y/o generacin de recursos (objetos e informacin) a travs del software. o Crear los escenarios futuros completando los escenarios derivados y con las transformaciones realizadas. Construir los escenarios futuros integradores aplicando la tcnica de integracin.
7.4.5.
Enfoque Top-Down Tradicional
Al presentarse dos circunstanciales cruciales: un alto nivel de cambios esperado en los procesos del negocio y no disponer del conjunto de Escenarios Actuales, derivar escenarios a partir del lxico puede inducir a mantener prcticas actuales en desmedro de elaborar mejores propuestas para el negocio a partir del sistema de software a desarrollar. Por otro lado, cuando tampoco se dispone del Lxico Extendido del Lenguaje, se est asumiendo un grupo de ingenieros con alto conocimiento del dominio de la aplicacin, que est en condiciones de realizar propuestas basados exclusivamente en los objetivos del sistema, sin requerir de herramientas de soporte. Bajo estas circunstancias, es concebible aplicar un enfoque top-down para construir Escenarios Futuros, pues una divisin del problema, dado el conocimiento pre-existente, puede realizarse sin mayores inconvenientes. Se construyen escenarios futuros generales capturando conocimiento general del problema bajo la perspectiva de los objetivos del sistema. Estos se van refinando mediante la construccin de escenarios de menor nivel. En el cuadro siguiente se resume el proceso. PROCESO TOP-DOWN Identificar los procesos del negocio bajo estudio y crear los escenarios futuros generales: o Definir el objetivo y ttulo del escenario futuro general en el marco de los objetivos del sistema.
- 118 -
o Crear los episodios en base a cada proceso del negocio identificado. o Construir tantos escenarios futuros generales de menor nivel como procesos del negocio (episodios del escenario general de mayor nivel). Recorrer el conjunto de escenarios futuros generales usando el modo preorder. Crear un escenario futuro por cada episodio de escenario futuro general: o Definir el objetivo y ttulo del Escenario Futuro en el marco de los objetivos del sistema. o Elicitar o proponer los episodios y excepciones requeridos para cumplir los objetivos de los escenarios futuros. o Definir los actores y recursos del escenario futuro. o Definir el contexto del escenario futuro. Construir los escenarios futuros integradores aplicando la tcnica de integracin.
7.5. Observaciones sobre el Proceso de Escenarios Futuros

Los escenarios se enmarcan en un contexto organizacional, el cual puede ser el contexto presente o el contexto proyectado. Se enfatiza el estudio del contexto en el cual el sistema de software quedar inmerso, pues la solucin ms adecuada a un problema es intrnsecamente dependiente del contexto en el que dicha solucin ser aplicada. Las situaciones observadas (plasmadas en EA) son la base para el conocimiento del problema y las situaciones deseadas (plasmadas en EF) son el bosquejo para los requisitos. La diferencia entre escenarios actuales y escenarios futuros es vlida solamente bajo la visin que se parte de escenarios que describen el macrosistema a escenarios que describen cambios en l.
- 119 -
En esta etapa de la estrategia es fundamental el acuerdo de los clientes y usuarios respecto de la funcionalidad y condiciones bajo las que el sistema de software va a operar. Para lograr una mejor validacin de los EF se utilizar la tcnica de prototipado o el uso de storyboards. Mediante estas tcnicas se pueden mostrar alternativas para los procesos del negocio utilizando el sistema de software. Los EF son construidos desde el punto de vista del proceso del negocio, incorporando las acciones del actor sistema de software. Es as, que el mundo descripto por estos escenarios no es observable sino que describen la forma en que se espera que se desenvuelva el negocio cuando se disponga del sistema de software que se planifica desarrollar. No toda la informacin incluida en los EF est directamente relacionada con el sistema de software, por el contrario muchas de ellos describen situaciones en las que no participa el sistema de software. Estas situaciones se constituyen en una eficaz descripcin del contexto en el que el sistema se desenvolver.
- 120 -
8. Creacin del Documento de Requisitos

Una vez construidos los escenarios futuros, los requisitos del sistema de software estn fcilmente disponibles. Los escenarios futuros no son requisitos pero los contienen en distintos componentes del escenario, de donde pueden ser extrados con cierta facilidad. A veces es deseable individualizar los requisitos y plasmarlos en un documento. Muchas de las buenas prcticas o prcticas recomendadas en el proceso de desarrollo de software se basan en la existencia de un documento de requisitos en el que se individualizan los mismos en forma precisa. Esta individualizacin facilita la rastreabilidad de los mismos, el control de sus cambios, el anlisis de su interdependencia, el apareamiento de los requisitos con los componentes de software, el seguimiento de la evolucin de los requisitos y el versionado de los mismos, entre otras actividades. Por otro lado, muchas organizaciones solicitantes de un software estipulan la necesidad de un documento que avale todos los requisitos del software como parte del contrato con la empresa desarrolladora. Es frecuente que este documento sea utilizado como parte del pliego de licitacin o de un anexo tcnico en el caso de sistemas de software de cierta envergadura. La generacin del SRS es una actividad dirigida para los clientes, mientras que la construccin de los escenarios futuros permite la elicitacin y validacin de requisitos, y como producto final son de gran utilidad para el diseo del software.
8.1. Documento de Definicin de Requisitos

Los requisitos son generalmente documentados con una narrativa explcita para comunicarlos a los involucrados en el proyecto. Tambin sirve como contrato entre los clientes y el equipo de desarrollo sobre lo que va a proveer el nuevo sistema de software. Adems, el SRS puede ser usado para registrar y
- 121 -
gestionar cmo los requisitos son satisfechos y qu fragmento del sistema de software fue originado en un cierto requisito (alocacin de requisitos), como un ancla para pre y post rastreo de los requisitos, como ancla para la gestin de cambios en los requisitos, como herramienta de validacin de los requisitos con los usuarios, como puente de comunicacin entre el equipo de analistas y el equipo de diseadores, como instrumento para probar el sistema de software. En diferentes organizaciones y en la literatura misma, este documento se genera con diversas estructuras, aunque existen estndares internacionales que especifican su estructura, tales como [IEEE Std 830-1998], [IEEE Std P1233/D3-1995], [DOD 5000.2-R], [ESA PSS-05-0], [NCC 87] entre otros. Este documento es el producto final del proceso de la IR; en algunos proyectos pequeos y medianos puede ser muy informal, e incluso puede no existir. En general, se escribe en lenguaje natural para servir como medio de comunicacin entre los participantes, pero en algunos casos se lo escribe con una notacin formal o semi-formal para describir los requisitos en forma ms precisa y concisa. Se requiere entrenamiento especial para generar un SRS en lenguaje natural que sea lo ms completo posible, consistente, no ambiguo, legible y adems producirlo en un lapso de tiempo razonable. Un documento de definicin de requisitos debe describir:

funciones y servicios que el sistema proveer (RF), propiedades que debe poseer el sistema (RNF), restricciones que limitan el proceso de desarrollo del sistema y restricciones bajo las cuales el sistema debe operar (RNF), informacin acerca de otros sistemas con los que el sistema debe integrarse, e informacin sobre el dominio de la aplicacin.
Como se observa en la Figura 43, la estructura que sugiere la IEEE es una gua general de lo que debera contener este documento, dando pautas generales de contenido de cada seccin. La seccin 1 describe los objetivos y alcance del sistema, e incluye un glosario de trminos utilizados en el documento. La seccin 2 describe la funcionalidad general del sistema y los factores que afectarn al sistema y al proceso de desarrollo. La seccin 3
describe en detalle los requisitos del software. Los apndices pueden ser parte del documento o estar separados, ellos pueden ser modelos del sistema que se adosan para clarificar las descripciones de los requisitos, descripciones de hardware, descripciones de base de datos a utilizar, componentes de software a ser reusados, etc.
1. Introduccin 1.1. Propsito del documento de requisitos 1.2. Alcance del proyecto 1.3. Definiciones, acrnimos y abreviaturas 1.4. Referencias 1.5. Resumen del resto del documento 2. Descripcin General 2.1. Perspectiva del producto 2.2. Funciones del producto 2.3. Caractersticas de los usuarios 2.4. Limitaciones generales 2.5. Suposiciones y dependencias 3. Requisitos Especficos Requisitos funcionales, no funcionales y de interfaces Apndices ndice
Figura 43. Estructura de SRS segn [IEEE Std 830-1998] Se desprende de la Figura 43 que la seccin 3 del documento no tiene una apertura en sub-secciones, el detalle de cmo organizar y describir los requisitos especficos depender de la organizacin, de la estrategia de desarrollo a utilizar y del tipo de software a desarrollar, pero s ofrece ocho patrones guas alternativos de cmo organizar la seccin. No siempre se crea el SRS, los requisitos pueden quedar empotrados en los modelos construidos, o definirse con alguna plantilla donde se incluyen ciertos atributos [IEEE Std P1233/D3-1995] [Kotonya 98] [Whitten 03] [Young 04]. En general los atributos que se asocian a los requisitos se adaptan segn el equipo de desarrolladores, cada aplicacin en particular y la herramienta de gestin utilizada. Estos atributos deben procurar brindar, primordialmente, ayuda en la comprensin del requisito, adicionalmente facilidad en la bsqueda o seleccin de requisitos y en la administracin del propio proceso de definicin de requisitos.
- 123 -
8.2. Proceso de Creacin del Documento de Requisitos

Los requisitos del sistema de software habitualmente se modelan en un documento. Este proceso de creacin del documento [Hadad 09] comienza buscando requisitos funcionales y algunos no funcionales en los escenarios futuros. La gran mayora de los RF pueden ser recolectados de los episodios donde el sistema de software es un actor involucrado. Los RNF pueden capturarse de las restricciones y excepciones de los escenarios futuros. La lista de requisitos no requiere ser verificada ni validada dado que se construye a partir de un conjunto de EF que ha pasado por procesos de verificacin y validacin. Adems se supone que en esta etapa los requisitos no necesitan ser acordados porque ello ya fue realizado a travs de los EF. Si los EF no fueron priorizados, entonces es probable que se realicen reuniones con los clientes y usuarios para dar prioridades a los requisitos. Se redacta el Documento de Definicin de Requisitos, basndose en algn estndar que la organizacin utilice o que se proponga de acuerdo al proyecto en particular. Cabe mencionar que este documento respeta el vocabulario del UdeD, manteniendo vnculos al LEL, pues por un lado fue generado a partir de los EF descriptos utilizando el LEL y todo otro agregado debe realizarse respetando el uso de dicho vocabulario. Luego el SRS es un documento de fcil lectura para los clientes y usuarios, y que adems presenta nula o escasa ambigedad. Debe destacarse que se est partiendo de un conjunto de EF, el cual no slo fue verificado y validado, sino que los RNF elicitados fueron muchos de ellos operacionalizados. La operacionalizacin de RNF implica la inclusin de nuevas acciones en los EF. Otros RNF permanecieron como tales en los EF, por implicar decisiones de diseo o propiedades intrnsecas del software, y fueron adosados a escenarios o episodios de escenarios utilizando el atributo Restriccin. Esto ltimo indica que el RNF es incluido en la Restriccin de un episodio de un escenario integrador.
- 124 -
Las actividades involucradas en el proceso, que se presenta en la Figura 44, son: 1) Extraer los requisitos, 2) Asignar atributos a los requisitos, 3) Verificar las especificaciones de requisitos, 4) Organizar los requisitos en un SRS, y 5) Verificar el SRS.

CLIENT-USER
Notion: CLIENT-USER - Person or group of persons, belonging to UofD, who Notion: CLIENT-USER interacts with the requirements engineer - Person or group of persons, belonging to UofD, who Notion: Behavioral Response: interacts with the requirements engineer - Person or group of persons, belonging toin UofD, who - He supplies the documentation or he participates Behavioral Response: interacts with the requirements engineer the interviews - He supplies the documentation or he participates in Behavioral Response: - He participates in the LEL validation the interviews - He supplies documentation or he participates in - He participates in the the scenarios validation - He participates in the LEL validation the interviews - He participates in the scenarios validation - He participates in the LEL validation - He participates in the scenarios validation
T itle : G o a l: C o n te x t:
T e m p o r a l L o c a tio n : G e o g r a p h ic a l L o c a t io n : P r e c o n d itio n s :
E x c e p tio n s :

Ttu lo : O b te ne r la d o c u m e n ta c i n O b je tiv o : O btene r to da la in form ac in e s crita Ttu lo c : on que Ocb neerl c la dte o -u cu m e npa tara c i n u te enta lien s uario
rea lic e s crita que l inge niero de req itos ac r to la uis in O b je tiv o :e Ttu loO : bteneO bda te ne r form la d oin cue m e n ta c i n
O r to dareq laias in form in b efe je tiv o :e rea lic e s crita que de uis itos ac C o n te x to : O Se c ta e lninge labtene s niero de pen de nc del
Heursticas
LEL
Plantillas de Escenario y Especificacin

FICHA DE REQUISITO CANDIDATO ESPONTANEO FICHA DE REQUISITO CANDIDATO Proyecto: ____________________ ESPONTANEO Fecha: __/__/____ FICHA DE REQUISITO CANDIDATO Ingeniero de Requisitos: ________ Proyecto: ____________________ ESPONTANEO Fecha: __/__/____ Ingeniero de Requisitos: ________ Proyecto: ____________________ Descripcin:___________________ Fecha: __/__/____ ______________________________ Ingeniero de Requisitos: ________ ______________________________ Descripcin:___________________ Prioridad: Obligatorio Deseado ______________________________ ______________________________ Descripcin:___________________ Tipo: Prioridad: RF RNF : ____________ Obligatorio Deseado ______________________________ Fuente de Informacin: ____________ ______________________________ Etapa Tipo: del Proyecto: RF_______________ RNF : ____________ Prioridad: Obligatorio Deseado Observacin: ____________________ Fuente de Informacin: ____________ Etapa Tipo: del Proyecto: RF_______________ RNF: ____________ Observacin: ____________________ Fuente de Informacin: ____________ Etapa del Proyecto: _______________ Observacin: ____________________
s u tra ba jo que c u enta e l c lien te -u s uario pa ra c on
id en tific n -u de fue nte s de cac liei nte s uario in o fon rm aD ci n : ha C te x to S be e efe en la s la de pen de nc ias del e be rs ec ta rea liz a do cac lie nte -u s uario en i n ds e fue nte s de A c to re s : Ing en ieid ro d tific e re quis ito e be rm aD ci n ha be rs e rea liz a do la C lie nte in -ufo s uario id en tific ac i n d e fue nte s de Ac to:re s :u m e Ing enin ie ro d e re quis ito s R e c u rs os doc ntac in fo rm a ci n C lie nte -u s uario E p is o d io s :A c to re s : Ing en ie ro d e re quis ito s R doc um ntac inito s rec ib e toda 1.e c u rs E l os ing: enie ro de e req uis C lie nte -u s uario la d oc um en ta c i n co n que c ue nta e l E p is oR de io s c u:rs os : doc u m e ntac in c lie nte -u uario . ro 1. E ls ing enie d e req uis ito s rec ib e toda 2. Ep l ing enie ro uis ito en o njun to nta e l E is o d io sd :e req la d oc um en ta c i ns co nc que c ue a la i lauis ito s rec ib e toda c on el c te-u 1. Es l uario ing enie de s req clien lie nte -u s uario .evro doc u m e ibid re sp on de a la rec d oc um en ta c i ns co nc que c ue 2. Entac l ingin enie ro d e a req uis ito en o njun to nta e l la s e xp c ec tativ as . nte clien lie -us suario uario .ev a la s i la on el c te-u E x c e pc io n e s : 2. Entac l ingin enie ro ibid de a req ito s en doc u m e rec reuis sp on de a c o njun to on el as c lien la s e xp c ec tativ . te-u s uario ev a la s i la E x c e pc io n e s : doc u m e ntac in rec ibid a re sp on de a la s e xp ec tativ as .
be be rs e rea liz a do C o n teD xe to : ha Se efe c ta en la s la de pen de nc ias del s u tra ba jo
c jo on que c u enta e l c lien te -u s uario pa ra su tra ba c lie nte -u s uario que e l inge niero de req uis itos rea lic e
Verificar SRS
E x c e pc io n e s :
Escenarios Futuros
UdeD
Extraer Requisitos
Asignar Atributos
Organizar SRS
Fichas Especificacin de Requisito

Ttu lo : O b te ne r la d o c u m e n ta c i n O b je tiv o : O btene r to da la in form ac in e s crita Ttu lo c : on que Ocb neerl c la dte o -u cu m e npa tara c i n u te enta lien s uario
que l inge niero de req itos ac rea lic e s crita O b je tiv o :e r to la uis in Ttu loO : bteneO bda te ne r form la d oin cue m e n ta c i n O r to dareq laias in form in b efe je tiv o :e que de uis itos ac rea lic e s crita C o n te x to : O Se c ta e lninge labtene s niero de pen de nc del be be rs e rea liz a do C o n teD xe to : ha Se efe c ta en la s la de pen de nc ias del s u tra ba jo s u tra ba jo que c u enta e l c lien te -u s uario pa ra c on c jo on que c u enta e l c lien te -u s uario pa ra su tra ba c lie nte -u s uario que e l inge niero de req uis itos rea lic e
Verificar Especificaciones
id en tific n -u de fue nte s de cac liei nte s uario in o fon rm aD ci n : ha C te x to S be e efe en la s la de pen de nc ias del e be rs ec ta rea liz a do cac lie nte -u s uario en i n ds e fue nte s de A c to re s : Ing en ieid ro d tific e re quis ito e be rm aD ci n ha be rs e rea liz a do la C lie nte in -ufo s uario id en tific ac i n d e fue nte s de Ac to:re s :u m e Ing enin ie ro d e re quis ito s R e c u rs os doc ntac in fo rm a ci n C lie nte -u s uario E p is o d io s :A c to re s : Ing en ie ro d e re quis ito s R e c u rs os : doc u m e ntac in 1. E l ing enie ro d e req uis ito s rec ib e toda C lie nte -u s uario la d oc um en ta c i n co n que c ue nta e l E p is oR de io cs u:rssos : doc u m e ntac in c lie nte -u uario . ro d e req uis ito s rec ib e toda 1. E l ing enie 2. Ep l ing enie ro uis ito en o njun to nta e l E is o d io sd :e req la d oc um en ta c i ns co nc que c ue c on el c te-u a la i lauis ito s rec ib e toda 1. Es l uario ing enie de s req clien lie nte -u s uario .evro doc u m e ibid re sp on de a la rec d oc um en ta c i ns co nc que c ue 2. Entac l ingin enie ro d e a req uis ito en o njun to nta e l la s e xp c ec tativ as . nte clien lie -us suario uario .ev a la s i la on el c te-u Entac l ingin enie ro ibid de a req ito s en doc u m e rec reuis sp on de a c o njun to E x c e pc io n e s : 2. on el as c lien la s e xp c ec tativ . te-u s uario ev a la s i la E x c e pc io n e s : doc u m e ntac in rec ibid a re sp on de a la s e xp ec tativ as .
E x c e pc io n e s :
SRS
Figura 44. Proceso de Creacin del Documento de Requisitos Este proceso no requiere una validacin pues toda la informacin que se maneja en l proviene de una fase anterior ya validada, excepto la asignacin de prioridades, pero esta actividad se logra por consenso en reuniones. Mientras que s se requiere una verificacin para comprobar la correcta extraccin de requisitos y generacin del SRS.

A continuacin se detallan las actividades graficadas en la Figura 44.
(1) Extraer Requisitos

Esta actividad tiene por objetivo generar una lista de requisitos nicos del sistema de software, lo ms completa posible. Incluye extraer los requisitos de cada EF y eliminar requisitos repetidos de la lista. Los requisitos se obtienen de
varios componentes de los escenarios, sub-escenarios y escenarios excepcin, siguiendo un conjunto de guas de extraccin. Los escenarios futuros integradores solo son considerados para extraer RNF que tienen un amplio alcance, dado que engloban informacin que se expande hacia escenarios de menor nivel. Cabe mencionar que durante esta actividad, se identifican trazas bidireccionales, las cuales establecen la relacin entre el requisito y el EF de donde se extrajo. Las trazas deberan contener informacin de la regla de extraccin utilizada y el componente del escenario origen. Cuando el mismo requisito se extrae de ms de un escenario, se deben producir trazas del requisito a cada escenario origen.
Reglas de Extraccin de Requisitos desde Escenarios Futuros

Las guas de extraccin de requisitos se clasifican en funcionales y no funcionales. Los escenarios integradores solo son examinados en la regla RNF.R5.
RF.R1> Los RF se capturan principalmente de episodios donde el sistema de software est involucrado, ignorando los episodios que son sub-escenarios. La sentencia del requisito debe enfatizar lo que sistema har o proveer. Los requisitos derivados de esta regla se pueden escribir usando dos tipos de estructuras sintcticas: SP1. SP2. El sistema debe <realizar una accin> El sistema debe <proveer una respuesta>
Frecuentemente, las acciones o respuestas involucran el uso de datos: colecciones de datos o atributos de datos. Esto implica que de un mismo episodio se puede extraer ms un requisito. Los requisitos que involucran datos seguirn uno de estas estructuras sintcticas: SP3. SP4. El sistema debe administrar <repositorio de datos> El sistema debe administra los siguientes <atributos de datos> de <repositorio de datos>
- 126 -
Ejemplo: Episodio: El sistema emite un recibo por cargo. RF: El sistema debe imprimir el recibo por cargo. RF: El sistema debe administrar el repositorio de recibos por cargo. Ejemplo: Episodio: El empleado de la Administracin ingresa los datos del pedido de service en el sistema. RF: El sistema debe proveer una interfaz para el ingreso de datos del pedido de service. RF: El sistema debe administrar el repositorio de pedidos de service.
RF.R2> Los RF tambin se obtienen de las excepciones cuando el tratamiento de la excepcin es una sentencia simple y el sistema de software tiene un rol, similar a la regla RF.R1. Aqu, se usan tambin los mismos patrones sintcticos.
Ejemplo: Tratamiento de la Excepcin: El sistema notifica la fecha vencida para retirar el pasaporte antes de su destruccin. RF: El sistema debe notificar acerca de los pasaportes con fecha vencida para retirar. RF: El sistema debe administrar la fecha de vencimiento para el retiro de pasaportes en el repositorio de pasaportes emitidos.
RF.R3> Las condiciones de episodios pueden involucrar atributos y/o valores de datos, estados de datos, o acciones del sistema. Estas condiciones pueden convertirse en requisitos. La condicin o parte de ella se convierte en un RF si el sistema debe gestionar esos datos o el sistema debe realizar una accin.
Ejemplo: Condicin de Episodio: Si el procedimiento es un nuevo pasaporte entonces el sistema RF: El sistema debe administrar el tipo de procedimiento con estado: nuevo pasaporte. Ejemplo:
- 127 -
Condicin de Episodio: Si es la segunda vez que el equipo es chequeado entonces el sistema RF: El sistema debe administrar la cantidad de chequeos que se le realizan a los equipos.
Cuando la condicin se refiere al xito o fracaso de una accin, el episodio condicional puede realmente involucrar dos episodios: la accin en la condicin ms la accin en el episodio mismo. Esto puede considerarse como la abreviacin del discurso. Luego:
- Si accin1 entonces accin2 - accin1 - Si verdadera entonces accin2 Ejemplo: Si el sistema encuentra que el equipo no tiene asignado un nmero de pedido entonces ASIGNAR NMERO DE PEDIDO DE COMPRA. El sistema busca el nmero de pedido asignado al equipo. Si no tiene asignado, entonces ASIGNAR NMERO DE PEDIDO DE COMPRA. RF: El sistema debe verificar la asignacin de nmero de pedido al equipo.
Por lo tanto, las estructuras sintcticas de requisitos derivados de esta regla pueden ser: SP5. SP6. SP7. SP8. El sistema debe administrar <atributos de datos> El sistema debe administrar <estado de datos> El sistema debe verificar <estado de datos / valores de datos> El sistema debe <realizar una accin de verificacin>
RF.R4> Las causas de excepciones tambin pueden verse como condiciones. Por lo tanto, merecen el mismo tratamiento que en la regla anterior, aplicando las mismas estructuras sintcticas. Cuando la causa de una excepcin implcitamente involucra un RF, esto frecuentemente significa que el sistema de
software debe realizar alguna verificacin. A continuacin se presentan algunos ejemplos usando el patrn sintctico SP8:
Ejemplo: Causa de excepcin: El sistema no reconoce el nmero de formulario de solicitud. RF: El sistema debe verificar la existencia del nmero de formulario de solicitud. Ejemplo: Causa de excepcin: El pasaporte emitido no ha sido retirado antes de los 60 das. RF: El sistema debe verificar que la fecha de emisin del pasaporte no supere 60 das de la fecha actual cuando el solicitante pase a retirar el pasaporte
RF.R5> Un RF puede derivarse de un repositorio de datos mencionado en un EF, ya sea en un episodio o en el componente Recursos, y se utilizar el patrn sintctico SP3. Claramente se descartan aquellos recursos no asociados al sistema. En el componente Recursos no solo aparecen repositorios, tambin a veces figuran atributos; esto ltimo ocurre cuando dichos atributos son muy relevantes. Los atributos se mencionan frecuentemente en episodios que involucran al sistema cuando se ingresan datos, se buscan datos, se muestran datos, o acciones similares. Cuando el recurso es un smbolo del LEL del tipo Objeto, entonces atributos y caractersticas del repositorio de datos pueden detectarse en la nocin del smbolo y, menos frecuentemente, en el impacto. Los atributos identificados se registran como parte de un RF utilizando el patrn sintctico SP4.
Ejemplo: Recurso: Pedido de service. Atributos extrados de episodios de un EF: datos del equipo, necesidad de presupuesto, materiales necesarios, tiempo estimado de reparacin, costo de reparacin, service estimado, service a ser reparado, service demorado, service a ser entregado,
- 129 -
Atributos extrados de smbolos del LEL: nmero secuencial, cliente, descripcin del equipo, nmero de serie del equipo, estado (service presupuestado, service a ser reparado, service demorado, service a ser entregado, service entregado) RF: El sistema debe administrar la siguiente informacin: nmero secuencial, cliente, datos del equipo, indicador de presupuesto requerido, lista de materiales, tiempo estimado de reparacin, costo de reparacin, estado. Posibles valores del estado del Pedido de service: service estimado, service a ser reparado, service demorado, service a ser entregado, service entregado y service cancelado.
RNF.R1> Los RNF se obtienen principalmente de las Restricciones asociadas a episodios donde el sistema de software participa.
Ejemplo: Restriccin de Episodio: El clculo no debe exceder los 10 segundos. RNF: El sistema debe calcular el costo del trmite de emisin de pasaporte en no ms de 10 segundos.
Las reglas RNF.R1, RNF.R2, RNF.R3 y RNF.R5 usan una estructura sintctica comn que debe especializarse segn el tipo de RNF: SP9. El sistema debe <poseer caractersticas o limitaciones>
RNF.R2> Tambin se pueden identificar RNF en la causa de excepciones. Dos ejemplos de causas de excepciones que proveen RNF son:
Ejemplo: Causa de excepcin: El sistema no puede conectarse con el servidor de estadsticas. RNF: El sistema debe ser capaz de establecer conexin con el servidor de estadsticas. RF: El sistema debe verificar la disponibilidad de conexin con el servidor de estadsticas. Ejemplo: Causa de excepcin: Problemas con el servicio de Internet.
- 130 -
RNF: El sistema debe ser accesible desde Internet.
RNF.R3> RNF pueden ser inferidos de recursos de escenarios. Cuando el recurso es un smbolo del LEL del tipo Objeto, algunas caractersticas pueden extraerse de la nocin del smbolo. La informacin del LEL puede permitir que se derive un RNF. Por ejemplo:
Ejemplo: Recurso: Medio de comunicacin. RNF: El sistema debe poder conectarse por algn medio de comunicacin (e-mail o fax) con todos los convocados a la reunin. Ejemplo: Recurso: Archivo de lanzamiento. Nocin del Smbolo del LEL: El archivo de lanzamiento es un archivo sin formato que contiene todos los prstamos concedidos en el plazo de lanzamiento. Cada agente de seguros usa un formato de archivo especfico. RNF: El sistema debe reconocer los diferentes formatos del archivo de lanzamiento dependiendo del agente de seguros.
RNF.R4> Cuando hay episodios no secuenciales (marcados en el escenario con el carcter especial #) que involucran al software como un actor, esto puede que el software debe proveer alguna capacidad especial. Por ejemplo, puede ser requerida la concurrencia de varias funciones del sistema, con lo cual un RNF puede crearse en base a esta condicin. El patrn sintctico a usarse es: SP10. El sistema debe concurrentemente <realizar una lista de acciones>
Ejemplo: Episodios: # El sistema mensualmente calcula las estadsticas de compras por material prima y por proveedor. El sistema mensualmente calcula las estadsticas de venta por producto y por cliente. #
- 131 -
RNF: El sistema debe concurrentemente calcular las estadsticas mensuales de compra y de venta.
RNF.R5> Las restricciones asociadas a episodios pertenecientes a escenarios integradores se examinan para capturar RNF. En este tipo de escenarios, los episodios son en s mismos escenarios, por lo tanto, cualquier RNF extrado de ellos se aplica al sistema en su totalidad o a gran parte de l.
Ejemplo: Restriccin: Todo usuario del sistema debe ser un usuario de la intranet. RNF: El sistema debe reconocer a los usuarios de la intranet permitiendo que solo ellos tengan acceso.
Ejemplo: Restriccin: El sistema debe ser desarrollado usando el motor de MySQL y poder posteriormente ser portable a otro motor de base de datos. RNF: El sistema debe tener una capa de acceso a datos proveyendo acceso a MySQL, con facilidad de portabilidad futura hacia otros DBMS.
Lmite de las Reglas de Extraccin

Esto no significa que cada uno de estos componentes del escenario sea siempre un requisito, es justamente en esta actividad en la que se determina cules de las partes presentes en los EF son efectivamente requisitos. Hay tres posibles resultados en el mecanismo de extraccin: i) Se extrae directamente un requisito (ES), ii) Puede inferirse un requisito, es decir, hay una indicacin de un posible requisito (PUEDE INFERIRSE), o iii) Puede ser un requisito, requirindose informacin adicional para efectivamente derivar un requisito (PUEDE SER). Cualquiera sea el caso, no hay necesidad de elicitar nueva informacin. La
- 132 -
Figura 45 muestra un ejemplo de lista de requisitos extrada de un solo escenario futuro, donde se aprecian cuatro RF y un RNF (caso Sistema Nacional para la Obtencin de Pasaporte).
Escenario Futuro
Ttulo: COBRAR TRAMITE Objetivo: Cobrar el trmite al solicitante. Contexto: Ubicacin Geogrfica: sector Caja Ubicacin Temporal: lunes a viernes de 8:00 a 18:00 horas Precondicin: El solicitante debi completar el formulario y pasar por el control de documentacin. El formulario debe tener los datos del solicitante y la marca del tipo de trmite. Recursos: formulario Actores: Solicitante, Cajero, Sistema de Software Episodios: 1. El solicitante se presenta con el formulario en la Caja. 2. El cajero ingresa el nmero del formulario al Sistema de Software. 3. El Sistema de Software busca el formulario e informa el importe del trmite. Restriccin: El clculo no debe exceder los 10 segundos. 4. El solicitante paga el importe. 5. El cajero ingresa los datos de pago del formulario en el Sistema de Software. 6. El Sistema de Software actualiza los datos de pago del formulario. 7. El Sistema imprime un recibo de pago del trmite. 8. El cajero entrega el formulario y el recibo al solicitante. Excepciones: El Sistema de Software no reconoce el nmero de formulario (CARGAR FORMULARIO PROVISORIO.
Requisitos del EF
El sistema debe verificar la existencia del nmero de formulario. (RF) El sistema debe calcular el importe de un trmite segn el nmero de formulario. (RF) El sistema debe realizar el clculo del importe del trmite antes de 10 segundos. (RNF) El sistema debe registrar los datos de pago de un trmite. (RF) El sistema debe emitir un recibo de pago de trmite. (RF)
Figura 45. Ejemplo de lista de requisitos de un escenario futuro En la Tabla 3 se resumen los posibles tipos de requisitos a extraer de los EF y se identifica el tipo de extraccin. En la Tabla 4 se presentan ejemplos de requisitos funcionales extrados de cada componente de EF, y en la Tabla 5 ejemplos de requisitos no funcionales. Se puede observar en los ejemplos de esta Tabla que existen palabras o frases subrayadas, ellas representan vnculos a smbolos del LEL.
- 133 -
Tabla 3. Tipos de requisitos extrados de escenarios futuros

Tipo Regla Componente del Escenario Episodios donde el sistema participa como actor Tratamiento de Excepciones donde el sistema participa como actor Condicin de Episodios Causa de Excepciones Relacin ComponenteRequisito ES Patrn Sintctico SP1, SP2, SP3, SP4 SP1, SP2, SP3, SP4 SP5, SP6, SP7, SP8 SP5, SP6, SP7, SP8 SP3, SP4
RF.R1
Requisito Funcional
RF.R2
ES PUEDE INFERIRSE o PUEDE SER (accin) PUEDE INFERIRSE PUEDE SER (RF de datos) PUEDE SER
RF.R3
RF.R4
RF.R5
Recursos Restriccin de Episodios donde el sistema participa como actor Causa de Excepciones
RNF.R1 Requisito No Funcional
SP9
RNF.R2
PUEDE INFERIRSE
SP9
RNF.R3
Recursos Episodios No secuenciales donde el sistema participa como actor Restriccin en Escenarios Integradores
PUEDE INFERIRSE
SP9
RNF.R4
PUEDE INFERIRSE
SP10
RNF.R5
PUEDE SER
SP9
El objetivo del EF no se utiliza como posible contenedor de requisitos. Estos objetivos pueden representar las grandes funcionalidades del sistema, siempre y cuando el actor sistema de software tenga una participacin importante en los episodios del escenario. Por lo tanto, ellos pueden abarcar varios requisitos del sistema de software, pudiendo utilizarse esta relacin para establecer dependencias entre ellos.
- 134 -
Tabla 4. Ejemplos de RF extrados de escenarios futuros

Tipo Componente RF.R1 Episodios donde participa el actor Sistema Ejemplo El Sistema de Software imprime un recibo de pago del trmite. RF: El Sistema de Software debe imprimir un recibo de pago del trmite. RF.R2 Solucin de El Sistema de Software enva un mensaje sobre el Excepcin donde lmite de fecha para la incineracin de un pasaporte. participa el actor RF: El Sistema de Software debe enviar un mensaje Sistema sobre el lmite de fecha para la incineracin de un pasaporte. RF.R3 Condiciones Si <<el equipo no tiene asignado nmero de de Episodios donde pedido>> entonces El Sistema de Software participa el actor Si <<el tipo de trmite es pasaporte original>> Sistema entonces el Sistema de Software Si <<es el segundo chequeo del equipo>> entonces el Sistema de Software El Sistema de Software no reconoce el nmero de RF.R4 formulario. Causa de RF: El Sistema de Software debe verificar la Excepciones existencia del nmero de formulario Algn dato del convocado es invlido o nulo. RF: El Sistema de Software debe verificar los datos del convocado. El pasaporte emitido no es retirado antes de los 60 das. RF: El Sistema de Software debe verificar que la fecha de emisin del pasaporte no supere 60 das de la fecha actual cuando el solicitante pase a retirar el pasaporte. Recurso: pedido de service. Atributos del smbolo del LEL RF: El Sistema debe administrar la siguiente informacin: nmero secuencial, cliente, datos del equipo, lista de materiales, tiempo estimado, costo de reparacin, estado. Valores posibles de estado:
Requisito Funcional
RF.R5 Recursos
Una vez extrados los requisitos de cada EF, debe controlarse la existencia de redundancia de los mismos. Es muy frecuente que un requisito est presente en ms de un escenario. Por ejemplo el requisito El sistema debe permitir la seleccin de un cliente por apellido, por tipo o por localidad puede presentarse en ms de un escenario donde debe realizarse alguna tarea vinculada a un cliente. Luego a partir de esta actividad, se obtiene una lista de requisitos nicos.
- 135 -
Tabla 5. Ejemplos de RNF extrados de escenarios futuros

Tipo Componente RNF.R1 Restriccin donde en el episodio participa el actor Sistema Ejemplo El Sistema de Software busca el formulario e informa el importe del trmite. Restriccin: El clculo no debe exceder los 10 segundos. RNF: El Sistema de Software debe realizar el clculo del importe del trmite antes de 10 segundos. Existen problemas en el servicio de internet. RNF: El sistema debe poder accederse desde internet. El sistema no se puede conectar al servidor donde se encuentran las estadsticas. RNF: El sistema debe establecer conexin con el servidor de estadsticas. Medio de comunicacin. RNF: El sistema debe poder conectarse por algn medio de comunicacin (e-mail) con todos los convocados a una reunin. # El sistema calcula estadsticas de compra mensual por materia prima y por proveedor.El sistema calcula las estadsticas de venta mensual por producto y por cliente. # RNF: El sistema debe calcular concurrentemente las estadsticas de compra mensual y las estadsticas de venta mensual. Restriccin: Usar el motor MySQL con posibilidad futura de pasar a otro DBMS.RNF: El sistema debe tener una capa de acceso a datos para proveer acceso a MySQL con portabilidad futura a otro DBMS.
RNF.R2 Causa de Excepciones Requisito No Funcional
RNF.R3 Recursos
RNF.R4 Episodios No Secuenciales
RNF.R5 Restriccin en Escenarios Integradores
Recomendaciones para describir cada requisito (algunas han sido extradas de [Hull 05]):
Redactar utilizando la forma El sistema debe , con lo cual se identifica claramente la capacidad o la condicin que el sistema de software brindar o acatar. No incluir ms de un requisito en cada sentencia. Evitar el uso de la frase de ser necesario, pues debe quedar claro bajo qu condiciones opera el requisito. Evitar palabras ambiguas como generalmente, frecuentemente, rpido, flexible, amigable, preferible. Evitar deseos ilimitados en las capacidades del sistema de software, por ejemplo bajo cualquier plataforma, independiente del motor de base de datos, 100% confiable, sin fallas.

- 136 -
Para RNF, incluir valores de medicin. Se puede describir el valor deseado y el valor mximo o mnimo aceptable.
(2) Asignar Atributos a Requisitos

En esta actividad se completan, a partir de la lista de requisitos, las especificaciones de los requisitos. Adems de la descripcin del requisito, los restantes atributos se completan con informacin elicitada del UdeD y de las Fichas de Informacin Adelantada registradas en etapas anteriores. Estas especificaciones presentan vnculos al LEL, pues por un lado parte de la informacin proviene de los EF descriptos usando el LEL y la descripcin de la nueva informacin debe respetar tambin el uso de los smbolos del LEL. El fundamento puede describirse teniendo en cuenta el rol que juega el requisito en la satisfaccin del escenario de donde se extrajo. Adems, alguna Ficha de Informacin Adelantada puede proveer alguna informacin sobre la utilidad o necesidad del requisito. Los clientes establecen la volatilidad, prioridad, criticidad, factibilidad y riesgo para cada requisito, asistidos por los ingenieros de requisitos, mientras que el costo de implementacin es determinado por los ingenieros de requisitos con soporte del equipo de desarrollo. Se realizan reuniones para determinar la importancia relativa que tiene un requisito para los clientes y usuarios, y para organizar aquellos requisitos que deben implementarse inicialmente frente a aquellos que pueden postergarse. Se deben tener en cuenta, adems de la dependencia de los requisitos, la diversidad de intereses de los clientes y usuarios, las limitaciones de recursos, las necesidades del negocio y las imposiciones del mercado, entre otros factores. Existen variadas tcnicas de priorizacin de requisitos, como por ejemplo: AHP (Analytic Hierarchy Process) [Saaty 80], QDF (Quality Function Deployment) [Zultner 92] y EVOLVE [Greer 05]. En [Hadad 09b] se presenta una heurstica de asignacin de prioridades que se basa en una divisin de objetivos del sistema, donde se priorizan los sub-objetivos de menor nivel y por transitividad se asocia cada requisito a la satisfaccin del sub-objetivo.
- 137 -
La tarea de dar prioridades puede realizarse previamente al describirse los EF, dando prioridad a los mismos, pues puede ser una tarea ms fcil que priorizar cada requisito individualmente, ya que muchos de ellos estn interrelacionados y deben considerarse sus prioridades en simultneo.
(3) Verificar las Especificaciones

La actividad de verificacin debe comprobar que la extraccin de requisitos desde los EF fue realizada exhaustivamente y que la asignacin de atributos, incluyendo la tcnica de priorizacin, fue correctamente realizada. La tcnica de verificacin sugerida es la inspeccin, o tambin walkthrough (revisin interna informal) con una lista de control. Se genera a partir de esta actividad una lista de DEOs para corregir las especificaciones. Con la lista de defectos se vuelve a las actividades Extraer Requisitos o Asignar Atributos, segn el tipo de defectos encontrados. Los aspectos principales que cubre la verificacin son: Verificar la sintaxis:

Detectar el uso de ms de un verbo en la descripcin del requisito. Detectar el uso de adjetivos subjetivos. Detectar el uso de frases ambiguas o subjetivas (cuyo significado dependa del interlocutor). Detectar atributos nulos en la especificacin. Controlar la aplicacin de las guas de extraccin: todo requisito debe provenir de un componente de EF.
Verificar contra los componentes del EF:

Verificar atributos:

Controlar que todo requisito se haya fundamentado y clasificado. Controlar que prioridad, criticidad, factibilidad, riesgo y costo asignados a un requisito estn dentro de los rangos establecidos. Controlar que prioridad, criticidad, factibilidad, riesgo y costo del requisito sean consistentes segn su dependencia con otros requisitos. Controlar la tcnica de asignacin de prioridades se aplic
- 138 -
correctamente. Este tem debe detallerse de acuerdo a la tcnica empleada. Verificar referencias al LEL:
Controlar que todo smbolo del LEL es identificado al mencionarse en un requisito. Controlar el uso correcto de smbolos del LEL de acuerdo a su definicin dada en el lxico .
(4) Organizar el SRS

Los requisitos se describen en un documento segn el formato de SRS impuesto por el cliente o adoptado por el equipo de desarrollo, a partir de las especificaciones generadas. El propsito principal es organizar los requisitos de manera tal de obtener el mximo de legibilidad. Deben mantenerse en el SRS vnculos al LEL, como una forma de reducir la ambigedad del documento escrito en lenguaje natural. Adicionalmente, se mantienen vnculos a los EF para mantener la pre-trazabilidad de los requisitos. Debe adems considerarse que muchos requisitos estn relacionados con otros, en muchos casos se trata de RNF con RF. El mantenimiento de estos vnculos permite la inter-trazabilidad. Si se considera el formato presentado [IEEE Std 830-1998], entonces gran parte de sus secciones pueden completarse con la informacin registrada en los modelos, como se describe a continuacin (ver Figura 46). La seccin 1.2 del SRS Alcance del Proyecto incluye el nombre del proyecto que puede obtenerse del ttulo del escenario futuro integrador de nivel 0, y el objetivo del producto que se obtiene del documento de objetivos y alcance del sistema, incluyendo sub-objetivos obtenidos al priorizar, o de los objetivos de los escenarios integradores. En la seccin 1.3 del SRS Definiciones, acrnimos y abreviaturas puede hacerse referencia al LEL. En la seccin 1.4 Referencias se indicarn referencias al conjunto de EA, de EF y al LEL. La seccin 2.1 Perspectiva del Producto se completa con informacin acerca de interfaces de sistema proveniente de actores o recursos de EF que representan otros
- 139 -
sistemas involucrados. La seccin 2.2 Funciones del producto se puede completar con los objetivos de los EF donde participa el sistema como actor importante. En la seccin 2.3 Caractersticas de los usuarios se puede completar con los actores de los EF que interactan con el software y vincularlos con los respectivos smbolos tipo Sujeto del LEL. Dependiendo del criterio adoptado de organizacin del SRS, algunos requisitos asociados con decisiones de diseo pueden incluirse en la seccin 2.4 Limitaciones Generales; dicha informacin se obtiene de las especificaciones de RNF que se extrajeron de EF Integradores. La seccin 3 Requisitos Especficos incluye todos los requisitos extrados de los EF, donde podrn organizarse por su tipo, por el EF origen, por prioridad, por Actor del EF, o teniendo en cuenta algn criterio dado en el Anexo A de IEEE Std.830, entre otros criterios.
IEEE/ANSI 830-1998 1. Introduccin 1.1. Propsito 1.2. Alcance 1.3. Definiciones, acrnimos u abreviaturas 1.4. Referencias 1.5. Resumen del resto del documento 2. Descripcin General 2.1. Perspectiva del Producto 2.2. Funciones del Producto 2.3. Caractersticas de Usuarios 2.4. Limitaciones Generales 2.5. Suposiciones y Dependencias 3. Requisitos Especficos Apndices ndice
Documento de Objetivos y Alcance, o Ttulo/Objetivo de EF Integradores Una copia del LEL o referencia Referencias al LEL, EA, EF Actores o recursos de EF que representan a otros sistemas Objetivos de los EF Actores de EF que representan personas Especificaciones de RNF extrados de EF Integradores Especificaciones de Requisitos Fichas de Informacin Adelantada
Figura 46. Completar un SRS con informacin de los modelos Algunas Fichas de Informacin Adelantada pueden an no haber sido procesadas por contener informacin tal como: cantidades, frecuencias u otras medidas. Esta informacin debe ubicarse con el requisito correspondiente en la seccin 3 del SRS. Dichas fichas son luego marcadas como procesadas. Al finalizar esta actividad, todas las Fichas de Informacin Adelantada deben haberse procesado o eventualmente descartado.
- 140 -
(5) Verificar el SRS

Esta segunda actividad de verificacin tiene como propsito establecer la correctitud del documento SRS, considerando la inclusin de los requisitos identificados y el cumplimiento del estndar adoptado. Se sugieren las mismas tcnicas de verificacin que para la primera verificacin. Tambin se genera una lista de DEOs, donde se retornar a la actividad previa Organizar el SRS para realizar las correcciones necesarias. Los aspectos principales que cubre la verificacin son: Verificar la completitud del SRS:
Controlar que cada especificacin de requisito haya sido incluida en el SRS. Controlar que el SRS se ha creado de acuerdo al estndar adoptado. Controlar que toda Ficha de Informacin Adelantada fue procesada e incluida su informacin en el SRS. Controlar que los requisitos se organizaron en el SRS de acuerdo al criterio de organizacin adoptado.heck that the requirements are organized in the SRS according to the chosen criterion.

Verificar referencias al LEL:

Controlar que toda mencin a un smbolo del LEL est identificado. Controlar el uso correcto de smbolos del LEL de acuerdo a la definicin dada en el lxico .
- 141 -
Referencias
[Booch 94] Booch G, Scenarios, Report on Object Analysis and Design, 1(3): 3-6, 1994. [Breitman 01] Breitman KK, Leite JCSP, Requirements Elicitation through Scenarios, 5th IEEE International Symposium on Requirements Engineering (RE01), tutorial, Canad, Agosto 2001. [Cysneiros 04] Cysneiros LM, Yu E, Non-Functional Requirements Elicitation, en el libro Perspectives on Software Requirements, Kluwer Academic Publishers, Estados Unidos, captulo 6, 2004, pp.115-138. [DOD 5000.2-R] US Department of Defense, DoD Regulation Guidance 5000.2-R: Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs, 2002. [Doorn 02] Doorn JH, Hadad GDS, Kaplan GN, Comprendiendo el Universo de Discurso Futuro, WER02 - Workshop on Requirements Engineering, Espaa, pp.117-131, Noviembre 2002. [ESA PSS-05-0] European Space Agency Board for Software Standardisation and Control, Software Engineering Standards, DFl. 50, Issue 2, 1991. [Fagan 76] Fagan ME, Design and Code Inspections to reduce Errors in Program Development, IBM Systems Journal, 15(3):182-211, 1976. [Finkelstein 01] Finkelstein A, Savigni A, A Framework for Requirements Engineering for Context-Aware Services, 1st Intl Workshop From Software Requirements to Architectures (STRAW 01), Canad, 2001. [Gause 89] Gause DC, Weinberg GM, Exploring Requirements. Quality Before Design, Dorset House Publishing, Nueva York, 1989. [Greer 05] Greer D, Requirements Prioritisation for Incremental and Iterative Development, Requirements Engineering for Sociotechnical Systems, Information Science Publishing, Mat & Silva eds, cap. VII, 2005, pp. 100-118. [Hadad 08] Hadad GDS, Doorn JH, Kaplan GN, Creating Software System Context Glossaries, Mehdi Khosrow-Pour (ed) Encyclopaedia of
- 142 -
Information Science and Technology. IGI Global, Information Science Reference, Hershey, USA, ISBN: 978-1-60566-026-4, 2nd edn, 2008, Vol. II, pp 789-794 [Hadad 09] G.D.S. Hadad, J.H. Doorn, G.N. Kaplan, Explicitar Requisitos del Software usando Escenarios, in: 12th Workshop on Requirements Engineering (WER09), 2009, pp. 63-74. ISBN: 978-956-319-941-3 [Hadad 09b] G.D.S. Hadad, J.H. Doorn, M. Ridao, G.N. Kaplan, Facilitando la asignacin de Prioridades a los Requisitos, in: 12th Workshop on Requirements Engineering (WER09), 2009, pp. 75-84. ISBN: 978-956319-941-3 [Hull 05] Hull E, Jackson K, Dick J, Requirements Engineering. Springer Science, 2 edicin, 2005. [IEEE Std 830-1998] IEEE Recommended Practice for Software Requirements Specifications (ANSI), NY, 1998. [IEEE Std P1233/D3-1995] IEEE Guide for Developing System Requirements for Specifications, IEEE, NY, 1995. [ISO 25010:2011] ISO/IEC FCD 25010, (2011) Software engineering -Software product Quality Requirements and Evaluation (SQuaRE) -Quality model and guide. [Kaplan 00] Kaplan GN, Hadad GDS, Doorn JH, Leite JCSP, Inspeccin del Lxico Extendido del Lenguaje, WER00 III Workshop on Requirements Engineering, Brasil, 2000, pp.70-91. [Kerkow 05] Kerkow D, Drr J, Paech B, Olsson T, Koenig T, Elicitation and Documentation of Non-Functional Requirements for Sociotechnical Systems, captulo XVII, Information Science Publishing, Mat & Silva editores, Londres, 2005, pp.284-302. [Kotonya 98] Kotonya G, Sommerville I, Requirements Engineering: Process and Techniques, John Wiley & Sons, 1998. [Leite 00] Leite JCSP, Hadad GDS, Doorn JH, Kaplan GN, A Scenario Construction Process, Requirements Engineering Journal, SpringerVerlag London Ltd., 5(1):38-61, 2000. [Leite 04] Leite JCSP, Doorn JH, Kaplan GN, Hadad GDS, Ridao MN, Defining System Context using Scenarios, en el libro Perspectives on Software Requirements, Kluwer Academic Publishers, EEUU, ISBN: 1-4020Estrategia en la Ingeniera de Requisitos Hadad GDS - 143 -
7625-8, captulo 8, 2004, pp.169-199. [Leite 05] Leite JCSP, Doorn JH, Hadad GDS, Kaplan GN, Scenario Inspections, Requirements Engineering Journal, Vol.10, N 1, SpringerVerlag London Ltd., Gran Bretaa, 2005, pp.1-21. [Leite 90] Leite JCSP, Franco APM, O Uso de Hipertexto na Elicitaao de Linguagens da Aplicaao, IV Simpsio Brasilero de Engenharia de Software, SBC, Brasil, 1990, pp.134-149. [Leite 93] Leite JCSP, Franco APM, "A Strategy for Conceptual Model Acquisition", IEEE First International Symposium on Requirements Engineering, RE93, IEEE Computer Society Press, EEUU, 1993, pp.243-246. [Malinowski Rubio 01] Malinowski Rubio MP, Cuando hay que traducir del espaol al espaol, VII Simposio Internacional de Comunicacin Social, Cuba, 2001, pp. 491-494. [NCC 87] National Computing Centre, The STARTS Guide: A Guide to Methods and Software Tools for the Construction of Large Real-Time Systems, 1987. [Porter 95] Porter AA, Votta Jr LG, Basili VR, Comparing Detection Methods for Software Requirements Inspections: A Replicated Experiment, IEEE TSE, 21(6):563-575, 1995. [Saaty 80] Saaty TL, The Analytic Hierarchy Process, McGraw-Hill, 1980. [Sommerville 05] Sommerville I, Ingeniera del Software, Pearson Educacin, 7 edicin, ISBN: 9788478290741, 2005. [Whitten 03] Whitten J, Bentley L, Dittman K, Systems Analysis and Design Methods, Mc Graw-Hill / Irwin, 6 edicin, 2003. [Young 04] Young RR, The Requirements Engineering Handbook, Artech House, Norwood, MA, 2004. [Zorman 95] Zorman L, Requirements Envisaging by Utilizing Scenarios (Rebus), Ph.D. Dissertation, University of Southern California, 1995. [Zultner 92] Zultner R, Quality Function Deployment (QFD) for Software: Structured Requirements Exploration, Total Quality Management for Software, eds Schulmeyer & McManus, Van Nostrand Reinhold, 1992, pp. 297-317.
- 144 -

Estrategia en La Ingenieria de Requisitos - 2013

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Estrategia en La Ingenieria de Requisitos - 2013

Enviado por

Direitos autorais:

Formatos disponíveis

Notas de Clase: Estrategia en la Ingeniera de Requisitos Orientada al Cliente

Dra. Graciela D.S. Hadad Marzo 2013

Estrategia en la Ingeniera de Requisitos Hadad GDS

7.4.1. 7.4.2. 7.4.3. 7.4.4. 7.4.5. 7.5. 8. 8.1. 8.2. 8.3.

Referencias .................................................................................................... 142

Estrategia en la Ingeniera de Requisitos Hadad GDS

Comprender el UdeD Actual

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

3. Modelos y registros utilizados

Modelo del LEL

Estrategia en la Ingeniera de Requisitos Hadad GDS

+ significa composicin, {x} significa cero o ms ocurrencias de x, | representa or

Figura 3. Modelo del Lxico Extendido del Lenguaje

Estrategia en la Ingeniera de Requisitos Hadad GDS

Figura 4. Modelo de Escenario

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Modelo de Especificacin de Requisitos

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Figura 8. Ejemplos de Especificaciones de Requisitos

Ficha de Informacin Anticipada

Estrategia en la Ingeniera de Requisitos Hadad GDS

Estrategia en la Ingeniera de Requisitos Hadad GDS

4. Comprensin del Vocabulario del UdeD

Estrategia en la Ingeniera de Requisitos Hadad GDS

Finalidad de Crear el LEL

Estrategia en la Ingeniera de Requisitos Hadad GDS

Smbolo del LEL

Smbolo del LEL

Figura 10. Ejemplo de la vista hipertexto entre el LEL, Escenarios y SRS

Estrategia en la Ingeniera de Requisitos Hadad GDS

Proceso de Creacin del LEL

Estrategia en la Ingeniera de Requisitos Hadad GDS

Nam e / Synonym N o tio n :

Objetivos del Sistema

Modelo del LEL

Plant Supervisor Personal Chief Contract

Truck Dispatcher Enterprise Documents Legal Documentation

Lista de Fuentes de Informacin

Fichas Informacin Anticipada

Actividades del Proceso

A continuacin se detallan las actividades graficadas en la Figura 11.

Estrategia en la Ingeniera de Requisitos Hadad GDS

Objetivos del Sistema

Identificar Fuentes de Informacin

Evaluar Fuentes de Informacin

Lista de Fuentes de Informacin

Figura 12. Actividad Planear en el proceso del LEL

(1.1) Identificar Fuentes de Informacin

Estrategia en la Ingeniera de Requisitos Hadad GDS

(1.2) Evaluar Fuentes de Informacin

(1.3) Seleccionar Estrategias

(2) Recolectar Smbolos

Estrategia en la Ingeniera de Requisitos Hadad GDS