Ingeniería de

requerimientos o
requisitos

Sistemas de
Información

1
Necesidades de Información

Una de las tareas más importantes al momento de comenzar el desarrollo

de sistemas de información es la identificación de las necesidades de
información. Llamaremos así a los discursos que presentan los usuarios y
clientes y que permiten comprender la dimensión del problema.

La actividad de investigación comprende la indagación de los usuarios, la

inspección del entorno organizacional y sus procesos y la observación de
los datos. Estas primeras inquietudes de investigación toman importancia
ya que una adecuada identificación de necesidad de información da lugar
a un correcto análisis y por ende a una construcción correcta.

Diremos que es como plantear los cimientos adecuados para nuestro

trabajo y, por ende, profesionalmente, detenernos en estas primeras etapas
es por demás interesante. Los implicados en esta fase son el analista y los
usuarios, por lo general trabajadores y gerentes de áreas de sistemas de la
empresa cliente (en el caso de existir).

Para comenzar con nuestra inspección encontraremos que tenemos

distintos métodos que nos permiten organizar la información. Estos
métodos establecerán la forma en que se desarrolla la actividad de
investigación y se distinguirán unos de otros del campo de aplicación y de
la problemática a resolver.

A los efectos de la narración que si los conceptos de necesidades de

información y requerimientos de información se utilizarán en forma
indistinta. Es común observar que el concepto de necesidades se asocia a
sistemas de información (manuales o automáticos) y el de requerimientos
al de software.

Al realizar la recopilación de la información se deberá consultar a todos los

usuarios para asegurarse de que todo problema o necesidad esté
identificado. Se deberán evitar trabajos repetitivos, es decir, que varios
analistas le hagan la misma pregunta a un mismo usuario. Para evitar
cometer errores, es conveniente organizarse con los métodos de
recolección de información. Esta estrategia permite identificar todas las
fuentes de las que se obtendrá información, junto con las técnicas para
obtener la información de cada una de ellas (entrevistas, cuestionarios,
etc.). El método de recolección define dónde empezar la búsqueda y cómo
continuarla. También identifica la secuencia en que se examinarán las
fuentes y qué información se obtendrá en cada paso.

FUENTES DE INFORMACIÓN

Hay una gran variedad de fuentes sobre las que se puede realizar la
investigación y la obtención de la información necesaria para el desarrollo
del sistema. Normalmente, cada fuente ofrece información distinta y requiere
un método de búsqueda diferente para conseguirla. Las fuentes de
información más comunes son:

2
  Usuarios del sistema: son generalmente los primeros, ya que
nos proporcionan información sobre las tareas y nos hacen
conocer las necesidades.

 Formularios y documentos: son utilizadas para los diagramas de
flujos de datos y transacciones.

 Programas: son utilizados principalmente para ver estructuras
de datos y procedimientos.

 Manuales de procedimientos: permiten conocer todas las
actividades que realiza el personal dentro de una organización.

 Informes: esta fuente nos sirve para detectar diferentes salidas
en un sistema. Con éstos, no se podrá obtener toda la
información requerida pero sí, la gran mayoría.

MÉTODOS PARA RECOLECCIÓN DE INFORMACIÓN

Método por estímulo o evento.

Iniciaremos el relevamiento a partir de la presencia de un estímulo o evento.

En este contexto denominaremos evento a un hecho ocurrido en el entorno
y que habilita a que el sistema de información responda. Podemos decir
que el sistema se encuentra “dormido” a la espera de eventos y cuando
éstos ocurren se ponen en funcionamiento un conjunto de acciones
preestablecidas. Por ejemplo: Pedidos de los clientes es el estímulo ante el
cual la organización debe reaccionar y generar actividades, documentos,
datos e información. Este método es uno de los más utilizados dentro de la
disciplina informática.

Este método se inicia con el momento en el que se genera un evento y

sigue el camino a través de la organización observando cuáles son los
sectores, áreas, personas, procesos e información involucrados; desde el
inicio hasta el fin. Durante el estudio se deben tener también en cuenta
aquellos eventuales, estímulos internos que se generan como reacción al
estímulo inicial.

El analista deberá iniciar el proceso de recolección de información desde el

estímulo inicial y recorrer las distintas instancias hasta el o los puntos
finales.

Este método no es sólo utilizado para organizaciones formales con

estructuras (u organigramas preestablecidos) sino que puede ser utilizado
en cualquier situación en la que se evalúa la presencia de un hecho externo
que da lugar a las actividades.

3
Los pasos a seguir para concretar este método son:

 Determinar los estímulos a los que el sistema debe responder.

 Listar tanto los estímulos internos como los externos.
 Determinar que secciones o departamentos son afectados.
 Determinar el flujo de información solamente en el camino que
genera el evento.
 Conseguir copias de todos los documentos que se utilizan en los
procesos.
 Conseguir ejemplares de dichos documentos en blanco (se puede
hacer durante la entrevista al personal correspondiente).
 Establecer en primera instancia el flujo principal que genera el
evento y anotar todos los flujos secundarios. No trate de tener toda
la información al mismo tiempo.
 Obtener los datos cuantitativos en lo posible. Estos datos dan una
buena base para el análisis de las excepciones que aparecen (por
ejemplo cuantas devoluciones se realizan por día).
 Una vez que se ha obtenido la información del flujo principal volver
hacia los flujos secundarios.

A modo de ejemplo:

El pedido de un cliente es un evento inicial, que da inicio a las actividades

de: registro de pedido, evaluación del pedido, determinación de existencias
de stock, generación de la factura, actualización de cuenta corriente,
registro de despacho.

A su vez este evento puede dar lugar a eventos internos, como son:
solicitud de reposición de mercadería (ya sea a Compras y proveedores o
a almacenes) y solicitud de evaluación de clientes (cuando se tratan de
clientes en cuenta corriente y se requiere evaluar el límite de crédito u otras
condiciones para habilitar la venta).

El pedido del cliente tendrá varios puntos finales: pedido no cumplimentado

por faltante de stock: avisar al cliente, pedido no cumplimentado por
problemas crediticios: avisar al cliente, pedido entregado, pedido facturado
y registrado en cuenta corriente del cliente.

¿Se comprendió el ejemplo? Espero que sí; ya sabe que si generan dudas,
nos puede consultar sin inconvenientes.

Método por departamento o secciones

Este método parte de la actual estructura de la organización. Es decir que

necesitamos conocer las áreas funcionales de la misma y que se
representan en gráficas como organigramas, planos, descripciones de
procesos.

Se identifica una sección o área y dentro de ella se observan todos los

elementos que den lugar al tratamiento de información, esto es, las
funciones, actividades y documentos que se utilizan. Es muy ventajoso para

4
organizaciones de amplia cobertura (empresas y sucursales) y apropiado
para iniciar actividades de mejora integral en los negocios (o procesos de
reingeniería). Una desventaja del método es que no permite ver los puntos
de contacto y relaciones entre los flujos de información dentro de la
organización.

La aplicación de este método se realiza de la siguiente manera:

 Obtener una descripción de las funciones y límites del sector bajo

 estudio, así como la relación con otros departamentos.

 Obtener una lista de las diferentes funciones y actividades que se

 desarrollan.

 De acuerdo a dicha lista, obtener una descripción de cada actividad,

controles que se realizan, políticas que se aplican y desiciones que
 se toman.

 Observar cada actividad en detalle. Anotar qué información se

necesita y qué información se produce. Si se utilizan registros o
 archivos obtener su descripción y contenido.

 Conseguir copias de todos los documentos que se utilizan en los

 procesos.

 Conseguir ejemplares de dichos documentos en blanco; se puede

hacer durante la observación de las actividades.

Recuerde que hemos analizado ya en la Unidad 1 las organizaciones como

sistemas y por lo tanto tenemos información sobre sus estructuras y la
forma en la que se desarrollan los organigramas. Puede volver a repasar
estos puntos si lo consideras necesario.

