Los Sistemas y Las Organizaciones

Sistemas de Informacin I

Universidad Nacional de Lujn

Departamento de Ciencias Bsicas Divisin Estadsticas y Sistemas rea de Sistemas de Informacin

01

Propiedades de los sistemas

Las propiedades de los sistemas, o propiedades emergentes segn Sommerville (2002), son los atributos del sistema visto como un todo. Estas propiedades no siempre pueden predecirse, por lo general, solo pueden medirse una vez que se hayan integrado los distintos subsistemas que conformarn el sistema completo. Clasificaremos a estas propiedades en dos tipos, propiedades funcionales y propiedades no funcionales: Las propiedades funcionales son inherentes al objetivo del sistema, visto como un todo dejando de lado las propiedades particulares de cada uno de los elementos que lo componen. Se describen en trminos de las capacidades que tiene el sistema en trminos de satisfacer necesidades de los usuarios (entendiendo por estos a todos quienes interactan con el sistema, ya sean personas, mquinas u otros sistemas). Las propiedades no funcionales estn relacionadas con el comportamiento del sistema en su entorno operacional. Desde este aspecto debe considerarse al sistema operando en su entorno y por lo tanto se considerarn propiedades tales como la fiabilidad, el rendimiento y la seguridad. Estas propiedades aparecen directamente relacionadas a la automatizacin de los procesos de una organizacin mediante la utilizacin de computadoras. Desde otra perspectiva, podramos decir que las propiedades no funcionales restringen o condicionan la manera en que se deben llevar a cabo las propiedades funcionales. Tanto las propiedades funcionales, como las no funcionales, de un sistema se definen en la especificacin de requerimientos. Vamos a desarrollar un ejemplo; supongamos que estamos planeando el desarrollo de un nuevo modelo de computadora personal; definiremos, entre alguna de sus propiedades funcionales, que debe tener la propiedad de poder ejecutar diferentes sistemas operativos, que permita la conexin de diversos perifricos mediante diferentes puertos de comunicacin, que tenga capacidad para direccionar determinada cantidad de memoria, etc. Entre sus propiedades no funcionales, definiremos que debe operar en un ambiente que tenga determinadas condiciones de temperatura y humedad, as como estar alimentada elctricamente por una tensin que se mantenga dentro de determinado rango (190-230 volts). Las propiedades que definamos para este equipo de computacin podrn verificarse siempre que se cumpla con las condiciones operacionales que fueron previstas en su construccin, si la temperatura del ambiente es inferior o superior a los valores preestablecidos, posiblemente, el computador comience a mostrar fallas, lo mismo ocurrira si la tensin que recibe no se encuentra dentro del rango que se ha determinado. Algunas de las propiedades que, generalmente, se requieren de los sistemas son: la fiabilidad, el rendimiento, la usabilidad o la seguridad. Estas propiedades no solo se refieren a un atributo que deber tener el comportamiento general del sistema, sino al comportamiento que el sistema no debera mostrar. Un sistema seguro es aquel que no permite accesos no autorizados a sus datos pero todos sabemos que es imposible predecir todos y cada uno de los modos probables de acceso y prohibirlos en forma explcita. Debido a ello, esta propiedad se valora por defecto; sabemos que un sistema es inseguro cuando alguien ha violado su seguridad, mientras tanto, el sistema es considerado seguro y siempre que cumpla adems con las medidas de seguridad que se hayan definido. Esta particularidad se da tambin con otras propiedades, se las considera alcanzadas hasta tanto no se verifique su carencia.

Los Sistemas y su Entorno

Ya hemos visto, que la Teora General de Sistemas plantea que una de las caractersticas de los sistemas es el ambiente: es todo lo que est fuera del sistema. El ambiente acta sobre el sistema cuando nos provee insumos (entradas) o cuando recibe sus productos (salidas). Por otra parte, hemos definido la Jerarqua Sistmica asumiendo para ello que todo sistema se encuentra involucrado en un sistema de nivel superior y a su vez est compuesto por subsistemas. Llamaremos ahora, a todo lo que se encuentra fuera del lmite del sistema su entorno (o contexto). El entorno afecta el funcionamiento y rendimiento del sistema. Este puede verse tanto como un sistema por s mismo o como un cierto nmero de sistemas que interactan entre ellos y con nuestro sistema en estudio (aquel en el que se encuentra nuestro foco de atencin). Observemos el siguiente ejemplo: Sistema de Educacin Superior Argentino Universidad Nacional de Lujn Carrera XXXXX Tercer cuatrimestre
Asignatura Asignatura Asignatura . 1 2 3

En el mismo vemos como en el entorno de la Asignatura 1 se encuentran las restantes asignaturas correspondientes al tercer cuatrimestre de la carrera, que son aquellas que interactan en el mismo momento en que nosotros estamos fijando nuestro foco de atencin en esta asignatura. En otro momento puede ser importante observar la relacin de la Asignatura 1 con las asignaturas precorrelativas y postcorrelativas. El entorno del tercer cuatrimestre de la carrera, es la Carrera XXXXX como un todo. Para la carrera, el entorno es la Universidad Nacional de Lujn (UNLu), lugar donde se desarrollan las actividades curriculares de la misma; mientras que para la UNLu su entorno es el Sistema de Educacin Superior Nacional. Este ejemplo no es una visin exacta del entorno pues dependiendo del tipo de interacciones que estemos observando aparecern unos u otros sistemas del entorno interactuando con nuestro sistema. Por otra parte, en este ejemplo se da la coincidencia de que los sistemas que identificamos en el entorno se encuentran involucrados en una jerarqua sistmica. Esto no siempre se da de este modo pues en el entorno del sistema, en el cual hemos fijado el foco de atencin, puede haber sistemas interactuando que no correspondan a una misma jerarqua sistmica. Pensemos, por ejemplo, que tambin se encuentra en el entorno de cada Asignatura, la oficina de alumnos de la Universidad, pues es la que determina que estudiantes cumplen con las condiciones acadmicas para poder tomar el curso, la comisin de plan de estudios de la carrera, pues es quien determina el rgimen de correlatividades de la carrera y as podemos encontrar otros sistemas que interactan con la asignatura pero no participan, necesariamente, de la misma jerarqua sistmica.

Por qu nuestro inters en el entorno? Existen dos razones por las cuales la Ingeniera de Sistemas considera importante comprender el entorno del sistema en estudio: 1. En muchos casos, el sistema ha sido diseado para producir cambios en su entorno, por lo tanto, el funcionamiento del sistema solo puede ser evaluado por los efectos que produce en su entorno. Pensemos por ejemplo en un sistema de calefaccin cuyo objetivo es mantener la temperatura ambiente clida. Si el sistema es exitoso en cumplir su objetivo, entonces modificar las condiciones de su entorno. En otras palabras, podemos decir que el sistema es una mquina para convertir energa. Analicemos la implantacin del sistema de cajeros automticos el cual no tiene otro objeto que hacer de interfaz entre el sistema bancario y los usuarios del mismo. En este caso, resulta esencial la interaccin entre el cajero y el usuario y entre el cajero y el banco en el cual se encuentra radicada la cuenta sobre la cual se realizan las operaciones. 2. El funcionamiento de los sistemas, y principalmente el de los sistemas abiertos, se ve afectado por los cambios en su entorno. Recordemos el ejemplo que dimos de una computadora personal la cual ve alterado su funcionamiento si las condiciones de temperatura o suministro elctrico de su entorno se modifican ms all de los rangos de tolerancia que fueron previstos. Ya dimos una idea de que hay distintos entornos y que los identificamos en funcin del tipo de interaccin que estamos observando. Hay entornos del tipo fsicos, espacios en los que el sistema debe operar; entornos organizacionales, como el que hemos ejemplificado para una asignatura; entornos econmicos y entornos sociales. Si trabajamos en un sistema de informacin sin comprender adecuadamente el entorno organizacional en el cual se deber desempear el sistema, es altamente probable que no cumpla con las necesidades propias de la organizacin y por consiguiente sea rechazado por los usuarios y los directivos de la organizacin. Por este motivo, cuando trabajemos con sistemas de informacin en entornos organizacionales, tendremos que considerar los factores humanos y organizacionales que se derivan del entorno del sistema y que pueden afectar su diseo. La actividad a llevar a cabo, es verificar si con nuestra intervencin o propuesta estamos provocando: Cambios en el proceso. Si el sistema requiere cambiar los procesos en el entorno, ser necesario implementar, con los usuarios del mismo, un fuerte programa de capacitacin. Si los cambios son significativos, o implican que la gente pierda su trabajo, existe el peligro de que haya resistencia al sistema. Pensemos que, producto de la implantacin del sistema de cajeros automticos, al mismo tiempo en que se ampli la banda horaria en que los usuarios pueden hacer sus operaciones bancarias, los bancos tienen contratado menos del 50% del personal que necesitaran para atender las cajas si no se hubiera implementado este sistema. Cambios en el trabajo. Si el sistema inhabilita a los usuarios en su entorno o provoca que se cambie la forma de trabajar, seguramente se resistirn a la introduccin del sistema en la organizacin. Pensemos que cuando se implementa en una organizacin un sistema que cambia la forma de trabajar; quienes se vean involucrados en el cambio van a resistirse por una simple cuestin de costumbre. Cambios organizacionales. Es posible que el sistema cambie la estructura de poder de una organizacin. Si se han automatizado la mayora de los procesos organizacionales, aquellos que tengan mayor domino del sistema y sepan como operarlo comienzan a tener mayor poder poltico. Por otra parte la posibilidad de sociabilizar la informacin de la organizacin har perder poder a quienes eran considerados los dueos de la informacin. Considerar estos factores es, generalmente, un aspecto crtico para determinar si un sistema cumple o no de manera adecuada los objetivos que se le han asignado. Tambin debemos

sealar que predecir los efectos de estos factores sobre los sistemas es una tarea muy difcil para quienes no tienen experiencia en estudios sociales o culturales, ms an si no tienen experiencia en implantacin y puesta en marcha de sistemas computarizados. Existen numerosos trabajos que estudian los efectos de los sistemas en las organizaciones, Sommerville(2002) propone la lectura de un trabajo de Ackroyd y Harper(1992), Information Technology and Practical Police Work. Nosotros proponemos la lectura y discusin del siguiente artculo, con el objetivo de identificar que tipo de cambios (en los procesos, en el trabajo u organizacionales) fueron tenidos en cuenta o dejados de lado por el equipo de sistemas que tuvo a su cargo el proyecto: El servicio de ambulancias de Londres
El Servicio de Ambulancias de Londres (SAL) maneja el trfico de ambulancias en la cuidad de Londres, incluyendo el centro y gran parte de la zona conurbana. Esto cubre un rea de cerca de 600 millas cuadradas, cerca de 5000 pacientes por da en 750 vehculos. El SAL recibe cerca de 2000 llamadas por da, incluyendo ms de 1300 llamadas de emergencia. El sistema que se discutir aqu es un sistema despachador 1 auxiliado por computadora (DAC). Tal sistema DAC tiene la siguiente funcionalidad: Maneja las llamadas que recibe, aceptando y verificando los detalles del incidente incluyendo la localizacin del mismo; Determina cual ambulancia debe ser enviada; Maneja la movilizacin de la ambulancia y comunica los detalles del incidente a la ambulancia; Toma en cuenta la administracin de los recursos de las ambulancias, en particular la posicin actual del vehculo para minimizar los tiempos de respuesta. Un sistema DAC completo es algo complejo. En el pnico, alguien podra llamar y decir que el accidente ha sucedido enfrente de Foyle, asumiendo que cualquiera conoce donde est localizada esta librera. Un componente de este sistema es una gua telefnica extensiva que incluye la identificacin de los telfonos pblicos para ayudar a resolver este tipo de problema. Pensemos que este sistema fue desarrollado en una poca donde los celulares no estaban difundidos y por lo tanto las llamadas a emergencias se hacan desde telfonos fijos. Siendo as, con una gua reversa, es decir, dado el nmero que llama obtener la ubicacin, ayudaba a resolver el problema en cuestin. El sistema DAC tambin contiene un sistema de radio, terminales mviles en las ambulancias y un sistema de localizacin automtica de vehculos. El proyecto DAC del Servicio de Ambulancias de Londres fue iniciado en otoo de 1990. La terminacin se contempl para enero de 1992. A esa fecha, sin embargo, el software estaba todava lejos de estar terminado. En los primeros nueve meses de 1992, el sistema fue instalado pieza por pieza sobre diferentes divisiones del SAL, pero nunca fue estable. El 26 y 27 de octubre de 1992, hubo serios problemas con el sistema y se decidi revertirlo a un modo de operacin semiautomtico. El 4 de noviembre de 1992 el sistema se vino abajo. La Autoridad Regional de Salud estableci un Equipo Examinador para investigar las fallas y la historia que haba llevado a ellas. Ellos acabaron con un reporte de 80 pginas, el cual se lee como una novela de suspenso. Aqu se subrayarn algunos de los puntos tratados en el reporte. Ningn servicio de emergencia haba intentado llegar tan lejos. El plan fue mover todo el proceso manual en el cual se llenaban formularios y se transportaban de un empleado al siguiente va una cinta transportadora a una automatizacin completa, en un solo salto. El esquema fue muy ambicioso. Parece ser que los participantes no tenan muy en mente todos los riesgos que estaban tomando. Mucho antes de que el proyecto comenzara, ya se haba cuestionado a la firma consultora administrativa que se haba contratado para que trabajara en la seleccin del contratista. Esta empresa haba sugerido que una solucin completa podra costar 1.5M de libras y tomar 19 meses. Tambin haban indicado en su informe que si no se encontraba una solucin empaquetada (producto ya construido), los costos estimados se incrementaran significativamente. De todas maneras, se escogi una solucin no empaquetada (a medida), y solo se tuvieron en cuenta los aspectos econmicos de este informe, o eso es lo que parece.
1

El trmino despachador se utiliza en este artculo como derivador de ambulancias

La licitacin obtuvo propuestas de 35 compaas. Las especificaciones y el calendario de ejecucin fueron discutidos con esas compaas. El calendario propuesto fue de 11 meses. Y aunque muchos proveedores plantearon cuestionamientos sobre lo ajustado del plan, les fue dicho que eso no era negociable. Solo 17 proveedores entregaron propuestas completas. Se seleccion la oferta de menor costo, cerca de 1M de libras. Esta oferta fue de cerca de 700,000 libras ms barata que la siguiente oferta ms barata. Nadie se cuestion esta enorme diferencia. La propuesta seleccionada superficialmente sugera que la compaa ya tena experiencia en diseo de sistemas para servicios de emergencia. Esto no era mentira: ellos ya haban desarrollado sistemas administrativos para tales servicios pero el sistema SAL fue mucho ms grande que cualquier proyecto que ellos hubiesen manejado antes. El sistema propuesto impactaba significativamente en la forma en que la tripulacin de las ambulancias llevaba a cabo su trabajo. Este deba ser por lo tanto el aspecto fundamental a tener en cuenta en la implantacin del proyecto. Si la tripulacin no presionaba los botones correctos, en la forma correcta, en el tiempo preciso y en el orden correcto, podra resultar un caos. An as, hubo muy poco involucramiento de los usuarios durante el proceso de ingeniera de requerimientos. El sistema DAC proyectado operara automticamente y movilizara los recursos ptimos (segn su criterio) para cualquier incidente. Esto modificaba muchas de las prcticas de trabajo presentes, las cuales la administracin consideraba anticuadas y de poco inters para el SAL. Por ejemplo, el nuevo sistema localizara los recursos disponibles ms cercanos de la estacin de origen. Con esto, podra ocurrir el siguiente escenario: La tripulacin de John tiene que ir a un accidente a unas pocas millas al este de su base. Una vez all, son dirigidos a un hospital a unas pocas millas ms al este para dejar al paciente. Si llegan otras llamadas y parece que John es el ms cercano, a l se le ordena viajar unas pocas millas ms al este. Y as sucesivamente. De esta forma, la tripulacin podra operar cada vez ms lejos de su base y en un territorio que no les es familiar (una de las caractersticas de Londres es que hay dos regiones y los que viven en una de ellas desconocen la otra). Con esto, se pierde tiempo por tomar caminos equivocados, o mas an por parar para preguntar por las direcciones. Adems, al finalizar su jornada tendra que viajar ms para volver a su base. A la tripulacin no le gust este aspecto del nuevo sistema. El nuevo sistema tampoco tomaba en cuenta la flexibilidad de las estaciones de emergencia locales, al decidir cuales recursos asignaba. En el nuevo esquema, la administracin de recursos fue centralizada completamente y manejada por el sistema. De esta forma, supongamos que John corra hacia donde las ambulancias estaban estacionadas y la computadora haba ordenado tomar el coche nmero 5. John estaba apurado y posiblemente podra no reconocer el coche nmero 5, o quizs ste est estacionado detrs de otro coche y era muy difcil sacarlo. De manera que John poda perder su paciencia y decidir tomar el coche nmero 4. Esto significaba un problema: el sistema asignara el vehculo nmero 4 a otro accidente y este ya no se encontrara en el estacionamiento. Por otro lado, el coche 5 no se mova, por lo tanto el sistema podra ordenar a otra ambulancia concurrir al accidente y de esta forma dos ambulancias iran al mismo lado. La gente responsable de estos requerimientos tena mal juicio o ingenuidad sobre lo que los sistemas computarizados podran brindar en las prcticas de los humanos. Las computadoras estn aqu para ayudar a la gente a hacer su trabajo, y no viceversa. Cuando los sistemas generan resistencia en quienes lo deben operar estn condenados al fracaso. La cada del sistema el 4 de noviembre de 1992 fue causada por un error de programacin menor. Unas tres semanas antes, un programador que haba estado trabajando en una parte del sistema olvid remover una pequea parte del cdigo del programa. El cdigo en s mismo no era daino. Sin embargo, este ocupaba una pequea cantidad de memoria cada vez que el sistema generaba una movilizacin de un vehculo. Esta memoria no era liberada y el sistema funcionaba sin interrupcin durante las 24 horas del da. Despus de tres semanas, se consumi toda la memoria y el sistema se cay.

El proyecto del SAL no fall debido a ese error de programacin. Este solo fue la ltima gota que derram el vaso. La previsin del proyecto fue demasiado rgida. La administracin tanto del Servicio de Ambulancias de Londres como del contratista o empresa contratada tenan muy poca o ninguna experiencia en desarrollo de proyectos de software de este tamao y complejidad. Fueron demasiado optimistas en su anlisis de riesgos. Asumieron que toda la gente podra interactuar con el sistema y podran hacerlo de la forma correcta, todo el tiempo. La administracin decidi sobre la funcionalidad del sistema, sin realizar ninguna consulta con quienes seran sus usuarios primarios. Cualquier proyecto de tales caractersticas est condenado a fallar, desde el mismsimo primer da.

De manera ideal, podemos decir que todo el conocimiento relevante del entorno deber incluirse en la especificacin del sistema, de manera tal que pueda ser tenido en cuenta por los diseadores del sistema. Los diseadores del sistema solo debern hacer suposiciones sobre el entorno basndose en otros sistemas comparables y en el sentido comn.

Estructura Organizativa y Sistemas de Informacin

El anlisis y diseo de sistemas de informacin no es una actividad que pueda desarrollarse desvinculada del contexto mayor con el que interacta: la estructura organizativa sobre la cual se implantan los sistemas. Este vnculo indisoluble hace que debamos estudiar tanto las tcnicas de anlisis de sistemas como las de anlisis estructural. El anlisis estructural es el estudio de la forma en que se dividen las tareas en una organizacin, la asignacin de funciones y responsabilidades entre sus miembros y las relaciones jerrquicas entre los mismos. El propsito de este tipo de anlisis es verificar la estructura de la organizacin para adecuarla a los objetivos corporativos y al mantenimiento adecuado del control interno. Desde el punto de vista sistmico, una organizacin puede verse como un sistema de mayor jerarqua compuesto por subsistemas que deben mantenerse interrelacionados entre s. Las diversas funciones que se cumplen en la organizacin se integran a travs de tecnologa informtica que permite formar un todo organizacional efectivo. Para efectuar un correcto anlisis de los requerimientos de informacin y para desarrollar sistemas de informacin que satisfagan esos requerimientos, es fundamental comprender el concepto de organizacin como un todo integrado. Lardent(2001) plantea que al construir un sistema de informacin es necesario interpretar la relacin entrada/salida para crear las interfaces que relacionan un sistema con otro; una salida de informacin del subsistema ventas se convierte en entrada del subsistema de produccin (para programar la produccin); una salida del sistema de produccin se convierte en una entrada del subsistema ventas (para conocer la disponibilidad). De esta manera debera poder describirse todas las relaciones que existen entre los subsistemas de la organizacin encontrando la dependencia funcional que existe entre un subsistema y otro.

Operaciones de una empresa

Las operaciones de Comprar, Pagar, Producir, Vender y Cobrar resultan insustituibles y solo puede estar ausente la tercera, en el caso de empresas que se dediquen a la compra / venta de productos terminados. A estas operaciones las denominaremos operaciones primarias. Estas operaciones primarias son las que sostienen el cumplimiento de los objetivos de la organizacin. De todas maneras, tambin existen operaciones que tienen por finalidad mejorar el desempeo de las operaciones primarias o implementar controles para el logro ms eficiente de las operaciones primarias. A estas operaciones se las denomina operaciones secundarias, las ms destacadas son:

Administracin general (contabilidad, asistencia, liquidacin de haberes, etc) Financieras (bancos, flujo de caja, crditos, cobranzas, etc) Conservacin de activos (reparaciones, inversiones en bienes, mantenimiento de vehculos, etc)

Estas operaciones pueden ser vistas como algunos de los subsistemas que se pueden identificar en la empresa.

Control de operaciones
Se debe procurar que la informacin que brinda la contabilidad est exenta de errores o deformaciones. Si los controles no son eficaces podran deslizarse errores o fraudes. La funcin administrativa del control es la medida y la correccin del desempeo de las actividades de los subordinados para asegurar que, los objetivos y planes de la empresa diseados para conseguir los objetivos, se estn llevando a cabo. Las operaciones bsicas por el hecho de ser frecuentes y repetitivas permiten ser normalizadas. La normalizacin consiste en programas que indican la forma ms adecuada de realizar las operaciones, y se materializa en los manuales de procedimientos o de trmites y en los circuitos administrativos o cursogramas2. Los manuales de procedimientos establecen en detalle cules son las operaciones y en que secuencia se deben presentar para llevar a cabo una determinada operacin. Al mejorar el programa, lo que corresponde es la optimizacin del procedimiento y la posterior comunicacin de las instrucciones al personal afectado. El control interno es el encargado de garantizar que las operaciones que reflejan los registros hablan de la verdadera situacin del negocio, que se minimicen las posibilidades de errores y fraude, y que se respeten los procedimientos que se han implantado a travs de manuales de instrucciones. El propsito es: la prevencin de errores y fraudes en la ejecucin de las operaciones, garantizar las registraciones que habrn de servir de fuente para los informes y estados provenientes de la contabilidad, procurar detectar cualquier desvo sobre los procedimientos estipulados y en general ejercer un control efectivo sobre todos los aspectos del negocio.

