Análise × projeto

Desenvolver sistemas é um processo sistemático, com fases de planejamento, análise, projeto, implantação e manutenção. Este tutorial se concentra nas duas do meio. ^{[1] [2]}

A análise e projeto de sistemas olha ao mesmo tempo para três coisas: os sistemas, os processos e a tecnologia. ^{[3] [4]}

O que é um sistema

A palavra vem do grego systema, um conjunto organizado de partes. Um sistema é um agrupamento ordenado de componentes interdependentes, ligados segundo um plano para atingir um objetivo específico. Exemplos: controle de tráfego, folha de pagamento, biblioteca automatizada, gestão de pessoas.

Todo sistema tem três restrições básicas:

• tem estrutura e comportamento pensados para um objetivo predefinido;
• seus componentes são interligados e interdependentes;
• os objetivos da organização têm prioridade sobre os dos subsistemas.

Propriedades

• Organização: estrutura e ordem entre os componentes.
• Interação: a forma como os componentes operam entre si, como compras e produção, ou folha de pagamento e pessoal.
• Interdependência: a saída de um subsistema é a entrada de outro.
• Integração: as partes trabalham juntas, mesmo que cada uma tenha uma função própria.
• Objetivo central: pode ser real ou apenas declarado; não é raro uma organização anunciar um objetivo e operar em função de outro. Os usuários precisam conhecê-lo cedo na análise.

Elementos

• Entradas e saídas: as entradas são o que entra para ser processado; as saídas, o resultado útil para o usuário.
• Processador: transforma entradas em saídas. Quando a especificação da saída muda, o processamento muda junto.
• Controle: o subsistema de decisão que orienta entradas, processamento e saídas.
• Realimentação (feedback): compara a saída com o objetivo e informa o controle. Na teoria de sistemas, a realimentação negativa corrige o desvio e estabiliza o sistema; a positiva reforça a tendência atual. ^[6]
• Ambiente: o “supersistema” em que a organização opera, com fornecedores, concorrentes e leis que impõem restrições.
• Fronteiras e interfaces: a fronteira define o que está dentro do sistema e a sua esfera de controle; as interfaces são os pontos de contato com outros sistemas.

Tipos, modelos e informação

Tipos de sistema

Os sistemas de informação feitos pelo homem reúnem hardware, software, comunicação, dados e aplicações para produzir a informação de que a organização precisa. Podem ser formais (memorandos e instruções que descem da direção), informais (a rede de colegas que resolve o dia a dia) ou baseados em computador (reservas, bancos, bibliotecas).

Modelos de sistema

• Esquemático: um diagrama em duas dimensões com os elementos e as suas ligações.
• De fluxo: mostra o fluxo ordenado de material, energia e informação; o PERT é um exemplo.
• Estático: representa um par de relações, como atividade e tempo; o gráfico de Gantt é um exemplo.
• Dinâmico: mostra o estado em mudança constante, com entradas, processador, programas e saídas.

Categorias de informação

Ciclo de vida (SDLC)

O ciclo de vida de desenvolvimento de sistemas (SDLC) é um modelo conceitual com políticas e procedimentos para criar ou alterar sistemas. Um bom SDLC entrega um sistema de qualidade, que atende ao cliente, dentro de prazo e custo, e funciona bem na infraestrutura atual e futura. ^[5]

1. Planejamento e viabilidade: define o problema e o escopo, os objetivos do sistema novo, riscos, restrições, integração e segurança; termina com o relatório de viabilidade e o cronograma.
2. Análise e especificação: levanta, analisa e valida as informações, define requisitos e protótipos, avalia alternativas e prioriza; termina com a especificação de requisitos de software (SRS).
3. Projeto: desenha a aplicação, a rede, os bancos de dados, as interfaces com o usuário e com outros sistemas; cria planos de contingência, treinamento, manutenção e operação; termina com o documento de projeto.
4. Implementação: codifica, integra os módulos, testa segundo o plano de testes e instala o sistema no seu ambiente.
5. Manutenção e suporte: atende os usuários, corrige os defeitos que sobraram e incorpora novos requisitos.

O analista de sistemas

É quem conhece o sistema a fundo e conduz o projeto, alinhando os objetivos do sistema de informação aos da organização. Suas principais funções:

• entender os requisitos dos usuários com técnicas de levantamento e priorizá-los por consenso;
• analisar e avaliar até chegar a um sistema adequado e fácil de usar;
• propor alternativas, escolher a melhor e quantificar custos e benefícios;
• escrever especificações que usuários e programadores entendam;
• garantir um projeto lógico modular e planejar avaliações periódicas depois da entrada em produção.

Levantamento de requisitos

Um requisito é uma característica essencial do sistema novo: capturar ou processar dados, controlar atividades, produzir informação ou apoiar a gestão. Determinar requisitos envolve três atividades:

• Antecipação: prever características a partir da experiência. Ajuda a olhar áreas que passariam despercebidas, mas pode introduzir vieses.
• Investigação: estudar e documentar o sistema atual com técnicas de levantamento, protótipos e ferramentas; é o coração da análise.
• Especificação: analisar os dados levantados, identificar os requisitos essenciais e descrever o sistema novo.

O resultado é a especificação de requisitos de software (SRS), que deve ser completa, sem ambiguidade e sem jargão, cobrir as necessidades operacionais, táticas e estratégicas e usar recursos gráficos. A antiga norma IEEE 830 sobre SRS foi substituída pela ISO/IEC/IEEE 29148. ^[10]

Técnicas de levantamento

O JAD (Joint Application Design) foi criado por Arnie Lind na IBM Canadá, em 1974, e formalizado depois por Tony Crawford e Chuck Morris. ^[9]

Qualidades de um bom requisito

Estudo de viabilidade

É a investigação preliminar que ajuda a direção a decidir se vale a pena desenvolver o sistema. O objetivo é entender o escopo do problema, não resolvê-lo. O resultado é uma proposta formal de sistema, que serve de documento de decisão.

Passos: formar a equipe e nomear um líder; desenhar fluxogramas do sistema; identificar as deficiências do atual e definir metas; listar as alternativas; avaliar a viabilidade de cada uma; comparar desempenho e custo; classificar e escolher a melhor; e levar a proposta à direção.

Na literatura de gestão de projetos, essas dimensões aparecem resumidas na sigla TELOS: técnica, econômica, legal, operacional e de cronograma. ^[11]

Análise estruturada

A análise estruturada é um método que permite entender o sistema de forma lógica, com ferramentas gráficas que vão da visão geral aos detalhes. Ela é gráfica, divide os processos para dar uma visão clara do fluxo e é lógica, não física: não depende de fornecedor nem de hardware. ^[12] Suas ferramentas são o DFD, o dicionário de dados, as árvores e tabelas de decisão, o português estruturado e o pseudocódigo.

Diagrama de fluxo de dados (DFD)

Proposto por Larry Constantine e difundido por Ed Yourdon, Tom DeMarco e por Chris Gane e Trish Sarson no fim dos anos 1970, o DFD mostra como os dados fluem entre as funções do sistema: o que é processado, que transformações ocorrem, o que é guardado e para onde vão os resultados. ^{[13] [14]}

O diagrama de contexto é o nível 0: mostra o sistema inteiro como um único processo, cercado pelas entidades externas. Depois, cada processo é detalhado em níveis inferiores, de cima para baixo.

Dicionário de dados

Repositório estruturado com a descrição de todos os elementos do DFD: fluxos, depósitos, dados e processos. Melhora a comunicação com o usuário e é a base do banco de dados. ^[16]

Árvore e tabela de decisão

Considere a regra: quem paga adiantado ganha 5% de desconto; quem não paga adiantado só ganha o desconto se a compra for de R$ 10.000 ou mais e for cliente regular.

A tabela de decisão mostra todas as combinações de uma vez. Ela tem quatro quadrantes: condições (acima, à esquerda), entradas de condição (acima, à direita), ações (abaixo, à esquerda) e entradas de ação (abaixo, à direita). S = sim, N = não, – = indiferente, X = executar. ^[17]

Português estruturado e pseudocódigo

O português estruturado descreve a lógica com frases imperativas e as estruturas da programação estruturada (sequência, decisão e repetição), sem sintaxe rígida. ^[19] A mesma regra fica assim:

SE o cliente pagou adiantado
    ENTÃO dar 5% de desconto
SENÃO
    SE a compra for de R$ 10.000 ou mais E o cliente for regular
        ENTÃO dar 5% de desconto
    SENÃO
        não dar desconto
    FIM-SE
FIM-SE

O pseudocódigo é parecido, mas já pensa na lógica do programa: independe de linguagem e costuma substituir os fluxogramas no projeto físico.

Qual ferramenta usar

• DFD: para documentar o sistema, em alto ou baixo nível;
• dicionário de dados: para organizar os requisitos de dados;
• português estruturado: quando há muitos laços e ações complexas;
• tabela de decisão: quando há muitas condições e a lógica é complexa;
• árvore de decisão: quando a ordem das condições importa e elas são poucas.

Projeto do sistema e dados

