Introducción

En una organización o empresa, el análisis y diseño de sistemas de información es el

proceso de estudiar su situación con la finalidad de observar como trabaja y decir si es
necesario realizar una mejora; el encargado de realizar estas tareas es el analista de
sistemas. Antes de comenzar el desarrollo de cualquier proyecto, se conoce un estudio
de sistema s para detectar todos los detalles de la situación actual en la empresa. La
información reunida con este estudio sirve como base para crear varias estrategias de
diseño. Los administradores deciden qué estrategia seguir. Los gerentes, empleados y
otros usuarios finales que se familiarizan cada vez más con el empleo de
computadoras están teniendo un papel muy importante en el desarrollo de sistemas.
Todas las organizaciones son sistemas que actúan recíprocamente con su medio
ambiente recibiendo entradas y produciendo salidas. Los sistemas, que pueden estar
formados por otros sistemas más pequeños denominados subsistemas, funcionan para
alcanzar fines específicos. Sin embargo, los propósitos o metas se alcanzan sólo
cuando se mantienen el control.
Un sistema de información es un conjunto de elementos que interactúan entre sí con el
fin de apoyar las actividades de una empresa o negocio. El equipo computacional: el
hardware necesario para que el sistema de información pueda operar.
El recurso humano que interactúa con el Sistema de Información, el cual está formado
por las personas que utilizan el sistema.
Un sistema de información realiza cuatro actividades básicas: entrada,
almacenamiento, procesamiento y salida de información.
En la actualidad, son muchos los procesos de desarrollo de software que existen. Con
el paso de los años, la Ingeniería del Software ha introducido y popularizado una serie
de estándares para medir y certificar la calidad, tanto del sistema a desarrollar, como
del proceso de desarrollo en sí. Como sabemos, un área de conocimiento de gran
importancia en el desarrollo de software, es la ingeniería de requerimientos. Esta
comprende las actividades de obtención captura, descubrimiento y adquisición,
análisis y negociación, especificación, y validación de requisitos. Además, establece
una actividad de gestión de requerimientos para manejar los cambios, mantenimiento
y rastreabilidad de los requerimientos. El proceso de obtención de requisitos, cuya
finalidad es llevar a la luz los requisitos, no solo es un proceso técnico, sino también
un proceso social que envuelve a diferentes personas, lo que conlleva dificultades
añadidas a su realización.
Hoy en día se depende más de sistemas automatizados que en épocas pasadas. Esto ha
llevado a los equipos de desarrollo a enfrentarse con una nueva década de procesos y
estándares de calidad ,a pesar de los avances que ha dado la tecnología, aún existen
procesos de producción informales, parciales. La Ingeniería de Requerimientos
cumple un papel primordial en el proceso de producción de software, ya que enfoca
un área fundamental ,la definición de lo que se desea producir. Su principal tarea
consiste en la generación de especificaciones correctas que describan con claridad, sin
ambigüedades, en forma consistente y compacta, el comportamiento del sistema. De
esta manera, se pretende minimizar los problemas relacionados al desarrollo de
sistemas.
Estrategias para determinar requerimientos

Existe un gran número de técnicas para obtener requerimientos. Hay que aclarar que
ninguna de estas técnicas es suficiente por sí sola y que es recomendable combinarlas
para obtener requerimientos completos. Algunas de las técnicas más habituales en la
elicitación de requerimientos son las entrevistas, el Joint Application Development
(JAD) o Desarrollo Conjunto de Aplicaciones, el brainstorming o tormenta de ideas y
la utilización de escenarios, más conocidos como casos de uso.
Estas técnicas, que se describen se suelen completar con otras técnicas
complementarias como la observación in situ, el estudio de documentación, los
cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de
requerimientos sean aprendices del cliente.

Entrevistas
Las entrevistas son la técnica de elicitación más utilizada, y de hecho son
practicamente inevitables en cualquier desarrollo ya que son una de las formas de
comunicación más naturales entre personas. En las entrevistas se pueden identificar
tres fases: preparación, realización y análisis.
Preparación de entrevistas: Las entrevistas no deben improvisarse, por lo que
conviene realizar las siguientes tareas previas:

Estudiar el dominio del problema: Conocer las categorías y conceptos de la

