Unidad 3 Análisis de sistemas y modelado de los requerimientos de un sistema de

información

3.1. Estudio de los requerimientos de un sistema de información

¿Qué es un requerimiento en sistemas de información?
Los requerimientos son declaraciones que pueden identificar características,
atributos, capacidades y cualidades que necesitan cumplir un sistema para que
tenga utilidad, así como valor para un usuario.
Es un conjunto de componentes que colectan, obtienen, procesan, almacenan y
distribuyen información para la ayuda en la toma de decisiones dentro de una
organización.
Se pueden clasificar en:
• Requerimientos funcionales: Que debe gestionar o hacer el sistema.
• Requerimientos no funcionales: Como debe funcionar el sistema. (calidad,
rendimiento, facilidad de uso,etc.)
• Requerimientos externos: la compatibilidad con otros sistemas, o la
flexibilidad que pueda tener respecto a su entorno.
Para poder cumplir dichos requerimientos el analista de sistemas necesitará
técnicas especificas, desde la observación de la organización, indagación en los
objetivos planteados y entrevistas a los usuarios finales.

3.2. Aprobación de los requerimentos de un sistema de información

Para que se aprueben los requerimientos de un sistema de información, el analista
debe tener todos los puntos aterrizados con el apoyo de prototipos en papel (SRS),
donde se detalla mejor el funcionamiento que se implementará, así se pueden
externar dudas sobre los objetivos, las carácteristicas, la viabilidad y la forma en
que se solventaran los costos para que todos los involucrados estén de acuerdo.
Una vez que son aprobados se debe llevar a cabo el compromiso formal de lo que
se hará dentro del sistema de informacion proyectado, debemos de recordar quien
toma esas desiciones (ESS).

Página 1 de 12
3.3. Clasificación de las técnicas de identificación de proyectos
Se pueden contemplar diferentes técnicas para identificar los requerimientos del
proyecto, por lo general se realizan entrevistas, casos de uso, cuestionarios, etc..
• Entrevistas: Son importantes para obtener las opiniones y descripciones de
las actividades del usuario, en ellas se ocupan preguntas abiertas, para que
se evite responder con un Sí o un No; Ya recopilando toda la información
sistemática en una conversación estructurada que no puede durar mas de
dos horas,
• Desarrollo de prototipos: Ayuda al analista a mejorar las especificaciones
definidas en los requerimientos, la generación de prototipos suele ser
costosa con relación en el tiempo, pero al final se puede recuperar, ya que
esta técnica ayuda ampliamente a los desarrolladores a entender los
requerimientos de manera precisa.
• Cuestionarios o encuestas: Permiten obtener informacion de grandes
grupos de personas, el analista debe asegurarse de que las personas
cuenten con el conocimiento suficiente para dar respuesta a cada una de las
preguntas.
• Lluvia de ideas: Se debe llevar acabo reuniones de cuatro a diez personas
las cuales sugeriran toda clase de ideas, esta técnica es utilizada para
identificar el primer conjunto de requerimientos que se necesitan cubrir.
• Historia de usuario: Nos permite tener acercamiento a los usarios para que
detallen las funcionalidades que el sistema realizará.

3.4 Modelado de funciones

Sabemos que los sistemas almacenan y usan dicha información para relacionar el
ambiente donde interactúan, esta información tiene un comportamiento dependiente
del tiempo conforme se van obteniendo los datos, por lo que necesitamos un modelo
para poder analisar dicho comportamiento, escenarios o situaciones, estos se
llaman estados, que pueden ser modelados a traves de los “Diagramas de Flujo de
Datos” junto con el “Diccionario de Datos”.
La representacion gráfica de este modelo pueden dibujarse sistemáticamente con
el uso de cuatro símbolos.
1. Rectángulo redondeado.- en el cual se describen el procesamiento de los
datos.
2. Cuadrado doble.- para mostrar un receptor de datos externos.
3. Flecha.- describe el flujo de datos.
4. Rectángulo con extremo abierto.- Muestra un almacén de datos