O projeto transforma a SRS num formato implementável e decide como o sistema vai operar. Entradas: declaração de trabalho, plano de requisitos, análise da situação atual e requisitos propostos (modelo conceitual de dados, DFDs revisados e metadados). Saídas: mudanças de infraestrutura e organização, esquema de dados (em geral relacional), metadados, mapa da estrutura do programa, código ou pseudocódigo de cada módulo e um protótipo.

Tipos de projeto

• Lógico: representação abstrata dos fluxos, entradas, saídas e depósitos de dados, com DFDs e modelos E-R.
• Físico: como os dados entram, são validados, processados e exibidos; define mídias, banco de dados, cópias de segurança, plano de testes e de implantação.
• Arquitetural (alto nível): a estrutura e o comportamento do sistema e a relação entre os módulos.
• Detalhado: vem depois do arquitetural e desenvolve cada módulo.

Modelo entidade-relacionamento

O modelo conceitual de dados captura o máximo de significado sobre os dados da organização. O mais usado é o modelo entidade-relacionamento (E-R), publicado por Peter Chen em 1976. ^{[20] [21]}

• Entidade: algo distinto do mundo real, como aluno, curso ou fornecedor.
• Relacionamento: uma dependência com significado entre entidades, como “professor ministra curso”.
• Atributo: uma propriedade de uma entidade ou relacionamento, como o nome do aluno.

Entre dois conjuntos de dados há três tipos de relacionamento: um para um (1:1), um para muitos (1:N) e muitos para muitos (N:M). A figura também mostra entidades fracas e atributos-chave, multivalorados, compostos e derivados.

Organização e acesso a arquivos

O acesso sequencial percorre os registros do primeiro ao último e é eficiente quando se precisa de quase todos; o acesso direto vai ao endereço do registro. Os arquivos de uma organização podem ser: mestre (dados atuais, como clientes), tabela (mestre que muda pouco, como CEPs), transação (movimento do dia a dia, que atualiza o mestre), temporário, espelho (cópia exata, para continuidade), log (histórico de mudanças, para auditoria e recuperação) e arquivo morto (versões históricas).

Estratégias de projeto

• De cima para baixo (top-down): começa no módulo principal e o divide em submódulos cada vez mais simples, até não haver mais o que dividir.
• De baixo para cima (bottom-up): começa pelos módulos mais básicos e os agrupa em módulos maiores, até chegar ao principal. ^[22]

Projeto estruturado

O projeto estruturado, de Yourdon e Constantine, parte dos DFDs para montar o diagrama de estrutura: caixas que representam módulos, ligadas por linhas que mostram quem chama quem. O objetivo é reduzir a complexidade e aumentar a modularidade. ^{[15] [23]}

• o módulo de controle dirige os módulos subordinados; o módulo de biblioteca é reutilizável e pode ser chamado de vários pontos;
• o diagrama é centrado em transformação quando todas as transações seguem o mesmo caminho, e centrado em transação quando seguem caminhos diferentes;
• a modularização permite testar primeiro as interfaces críticas, dividir o trabalho entre vários programadores e reutilizar código.

Acoplamento e coesão

Dois conceitos medem a qualidade de um projeto modular. Acoplamento é quanto um módulo depende dos outros; quanto mais forte, mais difícil implementar e manter. Coesão é quanto as partes de um módulo pertencem juntas. ^{[24] [25]}

• Acoplamento, do pior ao melhor: de conteúdo (um módulo altera o interior de outro); comum (compartilham dados globais); externo (compartilham um formato ou protocolo externo); de controle (um passa parâmetros que controlam o outro); de estrutura (passam estruturas de dados inteiras); de dados (passam só os dados necessários).
• Coesão, da pior à melhor: coincidental (partes sem relação); lógica (funções parecidas agrupadas); temporal (executadas no mesmo momento, como a inicialização); procedural (seguem uma ordem de execução); comunicacional (operam sobre os mesmos dados); sequencial (a saída de uma parte é a entrada da seguinte); funcional (tudo contribui para uma única tarefa).

Entrada, saída e formulários

Projeto de entrada

A qualidade da saída depende da qualidade da entrada. Os objetivos são: desenhar a entrada de dados e os seus procedimentos, reduzir o volume digitado, desenhar documentos-fonte e telas, e criar validações. Para evitar erros: formulários claros, com espaço suficiente e instruções; menos toques de teclado; e retorno imediato de erro. Os métodos incluem entrada em lote, on-line, por formulários legíveis por máquina e interativa.

Os controles de integridade da entrada verificam formato e completude de cada campo, e os registros de transação criam a trilha de auditoria de todas as mudanças no banco de dados.

Projeto de saída

A saída deve servir ao propósito, atender o usuário, ter a quantidade e o formato certos, chegar à pessoa certa e a tempo. As saídas externas vão para fora do sistema (algumas voltam como entrada, como um boleto); as internas apoiam a gestão, em três tipos de relatório:

• detalhado: a informação quase sem filtro;
• resumo: tendências e totais, para quem não quer detalhes;
• de exceção: só o que foge de um padrão ou limite.

Relatórios devem trazer data e hora de emissão, título e paginação; formulários pré-impressos, número de versão e data de vigência.

Formulários

Formulários servem para entrada de dados; relatórios, só para leitura. Um bom formulário é simples, com sequência lógica e rótulos claros, cumpre o propósito, facilita o preenchimento correto e a navegação. O texto original ainda descreve formulários em papel (planos, jogos com carbono, contínuos e sem carbono), hoje raros.

Documentação

Documentar reduz o tempo de parada, corta custos, acelera a manutenção, facilita o treinamento e a comunicação entre técnicos e não técnicos. A documentação precisa ser atualizada com regularidade. São quatro tipos:

Testes, implantação e manutenção

Testes e garantia da qualidade

O teste verifica se o software faz o que os requisitos pedem; um teste bem-sucedido é o que encontra erros. Ele começa pelos módulos e avança até o sistema integrado, seguindo uma estratégia, um plano, casos e procedimentos de teste e o registro dos resultados. Os tipos principais são o unitário, o de integração e o funcional (positivo, com entradas válidas, e negativo, com entradas inválidas). O tutorial Testes de software trata o assunto em detalhe.

A garantia da qualidade de software (SQA) revisa produtos e processos ao longo de todo o ciclo, em quatro níveis: revisão do código contra as regras (walk-through), compilação e ligação em todas as plataformas, execução em condições variadas e teste de desempenho.

Treinamento

Um sistema bem projetado pode fracassar se for mal operado. Os operadores aprendem as rotinas, as falhas comuns e o que fazer em cada uma; os usuários aprendem a operar o sistema e a resolver problemas simples. O treinamento pode ser conduzido por instrutor, em sala presencial ou virtual, ou no ritmo do aluno, com cursos multimídia ou pela web.

Conversão

É a migração do sistema antigo para o novo. O plano de conversão lista os arquivos a converter, os documentos e procedimentos novos, os controles, os responsáveis e o cronograma.

Depois da implantação, a revisão pós-implantação (PIER) compara custos, benefícios e prazos reais com os previstos, aponta forças e fraquezas e melhora as estimativas dos próximos projetos. Participam a equipe do projeto, a direção, os usuários e a gestão estratégica.

Manutenção

Manter é conservar o sistema de acordo com os seus requisitos; melhorar é incorporar requisitos novos. A norma ISO/IEC 14764 classifica a manutenção em quatro tipos: ^[26]

• corretiva: corrige defeitos encontrados, em geral relatados pelos usuários;
• adaptativa: adapta o sistema a mudanças no ambiente, como um novo sistema operacional ou uma nova lei;
• perfectiva: melhora desempenho, usabilidade ou acrescenta funções pedidas pelos usuários;
• preventiva: antecipa problemas que ainda não se manifestaram.

Segurança e auditoria

Auditoria de sistemas

A auditoria revisa o desempenho de um sistema em operação para comparar o real com o planejado, verificar se os objetivos continuam válidos e foram atingidos, garantir a confiabilidade das informações e proteger contra fraudes. O auditor deve participar desde o início do desenvolvimento, para que o sistema já nasça auditável.

A trilha de auditoria (audit trail) é o registro de quem acessou o sistema e o que fez em cada período; permite rastrear como os dados mudaram. ^[27] A auditoria pode ser feita em volta do computador (processar manualmente amostras de entrada e comparar com a saída do sistema) ou através do computador (examinar resultados intermediários pela trilha e por totais de controle).

Segurança

Proteger dados, software e hardware contra roubo, acesso ou alteração não autorizados e danos acidentais. Envolve a privacidade (ninguém acessa os dados de alguém sem permissão) e a integridade (a qualidade e a confiabilidade dos dados). As medidas de controle incluem:

• cópias de segurança: completas periódicas, incrementais mais frequentes, guardadas em local remoto e, em sistemas críticos, espelhamento das transações;
• controle de acesso físico: fechaduras, biometria, crachás e registro de quem lê ou altera dados;
• controles lógicos: senhas, criptografia, treinamento dos funcionários, antivírus e firewall.

Análise de risco