comunidad de clientes y usuarios es fundamental para poder entender las necesidades
de dicha comunidad y su forma de expresarlas, y para generar en los clientes y
usuarios la confianza de que el ingeniero de requerimientos entiende sus problemas.
Para conocer el dominio del problema se puede recurrir a técnicas de estudio de
documentación, a bibliografía sobre el tema, documentación de proyectos similares
realizados anteriormente, la inmersión dentro de la organización para la que se va a
desarrollar o a periodos de aprendizaje por parte de los ingenieros de requerimientos.

Seleccionar a las personas a las que se va a entrevistar: Se debe minimizar el número

de entrevistas a realizar, por lo que es fundamental seleccionar a las personas a
entrevistar. Normalmente se comienza por los directivos (que pueden ofrecer una
visión global), y se continúa con los futuros usuarios (que pueden aportar información
más detallada) y con el personal técnico (que aporta detalles sobre el entorno
operacional de la organización). Conviene también estudiar el perfil de los
entrevistados, buscando puntos en común con el entrevistador que ayuden a romper el
hielo.

Determinar el objetivo y contenido de las entrevistas: Para minimizar el tiempo de la

entrevista es fundamental fijar el objetivo que se pretende alcanzar y determinar
previamente su contenido. Previamente a su realización, se pueden enviar
cuestionarios (que los futuros entrevistados deben rellenar y devolver) y un pequeño
documento de introducción al proyecto de desarrollo (de forma que el entrevistado
conozca los temas que se van a tratar, y el entrevistador recoja información para
preparar la entrevista). Es importante que los cuestionarios, si se usan, se preparen
cuidadosamente teniendo en cuenta quién los va a responder y no incluir conceptos
que se asuman conocidos cuando puedan no serlo.

Planificar las entrevistas: La fecha, hora, lugar y duración de la entrevista deben

fijarse teniendo en cuenta siempre la agenda del entrevistado. En general, se deben
buscar sitios agradables donde no se produzcan interrupciones y que resulten
naturales a los entrevistados.

Realización de entrevistas: Dentro de la realización de las entrevistas se distinguen

tres etapas:
Apertura: El entrevistador debe presentarse e informar al entrevistado sobre la razón
de la entrevista, qué se espera conseguir, cómo se utilizará la información, la
mecánica de las preguntas, etc. Si se va a utilizar algún tipo de notación gráfica o
matemática que el entrevistado no conozca debe explicarse antes de utilizarse. Es
fundamental causar buena impresión en los primeros minutos.

Desarrollo: La entrevista en sí no debería durar más de dos horas, distribuyendo el

tiempo en un 20% para el entrevistador y un 80% para el entrevistado. Se deben evitar
los monólogos y mantener el control por parte del entrevistador, contemplando la
posibilidad de que una tercera persona tome notas durante la entrevista o grabar la
entrevista en cinta de vídeo o audio, siempre que el entrevistado esté de acuerdo.
Durante esta fase se pueden emplear distintas técnicas:

Preguntas abiertas: También denominadas de libre contexto, estas preguntas no

pueden responderse con un «sí» o un «no», permiten una mayor comunicación y
evitan la sensación de interrogatorio. Por ejemplo, «¿Qué se hace para registrar un
pedido?», «Dígame qué se debe hacer cuando un cliente pide una factura» o «¿Cómo
se rellena un albarán?». Estas preguntas se suelen utilizar al comienzo de la entrevista,
pasando posteriormente a preguntas más concretas. En general, se debe evitar la
tendencia de anticipar una respuesta a las preguntas que se formulan.
Utilizar palabras apropiadas: Se deben evitar tecnicismos que no conozca el
entrevistado y palabras o frases que puedan perturbar emocionalmente la
comunicación.

Mostrar interés en todo momento: Es fundamental cuidar la comunicación no verbal

durante la entrevista: tono de voz, movimiento, expresión facial, etc. Por ejemplo,
para animar a alguien a hablar puede asentirse con la cabeza, decir «ya entiendo»,
«sí», repetir algunas respuestas dadas, hacer pausas, poner una postura de atención,
etc. Debe evitarse bostezar, reclinarse en el sillón, mirar hacia otro lado, etc.

Terminación: Al terminar la entrevista se debe recapitular para confirmar que no ha

habido confusiones en la información recogida, agradecer al entrevistado su
colaboración y citarle para una nueva entrevista si fuera necesario, dejando siempre
abierta la posibilidad de volver a contactar para aclarar dudas que surjan al estudiar la
información o al contrastarla con otros entrevistados.

