El documento describe las técnicas de análisis de requerimientos para determinar las necesidades de un sistema de software, incluyendo entrevistas, cuestionarios, revisión de registros y observación. Explica los diagramas de flujo de datos que muestran las entradas, procesos y salidas de un sistema usando cuatro símbolos: entidades externas, procesos, almacenes de datos y flujos de datos. Los diagramas se descomponen en niveles de detalle creciente.

1. ANÁLISIS Y DISEÑO
ESTRUCTURADO DE
SISTEMAS

2. Análisis de requerimientos
Conjunto de técnicas y procedimientos que nos
permiten conocer los elementos necesarios para
definir un proyecto de software.
La IEEE los divide en:
resolver un problema o
Funcionales
alcanzar un objetivo
satisfacer un contrato, un
estándar, una especificación u
No funcionales
otro documento formalmente
impuesto

3. Actividades en la determinación de
requerimientos
Actividad Descripción
Anticipación de Prever las características del sistema con base
requerimientos a la experiencia previa. Esto puede llevar al
analista a investigar áreas y aspectos que de
otra forma no serían tomados en cuenta.
Investigación de Estudio y documentación del sistema actual
requerimientos utilizando para ello técnicas para hallar
hechos, análisis de flujo de datos y análisis de
decisión.
Especificación de Análisis de los datos que describen el sistema
requerimientos para determinar que tan bueno es su
desempeño, qué requerimientos se deben
satisfacer y las estrategias para alcanzarlos.

4. Especificaciones de
requerimiento
 Es la descripción de las características del
nuevo sistema. Tiene 3 partes relacionadas
entre sí:
Análisis de datos basados en hechos
reales
Identificación de requerimientos
esenciales
Selección de estrategias para satisfacer
los requerimientos

5. Análisis de requerimientos
 Se debe establecerse la comunicación
necesaria para el análisis, de forma que se
asegure el reconocimiento del problema.
 El analista debe establecer contacto con el
equipo técnico y de gestión del usuario/cliente
y con la empresa que vaya a desarrollar el
software.
 El objetivo del analista es reconocer los
elementos básicos del programa tal como lo
percibe el usuario/cliente.

6. Análisis de requerimientos
 El analista debe evaluar el flujo y estructura de
la información
 Refinar en detalle todas las funciones del
programa
 Establecer las características de la interface
del sistema
 Una vez que se hayan descrito las
funcionalidades básicas, comportamiento,
interface e información, se especifican los
criterios de validación para demostrar una
comprensión de una correcta implementación
de los programas.

7. Requerimientos básicos
 ¿Cuál es el proceso básico de la empresa?
 ¿Qué datos utiliza o produce este proceso?
 ¿Cuáles son los límites impuestos por el
tiempo y la carga de trabajo?
 ¿Qué controles de desempeño utiliza?

8. Requerimientos básicos
Para comprender el proceso, se debe responder
estas interrogantes:
 ¿Cuál es la finalidad de esta actividad dentro de
la empresa?
 ¿Qué pasos se siguen para llevarla a cabo?
 ¿Dónde se realizan estos pasos?
 ¿Quiénes lo realizan?
 ¿Cuánto tiempo tardan en efectuarlos?
 ¿Con cuánta frecuencia lo hacen?
 ¿Quiénes emplean la información resultante?

9. Requerimientos de las
transacciones de los usuarios
Para conocer y entender los requerimientos de las
transacciones, los analistas sin lugar a dudas formulan
preguntas como:
 ¿Qué es lo que forma parte de la transacción que está
siendo procesada?
 ¿Qué es lo que inicia la transacción?
 ¿Quién inicia la transacción?
 ¿Con qué propósito?
 ¿Con que frecuencia ocurre?
 ¿Qué volumen esta asociado a la transacción?
 ¿Existen diferentes condiciones que pueden afectar la
forma en que se procesan las transacciones?
 ¿Qué detalles son necesarios para procesar la
transacción?

10. Requerimientos de decisión de los
usuarios
 Los analistas que investigan los sistemas para el
soporte de las decisiones deberán considerar otras para
determinar los requerimientos de las decisiones:
 ¿Que información se utiliza para tomar una decisión?
 ¿Cuál es la fuente de más información?
 ¿Qué sistema transaccional produce datos utilizados en
el proceso de la decisión?
 ¿Qué otros datos son necesarios y no es posible
obtener del proceso transaccional?
 ¿Que datos originan las fuentes externas a la
organización?
 ¿Cómo se deben procesar los datos para producir
información necesaria?

11. Requerimientos de la
organización
Cuando los analistas estudian sistemas para
un departamento también evalúa las
implicaciones para los demás departamentos
con los que interactúa el sistema bajo
investigación.

12. Técnicas para encontrar
hechos
Entrevistas
Cuestionarios
Revisión de los registros
Observación