Risco é a possibilidade de perder algo de valor. A análise identifica os componentes do sistema, as ameaças a cada um e o prejuízo se elas se concretizarem. A gestão de risco é contínua: identificar medidas de segurança, calcular o custo de cada uma, compará-lo com a perda esperada, escolher e implantar as medidas e revisá-las periodicamente.

Orientação a objetos e UML

Na abordagem orientada a objetos, estrutura e comportamento ficam juntos em pequenos módulos que combinam dados e processos. Ela facilita mudanças a baixo custo, promove o reúso, simplifica a integração de componentes e o projeto de sistemas distribuídos. ^[28]

Elementos e características

• Objeto: algo do domínio do problema, identificado por dados e comportamento, como um aluno ou uma conta bancária.
• Classe: o molde que agrupa objetos com os mesmos atributos (dados) e métodos (comportamento).
• Mensagem: a chamada de um objeto a um método de outro.
• Encapsulamento: os dados de um objeto ficam escondidos e só são acessados pelos seus métodos, o que permite mudá-los sem afetar o resto.
• Abstração: ficar só com os atributos e métodos essenciais para o problema.
• Herança: criar subclasses que herdam atributos e operações de uma classe existente.
• Polimorfismo: a mesma operação é executada de formas diferentes por classes diferentes.
• Relacionamentos: associação (duas classes colaboram), agregação (todo e partes) e generalização (classe filha baseada na mãe).

UML

A Linguagem de Modelagem Unificada (UML) é a linguagem visual padrão para modelar sistemas orientados a objetos, mantida pelo Object Management Group (OMG); a versão atual é a 2.5.1, de 2017. ^{[29] [30]}

• Modelos estáticos mostram a estrutura: diagramas de classes, de objetos e de casos de uso.
• Modelos dinâmicos mostram o comportamento em resposta a eventos: diagramas de sequência, de comunicação, de estados e de atividades.
• As operações sobre objetos são de criação e destruição (incluir um funcionário), consulta (ler o endereço, sem efeito colateral) e atualização (mudar o endereço).

Estruturada × orientada a objetos

O ciclo orientado a objetos tem análise (com o modelo de casos de uso e as classes do domínio), projeto (refina classes, atributos, métodos, interface e acesso a dados), prototipação, implementação e testes incrementais. A implementação pode usar o desenvolvimento baseado em componentes (montar o sistema com peças prontas e testadas) ou o desenvolvimento rápido de aplicações (RAD), que complementa o SDLC com ferramentas para construir e entregar em incrementos. ^[31]

Casos de uso e histórias

Um caso de uso descreve a interação entre um usuário e o sistema para atingir um objetivo, com um fluxo básico e fluxos alternativos. ^[32]

Nos métodos ágeis, os requisitos costumam ser organizados numa hierarquia que vai do objetivo de negócio à tarefa técnica, e o requisito em si é escrito como história de usuário. ^[33]

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “System Analysis and Design”, GitHub Gist, texto original deste tutorial, gist.github.com/GiovaniPM/506ed93c3796fbaeb52effff0dcda2ca.
2. Tutorialspoint, “System Analysis and Design Tutorial”, acesso em 25/09/2026, tutorialspoint.com/system_analysis_and_design/index.htm.
3. Wikipedia (em inglês), “Systems analysis”, acesso em 25/09/2026, en.wikipedia.org/wiki/Systems_analysis.
4. Wikipedia (em inglês), “Systems design”, acesso em 25/09/2026, en.wikipedia.org/wiki/Systems_design.
5. Wikipedia (em inglês), “Systems development life cycle”, acesso em 25/09/2026, en.wikipedia.org/wiki/Systems_development_life_cycle.
6. Wikipedia (em inglês), “Feedback”, acesso em 25/09/2026, en.wikipedia.org/wiki/Feedback.
7. Wikipedia (em inglês), “Management information system”, acesso em 25/09/2026, en.wikipedia.org/wiki/Management_information_system.
8. Wikipedia (em inglês), “Decision support system”, acesso em 25/09/2026, en.wikipedia.org/wiki/Decision_support_system.
9. Wikipedia (em inglês), “Joint application design”, acesso em 25/09/2026, en.wikipedia.org/wiki/Joint_application_design.
10. Wikipedia (em inglês), “Software requirements specification”, acesso em 25/09/2026, en.wikipedia.org/wiki/Software_requirements_specification.
11. Wikipedia (em inglês), “Feasibility study”, acesso em 25/09/2026, en.wikipedia.org/wiki/Feasibility_study.
12. Wikipedia (em inglês), “Structured analysis”, acesso em 25/09/2026, en.wikipedia.org/wiki/Structured_analysis.
13. Wikipedia (em inglês), “Data-flow diagram”, acesso em 25/09/2026, en.wikipedia.org/wiki/Data-flow_diagram.
14. Tom DeMarco, Structured Analysis and System Specification, Prentice Hall, 1979.
15. Edward Yourdon e Larry L. Constantine, Structured Design, Prentice Hall, 1979.
16. Wikipedia (em inglês), “Data dictionary”, acesso em 25/09/2026, en.wikipedia.org/wiki/Data_dictionary.
17. Wikipedia (em inglês), “Decision table”, acesso em 25/09/2026, en.wikipedia.org/wiki/Decision_table.
18. Wikipedia (em inglês), “Decision tree”, acesso em 25/09/2026, en.wikipedia.org/wiki/Decision_tree.
19. Wikipedia (em inglês), “Structured English”, acesso em 25/09/2026, en.wikipedia.org/wiki/Structured_English.
20. Peter P. Chen, “The Entity-Relationship Model: Toward a Unified View of Data”, ACM Transactions on Database Systems, v. 1, n. 1, 1976.
21. Wikipedia (em inglês), “Entity–relationship model”, acesso em 25/09/2026, en.wikipedia.org/wiki/Entity–relationship_model.
22. Wikipedia (em inglês), “Top-down and bottom-up design”, acesso em 25/09/2026, en.wikipedia.org/wiki/Top-down_and_bottom-up_design.
23. Wikipedia (em inglês), “Structure chart”, acesso em 25/09/2026, en.wikipedia.org/wiki/Structure_chart.
24. Wikipedia (em inglês), “Coupling (computer programming)”, acesso em 25/09/2026, en.wikipedia.org/wiki/Coupling_(computer_programming).
25. Wikipedia (em inglês), “Cohesion (computer science)”, acesso em 25/09/2026, en.wikipedia.org/wiki/Cohesion_(computer_science).
26. Wikipedia (em inglês), “Software maintenance”, acesso em 25/09/2026, en.wikipedia.org/wiki/Software_maintenance.
27. Wikipedia (em inglês), “Audit trail”, acesso em 25/09/2026, en.wikipedia.org/wiki/Audit_trail.
28. Wikipedia (em inglês), “Object-oriented analysis and design”, acesso em 25/09/2026, en.wikipedia.org/wiki/Object-oriented_analysis_and_design.
29. Wikipedia (em inglês), “Unified Modeling Language”, acesso em 25/09/2026, en.wikipedia.org/wiki/Unified_Modeling_Language.
30. Object Management Group, “Unified Modeling Language (UML)”, especificação, acesso em 25/09/2026, omg.org/spec/UML.
31. Wikipedia (em inglês), “Rapid application development”, acesso em 25/09/2026, en.wikipedia.org/wiki/Rapid_application_development.
32. Wikipedia (em inglês), “Use case”, acesso em 25/09/2026, en.wikipedia.org/wiki/Use_case.
33. Wikipedia (em inglês), “User story”, acesso em 25/09/2026, en.wikipedia.org/wiki/User_story.

Analysis × design

Systems development is a systematic process, with planning, analysis, design, deployment and maintenance phases. This tutorial focuses on the two in the middle. ^{[1] [2]}

Systems analysis and design looks at three things at once: systems, processes and technology. ^{[3] [4]}

What a system is

The word comes from the Greek systema, an organized whole. A system is an orderly grouping of interdependent components, linked according to a plan to achieve a specific goal. Examples: traffic control, payroll, an automated library, human resources management.

Every system has three basic constraints:

• it has structure and behavior designed for a predefined objective;
• its components are interconnected and interdependent;
• the organization’s objectives take priority over those of its subsystems.

Properties

• Organization: structure and order among the components.
• Interaction: how the components operate with each other, such as purchasing and production, or payroll and personnel.
• Interdependence: the output of one subsystem is the input of another.
• Integration: the parts work together, even though each has its own function.
• Central objective: it may be real or merely stated; it is not unusual for an organization to announce one objective and operate toward another. Users need to know it early in the analysis.

Elements

• Inputs and outputs: inputs are what comes in to be processed; outputs, the useful result for the user.
• Processor: turns inputs into outputs. When the output specification changes, the processing changes too.
• Control: the decision-making subsystem that guides inputs, processing and outputs.
• Feedback: compares the output with the goal and informs control. In systems theory, negative feedback corrects deviation and stabilizes the system; positive feedback reinforces the current trend. ^[6]
• Environment: the “supersystem” in which the organization operates, with suppliers, competitors and laws that impose constraints.
• Boundaries and interfaces: the boundary defines what is inside the system and its sphere of control; interfaces are the points of contact with other systems.