Análisis de las entrevistas: Una vez realizada la entrevista es necesario leer las notas
tomadas, pasarlas a limpio, reorganizar la información, contrastarla con otras
entrevistas o fuentes de información, etc. Una vez elaborada la información, se puede
enviar al entrevistado para confirma los contenidos. También es importante evaluar la
propia entrevista para determinar los aspectos mejorables.

Desarrollo Conjunto de Aplicaciones ( JAD )

Es una técnica que se utiliza para promover la cooperación y el trabajo en equipo
entre usuarios y analistas. Consiste en realizar sesiones en las que participan usuarios
expertos del dominio junto a analistas de software. La idea es aprovechar la dinámica
de grupos aplicando un proceso de trabajo sistemático y organizado, apoyado por
elementos visuales de comunicación y comprensión de soluciones.
Las razones que sirven de base a JAD son las siguientes:
Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino
también en redactar un conjunto de requisitos coherente a partir de opiniones
diferentes de los distintos entrevistados.
Es más difícil apreciar posibles errores en la especificación de requisitos, ya que sólo
el analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y
detectar defectos.
El JAD propugna una participación más profunda de los usuarios en el proyecto, hasta
tal punto que los usuarios que participan adquieren un cierto sentido de propiedad en
el sistema que se construye.
El JAD no se utiliza demasiado, debido a que requiere una mayor organización que
las entrevistas y porque el ambiente o los métodos de trabajo convencionales en las
empresas no facilitan este tipo de actividades (falta de tiempo, dificultad de
coordinación de tanta gente, dificultad para convencer a la dirección, etc.). No
obstante las empresas que han implantado este método han informado de importantes
ahorros de tiempo en el desarrollo de software, así como de una mayor satisfacción de
los usuarios con los sistemas construidos.Desarrollo de Prototipos
Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas
(que no son totalmente operativos) de la aplicación pedida. Esta técnica es
particularmente útil cuando:
El área de la aplicación no está bien definida (posiblemente por ser algo muy
novedoso).
El costo del rechazo de la aplicación por los usuarios es muy alto.
Es necesario evaluar previamente el impacto del sistema en los usuarios y en la
organización.
Los prototipos de sistema permiten a los usuarios experimentar para ver cómo éste
ayuda a su trabajo. Fomentan el desarrollo de ideas que desembocan en
requerimientos. Además de permitir a los usuarios mejorar las especificaciones de
requerimientos, el desarrollo de un prototipo tiene otras ventajas:

Al demostrar las funciones del sistema se identifican las discrepancias entre los
desarrolladores y los usuarios.
Durante el desarrollo del prototipo, el personal del desarrollo de software puede darse
cuenta de que los requerimientos son inconsistentes y/o están incompletos.
Aunque limitado, se dispone rápidamente de un sistema que funciona y demuestra la
factibilidad y usabilidad de la aplicación a administrar.
El prototipo se utiliza como base para escribir la especificación para la producción.
En general, el uso de esta técnica es un medio que permite solventar objeciones del
usuario del tipo: “No sé exactamente lo que quiero, pero lo sabré cuando lo vea”. Por
lo general, la construcción de prototipos incrementa los costos en las etapas iniciales
de un proyecto, pero esto se recupera en etapas posteriores gracias al mejor
entendimiento de los requerimientos por parte de los desarrolladores. En algunos
casos también se utiliza como un medio para formalizar la aceptación previa del
cliente de los requisitos del proyecto.

Observación
Por medio de esta técnica el analista obtiene información de primera mano sobre la
forma en que se efectúan las actividades. Este método permite observar la forma en
que se llevan a cabo los procesos y, por otro, verificar que realmente se sigan todos
los pasos especificados. Como sabemos, en muchos casos los procesos son una cosa
en papel y otra muy diferente en la práctica. Los observadores experimentados saben
qué buscar y cómo evaluar la relevancia de lo que observan.

Estudio de documentación
Varios tipos de documentación, como manuales y reportes, pueden proporcionar al
analista información valiosa con respecto a las organizaciones y a sus operaciones. La
documentación difícilmente refleja la forma en que realmente se desarrollan las
actividades, o donde se encuentra el poder de la toma de decisiones. Sin embargo,
puede ser de gran impotancia para introducir al analista al dominio de operación y el
vocabulario que utiliza.