La base del control interno es la divisin del trabajo, una operacin bsica que puede ser subdividida en varias partes, nunca debe ser realizada por una sola persona. Para que esa complementacin pueda llevarse a cabo ser necesario programar la operacin bsica instruyendo y capacitando al personal para su ejecucin. Ser factible establecer un control por oposicin o automtico entre las personas. Al haber mayor control sobre el desarrollo de las operaciones, se intensifica el control sobre las registraciones y los datos que pueden extraerse de los registros sern ms confiables. Es necesario que se instrumente un sistema de informacin entre los distintos participantes, para que cada uno conozca cundo le corresponde actuar, cules son las operaciones que ya se han cumplido y cul fue el resultado de las mismas, y a la vez pueda indicar cuando concluye su parte y cul es la informacin que produjo. Esta informacin se materializa en comprobantes bsicos y en los registros previstos. Un sistema de control interno no puede garantizar totalmente la deteccin de errores, fraudes o desvos de los procedimientos administrativos, ni tampoco la exactitud de los informes. En algunos casos no resulta

Para conocimiento de esta tcnica debe trabajarse con la gua de autoestudio sobre cursogramas

posible aplicar el control interno en forma estricta, por resultar antieconmico en estos casos; se suele aplicar un control directo ms intenso. (Ej. Arqueo fsico de inventario en un hipermercado) Las normas de control interno3 son una gua que sirve a quien disea sistemas. El uso o aplicacin de estas normas deber estar vinculado con las caractersticas propias de la empresa y a las particularidades que adopta la operacin. Un ejemplo de norma de Control Interno es determinar que los cheques que se libran para el pago a proveedores deber ser firmados por dos personas de la organizacin que trabajen en distintos sectores. Por ejemplo alguien de pagos y alguien de administracin. De esta manera, la segunda firma sirve de control respecto de que el monto que se est pagando se corresponde con los comprobantes que dan sustento al trmite.

Automatizacin de los sistemas organizacionales

El estudio de los sistemas de informacin en una organizacin, generalmente, se lleva a cabo por los siguientes motivos: Identificar el origen de problemas de control, performance, eficiencia, seguridad, etc. con la finalidad de proponer soluciones y mejoras. Automatizacin de actividades repetitivas que se estn ejecutando en forma manual. Mejorar el desempeo del sistema actual en trminos de performance, control de operaciones, informacin que produce, etc. Automatizacin de los circuitos de informacin, con la finalidad de mejorar los procesos de negocio y disminuir los tiempos muertos. Estos procesos de automatizacin han ido evolucionando de la misma manera que lo hizo el hardware y el software, acompaado por una baja de los costos de estos elementos que resultan esenciales para la automatizacin. En trminos de la pirmide organizacional, una organizacin debe, necesariamente, comenzar por la automatizacin de sus sistemas transaccionales u operacionales para ir evolucionando hacia los niveles superiores de la pirmide mediante sistemas de apoyo a las decisiones hasta llegar a sistemas de informacin ejecutiva. Este proceso de automatizacin hace que los sistemas van disminuyendo a cantidad de informacin que administran para pasar a administrar conocimiento organizacional. Bibliografa Ingeniera de Software de Ian Sommerville. Editorial Addison Wesley (2002). Ingeniera de sistemas basados en computadora: pp. 20 25 Sistemas de Informacin para la Gestin Empresaria, Planeamiento, Tecnologa y Calidad de Alberto R. Lardent. Editorial Prentice Hall (2001). Estructura organizativa y sistemas de informacin: pp. 79 - 119

Para mayor detalle respecto de las distintas normas de control interno, consultar el apunte Circuitos Administrativos y Normas de Control Interno

Automatizacin del Flujo de Trabajo

Sistemas de Informacin I

Universidad Nacional de Lujn

Departamento de Ciencias Bsicas Divisin Estadsticas y Sistemas rea de Sistemas de Informacin

02
10

Flujo de Trabajo - Workflow

La transformacin del software empresarial ha evolucionado desde la automatizacin de procesos manuales a la automatizacin del flujo de trabajo. Flujo de trabajo es la secuencia de acciones y pasos usados en los procesos de negocios. El flujo de trabajo automatizado aplica tecnologa al proceso, aunque no necesariamente en cada accin. Workflow se relaciona con la automatizacin de los procedimientos donde los documentos, la informacin o tareas son transferidas entre los participantes del sistema de acuerdo a un conjunto de reglas previamente establecidas. El objetivo es llegar a culminar una meta comn impuesta por la empresa. Podemos ver al Workflow como un conjunto de mtodos y tecnologas que nos ofrece las facilidades para modelar y gestionar los diversos procesos que ocurren dentro de una empresa. Se podra decir que la tecnologa de Workflow se basa en la idea de que algunas tareas son realizadas ms efectivamente por las computadoras que por las personas. Los humanos somos buenos para tomar decisiones, innovar, identificar hechos inesperados. Pero usualmente no somos eficientes en actividades tales como: buscar un documento entre cientos; tener presentes los vencimientos de las tareas que se tienen que realizar dentro de ciertos plazos; as como tambin el asegurarse que el trabajo terminado pase de un lugar a otro respetando una secuencia definida. La actuacin del Workflow se ha desarrollado dentro de tres etapas, podremos identificar lo que sera un Workflow Manual en la primera etapa, el Workflow Automatizado dentro de la segunda, y lo que ofrece el Workflow en la actualidad. En el primer caso podemos ver que antes que la informtica se integrara al trabajo cotidiano, ste era realizado manualmente combinando toda la informacin en distintas carpetas/legajos/libros de registracin/ fichas/cuadernos. En este ambiente era bastante difcil determinar el estado de un trmite, as como tambin el hecho de determinar el proceso a seguir. Surge la necesidad de remplazar las actividades manuales por actividades automticas, buscando tener un mayor control y coordinacin sobre toda la informacin, logrando automatizar ciertas tareas, que antes se realizaban manualmente. Por esto podemos hablar de un Workflow Automatizado refirindonos a la automatizacin del flujo de trabajo. Por ejemplo, la automatizacin del registro de entrada y salida de personal, pas de tarjetas mecnicas o registro de firmas a la lectura digital de un cdigo que es informado, en tiempo real, al sistema que contabiliza las horas trabajadas por empleado. Esta automatizacin de esta tarea permite conocer que empleados se encuentran, en determinado momento, en la organizacin sin necesidad de trasladarse hasta el fichero de tarjetas y verificarlo manualmente. Finalmente llegamos a la actualidad, donde nos encontramos con el objetivo de resolver eficientemente el Workflow. Actualmente existe una proliferacin de diversos mecanismos de intercambio de informacin. Los mismos facilitan el manejo del flujo de informacin en general. Las metas son similares a las de pocas anteriores, pero el punto de partida y el impacto son distintos. Dentro de la evolucin actual del Workflow como tecnologa, identificamos la evolucin y creacin de ciertos productos que acompaan al Workflow:

Procesamiento de imgenes: En este caso se captura en forma de imagen electrnica (por ejemplo mediante un escner) la informacin o documento que se desea, para luego ser pasada entre los diferentes participantes con distintos propsitos, durante la realizacin de un proceso. Administracin de documentos: Esta tecnologa esta relacionada con la administracin del ciclo de vida de los documentos. Esta incluye facilidades para guardar en un depsito comn aquellos documentos que se comparten, as como tambin las facilidades para el acceso o modificacin de los mismos mediante un conjunto predefinido de reglas. Correo Electrnico y Directorios: El Correo Electrnico provee las facilidades para distribuir informacin entre individuos de una organizacin, o entre distintas organizaciones. El sistema de directorios no slo provee una forma de identificar a los participantes dentro de un conjunto de

11

direcciones de correo electrnico, nos ofrece adems la potencialidad de registrar la informacin sobre los participantes, es decir, roles dentro de la empresa u otros atributos.

Aplicaciones basadas en transacciones: Las transacciones de Workflow guardan la informacin, reglas, roles, y otros elementos sobre un servidor de Bases de Datos Relacionales, ejecutando la aplicacin de Workflow sobre una interfaz grfica para los usuarios. Estas aplicaciones tpicamente incluyen componentes grficos para el ingreso de datos. Procesamiento de Formularios: El ambiente de los formularios es amigable y familiar para muchos usuarios. ste es un excelente vehculo para el manejo de la informacin dentro de una aplicacin de Workflow, basado en el valor de los campos de un formulario. Algunos productos para implementar aplicaciones de Workflow proveen constructores de formularios, o se integran a constructores de terceros.

Algunas de las razones por las cuales las organizaciones podran considerar adoptar una solucin de Workflow son la eficiencia en los procesos y estandarizacin de los mismos. Esto conduce a:

Una reduccin de costos dentro de una empresa (la reduccin ms significativa es debida a la reduccin de gente empleada). La estandarizacin de los procesos lleva a tener un mayor conocimiento de los mismos, lo que a su vez conduce a obtener una mejor calidad de estos. La administracin de los Procesos (Process Management). Utilizando la tecnologa de Workflow es posible monitorear el estado actual de las tareas as como tambin observar cmo evolucionan los planes de trabajo realizados. Permite ver cules son los embotellamientos dentro del sistema, es decir aquellas tareas o decisiones que estn requiriendo de tiempo no planificado y se tornan en tareas o decisiones crticas. La asignacin de tareas a la gente. La asignacin de tareas se realiza mediante la definicin de roles dentro de la empresa, eliminando la tediosa tarea de asignar los trabajos caso por caso. Los recursos disponibles. Se asegura que los recursos de informacin (aplicaciones y datos) van a estar disponibles para los trabajadores cuando ellos los requieran. El diseo de procesos.

Hay adems muchos aspectos operacionales por los cuales es deseable contar con una tecnologa de Workflow ya que actividades como la secuencia de tareas, quienes la realizan, mecanismos de control y monitoreo, son implementadas por software de Workflow. El Workflow permite automatizar diferentes aspectos del flujo de la informacin: rutear los trabajos en la secuencia correcta, proveer acceso a datos y documentos, y manejar ciertos aspectos de la ejecucin de un proceso. Resumiendo, es de destacar a Workflow como una herramienta de automatizacin de trabajos de oficina que ha ganado aceptacin y uso en sistemas de negocios, a causa de su habilidad para incrementar la productividad. Pensemos en unn documento que necesita moverse de un lugar a otro hasta concluir un trmite, la informacin fluye mediante formularios electrnicos segn rutas y reglas predefinidas. Workflow es La automatizacin de los procesos que se usan diariamente en una empresa. Una aplicacin de Workflow automatiza la secuencia de acciones, actividades y tareas usadas para ejecutar los procesos, incluyendo monitoreo en cada instante del proceso, as como las herramientas para administrar el mismo. Workflow es La implementacin del proceso de distribucin electrnica de trabajo.

12

Primero, Workflow refleja las prcticas y procedimientos de las organizaciones. En otras palabras, Workflow debe capturar el quin, qu, cundo, dnde y porqu de una organizacin y los usa para controlar el flujo y la distribucin del trabajo. Segundo, Workflow controla el flujo y distribucin de trabajo electrnicamente. Workflow es la descripcin de procesos de negocios en trminos de tareas, prioridades, relaciones, organizaciones, informacin y herramientas. Es decir, Workflow son las tareas, pasos para procedimientos, organizaciones o personas involucradas, informacin de entrada y salida requerida, y herramientas necesarias para cada proceso de negocio. Plantearemos ahora, que problemas se presentan generalmente en los negocios. Tradicionalmente, los problemas que se han presentado son los siguientes:

No existen medios efectivos de comunicacin, Se pierden solicitudes, Empeora la imagen de la empresa, Falla la coordinacin interna, No se sabe qu est pasando, Falla el control de solicitudes reiteradas, No hay flexibilidad para adaptarse a los cambios, No es posible sistematizar los nuevos problemas recurrentes, Aumentan los problemas clasificados como OTROS, No existen datos de seguimiento, slo conozco la fotografa actual y No se dispone de TODA la informacin.

Para solucionar los problemas precedentes, se necesita:

Responder en forma efectiva a los requerimientos de los clientes, Conocer qu est pasando y cundo ocurre, Anticiparse a los problemas que puedan ocurrir, Adaptarse a los cambios en el mercado y Hacer todo esto en forma eficiente.

Ventajas de un sistema Workflow.

La forma de resolucin de los problemas mencionados consiste en un sistema basado en Workflow, con las siguientes caractersticas:

Desaparecen los tiempos muertos, Optimizacin del tiempo total de la transaccin, Evita la duplicacin de tareas, La informacin es colectada en la fuente, sin intermediarios, Todos conocen el estado de las transacciones,

13

Integracin de controles administrativos con sistemas informticos, Seguimiento, Control de compromisos (atrasos, responsables, etc.), Tipificacin de problemas, Flexibilidad ante los cambios (Las personas se focalizan en su trabajo) e Interaccin con otras fuentes de informacin.

Para el logro de efectividad, deben ser tenidos en cuenta los siguientes factores crticos de xito:

Tomar en cuenta que los seres humanos pueden pensar, Poner la informacin a su alcance, Dar las atribuciones apropiadas, Registro de cada evento y Utilizar informacin de gestin para lograr un mejoramiento continuo.

Desarrollaremos ahora un ejemplo de automatizacin del flujo de trabajo. Pensemos en las operaciones que debemos realizar si queremos comprar el libro de Ian Sommerville. Nos dicen que el libro puede adquirirse en la librera Cspide. La manera de adquirir el libro en esta librera, sin utilizar el sistema Workflow que posee la misma ser la siguiente: 1) 2) 3) 4) 5) 6) 7) 8) Conseguir informacin respecto de la direccin y telfono de alguna de las sucursales de Cspide. Llamar y consultar sobre la disponibilidad del libro Ingeniera de Software de Ian Sommerville. De no encontrarse disponible en esa sucursal, requerir el domicilio y telfono de una sucursal que cuente con el libro en su stock. Viajar hasta la sucursal. Requerir el libro a un vendedor. Abonar en caja con alguno de los medios de pago de que disponemos, y acepta la librera. Retirar el libro en empaque. Tarea cumplida.

Si utilizramos el sistema workflow de que dispone Cspide haramos lo siguiente: 1) Acceder al sitio web de Cspide: www.cuspide.com.ar 2) Buscar por ttulo o por autor el libro Ingeniera de Software de Ian Sommerville. 3) Agregar el libro al carro de compras. 4) Llenar el formulario con el domicilio de entrega y seleccionar la forma de pago. 5) Recibiremos el libro en nuestra casa. Ahora, que paso internamente en Cspide? Nuestro pedido, generado va web, quedo como pendiente de procesamiento para la oficina de ventas. La oficina de ventas procesa nuestro pedido, verifica la forma de pago y gener una orden de entrega

14

electrnica para el sector despacho. Al mismo tiempo, el sistema enva, automticamente, un correo electrnico al cliente notificndole que su pedido ha sido procesado, que ser despachado en determinada fecha y que lleva el siguiente nmero de pedido. Despacho, empaca el libro y lo remite por correo al domicilio del solicitante. Segn el tipo de pago, el pedido pasa al sector cuentas a cobrar. Una vez que llega el aviso de entrega y se confirma la acreditacin del pago del cliente, cuentas a cobrar marca el pedido como entregado. El pedido pasa a integrar las ventas realizadas va Internet. Observemos que toda la operatoria, dentro de Cspide, se realiza sin que nadie se mueva de su oficina dado que las transacciones viajan de un lugar a otro por la Intranet.

15

Bibliografa
Sistemas de Informacin para la Gestin Empresaria, Planeamiento, Tecnologa y Calidad de Alberto R. Lardent. Editorial Prentice Hall (2001). Estructura organizativa y sistemas de informacin: pp. 401 Workflow Management Coalition. Terminology & Glossary. Febrero de 1999 en: www.wfmc.org "Estrategia de integracin de aplicaciones Mediante un Motor de Flujo de Trabajo" de Antonio Alexis Moya Villegas, http://portal.inf.utfsm.cl/PTE2003/Libros/Libro3/AMoya.pdf Artculo introductorio a workflow en www.perfectxml.com/articles/xml/b2b.asp

16

Anlisis Funcional
Sistemas de Informacin I

Universidad Nacional de Lujn

Departamento de Ciencias Bsicas Divisin Estadsticas y Sistemas rea de Sistemas de Informacin

03
17

Introduccin
En las unidades previas hemos visto como representar el sistema bajo estudio. Por qu es necesario representar al sistema en estudio? Si el analista pude interactuar directamente con el sistema real, Por qu debo conformarme o tomarme el trabajo de representarlo?. Veamos: segn la Real Academia Espaola (RAE), representar es: Hacer presente algo con palabras o figuras que la imaginacin retiene. Nosotros, como analistas y luego como diseadores hacemos representaciones del sistema y decimos que intentamos representarlo lo ms fielmente posible. Pero, lamentablemente esto no es posible. Por qu?, pues simplemente porque la realidad es tan compleja que no es posible comprenderla cabalmente y mucho menos representarla. De hecho, cada representacin solo intenta reflejar un aspecto de la realidad. A esto se le llama abstraccin. Una abstraccin es (nuevamente al decir de la RAE) Separar por medio de una operacin intelectual las cualidades de un objeto para considerarlas aisladamente o para considerar el mismo objeto en su pura esencia o nocin. Y esto es EXACTAMENTE lo que tratamos de hacer. Como la realidad es muy compleja, tratamos de separar por medio de una operacin intelectual, aquellos aspectos que nos interesan ver en un determinado momento y obviamos por completo aquello que no nos interesa. Cuando estudiamos la construccin de los cursogramas, por ejemplo, nos enfocbamos solo en los aspectos que tienen que ver con el trnsito de los documentos o informacin por los sectores y las operaciones que se realizan con ellos y obviamos representar el color del documento, la personalidad de los usuarios participantes en las operaciones o el tamao de la oficina del gerente de ventas y otras muchas cosas que seguramente nos llamaron la atencin. De esta manera logramos mostrar, a travs de un conjunto pequeo de pginas el camino que sigue la informacin en la organizacin. Pero para poder comprender completamente (o lo ms completamente posible) al sistema, debemos observar otros aspectos de l. Desde el anlisis funcional se intentar representar las transformaciones que sufren los datos para convertirse en informacin. Para ello utilizaremos el enfoque estructurado de sistemas.

Enfoque estructurado
A mediados de los 70, el problema de especificar correctamente los requerimientos para un producto de software, tanto aquellos que tienen origen en el usuario como los que surgen del dominio de la aplicacin, comienza a ocupar seriamente a quienes se encontraban involucrados en el proceso de produccin de software. Emergen nuevos enfoques intentando ayudar a los analistas a producir relevamientos completos de los requerimientos. En 1975, Douglas T. Ross y Kenneth E. Schoman, Jr. publicaron uno de los primeros trabajos sobre tcnicas de anlisis y diseo estructurado SADT. Este fue un avance importante en las tcnicas para la definicin de requerimientos dado que se trataba de una de las primeras propuestas de un conjunto integrado de herramientas grficas de modelado para superar las deficiencias de las especificaciones en lenguaje natural, pero no fue el nico. A este trabajo le siguieron otros aportes muy valiosos tales como Structured Systems Analysis: Tools and Techniques de Chris Gane y Trish Sarson(1977), Essential systems analisys" de Stephen McMenamin y John Palmer (1982) y Modern Structured Analysis de Edward Yourdon (1989) entre otros ayudaron al enfoque estructurado a crecer y perfeccionarse.

El enfoque estructurado fue pensado como una solucin para el desafo que presentaba el desarrollo de sistemas grandes y complejos (en esa poca las computadoras empezaban a ser utilizadas en las grandes empresas y las aplicaciones de software se hacan ms complejas). Persigue dos objetivos: La divisin del sistema en componentes (para disminuir la complejidad por efectos de la descomposicin) y la construccin de un modelo de sistema.

18

Se concentra en especificar lo que se requiere que haga el sistema y no como hay que hacerlo. De esta forma el analista se enfoca en el modelo lgico (que es lo que se hace) dejando el modelo fsico (como se hace) para ms adelante. Para cumplir con su objetivo, el enfoque posee cuatro principios bsicos en los cuales se basa: 1. Enfoque Top-Down: Esto significa que el anlisis se hace pensando de lo general a lo particular, o de arriba hacia abajo. 2. Caja Negra / Caja Blanca: Acompaando al enfoque Top-Down, el principio de caja negra y caja blanca permite mejorar la abstraccin al ocuparse, con la caja negra, de estudiar lo que hace el sistema y, con la caja blanca, como opera para llegar a hacer lo que hace. 3. Tcnicas grficas: Para evitar la ambigedad del lenguaje natural en la descripcin del sistema. 4. Lenguaje Estructurado: Para aquellos casos donde las tcnicas grficas no alcancen. De esta manera (y como ejemplo) en un estudio de un sistema comenzaremos primero viendo al sistema como un todo y observaremos cuales son las relaciones existentes entre el sistema y su contexto (TopDown). El sistema en ese momento es una caja negra, es decir no se desea saber cmo funciona internamente sino solo las entradas que recibe y las salidas que produce. Luego se convierte la caja negra en caja blanca, para ver cuales entradas llegan a que subsistema y que salidas salen de cual subsistema. Una vez comprendido el sistema a ese grado de abstraccin, se puede descender de nivel para profundizar el conocimiento y tomar a cualquier subsistema como sistema y volvemos a hacer lo mismo. Nosotros en esta asignatura seguimos un modelo hibrido que nos ha dado muchas satisfacciones tanto en el aspecto profesional (pues lo usamos como metodologa de trabajo) como en el acadmico. El modelo que proponemos aqu, toma como punto de partida tanto a McMenamin y Palmer como a Yourdon. De este ltimo se mantiene la idea de realizar un modelo del sistema denominado modelo esencial conformado por un modelo ambiental y un modelo de comportamiento. De estos dos modelos, se propone un refinamiento que consiste en aplicar tcnicas que facilitan la lectura y ayudan a disminuir la ambigedad. Para una mejor comprensin del modelo, es importante que tengas en claro como se debe mirar al sistema en estudio, es decir, desde que ptica lo observaremos.

Sistemas de Respuestas Planeadas

Los sistemas de informacin que intentamos representar, se corresponden con la clase de sistemas "hechos por el hombre", cuya caracterstica ms importante es que estos son interactivos; esto es, sistemas que actan sobre cosas fuera de su control y stas, a su vez, actan sobre el sistema. Una casilla de ventas del subterrneo de Buenos Aires es un ejemplo de sistema interactivo. Los pasajeros quienes interactan con el sistema de venta de pasajes estn fuera del control del vendedor de pasajes. El pasajero puede decidir no viajar un da dado, o puede decidir viajar pero no comprar el pasaje. Los vendedores no tienen poder para forzar a los pasajeros a actuar de una forma en particular, sin embargo, si un pasajero decide comprar pasajes, ste debe interactuar con el vendedor para solicitarle un cierto nmero de pasajes y pagarle por stos. En respuesta, el vendedor acta de una manera que afecta al pasajero: Le da al pasajero los pasajes solicitados y eventualmente le da el vuelto. Observando este sistema interactivo, vemos que el pasajero que es parte de su entorno, acta sobre el sistema, y el sistema reacciona en consecuencia. La siguiente figura muestra esta interaccin.