Types, models and information

Types of system

Man-made information systems bring together hardware, software, communication, data and applications to produce the information the organization needs. They can be formal (memos and instructions flowing down from management), informal (the network of colleagues that solves day-to-day problems) or computer-based (reservations, banking, libraries).

System models

• Schematic: a two-dimensional chart with the elements and their links.
• Flow: shows the orderly flow of material, energy and information; PERT is an example.
• Static: represents one pair of relationships, such as activity and time; the Gantt chart is an example.
• Dynamic: shows the constantly changing state, with inputs, processor, programs and outputs.

Categories of information

Life cycle (SDLC)

The systems development life cycle (SDLC) is a conceptual model with policies and procedures for creating or changing systems. A good SDLC delivers a quality system that meets customer expectations, within time and cost, and works well in the current and planned infrastructure. ^[5]

1. Planning and feasibility: defines the problem and scope, the new system’s objectives, risks, constraints, integration and security; ends with the feasibility report and the schedule.
2. Analysis and specification: gathers, analyzes and validates information, defines requirements and prototypes, evaluates alternatives and prioritizes; ends with the software requirements specification (SRS).
3. Design: designs the application, network, databases, user interfaces and interfaces with other systems; creates contingency, training, maintenance and operation plans; ends with the design document.
4. Implementation: codes, integrates the modules, tests according to the test plan and installs the system in its environment.
5. Maintenance and support: supports users, fixes the remaining defects and incorporates new requirements.

The systems analyst

The analyst knows the system inside out and leads the project, aligning the information system’s objectives with the organization’s. Their main roles:

• understand users’ requirements through fact-finding techniques and prioritize them by consensus;
• analyze and evaluate until arriving at a suitable, user-friendly system;
• propose alternatives, pick the best one and quantify costs and benefits;
• write specifications that users and programmers understand;
• ensure a modular logical design and plan periodic evaluations after go-live.

Requirements gathering

A requirement is an essential feature of the new system: capturing or processing data, controlling activities, producing information or supporting management. Determining requirements involves three activities:

• Anticipation: predicting features from experience. It helps look at areas that would otherwise be missed, but can introduce bias.
• Investigation: studying and documenting the current system with fact-finding techniques, prototypes and tools; the heart of analysis.
• Specification: analyzing the data gathered, identifying the essential requirements and describing the new system.

The result is the software requirements specification (SRS), which must be complete, unambiguous and jargon-free, cover operational, tactical and strategic needs and use graphical aids. The old IEEE 830 standard on SRS was replaced by ISO/IEC/IEEE 29148. ^[10]

Fact-finding techniques

JAD (joint application design) was created by Arnie Lind at IBM Canada in 1974 and later formalized by Tony Crawford and Chuck Morris. ^[9]

Qualities of a good requirement

Feasibility study

This is the preliminary investigation that helps management decide whether the system is worth developing. The goal is to understand the scope of the problem, not to solve it. The outcome is a formal system proposal that serves as a decision document.

Steps: form the team and appoint a leader; draw system flowcharts; identify the current system’s shortcomings and set goals; list the alternatives; assess the feasibility of each; compare performance and cost; rank them and pick the best; and take the proposal to management.

In project management literature, these dimensions are summarized by the acronym TELOS: technical, economic, legal, operational and scheduling. ^[11]

Structured analysis

Structured analysis is a method for understanding the system logically, with graphical tools that go from the overview to the details. It is graphical, breaks processes down to give a clear picture of the flow and is logical rather than physical: it does not depend on vendor or hardware. ^[12] Its tools are the DFD, the data dictionary, decision trees and tables, structured English and pseudocode.

Data flow diagram (DFD)

First proposed by Larry Constantine and spread by Ed Yourdon, Tom DeMarco, and Chris Gane and Trish Sarson in the late 1970s, the DFD shows how data flows between the system’s functions: what is processed, what transformations occur, what is stored and where results go. ^{[13] [14]}

The context diagram is level 0: it shows the whole system as a single process, surrounded by the external entities. Each process is then detailed at lower levels, top-down.

Data dictionary

A structured repository describing every DFD element: flows, stores, data and processes. It improves communication with users and is the basis of the database. ^[16]

Decision tree and decision table

Consider the rule: customers who pay in advance get a 5% discount; customers who do not only get the discount if the purchase is $10,000 or more and they are regular customers.

The decision table shows every combination at once. It has four quadrants: condition stub (upper left), condition entries (upper right), action stub (lower left) and action entries (lower right). Y = yes, N = no, – = does not matter, X = do it. ^[17]

Structured English and pseudocode

Structured English describes logic with imperative sentences and the constructs of structured programming (sequence, decision and repetition), without strict syntax. ^[19] The same rule looks like this:

IF the customer paid in advance
    THEN give a 5% discount
ELSE
    IF the purchase is $10,000 or more AND the customer is regular
        THEN give a 5% discount
    ELSE
        give no discount
    END IF
END IF

Pseudocode is similar, but already thinks in terms of program logic: it is language-independent and often replaces flowcharts in physical design.

Which tool to use

• DFD: to document the system, at high or low level;
• data dictionary: to organize data requirements;
• structured English: when there are many loops and complex actions;
• decision table: when there are many conditions and the logic is complex;
• decision tree: when the order of conditions matters and there are few of them.

System and data design

Design turns the SRS into an implementable form and decides how the system will operate. Inputs: statement of work, requirements plan, analysis of the current situation and proposed requirements (conceptual data model, revised DFDs and metadata). Outputs: infrastructure and organizational changes, a data schema (usually relational), metadata, a map of the program structure, code or pseudocode for each module and a prototype.

Types of design

• Logical: an abstract representation of data flows, inputs, outputs and stores, using DFDs and E-R models.
• Physical: how data is entered, validated, processed and displayed; defines media, database, backups, test and implementation plans.
• Architectural (high-level): the system’s structure and behavior and the relationship between modules.
• Detailed: follows the architectural design and develops each module.

Entity-relationship model

The conceptual data model captures as much meaning as possible about the organization’s data. The most widely used is the entity-relationship (E-R) model, published by Peter Chen in 1976. ^{[20] [21]}

• Entity: a distinct real-world item, such as student, course or vendor.
• Relationship: a meaningful dependency between entities, such as “professor teaches course”.
• Attribute: a property of an entity or relationship, such as the student’s name.

There are three kinds of relationship between two data sets: one-to-one (1:1), one-to-many (1:N) and many-to-many (N:M). The figure also shows key, multivalued, composite and derived attributes and total participation.

File organization and access

Sequential access reads records from first to last and is efficient when almost all of them are needed; direct access goes straight to the record’s address. An organization’s files may be: master (current data, such as customers), table (a master that rarely changes, such as ZIP codes), transaction (day-to-day activity that updates the master), temporary, mirror (an exact copy, for continuity), log (a history of changes, for audit and recovery) and archive (historical versions).

Design strategies

• Top-down: starts at the main module and splits it into ever simpler submodules, until nothing is left to split.
• Bottom-up: starts at the most basic modules and groups them into larger ones, up to the main module. ^[22]

Structured design

Structured design, by Yourdon and Constantine, starts from the DFDs to build the structure chart: boxes that represent modules, connected by lines that show which calls which. The goal is to reduce complexity and increase modularity. ^{[15] [23]}

• a control module directs subordinate modules; a library module is reusable and can be called from several points;
• the chart is transform-centered when all transactions follow the same path, and transaction-centered when they follow different paths;
• modularization makes it possible to test critical interfaces first, split work among several programmers and reuse code.

Coupling and cohesion

Two concepts measure the quality of a modular design. Coupling is how much a module depends on others; the stronger it is, the harder the system is to implement and maintain. Cohesion is how much a module’s parts belong together. ^{[24] [25]}

• Coupling, from worst to best: content (one module changes another’s internals); common (they share global data); external (they share an external format or protocol); control (one passes parameters that control the other); stamp (they pass whole data structures); data (they pass only the data needed).
• Cohesion, from worst to best: coincidental (unrelated parts); logical (similar functions grouped); temporal (run at the same time, such as initialization); procedural (follow an execution order); communicational (operate on the same data); sequential (one part’s output is the next part’s input); functional (everything contributes to a single task).

Input, output and forms

Input design

The quality of output depends on the quality of input. The goals are: design data entry and its procedures, reduce the volume typed, design source documents and screens, and create validations. To prevent errors: clear forms with enough space and instructions; fewer keystrokes; and immediate error feedback. Methods include batch, online, machine-readable forms and interactive input.

Input integrity controls check each field’s format and completeness, and transaction logs create the audit trail of every change to the database.

Output design

Output must serve its purpose, meet user needs, come in the right quantity and format, reach the right person and arrive on time. External outputs leave the system (some come back as input, such as a payment slip); internal outputs support management, in three kinds of report:

• detailed: information with almost no filtering;
• summary: trends and totals, for those who do not want the details;
• exception: only what falls outside a standard or limit.

Reports should show the print date and time, a title and page numbers; pre-printed forms, a version number and effective date.

Forms