Cuestionarios
El uso de cuestionarios permite a los analistas reunir información proveniente de un
grupo grande de personas. El empleo de formatos estandarizados para las preguntas
puede proporcionar datos más confiables que otras técnicas; por otra parte, su amplia
distribución asegura el anonimato de los encuestados, situación que puede conducir a
respuestas más honestas. El inconveniente es que la respuesta puede ser limitada, ya
que es posible que no tenga mucha importancia para los encuestados llenar el
cuestionario. Es recomendable conseguir apoyo de la alta dirección para solicitar a las
personas de la organización que contesten el cuestionario.
Al igual que con las entrevistas, se debe seleccionar a los encuestados. El analista
debe asegurar que el conocimiento y experiencia de éstos califiquen para dar
respuestas a las preguntas.

Tormenta de ideas ( Brainstorming )

Consiste en reuniones con cuatro a diez personas donde como primer paso sugieren
toda clase de ideas sin juzgar su validez y después de recopilar todas las ideas se
realiza un análisis detallado de cada propuesta. Esta técnica se puede utilizar para
identificar un primer conjunto de requisitos en aquellos casos donde no están muy
claras las necesidades que hay que cubrir, o cuando se esta creando un sistema que
habilitará un servicio nuevo para la organización.

ETHICS ( Implementación Efectiva de Sistemas Informáticos desde los puntos

de vista Humano y Técnico )
Constituye un método bastante evolucionado para fomentar la participación de los
usuarios en los proyectos. Coordina la perspectiva social de los sistemas con su
implementación técnica. Un sistema no tiene éxito si no se ajusta a los factores
sociales y organizacionales que rigen a la empresa. Se busca la satisfacción de los
empleados en el trabajo a través de estudios integrales. Los requisitos técnicos del
sistema serán los necesarios para mejorar la situación de los empleados y, por lo tanto,
su productividad en función de dichos análisis.

Puntos de Vista
Cualquier sistema de software no trivial debe satisfacer las necesidades de un grupo
diverso de interesados (stakeholders). Cada uno de estos puede tener intereses
diferentes en el sistema de software, y por lo tanto sus necesidades pueden generar
requerimientos que tengan conflicto entre sí, o incluso se contradigan. Los métodos
orientados a puntos de vista (viewpoints) toman en consideración estas perspectivas
diferentes y las utilizan para estructurar y organizar tanto el proceso de obtención,
como los requerimientos mismos. Uno de estos métodos es el método VORD
(Definición de Requerimientos Orientado a Puntos de Vista), el cual provee un marco
de trabajo orientado para la obtención y documentación de requerimientos. Las etapas
principales de este método son:

Identificación de puntos de vista, que implica descubrir los que reciben los servicios
del sistema e identificar los servicios específicos que se suministran a cada punto de
vista.
Estructuración de puntos de vista, que comprende agrupar los relacionados en una
jerarquía. Los servicios comunes se ubican en los niveles altos de la jerarquía y se
heredan los puntos de vista de bajo nivel.
Documentación de puntos de vista, que comprende refinar la descripción de éstos y
los servicios identificados.
Trazado del punto de vista del sistema, que comprende identificar los objetos en un
diseño orientado a objetos utilizando la información del servicio encapsulado en los
puntos de vista.

Escenarios
Estos se utilizan para documentar el comportamiento del sistema cuando se le
presentan eventos específicos. Cada evento de interacción distinto, o la selección de
un servicio del sistema, se documentan como un escenario de eventos distinto. Los
escenarios de eventos incluyen una descripción del flujo de datos y las acciones del
sistema, y documenta las excepciones que puedan surgir. Las convenciones para los
diagramas utilizados en los escenarios de eventos son:

Los datos proporcionados desde un punto de vista o proporcionados a éste se

representan como elipses.
Las entradas y salidas de la información de control se ubican en la parte superior de
cada recuadro.
Las salidas de datos se ubican a la derecha de cada recuadro. Si no están encerradas,
significa que pertenecen al sistema.
Las excepciones se muestran en la parte inferior del recuadro. Si existen varias
excepciones posibles, éstas se encierran en un recuadro.
El nombre del siguiente evento esperado después de completar el escenario se muestra
en un recuadro sombreado.

Los Casos de Uso