Página 2 de 12
3.4.1 Diagrama de Flujo de Datos DFD
Los DFD son herrramientas estructuradas para el diseño y análisis de los sistemas
de información, donde el analista de sistemas puede plasmar de forma visual el
proceso de flujo de datos y la transformación de los mismos que se mueven dentro
de la organización. Existen cuatro principales ventajas respecto a la manera en el
que el flujo de datos se mueven a través del sistema:
1. Mayor comprensión de la relación de los sistemas y subsistemas.
2. Permite comunicar los datos a los usuario a través de diagramas de flujo.
3. Puede determinar si se han definifo los procesos y datos necesarios.
4. Libertad de implementacion técnica del sistema.
Un analista de sistemas necesita conceptualizar el flujo de datos de arriba hacia
abajo conforme a los siguientes puntos:
• Identificar las actividades de negocio: Entidades externas, Flujo de datos,
Procesos y Almacenamiento de datos.
• Elaborar un diagrama de contexto que muestre entidades externas y los flujos
de datos, no se debe mostrar procesos detallados, ni el alamacenamiento de
datos.
• Revisa errores, etiquetas significativas que se asignen a cada proceso y a
cada flujo de datos.
• Desarrolla un diagrama de flujo de datos físicos, a partir del diagrama de flujo
de datos lógicos; Distinguiendo los procesos manuales y automatizados,
para poder describir donde se completan los procesos o se producen errores.
• Se tiene que dividir el diagrama de flujo de datos físicos, separando o
agrupando partes del diagrama para facilitar la programación e
implementación.
Los DFD se clasifican como lógicos y físicos. Los lógicos están enfocados a la
organización y su manera de operación, mientras que los físicos muestran como
se implementará el sistema, incluyendo hardware, software, archivos, etc.
Algunas ventajas de los diagramas de flujo lógico:
• Mejor comunicación con los usuarios.
• Sistemas más estables.
• Flexibilidad y mantenimiento.
• Se eliminan las redundancias y se facilita la creación del modelo físico.
Algunas ventajas de los diagramas de flujo físico:
• Describen los procesos con más detalle que los DFD lógicos.
• Identifican los almacenes de datos temporales.
• Especifican los nombres reales de los archivos y bases de datos.

Página 3 de 12
 • Agragan controles para asegurar que los procesos se realicen de forma
apropiada.

Fig. 1 Ejemplos de diagrama de flujo lógico y físico (Kendall y Kendall, 2011,

p203).
3.4.2. Diccionario de datos DD
El DD es una versión especializada que contiene elementos, estructuras,
almacenes, flujos y procesos de datos; Todo es compilado por el analista de
sistemas para consultar, recopilar y coordinar información.
Para crear el DD se debe examinar y describir el contenido de los flujos de datos
como son los almacenes de datos y los procesos. Así mismo es necesario definir
cada almacén y flujo de datos, para después expandirlo de manera que incluya los
detalles de los elementos que contiene. También es importante desarrollar los