Forms are for data entry; reports are for reading only. A good form is simple, with a logical sequence and clear captions, fits its purpose, makes it easy to fill in correctly and to navigate. The original text also describes paper forms (flat, carbon unit sets, continuous and carbonless), rare today.

Documentation

Documentation reduces downtime, cuts costs, speeds up maintenance, and makes training and communication between technical and non-technical people easier. It must be updated regularly. There are four kinds:

Testing, implementation and maintenance

Testing and quality assurance

Testing checks whether the software does what the requirements ask; a successful test is one that finds errors. It starts at the modules and moves up to the integrated system, following a strategy, a plan, test cases and procedures, and a record of results. The main types are unit, integration and functional (positive, with valid inputs, and negative, with invalid ones). The Software testing tutorial covers the subject in detail.

Software quality assurance (SQA) reviews products and processes throughout the cycle, at four levels: code walk-through against the rules, compilation and linking on every platform, routine running under varied conditions and performance testing.

Training

A well-designed system can fail if it is badly operated. Operators learn the routines, common malfunctions and what to do about each; users learn to operate the system and solve simple problems. Training can be instructor-led, in a physical or virtual classroom, or self-paced, through multimedia or web-based courses.

Conversion

Conversion is the migration from the old system to the new one. The conversion plan lists the files to convert, the new documents and procedures, the controls, the people responsible and the schedule.

After go-live, the post-implementation evaluation review (PIER) compares actual costs, benefits and timelines with the planned ones, points out strengths and weaknesses and improves the estimates for future projects. The project team, management, users and strategic management take part.

Maintenance

Maintenance keeps the system in line with its requirements; enhancement adds new requirements. ISO/IEC 14764 classifies maintenance into four types: ^[26]

• corrective: fixes defects found, usually reported by users;
• adaptive: adapts the system to changes in the environment, such as a new operating system or a new law;
• perfective: improves performance or usability, or adds functions requested by users;
• preventive: anticipates problems that have not shown up yet.

Security and audit

Systems audit

An audit reviews the performance of an operational system to compare actual with planned results, check whether the objectives are still valid and have been met, ensure the reliability of the information and protect against fraud. The auditor should take part from the start of development, so the system is auditable from day one.

The audit trail is the record of who accessed the system and what they did in each period; it makes it possible to trace how data changed. ^[27] Auditing can be done around the computer (manually process sample inputs and compare with the system’s output) or through the computer (examine intermediate results through the trail and control totals).

Security

Protecting data, software and hardware against theft, unauthorized access or change and accidental damage. It covers privacy (nobody accesses someone’s data without permission) and integrity (the quality and reliability of the data). Control measures include:

• backups: periodic full copies, more frequent incremental ones, kept at a remote site and, for critical systems, mirroring of transactions;
• physical access control: locks, biometrics, badges and logging of who reads or changes data;
• logical controls: passwords, encryption, employee training, antivirus and firewalls.

Risk analysis

A risk is the possibility of losing something of value. Risk analysis identifies the system’s components, the threats to each and the loss if they materialize. Risk management is continuous: identify security measures, calculate each one’s cost, compare it with the expected loss, choose and implement the measures and review them periodically.

Object orientation and UML

In the object-oriented approach, structure and behavior live together in small modules that combine data and process. It makes change cheaper, promotes reuse, and simplifies component integration and the design of distributed systems. ^[28]

Elements and features

• Object: something in the problem domain, identified by data and behavior, such as a student or a bank account.
• Class: the template that groups objects with the same attributes (data) and methods (behavior).
• Message: one object’s call to another object’s method.
• Encapsulation: an object’s data is hidden and only reached through its methods, so it can change without affecting the rest.
• Abstraction: keeping only the attributes and methods that are essential to the problem.
• Inheritance: creating subclasses that inherit attributes and operations from an existing class.
• Polymorphism: the same operation is carried out differently by different classes.
• Relationships: association (two classes work together), aggregation (whole and parts) and generalization (a child class based on a parent).

UML

The Unified Modeling Language (UML) is the standard visual language for modeling object-oriented systems, maintained by the Object Management Group (OMG); the current version is 2.5.1, from 2017. ^{[29] [30]}

• Static models show structure: class, object and use case diagrams.
• Dynamic models show behavior in response to events: sequence, communication, state and activity diagrams.
• Operations on objects are constructor and destructor (add an employee), query (read the address, with no side effects) and update (change the address).

Structured × object-oriented

The object-oriented cycle has analysis (with the use case model and the domain classes), design (refining classes, attributes, methods, interface and data access), prototyping, implementation and incremental testing. Implementation can use component-based development (assembling the system from ready-made, tested parts) or rapid application development (RAD), which complements the SDLC with tools to build and deliver in increments. ^[31]

Use cases and stories

A use case describes the interaction between a user and the system to reach a goal, with a basic flow and alternative flows. ^[32]

In agile methods, requirements are usually organized in a hierarchy that goes from the business goal to the technical task, and the requirement itself is written as a user story. ^[33]

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “System Analysis and Design”, GitHub Gist, original text of this tutorial, gist.github.com/GiovaniPM/506ed93c3796fbaeb52effff0dcda2ca.
2. Tutorialspoint, “System Analysis and Design Tutorial”, accessed 25 September 2026, tutorialspoint.com/system_analysis_and_design/index.htm.
3. Wikipedia, “Systems analysis”, accessed 25 September 2026, en.wikipedia.org/wiki/Systems_analysis.
4. Wikipedia, “Systems design”, accessed 25 September 2026, en.wikipedia.org/wiki/Systems_design.
5. Wikipedia, “Systems development life cycle”, accessed 25 September 2026, en.wikipedia.org/wiki/Systems_development_life_cycle.
6. Wikipedia, “Feedback”, accessed 25 September 2026, en.wikipedia.org/wiki/Feedback.
7. Wikipedia, “Management information system”, accessed 25 September 2026, en.wikipedia.org/wiki/Management_information_system.
8. Wikipedia, “Decision support system”, accessed 25 September 2026, en.wikipedia.org/wiki/Decision_support_system.
9. Wikipedia, “Joint application design”, accessed 25 September 2026, en.wikipedia.org/wiki/Joint_application_design.
10. Wikipedia, “Software requirements specification”, accessed 25 September 2026, en.wikipedia.org/wiki/Software_requirements_specification.
11. Wikipedia, “Feasibility study”, accessed 25 September 2026, en.wikipedia.org/wiki/Feasibility_study.
12. Wikipedia, “Structured analysis”, accessed 25 September 2026, en.wikipedia.org/wiki/Structured_analysis.
13. Wikipedia, “Data-flow diagram”, accessed 25 September 2026, en.wikipedia.org/wiki/Data-flow_diagram.
14. Tom DeMarco, Structured Analysis and System Specification, Prentice Hall, 1979.
15. Edward Yourdon and Larry L. Constantine, Structured Design, Prentice Hall, 1979.
16. Wikipedia, “Data dictionary”, accessed 25 September 2026, en.wikipedia.org/wiki/Data_dictionary.
17. Wikipedia, “Decision table”, accessed 25 September 2026, en.wikipedia.org/wiki/Decision_table.
18. Wikipedia, “Decision tree”, accessed 25 September 2026, en.wikipedia.org/wiki/Decision_tree.
19. Wikipedia, “Structured English”, accessed 25 September 2026, en.wikipedia.org/wiki/Structured_English.
20. Peter P. Chen, “The Entity-Relationship Model: Toward a Unified View of Data”, ACM Transactions on Database Systems, vol. 1, no. 1, 1976.
21. Wikipedia, “Entity–relationship model”, accessed 25 September 2026, en.wikipedia.org/wiki/Entity–relationship_model.
22. Wikipedia, “Top-down and bottom-up design”, accessed 25 September 2026, en.wikipedia.org/wiki/Top-down_and_bottom-up_design.
23. Wikipedia, “Structure chart”, accessed 25 September 2026, en.wikipedia.org/wiki/Structure_chart.
24. Wikipedia, “Coupling (computer programming)”, accessed 25 September 2026, en.wikipedia.org/wiki/Coupling_(computer_programming).
25. Wikipedia, “Cohesion (computer science)”, accessed 25 September 2026, en.wikipedia.org/wiki/Cohesion_(computer_science).
26. Wikipedia, “Software maintenance”, accessed 25 September 2026, en.wikipedia.org/wiki/Software_maintenance.
27. Wikipedia, “Audit trail”, accessed 25 September 2026, en.wikipedia.org/wiki/Audit_trail.
28. Wikipedia, “Object-oriented analysis and design”, accessed 25 September 2026, en.wikipedia.org/wiki/Object-oriented_analysis_and_design.
29. Wikipedia, “Unified Modeling Language”, accessed 25 September 2026, en.wikipedia.org/wiki/Unified_Modeling_Language.
30. Object Management Group, “Unified Modeling Language (UML)”, specification, accessed 25 September 2026, omg.org/spec/UML.
31. Wikipedia, “Rapid application development”, accessed 25 September 2026, en.wikipedia.org/wiki/Rapid_application_development.
32. Wikipedia, “Use case”, accessed 25 September 2026, en.wikipedia.org/wiki/Use_case.
33. Wikipedia, “User story”, accessed 25 September 2026, en.wikipedia.org/wiki/User_story.