Son una técnica que se basa en escenarios para la obtención de requerimientos.
Actualmente se han convertido en una técnica fundamental que se utiliza para analizar
y describir modelos de sistemas orientados a objetos. En su forma más simple, un
caso de uso identifica a los actores involucrados en una interacción y nombra al tipo
de ésta.

Diagrama de flujo de datos

Es una técnica muy apropiada para reflejar de una forma clara y precisa los procesos
que conforman el sistema de información. Permite representar gráficamente los
límites del sistema y la lógica de los procesos, estableciendo qué funciones hay que
desarrollar. Además, muestra el flujo o movimiento de los datos a través del sistema y
sus transformaciones como resultado de la ejecución de los procesos. Esta técnica
consiste en la descomposición sucesiva de los procesos, desde un nivel general, hasta
llegar al nivel de detalle necesario para reflejar toda la semántica que debe soportar el
sistema en estudio.

El diagrama de flujo de datos se compone de los siguientes elementos:

Entidad externa: representa un ente ajeno al sistema que proporciona o recibe

información del mismo. Puede hacer referencia a departamentos, personas, máquinas,
recursos u otros sistemas. El estudio de las relaciones entre entidades externas no
forma parte del modelo.
Puede aparecer varias veces en un mismo diagrama, así como en los distintos niveles
del DFD para mejorar la claridad del diagrama.
Proceso: representa una funcionalidad que tiene que llevar a cabo el sistema para
transformar o manipular datos. El proceso debe ser capaz de generar los flujos de
datos de salida a partir de los de entrada, más una información constante o variable al
proceso.
El proceso nunca es el origen ni el final de los datos, puede transformar un flujo de
datos de entrada en varios de salida y siempre es necesario como intermediario entre
una entidad externa y un almacén de datos.

Almacén de datos: representa la información en reposo utilizada por el sistema

independientemente del sistema de gestión de datos (por ejemplo un. fichero, base de
datos, archivador, etc.). Contiene la información necesaria para la ejecución del
proceso.
El almacén no puede crear, transformar o destruir datos, no puede estar comunicado
con otro almacén o entidad externa y aparecerá por primera vez en aquel nivel en que
dos o más procesos accedan a él.

Flujo de datos: representa el movimiento de los datos, y establece la comunicación

entre los procesos y los almacenes de datos o las entidades externas. Un flujo de datos
entre dos procesos sólo es posible cuando la información es síncrona, es decir, el
proceso destino comienza cuando el proceso origen finaliza su función.
Los flujos de datos que comunican procesos con almacenes pueden ser de los
siguientes tipos:
De consulta: representan la utilización de los valores de uno o más campos de un
almacén o la comprobación de que los valores de los campos seleccionados cumplen
unos criterios determinados.
De actualización: representan la alteración de los datos de un almacén como
consecuencia de la creación de un nuevo elemento, por eliminación o modificación de
otros ya existentes.
De diálogo: es un flujo entre un proceso y un almacén que representa una consulta y
una actualización.
Existen sistemas que precisan de información orientada al control de datos y requieren
flujos y procesos de control, así como los mecanismos que desencadenan su
ejecución. Para que resulte adecuado el análisis de estos sistemas, se ha ampliado la
notación de los diagramas de flujo de datos incorporando los siguientes elementos:

Proceso de control: representa procesos que coordinan y sincronizan las actividades

de otros procesos del diagrama de flujo de datos.
Flujo de control: representa el flujo entre un proceso de control y otro proceso. El
flujo de control que sale de un proceso de control activa al proceso que lo recibe y el
que entra le informa de la situación de un proceso. A diferencia de los flujos
tradicionales, que pueden considerarse como procesadores de datos porque reflejan el
movimiento y transformación de los mismos, los flujos de control no representan
datos con valores, sino que en cierto modo, se trata de eventos que activan los
procesos (señales o interrupciones). El objetivo del diagrama de flujo de datos es la
obtención de un modelo lógico de procesos que represente el sistema, con
independencia de las restricciones físicas del entorno. Así se facilita su comprensión
por los usuarios y los miembros del equipo de desarrollo. El sistema se divide en
distintos niveles de detalle, con el objetivo de:

-Simplificar la complejidad del sistema, representando los diferentes procesos de que