19

Solicitud Pasajes Pasajero Vendedor de Pasajes

Pasajes Vuelto

Figura 1: Sistema de venta de pasajes Como en el sistema de venta de pasajes, los sistemas interactivos tienen la forma general mostrada en la siguiente figura.
Evento Entorno

Sistema Interactivo Respuesta

Figura 2: Sistema interactivo En la figura anterior se utilizaron los nombres genricos evento y respuesta para las interacciones entre el sistema y su entorno. Un evento es algn cambio en el entorno del sistema que tiene influencia para l, una respuesta es un conjunto de acciones realizadas por el sistema cada vez que el evento ocurre. Hasta ahora la discusin se ha concentrado en las causas y los efectos de la relacin entre los sistemas interactivos y su entorno. Ahora veremos cmo los sistemas pueden responder a los eventos. Dado un evento, un sistema puede dar una respuesta ad hoc o preparar una respuesta planeada con anterioridad. Cuando un sistema "inventa" una respuesta a un evento, luego de que el evento ha ocurrido, entonces su respuesta es ad hoc. Por ejemplo, supongamos que el pasajero se choque una plataforma que est enfrente de la cabina de venta de pasajes. Si el vendedor no est familiarizado con este tipo de accidentes, qu respuesta dar? La respuesta ser la que le salga en ese momento, dado que el vendedor no estaba preparado para responder a ese evento hasta que el evento ocurre. Una vez ocurrido, deber actuar en consecuencia con una respuesta no planificada. Cuando la respuesta del sistema para un evento ha sido determinada antes de que el evento ocurra, el sistema generar una respuesta planeada. Para nuestro ejemplo, supongamos que se entrena a los vendedores para actuar frente a las vctimas que tropiezan en las plataformas, entonces el vendedor actuar en consecuencia de su entrenamiento y de una forma prevista. Ahora, la respuesta al evento se conoce antes de que el evento ocurra. Los eventos a los cuales un sistema responde, pueden ser de dos tipos: Eventos externos o eventos temporales. Los eventos externos son producidos por entidades en el entorno (Entidades Externas), y los eventos temporales son producidos por el paso del tiempo. A su vez, los eventos externos pueden ser de dos tipos: De tipo flujo son los eventos que junto con el estimulo transportan informacin y los eventos de control que no transportan informacin adicional al estimulo. De tipo flujo es por ejemplo la compra de pasajes por parte del cliente, pues debe informar (junto al deseo de adquirir pasajes) la cantidad que desea y el importe con el que paga. Para ejemplificar un evento de control, podramos pensar en un timbre que la casilla de ventas posee para que el cliente avise su llegada, ante la posibilidad de que el vendedor se halla

20

retirado momentneamente de la ventanilla. Este evento slo da cuenta del timbre sonando pero no hay informacin adicional. Los eventos temporales por su parte, alcanzan la definicin de evento dado que un sistema no puede aumentar o disminuir su velocidad de trabajo para que el tiempo pase ms o menos rpido por lo tanto, para el sistema su llegada es eventual. Un sistema de respuestas planeadas, no acta como consecuencia de cualquier evento que ocurre en su entorno, sino de aquellos que son importantes para l, que son capaces de producir un estmulo al sistema. En el ejemplo del sistema de venta de pasajes, el vendedor no actuar de ningn modo ante el evento de que un pasajero se pase de estacin, o que un pasajero pase caminando delante de la cabina de venta y lo mire.

El Modelo Esencial
El modelo esencial del sistema es un modelo de lo que el sistema hace para cumplir con los requerimientos, desde el punto de vista lgico, esto es, sin preocuparnos de cmo lo hace4. El modelo esencial est compuesto por el modelo ambiental y el modelo de comportamiento. El modelo ambiental describe la relacin del sistema con el contexto, permitiendo identificar los flujos de entrada y salida de informacin, las entidades externas que producen y reciben estmulos del sistema y, principalmente, definir el lmite del sistema. Recuerda que una de las cosas ms complicadas en el anlisis de cualquier sistema es identificar y establecer claramente el lmite. Seguidamente se construye el modelo de comportamiento que guarda una relacin estricta con el modelo ambiental. Este modelo es una vista de caja blanca del sistema lo que permite mostrar de que manera el sistema logra cumplir con sus responsabilidades (siempre desde el punto de vista lgico). Observa como se ha aplicado aqu el concepto de Top-Down. Para ayudar a su concepcin, el modelo se construye pensando en que est siendo ejecutado por tecnologa perfecta, a la manera descripta por McMenamin y Palmer. McMenamin y Palmer en su libro Essential systems analisys" introducen el concepto de Tecnologa Perfecta para ayudarnos a separar la visin lgica del sistema (que es lo que realmente nos importa ahora) de la visin fsica del mismo. Ellos dicen que una tecnologa perfecta es aquella que no cuesta absolutamente nada, no ocupa espacio, no calienta el ambiente, hace cualquier tarea en un instante cero de tiempo, es capaz de recordar absolutamente cualquier cosa y nunca se queda sin espacio, etc.

El modelo ambiental
El modelo ambiental describe esencialmente la relacin entre el sistema y su contexto. Esta representacin pretende, fundamentalmente, describir que est dentro del lmite del sistema y que no. Utiliza para su representacin completa tres componentes: la descripcin de propiedades del sistema, un Diagrama de contexto y una Lista de eventos. Para una adecuada representacin, el modelo ambiental debe ser descripto desde la perspectiva externa del sistema (el analista est fuera del mismo), observando a ste como una caja negra, es decir sin ver su comportamiento. La visin de caja negra permite una mejor identificacin de las propiedades del sistema en funcin de las respuestas que ste es capaz de dar, o servicios que presta al ambiente. Descripcin de las propiedades del sistema La descripcin de las propiedades del sistema se conforma con las caractersticas del sistema que resultan necesarias para satisfacer los requerimientos. sta ayuda a determinar el alcance del sistema dado que se entiende que cualquier propiedad no incluida en esta descripcin no ser responsabilidad del sistema.
Nota aqu una diferencia sustancial de la visin con la que construiste cursogramas. All, el soporte de la informacin y la cantidad de copias era importante. Ac, eso no importa para nada.
4

21

Comenzamos aqu a ejemplificar usando un sistema que estimamos que todos conocen. Un video club. En el ejemplo que vamos a tratar, el sistema tendr las siguientes propiedades:

Llevar registro de socios Verificar sanciones vigentes en los socios Llevar registro de alquileres de pelculas Llevar registro de las devoluciones de pelculas Aplicar sanciones a los socios que devuelven pelculas despus del plazo Emitir diariamente un listado de morosos Aplicar sancin a los socios que tienen en su poder una pelcula ms de 30 das.

El diagrama de contexto El diagrama de contexto es una representacin grfica del intercambio de informacin entre el sistema y su contexto. Es un caso especial de Diagrama de Flujos de Datos (DFD) que representa a todo el sistema como una caja negra y a todas las entidades externas con las cuales el sistema se relaciona recibiendo sus estmulos a travs de flujos de datos y recibiendo las salidas del sistema. De esta forma, el sistema se representa como una burbuja que se identifica con el nombre del sistema. A su alrededor se distribuyen las entidades externas dibujadas como rectngulos que se identifican con el nombre del rol que juega la entidad externa al interactuar con el sistema y una letra en el borde superior derecho en minscula. El sistema y las entidades externas se conectan, entre s, utilizado arcos orientados que representan flujos de datos. Estos flujos de datos se identifican con un nombre que debe ser nico. Si el nombre se repite, significa que se trata de la misma informacin. La siguiente figura representa un diagrama de contexto. En esta figura, una persona juega dos roles diferentes como persona no socia y como socio. En su rol de Socio, una persona puede solicitar pelculas en alquiler.

Persona

Datos Personales Devolucin Pelculas Nmero de socio

Socio

Socio

Solicitud de Pelculas Rechazo

Sistema Video Club

Sancin

Morosos Administracin c

Figura 3: Diagrama de contexto de un video club. Si fuera necesario repetir, por cuestiones de claridad, a una entidad externa con el mismo rol se le coloca, en todos los casos, una lnea cruzando el vrtice inferior derecho. En la figura 1, la entidad externa Socio es un ejemplo de entidad externa que debi invocarse ms de una vez en el dibujo.

22