Analisi × progettazione

Sviluppare sistemi è un processo sistematico, con fasi di pianificazione, analisi, progettazione, rilascio e manutenzione. Questo tutorial si concentra sulle due centrali. ^{[1] [2]}

L’analisi e progettazione dei sistemi guarda contemporaneamente a tre cose: i sistemi, i processi e la tecnologia. ^{[3] [4]}

Cos’è un sistema

La parola viene dal greco systema, un insieme organizzato. Un sistema è un raggruppamento ordinato di componenti interdipendenti, collegati secondo un piano per raggiungere un obiettivo specifico. Esempi: controllo del traffico, paghe, biblioteca automatizzata, gestione del personale.

Ogni sistema ha tre vincoli di base:

• ha struttura e comportamento pensati per un obiettivo predefinito;
• i suoi componenti sono interconnessi e interdipendenti;
• gli obiettivi dell’organizzazione hanno la priorità su quelli dei sottosistemi.

Proprietà

• Organizzazione: struttura e ordine tra i componenti.
• Interazione: il modo in cui i componenti operano tra loro, come acquisti e produzione, o paghe e personale.
• Interdipendenza: l’output di un sottosistema è l’input di un altro.
• Integrazione: le parti lavorano insieme, anche se ognuna ha una funzione propria.
• Obiettivo centrale: può essere reale o solo dichiarato; non è raro che un’organizzazione annunci un obiettivo e ne persegua un altro. Gli utenti devono conoscerlo presto nell’analisi.

Elementi

• Input e output: gli input sono ciò che entra per essere elaborato; gli output, il risultato utile per l’utente.
• Processore: trasforma gli input in output. Quando cambia la specifica dell’output, cambia anche l’elaborazione.
• Controllo: il sottosistema decisionale che guida input, elaborazione e output.
• Retroazione (feedback): confronta l’output con l’obiettivo e informa il controllo. Nella teoria dei sistemi, la retroazione negativa corregge lo scostamento e stabilizza il sistema; quella positiva rafforza la tendenza in atto. ^[6]
• Ambiente: il “supersistema” in cui opera l’organizzazione, con fornitori, concorrenti e leggi che impongono vincoli.
• Confini e interfacce: il confine definisce cosa sta dentro il sistema e la sua sfera di controllo; le interfacce sono i punti di contatto con altri sistemi.

Tipi, modelli e informazione

Tipi di sistema

I sistemi informativi creati dall’uomo riuniscono hardware, software, comunicazione, dati e applicazioni per produrre l’informazione di cui l’organizzazione ha bisogno. Possono essere formali (circolari e istruzioni che scendono dalla direzione), informali (la rete di colleghi che risolve il quotidiano) o basati su computer (prenotazioni, banche, biblioteche).

Modelli di sistema

• Schematico: un diagramma bidimensionale con gli elementi e i loro collegamenti.
• Di flusso: mostra il flusso ordinato di materiali, energia e informazioni; il PERT ne è un esempio.
• Statico: rappresenta una coppia di relazioni, come attività e tempo; il diagramma di Gantt ne è un esempio.
• Dinamico: mostra lo stato in continuo cambiamento, con input, processore, programmi e output.

Categorie di informazione

Ciclo di vita (SDLC)

Il ciclo di vita dello sviluppo dei sistemi (SDLC) è un modello concettuale con politiche e procedure per creare o modificare sistemi. Un buon SDLC consegna un sistema di qualità, che soddisfa il cliente, nei tempi e nei costi, e funziona bene nell’infrastruttura attuale e futura. ^[5]

1. Pianificazione e fattibilità: definisce problema e ambito, obiettivi del nuovo sistema, rischi, vincoli, integrazione e sicurezza; si chiude con il rapporto di fattibilità e il calendario.
2. Analisi e specifica: raccoglie, analizza e convalida le informazioni, definisce requisiti e prototipi, valuta le alternative e dà le priorità; si chiude con la specifica dei requisiti software (SRS).
3. Progettazione: progetta applicazione, rete, database, interfacce utente e con altri sistemi; crea piani di emergenza, formazione, manutenzione e operatività; si chiude con il documento di progetto.
4. Implementazione: scrive il codice, integra i moduli, testa secondo il piano di test e installa il sistema nel suo ambiente.
5. Manutenzione e supporto: assiste gli utenti, corregge i difetti residui e incorpora nuovi requisiti.

L’analista di sistemi

È chi conosce a fondo il sistema e guida il progetto, allineando gli obiettivi del sistema informativo a quelli dell’organizzazione. I suoi compiti principali:

• capire i requisiti degli utenti con tecniche di raccolta e darne le priorità per consenso;
• analizzare e valutare fino ad arrivare a un sistema adatto e facile da usare;
• proporre alternative, scegliere la migliore e quantificare costi e benefici;
• scrivere specifiche comprensibili a utenti e programmatori;
• garantire un progetto logico modulare e pianificare valutazioni periodiche dopo l’avvio.

Raccolta dei requisiti

Un requisito è una caratteristica essenziale del nuovo sistema: acquisire o elaborare dati, controllare attività, produrre informazioni o supportare la gestione. Determinare i requisiti comporta tre attività:

• Anticipazione: prevedere caratteristiche in base all’esperienza. Aiuta a guardare aree che sfuggirebbero, ma può introdurre pregiudizi.
• Indagine: studiare e documentare il sistema attuale con tecniche di raccolta, prototipi e strumenti; è il cuore dell’analisi.
• Specifica: analizzare i dati raccolti, individuare i requisiti essenziali e descrivere il nuovo sistema.

Il risultato è la specifica dei requisiti software (SRS), che deve essere completa, non ambigua e senza gergo, coprire i bisogni operativi, tattici e strategici e usare supporti grafici. La vecchia norma IEEE 830 sulla SRS è stata sostituita dalla ISO/IEC/IEEE 29148. ^[10]

Tecniche di raccolta

Il JAD (joint application design) è stato creato da Arnie Lind in IBM Canada nel 1974 e poi formalizzato da Tony Crawford e Chuck Morris. ^[9]

Qualità di un buon requisito

Studio di fattibilità

È l’indagine preliminare che aiuta la direzione a decidere se valga la pena sviluppare il sistema. L’obiettivo è capire l’ambito del problema, non risolverlo. Il risultato è una proposta formale di sistema, che fa da documento decisionale.

Passi: formare il team e nominare un responsabile; disegnare i diagrammi di flusso del sistema; individuare le carenze di quello attuale e fissare gli obiettivi; elencare le alternative; valutare la fattibilità di ciascuna; confrontare prestazioni e costi; ordinarle e scegliere la migliore; e portare la proposta alla direzione.

Nella letteratura di project management queste dimensioni sono riassunte dalla sigla TELOS: tecnica, economica, legale, operativa e temporale. ^[11]

Analisi strutturata

L’analisi strutturata è un metodo per capire il sistema in modo logico, con strumenti grafici che vanno dalla visione d’insieme ai dettagli. È grafica, scompone i processi per dare un quadro chiaro del flusso ed è logica, non fisica: non dipende da fornitori né da hardware. ^[12] I suoi strumenti sono il DFD, il dizionario dei dati, gli alberi e le tabelle di decisione, l’inglese strutturato e lo pseudocodice.

Diagramma di flusso dei dati (DFD)

Proposto da Larry Constantine e diffuso da Ed Yourdon, Tom DeMarco e da Chris Gane e Trish Sarson alla fine degli anni Settanta, il DFD mostra come i dati fluiscono tra le funzioni del sistema: cosa viene elaborato, quali trasformazioni avvengono, cosa viene conservato e dove vanno i risultati. ^{[13] [14]}

Il diagramma di contesto è il livello 0: mostra l’intero sistema come un unico processo, circondato dalle entità esterne. Poi ogni processo viene dettagliato ai livelli inferiori, dall’alto verso il basso.

Dizionario dei dati

Archivio strutturato con la descrizione di tutti gli elementi del DFD: flussi, archivi, dati e processi. Migliora la comunicazione con l’utente ed è la base del database. ^[16]

Albero e tabella di decisione

Consideriamo la regola: chi paga in anticipo ha uno sconto del 5%; chi non paga in anticipo ha lo sconto solo se l’acquisto è di 10.000 € o più ed è un cliente abituale.

La tabella di decisione mostra tutte le combinazioni in una volta. Ha quattro quadranti: condizioni (in alto a sinistra), valori delle condizioni (in alto a destra), azioni (in basso a sinistra) e valori delle azioni (in basso a destra). S = sì, N = no, – = indifferente, X = eseguire. ^[17]

Inglese strutturato e pseudocodice

L’inglese strutturato (qui in italiano) descrive la logica con frasi imperative e le strutture della programmazione strutturata (sequenza, decisione e ripetizione), senza una sintassi rigida. ^[19] La stessa regola diventa:

SE il cliente ha pagato in anticipo
    ALLORA dare lo sconto del 5%
