Inroduccion Los sistemas de informacin pueden ser manuales, automatizados o combinados.

La mayora de los sistemas de informacin hacen uso de las maquinas en sus diversas formas de presentacin. Un requerimiento es una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. De la especificacin de requerimiento (ER) depende la construccin y el funcionamiento del futuro sistema de informacin. El resultado de la ER es un conjunto de documentos que definen inequvocamente y en forma complete que tiene que hacer el sistema de informacin. La ER es una actividad de un equipo de trabajo multidisciplinario en el que participan casi todos los integrantes de la organizacin; este equipo no se limita a los usuarios internos, sino que tambin a los externos. La Ingeniera de Requerimientos Su principal tarea consiste en la generacin de especificaciones correctas que describen con claridad, en forma consistente y compacta, el comportamiento del sistema. La meta de IR es crear y mantener un documento de requerimiento del sistema. El cual se compone de tablas, grficos y textos. Principales actividades de la Ingeniera de Requerimientos. Hay diferentes tcnicas para cumplir con los objetivos de IR. A modo de ejemplos: Se consideran 4 etapas: 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 grafico, tablas y textos. Validacin de los requerimientos: verificacin de que los requerimientos realmente cumplen con las necesidades que tienen o tendrn los clientes. Al proceso de obtencin de datos se le llama licitacion. La segunda consiste en una visin ms realista de unos procesos de tres etapas, interactiva de sucesivo refinamiento. Obtencin de requerimientos Especificacin de requerimientos Validacin de requerimientos Requerimientos Un requerimiento es una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 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.

Tambin se puede definir un requerimiento como una representacin documentada de una condicin o capacidad de los prrafos precedentes. Alcance del sistema o dominio del problema. Determinar el alcance es ver cules son sus lmites, o cual es el dominio del problema. El dominio del problema, es conjunto de conceptos interrelacionados que es necesario conocer para entender el negocio del cliente, y por lo tanto, poder entender sus necesidades y proponer una solucin adecuada. El dominio del problema, o alcance del sistema, deben ser conocidos a efectos de saber que incluye y que excluye el sistema de informacin, sino adems, para saber cul es el mbito en que tienen que ser definidos los requisitos. Requerimientos funcionales y no funcionales. Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver caractersticas que de una u otra forma pueden limitar el sistema, como por ejemplo el rendimiento, interfaces de usuarios, fiabilidad, mantenimiento, seguridad, etc. Son aquellos que no se refieren directamente a las funciones del sistema, sino a las propiedades del sistema. Una posible clasificacin de los requerimientos no funcionales: Requerimiento del producto: 1. Rapidez del sistema 2. Memoria disponible 3. Fallos 4. Portabilidad 5. Usabilidad Requerimientos organizacionales 1. Polticas y procedimientos de la organizacin cliente 2. dem del desarrollo Requerimientos externos: 1. Incluye todos los requerimientos que derivan de los factores externos del sistema y de su proceso de desarrollo Requerimiento de dominio: 1. Provienen del dominio de aplicacin del sistema y que reflejan las caractersticas y restricciones de ese dominio. Es lo que se conoce como medio ambiente del sistema de informacin. Caractersticas de los Requerimientos 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 entender. Su redaccin es simple, con pocas palabras y exactas para quienes lo tienen que leer en el futuro. Completo: Proporciona informacin suficiente para su comprensin. Consistente: Es consistente sino es contradictorio con otro requerimiento. No ambiguo: Tiene una sola interpretacin, la redaccin usado en su definicin no causa confusin.

 Verificable: Es posible comprobarlo, analizarlo, inspeccionarlo o demostrarlo. Trazable: Que se puede saber de dnde surge y cul fue la evolucin del requerimiento.

Dificultades para definir los requerimientos. 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 hacienda ajustes sucesivos, tratando de salvar dificultades.

Personal involucrado en la Ingeniera de los Requerimientos. Los posibles roles que se pueden distinguir son: Usuario final: Son las personas que usaran el sistema desarrollado. Estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema. Usuario clave o lder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde ser empleado el software desarrollado. Usuario de testing (prueba): Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son los que validan si los requerimientos satisfacen las necesidades de los clientes. Encargado del soporte operativo Encargado del 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. Equipo tcnico informtico de desarrollo del sistema Stakeholders: Son los que pueden afectar o son los afectados por las actividades de una empresa. Ej.: Empleados, accionistas, sindicatos, etc. Analistas y programadores: Son los responsables del desarrollo del producto en s; ellos interactan directamente con el cliente. Otros

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. Actividades de la Ingeniera de Requerimientos. Existen cinco actividades principales: Anlisis del problema: El objetivo es entender las verdaderas necesidades del negocio. Es comprender los problemas del negocio, evaluar las necesidades inciales de todos los involucrados en el proyecto y que se proponga una solucin de alto nivel para resolverlo. Se siguen pasos a realizar:

1. comprender el problema: Consiste en determinar quien tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. 2. construir un vocabulario comn: Debe confeccionarse un glosario en donde definan todos los trminos que tengan significados comunes y que sern utilizados en el proyecto. 3. identificar a los involucrados: Esto es a todas las personas o grupos de personas que directa o indirectamente son afectadas 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 requerimiento. Para saber que personas son las involucradas debemos preguntarnos quien usara el sistema que se va a construir? Quien desarrollara el sistema? Quin probara el sistema? Quin documentara el sistema? Quin dar mantenimiento al sistema? 4.definir el alcance del sistema: Es definir los lmites y las restricciones del sistema. Debe saberse lo que se elaborara y lo que no. Se establecen las fronteras, tambin las restricciones ambientales, presupuestarias, plazos y condiciones tcnicas y de factibilidad. Evaluacin y Negociacin: 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. 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. 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 innecesario. Una vez hecha esta categorizacin, se puede tomar como estrategia general incluir los obligatorios, discutir los deseables y descartar los innecesarios. 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 seria de consideraciones: documentar todos los requerimientos a un nivel de detalle apropiado. Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causa en los cambios a los requerimientos antes de aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencia. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones. Especificacin de requisitos de Software (SRS) Es la actividad en la cual se genera el documento, con el mismo nombre que contiene una descripcin completa de las necesidades y funcionalidades del sistema que ser desarrollado; describe el alcance del sistema y la forma en que har sus funciones, definiendo los requerimientos funcionales y los no fundacionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier informacin que sirva de soporte y guas para fases posteriores. Es el resultado de las actividades de anlisis y evaluacin de requerimientos; este documento resultante ser utilizado como fuente bsica de comunicacin entre los clientes, usuarios finales, analistas de sistemas, personal de pruebas, y todo involucrado en la

implementacin del sistema. Las caractersticas de la SRS son: complete, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Validacin: Demuestra que los requerimientos definidos en el sistema son los que realmente quiere el cliente, que son correctos, completos y apropiados al negocio y a la organizacin. Con la validacin se garantiza que la SRS est libre de errores. En esta fase se revisa el cumplimiento de las caractersticas de la especificacin de requisitos con preguntas como: 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. Esta cada requerimiento claramente representado? Entendible. Pueden los requerimientos ser implementados con la tecnologa y el presupuesto disponible? Viable. Etc. Evolucion Es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos pueden cambiar por estar destinados a satisfacer las necesidades de los clientes. Los cambios a los requisitos involucre 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 eso, la administracin de cambios establecen polticas, registra los cambios que se producen en cada requerimiento, identifica dependencia entre ellos y mantiene un control de versiones. Tener versiones tiene algunos beneficios, como: prevenir cambios no autorizados, guardar revisiones de los documentos de requerimientos, recuperar versiones previas de los documentos, administrar una estrategia de versiones, prevenir la modificacin simultnea a los requisitos. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos. Tcnicas y herramientas. Son utilizadas para la especificacin de requerimientos las cuales son muchas y cada una de ellas es til en diferentes contextos. Ellas son: Entrevistas y cuestionarios: Sirven para reunir informacin provenientes de personas o grupos. La entrevista es oral, hay un contacto personal y directo, hay interaccin. En el cuestionario, por lo general no hay contacto personal, puede ser individual o colectivo, no hay interaccin. Lluvia de ideas: Para trabajar con la lluvia de ideas se aplican varios principios: aplazar el juicio, y no realizar crticas mientras se presentan las ideas. Para envidar inhibir; cuantas ms ideas se sugieren, mejores resultados se conseguirn; 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 harn que aparezcan otras nuevas. El equipo de lluvias de ideas debe estar formado por el director, el secretario y los principales. Con todas las ideas presentadas y documentadas, se elabora una lista definitiva de ideas, para seleccionar la ms interesante. La seleccin se realiza desechando las ideas que no tienen valor y se estudia si son validas las que se consideran interesantes.