Lista de eventos La lista de eventos es una lista de doble entrada que enumera los estmulos que ocurren en el exterior y a los que el sistema responder con alguna actividad. Cada estmulo que el sistema recibe, se representa como una fila en la lista de eventos y se describe con las siguientes columnas: 1. 2. 3. 4. 5. 6. 7. Nmero de evento (#) Rol de Origen (Rol O) Evento Flujo de datos de entrada (FDE) Responsabilidad Flujo de datos de salida (FDS) Rol de Destino (Rol D)

La siguiente figura muestra un ejemplo de la lista de eventos que se corresponde con el diagrama de contexto anterior.

#
1

Rol O
Persona

Ev ento
Viene a asociarse

FDE
Datos Personales

Responsabilidad
Registrar Datos Personales Emitir Nmerode Socio

FDS
Nmero de socio Socio

Rol D

Socio

Solicita alquilarpelcula

Verif icar sanciones prev ias Solicitud dePelculas EmitirRechazo Registrar Alquiler Dev olucinPelculas Registrar Sancin
Verificar fecha de devolucin Emitir Sancin Registrar Devolucin

Rechazo

Socio

Socio

Dev uelv ePeliculas

Sancin

Socio

--------------

Lleg el f in del da

--------------

Emitir Listado de Morosos Registrar Sancin

Morosos

Administracin

Figura 4: Lista de eventos de un video club. Consideraciones generales Debe considerarse que los sistemas estn en reposo y solo salen de ese estado por la llegada de un estmulo, que se produce a partir de la ocurrencia de algn evento. Recordamos que los sistemas pueden recibir estmulos producto de tres tipos de eventos: Los eventos de tipo flujo, los eventos temporales y los eventos de control. Tanto los eventos de flujo como los eventos de control se producen en el ambiente y son reconocidos por el sistema por su llegada, mientras que los eventos temporales son reconocidos por el sistema dado el paso del tiempo. Los eventos de tipo flujo se asocian a un flujo de datos, es decir que, el estmulo llega al sistema mediante un conjunto de datos. En la figura 4, los eventos 1, 2 y 3 son eventos de este tipo. Los eventos temporales, ocurren dentro del sistema y estn asociados a la llegada de algn momento particular que es reconocible por el sistema. Se debe pensar que el sistema posee un reloj interno que es capaz de producir eventos. Los eventos temporales, al igual que los de control, no transportan informacin alguna mas all de la necesaria para identificar cual es el evento que se produjo. Por lo tanto el sistema debe ser capaz de cumplir con su responsabilidad con la informacin con la que dispone internamente. El evento 4 de la figura 2 es un evento de este tipo. Como se puede observar, los eventos temporales no tienen rol de origen (pues no son producidas por entidades externas) ni flujo de datos de entrada asociados a l (ya que no transportan informacin). Los eventos de control, por ltimo, son eventos que si bien se producen en el exterior, como los eventos temporales, no trasportan otra informacin ms que la que permita identificar al evento que se produjo. Son

23

los tpicos eventos que se disparan por la activacin de un sensor. Es difcil encontrar eventos de este tipo en sistemas transaccionales como el del ejemplo que estamos tratando. Este tipo de eventos son sumamente frecuentes en sistemas de tiempo real (pensemos en la mquina de caf). Finalidad de cada columna de la lista Nmero de evento: Es un nmero que identifica unvocamente al evento sin indicar orden de ejecucin alguno. No se prescribe ninguna tcnica de enumeracin de eventos, pero es comn comenzar de uno en adelante. Rol de origen: Es el rol que juega la entidad externa que produce el estmulo al cual el sistema debe responder. Los Roles de Origen deben ser exactamente los mismos que fueron identificados, como entidades externas, en el diagrama de contexto y son todos los que emiten flujos de datos hacia el sistema. Evento: Describe cual es el evento que ocurri. Los eventos se describen desde el punto de vista del ambiente, es decir, desde afuera, viendo hacia dentro. Esto permite una lectura secuencial como El Socio devuelve pelculas. Flujo de datos de entrada: Nombre del flujo de datos de entrada que produce el evento. Debe tener exactamente el mismo nombre con que fuera identificado en el diagrama de contexto. Responsabilidad: Lista de las responsabilidades del sistema ante la llegada del estmulo. Se debe tener en cuenta que como el modelo ambiental es una mirada de caja negra del sistema, todo lo que consignemos como responsabilidades del mismo debe poder percibirse desde el ambiente. Para eliminar la ambigedad de interpretacin en la lista de responsabilidades, solo se utilizarn los siguientes verbos: Registrar: Indica que el sistema registra la informacin que llega en un flujo de entrada. Esta es una responsabilidad evidentemente interna del sistema, con lo cual la nica forma en que se puede detectar, que esto ha ocurrido viendo al sistema como caja negra, es que el sistema evidencia en alguna salida que utiliz esa informacin para producirla. En la figura 4, el evento 1 registra los datos de los socios, esto puede deducirse dado que solo se acepta el pedido de pelculas por parte de un socio y es necesario conocer quienes juegan ese rol. En el evento 2, el sistema registra las pelculas alquiladas y en el evento tres las devoluciones. Estos registros se deducen de la salida del listado de morosos que se emite en el evento 4. Emitir: Indica que el sistema debe producir una salida. Esto se evidencia por la ocurrencia de algn flujo de datos de salida. Verificar: Esta responsabilidad indica que el sistema tiene la capacidad de controlar un flujo de datos de entrada contra informacin que ya dispone internamente. La nica forma de saber, en una visin de caja negra, que el sistema est controlando algo es que lo ponga en evidencia con alguna salida. En el ejemplo de la figura 2, la verificacin de la sancin que es responsabilidad del evento 2 se pone de manifiesto en la salida Emitir Rechazo. El sistema realiza el control del socio que solicita alquilar pelculas contra la informacin que posee de los socios que estn sancionados. Flujo de datos de salida: Si como responsabilidad del sistema ante la llegada de un estmulo, este debiera dar una o varias respuestas al exterior, aqu se nombran todos los flujos de datos que transportan la informacin que el sistema dar al exterior como respuesta. Rol de destino: El rol que juegan las entidades externas que reciben los flujos de datos de salida del sistema. Los flujos de datos de salida y los roles de destino son pares ordenados de manera que deben ser puestos de forma tal que se entienda quien recibe que flujo de datos. Tanto el flujo de datos de salida como el rol de destino va a estar presente solo si se identific un Emitir como responsabilidad del sistema, por otro lado, no puede haber un Emitir como responsabilidad del sistema si no hay un flujo de datos de salida y un rol de destino asociado.

24

Relaciones entre tcnicas Un modelo ambiental as descripto permite visualizar las relaciones del sistema con el contexto mostradas por el diagrama de contexto y la lista de eventos, las limitaciones del sistema impuestas por las propiedades del sistema, las relaciones entre las entradas y las salidas puestas de manifiesto en la lista de eventos, las responsabilidades que el sistema deber tener para cumplir con sus requerimientos, manifestados en la lista de propiedades y reveladas en la lista de eventos. Todo esto sin ver an al sistema como caja blanca para describir que actividades lleva a cabo para alcanzar sus propiedades. Si el sistema es modelado consistentemente, entonces todos los roles jugados por las entidades externas al interactuar con el sistema e identificados en el diagrama de contexto estarn en la lista de eventos. Los flujos de datos que emiten estas entidades externas tendrn el mismo nombre que figura en la columna Flujo de datos de entrada en la lista de eventos y estar relacionado con la entidad externa que lo emite. Todas las salidas que fueron identificadas en el diagrama de contexto, estarn en la columna Flujo de datos de salida de la lista de eventos e irn hacia la misma entidad externa que ya fue identificada. Por otra parte, estas salidas debern dar respuesta a todas las propiedades de la descripcin de propiedades del sistema y no habr otras propiedades emergentes del sistema que no fueron ya identificadas. La necesidad de la lista de eventos, es para suplir la incapacidad del diagrama de contexto para identificar que salidas se corresponden a estmulos producidos por el ambiente y cuales a eventos temporales. En este punto, es importante sealar que disponindose de la lista de eventos, el diagrama de contexto puede, directamente, obviarse o ser derivado, mediante herramientas automticas, desde la lista de eventos. Ahora que hemos avanzado con el sistema de ejemplo, observemos de nuevo la descripcin de las responsabilidades del sistema.
1. 2. 3. 4. 5. 6. 7.

Llevar registro de socios Verificar sanciones vigentes en los socios Llevar registro de alquileres de pelculas Llevar registro de las devoluciones de pelculas Aplicar sanciones a los socios que devuelven pelculas despus del plazo Emitir diariamente un listado de morosos Aplicar sancin a los socios que tienen en su poder una pelcula ms de 30 das.

Hay algunas propiedades que son fciles de detectar observando al sistema desde afuera como lo estamos haciendo en este momento, dado que se ponen de manifiesto por las salidas del mismo. Es el caso de las propiedades 5 y 6. Las otras propiedades se infieren mirando la relacin entre entradas y salidas. As, se que el sistema solo pide los datos del socio la primera vez que la persona se presenta por lo tanto debe llevar su registro. S que verifica sanciones porque cuando un socio pide una pelcula su pedido puede ser rechazado por el sistema con ese motivo, por lo tanto en algn momento debi haberlas aplicado. Hay dos momentos para aplicar sanciones, uno cuando el socio devuelve las pelculas luego de que pas el perodo de devolucin y otro cuando no las devuelve por ms de treinta das. Esta ltima responsabilidad es ms difcil de detectar ya que, como vimos luego, es responsabilidad de un evento temporal con lo cual no posee entradas. La nica forma de darnos cuenta de ello es ver que un socio que no devolvi una pelcula, al solicitar otra es sancionado (siendo que su sancin no pudo provenir de una devolucin anterior).

El modelo de comportamiento
Una vez modelado el ambiente, nos debemos abocar a analizar cmo hace el sistema para cumplir con sus responsabilidades. El modelo de comportamiento, muestra al sistema como una caja blanca, poniendo en evidencia al conjunto de actividades que debe realizar para poder manifestar sus propiedades. Desde la perspectiva del usuario, diramos las actividades necesarias para cumplir con sus responsabilidades.

25

El modelo que vamos a realizar sigue siendo parte de lo que denominamos modelo esencial y como en el modelo de comportamiento es donde solemos ms frecuentemente olvidarnos de esto, veremos ahora a que llamamos exactamente modelo esencial o esencia del sistema. La esencia del sistema La esencia de un sistema se compone de actividades esenciales y la memoria esencial. Las actividades esenciales son todas aquellas tareas que el sistema debera realizar si se implementara el sistema con tecnologa perfecta. Si se piensa en las funciones de un sistema de software tpico, se ver que unas pocas de stas son esenciales. Por ejemplo, la mayora de los sistemas realizan chequeos de auditora para asegurarse de que no produzca salidas incorrectas. Este chequeo sera innecesario en una tecnologa perfecta, dado que el sistema nunca cometera errores. La memoria esencial est compuesta de todos los datos que el sistema debera tener que recordar si fueran producidos por actividades esenciales. En otras palabras, la memoria esencial contiene todos los datos que un sistema tecnolgicamente perfecto debera tener que recordar. Para continuar con el ejemplo de las actividades de auditora, muchos sistemas mantienen archivos de seguimiento de auditora (el registro de que operaciones fueron realizadas con el sistema y por que usuario) y otros datos extraos que un sistema infalible no necesitara. Se distinguen dos tipos de actividades esenciales: Las actividades fundamentales y las actividades de custodia. Actividades Fundamentales Una actividad esencial es tambin una actividad fundamental si ayuda a justificar la existencia del sistema. En otras palabras, una actividad fundamental realiza tareas que son parte del propsito para el cual el sistema fue construido. Considere un sistema que paga horas trabajadas como se muestra en la figura 5.
Horas Trabajadas Nombre + Direccin Pago de Horas Trabajadas

Sueldos

Deduccuiones

Cheque

Figura 5: Actividades fundamentales del sistema de pagos

Cada semana, los empleados le dicen al sistema cuantas horas han trabajado en la semana y el sistema produce el cheque. Ahora suponte que debes comprar un paquete de software que realice esta funcin. Entonces entrevistas a varios representantes de venta de software para comparar las empresas y la lista de caractersticas de sus productos. Qu caractersticas influirn en tu decisin? Estars influenciado por los productos que mantienen un seguimiento de los empleados, sus sueldos, sus impuestos a las ganancias y otras deducciones? Tal vez, pero ciertamente no estars satisfecho, porque las personas de venta no te prometen la principal caracterstica que ests buscando: la generacin de cheques. Para decirlo de otra manera, la razn de que este sistema exista es pagar las horas trabajadas. El seguimiento de empleados, sueldos y deducciones a realizar para pagar las horas trabajadas no, porque son funciones auxiliares de la actividad principal y es obvio que el sistema necesita hacerlas puesto que si no, no cumplira con su responsabilidad correctamente. sta es informacin necesaria para su funcionamiento. De esta forma la actividad fundamental para este sistema es la produccin del cheque para pagar las horas trabajadas.

26

Cada actividad fundamental necesita de dos partes: La respuesta planeada y la definicin del estimulo de la actividad. La respuesta planeada es el conjunto de acciones llevadas a cabo por el sistema para realizar una actividad. Como en todo sistema de respuesta planeada, la respuesta es iniciada por un evento temporal o externo. La actividad comienza cuando se reconoce un estmulo enviado por un evento externo en cualquier momento que el evento ocurra. En el sistema de pago de horas trabajadas, el estmulo es la tarjeta suministrada por el empleado y la respuesta es la generacin del cheque. La memoria esencial Para producir una respuesta apropiada, la actividad fundamental debe tener a su disposicin toda la informacin necesaria. Por ejemplo, la actividad fundamental "Pagar horas trabajadas", necesita la identidad del empleado, el sueldo que percibe, el da en que se paga, las deducciones a realizar y la cantidad de horas trabajadas en el perodo de pago. Algunos de estos datos vienen del entorno mientras que el resto viene de la memoria esencial. Cuando ocurre un evento, la actividad fundamental habitualmente obtiene algunos datos desde el entorno del sistema para dar la respuesta apropiada. En nuestro ejemplo la tarjeta identifica al empleado y las horas trabajadas durante el perodo de pago. Estas piezas de informacin son parte del estimulo, y vienen junto al evento desde su origen, ya que se trata de un evento de tipo flujo. Las actividades esenciales a menudo tambin requieren informacin de otras fuentes: necesita informacin producida por ella misma o por alguna otra actividad esencial en el mismo sistema en respuesta a algn evento anterior. La actividad Pagar Horas Trabajadas puede necesitar saber el monto total pagado a un empleado en lo que va del ao o en los ltimos seis meses (para descontar ganancias o pagar aguinaldos) y as calcular correctamente el importe a abonar. Muchos sistemas recuerdan ese tipo de informacin. El total de todos los elementos de datos recordados por el sistema y requeridas por sus actividades fundamentales se denomina memoria esencial. El sistema debe recordar estos datos debido a las imperfecciones del entorno. Uno podra pensar "Si tengo una tecnologa perfecta, porqu el sistema debera recordar los sueldos de los empleados? Por qu no se lo preguntamos al empleado? Sencillamente porque el concepto de tecnologa perfecta no se aplica al entorno. La memoria esencial tambin incluye declaraciones de como las actividades fundamentales acceden a los datos almacenados. Por ejemplo, la actividad de pagar debera poder ver los sueldos de un empleado identificado, digamos, por nmero de documento. La figura 6 muestra como se representa a la memoria esencial de la actividad de Pagar Horas Trabajadas. Las dos lneas paralelas indican un almacn de datos, cada almacn representa un sub conjunto de la memoria esencial5. El nombre de cada almacn de datos va a aparecer luego como una entrada en el diccionario de datos y tambin la definicin de los elementos de datos almacenados. El diccionario de datos es otro de los elementos del modelo de comportamiento que veremos luego. Para que una memoria esencial complete su propsito, se debera poder responder a dos preguntas: Cmo hace el sistema para adquirir los datos recordados? Cmo hace el sistema para asegurarse de que los datos estn lo suficientemente actualizado para servir a las actividades fundamentales?

Estas tareas son llevadas a cavo por el otro tipo de actividades esenciales: Las actividades de custodia.

En nuestro modelo, nosotros llamamos memoria esencial a los almacenes de datos individuales. Recurdalo para no confundirte.

27

N om br e

D ire cc i n

Horas Trabajadas

Sueldos

Pagar Horas Trabajadas

Figura 6: Memoria esencial del sistema de pago.

Actividades de custodia Las actividades de custodia establecen y mantienen la memoria esencial del sistema, adquiriendo y almacenando la informacin necesaria para las actividades fundamentales. Estas tambin actualizan la informacin almacenada para que se mantenga correcta. La esencia del sistema de pago debe incluir actividades para hacer el seguimiento de los cambios en el conjunto de empleados, sus sueldos y sus deducciones. Estas actividades de custodia se muestran en la figura 7. Al igual que las actividades fundamentales, las actividades de custodia consisten de una o ms respuestas planeadas y la definicin de un estmulo. En el caso de las actividades de custodia, las respuestas consisten de una actualizacin a la memoria esencial del sistema en lugar de enviar una salida al mundo exterior.
Aumento Manteni_ miento de Sueldos

uc ed D

ne io

Cheque

Sueldos

Horas Trabajadas
Manteni_ miento de Empleados

Nombre + Direccion

Ingresos

Despidos

Pagar Horas Trabajadas

Actualizacin de Deduciones

Manteni_ miento de deducciones

Deducciones

Cheque

Figura 7: Actividades de custodia del sistema de pagos

Combinacin de actividades esenciales. Muchas actividades esenciales fundamentales lo son tambin de custodia, esto es, mientras realizan respuestas planeadas fundamentales, tambin actualizan la memoria esencial. En el ejemplo que hemos seguido las actividades eran fundamentales o de custodia, pero en un sistema real, rara vez las actividades fundamentales no realizan actualizaciones de la memoria esencial. Normalmente ellas deben recordar que es lo que hicieron para luego usar esa informacin ellas mismas o para uso de otras actividades fundamentales. Igual que las actividades fundamentales, las actividades de custodia, pueden combinar la actualizacin de los datos y adems dar alguna respuesta al mundo exterior.

28

Entonces el modelo de comportamiento se integra con dos componentes: El diagrama de flujo de datos particionado por eventos y un diccionario de datos. Ya que hemos estudiado los componentes del modelo esencial, sigamos ahora viendo formalmente los elementos del modelo de comportamiento.

Diagrama de flujo de datos particionado por eventos (DFD-PE)

Un DFD-PE es una tcnica grfica compuesta por cuatro elementos: Entidades externas, Actividades Fundamentales, Memoria Esencial y Flujos de datos. Entidades externas Son los elementos del contexto que se relacionan con el sistema, producindole estmulos o recibiendo las salidas. Debern ser los mismos que fueron identificados en la lista de eventos como roles de origen o destino. Flujos de datos Igual que en el diagrama de contexto, los flujos de datos son arcos orientados. Dentro del DFD-PE hay dos tipos de flujos de datos, los Flujos de Datos Externos que son los que comunican al sistema con el contexto, y por lo tanto requieren de interfaces para comunicar al sistema con la entidad externa, los cuales sern identificados con un nombre y los Flujos de Datos Internos que no llevan identificacin y son los que conectan a las actividades esenciales con las memorias esenciales. Memoria esencial La memoria esencial es la encargada de recordar toda la informacin que es necesaria para que las actividades esenciales cumplan con su objetivo. Como el sistema est siendo ejecutado por tecnologa perfecta, no se impone sobre ella ninguna limitacin, pero se debe tener en cuenta que por tratarse de un modelo esencial, el sistema solo recordar lo que sea indispensable y nada ms que eso. Actividades Esenciales Las actividades esenciales son las encargadas de llevar a cabo las funciones del sistema para cumplir con las propiedades que son percibidas desde el exterior. Estos elementos son los nicos que realizan funciones en el sistema. Hay dos tipos de actividades esenciales: Las fundamentales y las de custodia. Las actividades esenciales fundamentales son las encargadas de cumplir las actividades necesarias para que el sistema pueda manifestar sus propiedades y por lo tanto son las que proveen las salidas del sistema. Las actividades esenciales de custodia son las que proveen las interfases necesarias para mantener actualizada la memoria esencial. La figura 8 muestra un ejemplo de un DFD-PE que representa al sistema del video club.

Persona

Datos Personales

Dev olucin Pelculas

Socio

1 Nmero de socio

Asociar Clientes

Atender Devoluciones
Socios

Sancin

Socio

b Solicitud de Pelculas 2

Alquileres Pelculas Administracin 4T Morosos c

Alquilar Pelculas

Rechazo Socios

Emitir Morosos

29

Figura 8: DFD PE de un video club. Reglas generales de construccin En el diagrama habr una Actividad Fundamental por cada evento identificado en la lista de eventos. Las actividades son identificadas usando el mismo nmero que identifica al evento en la lista y un nombre que describir la responsabilidad que le cabe a esa actividad. Si el evento que estimula a la actividad es temporal, se coloca una T al lado del nmero. Los flujos de datos externos se identifican con un nombre que ser el mismo nombre que se us en el diagrama de contexto y en la lista de eventos. Para los flujos de datos internos se sigue el siguiente razonamiento: Un flujo de datos interno que va desde una actividad a una memoria indica que la actividad Registra algo en la memoria. Un flujo de datos que va desde la memoria a la actividad indica que la actividad est consultando algo recordado previamente. Si el flujo de datos posee flechas en ambos sentidos indica que la actividad registra y consulta. Las memorias esenciales, se identifican con un nombre que describe a la informacin que recuerda. Como es un sistema de tecnologa perfecta, no hace falta minimizar redundancia ni evitar atributos nulos de manera que el contenido de las memorias solo se distribuye de acuerdo al criterio del constructor siguiendo una asociacin de ideas. Si dentro del diagrama y por razones de claridad es necesario repetir una memoria esencial, la misma se identifica con el mismo nombre y se le coloca doble lnea en todos los casos en que aparezca. La lista de eventos es la base desde la cual deriva la construccin del DFD-PE. Si en la lista de eventos hemos identificado que como responsabilidad ante una solicitud de alquiler de pelculas el sistema debe:

Verificar Sanciones Previas: debo pensar donde se ubicarn las sanciones. En el ejemplo de la figura 8, las sanciones estn ubicadas en la memoria Socios y esto no indica que solo se recordar la ltima sancin. Emitir Rechazo: debe haber un flujo de datos externo que vaya desde esta actividad hacia el socio emitiendo el FDS Rechazo. Registrar Alquiler: se hace por un lado sobre la memoria Pelculas indicando que la pelcula alquilada ya no est disponible y sobre la memoria alquileres donde se recordar las fechas que sern necesarias para obtener el informe de morosos del evento 4. Obviamente solo se registrar el alquiler si el socio no tena sanciones previas pero esto solo se ve en la descripcin de la actividad en el diccionario de datos.

Una vez concluida la derivacin del diagrama, se ve que la memoria Socios es alimentada por la actividad Asociar Clientes y actualizada por Emitir Morosos, la memoria Alquileres es mantenida por Alquilar Pelculas y por Atender Devoluciones y la memoria Pelculas es actualizada tambin por estas dos actividades pero no hay ninguna actividad que coloque en esa memoria las pelculas nuevas. Por lo tanto hace falta una actividad de custodia que mantenga dicha memoria esencial y que no fue descubierta durante el modelado del ambiente dado que no fue reconocida como una propiedad o servicio que brinda el sistema. Por lo tanto, se deben actualizar las tres tcnicas: Diagrama de contexto, lista de eventos y DFD-PE, para incorporar la nueva informacin descubierta. Las figuras 9 A, B y C muestran estos cambios.

30

A
Proveedores d Nuevas Peliculas

Sistema Video Club

B
#
... 5 ... Proveedores

Rol O
...

Evento
...

FDE
...

Responsabilidad
...

FDS
...

Rol D

Hay novedades de pelculas

Nuevas Peliculas

Registrar Peliculas

C
5 Proveedores d Nuevas Peliculas

Mto. de Peliculas

Pelculas

Figura 9: A - Nuevo Diagrama de contexto, B-Nuevo evento en la lista de eventos y C-Nueva actividad en el DFD-PE. Diccionario de datos El diccionario de datos es un listado organizado de todos los datos del sistema, con definiciones precisas para que tanto el usuario como el analista tengan un entendimiento comn de toda la informacin y actividades que se encuentran en el alcance del sistema. Los elementos que son descriptos en el diccionario son: Las entidades externas o roles, los flujos de datos externos, las estructuras de datos incluidas en los flujos de datos, en las memorias esenciales o en otras estructuras de datos de orden superior, los datos elementales que estn en las estructuras de datos, las actividades esenciales y las memorias esenciales. La definicin de estos elementos en el diccionario de datos ayuda a tener una interpretacin precisa y completa del diagrama. Como no es una tcnica grfica, es necesario ser cauteloso a la hora de describir los elementos para no introducir ambigedad. Roles externos Los roles externos se especifican poniendo en el diccionario su nombre como clave y su descripcin. Las descripciones deben ayudar a identificar que rol juega la entidad externa al interactuar con el sistema.
Socio (RL) Descripcin : Persona que ya ha sido registrado por el sistema como socio.

Flujos de Datos Externos Los flujos de datos se especifican utilizando su nombre como clave en el diccionario, una descripcin del flujo de datos, el origen o lugar desde donde parte, el destino o lugar donde se dirige y el nombre de la estructura de datos que contiene.
Solicitud de Pelculas (FD) Descripcin : Informacin proporcionada por un socio para solicitar el alquiler de una pelcula. Origen : Socios (RL) Destino : Alquilar Pelculas (AC) Estructura de Datos que contiene : Alquiler_Pelicula (ED)

Memorias Esenciales Las memorias esenciales se especifican en el diccionario de datos utilizando su nombre como clave, una descripcin de la memoria y el nombre de la estructura de datos que contiene.
Socios (MEM) Descripcin : Recuerda todos los socios existentes y sus sanciones Estructura de Datos que contiene : ED_Socios (ED)

31

Estructuras de Datos Una estructura de datos es una coleccin de datos que se agrupan para formar una idea concreta. Las estructuras de datos se encuentran dentro de los flujos de datos, dentro de las memorias esenciales y dentro de otras estructuras de datos de mayor nivel.
Alquiler_Pelicula (ED) Descripcin : Informacin proporcionada por un socio al solicitar el alquiler de una pelcula. Contenido : Nmero de Socio (DE) Cdigo de Pelcula (DE) * {1,10}

Datos Elementales Un dato elemental es una unidad indivisible y dentro del diccionario se especifica utilizando su nombre como clave, una descripcin, un alias si es que el mismo dato aparece en otra estructura de datos con otro nombre, su tipo de dato, su longitud y opcionalmente el rango de valores posibles.
Nmero de Socio (DE) Descripcin : identificador nico de un socio. Tipo de Dato : Numrico Longitud : 8 Rango : 0..99999999

Actividades Esenciales Las actividades esenciales se especifican utilizando el nombre de la actividad como clave, una descripcin que defina globalmente el objetivo de la actividad, los pre-requisitos o cuestiones que debern estar dadas antes que la actividad lleve a cabo su responsabilidad, el detalle que se define, utilizando lenguaje estructurado de alto nivel, su responsabilidad y los post-requisitos o estados que dej establecida la actividad luego que llev a cabo su responsabilidad.
Alquilar Pelculas (AC) Descripcin : Alquila pelculas a socios. Pre-Requisitos : La persona solicitante debe ser socia. Detalle : Si No est sancionado o la fecha de caducidad de la ltima sancin en Socios (MEM) < Fecha de alquiler entonces Mientras haya cdigo de pelculas en Solicitud de Pelculas (FD) Si Pelcula est disponible en Pelculas (MEM) Registrar Alquiler Fin Si Fin Mientras Sino Emitir Rechazo Fin Si Post-Requisitos : Se registr el alquiler Se emiti rechazo

32

Bibliografa y Referencias
Ross D.T, Schoman K.E. Jr.; Structured Analysis for Requirements Definition; IEEE Transactions on Software Engineering; Vol. SE-3, Nro 1 (Enero 1977) Yourdon E, Constantine L.L; Structured Design: Fundamentals of a Dscipline of Computer Program and System Design; 2nd ed. Yourdon Press; 1978 Gane C, Sarson T. ; Structured Systems Analysis: Tools and Techniques. Improved System Techniques; 1977. DeMarco T.; Structured Analysis and System Specification; Yourdon Press; 1978 Weingberg G.M.; An Introduction to General Systems Thinking; Yourdon Press; 1978 McMenamin S.M., Palmer J.F; Essential Systems Analysis; Yourdon Press; 1984 Yourdon E.; Modern Structured Analysis; Prentice Hall; 1989 Panessi W., Oloriz M.G., Ortiz C.; Diagrama de Estructuras como Mapa del Sistema; WICC; 2005

33

Factibilidad
Sistemas de Informacin I

Universidad Nacional de Lujn

Departamento de Ciencias Bsicas Divisin Estadsticas y Sistemas rea de Sistemas de Informacin

04
34

Introduccin
Para todos los sistemas nuevos, el proceso de ingeniera de software comienza con un estudio de factibilidad. Sin embargo, sin relevar cierta informacin no es posible realizar el estudio de factibilidad. Por otra parte, el momento depende, en gran medida, de la experiencia del equipo de desarrollo. La informacin de entrada es una descripcin resumida del sistema y de cmo se utilizar dentro de la organizacin. El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la ingeniera de requerimientos y el proceso de desarrollo del sistema. Un estudio de factibilidad es un estudio corto y orientado a resolver varias preguntas: El sistema contribuye a los objetivos generales de la organizacin? El sistema se puede implementar usando la tecnologa actual y con las restricciones de costo y tiempo? El sistema puede integrarse con otros que existen en la organizacin? Llevar a cabo un estudio de factibilidad comprende la evaluacin y recoleccin de informacin y la redaccin de informes. Un proyecto tendr beneficios si el equipo de desarrollo logra recolectar y satisfacer los requerimientos de sistemas. Pero no siempre es posible recolectar los requerimientos y cumplirlos. Hay varias razones por las cuales no es posible hacerlo. El estudio de factibilidad tiene como propsito evaluar la posibilidad de que un proyecto tenga xito tan pronto como sea posible. Esta evaluacin estudia la factibilidad de las dos partes relacionadas. Por un lado, la factibilidad de que el equipo de desarrollo lleve a cabo el estudio satisfactoriamente. Por otro lado si el sistema propuesto ser, luego de ser implantado en la organizacin, utilizado por los participantes y si satisfar las necesidades organizacionales. Descompondremos este estudio en cinco partes que denominaremos Factibilidad del equipo de desarrollo (o del analista), Factibilidad Operacional, Factibilidad Tcnica, Factibilidad Econmica y Factibilidad Legal. Todos las partes del estudio son crticas y poseen la misma importancia. Cualquiera de las partes que falle, pondr en peligro el xito del proyecto.

Factibilidad
Factibilidad del equipo de desarrollo
El equipo de desarrollo, no siempre tendr la posibilidad o capacidad para desarrollar cualquier proyecto que se le proponga (recordemos el caso del Sistema de Ambulancias de Londres, presentado en el captulo 1). Hay que tener en cuenta que el xito profesional est fuertemente ligado con el xito de los proyectos que se lleven a cabo, de manera que todos los proyectos debern ser importantes una vez asumido el compromiso, por ms que se hayan dado cuenta tarde que se equivocaron en el negocio y piensen que estn perdiendo dinero con ese proyecto. Un fracaso en el desarrollo de un proyecto es muy costoso de recuperar por la evidente prdida de prestigio. Las causas que pueden hacer fallar la factibilidad de los desarrolladores son: 1 - Tiempo: la falta de tiempo del equipo conjugada con la urgencia con la cual se necesite la solucin 2 - Inexperiencia en el dominio: la inexperiencia de los desarrolladores en el dominio de la aplicacin conjugado con la gravedad de sus posibles fallas. 3 - Inexperiencia en las herramientas: la inexperiencia de los desarrolladores en las herramientas necesarias para llevar a cabo el proyecto. 4 - Tamao: el tamao del proyecto ligado al tamao del equipo necesario para el desarrollo.

35

Factibilidad operacional:
La factibilidad operacional mide el grado de aceptacin por parte de los usuarios que tendr el sistema luego de ser instalado y la habilidad para utilizarlo. Tambin mide el grado de compromiso de los usuarios durante el anlisis, con el proyecto. Esta parte del estudio depende, en gran medida, de la habilidad que posea el equipo de desarrollo de hacer, que los usuarios, se sientan partcipes del proyecto de sistema. Es el usuario quien conoce el sistema actual y de l es de quien se deben obtener los requerimientos. Si los usuarios no estn dispuestos a darnos la informacin de cmo se realizan las actividades o qu se pretende de ellas, ser muy difcil que el nuevo sistema cubra las expectativas. Para establecer la factibilidad operativa hay que tener en cuenta: Apoyo de la administracin: es fundamental para el proyecto contar con el apoyo de la administracin de la organizacin. Esta es quin nos abrir las puertas de los sectores que se debern mantener bajo estudio y quien nos proveer de la informacin necesaria acerca de las actividades que se llevan a cabo en cada uno de ellos. Apoyo de los usuarios: los usuarios por su parte, son los que realizan las actividades y las seguirn realizando sobre el sistema nuevo. Es la fuente de informacin fidedigna de la forma exacta en que se realizan las actividades de la organizacin. Aceptacin de los mtodos actuales: el grado de aceptacin que tengan los usuarios sobre la forma actual de realizar las actividades es muy importante para determinar el grado de rechazo del nuevo proyecto. Hay que pensar que el trmino cambio proviene de crisis, si los usuarios estn conformes con la metodologa actual les ser muy difcil aceptar el cambio de metodologa. Equilibrio de los beneficios: cuando un rea se favorece ms que otra con los beneficios obtenidos por el nuevo sistema, se suele producir un fuerte rechazo de los que quedan menos favorecidos con el proyecto. Habilidad de los usuarios: hay muchos usuarios que son reacios a utilizar herramientas nuevas. Tambin, y en el otro extremo hay usuarios que tienen mucho inters en utilizarlas, pero sus habilidades o capacidades no les permiten hacerlo debido a la complejidad que su manejo presenta. De esta manera se deber evaluar que tan factible ser el uso del nuevo sistema por los usuarios actuales o el reemplazo de stos, la predisposicin para aprender a utilizarlo y la disponibilidad del tiempo necesario para su aprendizaje. Finalmente, cuando los usuarios se sienten partcipes del proyecto y en cierto grado los autores de ste, estarn ms predispuestos a ayudarnos en la obtencin de los requerimientos de sistema y apoyarn la implementacin del sistema nuevo.

Factibilidad tcnica:
Los aspectos tcnicos que intervienen en el estudio de factibilidad son: Disponibilidad de la tecnologa necesaria: muchas veces las soluciones que se pretenden no son tecnolgicamente factibles debido a la no existencia en el mercado de la tecnologa necesaria. Costo de la tecnologa necesaria: a veces, si bien la tecnologa necesaria existe en el mercado su costo es demasiado alto a la luz de los beneficios esperados. Respuestas adecuadas: se deber estudiar si las respuestas que el nuevo sistema dar estn acordes con lo que se espera de l. Crecimiento: la escalabilidad (posibilidad de ampliacin) del equipamiento necesarios para el desarrollo del proyecto debe permitir el crecimiento del sistema. Muchas veces, la cantidad de transacciones realizadas requieren de un equipamiento tal, que pueda ser incorporado paulatinamente a medida que el tiempo

36

transcurra. De esta manera se debe garantizar la compatibilidad del equipamiento con los nuevos desarrollos tecnolgicos o su reemplazo total a un costo razonable. Exactitud: el sistema debe exhibir la exactitud que se requiera en las mediciones, controles y en la presentacin de la informacin resultante. Si esto no ocurre se perder la confianza en el sistema. Confiabilidad: el sistema debe ser confiable, con un mnimo de tasa de fallas para que el usuario pueda depender de l. Facilidad: el sistema debe ser fcil de operar para que el tiempo necesario en dominar su operacin sea acorde con el beneficio que se obtiene de su utilizacin. Seguridad: el sistema debe ser seguro, tanto en el resguardo de la informacin, como en el acceso a la misma de personas no autorizadas.

Factibilidad econmica y financiera:

El costo de un sistema operacional y tcnicamente factible, debe estar adems acorde con los beneficios obtenidos por su implementacin. De esta manera, los beneficios obtenidos deben exceder o igualar al costo de su implementacin en un tiempo razonable. Durante el estudio de factibilidad se deber estimar: El costo del sistema actual: el costo asociado a la forma en que se desarrollan las actividades actualmente, estimando adems, el costo asociado a los errores que se cometen y al impacto de la prdida de productividad por las demoras de procesamiento. El costo del estudio completo del sistema: el costo asociado para llevar a cabo el estudio completo del sistema actual. El costo del hardware y software propuesto: el valor del equipamiento a instalar para que el nuevo sistema deba operar y el software a desarrollar o comprar con el costo de mantenimiento asociado. Los beneficios en el aumento de productividad: los beneficios que el nuevo sistema tenga relacionado con el aumento de productividad en algunas actividades. Los beneficios en la disminucin de errores: los beneficios que el nuevo sistema genere relacionado con la disminucin de errores en el procesamiento y en la entrega de informacin. Luego de haber estimado todo esto, se debern cruzar los costos con los beneficios para estimar si el proyecto es econmica y financieramente factible.

Factibilidad legal:
El sistema que se requiere deber desarrollarse dentro del marco legal que se encuentre vigente en el pas o regin en el que el mismo va a operar. Se Determina cualquier infraccin, violacin o responsabilidad legal en que se podra incurrir por el desarrollo del sistema. Algunos autores consideran esta factibilidad en forma conjunta con la factibilidad tcnica. En este estudio se deben considerar, genricamente, aquellas leyes que regulan la privacidad de los datos personales considerados sensibles (Ley de Habeas Data) o aquellas que determinen la seguridad respecto del control de acceso a bases de datos que contienen datos sensibles.

Resumen
Para que un proyecto pueda ser llevado a cabo con xito, debe ser factible. Para determinar si el proyecto es factible, debe pasar y aprobar todas las pruebas que hemos sealado. No son suficiente tres de cinco, mucho menos dos de cinco.

37

Algunas de las pruebas podrn ser verificadas inmediatamente, mientras que para otras, ser necesario que se haya hecho parte del anlisis. Lo importante es determinar la factibilidad del proyecto lo antes posible. Hasta que no se est seguro de que el proyecto es factible el trabajo no est garantizado y se puede estar perdiendo tiempo y dinero.

Bibliografa
Anlisis y Diseo de Sistemas de Informacin de James A. Senn. Editorial Mc Graw Hill (1994) Factibilidad: pp 89 91. Ingeniera de Software de Ian Sommerville. Editorial Addison Wesley (2002). Estudios de Factibilidad: pp 123

38

Requerimientos
Sistemas de Informacin I

Universidad Nacional de Lujn

Departamento de Ciencias Bsicas Divisin Estadsticas y Sistemas rea de Sistemas de Informacin

05
39

Introduccin

Ya habamos determinado que el anlisis es el proceso de clasificacin e interpretacin de los hechos, diagnstico del problema y empleo de la informacin para recomendar mejoras al sistema. El proceso de determinacin de los hechos, posee la finalidad bsica y esencial de comprender los procesos del cliente, las necesidades de informacin del sistema actual y los problemas asociados a ste. La palabra Requerimiento, fue incorporada al vocablo castellano con un nuevo significado, para nuestra rea de conocimiento, a partir de la palabra anglosajona Requirement, no es que la palabra no existiese en castellano, sino que estaba reservada para otros contextos con significados diferentes. As, para estudiar su significado, debemos ver qu significa requirement. Websters Ninth New Collegiate Dictionary define requirement como: Algo requerido; algo esperado o necesitado. Por otra parte el estndar 729 de la IEEE6 lo define como: (1) una condicin o capacidad necesitada por un usuario para resolver un problema o lograr un objetivo; (2) una condicin o capacidad que debe ser alcanzada o poseda por un sistema ... para satisfacer un contrato, estndar, especificacin, o algn otro documento formalmente impuesto. Estas definiciones son muy generales, por consiguiente, no dejan demasiado claro que cosas exactamente podran encuadrarse dentro de un requerimiento y que cosas no.

Qu es la determinacin de requerimientos?
La determinacin de requerimientos es el estudio de un sistema para conocer cmo trabaja y cules son las necesidades de la organizacin que no son satisfechas por el sistema actual. El resultado de la determinacin de requerimientos es una evaluacin de los procesos de la organizacin para determinar si es necesario o posible realizar ajustes. Estos ajustes, se determinarn en el diagnstico y pueden dar como resultado, diferentes soluciones que a su vez pueden o no ser implementadas con computadoras. Un requerimiento es una caracterstica que el sistema debe poseer para lograr un objetivo, y por lo tanto, dicha caracterstica debe ser incluida en el nuevo sistema. Desde este punto de vista, la determinacin de requerimientos relaciona al estudio del sistema con la descripcin de sus caractersticas. Como el analista no trabaja dentro de la organizacin del cliente como gerente, o empleado de ventas, produccin, etc. no tiene el mismo conocimiento que stos sobre las distintas actividades que se llevan a cabo. Por consiguiente, lo que el analista debe hacer como primera medida, es conducir un estudio para conocer y entender las actividades del cliente. Ciertas actividades y sus requisitos son comunes a todas las organizaciones que realizan la misma actividad. Como ejemplo, consideremos que toda empresa que realice facturas a sus clientes, deber realizar esta actividad de acuerdo con las normas establecidas por los organismos nacionales de control (AFIP en nuestro caso). Este tipo de requerimientos se dice que se extraen del Dominio de Aplicacin o Dominio del problema. Otras actividades y requisitos son propios de la organizacin. Estos requerimientos a su vez pueden ser comunes a varios sectores de la organizacin o ser de una persona en particular. Ejemplo de Requerimiento Comn: Todos los gerentes de nivel medio deben presentar un informe a su gerente de nivel superior indicando el costo mensual de materia prima, insumos, horas hombre y cantidades de productos terminados. Ejemplo de Requerimiento Individual: Si un pedido de un cliente excede en dos veces lo pedido tradicionalmente, se deber informar de inmediato al gerente de ventas para que evale la pertinencia o no de enviar el pedido.

IEEE: Institute of Electrical and Electronics Engineers. Instituto de Ingenieros en Electricidad y Electrnica

40

Especificacin de Requerimientos:
Algunos de los problemas que surgen durante el proceso de ingeniera de requerimientos son consecuencia de no hacer una clara separacin entre los diferentes niveles de descripcin de requerimientos. Esto se hace utilizando el trmino requerimientos del usuario, para designar los requerimientos abstractos de alto nivel, y requerimientos del sistema, para describir la descripcin detallada de lo que el sistema debe hacer. De la misma forma, se puede producir una descripcin ms detallada que servir de puente entre la ingeniera de requerimientos y las actividades propias de diseo. Los requerimientos del usuario, son declaraciones en lenguaje natural y en diagramas, de los servicios que se espera que el sistema provea y las restricciones bajo las cuales debe operar. Los requerimientos del sistema, establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, tambin suele denominarse especificacin funcional, debe ser muy preciso. Este documento sirve como contrato entre el comprador del sistema y el desarrollador de software. Si consideramos, por ejemplo, un requerimiento del usuario que sea: 1. El sistema debe proveer de un medio para graficar la evolucin de las cuentas a cobrar; Los requerimientos del sistema podran ser: 1.1. Al usuario se le proveer la posibilidad de elegir el perodo en el cual se quiere efectuar el anlisis de la evolucin de las cuentas a cobrar. 1.2. Se deber poder elegir el tipo de grfico que se quiere obtener. 1.3. Se tiene que permitir definir los ttulos del grfico, la descripcin de los distintos ejes y el rango inferior y superior de cada escala. 1.4. Se deber brindar la posibilidad de almacenar el grfico para que pueda ser luego accedido desde otras aplicaciones. Estos diferentes niveles de especificacin son de gran utilidad debido a que comunican la informacin del sistema a los diferentes tipos de lectores. Los requerimientos del usuario se redactan para el cliente y los contratistas quienes no tienen un conocimiento tcnico detallado del sistema. La especificacin de requerimientos del sistema est orientada al personal tcnico y a los administradores del proyecto. Generalmente ser utilizada tanto por los equipos tcnicos del cliente como por los del contratista. Dos visiones que complementan la especificacin funcional son: Una comprensin del dominio en que funcionar el sistema, entender los requerimientos requiere entender previamente a la organizacin. Una comprensin de las restricciones (del sistema, el ambiente o el desarrollo), conocidos como requerimientos no funcionales, tales como seguridad, disponibilidad, portabilidad, usabilidad, etc. Loucopoulos(1995) considera que: la especificacin de requerimientos tiene una perspectiva amplia y se refiere a la descripcin de los requerimientos de la organizacin expresados en trminos de los fenmenos comunes a la organizacin y al dominio del sistema. Las descripciones de la organizacin son independientes de cualquier comportamiento del sistema, en tanto que las descripciones del sistema se refieren a las propiedades que el sistema debe proveer. Grficamente puede representarse de la siguiente manera:

41

Requerimientos Del Dominio

Requerimientos Funcionales

Especificacin de Requerimientos

Requerimientos no Funcionales

Evaluacin

Figura 19: Esquema del proceso de Especificacin de Requerimientos

Los requerimientos pueden clasificarse en tres categoras: Requerimientos funcionales: Son declaraciones de los servicios o funcionalidad que proveer el sistema, de la manera en que ste reaccionar a entradas particulares (eventos externos) y de cmo se comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas tambin declaran explcitamente lo que el sistema no debe hacer. Requerimientos no funcionales: Son restricciones de los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estndares, etc. Requerimientos del dominio: Son requerimientos que provienen del dominio de aplicacin del sistema y que reflejan las caractersticas de ese dominio. Estos pueden ser a su vez, funcionales o no funcionales. Debemos considerar que esta clasificacin de requerimientos no es tan taxativa como lo presentan las definiciones anteriores. Debemos tener siempre presente que es una clasificacin artificial y por lo tanto podemos tener algunos problemas de frontera que nos lleven a poder ubicar algunos requerimientos como no funcionales mientras que otro analista podra situarlos como funcionales.

Requerimientos Funcionales:
Describen las funciones fundamentales a las que debe ajustarse el sistema. El centro de atencin para la obtencin de los requerimientos funcionales es transformar los inputs en outputs. Las funciones se especifican en trminos de inputs procesos outputs. Esta visin dinmica de la funcionalidad del sistema requiere tener en cuenta elementos tales como el control (secuenciamiento y paralelismo), el timing (comienzo y fin) y las excepciones en el comportamiento. Como las funciones interactan con los datos, stos deben formar parte de la especificacin. Las entidades del mundo real y sus relaciones deben definirse y relacionarse con funciones del sistema. Los requerimientos funcionales para un sistema suelen representarse de diferentes formas, podemos describir, por ejemplo, algunos de los requerimientos funcionales del sistema de gestin acadmica de la Universidad: El usuario deber tener la posibilidad de generar el listado de alumnos que se encuentran cursando determinada asignatura en un cuatrimestre.

42

 El sistema deber emitir las actas de calificaciones del curso, para que el docente responsable del mismo vuelque en ella las calificaciones. El sistema deber controlar que el alumno tenga aprobadas las asignaturas correlativas para permitir su inscripcin a examen final. El sistema tendr la capacidad de controlar la regularidad de los alumnos de acuerdo a lo establecido por el rgimen general de estudios. La imprecisin en la especificacin de los requerimientos de un sistema es una de las mayores fuentes de errores en los productos de software. Para quien realiza el diseo o el desarrollo del software es totalmente comn interpretar un requerimiento ambiguo con el fin de simplificar su implementacin. En estos casos, se termina especificando nuevos requerimientos para el sistema, haciendo cambios en el sistema y de esta manera se incrementan los tiempos de entrega y los costos de desarrollo de los productos. Como primera medida, podemos decir que la especificacin de requerimientos funcionales de un sistema debe estar completa y ser consistente. La completitud, significa que todos los requerimientos planteados por el usuario estn definidos en la especificacin de requerimientos. La consistencia, significa que los requerimientos no tengan definiciones contradictorias. Cuando definimos por primera vez los requerimientos, las inconsistencias no resultan tan obvias como cuando efectuamos un anlisis profundo de los requerimientos. Esto significa que el proceso de especificacin de los requerimientos presenta una estructura cclica, en la cual se repiten tareas, con distinto nivel de profundidad, y se va corrigiendo y depurando el documento de los requerimientos.

Requerimientos No Funcionales:
Son aquellos requerimientos que no se refieren, directamente, a las funciones especficas que deber entregar el sistema, sino a las propiedades emergentes del mismo como la fiabilidad, el tiempo en que debe dar respuesta o la capacidad de almacenamiento. Al mismo tiempo, pueden comprender las distintas restricciones del sistema como la capacidad de los dispositivos de entrada/salida (se requiere que el sistema tenga la capacidad de leer el EAN13 cdigo de barras - de determinados productos) o la manera en que se representan los datos en las distintas interfaces del sistema (pensemos, por ejemplo, en un sistema que tenga que imprimir cheques y se requiera que utilice determinado tipo de tinta). Si nos propusiramos hacer una lista de los distintos tipos de requerimientos no funcionales que podramos encontrar en un sistema, una nmina posible sera:

Performance
o o o tiempo real restricciones de tiempo velocidad de procesamiento

Precisin
o o precisin numrica informacin correcta en el tiempo correcto

Confiabilidad o o o disponibilidad de equipos disponibilidad de informacin integridad

Localizacin

43

o o

Geogrfica de responsabilidades

Restricciones operacionales Restricciones fsicas Seguridad o o o o o o o o Permiso de acceso Niveles de seguridad Polticas de confiabilidad Distribucin de datos help lookup de tablas restricciones de entrada /visualizacin de datos amigable

Interface

Mantenible Sommerville(2002) agrupa a los requerimientos no funcionales en tres categoras: 1. Requerimientos del producto: son aquellos que especifican el comportamiento del producto. 2. Requerimientos organizacionales: se derivan de las polticas y procedimientos existentes en la organizacin, tanto del cliente como del desarrollador de software. 3. Requerimientos externos: se derivan de factores externos al sistema. Por ejemplo la manera en que el sistema interacta con otros sistemas de la organizacin; requerimientos legales o requerimientos ticos.

Se debe cuidar de no incluir en la especificacin requerimientos del proyecto (asignacin de gente, cronogramas, costos, actividades, fases, procedimientos de reporting, etc.), ni diseos o planes de aseguramiento de calidad.

Requerimientos del Usuario:

Ya habamos planteado que los requerimientos del usuario son aquellos que especifican el comportamiento del sistema con un grado de detalle tal que puedan ser interpretados por los usuarios. Su funcin es describir los requerimientos funcionales y no funcionales de forma tal que sean comprensibles por quienes no tienen un conocimiento tcnico detallado. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas que puedan interpretarse intuitivamente. De todas maneras, es posible que surjan diversos problemas cuando se redacta usando lenguaje natural: Falta de claridad. Es difcil utilizar el lenguaje en forma precisa y no ambigua sin detallar el documento y convertirlo en algo complicado de leer. Confusin de requerimientos. No se distinguen claramente los requerimientos funcionales de los no funcionales, las metas del sistema y la informacin que es pertinente al diseo del sistema. Conjuncin de requerimientos. Se expresa como un nico requerimiento a un conjunto de requerimientos diferentes.

44

Podemos adelantar, que como una buena prctica en el documento de especificacin de requerimientos se deben separar, claramente, los requerimientos del usuario de los requerimientos del sistema. Cuando los requerimientos del usuario incluyen demasiada informacin, restringen la libertad del desarrollador del sistema para proveer soluciones innovadoras a los problemas del usuario (en el contexto de la organizacin). Los requerimientos del usuario debern enfocarse a los recursos principales a proveer por el sistema. Sommerville(2002), sugiere una serie de pautas sencillas para redactar los requerimientos del usuario: 1. Inventar un formato estndar y asegurar que todos los requerimientos sigan ese formato. Esto permitir reducir la probabilidad de omisiones y facilita la tarea de verificar los requerimientos. El formato propuesto considera poner en negrita el requerimiento inicial, incluir una declaracin bsica para cada requerimiento, y una referencia a la especificacin detallada de los requerimientos del sistema. 2. Utilizar el lenguaje en forma consistente. Distinguir claramente entre los requerimientos obligatorios y los que son deseables. Es aconsejable definir a los obligatorios en futuro simple el sistema deber y a los deseables en futuro condicional el sistema tendera o el sistema podra. 3. Resaltar el texto (con negritas o itlicas) para sealar las partes claves del requerimiento. 4. Evitar, en la medida de lo posible, utilizar lenguaje tcnico de computacin. Sin embargo, en los requerimientos del usuario, ser inevitable utilizar trminos tcnicos provenientes del dominio de la aplicacin del sistema.

Requerimientos del Sistema:

Son descripciones ms detalladas de los requerimientos del usuario. Son la base para definir el contrato entre el cliente y el desarrollador y por lo tanto debe ser una descripcin consistente y completa del sistema. Esta especificacin es el punto de partida para el diseo del sistema, por parte de los Ingenieros de Software. Incluye diferentes modelos del sistema como el de flujo de datos (DFD) o el modelo de objetos, listas de eventos y diccionarios de datos. En principio, los requerimientos del sistema debern establecer lo que ste har y no la manera en que se implementar. Sin embargo, es probable que se deban incluir algunos detalles que son propios de los requerimientos no funcionales. Por lo general se utiliza el lenguaje natural para definir los requerimientos del sistema, no obstante, ya hemos mencionado alguno de los inconvenientes de usar lenguaje natural por lo cual presentaremos otras alternativas de medio de comunicacin para la documentacin de los requerimientos del sistema: Lenguaje natural estructurado. Consiste en definir formatos estndar o plantillas para expresar los requerimientos. Lenguajes de descripcin de diseo. Se utiliza un lenguaje similar a los de alto nivel en programacin, pero con caractersticas ms abstractas que permitan especificar los requerimientos por medio de la definicin de un modelo operacional del sistema. Notaciones grficas. Para definir los requerimientos funcionales del sistema se pueden utilizar los lenguajes grficos. Uno de los primeros fue el SADT (Ross, 1977), tambin pueden utilizarse los casos de uso (Jacobsen, 1997) o los escenarios (Leite, 1997) Especificaciones matemticas. Son notaciones que se basan en conceptos matemticos como el de las mquinas de estado finito o los conjuntos. Estas especificaciones descartan

45

totalmente la posibilidad de ambigedad pero suelen no ser aceptadas por los clientes pues no las comprenden y por lo tanto no pueden usarse como contrato.

Determinando los Requerimientos

El proceso de determinacin de los requerimientos y su correcta especificacin, es uno de los procesos ms importantes, ya que de l depender gran parte del xito del proyecto. Este proceso, planteado por Loucopoulos(1995), puede ser dividido en tres subprocesos que mostramos a continuacin :
Comentarios del Usuario Usuario
t os ien o rim ri u e ua eq l Us R e d Mo d p o el o re aV l U al su ida ar i r o

Conocimiento Elicitacin Necesidad de ms Conocimiento

Co no cim D o ie n mi to d nio el

Modelo de Requerimientos Especificacin Resultado de la Validacin

to en mi nio ci no mi Co Do l de

Validacin

Dominio del Problema

Figura 20: Procesos de la Ingeniera de Requerimientos Describiremos ahora a cada uno de los tres procesos que integran el proceso de la ingeniera de requerimientos: Elicitacin7: Captura las necesidades de los clientes que provienen del dominio del problema y de los usuarios, que sern recuperados a travs de las tcnicas de recoleccin de datos. Este conocimiento capturado ser la entrada al subproceso de Especificacin. Especificacin: Se encarga de representar el conocimiento en un conjunto de notaciones, utilizando las tcnicas de documentacin. Estos modelos de requerimientos, sern la entrada al subproceso de validacin.

Validacin: Los modelos de requerimientos se presentarn al usuario para que ste certifique
que representa sus necesidades. Tambin sern contrastados contra el dominio del problema. Si los modelos son correctos y estn completos, el proceso de requerimientos ha concluido, de lo contrario es devuelto al subproceso de especificacin con los problemas encontrados.
7

Elicitar eliciting: Es el proceso de adquirir o sonsacar todo el conocimiento relevante necesario para producir un modelo de los requerimientos de un dominio de problema.

46

Actividades para la determinacin de requerimientos:

La determinacin de los requerimientos (Elicitacin) puede ser realizada desde cero, investigando el sistema o pueden tambin reutilizarse estudios conducidos con anterioridad en dominios similares. De esta manera, las actividades a llevar a cabo pueden ser : Reutilizacin de los requerimientos: Si el analista ya ha trabajado antes analizando otros dominios de aplicacin similares, sabr los requerimientos propios del dominio, as como tambin donde habitualmente se producen los problemas y pudiendo, de esta manera anticipar los requerimientos e investigar directamente las reas de conflicto. Investigacin del sistema: Estudio del sistema actual utilizando las herramientas para detectar hechos.

Reutilizacin de los requerimientos: La experiencia de los analistas en dominios similares, lo conducirn, conciente o inconscientemente, a realizar ciertas preguntas o desarrollar actividades o utilizar herramientas que no utilizara si desconociera por completo el dominio. Esto trae como consecuencia algunas ventajas y desventajas. Como ventaja fundamental, el analista con experiencia podr encontrar problemas rpidamente y conducir un anlisis ms sinttico, dado que lo general ya lo conoce y puede ser determinado sin una investigacin exhaustiva, dedicando ms tiempo al estudio de particularidades del usuario. Como consecuencia, el analista puede acortar pasos omitiendo investigar alguna actividad particular que en este caso, presente problemas y que no haya sido as en sus experiencias anteriores, constituyndose en la principal desventaja. De esta manera el subproceso de validacin cobrar ms importancia cuando se emplee esta actividad, verificando que lo que se haya inferido sea correcto y se aplique tambin en este caso, y adems certificando que todas las actividades han sido cubiertas. Investigacin del sistema: La investigacin del sistema comprende el estudio y documentacin del sistema actual. Se lleva a cabo aplicando tcnicas, herramientas y habilidades que le permitan al analista determinar y documentar las caractersticas del sistema. Esta actividad estar presente en todo anlisis de sistema ya que todos los sistemas tienen caractersticas propias que los hacen diferentes de otras aplicaciones del dominio y, que el analista deber tener en cuenta. La validacin de requerimientos, en este caso, certificar que lo que se haya entendido sea lo correcto y que tanto el cliente como el analista tengan la misma visin de las actividades desarrolladas por los primeros.

Requerimientos Bsicos
Cuando se conduce una investigacin, se debe procurar entender cada una de las actividades que se desarrollan y que quedaron dentro del lmite del sistema, establecido en la etapa de reconocimiento. Para entender estas actividades, debe estudiar : El procesamiento que se realiza Las entradas al procesamiento Las salidas del procesamiento Las restricciones impuestas por los lmites de tiempo y la carga de trabajo Los controles efectuados El usuario de las salidas. Para lograrlo, se debe dar respuesta a las siguientes preguntas :

47

 Cul es el proceso bsico de la organizacin? Qu datos utiliza o produce este proceso? Cules son los lmites impuestos por el tiempo y la carga de trabajo? Cules son los controles que se deben realizar? Quin utilizar los datos de salida de este proceso? Entender el Proceso Para comenzar, se debe intentar entender lo bsico de la actividad. Para hacerlo, lo primero es entender que es lo qu se hace y con qu finalidad. Esto dar una primera aproximacin al entendimiento del sistema y las caractersticas que sirven para describirlo. Un conjunto de preguntas nos darn esta aproximacin: Cul es la finalidad de esta actividad dentro del sistema? Qu pasos se siguen para llevarla a cabo? Dnde se realizan estos pasos? Quines lo realizan? Cunto tiempo les lleva realizarlo? Con qu frecuencia se realiza? Quines emplean la informacin resultante? Identificar las Entradas y Salidas El siguiente paso es identificar cules son los datos necesarios para realizar la actividad y qu informacin se produce. Uno debe, adems, relacionar esta salida con otras actividades que se han investigado para determinar cmo esta salida podra ayudar a realizar mejor el trabajo. La identificacin de las entradas y salidas, se obtiene fundamentalmente de los documentos que utilizan los usuarios para la realizacin de las tareas y de los documentos que producen. Identificar el Volumen y la Frecuencia La identificacin de la cantidad de datos necesarios para la realizacin de la actividad o de los datos que producen, as como tambin de la frecuencia de realizacin, darn una idea del impacto que esta actividad posee sobre el sistema global. Esto permitir, como consecuencia, valorar la importancia y su beneficio asociado en realizar los ajustes necesarios a esta actividad. Si la frecuencia es poca, y los volmenes tambin son pocos, probablemente el costo asociado del ajuste, respecto de los beneficios obtenidos, sean muy altos como para que una solucin pase por aqu. Si por el contrario, la actividad tiene una alta frecuencia o es muy tediosa su realizacin se pueden alcanzar altos beneficios ajustando la actividad. Identificar los Controles Para cada actividad o grupo de actividades, se deben identificar los controles que se realizan, as como tambin los estndares y los mtodos de retroalimentacin o ajustes que se utilizan. Esto hace una clara referencia al mtodo bsico de control que se vi en Introduccin a la Informtica. La siguiente lista de preguntas ayuda a identificar los controles: Existen estndares de desempeo especficos para esta/s actividad/es? Quin o quines realizan las mediciones?

48

 Quin o quines realizan la comparacin de las mediciones actuales contra los estndares? Cmo se detectan los errores? Cmo se corrigen los errores? Cuntos errores se comenten? Cul es el impacto de cometer un error? es decir hasta dnde se propaga? Cunto tiempo se tarda en corregirlo? Cunto cuesta corregirlo? Con este error se compromete la calidad del servicio a terceros? Como se comprender, identificar que hay problemas de controles en el sistema es un hecho sumamente importante, dado que ampla el costo del sistema actual haciendo que la solucin propuesta tenga mayores beneficios. Identificar a los Usuario de las Salidas La identificacin de los usuarios de las salidas ayuda a comprender las relaciones existentes entre los subsistemas y la importancia de stas para los destinatarios. Luego, se puede ver cmo las salidas ayudan a los usuarios a completar el propsito de las actividades que realizan y verificar si es posible realizar mejoras, dado que las salidas aqu sern las entradas para las actividades de los destinatarios.

Tcnicas para Elicitacin de Requerimientos

Las tcnicas de elicitacin de requerimientos son la herramienta de apoyo cuando se lleva a cabo la investigacin del sistema. Pueden categorizarse de diferente manera, nosotros propondremos las siguientes categoras: Partiendo del usuario Escenarios Anlisis de formularios Lenguaje natural

Partiendo del usuario:

Es el enfoque ms intuitivo, y de hecho hemos hablado directa e indirectamente de l, prcticamente, en todos los captulos. Sin embargo existen una serie de dificultades que debemos considerar, puede darse el caso de que el usuario tenga poca claridad para expresarse. Ocurre con frecuencia que quienes tienen experticia en la realizacin de determinadas tareas suelen tener dificultad para expresar el proceso que realizan para alcanzar los resultados que obtienen cotidianamente. Otra de las dificultades, es que se produzcan diferencias entre el usuario y el analista. Estas diferencias pueden tener distintos orgenes, se pueden producir por que el analista contradice al usuario respecto de manera en la que le informa que efecta una tarea, y esto genera diferencias entre ambas personas que dificultan la comunicacin. Otro de los posibles orgenes, es que el usuario est convencido que la tarea del analista es obtener todo el conocimiento que l tiene acumulado para desarrollar un sistema y que terminar por reemplazarlo. En este caso, el usuario generar, ex profeso, tensin en la comunicacin con el analista buscando que el clima hostil le permita negarse a informar lo requerido. Existen una serie de tcnicas para elicitar requerimientos partiendo del usuario: Entrevistas de comienzo y final abierto: es la manera ms simple de interaccin entre el analista y el usuario. El analista deja que el usuario hable respecto de cmo desarrolla sus tareas. Se deben realizar en un ambiente informal para estimular la confianza del usuario y disminuir la presin que

49

puede provocarle al estar siendo entrevistado. Son de gran utilidad para obtener visiones globales de cmo se realizan las tareas pero, por lo general, no suelen ser una manera eficaz de obtener informacin detallada al respecto. Entrevistas estructuradas: en este caso el analista tiene una serie de preguntas formuladas con antelacin al momento de la entrevista. Tienen por finalidad direccionar al usuario hacia aspectos especficos de requerimientos a elicitar. Debido a ello son de gran utilidad para obtener informacin detallada. Se utilizan preguntas cerradas, abiertas, de sondeo y de control. Brainstorming: cuando se genera falta de consenso entre los usuarios respecto a un requerimiento en particular, se puede utilizar la tcnica del brainstorming para resolver dicha falta de consenso. Por otra parte, este tipo de reuniones, en las cuales varios usuarios debaten entre s respecto de la manera en que se debe dar solucin a una cuestin, es un espacio que ayuda al analista a comprender el dominio del problema. Tambin puede utilizarse esta tcnica para resolver los problemas de diferencias entre usuarios y analistas o para reducir la falta de consenso respecto a determinados aspectos clave del proyecto.

Escenarios / Casos de Uso:

Un escenario es una historia que ilustra como un sistema puede satisfacer determinadas necesidades de los usuarios. Consiste en una descripcin idealizada, pero detallada, de una instancia especfica de interaccin usuario sistema. Se utilizan diferentes medios para documentar esta tcnica, puede utilizarse texto en lenguaje estructurado, dibujos tipo caricaturas o diagramas. Tienen la ventaja de que los usuarios encuentran mucho ms fcil contar su experiencia a travs de contar una historia.

Anlisis de la documentacin existente:

Un formulario puede definirse como una coleccin estructurada de variables que est formateada para soportar el ingreso de datos y su posterior recuperacin. Es una fuente muy importante para la elicitacin de requerimientos pues: es un modelo formal de datos, por lo general suelen contener informacin sobre la organizacin, sus instrucciones de uso encierran conocimiento sobre el dominio y su anlisis puede automatizarse. Como desventaja, podemos plantear que muchas veces los formularios contienen informacin que ya no se utiliza o ha dejado de ser relevante. A este punto debe prestrsele suma atencin pues se corre el riesgo de incorporar en las estructuras de datos, atributos o datos elementales que dejaron de tener relevancia en el dominio de la aplicacin.

Lenguaje Natural:
El lenguaje natural es la forma ms habitual en la cual se representa el conocimiento, independientemente del tipo de soporte que se est utilizando para su persistencia (oral o escrito). Es habitual que la mayora de lo que vale la pena conocer sobre el dominio de un problema puede formularse en lenguaje natural. Hay dos categoras de elicitacin en lenguaje natural: las que se basan en la interaccin con el usuario y los enfoques que elicitan desde un texto escrito en lenguaje natural. El mayor atractivo para usar lenguaje natural es que el vocabulario es preexistente (en este punto dejamos de lado la problemtica del lxico extendido del lenguaje 8. Otro atractivo consiste en que la sintaxis es conocida tanto por el receptor como por el emisor y, por ltimo, permite cierta informalidad al proceso de elicitacin. No obstante estas ventajas, tiene importantes limitaciones: el lenguaje natural es muy complejo, un mismo trmino suele utilizarse con diferente significado en distintos dominios (por ejemplo, el trmino factura tiene significados diferentes segn sea utilizado en el dominio de la
Lxico extendido del lenguaje, conjunto de trminos que tienen un significado propio en el dominio de la aplicacin y cuyo uso es preponderante en dicho dominio.
8

50

industria panadera o en una imprenta). Otra desventaja es la ambigedad, ciertos trminos pueden interpretarse de manera diferente tanto por el emisor como por el receptor. El lenguaje natural permite expresiones calificativas que, acompaadas de gesticulaciones, pueden utilizarse con diferente orden de importancia.

Administracin de Requerimientos
La administracin de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema. El proceso de administracin de requerimientos se lleva a cabo junto con los otros procesos de la ingeniera de requerimientos. La planeacin comienza al mismo tiempo que la obtencin de requerimientos iniciales, y la administracin efectiva de los requerimientos debe iniciarse ni bien est lista la primera versin del documento de requerimientos.
Porqu los requerimientos cambian?

Conforme se va desarrollando la definicin de requerimientos, se tiene una mejor comprensin de las necesidades del usuario. Esto retroalimenta la informacin del usuario, lo que provoca los cambios en los requerimientos. Con el tiempo, el entorno del sistema y los objetivos del negocio seguramente cambiarn, por lo tanto los requerimientos deben evolucionar para reflejar esto. Desde una perspectiva evolutiva, los requerimientos son de dos clases: 1. Requerimientos duraderos: Son relativamente estables, derivan de la actividad principal de la organizacin y estn relacionados directamente con el dominio del sistema. 2. Requerimientos voltiles: Estos cambiarn probablemente con el desarrollo del sistema o despus que este se haya puesto en operacin. Pueden ser clasificados de la siguiente manera : 2.1. Requerimientos mutantes: Son los que cambian debido a los cambios en el ambiente en el que opera la organizacin. 2.2. Requerimientos emergentes: Emergen al incrementarse la comprensin del cliente en el desarrollo del sistema. 2.3. Requerimientos consecutivos: Son el resultado de introducir el sistema. Esta introduccin puede cambiar los procesos de la organizacin y abrir nuevas formas de trabajar que generarn nuevos requerimientos. 2.4. Requerimientos de compatibilidad: Dependen de sistemas particulares o procesos de negocios dentro de la organizacin.

Planeacin de la administracin de requerimientos

Esta es una de las primeras etapas del proceso de administracin de requerimientos. Como la administracin de requerimientos es muy cara, la etapa de planeacin establece el nivel de detalle necesario en la administracin de requerimientos. Durante la etapa de administracin de requerimientos se debe decidir sobre : La identificacin de requerimientos: cada requerimiento debe identificarse de forma nica. Un proceso de administracin del cambio: este es un conjunto de actividades que evala el impacto y costo de los cambios. Polticas de rastreo: Definen la relacin entre los requerimientos, los requerimientos y el diseo del sistema que se debe registrar y la manera que los registros se deben mantener.

51

 Ayudas de herramientas CASE: Las herramientas que se pueden utilizar van desde sistemas de administracin de requerimientos especiales, hasta hojas de clculo y sistemas sencillos de bases de datos. Existen tres tipos de informacin de rastreo que se deben mantener: La informacin de rastreo de la fuente: vincula los requerimientos con quienes los propusieron y la razn de estos. La informacin de rastreo de los requerimientos: vincula los requerimientos dependientes en el documento de requerimientos. La informacin de rastreo del diseo: vincula los requerimientos a los mdulos del diseo en el cual sern implementados. Para relacionar este tipo de informacin muchas veces se utilizan matrices de rastreo. Son utilizadas cuando se tiene que administrar un nmero pequeo de requerimientos, pero son muy caras y pesadas de mantener para sistemas grandes. La administracin de requerimientos necesita ayuda automtica y las herramientas CASE que se utilizarn deben elegirse en la etapa de planeacin. Se requiera ayuda de estas herramientas para : Almacenar requerimientos: los requerimientos deben mantenerse en un almacn de datos seguro y administrado. Accesible para todos los que estn relacionados con el proceso de ingeniera de requerimientos. Administrar el cambio: este proceso se simplifica si se dispone de una herramienta de ayuda. Administrar el rastreo: para ayudar a descubrir relaciones entre los requerimientos, estn disponibles algunas herramientas que utilizan tcnicas de lenguaje natural. Para sistemas pequeos no es necesario utilizar herramientas de administracin de requerimientos especializadas. El proceso puede llevarse a cabo utilizando los recursos disponibles en los procesadores de texto, hojas de clculo y bases de datos.

Administracin del cambio de los requerimientos

Esta administracin se aplica a todos los cambios propuestos en los requerimientos. La ventaja de utilizar un proceso formal para administrar el cambio es que todos los cambios propuestos son tratados en forma consistente y controlada. Existen tres etapas principales en el proceso de administracin del cambio : Anlisis del problema y especificacin del cambio: Durante esta etapa, el problema o propuesta de cambio se analiza, para verificar su validez. Luego se realiza una propuesta de cambio de requerimientos ms especfica. Anlisis del cambio y costeo: El efecto de un cambio propuesto se valora, utilizando informacin de rastreo y conocimiento de los requerimientos del sistema. El costo de hacer un cambio se estima, tanto en trminos de modificaciones al documento de requerimientos, como a los de diseo e implementacin. Implementacin del cambio: Se modifica el documento de requerimientos, y en caso de ser necesario el diseo e implementacin del sistema. El documento se organiza a tal forma que los cambios se acomoden sin tener necesidad de redactar todo de nuevo.

52

Bibliografa
IEEE, An American National Standard. IEEE Guide to Software Requirements Specifications. ANSI/IEEE Std 830-1984, en Dorfman, M., Thayer, R.H., Standards, Guidelines, and Examples on Systems and Software Requirements Engineering, IEEE Computer Society Press, Los Alamitos, 1990 Loucopoulos, P., Karakostas, V., System Requirements Engineering, McGraw-Hill, London, 1995

Ingeniera de Software de Ian Sommerville. Editorial Addison Wesley (2002). Davis, A. Software Requeriments. Revision. Objects, Functions & States, Englewood Cliffs, Prentice Hall, 1993

53

Especificacin de Requerimientos de Software

Sistemas de Informacin I

Universidad Nacional de Lujn

Departamento de Ciencias Bsicas Divisin Estadsticas y Sistemas rea de Sistemas de Informacin

06
54

IEEE-STD-830-1998 : Especificacin de los requisitos del software.

1. Definiciones
En general las definiciones de los trminos usados en estas especificaciones estn conforme a las definiciones proporcionadas en IEEE Std 610.12-1990. Las definiciones siguientes son trminos claves usados en esta prctica recomendada. 1.1 Contrato: Documento legal acordado por el cliente y el proveedor. Esto incluye los requisitos tcnicos y requerimientos de la organizacin, costo y tiempo para un producto. Un contrato tambin puede contener la informacin informal pero til tales como los compromisos o expectativas de las partes involucradas. 1.2 Cliente: La (s) persona (s) que pagan por el producto y normalmente (pero no necesariamente) definen los requisitos. En el contexto de esta prctica recomendada el cliente y el proveedor pueden ser miembros de la misma organizacin. 1.3 Proveedor: La (s) persona (s) que producen un producto para un cliente. En el contexto de esta prctica recomendada el cliente y el proveedor pueden ser miembros de la misma organizacin. 1.4 Usuario: La (s) persona (s) que operan o interactan directamente con el producto. El usuario (s) y el cliente (s) no es (son) a menudo las mismas persona(s).

2. Las consideraciones para producir una buena SRS.

Estas clusulas proporcionan informacin contextual que deberan ser consideradas al momento de producir una SRS. Esto incluye lo siguiente: a) la Naturaleza de la SRS; b) el Ambiente de la SRS; c) las Caractersticas de una buena SRS ; d) la preparacin del acuerdo de la SRS; e) la evolucin de la SRS; f) Prototipos; g) Incorporando el diseo en la SRS; h) Incorporando los requisitos del proyecto en la SRS. 2.1 Naturaleza de la SRS La SRS es una especificacin para un producto de software en particular, programa, o conjunto de programas que realizan ciertas funciones en un ambiente especfico. La SRS puede escribirse por uno o ms representantes del proveedor, uno o ms representantes del cliente, o por ambos. La Subclausula 2.4 recomienda ambos.

