la especificación de requerimientos ... v 2.3

Facultad de Ciencias Econmicas y de Administracin, Universidad de la Repblica, Uruguay Unidad Acadmica Sistemas

La especificacin de requerimientos en sistemas de informacin S. M. Tenzer y N. Pequeo

Mayo 2014 - Pg. 1

La especificacin de requerimientos en sistemas de informacin

Simn Mario Tenzer, Nelson Pequeo 1 2

Marzo 2013 Mayo 2014

Unidad Acadmica Sistemas asociada al Departamento de Administracin

Unidad Acadmica Administracin y Gestin de las Organizaciones

Departamento de Administracin

1 Se agradecen comentarios al texto a [email protected]

2 Los autores agradecen los aportes de Ricardo Alvarado, Natalia Botto y Silvina Npoli.



Mayo 2014 - Pg. 2

0. INDICE 1. Introduccin ................................................................................................................................................................ 3

1.1 El clsico problema de los sistemas de informacin.......................................................................... 5

1.2 Objetivos del texto ........................................................................................................................................... 6

2. La ingeniera de requerimientos ........................................................................................................................ 6 2.1 Principales actividades de la ingeniera de requerimientos ........................................................... 7

3. Requerimientos.......................................................................................................................................................... 8 3.1. Alcance del sistema o dominio del problema ....................................................................................... 9

3.2. Requerimientos funcionales y no funcionales .................................................................................... 10

3.3. Caractersticas de los requerimientos ................................................................................................... 11

3.4. Dificultades para definir los requerimientos ...................................................................................... 11

3.5. Personal involucrado en la Ingeniera de Requerimientos ........................................................... 12

3.6. Actividades de la Ingeniera de Requerimientos ............................................................................... 13

3.7. Anlisis del Problema ................................................................................................................................... 14

3.7.1. Comprender el problema................................................................................................................... 14 3.7.2. Construir un vocabulario comn .................................................................................................... 15 3.7.3. Identificar a los involucrados .......................................................................................................... 15 3.7.4. Alcance del sistema .............................................................................................................................. 16

3.8. Evaluacin y negociacin de los requerimientos .............................................................................. 16

3.9. Especificacin de Requisitos de Software ............................................................................................ 17

3.10. Validacin de Requisitos ......................................................................................................................... 18

3.11. Evolucin de los requerimientos ........................................................................................................ 19

4. Tcnicas y herramientas ....................................................................................................................................... 20 4.1. Entrevistas y Cuestionarios ........................................................................................................................ 20

4.2. Lluvia de Ideas ................................................................................................................................................. 21

4.3. Prototipos .......................................................................................................................................................... 22

4.4. Los Casos de Uso y UML ............................................................................................................................... 23

4.4.1. Actores....................................................................................................................................................... 24

4.4.2. Sistema ...................................................................................................................................................... 25 4.4.3. Lneas y flechas ...................................................................................................................................... 25 4.4.4. Casos de Uso ............................................................................................................................................ 25 4.4.5. Extensiones (Extends) ........................................................................................................................ 28 4.4.6. Usos (Uses o include) .......................................................................................................................... 28 4.4.7. Generalizacin o herencia ................................................................................................................. 29 4.4.8. Construccin del grfico de casos de uso .................................................................................... 29 4.4.9. Documentacin de Casos de Uso plantillas ............................................................................ 32 4.4.10. Campos de la plantilla ......................................................................................................................... 33 4.4.11. Nivel de detalle del caso de uso y solucin nica .................................................................... 34 4.4.12. Lo que no debe hacerse en casos de uso ..................................................................................... 35 4.4.13. Ejemplo de caso de uso plantilla y diagrama ......................................................................... 37 4.4.14. Herramientas automatizadas........................................................................................................... 37

5. Comparacin de algunas herramientas .......................................................................................................... 40

6. Conclusiones .............................................................................................................................................................. 40

7. Bibliografa ................................................................................................................................................................. 41



Mayo 2014 - Pg. 3

1. Introduccin Hoy, toda actividad que se realiza en todos los rdenes de la vida comercial, industrial, de entrenamiento, espiritual, etc., est soportada por sistemas de informacin. Estos sistemas pueden ser manuales, automatizados o combinados. Dada la facilidad de uso y de acceso a computadoras, la mayora de los sistemas de informacin hacen uso de las mquinas, en sus diversas formas de presentacin: PC de escritorio, notebooks, tablets3, celulares inteligentes, servidores de gran porte, etc. Independiente de que sean o no automatizados, de que se utilicen computadoras grandes o chicas, mviles o fijas, es necesario saber qu hace o qu tiene que hacer el sistema de informacin. La especificacin de requerimientos es la disciplina que se encarga de esta actividad. Un requerimiento es una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. De la especificacin de requerimientos (ER) depende la construccin y el funciona-miento del futuro sistema de informacin. Tan relevante es la ER que se ha convertido en una rama propia de la ingeniera4: la Ingeniera de Requerimientos, por lo que tiene sus metodologas y tcnicas de trabajo. El resultado de la ER es un conjunto de documentos que definen inequvocamente y en forma completa qu tiene que hacer el sistema de informacin.

Para entender la relevancia de la ER tener presente la enorme cantidad de fracasos en sistemas de informacin que tenemos o que tuvimos a nuestro alrededor. Fracasos son proyectos que nunca entraron en produccin, o que insumieron mucho ms tiempo del previsto, o bien sus costos han superado ampliamente los presupuestos. Tambin son fracasos sistemas de informacin que no responden a lo que se esperaba que hicieran. Si bien la ER no es necesariamente el nico motivo de fracaso, suele ser el ms frecuente. La especificacin de requerimientos es una actividad de un amplio y variado equipo de trabajo multidisciplinario en el que participan casi todos los integrantes de la organizacin o empresa para la cual se est estudiando el sistema de informacin. Este equipo no se limita a los usuarios internos, sino que incluye a los externos, como ser clientes, organismos pblicos (DGI, BPS, etc.) y puede incluir a la sociedad. Por lo tanto, conocer qu es la ER, cmo se trabaja y qu produce es relevante para toda persona que de una u otra manera est o estar relacionada en esta actividad al ser necesario definir o modificar un sistema de informacin. A su vez, los sistemas de informacin necesitan ser actualizados, sea por modificacin o por creacin de nuevos, con una frecuencia cada vez mayor, debido a las exigencias del medio, a los cambios que se producen y a la cada vez mayor

3 Tablet (tableta): computadora porttil de mayor tamao que un telfono inteligente o una PDA, integrado en una pantalla tctil con la que se interacta con los dedos, sin necesidad de teclado fsico ni ratn. 4 Ingeniera: Estudio y aplicacin, por especialistas, de las diversas ramas de la tecnologa.



Mayo 2014 - Pg. 4

interdependencia de los sistemas de informacin entre las empresas y de stas con los organismos de control y recaudacin oficiales. Los cambios en la sociedad en cuanto al manejo de informacin, tanto a nivel de pas como internacionales, son relevantes y vertiginosos, se podra decir. En general, no se suele percibir la trascendencia de estas transformaciones. Un par de ejemplos tienen que ver con el manejo legal de la informacin. Una est dada por la ley 18.3315, de proteccin de datos personales, conocida como ley de Habeas Data y la otra es la ley 18.3816 de Informacin Pblica, donde los organismos pblicos deben especificar cul es su informacin reservada, a efectos de poner a disposicin de la comunidad la informacin que es pblica. La informacin ha pasado a ser un derecho bsico de las personas, como lo es la salud o la vivienda.

Un sistema de informacin puede ser tan bsico como una planilla electrnica o tan complejo como un sistema automtico de intermediacin laboral, pasando por un sistema inteligente de control de trfico de calles para operacin de semforos, el sistema de balance de consumo elctrico en base a la matriz energtica, clculos de aportes laborales, impuestos, aforos, etc. como as tambin proyecciones de consumo masivo a corto y mediano plazo para determinados rubros. En todos estos ejemplos es necesario contar con una apropiada especificacin de requerimientos. Cuntas veces se genera una planilla electrnica y despus no se sabe para qu se la hizo o qu sentido tenan ciertos campos calculados? En toda organizacin suele haber miles de planillas electrnicas y se suelen guardar a lo largo del tiempo. Muchas son de uso individual y muchas otras son de uso colectivo, donde diferentes personas van agregando o modificando campos que con el paso del tiempo se desvirtan. Cuntos sistemas de informacin existen en organizaciones que desconocen qu hacen, en especial cuando son de otras generaciones tecnolgicas, y siguen en uso por falta de documentacin y de tcnicos capaces de abordarlo? No se sabe en detalle qu hacen! Estos ejemplos pueden parecer absurdos, pero no lo son, existen en el pas y en el mundo. Por estos motivos es que la ingeniera de requerimientos se ha desarrollado en forma relevante y la sociedad est tomando conciencia de su importancia, por motivos de seguridad y de gestin apropiada de los costos.