consta.
-Facilitar el mantenimiento del sistema.
Diccionario de datos
Es un conjunto de definiciones que contiene las características lógicas y puntuales de
los datos que se van a utilizar en el sistema que se programa, incluyendo nombre,
descripción, alias, contenido y organización. Identifica los procesos donde se emplean
los datos y los sitios donde se necesita el acceso inmediato a la información, se
desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan
en la determinación de los requerimientos del sistema, su contenido también se
emplea durante el diseño. En un diccionario de datos se encuentra la lista de todos los
elementos que forman parte del flujo de datos de todo el sistema. Los elementos más
importantes son flujos de datos, almacenes de datos y procesos. El diccionario de
datos guarda los detalles y descripción de todos estos elementos. Si los analistas
desean conocer cuántos caracteres abarca un determinado dato o qué otros nombres
recibe en distintas partes del sistema, o dónde se utiliza, encontrarán las respuestas en
un diccionario de datos desarrollado en forma apropiada. El diccionario se desarrolla
durante el análisis de flujo de datos y auxilia a los analistas que participan en la
determinación de los requerimientos de sistemas
Razones para su utilización
1- Para manejar los detalles en sistemas muy grandes, ya que tienen enormes
cantidades de datos, aun en los sistemas mas chicos hay gran cantidad de datos:
Los sistemas al sufrir cambios continuos, es muy difícil manejar todos los detalles.
Por eso se registra la información, ya sea sobre hoja de papel o usando procesadores
de texto. Los analistas mas organizados usan el diccionario de datos automatizados
diseñados específicamente para el análisis y diseño de software.

2- Para asignarle un solo significado a cada uno de los elementos y actividades del
sistema: Los diccionarios de datos proporcionan asistencia para asegurar significados
comunes para los elementos y actividades del sistema y registrando detalles
adicionales relacionadas con el flujo de datos en el sistema, de tal manera que todo
pueda localizarse con rapidez.

3- Para documentar las características del sistema, incluyendo partes o componentes

así como los aspectos que los distinguen. Tambien es necesario saber bajo que
circunstancias se lleva a cabo cada proceso y con que frecuencia ocurren.
Produciendo una comprensión mas completa. Una vez que las características están
articuladas y registradas, todos los participantes en el proyecto tendrán una fuente
común de información con respecto al sistema.

4- Para facilitar el análisis de los detalles con la finalidad de evaluar las características
y determinar donde efectuar cambios en el sistema.
Determina si son necesarias nuevas características o si están en orden los cambios de
cualquier tipo.

Características

-Naturaleza de las transacciones: las actividades de la empresa que se llevan a cabo

mientras se emplea el sistema.

-Preguntas: solicitudes para la recuperación o procesamiento de información para

generar una respuesta especifica.
-Archivos y bases de datos: detalles de las transacciones y registros maestros que son
de interés para la organización.

-Capacidad del sistema: Habilidad del sistema para aceptar, procesar y almacenar
transacciones y datos

5- Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan

en un informe. Aun en los manuales, se revelan errores.

Contenido de un registro de diccionario

El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son
los elementos datos y estructura de datos.
Elemento dato: son los bloques básicos para todos los demás datos del sistema, por si
mismos no le dan un significado suficiente al usuario. Se agrupan para formar una
estructura de datos.
Descripción: Cada entrada en el diccionario consiste de un conjunto de detalles que
describen los datos utilizados o producidos por el sistema.

Se identifica cada uno a través

Un nombre: para distinguir un dato de otro.

Descripción: indica lo que representa en el sistema.

Alias: porque un dato puede recibir varios nombres, dependiendo de quien uso este
dato.

Longitud: porque es de importancia de saber la cantidad de espacio necesario para

cada dato.

Valores de los datos: porque en algunos procesos solo son permitidos valores muy
específicos para los datos. Si los valores de los datos están restringidos a un intervalo
especifico, esto debe estar en la entrada del diccionario.

Estructura de datos: es un grupo de datos que están relacionados con otros y que en
conjunto describen un componente del sistema.