55

Los problemas bsicos que se presentan al escribir una SRS van dirigidos a lo siguiente: a) La Funcionalidad. Qu se supone va hacer el software ? b) Las interfaces Externas. Cmo el software acta recprocamente con las personas, el hardware de los sistemas, otro hardware, y otro software? c) Performance. Cul es la velocidad, la disponibilidad, tiempo de respuesta, tiempo de recuperacin de varias funciones del software, etc.? d) Los Atributos. Qu portabilidad tiene, exactitud, el mantenimiento, la seguridad, las consideraciones etc.? e) Las restricciones de diseo impuestas sobre una implementacin. Hay algn Standard requerido, lenguaje de la implementacin, polticas para la integridad de la base de datos, lmites de recursos, entornos operativos etc.? Los autores de la especificacin de Requerimientos de Software deberan evitar poner requerimientos de diseo o del proyecto dentro de la SRS. Para ver el contenido recomendado ver clusula 3 2.2 Ambiente de la SRS Es importante considerar la parte que la SRS juega en el plan de proyecto total, que se define en IEEE Std 610.12-1990. El software puede contener toda la funcionalidad del proyecto esencialmente o puede ser parte de un sistema ms grande. En el ltimo caso habr una SRS que establecer las interfaces entre el sistema y sus partes, y se pondrn los requerimientos de performance y funcionalidad de cada parte del software. Por supuesto, la SRS debera estar de acuerdo con los requerimientos del sistema completo. El estndar IEEE 1074-1997 describe las etapas en el ciclo de vida del software y las entradas aplicables a cada una de ellas. Otros estndares estn relacionados con otras partes del ciclo de vida de software y as los requerimientos de Software pueden ser complementados. Dado que la SRS tiene un papel especfico en el proceso de desarrollo de software, los autores de la SRS deberan cuidar no ir ms all de los lmites de ese rol. Esto significa que la SRS: a) debe definir todos los requisitos del software correctamente. Un requisito del software puede existir debido a la naturaleza de la tarea a ser resuelta o debido a una caracterstica especial del proyecto. b) no debe describir ningn detalle de diseo o implementacin. stos deben describirse en la fase del diseo del proyecto. c) no debe imponer restricciones adicionales sobre el software. stas son especificadas apropiadamente en otros documentos, tales como los planes de Aseguramiento de la Calidad del Software. De esta forma, una SRS apropiada limita el rango de diseos vlidos pero no especifica un diseo particular.