Volviendo al problema de los fracasos, que se dan en todo tipo de sistema de informacin, sea pequeo o grande, de uso pblico o privado, comercial, industrial o de servicios, etc., por qu ocurren si en general suele haber documentacin que respalda lo que se desea o lo que se necesita. Hay estudios que indican que ms del 80% de los proyectos informticos son fracasados, por exceder los tiempos previstos, por superar los costos presupuestados o por no hacer lo que se supona haran. Algunos estudios han encontrado que ms de la mitad de los fracasos se debieron a errores en la especificacin de los 5 http://www.parlamento.gub.uy/leyes/AccesoTextoLey.asp?Ley=18331&Anchor=

6 http://200.40.229.134/leyes/AccesoTextoLey.asp?Ley=18381&Anchor=



Mayo 2014 - Pg. 5

requerimientos, incluida una adecuada comunicacin de las necesidades y las expectativas entre todos los involucrados.

1.1 El clsico problema de los sistemas de informacin La figura que sigue, muy conocida en el ambiente informtico por casi ms de dos dcadas, suele explicarlo bien.

Todo comienza con una solicitud y una definicin inicial en la cual el usuario expresa lo que desea y se lo comunica al gerente (o lder) de proyecto, que hace su interpre-tacin de qu desea el usuario. La solicitud es comunicada al analista de sistemas que interpreta el pedido, el cual es transferido al programador, que a su vez hace su interpretacin, y as sucesivamente, hasta que se concluye qu es lo que realmente quera el usuario. Aqu se aprecia bien los problemas de comunicacin que existen, los cuales aumen-tan al haber diferentes usuarios, cada uno con intereses distintos y diferente grado de habilidad o limitacin en comunicar sus necesidades. En el mundo del desarrollo de soluciones informticas es frecuente que ocurra lo mismo que en el juego del telfono descompuesto: la diferencia entre lo que se dijo, o se pretendi decir al comienzo, y lo que realmente se entendi al final. La diferencia que en un caso es un juego y en el otro hay personas, costos y tiempos involucrados. Por lo tanto, es necesario hacer la difusin de las metodologas, tcnicas y herra-mientas disponibles para reducir lo ms posible los problemas de especificacin de requerimientos.



Mayo 2014 - Pg. 6

La disciplina que se encarga de la adecuada documentacin de la especificacin de requerimientos es la ingeniera de requerimientos (IR). La IR tiene el propsito de descubrir qu se necesita realmente y documentarlo apro-piadamente para que todos los involucrados, sean clientes, operadores, accionistas, tcnicos informticos, ingenieros informticos, etc. sepan inequvocamente qu se quiere que el sistema de informacin haga o cmo funcione, bajo qu limitaciones y cul es su alcance. Es relevante que las soluciones informticas sean de calidad7. La calidad est vinculada a la especificacin de requerimientos y al cliente o usuario del sistema de informacin.

1.2 Objetivos del texto En este texto se pretende alcanzar los siguientes objetivos: Resaltar la importancia que tiene la IR dentro del ciclo de vida de los sistemas de informacin. Dar a conocer algunas de las alternativas que existen para identificar requerimientos. Introducir en algunas de las tcnicas utilizadas en la IR. Explicar qu son y para qu sirven los casos de uso.

2. La ingeniera de requerimientos La ingeniera de requerimientos (IR) cumple un papel primordial en el proceso8 de produccin de software. Enfoca un rea fundamental: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, el comportamiento del sistema. La meta de la IR es crear y mantener un documento de requerimientos del sistema. El documento se compone de grficos, tablas y texto. La IR recopila, analiza y verifica las necesidades del cliente para un sistema de infor-macin y produce una especificacin de requisitos de software correcta y completa. 7 Calidad (Wikipedia): propiedad inherente de cualquier cosa que permite compararla con cualquier otra de su misma especie. La calidad de un producto o servicio es la percepcin que el cliente tiene del mismo, es una fijacin mental del consumidor que asume conformidad con dicho producto o servicio y la capacidad del mismo para satisfacer sus necesidades.

Segn norma ISO 9000: Calidad es el grado en el que un conjunto de caractersticas inherentes cumple con los requisitos.

Segn la Real Academia de la Lengua Espaola: Calidad es la propiedad, o el conjunto de propiedades, inherentes a una cosa que permiten apreciarla como igual, mejor o peor que las restantes de su especie.

Philip Crosby: Calidad es cumplimiento de requisitos.

Armand V. Feigenbaum: Calidad es satisfacer las expectativas del cliente.

8 Proceso. Tiene mltiples significados. No confundir con proceso de negocio o proceso empresarial. En este texto se refiere al conjunto de las fases sucesivas de una operacin artificial repetitiva (Diccionario Real Academia), que se realizan con un fin determinado.



Mayo 2014 - Pg. 7

2.1 Principales actividades de la ingeniera de requerimientos Hay diferentes tcnicas para cumplir los objetivos de la ingeniera de requerimientos. Aqu se sealan, a modo de ejemplo, dos posibles. La primera consiste en considerar cuatro etapas de alto nivel:

- Estudio de viabilidad: evaluar si el sistema puede ser implementado, considerando aspectos tcnicos, operativos y econmicos.

- Obtencin y anlisis de requerimientos: consiste en el descubrimiento de cules son los requerimientos del sistema de informacin

- Documentacin de los requerimientos: en un formato estndar en modo de grficas, tablas y texto

- Validacin de los requerimientos: verificacin de que los requerimientos realmente cumplen con las necesidades que tiene o que tendr el cliente.

Al proceso de obtencin de datos se le suele llamar elicitacin. Elicitacin9 en psicologa se asocia al concepto de traspaso de informacin en forma fluida de un ser humano a otro. En Computacin la asociacin es similar, se agrega el traspaso de informacin fluida desde un software a otro en forma fluida y a la vez de un computador a una persona o de persona a persona. Cuando esa informacin que est fluyendo entre los programas puede ser vista y compartida por personas, se dice que se est elicitando la informacin. El siguiente esquema representa esta primera opcin:

9 Wikipedia. No existe la palabra en el diccionario de la Real Academia Espaola.



Mayo 2014 - Pg. 8

Esta es una visin lineal del proceso de la actividad de la ingeniera de requeri-mientos.

La segunda opcin consiste en una visin ms realista, evolutiva, que puede consistir en tres etapas, en un proceso iterativo, de sucesivo refinamiento. Las etapas son:

- Obtencin de requerimientos - Especificacin de requerimientos - Validacin de requerimientos.

El proceso comienza enfocado en las especificaciones del negocio, luego de los usuarios y finalmente en la especificacin del sistema de informacin y definir su modelado. En el proceso se pasa de los requerimientos no funcionales a los funcionales. En la, o las, etapas en que se cuenta con suficiente informacin, se hacen los estudios de viabilidad (puede ser uno solo o varios). El siguiente esquema representa esta segunda opcin, donde la espiral se recorre desde adentro hacia afuera:

3. Requerimientos Las posibles definiciones de un requerimiento son las siguientes:

Un requerimiento es una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo.10

Un requerimiento es una condicin o capacidad que debe estar presente en un sistema, o en componentes del sistema, para satisfacer un contrato, un estndar, una especificacin u otro documento formal.11

10 IEEE. (1990) Standard Glossary of Software Engineering Terminology IEEE Std.610.12



Mayo 2014 - Pg. 9

Tambin se puede definir un requerimiento como una representacin documentada de una condicin o capacidad de los prrafos precedentes.