Método orientado a las funciones o actividades

Se utiliza para tener en claro que información se necesita para iniciar y/o
realizar determinada actividad. Se utiliza como complemento del método
por departamento o por estímulo.

Método orientado al objeto

Este método se concentra en el estudio de las cosas y servicios que se

producen en una determinada organización o dominio de problema. Se
basa en la detección de los objetos o entidades presentes en el contexto
del problema y en base a estos elementos se observan todas las
actividades e información asociada.

Si observa los elementos que conforman un sistema y que tienen su

explicación en el relato de la Unidad 1 detectará que los sistemas están
compuestos por elementos u objetos. El método orientado al objeto
establece que se determinen los objetos más importantes del sistema bajo

5
 estudio y para él se determinan las necesidades de información o los
requerimientos.

Por ejemplo:

Un sistema de información de clientes tendrá los siguientes objetos y para

ellos se podrán analizar los siguientes elementos de información:

Objeto Información asociada

Clientes Datos personales

Datos de domicilio

Nómina de pedidos realizados

Nómina de pagos pendientes

Nómina de pedidos pendientes de

entrega

Tickets Datos del tickets

Datos del vendedor

Datos de la sucursal

Total de tickets generados por período

Vendedores Datos personales

Datos del puesto de trabajo

(sección,

fecha de ingreso, categoría)

Totales de ventas realizadas

Método de análisis de salidas

Este método se basa en el análisis de los documentos de salida de la

organización. A través de estudiar qué información se procesa y qué datos
conforman las salidas es posible establecer cuáles son los datos necesarios
para que esta información se produzca. Podemos decir que es un método
del estímulo al revés.

6
Por ejemplo:

Documento:

Listado de pedidos pendientes de entrega

Datos:

Datos del cliente+Nro de pedido+fecha de pedido+nombre del

articulo+cantidad pendiente

Esto indica que para poder obtener hay que tener la siguiente información:
datos del pedido realizado por el cliente, datos de existencias de stock.

Selección del método:

El método por estímulo se adapta mejor durante la primera parte de la etapa

de análisis ya que brinda una mejor relación entre los distintos procesos
que conforman el problema. La información se presenta en forma dinámica
y guiada por la presencia de los actores o también llamados elementos
externos.

El método orientado a las actividades es utilizado en pequeñas

organizaciones o procedimientos de menor complejidad. El método
orientado al objeto es un excelente complemento para determinar el
contenido de los registros o archivos de datos.

Estos dos últimos métodos no dan una imagen completa del flujo de
información, por eso se utilizan como complementos del método de
estímulos.

Como consideraciones generales de aplicación de los distintos métodos

que se han estudiado en estos apartados podemos decir que:

 Es importante evaluar los documentos que se encuentran

analizando contenidos, frecuencia de uso, quienes lo usan y para
qué, exceso o carencia de datos, defectos de diseño,
inconsistencias, redundancias.


 Siempre llevar un registro de las respuestas que se encuentran con

respecto al uso de los documentos por parte de los distintos
usuarios, sobre los aspectos de contenido, uso, frecuencia,
realismo.


 Indique la causa de los cuellos de botella, fluctuaciones, sobrecargas

de trabajo, etc.


7
  Trate con el material obtenido de verificar el volumen de los datos.
Si esa información no existe trate de obtenerla durante la
observación.

TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN

Muestreo

El muestreo es el proceso de seleccionar sistemáticamente elementos

representativos de una población. El muestreo ayuda a acelerar el proceso,
recolectando datos seleccionados en vez de todos los datos de la población
completa. (Kendall, pág. 123)

Esta técnica es muy usada en las investigaciones en ciencias sociales en

las cuales la población es muy numerosa pero es posible encontrar grupos
de comportamiento semejante. Por ejemplo: muestreo para realizar
encuestas de consumo de determinados productos o para evaluar el nivel
económico de la población.

Los cuatro pasos que deben seguirse para diseñar una nuestra son:

1. Determinar los datos a ser recolectados: el analista de sistemas

necesita un plan realista sobre lo que hará con los datos una vez
que los recolecte. Las tareas del analista en esta etapa son
identificar las variables, atributos y conceptos de datos asociados
que necesitan ser recolectados en la muestra.

2. Determinación de la población a ser muestreada.

3. Selección del tipo de muestra.

4. Decisión del tamaño de la muestra: el tamaño de la muestra

depende frecuentemente del costo involucrado, el tiempo requerido
por el analista de sistemas o hasta el tiempo disponible por las
personas de la organización. Hay que seguir una serie de pasos,
para decidir el tamaño de la muestra.

La información que buscamos en una investigación que se base en el

muestreo incluye hechos y cifras, información financiera, tipos de
documentos y el contexto organizacional. Los datos relevantes acumulados
en la investigación proporcionan información que no puede ser obtenida por
medio de otros métodos, tales como la entrevista o la observación.

8
Análisis de documentos

Antes de comenzar es importante notar (quizás ya lo haya notado) que en

la traducción de su libro, Kendall le llama “formas” a los documentos o
formularios.

Distinguiremos entre dos tipos de documentos: los documentos

cuantitativos y los documentos cualitativos (Kendall, pág. 128)

Hay una gran variedad de documentos cuantitativos, entre ellos están los
reportes usados para la toma de decisiones, reportes de desempeño y otros
formularios. Estos documentos se caracterizan por poseer información de
base en resultados o números.

Algunos de los tipos de elementos cuantitativos a considerar son:

 Reportes usados para la toma de decisiones: estos documentos son

frecuentemente reportes en papel con relación al estado del
 inventario, las ventas o la producción.

 Reportes de desempeño: la mayoría de los reportes de desempeño

 toman la forma general de desempeño actual contra el programado.

 Registros: los registros proporcionan actualizaciones periódicas de

lo que está sucediendo en el negocio. Si el registro es actualizado
en forma periódica, puede proporcionar mucha información al
analista.

Muchos documentos que circulan dentro de las organizaciones no son

cuantitativos. Aunque los documentos cualitativos tal vez no sigan una
forma predeterminada, el análisis de ellos es crítico para la comprensión de
la manera en que los miembros de la organización se relacionan dentro de
ella.

Cada vez más encontramos sistemas de información que llevan registros

de textos. La capacidad de almacenamiento y el procesamiento de
imágenes han sido un avance tecnológico en pos de esta información.

¿Conoce algún sistema que administre estos tipos de documentos? Por

ejemplo: historias clínicas, presupuestos, calificaciones de estudiantes.

Entre los tipos de documentos cualitativos encontramos:

 Memorándum: estos son documentos formales enviados al interior

 de la organización.

 Papeles sueltos colocados en avisadores a los efectos de

“recordatorios”. Aunque las consignas pueden parecer incidentales
a lo que está sucediendo en la organización, sirve como
 reforzadores de los valores de quienes los leen.

9
  Manuales: los manuales organizacionales, incluyendo los manuales
para los procedimientos y los manuales de usuario del software ya
 existente.

 Manuales de política: establecen políticas acerca de servicios, uso,

acceso y cambios relativos a los procedimientos y luego al sistema
de información. Estos elementos nos brindan información sobre las
 restricciones del sistema a desarrollar.

 En la actualidad el estudio de la información contenida en sitios Web

y en e-mails de trabajo son considerados documentos cualitativos.

Entrevistas

Una entrevista es una conversación dirigida con un propósito específico y

que se basa en el uso de un formato preestablecido de preguntas y
respuestas.

El analista, al utilizar esta técnica de recolección de información no sólo

busca información sino que también busca lograr una empatía con el
entrevistado que redunde en el éxito futuro de la aplicación de software a
desarrollar.

En la entrevista se quiere obtener la opinión del entrevistado y sus