56

2.3 Caractersticas de una buena SRS. Una SRS debe ser: a) Correcta; b) No ambigua; c) Completa; d) Consistente; e) Clasificar por importancia y/o estabilidad; f) Verificable; g) Modificable; h) Rastreable.

2.3.1 Correcta Una SRS es correcta si, y slo si, cada requisito declarado es un requerimiento que el software debe alcanzar. No hay ninguna herramienta o procedimiento que aseguren la correctitud. La SRS debera ser comparada con alguna especificacin superior aplicable, tal como una especificacin de los requerimientos del Sistema, con otros documentos del proyecto y con otros estndares aplicables para asegurar que est de acuerdo. Alternativamente el cliente o el usuario pueden determinar si la SRS refleja las necesidades reales correctamente. La rastreabilidad hace este procedimiento ms fcil y menos propenso al error. 2.3.2 No ambigua Una SRS es no ambigua si, y slo si, cada requisito declarado tiene slo una interpretacin. Esto requiere que, como mnimo, cada caracterstica del producto final sea descripta usando un nico trmino. En casos dnde un trmino en un contexto particular tenga significados mltiples, el trmino debe ser incluido en un glosario dnde su significado es ms especfico. Una SRS es una parte importante del proceso de requerimientos del ciclo de vida de software y se usa en el diseo, implementacin, monitoreo del proyecto, validacin y verificacin y en entrenamiento como se describe en IEEE Std 1074-1997. La SRS debe ser no ambigua tanto para aquellos que la crean como para aquellos que la usan. Sin embargo, estos grupos no tienen a menudo la misma formacin y por consiguiente no tienden a describir los requisitos del software de la misma manera. Las representaciones que proveen la SRS para los desarrolladores puede ser contraproducente en el entendimiento de los usuarios y viceversa. Las Subclausulas 2.3.2.1 hasta de 2.3.2.3 recomiendan cmo evitar la ambigedad.

57

2.3.2.1 Dificultad del lenguaje natural. Los requisitos son a menudo escritos en lenguaje natural (por ejemplo, castellano) el lenguaje natural es inherentemente ambiguo. Una SRS en lenguaje natural debera ser revisada por un equipo independiente para identificar el uso ambiguo del lenguaje para que pueda corregirse. 2.3.2.2 Lenguajes de especificacin de requisitos Una manera de evitar la ambigedad inherente al lenguaje natural es escribir la SRS en un lenguaje de especificacin de requisitos particular. Sus procesadores de lenguaje detectan errores lxicos, sintcticos, y semnticos automticamente. Una desventaja en el uso de tales lenguajes es la cantidad de tiempo requerido para aprenderlos. Adems, muchos usuarios no-tcnicos los encuentran ininteligibles. Es ms, estos lenguajes tienden a ser mejores para expresar ciertos tipos de requisitos y dirigirse a ciertos tipos de sistemas. As, ellos pueden influenciar los requerimientos de una manera sutil. 2.3.2.3 Herramientas de Representacin En general, los mtodos de requisitos y lenguajes y las herramientas que los apoyan entran en tres categoras generales - objeto, proceso y comportamiento. Los enfoques orientados a objetos organizan los requisitos en trminos de objetos del mundo real , sus atributos, y los servicios realizados por esos objetos. Los enfoques basados en procesos organizan los requisitos dentro de jerarquas de funciones que se comunican va el flujo de datos. Los enfoques de comportamiento describen el comportamiento externo del sistema en trminos de algunas nociones abstractas, (tales como clculo de predicados), funciones matemticas o mquinas de estado. El grado en el cual estas herramientas y mtodos pueden ser tiles para preparar una SRS dependen del tamao y complejidad de los programas. No intentamos aqu describir o recomendar ninguna herramienta particular. Usar cualquiera de estos enfoques es mejor que emplear descripciones en lenguaje natural. De esta manera los clientes que no estn familiarizados con las notaciones pueden entender igualmente la SRS.

2.3.3 Completa Una SRS est completa si, y slo si, incluye los siguientes elementos: a) Todos los requerimientos importantes ya sean relacionados con la funcionalidad, performance, restricciones del diseo, atributos o interfaces externas. En particular cualquier requerimiento externo impuesto por una especificacin del sistema debera ser acordado y tratado. b) La definicin de las respuestas del software a todos los posibles datos de entrada del sistema en todas las situaciones posibles. Note que es importante especificar tanto las respuestas vlidas e invlidas a los valores de entrada. c) Tener todas las etiquetas llenas y referencias a todas las figuras, tablas, diagramas en la SRS y definicin de todos los trminos y unidades de medida. 2.3.3.1 Uso de ASDs Cualquier SRS que usa la frase "A ser definido" (ASD) no es una SRS completa.