ALTRIMENTI
    SE l’acquisto è di 10.000 € o più E il cliente è abituale
        ALLORA dare lo sconto del 5%
    ALTRIMENTI
        non dare sconti
    FINE-SE
FINE-SE

Lo pseudocodice è simile, ma ragiona già in termini di logica del programma: è indipendente dal linguaggio e spesso sostituisce i diagrammi di flusso nel progetto fisico.

Quale strumento usare

• DFD: per documentare il sistema, ad alto o basso livello;
• dizionario dei dati: per organizzare i requisiti sui dati;
• inglese strutturato: quando ci sono molti cicli e azioni complesse;
• tabella di decisione: quando ci sono molte condizioni e la logica è complessa;
• albero di decisione: quando l’ordine delle condizioni conta e sono poche.

Progettazione del sistema e dei dati

La progettazione trasforma la SRS in una forma realizzabile e decide come opererà il sistema. Input: dichiarazione di lavoro, piano dei requisiti, analisi della situazione attuale e requisiti proposti (modello concettuale dei dati, DFD rivisti e metadati). Output: cambiamenti di infrastruttura e organizzazione, schema dei dati (di solito relazionale), metadati, mappa della struttura del programma, codice o pseudocodice di ogni modulo e un prototipo.

Tipi di progettazione

• Logica: rappresentazione astratta di flussi, input, output e archivi di dati, con DFD e modelli E-R.
• Fisica: come i dati entrano, vengono convalidati, elaborati e mostrati; definisce supporti, database, backup, piani di test e di implementazione.
• Architetturale (alto livello): struttura e comportamento del sistema e relazioni tra i moduli.
• Di dettaglio: segue quella architetturale e sviluppa ogni modulo.

Modello entità-relazione

Il modello concettuale dei dati cattura il massimo significato sui dati dell’organizzazione. Il più usato è il modello entità-relazione (E-R), pubblicato da Peter Chen nel 1976. ^{[20] [21]}

• Entità: un elemento distinto del mondo reale, come studente, corso o fornitore.
• Relazione: una dipendenza significativa tra entità, come “il docente insegna il corso”.
• Attributo: una proprietà di un’entità o di una relazione, come il nome dello studente.

Tra due insiemi di dati esistono tre tipi di relazione: uno a uno (1:1), uno a molti (1:N) e molti a molti (N:M). La figura mostra anche attributi chiave, multivalore, composti e derivati e la partecipazione totale.

Organizzazione e accesso ai file

L’accesso sequenziale legge i record dal primo all’ultimo ed è efficiente quando servono quasi tutti; l’accesso diretto va subito all’indirizzo del record. I file di un’organizzazione possono essere: anagrafici (dati correnti, come i clienti), tabella (anagrafici che cambiano di rado, come i CAP), di transazione (il movimento quotidiano, che aggiorna l’anagrafica), temporanei, speculari (copia esatta, per la continuità), di log (storico delle modifiche, per audit e ripristino) e di archivio (versioni storiche).

Strategie di progettazione

• Dall’alto verso il basso (top-down): parte dal modulo principale e lo divide in sottomoduli sempre più semplici, finché non resta nulla da dividere.
• Dal basso verso l’alto (bottom-up): parte dai moduli più elementari e li raggruppa in moduli più grandi, fino al principale. ^[22]

Progettazione strutturata

La progettazione strutturata, di Yourdon e Constantine, parte dai DFD per costruire lo structure chart: riquadri che rappresentano i moduli, collegati da linee che mostrano chi chiama chi. L’obiettivo è ridurre la complessità e aumentare la modularità. ^{[15] [23]}

• il modulo di controllo dirige i moduli subordinati; il modulo di libreria è riutilizzabile e può essere chiamato da più punti;
• il diagramma è centrato sulla trasformazione quando tutte le transazioni seguono lo stesso percorso, e centrato sulla transazione quando seguono percorsi diversi;
• la modularizzazione permette di testare prima le interfacce critiche, dividere il lavoro tra più programmatori e riutilizzare il codice.

Accoppiamento e coesione

Due concetti misurano la qualità di un progetto modulare. L’accoppiamento indica quanto un modulo dipende dagli altri; più è forte, più il sistema è difficile da realizzare e mantenere. La coesione indica quanto le parti di un modulo stanno insieme. ^{[24] [25]}

• Accoppiamento, dal peggiore al migliore: di contenuto (un modulo modifica l’interno di un altro); comune (condividono dati globali); esterno (condividono un formato o protocollo esterno); di controllo (uno passa parametri che controllano l’altro); di struttura (si passano intere strutture dati); di dati (si passano solo i dati necessari).
• Coesione, dalla peggiore alla migliore: casuale (parti senza relazione); logica (funzioni simili raggruppate); temporale (eseguite nello stesso momento, come l’inizializzazione); procedurale (seguono un ordine di esecuzione); comunicazionale (operano sugli stessi dati); sequenziale (l’output di una parte è l’input della successiva); funzionale (tutto contribuisce a un solo compito).

Input, output e moduli

Progettazione dell’input

La qualità dell’output dipende dalla qualità dell’input. Gli obiettivi sono: progettare l’inserimento dei dati e le sue procedure, ridurre il volume digitato, progettare documenti di origine e schermate, e creare controlli di validità. Per prevenire errori: moduli chiari, con spazio sufficiente e istruzioni; meno battute di tastiera; e segnalazione immediata degli errori. I metodi comprendono l’inserimento a lotti, online, con moduli leggibili dalla macchina e interattivo.

I controlli di integrità dell’input verificano formato e completezza di ogni campo, e i log delle transazioni creano la traccia di audit di tutte le modifiche al database.

Progettazione dell’output

L’output deve servire allo scopo, soddisfare l’utente, avere quantità e formato giusti, arrivare alla persona giusta e in tempo. Gli output esterni escono dal sistema (alcuni rientrano come input, come un bollettino di pagamento); quelli interni supportano la gestione, con tre tipi di report:

• dettagliato: l’informazione quasi senza filtri;
• di sintesi: tendenze e totali, per chi non vuole i dettagli;
• di eccezione: solo ciò che esce da uno standard o da un limite.

I report devono riportare data e ora di stampa, titolo e numerazione delle pagine; i moduli prestampati, numero di versione e data di validità.

Moduli

I moduli servono per l’inserimento dei dati; i report, solo per la lettura. Un buon modulo è semplice, con una sequenza logica ed etichette chiare, adatto allo scopo, facile da compilare correttamente e da navigare. Il testo originale descrive anche i moduli cartacei (semplici, con carta carbone, continui e autocopianti), oggi rari.

Documentazione

Documentare riduce i fermi, taglia i costi, velocizza la manutenzione e facilita la formazione e la comunicazione tra tecnici e non tecnici. La documentazione va aggiornata con regolarità. Ce ne sono quattro tipi:

Test, implementazione e manutenzione

Test e assicurazione della qualità

Il test verifica che il software faccia ciò che chiedono i requisiti; un test riuscito è quello che trova errori. Parte dai moduli e sale fino al sistema integrato, seguendo una strategia, un piano, casi e procedure di test e la registrazione dei risultati. I tipi principali sono il test di unità, di integrazione e funzionale (positivo, con input validi, e negativo, con input non validi). Il tutorial Test del software tratta l’argomento in dettaglio.

L’assicurazione della qualità del software (SQA) rivede prodotti e processi lungo tutto il ciclo, su quattro livelli: revisione del codice rispetto alle regole (walk-through), compilazione e linking su tutte le piattaforme, esecuzione in condizioni varie e test delle prestazioni.

Formazione

Un sistema ben progettato può fallire se viene usato male. Gli operatori imparano le procedure, i guasti comuni e cosa fare in ciascun caso; gli utenti imparano a usare il sistema e a risolvere problemi semplici. La formazione può essere guidata da un docente, in aula fisica o virtuale, o autogestita, con corsi multimediali o sul web.

Conversione

È la migrazione dal vecchio sistema al nuovo. Il piano di conversione elenca i file da convertire, i nuovi documenti e procedure, i controlli, i responsabili e il calendario.

Dopo l’avvio, la revisione post-implementazione (PIER) confronta costi, benefici e tempi reali con quelli previsti, evidenzia punti di forza e debolezze e migliora le stime dei progetti futuri. Vi partecipano il team di progetto, la direzione, gli utenti e la direzione strategica.

Manutenzione

Mantenere significa conservare il sistema conforme ai suoi requisiti; migliorare significa incorporare nuovi requisiti. La norma ISO/IEC 14764 classifica la manutenzione in quattro tipi: ^[26]

• correttiva: corregge i difetti trovati, di solito segnalati dagli utenti;
• adattiva: adatta il sistema ai cambiamenti dell’ambiente, come un nuovo sistema operativo o una nuova legge;
• perfettiva: migliora prestazioni o usabilità, o aggiunge funzioni richieste dagli utenti;
• preventiva: anticipa problemi che non si sono ancora manifestati.

Sicurezza e audit

Audit dei sistemi