Página 4 de 12
cuatro categorías del DD (flujo de datos como estructura de datos como elementos
de datos y almacenes de datos) para lograr la comprensión de los datos del sistema.
Para describir las estructuras de datos, se utiliza una notación algebraica, este
metodo permite al analista producir una vista de los elementos que forman una
estructura de datos. La notación algebraica utiliza los siguiente simbolos.
1. Un signo de igual (=) significa “está compuesto de”.
2. Un signo positivo (+) significa “y”.
3. Las llaves {} indican elementos repetitivos, también conocidos como grupos
o tablas repetitivos. Puede haber un elemento repetitivo o varios de ellos en
el grupo. El grupo repetitivo puede tener condiciones, como un número fijo
de repeticiones, o límites superiores e inferiores para el número de
repeticiones.
4. Los corchetes [] representan una situación de cualquier tipo. Puede estar
presente cualquier elemento u otro, pero no ambos. Los elementos que se
en listan entre corchetes son mutuamente excluyentes.
5. Los paréntesis () representan un elemento opcional, que se puede dejar en
blanco en las pantallas de entrada de datos y puede contener espacios o
ceros para los compuestos númericos en las estructuras de archivos.
Para utilizar esta notación algebraica que define cada registro de una manera
detallada hasta que todo el conjunto se descomponga en sus elementos básicos,
mediante este método, el analista de sistemas puede definir los registros para
usarlos en muchas aplicaciones.
3.4.3. Técnicas de especificación de procesos
Las especificaciones en los procesos pueden explicar la lógica al tomar desiciones,
junto con el tratamiento de la información de entrada para realizar el proceso de
salida. En algunas ocaciones son una pequeña parte de las especificaciones totales
en un proyecto, por lo que deben cubrir los siguientes objetivos:
• Reducir la ambigüedad del proceso.
• Obtener una descripción precisa de lo que se va a lograr.
• Validar el sistema de diseño.
3.5. Modelado de datos

El modelado de datos se refiere a la manera de unificar y moldear la información

para que pueda ser transmitida, ejecutada y procesada por las bases de datos. El
modelado de datos junto con una base de datos, comúnmente relacional. La idea
de modelar los datos es para que el análisis y la integración se pueda hacer de
manera óptima y lo más fácil posible.

El modelado de datos puede ser usado para diferentes propósitos, como realizar
modelos conceptuales de los objetos detectados en el análisis, hasta modelos de

Página 5 de 12
datos físicos que serán usados para transportar un conjunto de información y que,
posteriormente, serán almacenados en la base de datos correspondiente.

3.5.1. Diagramas E-R

Los diagramas E-R apoyan el modelado de archivos o bases de datos y son
elementales para que el analista de sistemas comprenda tanto las entidades como
las relaciones en el sistema. Para elaborar bosquejos de algunos diagramas E-R
básicos un analista necesita:

1. Enlistar las entidades en la organización para obtener una mejor

comprensión de esta.
2. Elegir las entidades clave para reducir el alcance del problema a una
dimensión manejable y significativa.
3. Identificar cuál debe ser la entidad principal.
4. Confirmar los resultados de los pasos uno al tres por medio de otros métodos
de recopilación de datos (investigación, entrevistas, administración de
cuestionarios, observación y prototipos).

El diseño de diagramas E-R debe iniciar cuando el analista ingresa a la organización, a fin
de comprender la actividad y tamaño de la misma, el alcance del problema y discernir si
está tratando o no con el problema correcto. Conforme el proceso de recopilación de datos
va avanzando, se deben confirmar y revisar los diagramas E-R.

Fig.2 Entidades utilizadas en diagramas E-R (Kendall y Kendall, 2011, p233).

Página 6 de 12
3.5.2 Diagramas de estructura de datos

El diagrama de estructura de datos representa de manera gráfica el diseño lógico

de nuestra base de datos. Está basado en representaciones que interconectan
tablas (entidades) mediante ligas. Puede que existan dos o más entidades,
incluyendo atributos que nos ayuden a describir la relación.

La representación gráfica del diagrama de estructura consta de:

Celdas: representan los campos del registro.

Líneas: representan los enlaces entre los registros.

El diagrama de estructura de datos es una técnica necesaria para modelar los datos
que serán utilizados en el sistema, nos ayuda a identificar las relaciones adyacentes
entre entidades y nos describe de forma colectiva un componente del sistema. La
representación gráfica se basa en acomodar todos los campos de un registro en un
conjunto de celdas que tienen relación con otro(s) registro(s).

3.6 Modelado de decisiones estructurales