Análisis de decisión
Seguir procedimientos y tomar decisiones son aspectos importantes de cualquier
empresa. Las decisiones y procedimientos son de importancia para el analista cuando
este conduce una investigación de sistemas dentro de la empresa. Las herramientas
ayudan al analista a integrar los datos recopilados por los diversos métodos estudiados
anteriormente. Pero, como sucede con todas las herramientas, la que emplea el
analista para documentar procedimientos y decisiones deben utilizarse
adecuadamente.
Cuando se observa un sistema y se pregunta ¿cuáles son las posibilidades? O ¿qué
puede suceder?, en realidad se esta preguntando por las condiciones, que son los
posibles estados de una entidad. Las condiciones cambian, y es por eso que el analista
se refiere a ellas como variables de decisión. Al documentar la decisión de cómo
procesar un procedimiento, el investigador debe identificar tanto las condiciones
permisibles como las relevantes que pueden presentarse en determinada situación.
Solo deben incluirse en el estudio aquellas condiciones que son relevantes. Cuando se
conocen todas las posibles condiciones, el siguiente paso del analista es determinar
que hacer cuando se presentan algunas de estas. Las acciones son opciones, que
comprenden pasos, actividades o requerimientos, que puede elegir una persona
cuando se enfrenta ante un conjunto de condiciones.

Árboles de decisión
Las personas pueden tener diferentes formas de decir lo mismo. Tener diferentes
formas e decir la misma cosa pueden crear dificultades de comunicación durante los
estudios de sistemas. Por consiguiente, el analista busca evitar las malas
interpretaciones. Asimismo, el analista necesita organizar la información recopilada
con respecto a la toma de decisiones.
Características de los árboles de decisión:

El árbol de decisión es un diagrama que representa en forma secuencial condiciones y

acciones; muestra que condiciones se consideran en primer lugar, cuales en segundo y
así sucesivamente. Este método también permite mostrar la relación que existe entre
cada condición y el grupo de acciones permisibles asociado con ella. La raíz del árbol
es el punto donde comienza la secuencia de decisión. La rama a seguir depende de las
condiciones existentes y de la decisión que debe tomarse. Al avanzar de izquierda a
derecha por una rama en particular, se obtiene una serie de toma de decisiones.
Después de cada punto de decisión, se encuentra el siguiente conjunto de decisiones a
considerar. De esta forma, los nodos del árbol representan condiciones y señalan la
necesidad de tomar una determinación relacionada con la existencia de alguna de
estas, antes de seleccionar la siguiente trayectoria. La parte que se encuentra a la
derecha del árbol indica las acciones que deben realizarse, las que a su vez dependen
de la secuencia de condiciones que las proceden.
Uso de árboles de decisión:
El desarrollo de árboles de decisión beneficia al analista en dos formas. Primero que
todo, la necesidad de describir condiciones y acciones llevan a los analistas a
identificar de manera formal las decisiones que actualmente deben tomarse. De esta
forma, es difícil para ellos pasar por alto cualquier etapa del proceso de decisión, sin
importar que este dependa de variables cualitativas o cuantitativas. Los árboles de
decisión también obligan a los analistas a considerar la secuencia de las decisiones.

Tablas de decisión
La tabla de decisión es una matriz de renglones y columnas que indican condiciones y
acciones. Las reglas de decisión, incluidas en una tabla de decisión, establecen el
procedimiento a seguir cuando existen ciertas condiciones.
Características de las tablas de decisión:
La taba de decisión esta integrada por cuatro secciones: identificación de condiciones,
entradas de condiciones, identificación de acciones y entradas de acciones. La
identificación de condiciones señala aquellas que son relevantes. Las entradas de
condiciones indican que valor, si es que lo hay, se debe asociar para una determinada
condición. La identificación de acciones enlista el conjunto de todos los pasos que se
deben seguir cuando se presenta cierta condición. Las entradas de acciones muestran
las acciones especificas del conjunto que deben emprenderse cuando ciertas
condiciones o combinaciones de estas son verdaderas. En ocasiones se añaden notas
en la parte inferior de la tabla para indicar cuando utilizar la tabla o para diferenciarla
de otras tablas de decisión.
Las columnas del lado derecho de la tabla enlazan condiciones y acciones, forman
reglas de decisión que establecen condiciones que deben satisfacerse para emprender
un determinado conjunto de acciones. La regla de decisión incorpora todas las
condiciones que deben ser ciertas y no solo una a la vez.
Para desarrollar tablas de decisión, los analistas deben emprender los siguientes pasos:

- Determinar los factores determinados como más relevantes en la toma de decisiones.

Esto permite identificar las condiciones en la decisión. Cada condición seleccionada
debe tener la característica de ocurrir o no ocurrir; en este caso no es posible la
ocurrencia parcial.