L’audit rivede le prestazioni di un sistema in esercizio per confrontare il reale con il pianificato, verificare che gli obiettivi siano ancora validi e raggiunti, garantire l’affidabilità delle informazioni e proteggere dalle frodi. L’auditor dovrebbe partecipare fin dall’inizio dello sviluppo, perché il sistema nasca già verificabile.

La traccia di audit (audit trail) è la registrazione di chi ha acceduto al sistema e di cosa ha fatto in ogni periodo; permette di ricostruire come sono cambiati i dati. ^[27] L’audit si può fare intorno al computer (elaborare a mano campioni di input e confrontarli con l’output del sistema) o attraverso il computer (esaminare i risultati intermedi tramite la traccia e i totali di controllo).

Sicurezza

Proteggere dati, software e hardware da furti, accessi o modifiche non autorizzati e danni accidentali. Comprende la riservatezza (nessuno accede ai dati di qualcuno senza permesso) e l’integrità (qualità e affidabilità dei dati). Le misure di controllo comprendono:

• backup: copie complete periodiche, incrementali più frequenti, conservate in un sito remoto e, per i sistemi critici, mirroring delle transazioni;
• controllo dell’accesso fisico: serrature, biometria, badge e registrazione di chi legge o modifica i dati;
• controlli logici: password, crittografia, formazione dei dipendenti, antivirus e firewall.

Analisi dei rischi

Il rischio è la possibilità di perdere qualcosa di valore. L’analisi individua i componenti del sistema, le minacce a ciascuno e la perdita se si concretizzano. La gestione del rischio è continua: individuare le misure di sicurezza, calcolarne il costo, confrontarlo con la perdita attesa, scegliere e attuare le misure e rivederle periodicamente.

Orientamento agli oggetti e UML

Nell’approccio orientato agli oggetti, struttura e comportamento stanno insieme in piccoli moduli che uniscono dati e processi. Rende le modifiche più economiche, favorisce il riuso e semplifica l’integrazione dei componenti e la progettazione dei sistemi distribuiti. ^[28]

Elementi e caratteristiche

• Oggetto: qualcosa del dominio del problema, identificato da dati e comportamento, come uno studente o un conto bancario.
• Classe: il modello che raggruppa oggetti con gli stessi attributi (dati) e metodi (comportamento).
• Messaggio: la chiamata di un oggetto a un metodo di un altro.
• Incapsulamento: i dati di un oggetto sono nascosti e raggiungibili solo tramite i suoi metodi, quindi si possono cambiare senza toccare il resto.
• Astrazione: tenere solo gli attributi e i metodi essenziali per il problema.
• Ereditarietà: creare sottoclassi che ereditano attributi e operazioni da una classe esistente.
• Polimorfismo: la stessa operazione viene eseguita in modi diversi da classi diverse.
• Relazioni: associazione (due classi collaborano), aggregazione (tutto e parti) e generalizzazione (classe figlia basata sulla madre).

UML

Il linguaggio di modellazione unificato (UML) è il linguaggio visuale standard per modellare sistemi orientati agli oggetti, mantenuto dall’Object Management Group (OMG); la versione attuale è la 2.5.1, del 2017. ^{[29] [30]}

• I modelli statici mostrano la struttura: diagrammi delle classi, degli oggetti e dei casi d’uso.
• I modelli dinamici mostrano il comportamento in risposta agli eventi: diagrammi di sequenza, di comunicazione, di stato e di attività.
• Le operazioni sugli oggetti sono di creazione e distruzione (aggiungere un dipendente), interrogazione (leggere l’indirizzo, senza effetti collaterali) e aggiornamento (cambiare l’indirizzo).

Strutturato × orientato agli oggetti

Il ciclo orientato agli oggetti comprende analisi (con il modello dei casi d’uso e le classi del dominio), progettazione (affina classi, attributi, metodi, interfaccia e accesso ai dati), prototipazione, implementazione e test incrementali. L’implementazione può usare lo sviluppo basato su componenti (assemblare il sistema con parti pronte e testate) o lo sviluppo rapido di applicazioni (RAD), che integra l’SDLC con strumenti per costruire e consegnare per incrementi. ^[31]

Casi d’uso e storie

Un caso d’uso descrive l’interazione tra un utente e il sistema per raggiungere un obiettivo, con un flusso principale e flussi alternativi. ^[32]

Nei metodi agili i requisiti sono di solito organizzati in una gerarchia che va dall’obiettivo di business al compito tecnico, e il requisito vero e proprio è scritto come storia utente. ^[33]

Ripasso veloce

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “System Analysis and Design”, GitHub Gist, testo originale di questo tutorial, gist.github.com/GiovaniPM/506ed93c3796fbaeb52effff0dcda2ca.
2. Tutorialspoint, “System Analysis and Design Tutorial”, consultato il 25/09/2026, tutorialspoint.com/system_analysis_and_design/index.htm.
3. Wikipedia (in inglese), “Systems analysis”, consultato il 25/09/2026, en.wikipedia.org/wiki/Systems_analysis.
4. Wikipedia (in inglese), “Systems design”, consultato il 25/09/2026, en.wikipedia.org/wiki/Systems_design.
5. Wikipedia (in inglese), “Systems development life cycle”, consultato il 25/09/2026, en.wikipedia.org/wiki/Systems_development_life_cycle.
6. Wikipedia (in inglese), “Feedback”, consultato il 25/09/2026, en.wikipedia.org/wiki/Feedback.
7. Wikipedia (in inglese), “Management information system”, consultato il 25/09/2026, en.wikipedia.org/wiki/Management_information_system.
8. Wikipedia (in inglese), “Decision support system”, consultato il 25/09/2026, en.wikipedia.org/wiki/Decision_support_system.
9. Wikipedia (in inglese), “Joint application design”, consultato il 25/09/2026, en.wikipedia.org/wiki/Joint_application_design.
10. Wikipedia (in inglese), “Software requirements specification”, consultato il 25/09/2026, en.wikipedia.org/wiki/Software_requirements_specification.
11. Wikipedia (in inglese), “Feasibility study”, consultato il 25/09/2026, en.wikipedia.org/wiki/Feasibility_study.
12. Wikipedia (in inglese), “Structured analysis”, consultato il 25/09/2026, en.wikipedia.org/wiki/Structured_analysis.
13. Wikipedia (in inglese), “Data-flow diagram”, consultato il 25/09/2026, en.wikipedia.org/wiki/Data-flow_diagram.
14. Tom DeMarco, Structured Analysis and System Specification, Prentice Hall, 1979.
15. Edward Yourdon e Larry L. Constantine, Structured Design, Prentice Hall, 1979.
16. Wikipedia (in inglese), “Data dictionary”, consultato il 25/09/2026, en.wikipedia.org/wiki/Data_dictionary.
17. Wikipedia (in inglese), “Decision table”, consultato il 25/09/2026, en.wikipedia.org/wiki/Decision_table.
18. Wikipedia (in inglese), “Decision tree”, consultato il 25/09/2026, en.wikipedia.org/wiki/Decision_tree.
19. Wikipedia (in inglese), “Structured English”, consultato il 25/09/2026, en.wikipedia.org/wiki/Structured_English.
20. Peter P. Chen, “The Entity-Relationship Model: Toward a Unified View of Data”, ACM Transactions on Database Systems, vol. 1, n. 1, 1976.
21. Wikipedia (in inglese), “Entity–relationship model”, consultato il 25/09/2026, en.wikipedia.org/wiki/Entity–relationship_model.
22. Wikipedia (in inglese), “Top-down and bottom-up design”, consultato il 25/09/2026, en.wikipedia.org/wiki/Top-down_and_bottom-up_design.
23. Wikipedia (in inglese), “Structure chart”, consultato il 25/09/2026, en.wikipedia.org/wiki/Structure_chart.
24. Wikipedia (in inglese), “Coupling (computer programming)”, consultato il 25/09/2026, en.wikipedia.org/wiki/Coupling_(computer_programming).
25. Wikipedia (in inglese), “Cohesion (computer science)”, consultato il 25/09/2026, en.wikipedia.org/wiki/Cohesion_(computer_science).
26. Wikipedia (in inglese), “Software maintenance”, consultato il 25/09/2026, en.wikipedia.org/wiki/Software_maintenance.
27. Wikipedia (in inglese), “Audit trail”, consultato il 25/09/2026, en.wikipedia.org/wiki/Audit_trail.
28. Wikipedia (in inglese), “Object-oriented analysis and design”, consultato il 25/09/2026, en.wikipedia.org/wiki/Object-oriented_analysis_and_design.
29. Wikipedia (in inglese), “Unified Modeling Language”, consultato il 25/09/2026, en.wikipedia.org/wiki/Unified_Modeling_Language.
30. Object Management Group, “Unified Modeling Language (UML)”, specifica, consultato il 25/09/2026, omg.org/spec/UML.
31. Wikipedia (in inglese), “Rapid application development”, consultato il 25/09/2026, en.wikipedia.org/wiki/Rapid_application_development.
32. Wikipedia (in inglese), “Use case”, consultato il 25/09/2026, en.wikipedia.org/wiki/Use_case.
33. Wikipedia (in inglese), “User story”, consultato il 25/09/2026, en.wikipedia.org/wiki/User_story.