El analista debe ser capaz de diferenciar las decisiones lógicas y estructuradas que
ocurren dentro de la organización. Así mismo, él deberá servir de apoyo a los
directivos para tomar la mejor elección entre alternativas basadas en estimaciones
previamente capturadas en el proceso de obtención de requerimientos.
3.6.1. Árboles de decisión
Se utiliza cuando ocurren ramifiaciones complejas en el proceso de decisión, estos
árboles se dibujan de lado del papel de ahí se ramifican hacia la derecha, esta
orientación permite al analista escribir en las ramas para describir condiciones y
acciones.
Es conveniente diferenciar entre las condiciones y las acciones al momento de
dibujar estos árboles, las acciones se presentan durante un periodo de tiempo, para
este fin se debe dibujar un nodo cuadrado para indicar una acción y un círculo para
representar una condición.
El uso de está notación mejora la legibilidad del árbol, esta notación significa en
círculo un “SI” y en un cuadrado un “Entonces”
Para poder dibujar el arbol de decisiones debemos de tomar en cuenta la
identificación de todas las posibles condiciones y acciones, junto con su orden y

Página 7 de 12
sincronización, la construccion del árbol de izquierda a derecha y recordar que no
son simétricos.
El árbol de desiciones tiene dos ventajas, saca provecho de la escritura secuencial
de sus ramas encontrando condiciones y acciones en algunas ramas.
3.6.2. Matrices
Aparte del árbol de desiciones existe la tabla de decisión, que sé encuentra
representado por una matriz de renglones y columnas que indican ciertas
condiciones y acciones por lo que se emplea para el analisis de funciones dentro de
una organzación.
La tabla de decisión contempla cuatro criterios:
1. Identificación de Condiciones.- Es la identificación de condiciones que
indican mayor valor y son relevantes para determinada condición.
2. Entrada de Condiciones.- muestra condiciones que permite identificar su
característica de ocurrir o no ocurrir para tomar una decisión.
3. Identificación de Acciones.- Es la identificaciones de acciones según la
jerarquía de ejecución.
4. Entrada de Acciones.-Muestra acciones especificas derivadas de ciertas
condiciones ya definidas.
Una vez definida la tabla de desiciones a partir de la recopilación de información,
podemos identificar más facilmente donde pueda haber huecos en condiciones,
relaciones o la misma información que no se detecto o considero, por lo que se
produce un análisis más detallado.
3.7. Diagramas de estados
Los diagramas de estados determinan los métodos de clase y se utilizan para
examinar los diferentes estados que puede tener un objeto, normalmente los objetos
se crean, sufren cambios y son eliminados o modificados. Los objetos y estados
precisan algunas características:
• Los objetos existen en diversos estados, que son las condiciones de un
objeto en un momento específico.
• Los valores de atributo definen el estado en el que se encuentra el objeto.
• En ocasiones, hay un atributo, como el estatus de un pedido (pendiente,
empaquetado, enviado, recibido, etc.) que indica el estado.
• En el estado, el nombre del objeto se escribe con cada palabra en mayuscula,
debe ser único y significativo para los usuarios.

Página 8 de 12
 • Un estado también tiene acciones de entrada y salida (las cosas que el objeto
debe hacer cada vez que entra o sale de un estado determinado).
• Un evento es algo que sucede en un momento y lugar específico, provocando
un cambio en el estado del objeto.
• Pueden darse eventos separados, por ejemplo, en un pedido que está a la
espera de ser llenado, donde los eventos separados serían el pedido recibido
o pedido completado.
• Un evento causa la transición y ocurre cuando se cumple una condición.
• Una condición es algo que se evalúa como verdadero o falso y puede ser tan
simple como hacer clic para confirmar el pedido. También puede ser una
condición que ocurre en un método, como un artículo que está agotado.Las
condiciones se muestran entre corchetes junto a la etiqueta del evento.
• También hay eventos diferidos o aquellos que se mantienen hasta que un
objeto cambia de estado que puede aceptarlo. Un ejemplo es un usuario que
ingresa algo cuando un procesador de textos está realizando una copia de
seguridad automática; una vez completada la copia de seguridad, el texto
aparece en el documento.
• Cuando un objeto cambia de estado, algunos de los atributos cambian sus
valores, cuando esto último sucede, debe haber un método para cambiar los
atributos.
• Cada uno de los métodos necesitaría una pantalla o un formulario web para
agregar los atributos, que se convierten en los objetos de la interfaz.
• La pantalla o formulario web posee más controles en los objetos que sólo los
atributos cambian. Por lo general, se requieren claves primarias, información
de identificación y otros atributos para una buena interfaz de usuario.
• La excepción es un evento temporal, que puede usar tablas de base de datos
o una cola que contiene la información.
Los diagramas de estado no son creados para todas las clases, sólo cuando se dan
las siguientes condiciones:
1. Una clase tiene un complejo ciclo de vida.
2. Una instancia de una clase puede actualizar sus atributos de varias maneras
a lo largo del ciclo de vida.