58

El ASD es, sin embargo, ocasionalmente necesario y debe acompaarse por: a) Una descripcin de las condiciones que causan el ASD (por ejemplo, por qu una respuesta no es conocida) para que la situacin pueda resolverse; b) Una descripcin de lo que debe hacerse para eliminar el ASD que es responsable para su eliminacin y por como debe eliminarse.

2.3.4 Consistente La consistencia se refiere a la consistencia interna. Si una SRS no est de acuerdo con algn documento de alto nivel, tal como la especificacin de requerimientos de sistema, entonces no es correcta. 2.3.4.1 Consistencia interna Una SRS es internamente consistente si, y slo si, no hay ningn subconjunto individual de la SRS que est en conflicto. Los tres tipos de conflictos en una SRS pueden ser los siguientes : a) Las caractersticas especificadas para un objeto del mundo real pueden estar en conflicto. Por ejemplo 1) Los formatos de un reporte de salida pueden ser descriptos en un requerimiento como una tabla en otro como un texto. 2) Un requerimiento puede establecer que todas las luces deberan ser verdes mientras otro puede establecer que todas las luces deberan ser azules. b) Podra haber conflictos lgicos o temporales entre dos acciones especificadas. Por ejemplo, 1) un requerimiento puede especificar que el programa debe sumar dos entradas y otro puede especificar que el programa debera multiplicarlas. 2) un requerimiento que establece que "A" debe seguir a "B", mientras otro puede requerir que "Ay B" ocurran simultneamente. c) Dos o ms requerimientos pueden describir el mismo objeto del mundo real pero usando diferentes trminos para este objeto. Por ejemplo, las solicitudes de un programa pueden ser llamadas un prompt (peticin de orden) en un requerimiento y un que (mostrar) en otro. El uso de definiciones y terminologa estndar promueve la consistencia.

2.3.5 Clasificacin por importancia y/o estabilidad Una SRS est ordenada por importancia y/o estabilidad si cada requerimiento en ella ha sido identificado para indicar tanto la importancia como la estabilidad del requerimiento particular. Habitualmente, todos los requerimientos que se relacionan con un producto de software no tienen la misma importancia. Algunos requerimientos pueden ser esenciales, mientras que otros pueden ser deseables. Cada requerimiento en la SRS debera estar identificado para hacer explcita y clara esta diferencia. Identificar los requerimientos de la siguiente manera puede ayudar : a) A hacer que los clientes hagan consideraciones ms cuidadosas a cada requerimiento, lo cual a menudo clarifica alguna presuncin oculta que ellos pueden tener.

59

b) Tener desarrolladores que hacen decisiones de diseo ms correctas y tengan niveles de dedicacin apropiados del esfuerzo para las diferentes partes del producto de software. 2.3.5.1 Grado de estabilidad Un mtodo de identificar requerimientos es usar la dimensin de estabilidad. La estabilidad puede ser expresada en trminos del nmero de cambios esperados para algn requerimiento basado en la experiencia o el conocimiento de la ocurrencia de algn evento que efecte la organizacin, funciones, o la gente que es ayudada por el sistema de software. 2.3.5.2 Grado de necesidad Otra manera de ordenar requerimientos es distinguir las clases de requisitos que hay: el esencial, el condicional y opcional. a) Esenciales. Implica que el software no debera ser aceptado hasta que stos requerimientos sean provistos en la manera acordada. b) Condicionales. Implica que hay requerimientos que podran hacer ms relevante al producto de software, pero no lo haran inaceptable si estn ausentes. c) Opcionales. Implica una clase de funciones que podran o no ser importantes. Esto le da al proveedor la oportunidad de proponer algo que exceda la SRS .

2.3.6 Verificable Una SRS es verificable si, y slo si, cada requisito establecido en ella es verificable. Un requerimiento es verificable si, y slo si, existe algn proceso finito y efectivo en costos con el cual una persona o la mquina pueda chequear que el producto de software rene tal requerimiento. En general los requerimientos ambiguos son no verificables. Los requerimientos No-verificables incluyen expresiones tales como "Que trabaje bien", "Buena interface humana" y "podra usualmente pasar". Estos requerimientos no pueden ser verificados porque no es posible definir los trminos "bueno," "bien" o "usualmente". La expresin "el programa nunca entrar en un loop infinito" no es verificable porque las pruebas de esta cualidad son tericamente imposibles. Un ejemplo de una expresin verificable es: Las salidas del programa deberan producirse dentro de 20 seg el 60% de las veces; y deberan ser producidas dentro de los 30 seg el 100% de las veces. Estas expresiones son verificables porque usan trminos concretos y medidas cuantitativas. Si no se puede seguir un mtodo para determinar que el software rene un particular requerimiento , entonces el requerimiento debera ser removido o revisado.

60

2.3.7 Modificable Una SRS es modificable si, y slo si, su estructura y estilo son tales que los cambios a los requerimientos pueden ser hechos fcil, completamente y consistentemente mientras se mantiene la estructura y estilo. La modificabilidad generalmente requiere que la SRS : a) Tenga una organizacin coherente y fcil de usar con una tabla de contenidos, un ndice y una tabla de referencias cruzadas explcitas; b) no ser redundante (por ejemplo, el mismo requisito no debera aparecer en ms de un lugar en la SRS); c) Expresar cada requisito separadamente, en lugar de entremezclarlos con otros requerimientos. La redundancia en si misma no es un error, pero puede fcilmente conducirnos a un error. La redundancia puede ayudar a hacer una SRS ms legible de vez en cuando, pero el problema que puede ocurrir cuando un documento redundante es actualizado. Por ejemplo, un requisito puede alterarse en un solo lugar dnde aparece. La SRS entonces se convierte en inconsistente. Cuando la redundancia es necesaria, la SRS debera incluir referencias cruzadas explcitas para hacerla modificable.

2.3.8 Rastreable Una SRS es rastreable si el origen de cada uno de sus requisitos est claro y si ella facilita referenciar a cada requerimiento en un futuro desarrollo o documentacin. Se recomienda seguir dos tipos de rastreabilidad: a) Rastreabilidad hacia atrs (por ejemplo estados previos de desarrollo). Esto cuenta con que cada requerimiento referencie explcitamente a sus fuentes en documentos anteriores. b) Rastreabilidad hacia adelante (Por ejemplo hacia todos los documentos creados posteriormente a la SRS). Esto cuenta con que cada requerimiento en la SRS tenga un nombre nico o un nmero de la referencia. La rastreabilidad hacia adelante de la SRS es esencialmente importante cuando el producto del software entra en la fase de operacin y mantenimiento. Cuando los documentos de diseo o el cdigo son modificados, es esencial que estn disponibles el conjunto de requerimientos completos que pueden ser afectados por estas modificaciones.

2.4 Preparacin comn para la SRS El proceso de desarrollo de software debera comenzar proveedores y clientes acordando en cual es el software completo que debe hacerse. Este acuerdo, en la forma de una SRS, debera ser preparado en forma conjunta. Esto es importante porque habitualmente ni los clientes ni los proveedores estn calificados para escribir una buena SRS solos. a) Los clientes no entienden el proceso de diseo y desarrollo de software tan bien como para escribir una SRS usable. b) Los Proveedores usualmente no entienden los problemas del cliente y el campo de aplicacin tan bien como para especificar requerimientos para un sistema satisfactorio. Por consiguiente, los cliente y los proveedores deberan trabajar juntos para producir una SRS bien escrita y completamente entendible. Una situacin especial existe cuando el sistema y su software son ambos definidos concurrentemente. Entonces la funcionalidad, interfaces, performance y otros atributos, y restricciones del software no estn

61

predefinidos, sino que son ms bien definidos en conjunto, as como tambin los cambios y los asuntos de negocios. Esto hace ms difcil, pero no menos importante, alcanzar las caractersticas establecidas en 2.3. En particular, una SRS que no cumple con la especificacin de requerimientos de su sistema padre es incorrecto. Estas prcticas recomendadas no discuten especficamente estilos, lenguajes usados o tcnicas de buena escritura, sin embargo es muy importante que la SRS est bien escrita. Las tcnicas generales para escribir libros pueden ser usadas como gua.

2.5 Evolucin de la SRS La SRS puede necesitar modificarse a medida que progresa el desarrollo del producto de software. Puede ser imposible especificar algunos detalles al momento de iniciar el proyecto (por ejemplo, puede ser imposible definir todos los formatos de la pantalla para un programa interactivo durante la fase de requisitos). Cambios adicionales pueden asegurar poner al descubierto deficiencias, fallas y equivocaciones en la SRS. Las dos principales consideraciones en este proceso son las siguientes : a) Deben especificarse los requisitos completamente como son conocidos en el momento, aun cuando las revisiones evolutivas puedan preverse como inevitables. El hecho que ellos estn incompletos debe ser anotado. b) Un proceso de cambio formal debe ser inicializado para identificar, controlar, seguir y reportar cambios en el proyecto. Una vez aprobados los cambios en los requerimientos deberan ser incorporados en la SRS para 1. Proporcionar un adecuado y completo camino para auditar los cambios. 2. Permitir la revisin de la porcin actual y la reemplazada en la SRS . 2.6 Prototipos. Los prototipos frecuentemente se usan durante la fase de los requisitos de un proyecto. Muchas herramientas existen para permitir un prototipo que exhiba algunas caractersticas de un sistema, creado en forma rpida y fcil. Ver tambin ASTME 1340-96. Los prototipos son tiles por las siguientes razones: a) Los clientes pueden ser ms propensos a ver los prototipos y reaccionar a ellos, que leer la SRS y reaccionar a ella. As, los prototipos proporcionan una ms rpida retroalimentacin. b) El prototipo muestran aspectos imprevistos del comportamiento de los sistemas. As, produce no slo respuestas sino tambin nuevas preguntas. Esto ayuda a alcanzar el final de la SRS. c) Una SRS basada en un prototipo tiende a sufrir menos cambios durante el desarrollo, as acorta el tiempo de desarrollo. Un prototipo debe usarse como una manera de elicitar los requisitos del software. Algunas caractersticas tales como pantalla o formatos del reporte pueden ser extrados directamente del prototipo. Otros requisitos pueden ser inferidos de la ejecucin de los prototipos.

2.7 Incorporando el diseo en la SRS Un requisito especifica una funcin visible externamente o atributo de un sistema. Un diseo describe un subcomponente particular del sistema y/o sus interfaces con otros subcomponentes. La escritura de la SRS

62

debera distinguir claramente entre restricciones identificadas al diseo requerido y proponer un diseo especfico. Note que cada requisito en la SRS limita las alternativas de diseo. Esto no significa, sin embargo, que cada requisito sea un diseo. La SRS debera especificar qu funciones deben ser realizadas, sobre qu datos, para producir qu resultados, en qu situacin y para quien. La SRS se debera enfocar en los servicios a ser realizados. La SRS no debera normalmente especificar items de diseo tales como los que siguen : a) Particionamiento del software en mdulos; b) Asignaciones de funciones a los mdulos; c) Describir el flujo de informacin o controles entre los mdulos; d) Escogiendo las estructuras de los datos. 2.7.1 Requisitos de diseo necesarios En casos especiales algunos requisitos pueden restringir el diseo severamente. Por ejemplo, seguridad o requisitos de seguridad pueden reflejarse directamente en el diseo cuando sean necesarios para : a) Mantener ciertas funciones en mdulos separados; b) Permitir slo comunicacin limitada entre algunas reas del programa; c) Verificar la integridad de datos de algunas variables crticas. Ejemplos de restricciones del diseo vlidos son requisitos fsicos, requisitos de performance, estndar de desarrollo de software y de aseguramiento de la calidad del software. Por consiguiente, los requisitos deberan ser establecidos desde un punto de vista completamente externo. Cuando se utilizan modelos para ilustrar los requisitos, recuerde que los modelos slo indican el comportamiento externo, y no especifican un diseo

2.8 Incorporando los requisitos del proyecto en la SRS. La SRS debera conducir al producto software, no al proceso de producir el producto del software. Los requisitos del proyecto representan un acuerdo entre el cliente y el proveedor acerca de la manera contractual adecuada para producir el software y por lo tanto no debera incluirse en la SRS. Esto normalmente incluye items como: a) Costos; b) Planes de entrega; c) Procedimientos de reportes; d) Mtodos de desarrollo de Software; e) Aseguramiento de la Calidad; f) Criterios de verificacin y validacin ; g) Procedimientos de aceptacin.

63

Los requisitos del proyecto son especificados en otros documentos, habitualmente en un plan de desarrollo de software, uno de aseguramiento de la calidad del software o una declaracin de trabajo.

3. Las partes de una SRS

Esta clusula discute cada parte esencial de la SRS. Estas partes estn ordenadas en la Figura 1 en un borrador que puede servir como un ejemplo de escrito de una SRS. Si bien, una SRS no tiene que seguir este borrador o usar los nombres dados aqu para sus partes, una buen SRS debera incluir toda la informacin que es discutida aqu. Tabla de Contenidos

1. Introduccin
1.1 Propsito 1.2 Alcance 1.3 Definiciones, acrnimos, y abreviaturas 1.4 Referencias 1.5 Apreciacin global

2. Descripcin global
2.1 Perspectivas del producto 2.2 Funciones del producto 2.3 Caractersticas del usuario 2.4 Restricciones 2.5 Presunciones y dependencias

3. Los requisitos especficos (Vea del 3.3.1 al de 3.3.8 para una explicacin de los posibles requerimientos especficos) Ver tambin anexo A para varias maneras de organizar esta seccin de la SRS.
Apndices Indice 3.1 Introduccin (Seccin 1 de la SRS) La introduccin de la SRS debera proveer una visin global de la SRS completa. Debera contener las siguientes subsecciones: a) Propsito; b) Alcance; c) Definiciones, acrnimos, y abreviaturas; d) Referencias;

64

e) Apreciacin global. 3.1.1 Propsito (1.1 de la SRS) Esta subseccin debera: a) Delimitar el propsito de la SRS; b) Especificar la audiencia pretendida para la SRS. 3.1.2 Alcance (1.2 de la SRS) Esta subseccin debera: a) Identificar los productos software a ser producidos por su nombre (por ejemplo, Host DBMS, Generador de Reportes, etc.); b) Explicar que har el producto software y si es necesario que no har. c) Describir la aplicacin del software especificada, incluyendo beneficios relevantes, objetivos, y metas; d) Ser consistente con los establecido en forma similar en especificaciones de ms alto nivel (por ejemplo, las especificaciones de los requisitos del sistema), si existen. 3.1.3 Definiciones, Acrnimos, y abreviaturas (1.3 de la SRS) Esta subseccin debera proporcionar las definiciones de todos los trminos, acrnimos, y abreviaturas para interpretar apropiadamente la SRS . Esta informacin puede ser provista haciendo referencia a uno o ms apndices en la SRS o referenciando a otros documentos. 3.1.4 Referencias (1.4 de la SRS) Esta subseccin debera: a) Proporcionar una lista completa de todos los documentos referenciados en otra parte en la SRS; b) Identificar cada documento por ttulo, nmero reporte (si es aplicable), fecha, y editorial; c) Especificar las fuentes de donde se obtuvieron las referencias. Esta informacin puede proporcionarse por referencias a un apndice o a otro documento. 3.1.5 Apreciacin global (1.5 de la SRS) Esta subseccin debera: a) Describir que contiene el resto de la SRS; b) Explicar cmo est organizada la SRS.

3.2 Descripcin global (Seccin 2 de la SRS)

Esta seccin de la SRS debera describir los factores generales que afectan el producto y sus requisitos. Esta seccin no establece requisitos especficos. A pesar de ello provee el contexto de aquellos requerimientos que son definidos en detalle en Seccin 3 de la SRS, y que los hacen ms fciles de comprender. Esta seccin normalmente consiste en seis subdivisiones, como sigue: a) Perspectiva del Producto; b) Funciones del Producto;

65

c) Caractersticas del Usuario; d) Restricciones; e) Presunciones y dependencias; f) Divisin de requerimientos. 3.2.1 Perspectiva del producto (2.1 de la SRS) Esta subseccin de la SRS debera poner al producto en perspectiva con otros productos relacionados. Si este producto es independiente y est totalmente autocontenido, debera tambin ser establecido aqu. Si la SRS define un producto que es un componente de un sistema mayor, como frecuentemente ocurre, entonces esta subseccin debera relacionar los requisitos del sistema mayor a la funcionalidad del software y debera identificar las interfaces entre ese sistema y el software. Puede ser til un diagrama de bloques que muestre los componentes principales del sistema mayor, interconexiones, e interfaces externas. Esta subseccin debera tambin describir cmo el software opera dentro de varias restricciones. Por ejemplo, estas restricciones podran incluir: a) Interfaces de Sistema; b) Interfaces de Usuario; c) Interfaces de Hardware; d) Interfaces de Software; e) Interfaces de Comunicaciones; f) Memoria; g) Operacin; h) Requerimientos de adaptacin del Site. 3.2.1.1 Interfaces del sistema. Esto debe listar cada interfaz del sistema y debe identificar la funcionalidad del software para cumplir los requisitos del sistema y la descripcin de las interfaces que concuerdan con el sistema. 3.2.1.2 Interfaces del usuario. Esto debera especificar lo siguiente: a) Las caractersticas lgicas de cada interfaz entre el producto del software y sus usuarios. Esto incluye aquellas caractersticas de configuracin necesarias para cumplir los requisitos del software. (Por ejemplo, formatos de la pantalla requeridos, esquemas de ventanas o pgina, contenido de algn reporte o mens, funciones de teclas programables o disponibles). b) Todos los aspectos de optimizacin de las interfaces con las personas que deban usar el sistema. Esto simplemente puede consistir de una lista de cmo el sistema hace para mostrarse al usuario o como no. Un ejemplo puede ser un requisito de la opcin de un mensaje de error largo o corto. Adems todos estos requisitos deben ser verificables (esto debe tambin ser especificado en los Atributos de Sistema Software bajo una seccin titulada Facilidad de Uso).

66

3.2.1.3 Interfaces del hardware. Esto debera especificar las caractersticas lgicas de cada interfaz entre el producto del software y los componentes del hardware del sistema. Esto incluye las caractersticas de la configuracin (el nmero de puertos, conjunto de instrucciones, etc.), esto tambin cubre cosas importantes cmo qu dispositivos deben ser soportados, cmo sern soportados y los protocolos. Por ejemplo, se puede especificar soporte para terminales de pantalla completa como opuesto a pantallas de lnea a lnea. 3.2.1.4 Interfaces con el software. Esto debera especificar el uso de otros productos del software requeridos (por ejemplo, un sistema de administracin de datos, un sistema operativo o un paquete matemtico), e interfaces con otros sistemas de aplicacin (por ejemplo, la unin entre, un Sistema de Cuentas a Cobrar y Sistema de Contabilidad General). Para cada producto de software requerido se debera proveer lo siguiente: - Nombre; - Mnemotcnico; - Nmero de especificacin; - Nmero de versin; - Fuente. Para cada interfaz, debera proporcionarse lo siguiente: - Discusin del propsito de la interfaz del software en relacin con el producto del software. - Definiciones de las interfaces en trminos de contenidos del mensaje contenidos y formato. No es necesario detallar interfaz bien documentada, pero si es necesario una referencia al documento que la define. 3.2.1.5 Interfaces de comunicaciones Esto debera especificar las varias interfaces para la comunicacin tales como protocolos de las redes locales, etc., 3.2.1.6 Restricciones de memoria Esto debera especificar cualquier caracterstica aplicable y lmites en la memoria primaria y la memoria secundaria. 3.2.1.7 Operaciones Esto debera especificar las operaciones normales y especiales requeridas por los usuarios tales como: a) Los varios modos de operacin en la organizacin del usuario. b) Periodos de operacin interactiva y periodos de operacin no supervisada; c) Funciones de soporte al procesamiento de datos d) Operaciones de Backup y recuperacin. NOTA : Esto es algunas veces especificado como parte de la Seccin de interfaces de Usuario. 3.2.1.8 Requisitos de adaptacin del Site. Esto debera:

67

a) Definir los requisitos para cualquier dato o secuencia de inicializacin que son especificadas para un site dado, misin, o modo de operacin (por ejemplo, grillas de valores, lmites de seguridad, etc.); b) Especificar el site o caractersticas relacionadas con la misin que deberan ser modificadas para adaptar el software a una instalacin particular. 3.2.2 Funciones del Producto (2.2 de la SRS) Esta subseccin de la SRS debera proveer un resumen de las funciones principales que el software realizar. Por ejemplo, una SRS para un programa de cuentas podra usar esta parte para introducir al mantenimiento de Cuentas de Clientes, declaraciones de clientes, preparacin de inventarios, sin mencionar el vasto tamao de los detalles que cada una de estas funciones requiere. Algunas veces el resumen de funciones que es necesario para esta parte puede ser tomado directamente desde las secciones de especificacin de alto nivel (si existen) que asignan funciones particulares al producto software. Note que para ganar claridad : a) Las funciones deberan estar organizadas en una forma que la lista de funciones sean entendibles para los clientes o para cualquier otro que lea el documento por primera vez. b) Mtodos grficos o textuales pueden ser utilizados para mostrar las diferentes funciones y sus relaciones. Tales diagramas no tienen la intencin de mostrar un diseo de un producto, sino simplemente mostrar las relaciones lgicas ms variables. 3.2.3 Caractersticas del usuario (2.3 de la SRS) Esta subseccin de la SRS debera describir aquellas caractersticas generales del usuario pretendido del producto incluyendo nivel de educacin, experiencia, experticia tcnica. No debera ser usado para establecer requerimientos especficos, sino ms bien para proveer las razones por las cuales ciertos requerimientos especficos son luego especificados en la seccin 3 de la SRS. 3.2.4 Restricciones (2.4 de la SRS) Esta subseccin de la SRS debera proporcionar una descripcin general de algunos otros items que limitarn las opciones de desarrollo. sto incluye: a) Polticas regulatorias ; b) Limitaciones de Hardware; (por ejemplo requerimientos de tiempo de seal) c) Interfaces con otras aplicaciones; d) Operacin en Paralelo; e) Funciones de Auditora; f) Funciones de Control; g) Requerimientos de lenguaje de orden mayor; h) Protocolos para establecimiento de comunicaciones (por ejemplo, XON-XOFF, ACK-NACK); i) Requerimientos de Fiabilidad; j) Criticidad de la aplicacin; k) Seguridad y consideraciones de seguridad y fiabilidad.

68