- Determinar los pasos o actividades más factibles bajo condiciones que cambian.
Esto permite identificar las acciones.

- Estudiar las diferentes posibilidades de combinaciones de condiciones. Para

cualquier numero n de condiciones, existen 2 a la n combinaciones a considerar.

- Llenar la tabla con las reglas de decisión. Existen dos formas para hacerlo.

La primera, y más larga, es llenar los renglones de condición con valores si o no para
cada combinación posible de condiciones. Esto es, llenar la primera mitad del renglón
con Si y la segunda con No. El siguiente renglón se llena alternando con S y N cada
25% del renglón; es decir, 25% Si, 25% No, 25% Si y 25% No. Se repite de nuevo
este proceso: se llena ada renglón faltante en forma alterna con S y con N, dividiendo
cada vez por potencias sucesivas de 2.
El otro método para llenar la tabla considera una condición a la vez y, por cada
condición adicional le añade una tabla pero sin considerar las combinaciones de
condiciones y acciones duplicadas.

Verificación de tablas de decisión

Después de construir una tabla, los analistas verifican que sea correcta y completa con
la finalidad de asegurar que la tabla incluye todas las condiciones junto con las reglas
de decisión que las relacionan con las acciones. Asimismo, los analistas también
deben examinar la tabla para encontrar redundancias y contradicciones.

Eliminación de la redundancia: Las tablas de decisión pueden volverse muy grandes y

difíciles de manejar si se permite que crezcan sin ningún control. Remover las
entradas redundantes puede ser de ayuda para manejar el tamaño de la tabla. La
redundancia se presenta cuando las siguientes condiciones son verdaderas al mismo
tiempo: 1) dos reglas de decisión son idénticas salvo para una condición del renglón y
2) las acciones para las dos reglas son idénticas.

Supresión de contradicciones: las reglas de decisión son contradictorias entre si

cuando dos o más reglas tienen el mismo conjunto de contradicciones pero sus
acciones son diferentes.
Las contradicciones indican que la información que tiene el analista es incorrecta o
bien existe un error en la construcción de la tabla. Sin embargo, muchas veces la
contradicción es resultado de las dependencias en la información que recibe el analista
de diferentes personas con respecto a la forma en que estas toman decisiones. Se
puede tomar una decisión especifica utilizando diferentes reglas. Encontrar tales
discrepancias puede ser de gran utilidad para el analista que trabaja con la finalidad de
mejorar una situación de decisión.

Conclusión

Un proyecto de desarrollo de un Sistema de Información comprende varios

componentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda a
traducir las necesidades del cliente en un modelo de Sistema que utiliza uno más de
los componentes: Software, hardware, personas, base de datos, documentación y
procedimientos. En una organización o Empresa, el análisis y Diseño de Sistemas, es
el proceso de estudiar su Situación con la finalidad de observar como trabaja y decidir
si es necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el
analista de sistemas.
Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio de
Sistemas para detectar todos los detalles de la situación actual de la empresa. La
información reunida con este estudio sirve como base para crear varias estrategias de
Diseño. Los administradores deciden que estrategias seguir.
Los Gerentes, empleados y otros usuarios finales que se familiarizan cada vez mas
con el uso de computadoras están teniendo un papel muy importante en el desarrollo
de sistemas.
Todas las organizaciones son Sistemas que actúan de manera reciproca con su medio
ambiente recibiendo entradas y produciendo salidas. Los Sistemas que pueden estar
formados por otros Sistemas de denominan subsistemas y funcionan para alcanzar los
fines de su Implantación.
 Referencias

Flaaten, P. O., McCubbrey, D.J., O´Riordan, P.D., Burgués, K., “Foundations of

Business Systems”. Chicago (EE.UU.), The Dryden Pres, 1989.
Raghavan, S., Zelesnik, G., Ford, G., “Lecture Notes on Requirements Elicitation”.
CMU/SEI-94-EM-10, Pittsburgh (E.E.U.U.), Software Engineering Institute
(Carnegie Mellon University), 1994.
Kontonya, G. & Sommerville I., “Requirements Engineering: Processes and
Techniques”. John Wiley and Sons, 2002.
Kotonya, G. y Sommerville, I. (1996). “Requirements Engineering with viewpoints”.
BCS/IEE Software Engineering J.