Diagrama de fluxo de dado

Introdução

Até o final da década de 70, a grande maioria dos projetos de desenvolvimento de sistemas começava pela criação de um documento elaborado pelo analista de sistemas, contendo uma descrição textual sobre o que ele entendia ser os requisitos do usuário. Esses documentos muitas vezes denominados de especificação funcional padeciam de alguns problemas: eram monolíticos e, portanto, de difícil compreensão, uma vez que era necessária toda a especificação funcional, para poder compreendê-la; eram redundantes, dado que a mesma informação era muitas vezes repetida em diversas partes diferentes do documento, tornando difícil a sua atualização e revisão, conduzindo a um problema grave de inconsistência; eram ambíguos, pois o detalhamento dos requisitos do usuário podia ser interpretado de modo distinto pelo analista de sistemas, pelo projetista, pelo programador e pelo próprio usuário; eram de difícil manutenção, posto que a especificação funcional quase sempre era obsoleta no final do processo de desenvolvimento do sistema, o que muitas vezes ocorria no final da fase de análise, devido aos motivos anteriormente explicitados.
Esses problemas provocaram uma reação da comunidade de engenharia de software que levou à percepção de que a atividade de desenvolvimento de sistema compreendesse especificações funcionais que fossem gráficas, particionadas e de redundância mínima conforme visto em Yourdon (1992).
Para DeMarco (1989) a análise tradicional de sistemas, caracterizada por especificações maciças e pesadas começou a se modificar no final da década de 70, dando lugar a uma nova abordagem denominada análise estruturada, que dizia respeito fundamentalmente a um novo tipo de especificação funcional, a especificação estruturada.
O termo “análise estruturada” foi popularizado por DeMarco (1989) quando então introduziu e nomeou símbolos gráficos que possibilitariam ao analista criar modelos de fluxo de informação, sugeriu uma heurística para o uso desses