Análise e modelagem de sistemas: o que acontece antes da primeira linha de código

Quando alguém encomenda um sistema, a expectativa costuma ser ver telas logo na primeira semana. Faz sentido: tela é a parte visível. Mas o que define se um sistema vai funcionar bem por anos acontece antes, numa etapa que o cliente quase nunca vê: a análise e a modelagem.

Eu sou desenvolvedora fullstack e desenvolvo sistemas e SaaS sob encomenda. Neste artigo, mostro o que acontece nessa etapa, com um exemplo de sistema de agendamento para clínica, e deixo uma lista de perguntas para você usar ao contratar qualquer desenvolvedor.

O que é análise e modelagem de sistemas

Análise é entender o problema: como o negócio funciona hoje, quem vai usar o sistema, o que cada pessoa precisa fazer e quais regras não podem ser quebradas. Modelagem é transformar esse entendimento em modelos, quase sempre diagramas, que descrevem o sistema antes que ele exista.

A comparação mais honesta é com a construção civil. Ninguém sério começa uma casa pelas paredes: primeiro vem a planta, depois a obra. No software, os modelos cumprem o papel da planta. Eles permitem discutir, corrigir e aprovar o projeto enquanto mudar ainda é barato.

Por que essa etapa economiza dinheiro

Barry Boehm e Victor Basili, dois nomes clássicos da engenharia de software, reuniram em 2001 as conclusões de décadas de estudos sobre defeitos em software. Uma das principais: encontrar e corrigir um problema depois que o sistema foi entregue costuma custar muitas vezes mais do que resolvê-lo na fase de requisitos e projeto. Em sistemas grandes e críticos, eles falam em diferenças de até 100 vezes; em sistemas menores, a diferença é menor, mas continua existindo.

O motivo é simples. No papel, mudar uma regra é apagar uma seta. Com o sistema no ar, a mesma mudança pode mexer no banco de dados, nas telas, nos relatórios, nos dados já cadastrados e na rotina de quem usa.

As 4 etapas antes de programar

1. Levantamento de requisitos

Requisitos são as necessidades que o sistema precisa atender. Eles se dividem em dois tipos:

• Requisitos funcionais: o que o sistema faz. Exemplo: "o paciente pode remarcar a consulta até 24 horas antes".
• Requisitos não funcionais: como o sistema precisa se comportar. Exemplo: "só a recepção e o profissional responsável veem os dados de contato do paciente" ou "a agenda precisa abrir rápido no celular".

O levantamento é feito com conversas, observação da rotina e análise de planilhas, formulários e sistemas que já existem. A norma internacional ISO/IEC/IEEE 29148 trata justamente desse processo, que a engenharia de software chama de engenharia de requisitos.

A regra de ouro: requisito bom pode ser testado. "O sistema deve ser fácil" não é requisito. "Uma consulta deve ser marcada em até três toques no celular" é.

2. Casos de uso

Um caso de uso descreve uma interação completa entre uma pessoa (o ator) e o sistema para atingir um objetivo. "Agendar consulta" é um caso de uso; "clicar no botão azul" não é.

Para cada caso de uso, descrevo o caminho principal e os desvios: o que acontece se o horário for ocupado no meio do processo? E se o paciente não tiver cadastro? Esses desvios são exatamente os pontos em que sistemas mal planejados quebram.

3. Modelagem com diagramas

Com requisitos e casos de uso definidos, o sistema é desenhado. A linguagem padrão para isso é a UML (Unified Modeling Language), mantida pelo Object Management Group (OMG). A UML tem mais de uma dezena de tipos de diagrama, mas no dia a dia de um sistema sob encomenda poucos fazem a maior parte do trabalho:

4. Validação com o cliente

O modelo só vale se o cliente se reconhece nele. Nesta etapa, apresento os diagramas e os fluxos em linguagem simples e caminhamos juntos por situações reais: "uma paciente liga para remarcar, o que acontece?". É aqui que aparecem frases como "ah, mas aqui a gente faz diferente". Cada uma delas, descoberta nesta etapa, é retrabalho evitado.

Exemplo: um sistema de agendamento para clínica

Para deixar concreto, um exemplo fictício e simplificado: uma clínica com três profissionais quer um sistema de agendamento.

Alguns requisitos levantados:

• O paciente agenda pelo celular, escolhendo profissional e horário livre;
• A recepção vê a agenda de todos e pode marcar, remarcar e cancelar;
• Cada profissional vê só a própria agenda e registra o atendimento;
• O sistema envia lembrete antes da consulta e registra a confirmação;
• Dados de pacientes são dados pessoais e, em muitos casos, dados de saúde: acesso restrito por perfil, conforme a LGPD.

Desses requisitos sai o diagrama de casos de uso. Ele mostra, numa imagem, quem faz o quê:

Depois vem o diagrama de classes, que organiza as informações que o sistema guarda. Ele é a base do banco de dados:

Repare no que o desenho revela. Ao listar os status da consulta, surge a pergunta: falta conta como atendimento para o financeiro? E consulta cancelada com menos de 24 horas? Decisões como essas, tomadas no modelo, custam uma conversa. Descobertas depois do lançamento, custam uma reforma.

Engenharia reversa: quando o sistema já existe

Nem todo projeto começa do zero. Muitas vezes o cliente já tem um sistema, uma planilha cheia de fórmulas ou um software antigo que precisa evoluir. Nesses casos, faço o caminho inverso: a engenharia reversa.

Analiso o que existe, as telas, os dados e as regras escondidas no código ou nas fórmulas, e reconstruo os modelos a partir disso. O resultado é um mapa do sistema atual, que mostra o que funciona, o que está duplicado e o que ninguém mais usa. Só depois disso faz sentido decidir entre evoluir, reorganizar ou reconstruir.

Perguntas para fazer antes de contratar um sistema

Use esta lista com qualquer desenvolvedor, inclusive comigo:

1. Como você vai levantar os requisitos? Vai conversar com quem usa o sistema no dia a dia?
2. Vou ver algum modelo ou protótipo antes da programação começar?
3. Como serão tratados os casos de exceção, como cancelamentos, erros e falta de internet?
4. Quem pode ver cada informação? Como fica a proteção de dados?
5. O que acontece quando eu precisar de uma mudança depois de pronto?
6. Os dados e as contas ficam no nome da minha empresa?

Se a resposta para a segunda pergunta for "não precisa, já começo programando", desconfie. Rapidez no início, sem modelo, costuma virar lentidão e custo no meio do projeto.

Como eu trabalho em sistemas sob encomenda

Todo sistema que desenvolvo passa por essas etapas: requisitos, casos de uso, modelos e validação com o cliente antes da primeira linha de código. Só depois vêm a programação da interface, do servidor e do banco de dados, os testes e a implantação. Se você está pensando em um sistema ou SaaS para o seu negócio, veja como funcionam os projetos sob encomenda.