sentimientos acerca del estado actual del sistema, los objetivos de la
organización, los personales y los procedimientos informales. Los hechos
que se obtienen de los datos relevantes pueden explicar el desempeño
deseado. Los sentimientos deseados ayudan a capturar la emoción y las
actitudes.

Los pasos a seguir para la concreción de una entrevista son (Kendall, pág.
90):

 Lectura de material, tanto del entrevistado, como del problema y la

 organización.

 Establecimiento de los objetivos de la entrevista. Use la información

de fondo que recopiló, así como su propia experiencia, para
 establecer los objetivos de la entrevista.

  Decidir a quién entrevistar.

 Contactar la entrevista: organizar en base a los tiempos disponibles

por el entrevistado el momento adecuado de aplicar el instrumento.
 Se establece la fecha, hora, lugar y duración de la entrevista.

 Redactar las preguntas a realizar.

10
Tipos de preguntas (Kendall, pág. 91):

Preguntas abiertas: las preguntas abiertas incluyen aquellas tales como:

¿Qué problemas encuentra Usted en el actual procedimiento de captura de
pedidos por Web? ¿Qué información necesita Ud., como encargado de
ventas; para determinar la eficiencia de un vendedor?

Ventajas:

  Pone confortable al entrevistado.

 Proporciona riqueza de detalles.

 Revela caminos para preguntas posteriores que podrían haber
quedado sin hacer.
 Permite más espontaneidad.

Desventajas:

 El curso de las respuestas puede llevar al desarrollo de respuestas

 de mucho detalle y de poca relevancia para la investigación.

 La posibilidad de perder el control de la entrevista.

  El permitir respuestas que pueden llevar demasiado tiempo.

 Puede llevar a la repregunta por parte del entrevistado colocando al

entrevistador en desventaja o en una posición de desventaja de
conocimiento.

Preguntas cerradas: Son aquellas que poseen la siguiente forma ¿Cuántos

empleados trabajan en la sección de ventas? ¿Cuántos artículos en
promedio conforman un tickets de venta? ¿A qué hora se realiza el
despacho de pedido de los clientes? La respuesta por parte del entrevistado
es un número (incluido el 0).

Ventajas:

 Se ahorra tiempo.
 Se facilita la comparación de entrevistas entre distintas personas.
 Se mantiene control sobre la entrevista.
 Se obtienen datos relevantes.
 No es necesario contar con un entrevistador formado.

11
Desventajas:

 Son aburridas para el entrevistado.

 Impide obtener detalles de procedimientos y de experiencias.
 No se llega a obtener una relación de cordialidad entre el
 entrevistado y el entrevistador.

 Su abuso establece que en vez de realizar una entrevista estamos

realizando una encuesta.

El registro de la entrevista:

Durante el desarrollo de la entrevista se pueden acordar distintos tipos

elementos para llevar el registro de las respuestas. Puede tratarse de
grabaciones aunque el elemento más utilizado es el registro en papel o
directamente en equipos informáticos a través de procesadores de texto
(muchos analista ya se sientan a charlar con su notebook).

Es también y dependiente de la envergadura del proyecto que la actividad

de recolección de información a partir de entrevistas se realice con un grupo
de usuarios y un grupo de analistas.

Cuestionarios

Los cuestionarios son una técnica de recolección de información que

permite que los analistas de sistemas estudien actitudes, creencias,
comportamientos y características de varias personas principales en a
organización que pueden ser afectadas por los sistemas actual y propuesto.
Las actitudes son lo que la gente de la organización dice que quiere, las
creencias son lo que la gente

piensa que es cierto, el comportamiento es lo que hacen los miembros de

la organización y las características son propiedades de las personas o
cosas. (Kendall, pág. 101)

Podrá encontrar el concepto de cuestionario en distintas bibliografías con

distintas valoraciones, una de las más comunes es la confusión con el
concepto de encuesta. Se puede decir en grandes rasgos que estamos
hablando del mismo elemento: una encuesta se refiere a la aplicación de
un documento (llamado cuestionario) a una muestra de población. Por
ejemplo: La encuesta nacional de hogares que realiza el INDEC para
determinar los comportamientos de consumo y los distintos índices de
actividad económica. En el mismo aspecto la aplicación de un cuestionario
sobre la totalidad de la población se denomina censo. Por ejemplo: Censo
de población.

A primera vista los cuestionarios parecen ser una forma rápida para
recolectar grandes cantidades de datos acerca de la manera en que los
usuarios valoran el sistema actual, que problemas están teniendo con su
trabajo y lo que la gente espera de un sistema nuevo o modificado. El

12
desarrollo de un cuestionario lleva un gran tiempo de planeación. El
elemento más importante a considerar en el desarrollo previo del formulario
del cuestionario se centra en determinar cuáles son las variables que se
investigarán y para ellas cuales son los indicadores posibles.

Algunos lineamientos que ayudarán a decidir si es adecuado el uso de

cuestionarios son:

 Las personas a quienes necesitan preguntarles están ampliamente

dispersas.
 En el proyecto de sistemas está involucrado un gran número de
personas.
 Se está haciendo un estudio exploratorio y se quiere medir la opinión
general.
 Se desea asegurar que cualquier problema con el sistema actual
estará identificado.

La principal diferencia entre las preguntas usadas en el cuestionario y las

usadas en la entrevista es que en las entrevistas permiten la interacción en
relación con las preguntas y su significado. En una entrevista el analista
tiene la oportunidad de refinar una pregunta, definir un término dudoso,
cambiar el curso de las preguntas, responder a una apariencia confusa y
por lo general controlar el contexto. Muy poco de esto es posible en los
cuestionarios.

El lenguaje a utilizar en la redacción de los cuestionarios es un aspecto

extremadamente importante para su efectividad, algunas recomendaciones
al respecto son:

 Use el lenguaje del interlocutor siempre que sea posible.

 Trate de ser específico en la redacción.
 Mantenga cortas las preguntas.
 Dirija las preguntas a los interlocutores adecuados.
 Asegúrese de que las preguntas son técnicamente precisas antes de
incluirlas.

Las siguientes son consideraciones de importancia a tener en cuenta para

el diseño de cuestionarios:

 Deje bastante espacio en blanco entre los renglones: para que el

 interlocutor escriba con comodidad dentro del cuestionario.

 Deje suficiente espacio para las respuestas.

 Pida al interlocutor que seleccione las respuestas correctas con un
 círculo.

 Sea consistente con el estilo: utilice la misma forma verbal, el mismo

sujeto (es decir siempre tuteo o siempre considero por Ud.), el
mismo tipo de letra, la misma ubicación para los textos de ayuda.

13
  Orden de las preguntas conforme a los objetivos. Las preguntas
importantes para los interlocutores van primero. Agrupe conceptos
de contenido similar. Ponga primero los conceptos menos
controvertidos.

Observación

Llamaremos observación al proceso por el cual el analista toma contacto

con el comportamiento de los distintos tomadores de decisiones y el
ambiente o contexto donde se desarrolla el problema. (Kendall, pág. 135)

Mediante el uso de observaciones se busca obtener una percepción de lo

que realmente se hace y no sólo de lo que está documentado o explicado.
Mediante la observación del ambiente de la oficina el analista de sistema
busca el significado simbólico del contexto de trabajo de los tomadores de
decisiones. El analista examina los elementos físicos del espacio de trabajo
del tomador de decisiones para ver su influencia sobre el comportamiento
del mismo. Se buscan las actividades, mensajes, relaciones e influencias.

La razón por la que se realiza una observación es para obtener información

acerca de los tomadores y su ambiente, información que muchas veces
resulta inaccesible por otro método. La observación también ayuda a
confirmar, negar o cambiar lo que se ha obtenido por medio de
cuestionarios o entrevistas. La observación debe ser sistemática y
estructurada si es que se quiere que los hallazgos sean interpretables.

Los siguientes pasos ayudan en la observación de las actividades típicas