3.1. Alcance del sistema o dominio del problema Es fundamental determinar cul es el alcance del sistema de informacin, esto es cules son sus lmites, o tambin dicho de otra forma, cul es el dominio del problema. Es el rea de experiencia o aplicacin que necesita conocerse para resolver un problema. En el mbito de los sistemas de informacin, el dominio del problema es el conjunto de conceptos interrelacionados que es necesario conocer para entender el negocio del cliente, y por lo tanto, para poder entender sus necesidades y proponer una solucin adecuada.12 Ejemplos de dominio del problema: Si se va a desarrollar una aplicacin para la gestin de urgencias de un hospital, el dominio del problema ser todo lo relacionado con: paciente, guardia, admisin, diagnstico, etc. Si se va a desarrollar para una empresa de seguros de automvil, el dominio del problema sern: las plizas, los asegurados, los siniestros, las tablas de costos y beneficios, etc. Muchas veces es til en la definicin del dominio del problema indicar lo que no es parte del sistema de informacin. Por ejemplo, en un sistema de informacin de una biblioteca de una facultad, los usuarios son todos los estudiantes de la institucin inscriptos en cursos; no est habilitado el prstamo a estudiantes que no son de la facultad o que no estn cursando alguna materia. Otro sistema de bibliotecas, puede estar disponible para todo estudiante de la facultad o que tenga un carn inter-bibliotecario, por ejemplo. Las situaciones pueden ser ms o menos complejas y se reflejan en los requerimientos. Por ejemplo, un sistema de intermediacin laboral puede estar dirigido a los ciudadanos que poseen documento nacional de identificacin (la cdula de identidad). Ahora bien, si tambin admite ciudadanos de otros pases que carecen de CI, deber tener un campo especial para pasaporte o documento equivalente. A su vez, en el primer caso, podr validar la identificacin contra el registro de la Direccin Nacional de Identificacin Civil, de tal manera que con slo digitar el nmero, obtenga directamente el nombre completo del ciudadano, su fecha de nacimiento, etc. De esta forma se evita registrar datos redundantes y se asegura la calidad de los datos. En caso de permitir el uso de pasaporte u otro documento, no ser posible validar (controlar) que el nmero sea correcto, y se requerir el ingreso de los datos de identificacin de la persona. La mala definicin del alcance, o la definicin ambigua, es causa de que los proyectos fracasen. El dominio del problema, o el alcance del sistema, deben ser conocidos a efectos de saber qu incluye y qu excluye el sistema de informacin, sino adems, para saber cul es el mbito en que tienen que ser definidos los requisitos.

11 DAVID, Fred R. Conceptos de administracin estratgica. traduccin de Strategic Management: concepts 9th ed., Pearson Education. Inc., Mxico 2003. rea Universidad ISBN: 970-26-0427-3 12 http://www.juntadeandalucia.es/servicios/madeja/contenido/libro-pautas/175



Mayo 2014 - Pg. 10

En 3.7.4 se vuelve a hacer referencia al alcance del sistema.

3.2. Requerimientos funcionales y no funcionales Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones13 que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc. Hoy tienen una relevancia especial los requerimientos no funcionales sobre seguridad, donde es fundamental cumplir con los aspectos de confidencialidad, disponibilidad e integridad. Otro requerimiento no funcional relevante es el cumplimiento de los aspectos legales, como ser las leyes 18.33114 Proteccin de datos personales, conocida como ley de habeas Data, 18.38115 Informacin pblica y 18.60016 de documento electrnico y firma electrnica, segn corresponda en cada situacin concreta. Los requerimientos no funcionales son aquellos que no se refieren directamente a las funciones del sistema, sino a las propiedades del sistema. Surgen de las necesidades del usuario causadas por las restricciones en el presupuesto, a las polticas de la organizacin, a la necesidad de interoperabilidad con otros sistemas (dentro de la organizacin o externos como ser de DGI, BPS, BCU, etc.17), software o hardware, incluida la portabilidad18, factores externos como regulaciones de seguridad o legislaciones sobre privacidad. Una posible clasificacin de los requerimientos no funcionales es la siguiente:

- Requerimientos del producto: o rapidez del sistema, o memoria disponible, o fallos o portabilidad,

13 Funciones tambin se utiliza en el marco de una organizacin como ser produccin, administracin, etc. El diccionario de la Real Academia presenta ms de 15 significados diferentes. En este texto se utiliza en el sentid de tarea que se tiene que realizar. Por ejemplo: Alta de artculo, emisin de factura, etc.

14 http://www.datospersonales.gub.uy/

15 http://www.uaip.gub.uy/

16 http://uce.gub.uy/pagina-principal

17 DGI = Direccin General Impositiva; BPS = Banco de Previsin Social; BCU = Banco Central de Uruguay.

18 Portabilidad: posibilidad de ejecutar el programa en diferentes plataformas, como ser: PC, tablet, smartphones, etc.



Mayo 2014 - Pg. 11

o usabilidad. - Requerimientos organizacionales:

o polticas y procedimientos de la organizacin cliente o dem del desarrollador.

- Requerimientos externos: o incluye todos los requerimientos que derivan de los factores externos

del sistema y de su proceso de desarrollo. - Requerimientos de dominio:

o Provienen del dominio de aplicacin del sistema y que reflejan las caractersticas y restricciones de ese dominio. Es lo que se conoce como el medio ambiente del sistema de informacin,

3.3. Caractersticas de los requerimientos

Un requerimiento est bien definido si cumple las siguientes siete caractersticas:

Necesario: porque su omisin provoca una deficiencia en el sistema a construir, y no puede ser reemplazado por otros requerimientos. Conciso: porque es fcil de leer y de entender. Su redaccin es simple, con pocas palabras y exacta para quienes lo tienen que leer en el futuro. Completo: proporciona informacin suficiente para su comprensin. No es necesario ampliar detalles en su redaccin. Consistente: es consistente si no es contradictorio con otro requerimiento. No ambiguo: tiene una sola interpretacin; la redaccin usado en su definicin no causa confusiones al lector. Verificable: es posible comprobarlo, analizarlo, inspeccionarlo o demostrarlo. Esta condicin debe satisfacerse tanto antes de contar con el sistema de informacin en funcionamiento como cuando est en uso. En todo momento se debe poder verificar que se cumple con lo establecido en el requerimiento. Trazable: que se puede saber de dnde surge y cul fue la evolucin del requeri-miento. Es decir, si tuvo cambios, por qu, quin o quienes lo hicieron y cundo.

3.4. Dificultades para definir los requerimientos Definir requerimientos suele ser una tarea compleja, no slo por tener que cumplir con las caractersticas indicadas, sino adems: Los requerimientos no son obvios Provienen de muchas fuentes, algunas de ellas contradictorias entre s. Suelen ser difciles de expresar por escrito porque el lenguaje es ambiguo. No siempre es inmediato determinar a qu tipo pertenece un requerimiento. Existen varios niveles de detalle posibles y elegir el apropiado no es fcil.



Mayo 2014 - Pg. 12

La cantidad de requerimientos en un proyecto suele ser grande y por lo tanto, difcil de manejar.

La especificacin de cada requerimiento depende del proceso/sistema al que se aplica, a la organizacin y su contexto.

Algunos requerimientos son estables y otros son variables en el tiempo. Es decir, un requerimiento puede cambiar a lo largo del ciclo de desarrollo, e incluso en la fase operativa, ocasionando la necesidad de mantenimiento.

Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.

Cada requerimiento tiene propiedades nicas y abarca reas funcionales especficas.

Los requerimientos suelen ser difciles de cuantificar.

La especificacin de requerimientos suele ser un proceso iterativo, donde se hace una definicin inicial, se verifica el cumplimiento de las caractersticas indicadas, y se van haciendo ajustes sucesivos, tratando de salvar las dificultades mencionadas.

3.5. Personal involucrado en la Ingeniera de Requerimientos Las personas involucradas en el desarrollo de la especificacin de los requerimientos de un sistema tienen muy variada experiencia, formacin e intereses, todos los cuales tienen que ser considerados en el anlisis de los requerimientos. Cada grupo de personas juega uno o ms roles. Un rol es la funcin o papel que cumple algo o alguien19. Los posibles roles que se suelen distinguir en IR son:

- Usuario final - Usuario clave o lder. - Usuario de testing (pruebas) - Encargado del soporte operativo - Encargado del mantenimiento - Equipo tcnico informtico de desarrollo del sistema - stakeholders - Otros Interesados

Para un buen anlisis de los requerimientos, se deben identificar las caractersticas de todas las personas y sus roles, en especial, sus intereses y sus limitaciones. Por ejemplo, un sistema informtico fracas porque no se previ que haba operadores analfabetos. Otra situacin fue que la capacitacin para el uso del nuevo sistema inclua personas de avanzada edad. No se puede dar nada por obvio, por supuesto. Todo debe ser explicitado.

19 El rol del entrenador, el rol del #10 en la cancha, etc.



Mayo 2014 - Pg. 13

Usuario final: Son las personas que usarn el sistema desarrollado. Estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; deben estar familiarizados con los procesos especficos que debe realizar el software, dentro de los parmetros de su ambiente laboral. Tener presente que el usuario final es quien interacta con el sistema que se va a elaborar o modificar. Por ejemplo, en un sistema bancario, si es un sistema de autogestin, el usuario final es el cliente del banco. En cambio, si el cliente es atendido por un funcionario bancario y ste interacta con el sistema, el usuario final es el funcionario, no el cliente.

Usuario Lder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde ser empleado el software desarrollado. Ellos proporcionan al equipo tcnico los detalles y requerimientos de las interfaces del sistema.

Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son las responsables de la administracin de cambios, de la implementacin y resolucin de anomalas. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.

Analistas y programadores: Son los responsables del desarrollo del producto en s; ellos interactan directamente con el cliente.

Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

"Stakeholders no tiene una traduccin apropiada al espaol, por lo que se usa el trmino en ingls. Se refiere a quienes pueden afectar o son afectados por las actividades de una empresa. Se puede definir como cualquier persona o entidad que es afectada por las actividades de una organizacin; por ejemplo, los trabajadores de esa organizacin, sus accionistas, las asociaciones de vecinos, sindicatos, organizaciones civiles y gubernamentales, etc.

Se agreg otros interesados, porque uno de los problemas relevantes en la IR es omitirlos. stos, por no haber sido incluidos por omisin involuntaria, pueden afectar al sistema de informacin. Los otros interesados pueden ser tanto quienes proveen datos como quienes usan informacin del sistema. Al no ser considerados, no son tomados en cuenta sus requisitos de manejo de informacin.

3.6. Actividades de la Ingeniera de Requerimientos En el trabajo de la ingeniera de requerimientos hay cinco actividades principales que son las siguientes, las cuales son explicadas a continuacin: Anlisis del Problema Evaluacin y Negociacin Especificacin Validacin Evolucin



Mayo 2014 - Pg. 14

3.7. Anlisis del Problema El objetivo del anlisis del problema es entender las verdaderas necesidades del negocio20, lo cual no suele ser trivial. "Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean." Notar la importancia que tiene una buena comuni-cacin entre desarrolladores y clientes, pues de la misma depende que se entiendan las necesidades del cliente. La actividad de "Anlisis del Problema" tiene por objetivo que se comprendan los pro-blemas del negocio, se evalen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solucin de alto nivel para resolverlo. Durante el anlisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio. Estos pasos son los siguientes:

- Comprender el problema - Construir un vocabulario comn - Identificar a los involucrados - Definir el alcance del sistema

3.7.1. Comprender el problema Comprender el problema que se est resolviendo es bsico. Este paso consiste en determinar quin tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Ejemplo. "El cliente se queja mucho por la enorme fila (cola de espera) que debe formar para realizar el trmite X." La perspectiva del cliente puede ser una prdida de tiempo y la perspectiva del negocio puede ser la posible prdida de clientes. Las posibles soluciones pueden ser:

a) determinar por qu se demora la atencin b) colocar un nuevo puesto atencin (implica agregar mostrador, equipamiento

informtico y nuevos funcionarios o redistribucin de los existentes) c) automatizar la transaccin d) implementar solucin alternativa, por ej., tercerizar21 el servicio, si es posible o

conveniente. e) Otras alternativas.

20 Negocio: Es una actividad, sistema, mtodo o forma de obtener dinero, a cambio de ofrecer bienes o servicios a otras personas. Consiste en una entidad creada o constituida con la finalidad de obtener dinero a cambio de realizar actividades de produccin (por ejemplo, una fbrica de muebles), comercializacin (por ejemplo, una tienda de repuestos de autos o una distribuidora) o prestacin de servicios (por ejemplo, un restaurante o un taller de mecnica), que beneficien a otras personas. (Wikipedia). En este texto se considera con sentido ms amplio, incluyendo servicios pblicos, por ejemplo, municipales o nacionales.

21 Tercerizar: que el servicio sea provisto por otra empresa, como ser: servicios de vigilancia, limpieza, call centers, servicio tcnico, etc. En general, se aplica a tareas que no son las principales de la organizacin. No existe el trmino en el diccionario de la Real Academia Espaola, aunque es de uso frecuente en el mbito empresarial.



Mayo 2014 - Pg. 15

Como puede verse, hay mltiples soluciones para el mismo problema. Sin embargo, slo una de ellas ser la ms factible. En muchas circunstancias, la mejor solucin surge de una combinacin de varias alternativas propuestas, o bien de una nueva.

3.7.2. Construir un vocabulario comn Construir un vocabulario comn: Debe confeccionarse un glosario22 en dnde se defi-nan todos los trminos que tengan significados comunes (sinnimos) y que sern uti-lizados durante el proyecto. Una misma palabra o expresin puede tener diferente significado en diferentes con-textos, por lo cual, la confeccin de un glosario evita confusiones. Por otra parte, es frecuente que quienes estn en cierta rea de negocio conozcan el significado de los trminos que utilizan, pero eso no incluye a los tcnicos inform-ticos, quienes deben familiarizarse con el vocabulario. Esta necesidad de familiari-zacin incluye al analista funcional, al programador, al administrador de base de datos, etc. La creacin de un glosario es sumamente beneficiosa ya que reduce los trminos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunin interpreten de igual forma los trminos utilizados. Estn todas las definiciones juntas en un mismo lugar. Adems son reutilizables en otros proyectos.

3.7.3. Identificar a los involucrados Identificar a todos los involucrados por el sistema, esto es a todas las personas o grupos de personas que directa o indirectamente son afectados por el sistema, evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante el trabajo de ingeniera de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la informacin necesaria para especificar un sistema adecuado. Si bien es necesario conocer la opinin de todos los involucrados, es frecuente que haya contrariedades. Por ejemplo, una persona dice que determinados datos nos los precisa, por lo cual no deberan ser ingresados en determinada pantalla. Pero esos datos pueden ser fundamentales para un proceso posterior, y otra persona indica que deben ser ingresados al principio, para ser correctamente validados. En casos como este, se debe analizar cul es la mejor solucin y si realmente se deben ingresar los datos, decidir en qu pantalla es mejor que se realice dicho ingreso. Debe conocerse la opinin de toda persona que de una u otra forma est involucrada, o lo estar, con el sistema, sea directa o indirectamente. Para saber quines son las personas, departamentos, organizaciones internas o externas que se vern afectadas por el sistema, debemos realizar algunas preguntas, como las que se presentan en la tabla siguiente:

22 Glosario: catlogo de palabras de una misma disciplina o de un campo de estudio, donde son definidas, explicadas o comentadas



Mayo 2014 - Pg. 16

Preguntas a formular para identificar a los involucrados

Quin usar el sistema que se va a construir?

Quin desarrollar el sistema?

Quin probar el sistema?

Quin documentar el sistema?

Quin dar soporte al sistema?

Quin dar mantenimiento al sistema?

Quin mercadear, vender, y/o distribuir el sistema?

Quin se beneficiar por el retorno de inversin del sistema?

3.7.4. Alcance del sistema Definir el alcance del sistema es definir los lmites y las restricciones del sistema. (Ver 3.13.1) Este punto es tanto o ms importante que los precedentes, pues se debemos saber lo que se elaborar y lo que no se elaborar. Se establecen las fronteras, qu est dentro del producto y que est fuera. Tambin se especifican las restricciones ambientales, presupuestarias, plazos y condiciones tcnicas y de factibilidad. La mayora de los fracasos en la implementacin de sistemas se da por el reclamo de usuarios en partes que no fueron incluidas en el nuevo sistema de informacin y que se supona que deban estarlo. Es decir, problemas de alcance.