Página 9 de 12
 3. Una clase tienen un ciclo de vida operacional.
4. Dos clases dependen una de la otra.
5. El comportamiento actual del objeto depende de lo que sucedio
anteriormente.

Fig.3 Diagrama de estados donde se muestra la evolucion de un estudiante

potencial a graduado. (Kendall y Kendall, 2011, p238).
3.8. Expediente de los requerimientos de un sistema de información.
La plantilla para elaborar el documento de requerimientos de software debe dividirse
en las siguientes secciones:
• Propósito: nombre o título del software que se está especificado en el
documento, incluyendo su número de versión. También se describen cuáles
componentes o partes del alcance del producto están incluidas en el
documento, estableciendo si cubre la totalidad del software, sólo una parte
del sistema, subsistema o subgrupo de procesos.

Página 10 de 12
• Alcance del producto/software: descripción corta del alcance del software
que se está especificando, incluyendo el propósito u objetivo general, los
beneficios que brinda al área de negocio y organización, la relación de los
objetivos del software con los objetivos corporativos, así como las estrategias
de negocio. Se puede hacer referencia a otros documentos.
• Referencias: aquí se pueden incluir otros documentos impresos,
documentos o direcciones electrónicos que complementen la documentación
de requerimientos de software
• Funcionalidades del producto: lista de las funcionalidades principales del
software, que se especifican en el documento de requerimientos. Cada
funcionalidad puede estar compuesta por uno o varios requerimientos del
software.
• Clases y características de usuarios: se clasifican los usuarios que
utilizarán el producto. La clasificación puede ser en función a la frecuencia
de uso, el grupo de funcionalidades utilizadas, los privilegios de seguridad, el
nivel de experiencia y otros parámetros.
• Entorno operativo: se describe el entorno operativo en el que se
desenvolverá el sistema, software, módulo o grupo de funcionalidades,
mencionando aspectos como la plataforma de hardware, las versiones de
sistema operativo y otros sistemas o componentes con los que debe coexistir.
• Requerimientos funcionales: en esta sección de la plantilla, ilustramos
cómo organizar los requerimientos funcionales de software, de acuerdo a la
funcionalidad de producto o sistema. Aquí se listan las funcionalidades, así
como los requerimientos funcionales (que también se pueden documentar en
una matriz de trazabilidad de requerimientos).
• Reglas de negocio: listado de reglas y principios que aplican a todo el
conjunto de requerimientos de software contenidos en el documento. Por
ejemplo, cuáles individuos o roles pueden desempeñar cierta función bajo
ciertas circunstancias.
• Requerimientos de interfaces externas: describe las características y
atributos de las interfaces con el usuario (gui), las interfaces con el hardware,
las interfaces con otros sistemas y las interfaces de comunicaciones.
• Requerimientos no funcionales: son los que especifican criterios para
evaluar la operación de un servicio de tecnología de información, en
contraste con los requerimientos funcionales que especifican los
comportamientos específicos .

Página 11 de 12
REFERENCIAS

Pressman, S. (2010). Análisis y Diseño de Software. Pearson

Page-Jones, M. (1988). La Guía Práctica del Diseño de Sistemas Estructurados
Pearson.

Página 12 de 12