de tomas de decisiones de un gerente:

 Decidir lo que va a ser observado.

 Decidir a qué nivel de concreción van a ser observada las
actividades.
 Crear categorías que capturen adecuadamente las actividades
principales.
 Preparar escalas, listas de verificación y otros materiales adecuados
para la observación.
 Decidir cuándo observar.

Hay métodos especiales a desarrollar durante la observación:

El muestreo de tiempos, que permite que el analista ponga intervalos

específicos en los cuales observar las actividades de los distintos
empleados, ya sean gerentes, mandos medios u operarios. Las ventajas
incluyen la eliminación de la ascendencia, entre las desventajas
encontramos el problema de que la observación por intervalos de tiempo
incluyen la recolección de datos en pedacitos que tal vez no permite que se
desarrolle completamente un evento.

14
El muestreo por eventos, muestrea un evento completo, esto es,
situaciones completas en las que se observan a los involucrados, por
ejemplo: observando la forma en la que se desarrolla la jornada de atención
al cliente en una mesa de entrada, desde el inicio hasta el final de la misma.

Por último, encontramos diversos aspectos que se tendrán en cuenta

durante la observación:

 Ubicación de la persona en el entorno de trabajo (luz, ventilación,

 ruido).

 Relación con clientes y compañeros de trabajo.

 Trayectos de movimiento que realiza durante la jornada de trabajo.
 Stress laboral.
 Lenguaje corporal, esto es, cómo se muestra y se relaciona con
otros.

Entre los ítems expresados cobra importancia la observación estructurada

del ambiente y el método para la observación estructurada del ambiente es
llamado por Kendall “STROBE”.

Este método es sistemático debido a que proporciona una metodología

estándar para el análisis de los elementos organizacionales que influyen en
la toma de decisiones. Los elementos STROBE y que son fácilmente
observables por un analista de sistemas son:

 Ubicación de la oficina
 Ubicación del escritorio
 Equipo de oficina fijo
 Características físicas del equipamiento (uso, calidad, cantidad)
 Revistas y periódicos del negocio
 Iluminación y color de la oficina
 Vestimenta usada por los tomadores de decisiones.


Usuarios de Información

Los usuarios de los sistemas de información son los participantes más

importantes del desarrollo de los sistemas. Son aquellos para quienes se
construye el sistema. Es la persona a la que tendrá que entrevistar el
analista de sistemas a fin de conocer las características que deberá tener
el nuevo sistema para tener éxito. En resumen, es quién hará uso del
sistema.

15
Requerimientos

Un requerimiento representa básicamente algo que se necesita que el

sistema a desarrollar haga, es decir, aquella funcionalidad o característica
que deberá poseer el sistema para cubrir las necesidades planteadas por
los usuarios. Como hemos visto esta tarea es desarrollada en conjunto
entre analistas y usuarios a los efectos de llegar a comprensiones y
acuerdos sobre el desempeño deseado para el sistema de información.

Un requerimiento es una característica que debe incluirse en el nuevo

sistema y puede consistir en una forma de captar o procesar datos, producir
información, controlar una actividad o dar apoyo a la gerencia.

Las descripciones de los servicios y las restricciones para el sistema son

los requerimientos para el sistema y el proceso de descubrir, analizar,
documentar y verificar estos servicios y restricciones se llama Ingeniería de
Requerimientos. (Sommerville, pág. 98)

En algunos casos, un requerimiento se visualiza como una declaración

abstracta de alto nivel de un servicio que debe proveer el sistema o como
una restricción de éste. Una simple pero muy útil forma de clasificar los
requerimientos es la siguiente: funcionales y no funcionales, lo que ayuda
a definirlos y expresarlos.

La ingeniería de requerimientos:

La Ingeniería de Requerimientos se define como el proceso mediante el

cual se capturan las necesidades del cliente y se desarrolla un modelo de
la solución a esas necesidades. Como resultado de este proceso se
obtendrá un documento que servirá como un contrato entre los clientes y
los desarrolladores, que representará una comprensión entre las partes de
lo que el sistema será capaz de hacer.

Cuando se comienza el desarrollo de proyecto de sistemas, la tarea inicial

se encuentra centrada en la determinación de las necesidades de los
futuros usuarios del sistema en lo relacionado a la administración de la
información en la que se basan para realizar las actividades
organizacionales. Es por ello que en este punto nos centraremos en
estudiar los requerimientos y aquellos conceptos relacionados a la captura
y determinación de los mismos y los aspectos a tener en cuenta para el
desarrollo de la tarea de obtener un documento que refleje la solución
propuesta.

Como vimos anteriormente, la Ingeniería de Requerimientos es el proceso

mediante el cual se extraen los requerimientos, se documentan y verifican,
a través de un documento que permite a desarrolladores y usuarios
comprender lo que hará el sistema.

16
El proceso de ingeniería de requerimientos está comprendido por las
siguientes actividades que se realizan para obtener una comprensión clara
de los requerimientos que serán incluidos en el sistema (extraídas de
Sommerville y colocada aquí sólo a modo de referencia y cierre del tema):

 El Relevamiento de Información. Esta actividad comprende la

obtención de los datos para el sistema y la extracción de los
requerimientos de los usuarios. Esta actividad se basa en la
utilización de una serie de técnicas e implica en primer lugar,
trabajar con los clientes para extraer los requerimientos,
formulando preguntas, haciendo demostraciones de sistemas
similares y hasta desarrollando prototipos de todo o parte del
sistema propuesto


 La Especificación de Requerimientos. Esta tarea se centra en

realizar un análisis de la información relevada y expresar los
requerimientos detectados en forma rigurosa. Se utiliza una
notación formal para describir el sistema a ser construido. Una
ventaja de esto es que se pueden desarrollar herramientas que
sirvan para comprobar la especificación de los requerimientos
en cuanto a su completitud y consistencia y así hacer más fácil
la tarea de rastrearlos y administrarlos.

 La Validación de Requerimientos. La especificación es una
actividad que sirve a dos propósitos. Primero, proporciona una
vía para que los clientes y desarrolladores lleguen a un acuerdo
sobre lo que debe hacer el sistema. Segundo, la especificación

proporciona las pautas para los diseñadores del sistema. Por lo

tanto, antes que los requerimientos sean derivados a los
diseñadores, cada uno tiene que estar absolutamente seguro de
conocer la intención y significados del otro. Los requerimientos
se validan para establecer esta certeza. La validación de los
requerimientos es el proceso por el cual se determina si la
especificación es consistente con la definición de los
requerimientos iniciales, es decir, la validación asegura que los
requerimientos satisfarán las necesidades del cliente.

Requerimientos funcionales y no funcionales

Un requerimiento funcional describe la funcionalidad que se espera que el

sistema provea. Además, los requerimientos funcionales describen cómo
debe comportarse el sistema ante determinado estímulo y cómo
interacciona ante el ambiente. Un requerimiento funcional describe lo que
el sistema hará sin definición de aspectos referidos a cómo será
implementado. Por ejemplo: registrar el pedido del cliente.

Un requerimiento no funcional impone restricciones al sistema que limita la

forma en que será implementado. Estas restricciones tienen que ver por
ejemplo con la selección del lenguaje de programación, la plataforma o

17
técnicas y herramientas de implementación a utilizar. Una cosa a tener en
cuenta es que estos requerimientos se utilizan en la etapa de diseño del
sistema, donde se define el modelo físico del sistema, después de haber
especificado los requerimientos, pero es necesaria su identificación en este
momento. Por ejemplo: el sistema deberá ser desarrollado en lenguaje
Java.

Tanto los requerimientos funcionales como los no funcionales son

obtenidos del cliente de manera formal y detallada.

El Documento de Especificación de Requerimientos de Software.

El proceso de especificación de los requerimientos es un proceso iterativo