3.8. Evaluacin y negociacin de los requerimientos La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluacin de los mismos antes de definir si son adecuados para el cliente. El trmino "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades tcnicas y econmicas, a la vez que se buscan resultados completos, correctos y sin ambigedades. En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstraccin y descomposicin de cada problema presentado. Clasificar los requerimientos: consiste en identificar la importancia que tiene un requerimiento en trminos de implementacin. A esta caracterstica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirn las actividades de diseo y de prueba de cada requisito. La prioridad de cada requerimiento depender de las necesidades que tenga el negocio. En base a la prioridad, cada requerimiento puede ser clasificado como mandatorio, deseable o innecesario.



Mayo 2014 - Pg. 17

Un requerimiento es mandatorio si afecta una operacin crtica del negocio. Si existe algn proceso que se quiera incluir para mejorar los procesos actuales, se est ante un requerimiento deseable. Si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario. Una vez hecha esta categorizacin de los requerimientos, se puede tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusin de un requerimiento, tambin debe analizarse su costo, su complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por ms que ste sea slo deseable. Evaluar factibilidades y riesgos: Involucra la evaluacin de factibilidades tcnicas (pueden implementarse los requerimientos con la tecnologa actual?); factibilidades operacionales (puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades econmicas (ha sido aprobado por los clientes el presupuesto?). En la actividad de evaluacin y negociacin, se incrementa la comunicacin entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre ellas, las siguientes: Documentar todos los requerimientos a un nivel de detalle apropiado. Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causen los cambios a los requerimientos antes de

aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones.

3.9. Especificacin de Requisitos de Software La especificacin de requisitos de software se conoce por la sigla SRS que viene de Software Requirement Specifications. Esta es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripcin completa de las necesidades y funcionalidades23 del sistema que ser desarrollado; describe el alcance del sistema y la forma en como har sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra informacin que sirva de soporte y gua para fases posteriores. Es importante destacar que la especificacin de requisitos es el resultado final de las actividades de anlisis y evaluacin de requerimientos; este documento resultante

23 Funcionalidades: conjunto de funciones, es decir, las tareas que tiene que cumplir el sistema de informacin.



Mayo 2014 - Pg. 18

ser utilizado como fuente bsica de comunicacin entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implemen-tacin del sistema. Los clientes y usuarios utilizan la SRS para comparar si lo que se est proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utili-zan para determinar el producto que debe desarrollarse. El personal de pruebas elaborar las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolucin del sistema. La SRS posee las mismas caractersticas de los requerimientos: completa, consis-tente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. La estandarizacin de la SRS es fundamental pues ayudar, entre otras cosas, a faci-litar la lectura y escritura de la misma. Ser un documento familiar para todos los involucrados, adems de asegurar que se cubren todos los tpicos importantes.

3.10. Validacin de Requisitos La validacin es la actividad que demuestra que los requerimientos definidos en el sistema son los que realmente quiere el cliente, que son correctos, completos y apropiados al negocio y la organizacin (sin omisiones, sin ambigedades, sin inconsistencias, sin redundancias, etc.). Con la validacin se garantiza que la SRS est libre de errores y responde a las necesidades, estando en un documento que cumple con estndares de calidad, comprendido y acordado. En esta fase se revisa el cumplimiento de las caractersticas de la especificacin de requisitos, con preguntas como ser:

Pregunta Caracterstica de la SRS que verifica

Estn incluidas todas las funciones requeridas por el cliente? COMPLETA

Existen conflictos en los requerimientos? CONSISTENTE

Tiene alguno de los requerimientos ms de una interpretacin? NO AMBIGUA

Est cada requerimiento claramente representado? ENTENDIBLE

Pueden los requerimientos ser implementados con la tecnologa y el presupuesto disponible?

VIABLE

Est la SRS escrita en un lenguaje apropiado? SE ENTIENDE

Existe facilidad para hacer cambios en los requerimientos? MODIFICABLE

Est claramente definido el origen de cada requisito? RASTREABLE

Pueden los requerimientos ser sometidos a medidas cuantitativas? VERIFICABLE



Mayo 2014 - Pg. 19

3.11. Evolucin de los requerimientos Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cmo los objetivos de la organizacin pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolucin es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las ms frecuentes son: Porque al analizar el problema, no se hacen las preguntas correctas a las

personas correctas. Porque cambi el problema que se estaba resolviendo. Porque los usuarios cambiaron su forma de pensar o sus percepciones. Porque cambi el ambiente de negocios. Porque cambi el mercado en el cual se desenvuelve el negocio.

Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una caracterstica en particular, modificacin que a la vez puede tener impacto en otros requerimientos. Por esto, la administracin de cambios involucra actividades como establecer polticas, registrar los cambios que se producen de cada requerimiento (tambin llamado guardar histricos), identificar dependencias entre ellos y mantener un control de versiones. Tener versiones de los requerimientos es tan importante como tener versiones del cdigo, ya que evita tener requerimientos emparchados en un proyecto Entre algunos de los beneficios que proporciona el control de versiones estn: Prevenir cambios no autorizados. Guardar revisiones de los documentos de requerimientos. Recuperar versiones previas de los documentos. Administrar una estrategia de versiones.24 Prevenir la modificacin simultnea a los requisitos.

En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser encaminadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.

24 Versiones: "releases" en ingls. El versionado de software o de documentos es el proceso de asignacin de un nombre o nmero nico a un software o documento para indicar su nivel de desarrollo y evolucin. Generalmente se asigna dos nmeros, mayor.menor (Ej.: 3.2), que van incrementando conforme el desarrollo aumente y se requiera la asignacin de un nuevo nombre o nmero nico. Pueden usarse ms nmeros. Ej.: 4.0.1.2.

Se aumenta el nmero mayor (el ms a la izquierda) cuando el software o documento sufre grandes cambios y mejoras.

Se aumenta el nmero menor (el que le sigue a la derecha) cuando el software o documento sufre pequeos cambios y/o correcciones de errores.

Y as sucesivamente.

El trabajar con versiones requiere una adecuada gestin de los archivos, a efectos de permitir en todo momento volver a una versin anterior.



Mayo 2014 - Pg. 20

4. Tcnicas y herramientas Las tcnicas y herramientas utilizadas para la especificacin de requerimientos son muchas y cada una de ellas es til en diferentes contextos. Dependen tambin de la metodologa que se utilice para el proyecto, como ser lineal, gil25, RUP26 u otra. En general, se suelen usar varias tcnicas y herramientas, en funcin de lo que se est analizando, con y para quienes. Aqu se introducen las ms comunes. Ellas son:

- Entrevistas y cuestionarios - Tormenta o lluvia de ideas - Prototipos - Los Casos de Uso y UML

4.1. Entrevistas y Cuestionarios Las entrevistas y los cuestionarios27 28 sirven para reunir informacin proveniente de personas o de grupos. En la entrevista, el analista conversa con el o los encues-tados. En el cuestionario el o los usuarios responden preguntas para conocer aspectos de un sistema. En la entrevista es oral, hay un contacto personal, directo; hay interaccin. En el cuestionario, en general, no hay contacto personal; puede ser individual o colectivo; no hay interaccin; queda documentado en los formularios que son completados. Por lo comn, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que sern afectados por l. Las preguntas que deben realizarse en esta tcnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener informa-cin sobre aspectos globales del problema del usuario y soluciones potenciales. Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para explorar un proceso o problema. Este tipo de

25 El desarrollo gil de software son mtodos de ingeniera del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboracin de grupos auto organizados y multidisciplinarios. Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando software en lapsos cortos (una a cuatro semanas). Wikipedia.

26 El Proceso Unificado Racional (Rational Unified Process en ingls, RUP) es un proceso de desarrollo de software de la empresa Rational Software, propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Wikipedia.

27 http://www.slideshare.net/troncd/la-entrevista-contrastada-con-el-cuestionario-como-tecnicas-de-investigacion

28 http://www.fhumyar.unr.edu.ar/escuelas/3/materiales%20de%20catedras /trabajo%20de%20campo/entrevistas.htm



Mayo 2014 - Pg. 21

preguntas son siempre apropiadas, adems que ayudan a entender la perspectiva del afectado y no estn influenciadas por el conocimiento de la solucin. Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. El ejemplo de la hoja siguiente muestra algunos tipos de preguntas abiertas.

El xito de esta tcnica combinada, depende de la habilidad del entrevistador y de su preparacin para la misma. Los analistas necesitan ser sensibles a las dificultades que algunos entrevistados crean durante la entrevista y saber cmo tratar con problemas potenciales. Asimismo, necesitan considerar no slo la informacin que adquieren a travs del cuestionario y la entrevista, sino tambin, su significancia.

Ejemplo de posibles preguntas para descubrir las caractersticas del problema y sus potenciales soluciones Del usuario

Quin es el cliente? Quin es el usuario? Son sus necesidades diferentes?

Cules son sus habilidades, capacidades, ambiente?

Del proceso

Cul es la razn por la que se quiere resolver este problema?

Cul es el valor de una solucin exitosa?

Cmo usted resuelve el problema actualmente?

Qu retrasos ocurren o pueden ocurrir?

Del producto

Qu problemas podra causar este producto en el negocio? En qu ambiente se usar el producto?

Cules son sus expectativas para los conceptos fcil de usar, confiable, rendimiento?

Qu obstculos afectan la eficiencia del sistema?

4.2. Lluvia de Ideas El mtodo de lluvia de ideas29 mtodo comenz en el mbito de las empresas, aplicndose a temas tan variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos mtodos que desarrollen el pensamiento creativo a todos los niveles, etc. Pronto se extendi a otros mbitos, incluyendo el mundo de desarrollo de sistemas, donde se busca que los involucrados en un proyecto desarrollen su creatividad. A esta tcnica se le conoce tambin como brainstorm, tormenta de ideas y otras denominaciones ms o menos similares.

29 http://homepage.cem.itesm.mx/alesando/index_archivos/MetodolDisMejoraDeProcesos/ LluviaDeIdeas.pdf



Mayo 2014 - Pg. 22

Para trabajar con lluvia de ideas se aplican varios principios, a saber: Aplazar el juicio y no realizar crticas mientras se presentan las ideas. Esto es

para evitar inhibir. Cuantas ms ideas se sugieren, mejores resultados se conseguirn: "la cantidad

produce la calidad". Las mejores ideas aparecen tarde en el periodo de produccin de ideas.

La produccin de ideas en grupos es ms efectiva que la individual. Durante las sesiones, las ideas de una persona sern percibidas de manera

distinta por cada miembro, y har que aparezcan otras nuevas.

El equipo en una lluvia de ideas debe estar formado por: el director, el secretario y los participantes. El Director: es el encargado de dirigir la sesin. Debe ser un experto en pensamiento creador. Su funcin es formular el problema, que todos los participantes se familiaricen con l. El secretario: es quien registra por escrito las ideas segn van surgiendo. Las enumera, las reproduce fielmente, las redacta y se asegura que todos estn de acuerdo con lo escrito. Los participantes: son cualquier involucrado en el proyecto, sin distincin de jerarqua. Pueden ser habituales o invitados. Su funcin es producir ideas. Deben estar motivadas para solucionar el problema. Todas las ideas, en principio, deben tener el mismo valor, pues cualquiera de ellas puede ser la clave para la solucin. Con todas las ideas presentadas y documentadas, se elabora una lista definitiva de ideas, para seleccionar las ms interesantes. La seleccin se realiza desechando las ideas que no tienen valor y se estudia si son vlidas las que se consideran interesantes. Se establece una lista de criterios de conveniencia para cada idea. Se seleccionan las ideas ms tiles y si es necesario se ponderan, para finalmente determinar la idea ms apropiada.

4.3. Prototipos Los prototipos permiten al desarrollador crear un modelo del software que debe ser construido. El prototipado (accin de construir un prototipo30) comienza con la captura de requerimientos. Desarrolladores y clientes se renen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y sealan reas en las que ser necesaria la profundizacin en las definiciones. Luego de esto, tiene lugar un "diseo rpido". Consiste en una representacin de aquellos aspectos del software que sern visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseo rpido lleva a la construccin de un prototipo, que

30 Prototipo: Ejemplar original o primer molde en que se fabrica una figura u otra cosa.



Mayo 2014 - Pg. 23

es evaluado por el cliente y el usuario y utilizado para refinar los requerimientos del software a ser desarrollado. Un proceso de iteracin tiene lugar a medida que el prototipo es "puesto a punto" para satisfacer las necesidades del cliente y permitiendo al mismo tiempo una mejor comprensin del problema por parte del desarrollador. Existen principalmente dos tipos de prototipos:

Prototipo rpido (o concept prototype): Es un mecanismo para lograr la validacin pre-compromiso. Se utiliza para validar requerimientos en una etapa previa al diseo especfico. En este sentido, el prototipo puede ser visto como una aceptacin tcita de que los requerimientos no son totalmente conocidos o entendidos antes del diseo y la implementacin. El prototipo rpido puede ser usado como un medio para explorar nuevos requerimientos y as ayudar a "controlar" su constante evolucin.

Prototipo evolutivo: Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser visto como una serie incremental de detallados prototipos acumulativos. Tradicionalmente, el ciclo de vida est dividido en dos fases distintas: desarrollo y mantenimiento. La experiencia ha demostrado que esta distincin es arbitraria y va en contra de la realidad ya que la mayor parte del costo del software ocurre despus de que el producto se ha entregado. El punto de vista evolutivo del ciclo de vida del software considera a la primera entrega como un prototipo inicial en el campo. Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos ms maduros. Este proceso contina hasta que se haya desarrollado el producto final. La adopcin de esta ptica elimina la distincin arbitraria entre desarrollo y mantenimiento, resultando en un importante cambio de mentalidad que afecta las estrategias para la estimacin de costos, enfoques de desarrollo y adquisicin de productos.

4.4. Los Casos de Uso y UML Los casos de uso es una forma moderna y difundida de especificar el comportamiento externo de un sistema. La notacin de los casos de uso fue incorporada al lenguaje estndar de modelado UML (Unified Modeling Language)31. Permiten entender a un sistema a partir de los servicios o funciones que ofrece a su entorno. "Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios." Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar cmo alguien o algo externo a un sistema lo usa. Los sistemas son usados no slo por personas, sino tambin por otros sistemas de hardware y software. 31 Los casos de uso son uno de los ms de una decena de otros componentes para el modelado de sistemas de software que constituyen el Lenguaje Unificado de Modelado,



Mayo 2014 - Pg. 24

Por ejemplo, un sistema de ventas, si pretende tener xito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, se dice que est "ejecutando" el caso de uso ingresando pedido. Para trabajar con casos de uso se requieren conocer las definiciones y la notacin que sigue, donde los conceptos a considerar son:

- Actores - Sistemas - Lneas y flechas - Casos de uso

- Extensiones - Usos/Inclusiones - Herencia

4.4.1. Actores Un actor es una agrupacin uniforme de personas, sistemas o mquinas que interactan con el sistema que se analiza. Ejemplo, para una organizacin que recibe pedidos en forma telefnica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer las mismas cosas con el sistema, son considerados un nico actor: "Empleado de Ventas". Si unos operadores telefnicos pueden hacer determinadas tareas y otros operadores telefnicos pueden hacer otras tareas diferentes, habr dos actores distintos: Empleado de Ventas y Supervisor de Ventas, por ejemplo. Los actores son externos al sistema en estudio (por ejemplo, para ser desarrollado o modificado). Por lo tanto, identificar actores es parte de delimitar el sistema, y de definir su alcance (Ver 3.1 y 3.7.4). Los actores pueden o no ser parte de la organizacin donde se implementa el sistema. Es importante diferenciar usuario de actor. Un actor es una clase de rol y un usuario es una persona que, cuando usa el sistema, asume un rol. Un usuario puede acceder al sistema como distintos actores. Otro sistema que interacta con el que est en estudio tambin es un actor. Si el sistema debe generar asientos contables para ser procesados por el sistema de contabilidad, este ltimo sistema ser un actor, que usa los servicios del sistema en estudio. El actor puede ser una mquina, en el caso en que el software controle sus movimientos. Por ejemplo, un sistema de control de cambios de luces en semforos inteligente para el trnsito en cruces de calles. Otros ejemplos: la activacin de un servicio de telefona celular o mover el brazo de un robot. En estos casos, los semforos, el control fsico de utilizacin de celulares y el robot son actores.



Mayo 2014 - Pg. 25

Los actores se representan con dibujos simplificados de perso-nas, llamados hombres de palo ("stick man"). No tienen ms ele-mentos que los que se presentan como ejemplos (no se agrega ojos, boca, etc.). Todos tienen el mismo tamao. Si bien en UML los actores siempre se representan con "hombres de palo", a veces resulta til representar a otros sis-temas con alguna representacin ms clara. Por ejemplo, si el actor es otro sistema de informacin, puede ponerse una pantalla, como el ejemplo adjunto. Formalmente, slo debieran utilizarse hombres de palo.

4.4.2. Sistema Se marca con un rectngulo la parte del sistema que interacta con los actores. El lmite entre los actores y sistema est dado por el rectngulo. Dentro del rectngulo van dibujados los casos de uso como se indica a continuacin:

4.4.3. Lneas y flechas Las lneas relacionan los actores con los casos de uso. Las flechas, opcionales, indican si el actor acta sobre el caso de uso (flecha desde el actor), el caso de uso acta sobre el actor (flecha al actor), o bien es interactivo (flecha doble). La flecha no indica el flujo de informacin entre el actor y el sistema, sino cmo interactan el actor y el sistema. Lo relevante es el uso de las lneas, no as las flechas que son opcionales.

4.4.4. Casos de Uso Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores, intercambia datos o control32 con el sistema, participando de ese caso de uso. Un caso de uso tambin puede ejecutarse en forma peridica, programada, o en respuesta a un evento que puede producirse en forma automtica por el propio sistema.

32 Datos o control: se suele diferenciar dos tipos de datos: Los datos en s, como ser una fecha de nacimiento, un domicilio, etc. que no modifican la operativa. Otro tipo son los datos de control, que condicionan el flujo de la operativa, como por ejemplo si es una operacin contado o crdito, si est registrado o tiene que ser registrado, etc.



Mayo 2014 - Pg. 26

El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Grficamente, los casos de uso se representan con un valo, con el nombre del caso en su interior. El nombre del caso siempre est expresado desde el punto de vista del actor y no desde el punto de vista del sistema. Por eso en el ejemplo, el segundo caso de uso se llama "Recibiendo informacin de pedidos" y no "Generando informacin de pedidos". En la prctica en lugar de usar los verbos en gerundio33 se suelen usar en infinitivo34: ingresar pedido, recibir informacin de pedidos.

Los casos de uso tienen las siguientes caractersticas: Estn expresados desde el punto de vista del actor. Se documentan con texto preferentemente en lenguaje estructurado35 o pseudo-

cdigo.36 Describen tanto lo que hace el actor como lo que hace el sistema cuando

interacta con l, aunque el nfasis est puesto en la interaccin. Son iniciados por uno o varios diferentes actores. Estn acotados al uso de una determinada funcionalidad del sistema, claramente

diferenciada.

Determinar cada funcionalidad es una de las tareas de especificacin ms difciles. Se podra decir que todo sistema tiene un nico caso de uso denominado "Usando el Sistema" o Usar el Sistema. La especificacin resultante sera de poca utilidad para entender qu tiene que hacer el sistema.

33 Gerundio: Forma invariable no personal del verbo, cuya terminacin regular, en espaol, es -ando en los verbos de la primera conjugacin, -iendo o -yendo en los de la segunda y tercera.

34 Infinitivo: Forma no personal del verbo, que en espaol lleva las terminaciones -ar, -er, -ir.

35 Es un lenguaje natural limitado en palabras y construcciones, lo que le da ms ms precisin y claridad, evitando ambigedades (el lenguaje natural humano carece de precisin y es muy ambiguo). http://www.alegsa.com.ar/Dic/lenguaje%20estructurado.php

36 En computacin el pseudocdigo (o falso lenguaje) es una descripcin de un algoritmo que utiliza las convenciones estructurales de un lenguaje de programacin verdadero pero que est diseado para la lectura humana en lugar de la lectura mediante mquina. http://es.wikipedia.org/wiki/Pseudocdigo



Mayo 2014 - Pg. 27

Por otro lado una desagregacin excesiva tampoco permite entender qu tiene que hacer el sistema, adems de requerir mucho ms trabajo. La pregunta que tiene que hacerse es: Qu es una "funcionalidad claramente diferenciada"? Por ejemplo, ingresar pedidos es un caso de uso y autorizarlos es otro? Cancelar los pedidos, es otro caso de uso, o es parte del caso de uso ingresar pedidos? Los criterios para dividir la funcionalidad de un sistema en casos de uso son difusos. Se utiliza el sentido comn37 al definir el grado de desagregacin de las funcionali-dades, a efectos que cada una sea bien entendida y claramente diferenciada por quienes van a utilizar la documentacin que se genera. Se podra dar la siguiente regla general: una funcin del sistema es un caso de uso si se debe indicar explcitamente al sistema que uno quiere acceder a esa funcin. Ejemplo: si se quiere dar de alta un pedido, acceder a la funcionalidad de "dar de alta pedido". Si se quiere dar de alta un campo del pedido, no se debe indicar al sistema que se quiere acceder a esa funcin pues forma parte del caso de uso mencionado. Sugerencia: Al pensar en el grado de detalle y la divisin de los casos de uso resulta til imaginar que se est escribiendo el manual del usuario del sistema: no tendra un solo captulo que describe toda su funcionalidad, como as tampoco un captulo por cada dato que se carga. Lo mismo ocurre con los casos de uso. A continuacin se presenta un modelo de caso de uso de un Cajero Automtico (Automated Teller Machine - ATM).38

37 Sentido comn: Modo de pensar y proceder tal como lo hara la generalidad de las personas. 38 http://epf.eclipse.org/wikis/openupsp/openup_basic/guidances/concepts/ use_case_model,_2jyfUAhVEduRe8TeoBmuGg.html



Mayo 2014 - Pg. 28

4.4.5. Extensiones (Extends) A veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren slo en algunas oportunidades. Ejemplo: sea un sistema en que los clientes pueden ingresar pedidos interactivamente, y que dentro de la funcionalidad del ingreso de pedidos el cliente puede solicitar detalle del producto. Generalmente ingresar los pedidos sin consultar el detalle. En caso de consultar el detalle, se produce una situacin que ocurre solamente en determinadas circunstancias dentro del caso de uso "Ingresando Pedido" o Ingresar Pedido. La extensin consiste en pasar a ejecutar otro caso de uso, "Mostrar detalles del producto en el ejemplo, que es controlado por el caso de uso original. Luego de ejecutada la extensin, el caso de uso original controla cmo termin y determina cmo seguir. La extensin lo que hace es ampliar un caso de uso, agregando una o ms alternativas. Una extensin no es una excepcin ni es una interrupcin de un caso de uso. Se representa por una lnea de trazos desde el caso que extiende a el caso que es extendido. Hay autores que la representan con lnea continua. Tambin es comn agregar la palabra extiende entre smbolos de mayor y menor, simples < > o dobles >. El uso del trmino en ingls extend o include en lugar de espaol es frecuente, tanto para extensiones como para usos (ver ms adelante). Las extensiones tienen las siguientes caractersticas: Representan una parte de la funcionalidad del caso que no siempre ocurre. Son

de ejecucin opcional. Son un caso de uso en s mismas. No necesariamente provienen de un error o excepcin.

4.4.6. Usos (Uses o include) Es comn que la misma fun-cionalidad del sistema sea accedida a partir de varios casos de uso. Ejemplo: la fun-cionalidad buscar un producto puede ser accedida desde el ingreso de pedidos, desde las consultas de productos, o desde los reportes de ventas por producto. Cmo se hace para no repetir esta funcionalidad en todos los casos de uso que la acceden? La respuesta es sacar la funcionalidad de los casos de uso donde aparece y definir esta funcionalidad en un nuevo caso de uso, que es usado por los casos de los cuales fue sacada. Este tipo de relaciones se llama relaciones de uso o de inclusin y se representa por una lnea punteada desde el caso que usa a el caso que es usado.



Mayo 2014 - Pg. 29

Ejemplo: el caso de uso "Obteniendo reporte de ventas por producto", usa al caso de uso "Buscando producto". Hoy se usa la palabra include (incluye) en lugar de uses (usa). Las caractersticas de las relaciones de uso o inclusin son: Aparecen como funcionalidad comn, luego de haber especificado varios casos

de uso. Son casos de uso en s mismos. Es ejecutado siempre que el caso que lo usa es ejecutado. No es opcional.

4.4.7. Generalizacin o herencia Es frecuente que varios actores tengan similitudes en el uso de un sistema. Por ejemplo, el jefe y el empleado. Uno puede hacer ms cosas con el sistema que el otro. Se dice que el empleado hereda las funcionalidades del jefe, porque puede hacer parte de las funciones del jefe. ste generaliza las tareas del empleado. En el caso de usuarios de una biblioteca, estn los socios de la biblioteca y los investigadores son un subgrupo de dichos socios, por lo que heredan sus propiedades, pudiendo agregar propias.

Esta generalizacin o herencia tambin puede darse a nivel de casos de uso. Para comprender el concepto de herencia, considerar el ejemplo siguiente:

La compra de un vaso de gaseosa hereda la compra de gaseosa, porque es un caso particular de uno general.

4.4.8. Construccin del grfico de casos de uso La construccin del grfico con casos de uso tiene el aspecto que se muestra en los dos ejemplos de las hojas siguientes. Notar que de acuerdo a lo planteado ms adelante, en 4.4.12, los ejemplos no cumplen con las recomendaciones dadas. El primer ejemplo est tomado de un trabajo hecho en base al Proyecto ALBA: Sistema Informtico Abierto de Gestin Unificada para Unidades Educacionales39 40 El grfico de casos de uso suele tener un tamao que puede llegar a dificultar su interpretacin. Por lo tanto, es probable que sea necesario dividirlo en varios grficos, en hojas separadas. Las reglas recomendadas para construir los grficos de casos de uso en la especificacin de requerimientos del software siguen a continuacin: Un grfico de casos de uso no debe mostrar ms de 15 casos. Si es necesario dividir el grfico, debe hacerse por actor. La primera particin

debe separar los casos centrales de los casos auxiliares, ya que probablemente les interesen a personas distintas.

39 http://www.proyectoalba.com.ar/ 40 http://www.csfa47.edu.ar/user/sitio/diagramas_uml.php#uadministrador1



Mayo 2014 - Pg. 30

Si las relaciones de uso y las extensiones entran en el diagrama principal, sin dejar de cumplir con la regla primera, dejarlas ah. Lo mismo se aplica a los actores abstractos.

Si las relaciones de uso no entran en el diagrama principal, mostrarlas en grficos aparte, teniendo en cuenta siempre mostrar todos los casos de uso que usan a otro en un mismo diagrama.

Si un caso de uso es usado por gran parte de los otros casos de uso, evitar mostrarlo en el grfico principal.

Ver 4.4.12 con las recomendaciones de lo que no debe hacerse en casos de uso.



Mayo 2014 - Pg. 31



Mayo 2014 - Pg. 32

4.4.9. Documentacin de Casos de Uso plantillas Una vez identificados todos los casos de uso, empezamos a documentar sus pasos; este documento se crea para cada caso de uso, detallando lo que el sistema debe proporcionar al actor cuando el caso de uso es ejecutado. Esta tarea no es estrictamente secuencial de la anterior: es posible que, mientras empezamos a documentar los casos, sigamos buscando otros nuevos. Un contenido tpico de un documento de caso de uso sera: Describir cmo comienza el caso de uso y cmo termina. Realizar un flujo normal de eventos. Realizar un flujo alterno de eventos. Detallar las excepciones al flujo de eventos.

Una plantilla es como un formulario pre-definido en el cual se deben completar, de manera pre-establecida los contenidos de las diferentes reas en que est dividido el formulario. Facilita el registro completo y uniforme, siguiendo reglas dadas. Existen diferentes diseos de plantillas para la documentacin de los casos de uso. Uno simple es el siguiente:



Mayo 2014 - Pg. 33

4.4.10. Campos de la plantilla Como se dijo, puede haber diferentes diseos de la plantilla. No hay uno solo que sea el adecuado, sino varios equivalentes. A su vez, los campos que se registran pueden ser diferentes en plantillas distintas. Sin embargo, los siguientes son campos que deben figurar: Identificador Es un cdigo nico que identifica cada caso de uso, tanto en la

plantilla como en el diagrama. Nombre Es nico, breve y a su vez lo ms explcito posible sintetizando la

descripcin. Descripcin Explicacin de qu hace o debe hacer el caso de uso. Redaccin

simple. Precondicin Cul, o cules son las condiciones que deben existir para que el

caso de uso se pueda ejecutar. Son requisitos previos a que el caso de uso se lleve a cabo.

Secuencia normal Aqu se explicita, paso a paso cul es la secuencia normal con todo el grado de detalle necesario de los pasos a llevar a cabo por el caso de uso cuando es activado o requerido por el actor. Es equivalente al flujo normal.

Post-condicin Cul o cules son las condiciones en que queda el sistema luego de ejecutado el caso de uso.

Excepciones En general, suele haber situaciones especiales en uno o varios de los pasos de secuencia normal. Por ejemplo, si se estn ingresando movimientos de un artculo, puede ser que el artculo no exista. Otro ejemplo: se accede a los datos de un socio y resulta que no est registrado. Las situaciones de excepcin no se registran en la secuencia normal, sino bajo excepciones. Se trata de los flujos alternativos. De esta manera, se facilita la comprensin de qu hace el caso de uso. Para cada posible excepcin en un paso de la secuencia normal se hace una entrada en excepciones, identificando el paso y detallando qu se hace en cada posible situacin de excepcin. Las excepciones surgen del anlisis funcional y del sentido comn, como se indic en los dos ejemplos dados.

Es deseable que estn presentes los siguientes campos: Autor Quien construy el caso de uso. Puede estar el nombre completo

o las iniciales. Se puede omitir si todos los casos de uso son construidos por la misma persona.

Fecha En que se confeccion. Versin Usualmente, los casos de uso se modifican, refinndolos, por lo

que es conveniente registrar el nmero de versin.

Son opcionales los campos siguientes, que no son funcionales, sino que definen propiedades que debe cumplir el caso de uso:



Mayo 2014 - Pg. 34

Rendimiento Es el tiempo mximo que puede insumir la ejecucin del caso de uso. Ejemplo: 6 segundos.

Frecuencia Es la cantidad estimada de veces que se ejecutar el caso de uso en una unidad apropiada. Ejemplo: 50 al da.

Importancia Pueden clasificarse los casos de uso en cuanto a su importancia en baja media o alta, o bien sin importancia, importante o vital. Est vinculado con la implementacin, con la puesta en marcha. Por ejemplo, puede ser una funcionalidad complementaria o imprescindible.

Urgencia Puede clasificarse en baja, media o alta, o bien sin urgencia o urgente. Est vinculado con la implementacin. Tiene que ver con el plazo para que est operativo.

Comentarios Es para incluir toda observacin que se considere apropiada para facilitar la comprensin del caso de uso que se define, y que no se deduce del contenido de los campos bsicos.

:

4.4.11. Nivel de detalle del caso de uso y solucin nica Un aspecto relevante en la construccin (o definicin) de los casos de uso est referido al grado de detalle al que es necesario llegar para definir un caso de uso. No hay una regla precisa para ello. Se recomienda llegar a un nivel de detalle tal que la tarea que haga el caso de uso sea nica y su especificacin en pasos sea sencilla.

De este modo no habra casos de uso con tareas repetidas. Se utilizarn includes vinculando los casos de uso con las tareas que aparecen en ms de una funcionalidad.

Este grado de detalle puede hacer que el diagrama quede muy cargado y se generen ms plantillas de las deseables, hacindose pesada la documentacin.

Ejemplo. Supongamos que tenemos un servicio de atencin de reclamos de clientes en una empresa. El actor es el cliente. El caso de uso puede ser uno solo Atencin

del reclamo o bien se puede desglosar en cuatro casos de uso:

Recepcin del reclamo

Verificacin de cliente

la especificación de requerimientos ... v 2.3

Documents