13. Diagrama de flujo de datos
Los diagramas de flujos de datos son una
técnica de análisis estructurado que van de
lo general a lo específico muestran las
posibles entradas, procesos y salidas del
sistema.
Los diagramas son usados cuando los
analistas tratan de comprender los
requerimientos de información de los usuarios
de una manera gráfica utilizando solo cuatro
símbolos combinados entre sí.

14. Diagrama de flujo de datos
Tiene cuatro ventajas principales de la forma en
que se mueven los datos a través del sistema,
estas son:
1. Libertad para realizar en forma muy temprana la
implementación técnica del sistema.
2. Comprensión de las interrelaciones de los
sistemas y subsistemas.
3. Comunicación del conocimiento del sistema
actual a los usuarios por medio del diagrama de
flujo de datos.
4. Análisis de un sistema propuesto para
determinar si han sido definidos los datos y
procesos necesarios.

15. Entidad Externa
 Representa personas, organizaciones, o sistemas que no
pertenecen al sistema.
 En el caso de que las entidades externas se comunicasen
entre sí, esto no se contemplaría en el diagrama, por estar
fuera del ámbito de nuestro sistema
 Puede aparecer en los distintos niveles de DFD para
mejorar su comprensión, aunque normalmente sólo
aparecerá en el diagrama de contexto.
 Pueden aparecer varias veces en un mismo diagrama,
para evitar entrecruzamientos de líneas.
 Suministra información acerca de la conexión del sistema
con el mundo exterior.

16. Procesos
 Cuando un flujo de datos entra en un proceso
sufre una transformación. Un proceso no es
origen ni final de los datos, sólo lugar de
transformación de ellos.
 Un proceso puede trasformar un dato en
varios.
 Es necesario un proceso entre una Entidad
Externa y un Almacén de datos.
 Un proceso puede representarse señalando
una localización. La localización expresa la
unidad o área dentro de la organización donde
se realiza el proceso.

17. Almacén de Datos
 Representa la información en reposo
 No puede crear, destruir ni transformar datos
 No puede estar comunicado directamente con otro
almacén o Entidad externa
 El flujo de datos (Entrada y Salida) no lleva nombre
cuando incide sobre su contenido completo
 No debe estar referido al entorno físico, y por tanto,
no se diferencian los ficheros convencionales de las
bases de datos
 No se representa la clave de acceso a este almacén
sino sólo la operación que se realiza (lectura,
escritura, actualización)

18. Diagrama de flujo de datos
Utilizan cuatro símbolos básicos como los son (Gane y
Sarson):
 un cuadrado para representar las
entidades del sistema
 una flecha para representar los
flujos dentro del sistema
 un rectángulo con esquinas
redondas para representar los
procesos
 un rectángulo con un lado abierto
para representar los
almacenamientos de datos.

19. Descomposición por Niveles
 El desarrollo de un DFD ayuda en la
identificación de los datos de la transacción en
el modelo de datos.
 Sus niveles son:
Nivel 0: Diagrama de contexto.
Nivel 1: Diagrama de nivel superior.
Nivel 2: Diagrama de detalle o expansión.

20. Diagrama de Contexto: Nivel 0
 En el diagrama de contexto se caracterizan todas
las interacciones que realiza un sistema con su
entorno (entidades externas)
 Se dibuja un sólo proceso que representa al
sistema en cuestión y se escribe su nombre en
dicha burbuja como un sustantivo común más
adjetivos. De él solamente parten los flujos de
datos que denotan las interrelaciones entre el
sistema y sus agentes externos, no admitiéndose
otros procesos ni almacenamientos en el dibujo.
 Resulta de gran utilidad para los niveles
posteriores de análisis como herramienta de
balanceo.

21. Diagrama de Nivel Superior:
Nivel 1
 En el diagrama de nivel superior se plasman
todos los procesos que describen al proceso
principal.
 En este nivel los procesos no suelen
interrelacionarse directamente, sino que entre
ellos debe existir algún almacenamiento o entidad
externa que los una.
 Esta regla de construcción sirve como ayuda al
analista para contemplar que en un nivel tan
elevado de abstracción (DFD Nivel 1) es
altamente probable que la información que se
maneja requiera ser almacenada en el sistema
aunque no esté especificado por un Requisito

22. Diagrama de Detalle o
Expansión: Nivel 2
 En un diagrama de nivel 2 o mayor,
comienzan a explotarse las excepciones a los
caminos principales de la información dado
que aumenta progresivamente el nivel de
detalle. De aquí en adelante se permiten los
flujos entre procesos.
 Puede considerarse el máximo para ser
validado en forma conjunta con el usuario
dado que en los niveles posteriores el alto
grado de complejidad del diagrama puede
resultar de muy difícil lectura para personas
ajenas al equipo de sistemas.

25. Actividad
 Genere un diagrama de flujo de
datos para una biblioteca que
necesita gestionar el préstamo y
devolución de libros