y con retroalimentación continua entre el personal que realiza el desarrollo
y los usuarios, lo que permite ir introduciendo los cambios producidos en
los requerimientos del cliente a lo largo de desarrollo del proyecto.

La tarea fundamental que se define para este proceso es la de realizar un

análisis de los requerimientos detectados y la creación de los modelos
necesarios que representen la solución del software, que tiene en cuenta
esos requerimientos. La solución presentada es una solución lógica o
teórica, libre de cualquier aspecto referido a cómo se implementará el
sistema.

Como resultado del desarrollo de este proceso se obtiene el documento de

Especificación de Requerimientos de Software (ERS) que expresa los
requerimientos funcionales detectados a través de los modelos que dan
solución a los mismos.

Para la creación del ERS, un analista cuenta con una serie de herramientas
que le permiten describir la funcionalidad que tendrá el sistema, que será
utilizado no sólo para que el cliente pueda entender los procesos que
realizará el sistema sino también para comunicar a los diseñadores del
sistema, cuáles son los procesos que éste debe hacer, para que los mismos
traduzcan esa solución hacia una definición comprensible por los
desarrolladores del sistema.

Este documento constituye una declaración oficial de qué es lo que el

sistema debe hacer para satisfacer los requerimientos identificados. Incluye
tanto los requerimientos funcionales como no funcionales definidos en el
sistema.

El ERS tiene varios destinatarios; desde los administradores principales de

la organización, quienes pagan por el sistema, hasta los ingenieros
responsables del software. (Sommerville, pág. 115)

18
Sommerville define que existen seis requisitos que un ERS debe
satisfacer:

 Especificará únicamente el comportamiento externo del sistema.



 Especificará las restricciones de la implementación.



 Será fácil de cambiar.


 Servirá como herramienta de referencia para los mantenedores
del sistema.

 Registrará las previsiones del ciclo de vida del sistema.

 Caracterizará las respuestas aceptables para los eventos no
deseados.

Existen gran cantidad de estándares definiendo el contenido del ERS,

encontrará información en sitios Web sobre todo el del Institute of Electrical
and Electronics Engineers (IEEE).

La información que se incluya en un documento de especificación de

requerimientos debe depender del tipo de software a desarrollar y del
enfoque de desarrollo que se utilice y esto lo decide el equipo de desarrollo
junto con los clientes.

Para concluir con esta temática es importante notar se continuará

trabajando el libro de Ingeniería de Software de Sommerville en otras
materias y conforma parte de la bibliografía central de la disciplina
disponible en la actualidad.

Los sistemas de información

En general estamos rodeados de sistemas de información en todos los
ámbitos en los que comúnmente nos situamos. Es decir, arquitecturas
predeterminadas y formalmente establecidas sobre las cuales transita la
información.

Los sistemas con los que nos topamos son de distintos tipos, algunos
funcionan bien y nos llaman la atención; otros de forma deficiente y con
nuestros ojos de “informáticos” nos llaman más la atención. Por ejemplo,
hablamos por teléfono reclamando que determinado servicio nos ha sido
mal facturado y encontramos una voz simpática que nos dice: “estamos sin
sistemas”. ¿Le pasó? Me imagino que sí.

¿O cuántas otras veces nos encontramos con reclamos por pagos de

servicios que abonamos a término?

19
Hace unos días recibí un mensaje en mi teléfono fijo en el que se avisaba
de una deuda impaga con una empresa de teléfonos, que de no ser
regularizada implicaría mi colocación en los registros de morosos de
accesos públicos (sin dar nombres todos nos situamos en contexto).
Averiguando, descubro que se trataba de una deuda de centavos de un
teléfono dado de baja. Pensé en el trámite realizado y todas facturas que
llegaron con el mensaje “Ud. no tiene deuda”. Este mensaje de deuda llegó
6 años de luego de finalizado el servicio.

¿Cuántas otras veces nos encontramos con procedimientos administrativos

que se sostienen en sistemas de información que funcionan mal? o
¿cuántas veces procedimientos administrativos se tornan más ineficientes
cuando se piensa mejorarlos con la incursión de sistemas informáticos y la
organización toda se torna más burocrática y lenta? Seguramente tiene en
la memoria muchos ejemplos y de no ser así, le aseguro que a partir de
estas lecturas y luego del ejercicio de la profesión misma, se mostrará
mucho más atento a sus “apariciones”.

En la Unidad 1 estudiamos los conceptos asociados a la teoría general de

sistemas y la importancia que este paradigma tiene para la resolución de
problemas en distintos ámbitos de la ciencia.

Así es que los sistemas de información se pueden definir simplemente

como sistemas que tienen por objetivo brindar información para apoyar la
toma de decisiones. Teniendo en mente esta definición de sistemas no nos
será complicado completarla, para definir estos sistemas de información.

Saroka lo define como “un conjunto de recursos organizados para brindar y

a quienes operan y toman decisiones en las organizaciones la información
necesaria para el desarrollo de sus respectivas funciones” (Saroka, 2002,
Pág.33).

Stair y Reynolds lo definen como “un tipo especializado de sistema,

conjunto de elementos interrelacionados para recolectar, manipular y
diseminar datos e información y para proveer un mecanismo de
retroalimentación en pro del cumplimiento de un objetivo” (Stair, 2000,
Pág. 15).

Ahora repasemos esta definición en función de los elementos necesarios

para definir un sistema: Objetivos, Ambiente, Recursos, Alcances o
Actividades.

Objetivo de un sistema de información:

Brindar información que permita una adecuada toma de decisiones.

Permitir que los individuos (u organizaciones) incrementen el
conocimiento que poseen de una cosa.

20
Ambiente de un sistema de información:

Son aquellos que, situados fuera del sistema de información, influyen en

la determinación de sus objetivos. Es por tanto que serán ambiente los
clientes (aquellos que contratan el desarrollo del sistema y por tanto
determinan sus objetivos), los usuarios (a partir de que indican sus
requerimientos), los otros sistemas de información con los que interactúa
(ya sea entregando o compartiendo datos), los procesos del negocio (ya
que fijan procedimientos, controles y políticas a cumplir), los organismos
gubernamentales y otros organismos de control que fijarán distintas
restricciones sobre el funcionamiento del sistema de información.

Actividades de un sistema de información:

Son todas aquellas acciones que realiza el sistema para dar cumplimiento
al objetivo previsto. En el caso particular de los sistemas de información
nos referimos a todas aquellas actividades relacionadas con la captura y
validación de los datos de entrada, el procesamiento especial de los
mismos y las actividades propias de exponer o mostrar la información.

En el texto de Saroka lo vas a encontrar en la página 39 con el nombre de

Funciones del Sistema de información. La claridad de este texto me lleva a
no agregar ningún nuevo comentario.

Recursos de un sistema de información:

Son los elementos con los que el sistema cuenta para llevar adelante el
procesamiento de los datos.

Hablamos entonces de:

  Recursos tecnológicos: Hardware, software, comunicaciones.

 Recursos Humanos: encargados del ingreso de los datos (data

entry), del procesamiento de los datos (en el caso de sistema de
procesamiento manual), del personal de atención a clientes o
usuarios (encargado de mesa de ayudan de atención al cliente, de
mesa de entrada, entre otros) y especialmente de los recursos
especializados encargados de la producción del sistema de
información (analistas de sistemas, diseñadores, especialista en
arquitectura y comunicaciones, analista de testing, programadores,
líderes de proyectos, implementadores, analistas de procesos de
 negocio).

 Recursos Económicos y Financieros: capital necesario para llevar

adelante el desarrollo y el mantenimiento en funcionamiento del
 sistema.

21
  Recursos de insumos: material de oficina, papel, elementos de
 respaldo de información.

 Recursos de infraestructura: el espacio edilicio y la adecuación de

los mismos para el desempeño del sistema de información. Si
hicieran falta espacios propios para el área de sistemas (antes
llamados centro de cómputos) aquí tendríamos que
 determinarlos.

 Recursos logísticos: los procesos de negocio y los procedimientos