Se establece una lista de criterios de conveniencia para cada idea. Se seleccionan las ideas mas tiles y si es necesario se ponderan, para finalmente determinar la idea ms apropiada. Prototipos: Permiten al desarrollador crear un modelo de software que debe ser construido. 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 tiene lugar un diseo rpido, consiste en una representacin de aquellos aspectos del software que sern visibles al usuario. El diseo rpido lleva a la construccin de un prototipo, que es evaluado por el cliente y el usuario y utilizado para refinar los requerimientos del software a ser desarrollado. Existen dos tipos de prototipos: 1. Prototipo rpido: Es un mecanismo para lograr la validacin precompromiso. Se utiliza para validar requerimientos en una etapa previa al diseo especfico. 2. Prototipo evolutivo: 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 continua hasta que se haya desarrollado el producto final. Los casos de uso y UML: Los casos de uso es una forma de especificar el comportamiento externo de un sistema. Permiten entender a un sistema a partir de los servicios o funciones que ofrece su entorno. Se consideran los siguientes conceptos: 1. Actores: Agrupacin uniforme de personas, sistemas o maquinas que interactan con el sistema que se analiza. Los actores son externos al sistema en estudio; por lo tanto identificar actores es parte de delimitar el sistema, y de definir su alcance. Los actores pueden ser o no parte de la organizacin donde se implementa el sistema. Un usuario puede accede al sistema como distintos actores. Si el sistema debe generar asientos contables para ser procesados por el sistema de contabilidad, este ltimo sistema ser un actor. 2. Sistemas: (ver pgina 25) 3. Lneas y flechas: Las lneas relacionan los actores con los casos de uso; las flechas, opcionales, indica si el actor acta sobre el caso de uso (flechas desde el actor), el caso de uso acta sobre el actor (fleche al actor), o bien es interactiva (fleche sobre). 4. Casos de uso: Secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Es indicado por un actor. Tambin puede ejecutarse en forma peridica, programada, o en respuesta de un evento que puede producirse en forma automtica por el propio sistema. Los casos de uso se representan con un ovalo, con el nombre del caso en su interior. El nombre del caso de uso siempre esta expresado desde el punto de vista del actor y no del sistema. Los casos de uso tienen las siguientes caractersticas: se documentan con textos preferentemente en lenguaje estructurado; describen tanto lo que

hace el actor como lo que hace el sistema cuando interacta con l, aunque el nfasis esta puesto en la interaccin; son iniciados por uno o varios diferentes actores; estn acotados al uso de una determinada funcionalidad del sistema, claramente diferenciada. Una funcin del sistema es un caso de uso si se debe indicar explcitamente al sistema que uno quiere accede a esa funcin. 5. Extensiones: Consiste en pasar a ejecutar otro caso de uso, Mostrar detalles del Producto. Luego de ejecutada la extensin, el caso de uso original controla como termino y determina como seguir. La extensin lo que hace es ampliar un caso de uso, agregando una o ms alternativas. Se representa por una lnea de trazos desde el caso que extendi al caso que es extendido. La extensin tiene determinadas 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. 6. Usos: Se representan por una lnea punteada desde el caso que usa al caso que es usado. Caractersticas: 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. 7. Generalizacin o herencia: Se dice que el empleado hereda las funcionalidades del jefe, porque puede hacer parte de las funciones del jefe. Esta generalizacin o herencia tambin puede dares a nivel de casos de uso. 8. Construccin del grafico de casos de uso: Las reglas recomendadas para construir los grficos de casos de uso en la especificacin de requerimientos de software siguen a continuacin: un grafico de caso de uso no debe mostrar ms de 15 casos; si es necesario dividir el grafico, debe hacerse por actor. La primera particin debe separar los casos centrales de los casos auxiliareis, ya que probablemente les interesen a personas distintas; 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 para 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 grafico principal 9. Documentacin de casos de uso- planillas: Un contenido tpico de un documento de caso de uso seria: describir como comienza el caso de uso y como termina; realizar un flujo normal de eventos; realizar un flujo alterno de eventos; detallar las excepciones al flujo de eventos. Una planilla es como un formulario pre-definido en el cual se deben complementar de manera pre-establecida los contenidos de las diferentes reas en que est dividido el formulario. 10. Herramientas automatizadas: Ventajas que proporcionan las herramientas automatizadas para IR son: mayor control de proyectos complejos; reduccin de costos y retrasos en el

desarrollo de un proyecto; mayor comunicacin entre los equipos de trabajo; facilitan la determinacin de la complejidad del proyecto y los esfuerzo necesarios. Comparacin de algunas herramientas. Entrevistas y cuestionarios: Ventajas: Proveen mucha informacin a travs de los usuarios. Pueden ser usadas para obtener un pantallazo del dominio del problema. Son flexibles. Desventajas: La informacin obtenida al principio puede ser redundante o incompleta. Volumen alto de informacin que requiere ser organizada. Lluvia de ideas: Ventajas: Se generan ideas tiles y creativas. Fomenta la innovacin. Desventaja: Requiere una especialista en la tcnica-director. Es necesaria una Buena compenetracin del grupo de participante. Prototipos: Ventajas: Ayudan a validar y desarrollar nuevos requerimientos. Permite comprender los requerimientos. Desventajas: El prototipo no es la versin final, sirve para pruebas parciales, lo cual no siempre es as entendido. Casos de uso: Ventajas: Representan de manera documentada los requerimientos del sistema desde el punto de vista de cada rol de usuario. Desventajas: Definir todos los casos de uso implica un importante esfuerzo.