intro
Figura 1 — Visão geral do processo de modelagem com UML.
1 Fechamento de Requisitos
O fechamento de requisitos é o marco que sinaliza a passagem da fase de elicitação e análise para a fase de projeto do sistema. Segundo Sommerville (2019), esse momento envolve a validação formal dos requisitos junto aos stakeholders, garantindo que o escopo acordado esteja completo, consistente e viável. Não se trata de "congelar" todos os requisitos indefinidamente, mas de estabelecer uma linha de base (baseline) que servirá de referência para o controle de mudanças durante o restante do projeto.
Na prática, o fechamento envolve três atividades centrais (Pressman; Maxim, 2021):
b) Priorização e negociação — técnicas como MoSCoW (Must, Should, Could, Won't) são aplicadas para classificar requisitos por importância e viabilidade.
c) Assinatura do documento de requisitos — formalização do aceite, que pode ser digital em ferramentas como Jira, Azure DevOps ou mesmo em ata de reunião.
1.1 Exemplo prático — Sistema de Biblioteca Universitária
Imagine que a equipe levantou 38 requisitos para um sistema de empréstimo de livros. Na reunião de fechamento, o bibliotecário-chefe contesta o requisito RF-12: "O sistema deve permitir reserva de livros por até 48 horas", solicitando que o prazo seja de 72 horas. A equipe registra a alteração, atualiza a baseline e todos os envolvidos assinam o documento revisado. A partir desse ponto, qualquer nova alteração deverá passar pelo processo formal de controle de mudanças.
2 Introdução à UML — Visão Geral de Modelagem e Padrões
A Unified Modeling Language (UML) é uma linguagem padronizada pela Object Management Group (OMG) para especificação, visualização, construção e documentação de artefatos de sistemas de software (OMG, 2017). A versão corrente, UML 2.5.1, organiza seus diagramas em duas grandes categorias:
Tabela 1 — Categorias de diagramas da UML 2.5
| Categoria | Diagramas | Finalidade principal |
|---|---|---|
| Estruturais | Classes, Objetos, Componentes, Implantação, Pacotes, Estrutura Composta, Perfil | Modelar a arquitetura estática do sistema |
| Comportamentais | Casos de Uso, Atividades, Máquina de Estados, Sequência, Comunicação, Tempo, Visão Geral de Interação | Modelar o comportamento dinâmico do sistema |
Fonte: Adaptado de OMG (2017).
Conforme Fowler (2014), a UML pode ser empregada em três níveis: como rascunho (esboços informais), como projeto (modelos detalhados que guiam a implementação) e como linguagem de programação (geração automática de código). Na maioria dos projetos acadêmicos e corporativos, o uso como rascunho ou projeto é o mais frequente.
3 Diagrama de Casos de Uso
O diagrama de casos de uso é a ferramenta mais utilizada para capturar requisitos funcionais sob a perspectiva do usuário. Ele responde à pergunta: "O que o sistema faz para cada tipo de usuário?" (Larman, 2007).
3.1 Elementos fundamentais
Caso de uso: uma funcionalidade ou serviço que o sistema oferece, representada por uma elipse com o nome da ação.
Fronteira do sistema: um retângulo que delimita o escopo do sistema, separando o que está "dentro" do que está "fora".
Associação: linha sólida que conecta um ator a um caso de uso, indicando participação.
3.2 Relacionamentos: include e extend
Dois estereótipos são essenciais para organizar a complexidade dos casos de uso (Booch; Rumbaugh; Jacobson, 2006):
«extend» — indica que um caso de uso pode, sob condição específica, estender o comportamento de outro. É opcional. Exemplo: "Realizar Empréstimo" pode ser estendido por "Aplicar Multa por Atraso" (somente se houver devolução em atraso).
3.3 Exemplo prático — Sistema de Biblioteca Universitária
A seguir, a representação textual estruturada do diagrama de casos de uso do sistema de biblioteca. Em ferramentas como Astah, Lucidchart ou draw.io, essa descrição é transformada no diagrama gráfico correspondente.
Observe que o ator Sistema SIG (Sistema Integrado de Gestão da universidade) é um ator não humano: trata-se de um sistema externo que fornece dados de matrícula para a validação da carteirinha. Essa distinção é importante, pois reforça que atores não são necessariamente pessoas (Larman, 2007).
4 Diagrama de Atividades
O diagrama de atividades modela o fluxo de trabalho (workflow) de um processo ou a lógica interna de um caso de uso. Ele é particularmente útil para representar decisões, paralelismo e responsabilidades entre diferentes papéis, por meio de raias de natação (swimlanes) (Sommerville, 2019).
4.1 Elementos do diagrama
Ação: retângulo com bordas arredondadas — representa uma atividade executada.
Decisão / Merge: losango — ponto de ramificação condicional ou reunião de fluxos.
Fork / Join: barra horizontal — indica início e fim de atividades paralelas.
Nó final: círculo preenchido com contorno — encerra o fluxo.
Raias (swimlanes): faixas verticais ou horizontais que atribuem responsabilidade a um ator ou componente.
4.2 Exemplo prático — Fluxo de Empréstimo de Livro
│ Aluno │ Bibliotecário │ Sistema │ │─────────────────────│──────────────────────│──────────────────────│ │ │ │ │ │ ● (início) │ │ │ │ │ │ │ │ │ ┌─────▼──────┐ │ │ │ │ │ Solicitar │ │ │ │ │ │ empréstimo │ │ │ │ │ └─────┬──────┘ │ │ │ │ │ │ │ │ │ ├────────────┼──▶ ┌──────────────┐ │ │ │ │ │ │ Receber │ │ │ │ │ │ │ solicitação │ │ │ │ │ │ └──────┬───────┘ │ │ │ │ │ │ │ │ │ │ │ ├──────────┼──▶ ┌──────────────┐ │ │ │ │ │ │ │ Validar │ │ │ │ │ │ │ │ carteirinha │ │ │ │ │ │ │ └──────┬───────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ ◇ Válida? │ │ │ │ │ │ / \ │ │ │ │ │ │ Sim Não │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ┌───▼───────┐ │ │ │ │ │ │ │ │ Recusar │ │ │ │ │ │ │ │ │ empréstimo│ │ │ │ │ │ │ │ └───┬───────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ◉ (fim) │ │ │ │ │ │ │ │ │ │ │ │ │ ┌─▼──────────────┐ │ │ │ │ │ │ │ Registrar │ │ │ │ │ │ │ │ empréstimo │ │ │ │ │ │ │ └─┬──────────────┘ │ │ │ │ │ │ │ │ │ │ │ ┌────────┼──────────┼────┘ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ │ ┌────────────────┐ │ │ │ │ │ │ Entregar livro │ │ │ │ │ │ └───────┬────────┘ │ │ │ │ │ │ │ │ │ ┌─────▼──────┐ │ │ │ │ │ │ Receber │◀────┼─────────┘ │ │ │ │ livro │ │ │ │ │ └─────┬──────┘ │ │ │ │ │ │ │ │ │ ◉ (fim) │ │ │
Neste diagrama, as raias separam claramente as ações de cada participante. A decisão "Válida?" após a validação da carteirinha cria dois caminhos alternativos: o empréstimo prossegue ou é recusado. Segundo Pressman e Maxim (2021), essa representação facilita a identificação de gargalos e pontos de falha no processo.
5 Documentação de Requisitos
A documentação de requisitos é o artefato central da engenharia de requisitos. A norma IEEE 830, atualizada pela ISO/IEC/IEEE 29148:2018 (ISO/IEC/IEEE, 2018), define a estrutura recomendada para a Especificação de Requisitos de Software (SRS). Um documento bem elaborado deve ser: correto, não ambíguo, completo, consistente, classificado por importância, verificável, modificável e rastreável.
5.1 Estrutura típica de uma SRS
2. Descrição geral (perspectiva do produto, funções, características dos usuários, restrições, suposições)
3. Requisitos específicos (funcionais, não funcionais, de interface, de desempenho, de segurança)
4. Apêndices (modelos de dados, protótipos, glossário)
5.2 Exemplo de requisito funcional documentado
Nome: Realizar Empréstimo de Livro
Descrição: O sistema deve permitir que o bibliotecário registre o empréstimo de um exemplar disponível a um aluno com matrícula ativa e sem pendências.
Prioridade: Essencial (Must)
Entradas: Código do exemplar, número da matrícula
Saídas: Comprovante de empréstimo com data de devolução prevista
Pré-condições: Aluno autenticado; exemplar com status "disponível"
Pós-condições: Status do exemplar alterado para "emprestado"; registro salvo no histórico
Regras de negócio: RN-01 (limite de 3 livros simultâneos); RN-04 (prazo de 14 dias)
Rastreabilidade: UC-03 (caso de uso); US-07 (história de usuário)
6 Dicionário de Dados
O dicionário de dados é um repositório organizado de definições de todos os elementos de dados que circulam pelo sistema: entidades, atributos, tipos, domínios e restrições. Ele elimina ambiguidades e serve como referência única para toda a equipe (Pressman; Maxim, 2021).
6.1 Notação clássica
A notação utilizada em dicionários de dados segue convenções consolidadas na análise estruturada (Yourdon, 1990):
Tabela 2 — Notação de dicionário de dados
| Símbolo | Significado | Exemplo |
|---|---|---|
| = | é composto de | aluno = matrícula + nome + curso |
| + | concatenação (e) | endereço = rua + número + cidade |
| [ | ] | seleção (ou) | sexo = [M | F | Outro] |
| { } | repetição (iteração) | pedido = { item_pedido } |
| ( ) | opcional | telefone = DDD + número + (ramal) |
| ** ** | comentário | **chave primária** |
Fonte: Adaptado de Yourdon (1990).
6.2 Exemplo prático — Entidade "Empréstimo"
empréstimo = **entidade que registra a retirada de exemplar por um aluno**
id_empréstimo : inteiro, autoincremento **chave primária**
+ data_empréstimo : data (AAAA-MM-DD)
+ data_devolução_prev : data (AAAA-MM-DD) **= data_empréstimo + 14 dias (RN-04)**
+ (data_devolução_real): data (AAAA-MM-DD) **preenchida na devolução**
+ status : [ativo | devolvido | atrasado]
+ id_exemplar : inteiro **chave estrangeira → exemplar**
+ matrícula_aluno : char(10) **chave estrangeira → aluno**
+ id_bibliotecário : inteiro **chave estrangeira → funcionário**
Tabela 3 — Dicionário de dados da entidade Empréstimo
| Atributo | Tipo | Tamanho | Nulo? | Domínio / Regra |
|---|---|---|---|---|
| id_empréstimo | INT | — | Não | PK, autoincremento |
| data_empréstimo | DATE | — | Não | Formato AAAA-MM-DD |
| data_devolução_prev | DATE | — | Não | = data_empréstimo + 14 |
| data_devolução_real | DATE | — | Sim | Preenchida na devolução |
| status | ENUM | — | Não | ativo | devolvido | atrasado |
| id_exemplar | INT | — | Não | FK → exemplar |
| matrícula_aluno | CHAR | 10 | Não | FK → aluno |
| id_bibliotecário | INT | — | Não | FK → funcionário |
Fonte: Elaboração própria.
7 Escrita Estruturada de Cenários — Principais e Alternativos
A especificação de casos de uso é complementada pela descrição narrativa dos cenários. O cenário principal (ou fluxo básico) descreve o caminho de sucesso (happy path). Os cenários alternativos descrevem variações ou tratamentos de erro (Cockburn, 2001).
7.1 Modelo de especificação de caso de uso
Ator principal: Bibliotecário
Ator secundário: Sistema SIG
Pré-condições: Bibliotecário autenticado no sistema; exemplar disponível.
Pós-condições (sucesso): Empréstimo registrado; exemplar marcado como "emprestado".
Gatilho: Aluno apresenta carteirinha e solicita o empréstimo.
Cenário principal (fluxo básico)
2. O sistema solicita o número da matrícula do aluno.
3. O bibliotecário informa a matrícula.
4. O sistema envia a matrícula ao Sistema SIG e valida os dados do aluno. [«include» Validar Carteirinha]
5. O sistema exibe o nome do aluno e a quantidade de empréstimos ativos.
6. O bibliotecário informa o código de barras do exemplar.
7. O sistema verifica a disponibilidade do exemplar.
8. O sistema registra o empréstimo com data de devolução prevista (data atual + 14 dias).
9. O sistema gera e exibe o comprovante de empréstimo.
10. O caso de uso é encerrado.
Cenários alternativos
4a.1. O sistema exibe a mensagem "Matrícula não encontrada ou inativa".
4a.2. O caso de uso retorna ao passo 2.
5a. Aluno atingiu o limite de 3 empréstimos simultâneos:
5a.1. O sistema exibe a mensagem "Limite de empréstimos atingido".
5a.2. O caso de uso é encerrado.
7a. Exemplar indisponível (emprestado ou em manutenção):
7a.1. O sistema exibe a mensagem "Exemplar não disponível" e sugere reserva.
7a.2. O caso de uso é encerrado.
*a. A qualquer momento, o bibliotecário pode cancelar a operação:
*a.1. O sistema descarta os dados informados.
*a.2. O caso de uso é encerrado.
A notação *a (asterisco) indica uma alternativa que pode ocorrer em qualquer passo do cenário principal. Essa convenção é proposta por Cockburn (2001) e amplamente adotada na indústria.
8 Boas Práticas Organizacionais
A qualidade da documentação depende não apenas do conteúdo, mas da disciplina organizacional. A seguir, são elencadas práticas recomendadas pela literatura e pelo mercado.
8.1 Rastreabilidade bidirecional
Cada requisito deve ser rastreável "para frente" (até o caso de teste e o código) e "para trás" (até a origem — entrevista, documento de negócio, norma legal). A ISO/IEC/IEEE 29148 recomenda o uso de matrizes de rastreabilidade que cruzam requisitos com artefatos de projeto, teste e código (ISO/IEC/IEEE, 2018).
8.2 Versionamento e controle de mudanças
Documentos de requisitos devem ser versionados. Uma tabela de histórico de revisões — com data, autor, versão e descrição da mudança — é obrigatória em projetos profissionais. Ferramentas como Git (para arquivos texto/Markdown) ou os recursos nativos de ferramentas como Jira e Azure DevOps facilitam esse controle (Sommerville, 2019).
8.3 Nomenclatura padronizada
Adote um padrão de identificação consistente para todos os artefatos do projeto. Uma convenção comumente utilizada na indústria é exemplificada a seguir:
Tabela 4 — Exemplo de convenção de nomenclatura de artefatos
| Prefixo | Artefato | Exemplo |
|---|---|---|
| RF- | Requisito Funcional | RF-03 |
| RNF- | Requisito Não Funcional | RNF-12 |
| UC- | Caso de Uso | UC-03 |
| RN- | Regra de Negócio | RN-04 |
| CT- | Caso de Teste | CT-03.01 |
Fonte: Elaboração própria.
8.4 Revisões por pares e validação contínua
Revisões cruzadas entre analistas — e, idealmente, com a participação de desenvolvedores e testadores — reduzem defeitos em até 60%, segundo estimativas de Pressman e Maxim (2021). Inspeções formais (como a técnica de Fagan) ou revisões mais leves (walkthroughs) são aplicáveis conforme o nível de formalidade do projeto.
8.5 Glossário compartilhado e linguagem ubíqua
Manter um glossário unificado, acessível a todos os membros do projeto, evita que termos como "cliente", "usuário" e "assinante" sejam usados de forma intercambiável sem critério. O conceito de linguagem ubíqua (ubiquitous language), proposto por Evans (2003) no contexto de Domain-Driven Design, estende essa ideia: o vocabulário do domínio deve ser compartilhado entre equipe técnica e especialistas de negócio, permeando código, documentos e conversas.
Considerações Finais
O fechamento de requisitos, a modelagem em UML e a documentação estruturada não são etapas burocráticas, mas investimentos diretos na qualidade do software. Um diagrama de casos de uso bem construído comunica o escopo em minutos; um dicionário de dados preciso elimina retrabalho na implementação do banco de dados; cenários bem escritos antecipam falhas antes que o código exista. Para o estudante de Engenharia de Software e Análise de Sistemas, dominar essas técnicas é construir o alicerce sobre o qual metodologias ágeis e tradicionais igualmente se apoiam.
Referências
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2006.
COCKBURN, Alistair. Writing Effective Use Cases. Boston: Addison-Wesley, 2001.
EVANS, Eric. Domain-Driven Design: tackling complexity in the heart of software. Boston: Addison-Wesley, 2003.
FOWLER, Martin. UML Essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3. ed. Porto Alegre: Bookman, 2014.
ISO/IEC/IEEE. ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. Geneva: ISO, 2018.
LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007.
OMG — OBJECT MANAGEMENT GROUP. Unified Modeling Language (UML) Specification, version 2.5.1. Needham: OMG, 2017. Disponível em: https://www.omg.org/spec/UML/2.5.1. Acesso em: 28 mar. 2026.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de Software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.
SOMMERVILLE, Ian. Engenharia de Software. 10. ed. São Paulo: Pearson, 2019.
YOURDON, Edward. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990.
Visto no Brasil Acadêmico
Comentários