3.2.5 Presunciones y dependencias (2.5 de la SRS) Esta subseccin de la SRS debera listar cada uno de los factores que afectan los requerimientos establecidos en la SRS. Estos factores no son restricciones de diseo sobre el software, sino, ms bien, algunos cambios de estos que pueden afectar los requerimientos en la SRS. Por ejemplo, una presuncin podra ser que un sistema operativo especfico est disponible para un hardware diseado para el producto software. Si, de hecho, el sistema operativo no est disponible, la SRS deber tener que cambiar acorde a esto. 3.2.6 Particionamiento de los requerimientos (2.6 de la SRS) Esta subseccin de la SRS debera identificar los requerimientos que sern demorados hasta futuras versiones del sistema. 3.3 Requerimientos especficos (Seccin 3 de la SRS) Esta seccin de la SRS debera contener todos los requerimientos del software a un nivel de detalle suficiente para asegurar que los diseadores diseen un sistema que satisfaga estos requerimientos, y hacer que los testers (probadores) prueben que el sistema satisface estos requerimientos. A travs de esta seccin, cada requisito establecido debera ser percibido externamente por un usuario, operador u otro sistema externo. Estos requerimientos deberan ser incluidos con una mnima descripcin de cada entrada (el estmulo) dentro del sistema, cada salida (respuesta) del sistema, y todas las funciones realizadas por el sistema en respuesta a la entrada o como soporte de una salida. Esta es a menudo la seccin ms larga y ms importante de la SRS, los siguientes principios deberan aplicarse: a) Los requisitos especficos deberan ser establecidos en conformidad con todas las caractersticas descritas en 2.3. b) los requisitos especficos deberan tener referencias cruzadas a documentos anteriores que estn relacionados. c) Todos los requerimientos deberan ser identificados unvocamente. d) Se debera prestar atencin a la organizacin de los requerimientos para maximizar la legibilidad. Antes de examinar la manera especfica de la organizacin de los requerimientos es til entender los varios items que comprenden los requisitos como son descriptos desde 3.3.1 hasta 3.3.7. 3.3.1 Interfaces externas Aqu se deberan detallar todas las entradas y salidas del sistema del software. Debera completarse la descripcin de las interfaces en 3.2 y debera no repetirse a informacin aqu. Debera incluirse tanto contenidos y formatos como sigue: a) Nombre del item ; b) Descripcin de propsito; c) Fuente de entrada o destino de la salida; d) Rango vlido, adecuacin, y/o tolerancia; e) Unidades de medida; f) Tiempos;

69

g) Relaciones con otras entradas/salidas; h) Formato de pantallas u organizacin; i) Formato de ventanas u organizacin; j) Formato de datos; k) Formato de comandos; l) Mensajes finales. 3.3.2 Funciones Los requerimientos funcionales deberan definir la accin fundamental que debe realizar el software, en aceptacin y procesamiento de la entrada, y en el procesamiento y generacin de las salidas. Esto es generalmente listado con la sentencia "deber" que empieza con "El sistema deber." Esto incluye: a) Prueba de validacin de la entrada b) Secuencia exacta de operaciones c) Respuesta de situaciones anormales, incluyendo 1) overflow (sobredimensionamiento) 2) facilidad de comunicacin 3) manejo de errores y recuperacin d) Efecto de los parmetros e) Relaciones de las salidas y las entradas, incluyendo 1) Secuencia de entrada/salidas 2) Frmulas de entrada para conversin de las salidas Puede ser apropiado particionar los requerimientos funcionales en subfunciones o subprocesos. Esto no implica que el diseo del software deba ser particionado de esta manera. 3.3.3 Requerimientos de performance Esta subseccin debera especificar los requerimientos numricos estticos como los dinmicos puestos sobre el software o sobre la interaccin humana con el software como un todo. Los requerimientos numricos estticos pueden incluir lo siguiente: a) Cantidad de terminales a ser soportadas; b) El nmero de usuarios simultneos a ser soportados; c) El tamao y tipo de informacin manejada. Algunas veces los requerimientos numricos estticos son identificados bajo una seccin separada titulada Capacidades. Los requerimientos numricos dinmicos pueden incluir por ejemplo la cantidad de

70

transacciones, tareas y un tamao de datos a ser procesado dentro de ciertos periodos de tiempo tanto para una operacin normales como para condiciones de carga de trabajo profunda. Todos estos requisitos deberan ser establecidos en trminos medibles. Por ejemplo, 95% de las transacciones deberan ser procesadas en menos de 1 seg., en lugar de Un operador debera no tener que esperar para que una transaccin se complete. NOTA : Los lmites numricos aplicados a una funcin especfica son habitualmente especificados como parte de la descripcin del proceso de tal funcin. 3.3.4 Requerimientos de las bases de datos lgicas Esto debera especificar los requerimientos lgicos para alguna informacin que es puesta dentro de la Base de datos. Esto puede incluir lo siguiente: a) Tipo de informacin usada en varias funciones; b) Frecuencia de uso; c) Capacidades de accesibilidad; d) Entidades de datos y sus relaciones; e) Restricciones de integridad; f) Requerimientos de retencin de datos.(Tiempo que hay que guardar los datos). 3.3.5 Restricciones de diseo. Esto debera especificar las restricciones del diseo que pueden ser impuestas por otros estndares, las limitaciones del hardware, etc., 3.3.5.1 Cumplimiento con estndares Esta subseccin debera especificar los requisitos derivados de los estndares existentes o regulaciones. Ellos pueden incluir lo siguiente: a) Formato del reporte; b) Nombres de los datos; c) Procedimientos de contabilidad; d) Seguimientos de Auditora. Por ejemplo, aqu se podran especificar los requerimientos para el seguimiento de las actividades del proceso del software. Tales seguimientos son necesarios por algunas aplicaciones que alcance regulacin mnima o estndares financieros. Un requerimiento de seguimiento de auditora puede por ejemplo establecer que todos los cambios a la base de datos de nmina de pagos deben ser registrados en un archivo de seguimiento con el valor anterior y el nuevo.

3.3.6 Atributos del sistema software. Hay varios atributos del software que pueden servir como requisitos. Es importante que los atributos requeridos sean especificados para que su logro sea objetivamente verificado.

71

Subclasulas 3.3.6.1 hasta 3.3.6.5 proporcionan una lista parcial de ejemplos. 3.3.6.1 Fiabilidad Esto debera especificar los factores requeridos para establecer la fiabilidad requerida del sistema software al momento de la entrega. 3.3.6.2 Disponibilidad Esto debera especificar que los factores son requeridos para garantizar un nivel de disponibilidad definido para el sistema entero tales como puntos de chequeo, recuperacin y reinicio. 3.3.6.3 Seguridad Esto debera especificar los factores que protegen al software de accesos accidentales o maliciosos, usos, modificaciones, destruccin o improvisacin.. Requerimientos especficos en esta rea podran incluir la necesidad para: a) Utilizar ciertas tcnicas criptogrficas; b) Mantener un Log especficos o un conjunto de datos histricos; c) Asignar ciertas funciones a mdulos diferentes; d) Restricciones de comunicaciones entre algunas reas del programa; e) Datos de chequeo de integridad de variables crticas. 3.3.6.4 Mantenibilidad Aqu se debera especificar atributos de software que relacionan la facilidad de mantenimiento del software en si misma. Puede haber algn requisito para cierta modularidad, interfaces, la complejidad, etc. Estos requerimientos no deberan ser puestos aqu, porque son conceptos de buenas prcticas de diseo. 3.3.6.5 Portabilidad Aqu se deberan especificar atributos de software relacionados con lo fcil de portar del software a otra mquina anfitrin y/o sistema operativo. Esto puede incluir lo siguiente: a) Porcentaje de componentes con cdigo dependiente del host ; b) Porcentaje de cdigo que es dependiente del Host; c) Uso de un lenguaje portable; d) Uso de un particular compilador o subconjunto de lenguajes; e) Uso de un sistema operativo particular.

3.3.7 Organizacin de los requerimientos especficos. Para cualquier sistema trivial, los requerimientos detallados tienden a ser extensos. Por esta razn, es recomendable que se considere cuidadosamente la organizacin dada, para que se haga de una manera ptima para el entendimiento. No hay una organizacin ptima para todos los sistemas, diferentes clases de sistemas se prestan para diferentes organizaciones de requisitos en la seccin 3 de la SRS. Algunas de estas organizaciones se describen desde 3.3.7.1 hasta 3.3.7.7.

72

3.3.7.1 Modo sistema Algunos sistemas se comportan muy diferente dependiendo del modo de operacin. Por ejemplo, un sistema de control puede tener diferentes conjuntos de funciones dependiendo de su modo: entrenamiento, normal o emergencia. Al organizar esta seccin por el modo, se debera utilizar el borrador en A.1 o A.2. Esta eleccin depende de si las interfaces y la performance son dependientes del modo. 3.3.7.2 Clases de usuario Algunos sistemas proveen diferentes conjuntos de funciones para diferentes clases de usuarios. Por ejemplo, un sistema de control de ascensor presenta las capacidades diferentes a los pasajeros, obreros de mantenimiento y bomberos. Al organizar esta seccin por clase del usuario, debera usarse el borrador en A.3. 3.3.7.3 Objetos Los objetos son entidades del mundo real que tienen una contraparte dentro del sistema. Por ejemplo, en un sistema que supervisa pacientes, los objetos incluyen a los pacientes, los sensores, enfermeras, los cuartos, mdicos, las medicinas, etc. Asociado con cada objeto hay un conjunto de atributos (de estos objetos) y funciones (realizadas por ese objeto). Estas funciones tambin se llaman servicios, mtodos o procesos. Al organizar esta seccin por objetos, el borrador en A.4 debera usarse. Ntese que conjuntos de objetos pueden compartir atributos y servicios. stos se agrupan como las clases. 3.3.7.4 Caractersticas Una caracterstica es un servicio deseado externamente de un sistema que puede requerir una secuencia de entradas para efectuar un resultado deseado. Por ejemplo, en un sistema de telfonos, las caractersticas incluyen llamada local, transferencia de llamada y llamada en conferencia. Cada caracterstica se describe generalmente en una secuencia de estmulo respuesta. Cuando se organiza esta seccin por caracterstica se debera utilizar el borrador en A.6. 3.3.7.5 Estmulo Algunos sistemas pueden ser mejor organizados describiendo sus funciones en trmino de estmulos. Por ejemplo, las funciones de un sistema de aterrizaje automtico de un avin, puede ser organizado dentro de secciones : prdida de potencia, el cambio sbito en el destino, la velocidad vertical excesiva, etc. Al organizar esta seccin por estmulo, el borrador en A.6 debera usarse. 3.3.7.6 Respuestas Algunos sistemas pueden organizarse mejor describiendo todas las funciones que ayudan para la generacin de una respuesta. Por ejemplo, pueden organizarse las funciones de un sistema del personal en secciones que corresponden a todas las funciones asociadas con la generacin del pagos, todas las funciones asociadas con la generacin de la lista actual de empleados, etc. Se podra usar el borrador en A.6 (con todas las ocurrencias de estmulo reemplazadas por respuesta). 3.3.7.7 Jerarqua Funcional Cuando ninguno de los esquemas organizacionales anteriores provee ayuda, la funcionalidad global puede organizarse dentro de una jerarqua de funciones organizadas por cualquier entrada comn, salida comn o acceso a datos internos comunes. Los diagramas de Flujo de Datos y diccionarios de datos pueden ser usados para mostrar las relaciones entre las funciones y los datos. Cuando se organiza esta seccin por jerarqua funcional, se podra utilizar el borrador en A.7.

73

3.3.8 Comentarios adicionales Cuando se piensa en una nueva SRS, ms de una tcnica organizacional dada en 3.3.7.7 puede parecer apropiada. En tales casos, organice los requisitos especficos por jerarquas mltiples hacindolo a la medida de las necesidades especficas del sistema bajo especificacin. Por ejemplo, en A.8 se ha combinado la organizacin clases de usuarios y caractersticas. Algunos requerimientos adicionales pueden ser puestos en una seccin separada al final de la SRS. Hay muchas notaciones, mtodos y herramientas de soporte automatizadas disponibles para ayudar en la documentacin de requerimientos. La mayor parte, de su utilidad es una funcin de organizacin. Por ejemplo, mquinas de estado finitas o diagramas de estado pueden ser utiles cuando se organiza por modo; en anlisis orientado a objetos puede proveer ayuda si se organiza por objetos, las secuencias de estmulorespuesta pueden proveer ayuda cuando se organiza por caracterstica y al organizar por la jerarqua funcional, los diagramas de flujo de datos y los diccionarios de datos pueden ser de utilidad. En alguno de los borradores dados desde A.1 hasta de A.8, aquellas secciones llamadas "Requerimientos Funcionales i " pueden ser descriptos en lenguaje nativo (por ejemplo, castellano), en pseudo cdigo, en un lenguaje de definicin de sistema, o en cuatro subdivisiones tituladas: Introduccin, Entradas, Procesamiento, y Salidas. 3.4 Informacin de soporte La informacin de soporte hace a la SRS fcil de usar. Incluye lo siguiente: a) Tabla de contenidos; b) ndices; c) Apndice. 3.4.1 Tabla de contenidos e ndices La tabla de contenidos e ndices son muy importantes y debera seguir las prcticas de composicin general. 3.4.2 Apndices Los apndices no siempre son considerados parte de la SRS actual y no siempre son necesarios. Ellos pueden incluir: a) Ejemplos de formatos de las entradas/salidas, descripciones del anlisis del costo, resultados de intervenciones de los usuarios; b) Informacin de soporte o contextual que puede ayudar a los lectores de la SRS; c) Una descripcin de los problemas a ser resuelto por el software; d) las instrucciones de empaquetamiento especiales para el cdigo y los medios de seguridad a ser alcanzados, exportar, carga inicial u otros requisitos. Cuando los apndices son incluidos, la SRS debera especficamente establecer cuando los apndices son considerados parte de los requerimientos y cuando no.

74

Anexo A
Plantillas de la SRS
A.1 Plantilla de la SRS Seccin 3 organizada por el modo: Versin 1 3. Requisitos especficos 3.1 requisitos de interfaces externas 3.1.1 interfaz con el usuario 3.1.2 interfaces de hardware 3.1.3 interfaces del software 3.1.4 interfaces de comunicaciones 3.2 requisitos funcionales 3.2.1 modo 1 3.2.1.1 requisito funcional 1.1 . . . 3.2.1.n requisito Funcional 1.n 3.2.2 modo 2 . . . 3.2.m Modo m 3.2.m.1 requisito Funcional m.1 . . . 3.2.m.n requisito Funcional m.n 3.3 Requisitos de performance 3.4 Restricciones de diseo 3.5 Atributos de sistema software 3.6 Otros requisitos

A.2Plantilla de la SRS Seccin 3 organizada por modo: Versin 2

3. Requisitos especficos 3.1.Requisitos funcionales 3.1.1 modo 1 3.1.1.1 interfaces externas 3.1.1.1.1 interfaz con el usuario 3.1.1.1.2 interfaces de hardware 3.1.1.1.3 interfaces con el software 3.1.1.1.4 interfaces de comunicaciones 3.1.1.2 requisitos funcionales 3.1.1.2.1 requisito funcional 1 . . 3.1.1.2.n requisito Funcional n 3.1.1.3 Performance 3.1.2 Modo 2 . . . 3.1.m Modo m

75

3.2 Restricciones de diseo 3.3 Atributos de sistema software 3.4 Otros requisitos

A.3 Plantilla de la SRS Seccin 3 organizada por clase de usuario

3. Requisitos especficos 3.1 requisitos de interfaces externas 3.1.1 interfaz con el usuario 3.1.2 interfaces de hardware 3.1.3 interfaces del software 3.1.4 interfaces de comunicaciones 3.2 requisitos funcionales 3.2.1 Clase de usuario 1 3.2.1.1 requisito funcional 1.1 . . . 3.2.1.n requisito Funcional 1.n 3.2.2 Clase de usuario 2 . . . 3.2.m Clase de usuario m 3.2.m.1 requisito Funcional m.1 . . . 3.2.m.n requisito Funcional m.n 3.3 Requisitos de performance 3.4 Restricciones de diseo 3.5 Atributos de sistema software 3.6 Otros requisitos

A.4 Plantilla de la SRS Seccin 3 organizada por objeto

3. Requisitos especficos 3.1 requisitos de interfaces externas 3.1.1 interfaz con el usuario 3.1.2 interfaces de hardware 3.1.3 interfaces del software 3.1.4 interfaces de comunicaciones 3.2 Clases/Objetos 3.2.1 Clase/Objeto 1 3.2.1.1 atributos (directo o heredado) 3.2.1.1.1 atributo 1 . . . 3.2.1.1.n Atributo n 3.2.1.2 funciones (los servicios, los mtodos, directos o heredados) 3.2.1.2.1 requisito funcional 1.1 . .

76

. 3.2.1.2.m requisito Funcional 1.m 3.2.1.3 Mensajes (comunicaciones recibidas o enviadas) 3.2.2 Clase/Objeto 2 . . . 3.2.p Clase/Objeto p 3.3 Requisitos de performance 3.4 Restricciones de diseo 3.5 Atributos del sistema software 3.6 Otros requisitos

A.5 Plantilla de la SRS Seccin 3 organizada por caractersticas

3. Requisitos especficos 3.1 requisitos de interfaces externas 3.1.1 interfaz con el usuario 3.1.2 interfaces de hardware 3.1.3 interfaces del software 3.1.4 interfaces de comunicaciones 3.2 Caractersticas del sistema 3.2.1 Caracterstica 1 3.2.1.1 Introduccin / Propsito de la caracterstica 3.2.1.2 Secuencia de estmulo / Respuesta 3.2.1.3 Requisitos funcionales asociados 3.2.1.3.1 Requisito funcional 1 . . . 3.2.1.3.n Requisito funcional n 3.2.2 Caracterstica del sistema 2 . . . 3.2.m Caracterstica del Sistema m . . . 3.3 Requisitos de performance 3.4 Restricciones de diseo 3.5 Atributos del sistema software 3.6 Otros requisitos

A.6 Plantilla de la SRS Seccin 3 organizada por estmulo

3. Requisitos especficos 3.1 requisitos de interfaces externas 3.1.1 interfaz con el usuario 3.1.2 interfaces de hardware 3.1.3 interfaces del software 3.1.4 interfaces de comunicaciones 3.2 Requisitos funcionales 3.2.1 Estmulo 1

77

3.2.1.1 Requisito funcional 1.1 . . . 3.2.1.n Requisito funcional 1.n 3.2.2 Estmulo 2 . . . 3.2.m Estmulo m 3.2.m.1 Requisito funcional m.1 . . . 3.2.m.n Requisito funcional m.n 3.3 Requisitos de performance 3.4 Restricciones de diseo 3.5 Atributos del sistema software 3.6 Otros requisitos

A.7 Plantilla de la SRS Seccin 3 organizada por jerarqua funcional

3. Requisitos especficos 3.1 requisitos de interfaces externas 3.1.1 interfaz con el usuario 3.1.2 interfaces de hardware 3.1.3 interfaces del software 3.1.4 interfaces de comunicaciones 3.2 Requisitos funcionales 3.2.1 Flujo de informacin 3.2.1.1 Diagrama Flujo de datos 1 3.2.1.1.1 Entidades de datos 3.2.1.1.2 Procesos pertinentes 3.2.1.1.3 Topologa 3.2.1.2 Diagrama Flujo de datos 2 3.2.1.2.1 Entidades de datos 3.2.1.2.2 Procesos pertinentes 3.2.1.2.3 Topologa . . . 3.2.1.n Diagrama Flujo de datos n 3.2.1.n.1 Entidades de Datos 3.2.1.n.2 Procesos Pertinentes 3.2.1.n.3 Topologa 3.2.2 Descripciones de procesos 3.2.2.1 Proceso 1 3.2.2.1.1 Entidades de datos de entrada 3.2.2.1.2 Algoritmo o frmula del proceso 3.2.2.1.3 Entidades de datos afectados 3.2.2.2 Proceso 2 3.2.2.2.1 Entidades de datos de entrada 3.2.2.2.2 Algoritmo o frmula del proceso

78

3.2.2.2.3 Entidades de datos afectados . . . 3.2.2.m Proceso m 3.2.2.m.1 Entidades de datos de Entrada 3.2.2.m.2 Algoritmo o frmula del proceso 3.2.2.m.3 Entidades de datos Afectados 3.2.3 Especificaciones de las construcciones de los datos 3.2.3.1 Construccin 1 3.2.3.1.1 Tipo de registro 3.2.3.1.2 Campos constitutivos 3.2.3.2 Construccin 2 3.2.3.2.1 Tipo de registro 3.2.3.2.2 Campos constitutivos. . . 3.2.3.p Construccin p 3.2.3.p.1 Tipo de Registro 3.2.3.p.2 Campos constitutivos 3.2.4 Diccionario de datos 3.2.4.1 Elemento Dato 1 3.2.4.1.1 Nombre 3.2.4.1.2 Representacin 3.2.4.1.3 Unidad/Formato 3.2.4.1.4 Precisin/Validacin 3.2.4.1.5 Rango 3.2.4.2 Elemento Dato 2 3.2.4.2.1 Nombre 3.2.4.2.2 Representacin 3.2.4.2.3 Unidad/Formato 3.2.4.2.4 Precisin/Validacin 3.2.4.2.5 Rango . . 3.2.4.q Elemento Datos q 3.2.4.q.1 Nombre 3.2.4.q.2 Representacin 3.2.4.q.3 Unidad/Formato 3.2.4.q.4 Precisin/Validacin 3.2.4.q.5 Rango 3.3 Requisitos de desarrollo 3.4 Restricciones de diseo 3.5 Atributos del sistema software 3.6 Otros requisitos

A.8 Plantilla de la Seccin de SRS 3 mostrando mltiples organizaciones

3. Requisitos especficos 3.1 requisitos de interfaces externas 3.1.1 interfaz con el usuario 3.1.2 interfaces de hardware 3.1.3 interfaces del software

79

3.1.4 interfaces de comunicaciones 3.2 Requisitos funcionales 3.2.1 Clase de Usuario 1 3.2.1.1 Caracterstica 1.1 3.2.1.1.1 Introduccin / Propsito de la caracterstica 3.2.1.1.2 secuencia de estmulo /Respuesta 3.2.1.1.3 requisitos funcionales asociados 3.2.1.2 Caracterstica 1.2 3.2.1.2.1 Introduccin / Propsito de la caracterstica 3.2.1.2.2 Secuencia de estmulo/ Respuesta 3.2.1.2.3 Requisitos funcionales asociados . . . 3.2.1.m Caracterstica 1.m 3.2.1.m.1 Introduccin / Propsito de la caracterstica 3.2.1.m.2 Secuencia de estmulo /Respuesta 3.2.1.m.3 Requisitos funcionales Asociados 3.2.2 Clase de usuario 2 . . . 3.2.n Clase de usuario n . . . 3.3 Requisitos de desarrollo 3.4 Restricciones de diseo 3.5 Atributos del sistema software 3.6 Otros requisitos

80

Bibliografa
IEEE, An American National Standard. IEEE Guide to Software Requirements Specifications. ANSI/IEEE Std 830-1984, en Dorfman, M., Thayer, R.H., Standards, Guidelines, and Examples on Systems and Software Requirements Engineering, IEEE Computer Society Press, Los Alamitos, 1990

81