administrativos a los que el sistema da soporte. Aquí se
consideran las políticas, normas y controles del negocio.

Clasificación e integración de sistemas de información

Al igual que otros sistemas, al hablar de sistemas de información también

nos vamos a referir a una jerarquía de sistemas y por tanto
encontraremos un conjunto de sistemas de información que muchas
veces se presentarán integrados y otras no. Estas clasificaciones de
sistemas de información se exponen en la Unidad 3.

En los casos en los que encontramos sistemas de información integrados

podemos decir que estamos en presencia de organizaciones ya maduras
en referencia al uso de la tecnología de la información, con usuarios
expertos y con una gerencia corporativa que comprende lo central del
recurso de la información para la estrategia del negocio. En estos casos
las bases de datos se encuentran unificadas y accesibles desde distintas
aplicaciones.

Sistemas de información manuales y automáticos

Es importante distinguir que podemos contar con sistemas de información

manuales y otros automáticos. Estos últimos son los que poseen para
nosotros mayor importancia ya que conforman nuestro objeto de trabajo
profesional. No obstante, un sistema de información no requiere
necesariamente el uso de tecnología de computación (Saroka, pág. 33).
Podemos encontrar ejemplos en sistemas de registro de historias clínicas
en pequeños hospitales o consultorios privados, sistemas de información
manuales en estudios contables o en escuelas.

Un elemento a considerar es que la presencia de computadoras no

garantiza la existencia de sistemas de información. Si la computadora se
utiliza como procesador de texto, como planilla de cálculo y como resguardo
de información y dispositivo de rápido acceso a documentos estamos en
presencia de sistemas de información manuales. Nos referimos a sistemas
automáticos (o sistemas informáticos) cuando el procesamiento de los
datos es realizado por la computadora y mediante un software
especialmente asociado.

Los sistemas de información manuales, por ejemplo, son aquellos en los

que los tomadores de decisiones realizan gráficos con datos extraídos

22
de planillas de cálculo y con ellos establecen pronósticos o realizan
sumas con calculadoras o planillas de cálculo para determinar los totales
de ventas y el flujo de dinero en caja.

Los sistemas de informáticos han incrementado su presencia en distintos

tipos de organizaciones debido al costo cada vez menor de la tecnología
de hardware y al desarrollo de software cada vez más industrializado.
Muchos sistemas han sido manuales y ahora son automáticos (la gran
mayoría), se puede analizar el ejemplo que figura en Stair y Reynolds en
la página 17. Actualmente los avances en la tecnología y la necesidad de
las organizaciones de administrar la información en forma eficiente, ha
llevado a la industria del software a tener que producir software en forma
más eficiente y veloz, a la vez de reducir los costos insumidos en ese
proceso.

El desarrollo de sistemas de información y del software asociado son

nuestros objetos de desarrollo profesional y es por ello que damos un
repaso a las actividades más importantes que implica la producción de
sistemas de información.

Desarrollo de Sistemas de información

El desarrollo de software es la actividad destinada crear sistemas de

información. Las estrategias

que se utilizan a tales efectos se denominan metodologías y agrupan un

conjunto de actividades, herramientas y modelos.

La utilización por parte de los equipos de desarrollo de sistemas de

información de técnicas ingenieriles para la producción de sistemas de
información ha permitido que los resultados sean cada vez mejores,
logrando producir productos de calidad, que acompañan los intereses de
los clientes y que a su vez se entregan en los plazos acordados. En
general estamos hablando de métodos divulgados ampliamente,
difundidos en los ciclos académicos de las universidades y
estandarizados por la industria. Esto lleva a que los equipos de trabajo
también se consoliden y por ende se aumente la productividad.

Los procesos de desarrollo de sistemas de información pueden ser

distintos, organizando las actividades que en él se realizan de manera
diferente; pero existe un conjunto de actividades comunes a todos ellos y
que, efectivamente, deben ser llevadas a cabo para la obtención del
producto final.

En aspectos generales, podemos decir que las etapas por las que pasa
la producción de sistemas de información son las siguientes (Stair, 29)

 Investigación de sistemas. Es el momento inicial en el que se

toma contacto con la problemática del entorno del cliente y se
describen los aspectos generales de las necesidades que el
 sistema de cubrir.

23
  Análisis. Son las instancias en las que se elaboran los modelos
que resuelven las necesidades de información detectadas en la
investigación, estableciendo quizás diversas soluciones.

 Diseño. Nos referimos a la selección de una solución y la
determinación del entorno físico concreto con el que se
construirá.

 Implementación. Esta actividad se refiere a la construcción
propiamente dicha, agrupa las instancias de compras y
contratación de servicios de terceros de hacer falta. Incluye las
pruebas intermedias del producto, las finales, la capacitación del
usuario y la instalación propiamente dicha.

 Mantenimiento. Son aquellas acciones en las que se realizan
monitoreos sobre el sistema desarrollado a los efectos de
observar si es necesario realizar alguna mejora.

Es importante notar que la descripción arriba expuesta puede ser

desagregada en más cantidad de pasos según los autores, pero hemos
decidido seguir la nomenclatura que establece Stair y Reynolds a estos
efectos.

Ahora bien, en el entorno del desarrollo de sistemas de información y en

vista de la existencia cada vez más predominante de sistemas
informáticos en los cuáles el software es uno de los recursos de mayor
valor; la disciplina informática persigue el desarrollo de métodos cada vez
más robustos para la producción de este elemento. Es así que
avanzamos en los puntos siguientes en los conceptos de ingeniería de
software.

La ingeniería del software:

La Ingeniería de Software es la disciplina que permite el desarrollo de

software en forma ordenada, brindando métodos y técnicas rigurosas que
hacen del proceso de desarrollo un recorrido organizado y controlado,
permitiendo así producir software que acerca cada vez más a las
necesidades de las organizaciones.

La necesidad de administrar la información producida en las

organizaciones, las exigencias de éstas en medir los costos y conocer su
eficiencia ha hecho que los desarrolladores deban organizar mejor todo el
proceso de producción de software. Por otro lado, el avance vertiginoso que
ha tenido en los últimos años la tecnología de las computadoras, ha
permitido mejorar cada vez más este proceso, acompañándolo con un
avance importante en las técnicas y herramientas utilizadas.

Un proyecto de software tiene un objetivo claro y está formado por un

conjunto de tareas, que basado en determinados requerimientos de
entrada, permitirán como salida la obtención de un producto que satisfaga
las necesidades planteadas por los usuarios. Este proyecto permite que el

24
proceso de producción del software se desarrolle de forma planificada y
organizada, permitiendo realizar el control de avance de las tareas
efectuadas y poder así realizar los ajustes necesarios.

Al llevar a cabo el desarrollo de un proyecto de software, es necesario

contar con una organización de las actividades a realizar, a través de un
proceso que provea a los desarrolladores de métodos, herramientas y
técnicas confiables y efectivas que se adecuen al tipo de software a
desarrollar y a los problemas que se pretenden resolver y que permita
obtener como resultado un producto basado en las necesidades a
satisfacer.

Durante el proceso de desarrollo, se van efectuando cada una de las

actividades previstas siguiendo un determinado procedimiento y se van
obteniendo una serie de resultados que permiten continuar con la siguiente
actividad hasta completar el producto final.

Participantes en el desarrollo de software

 Clientes o Administradores: son los patrocinadores del proyecto,

proveen los recursos necesarios para el desarrollo del proyecto
 de sistemas. Pueden ser:

 Desarrolladores: es la organización encargada de construir el

sistema ejecutando todas las actividades en el proceso de
desarrollo. Los roles que existen dentro de un equipo de
desarrollo, que realizarán todas las tareas tendientes a la
 producción del sistema, son los siguientes:

 Líder del Proyecto: encargado de realizar la planificación del

proyecto, realizar las estimaciones, proveer los recursos,
asignar tareas y coordinar todas las actividades en el desarrollo
 del proyecto, realizando el control de avance del mismo.

 Analista de sistemas: encargados de detectar los problemas y

requerimientos de los usuarios y crean un modelo lógico para la
construcción del sistema. Dentro de este rol podemos definir a
su vez, dos nuevos roles que han surgido en base a las
 necesidades actuales de los equipos de desarrollo.

 Analista de Procesos: su rol se relaciona con realizar la

comprensión de la estructura y dinámica de la organización bajo
estudio, la detección de problemas reales en los procesos del
negocio y proponer mejoras y, construir especificaciones que
servirán como un entendimiento común de los procesos
organizacionales entre clientes, usuarios finales y
 desarrolladores.

 Analista Funcional: es el encargado de la determinación de los

requerimientos de información necesarios para la concreción de
un producto de software, solución a los problemas planteados
por los clientes y usuarios. Además, desarrollará la

25
 Especificación de Requerimientos de Software (ERS) que es el
documento en el que se detallan los requerimientos funcionales
del sistema, y que servirá de contrato entre el cliente y los
 desarrolladores.

 Diseñador: son los encargados de tomar el modelo libre de

consideraciones tecnológicas creado por el analista y traducirlo
en un modelo físico de sistema, con todas las consideraciones
necesarias de tecnología, que será entregado a los
programadores para su construcción.
 Programador: son los que realizan la construcción del sistema a
partir de la codificación del mismo, en el lenguaje de
programación definido para el proyecto a partir del trabajo
 realizado por el diseñador.

 Personal de Prueba: son los encargados de realizar las pruebas

sobre los artefactos generados en el desarrollo de software,
verificando que cumplan con los requerimientos planteados por
 el usuario.

 Entrenador: capacitan a los usuarios en el uso del sistema,

permitiendo resolver todas las inquietudes que pudieran surgir,
una vez instalado el sistema.

Para finalizar: Aplicando los conceptos en la práctica

Presentamos un caso práctico completo en el que se muestran los distintos
aspectos abordados en la bibliografía de esta unidad. Los aspectos
prácticos no siempre son realmente dimensionados en estas lecturas y es
por tanto necesario el refuerzo de actividades concretas en el que se
muestra el quehacer. A medida que se avanza en la resolución iremos
exponiendo algunos aspectos de la teoría importantes de remarcar.

En este caso, trabajamos los aspectos iniciales que se abordan al definir el

sistema de información, que se asocia al proceso de administración de
préstamos de libros en una biblioteca. La situación puede aplicarse de la
misma forma a otros entornos de negocio semejantes: videos club, alquiler
de canchas, etc.

Situación:

Se trata del proceso que se sigue en una biblioteca para la administración

de los socios en una biblioteca. Cuando un socio solicita un libro entrega su
carnet de socio. Éste debe ser controlado para verificar que realmente
pertenece al padrón de socios, que posea paga la última cuota y que no
adeude libros. Luego se verifica si el o los libros requeridos se encuentran
disponibles. Para ello se consulta un catálogo en el que figuran todos los
libros que existen en la biblioteca, ordenados por su código. En este
catálogo figuran los datos del libro así como también los datos del préstamo.
De cada libro pueden existir varios ejemplares.

26
Si el socio no adeuda libros se le entregaran los libros solicitados, se
registran los datos en la ficha de socio, así como también en el catálogo de
libros.

Si el socio adeuda cuotas y las paga, éstas se cobran con un interés

mensual del 1%. Se registra el pago de socio y se entrega un recibo del
pago.

Cuando el socio devuelve los libros, éstos se registran en la ficha de socio

y se actualiza el catálogo de libros.

Las personas pueden solicitar asociarse a la biblioteca abonando una

inscripción y entregando sus datos y comprobantes que avalan su domicilio
(por ejemplo, un impuesto o servicio a su nombre).

Dado que se han encontrado dificultades para mantener al día la

información por la gran afluencia de socios y la creciente cantidad de
ejemplares en pérdida se decide contratar el desarrollo de un sistema de
información que resuelva los problemas administrativos y además agregue
el nuevo servicio de entorno Web para consulta de catálogos y reserva de
libros (en primera instancia).

Procesos de negocio:

Como dijimos los sistemas de información se insertan en entornos

organizacionales donde se encuentran demandas o necesidades de
información. Estas demandas surgen de procesos o actividades (sistema-
objeto, según Saroka) o sistema organizacional en el que se desarrolla la
organización.

En este caso se trata de las siguientes actividades:

1- Aceptar nuevos socios.

2- Recibir pagos.

3- Realizar Préstamos.

4- Recibir devoluciones.

5- Realizar reservas.

Fíjese que se trata de actividades realizadas por recursos humanos dentro

de la organización (en este caso el bibliotecario) y que implican objetos
concretos (libros, dinero, socios, carnet).

27
Nombre del sistema de información: Administración de préstamos en
una biblioteca.

Cuando exponemos el nombre lo hacemos para poder identificarlo de otros

sistemas de información que se encuentren en la organización. Es común
colocar nombres de fantasía también en estos sistemas: Araucano. Tango
Gestión. Info Leg.

Objetivos del sistema de información: Apoyar las actividades

administrativas de una biblioteca aportando información de socios,
préstamos, devoluciones, reservas, pagos de socios y existencias de
ejemplares.

Ambiente:

Usuarios:

Los socios que desde sus hogares realizan las reservas y consultas de
catálogos. Los empleados que consultan catálogos y existencias.

Los empleados que registran préstamos y Devoluciones. Los empleados

que registran Pagos.

Los empleados supervisores que controlan el desarrollo general de las

actividades.

Otro elemento importante del ambiente es la base de datos de catálogo de

libros: importante considerar que los límites establecidos por el objetivo que
posee el sistema de información no contempla el registro de nuevos
ejemplares ni la gestión de compra. Estos datos centrales para el desarrollo
del sistema provienen del ambiente. ¿Se comprende? Recuerde de la
unidad anterior los aspectos asociados a “empujar los límites” en los casos
en los que el problema lo requiere.

Recursos:

Estamos pensando en un sistema informático con un servidor Web, con

terminales para consulta de los socios en la biblioteca, con puestos de
trabajo para los empleados y acceso a información para supervisores por
Intranet. Los recursos humanos están compuestos por el equipo de
analistas y desarrolladores involucrados en el proyecto.

28
Investigando hemos descubierto las siguiente Políticas de la Biblioteca:

 Las altas de los socios son sólo en la biblioteca.

 Las reservas se “caen” si el libro no se retira en 48hs.
 Se pueden reservar libros que se encuentran prestados.
 No se prestan libros a aquellos socios que adeuden cuotas.
 Los socios que adeudan cuotas pueden reservar libros.
 Sólo se prestan libros a socios.
 La cantidad de días de préstamo depende del tipo de libro.

¿Quién nos da esta información? Los distintos interlocutores: bibliotecarios,

supervisores, el director de la biblioteca.

¿Para qué nos sirve esta información? Para diseñar nuestro sistema de
información. Muchas tienen que ver con las decisiones programadas,
¿puede reconocerlas? Sí, el momento en el que una reserva realizada se
vence, por ejemplo.

Necesidades de Información:

También del desarrollo de las entrevistas encontramos las necesidades de

información que luego se traducen en requerimientos para el sistema de
información a desarrollar:

 Del bibliotecario: información de existencias, de reservas previas,

de préstamos, de socios, de pagos.
 Del encargado de cobranza: información de socios, de pagos
previos.
 Del encargado de reclamos: información de préstamos, de
devoluciones.
 Del socio: información de catálogos, de préstamos, de pagos, de
 reservas.

 Supervisores: información general de la operatoria de la

organización: cantidad de préstamos, comparativos de períodos
anteriores, cantidad de préstamos pendientes.

Requerimientos de información:

El sistema debe permitir:

 Registrar socios
 Registrar préstamos
 Registrar devoluciones
 Registrar pagos
 Registrar reservas para socios habilitados
 Cancelar reservas
 Consultar catálogo
 Consultar pagos
 Consultar préstamos

29
  Emitir lista de devoluciones pendientes
 Emitir lista de libros más solicitados
 Emitir lista de libros solicitados por socio

Además, el sistema debe permitir:

 La consulta de catálogo por Web para todos los navegantes.

 La consulta de índices, comentarios y resúmenes para socios.
 La reserva puede realizarse vía Web.
 La existencia de un sitio que funcione en cualquier navegador.
 Actualización en línea de las existencias de libros.

¿Puedes distinguir de estas listas requerimientos funcionales de no

funcionales?

La actualización en línea es un requerimiento no funcional asocia a la

perfomance del sistema; el registro de préstamos y devoluciones es un
requerimiento funcional.

Como los distinguimos, los no funcionales se asocian a elementos del

entorno como son el tipo de usuarios que pueden acceder, los permisos, la
seguridad, la forma, las apariencias, la velocidad, en general, aspectos que
podrían dejarse de lado sin que por ello el sistema dejará de funcionar.
Funcionaría de forma no eficiente. Los primeros, los funcionales, hacen al
cuerpo del sistema.

Actividades:

También llamados alcances, son las acciones que se realizan en el sistema

de información con el propósito de brindar las salidas de información
determinadas por los distintos niveles de usuarios.

Nos representan las acciones a realizar y salen directamente de la lista de

requerimientos y luego se completan con mayor nivel de detalle, por
ejemplo:

 Modificar datos de los socios.

 Dar de baja socios.
 Anular reservas en forma automática.
 Registrar solicitud de anulación de reserva.
 Registrar usuarios (con clave y acceso para Web).

Y agregando aquellos que surgen de la lista de requerimientos.

30
 Entradas

Los datos que ingresan al sistema de información a los efectos de que se

realicen cada una de las actividades, algunas son:

Nombre Descripción

Solicitud de reserva Nº de socio + nº libro + fecha reserva

Solicitud de préstamo Nº de socio + nº libro + fecha

Solicitud de nuevo socio DNI + apellido + domicilio + email + te

Salidas

Algunas de las que se presentan son las siguientes:

Nombre Descripción
Préstamos Nº de socio + nº libro + fecha préstamo +
fecha devolución
Libros disponibles Nº de libro + ubicación + cantidad de
ejemplares
Lista de Socios Nº de socio + DNI + apellido + fecha
ingreso
Reservas Nº de socio + nº libro +
fecha finaliza reserva + fecha reserva
Devolución Nº socio + fecha de préstamo + fecha
de devolución real + fecha de devolución
prevista

31
Ranking de libros más solicitados Nombre del libro + temática del libro +

número de veces que se ha retirado el

libro.

Especificación de requerimientos

A modo de ejemplo se expone la forma en la que se expresan los

requerimientos del sistema de información; encontrará distintos formatos,
pero en especial todos coinciden en expresar con claridad y sin
ambigüedades las acciones que el sistema realiza y los datos que ingresan
y salen del proceso.

Nombre: Registrar socios

Entrada: Solicitud de Nuevo Socio

Salida: Nuevo socio en registro de socios

Descripción:

 Tomar los datos del Socio.

 Verificar si el socio ya existe en la base de datos.
 Si no existe, registrar los datos nuevos.
 Si existe, solicitar si se desea modificar los datos
antiguos.
 Si se modifican mostrar los datos y aceptar los
cambios.
 Imprimir un comprobante para el socio con el nro. de
socio asignado.

Nombre: Registrar Reserva en Biblioteca

Entrada: Solicitud de Reservas

Salida: Reserva aceptada

Descripción:

 Tomar los datos del socio y del libro

 Verificar que la persona sea socio de la biblioteca
 Si no, dar la posibilidad de dársele de alta.
 Verificar que el libro esté en existencia.
 Si el ejemplar solicitado esta en préstamo, registrar la
reserva.

32
  Si el ejemplar está disponible informarlo y si se desea
reservarlo.
 Registrar fecha de vigencia de la reserva.
 Imprimir comprobante para el socio con los datos de
la reserva y la fecha de vencimiento de la reserva.

Nombre: Registrar devolución

Entrada: Devolución

Salida: Registro de la devolución

Descripción:

 Tomar datos de la devolución del libro

 Verificar los datos
 Mostrar los datos del préstamo
 Registrar la devolución.
 Mostrar la fecha prevista de devolución
 Mostrar los días de retraso si existiera (el sistema
puede prever luego sanciones o multas)
 Actualizar el catálogo de libros.


A modo de conclusión y sólo a los efectos de una presentación general se
muestra la forma que tendrá un documento de especificación de
requerimientos para este sistema. Este documento tiene dos partes
centrales: una primera que nos muestra el objetivo del documento en sí, o
sea, para qué y quién está realizado y una segunda parte en la que se
expresa el producto de software. En este momento se exponen dentro del
documento aquellos aspectos que hemos visto en los puntos anteriores.

Por último, todo nuestro trabajo se organiza en un documento que será

utilizado por distintas personas ya sean clientes o los programadores y
desarrolladores, este documento agrupa y ordena toda la información que
hemos analizado y se denomina Documento de Especificación de
Requerimientos. A continuación, le presentamos una estructura y la forma
general en la que se completa.

Documento de Especificación de Requerimientos (ERS)

1) Introducción

1.1) Objetivo. Mostrar la funcionalidad del Sistema de Información de

Biblioteca, con toda la información necesaria para comprender la
forma en la que se desarrollan las transacciones en el negocio y se
reflejan en el sistema de información.

1.2) Audiencia. Este documento ha sido realizado por el Analista de

Sistemas del proyecto y esta destinado a los usuarios finales y a la
administración de la biblioteca. Está dirigido también al equipo de

33
 desarrollo que llevará a cabo la construcción e implementación del
sistema.

1.3) Alcances. El presente documento cuenta con:

 Una lista de requerimientos funcionales

 Una lista de requerimientos no funcionales
 Un listado de los usuarios del sistema
 Una descripción de los requerimientos funcionales
 El diseño de los prototipos (Nota: vista de cómo serán las vistas
preliminares que el software tendrá para los usuarios).

2) Presentación del Producto:

2.1) Propósito del sistema: Apoyar las actividades administrativas de una

biblioteca aportando información de socios, préstamos, devoluciones,
reservas, pagos de socios y existencias de ejemplares.

2.2) Alcances: Registrar todos los préstamos, reservas y devoluciones.

Administrar los datos de los socios. Informar datos de los libros.

2.3) Restricciones:

 Sólo los socios retiran libros.

 Los socios tienen restricciones para retirar libres en función de su
estado de sanciones.
 El sistema debe permitir accesos Web para socios y público en
general.

3) Descripción general del producto:

3.1) Lista de requerimientos:

Aquí colocar la lista elaborada anteriormente.

3.2) Lista de usuarios:

Aquí colocar la lista elaborada anteriormente.

3.3) Descripción de los requerimientos:

Aquí colocar la especificación de los requerimientos realizada con

anterioridad.

Hemos llegado así al final de la lectura de la Unidad 2. Espero que el

repaso, además de reafirmar y organizar aspectos de la bibliografía, haya
permitido introducir nuevos interrogantes a nuestra tarea de análisis,
permitiendo avanzar en el conocimiento.

34
Referencias

Stair, R & Reynolds, G. (2010). Principios de sistemas de información: un enfoque

administrativo. (9a. Ed.) [Cap. 12]. México: Cengage Learning.

Saroka, R. (2002). Sistemas de Información en la Era Digital. Buenos Aires,

Argentina: Fundación OSDE.

35