O registro documental de requisitos seguem padrões reconhecidos pela engenharia de software. Conheça mais e veja um modelo aderente a esses ...
A documentação de requisitos é o alicerce de qualquer projeto de software bem-sucedido. Este post aborda os fundamentos da escrita estruturada de cenários principais e alternativos em casos de uso, apresenta os padrões normativos mais relevantes e reúne boas práticas organizacionais reconhecidas pela literatura. O conteúdo é direcionado a estudantes e profissionais que desejam produzir documentos de requisitos claros, rastreáveis e verificáveis.
Em engenharia de software, o termo requisito designa tanto uma declaração abstrata sobre um serviço que o sistema deve oferecer quanto uma definição formal e detalhada de uma função específica (SOMMERVILLE, 2011). Essa amplitude semântica exige que a documentação de requisitos seja cuidadosamente organizada para atender a públicos distintos — desde gerentes e clientes que necessitam de uma visão de alto nível até desenvolvedores e testadores que dependem de especificações precisas e verificáveis.
A norma ISO/IEC/IEEE 29148:2018, que substituiu a clássica IEEE 830-1998, estabelece que uma boa especificação de requisitos deve ser completa, consistente, rastreável e verificável (ISO/IEC/IEEE, 2018). Cada requisito precisa ser descrito de modo que seja possível confirmar seu atendimento por um método prescrito, seja por inspeção, demonstração ou teste. A norma distingue três níveis documentais: a especificação de requisitos das partes interessadas (StRS), a especificação de requisitos de sistema (SyRS) e a especificação de requisitos de software (SRS), cada uma com escopo e público-alvo próprios.
Requisitos funcionais e não funcionais
A classificação mais difundida separa os requisitos em funcionais — que definem o que o sistema deve fazer — e não funcionais — que descrevem as restrições e qualidades com que ele deve operar (SOMMERVILLE, 2011). Requisitos funcionais descrevem serviços, reações a entradas específicas e comportamentos em situações determinadas. Já os não funcionais abrangem propriedades como desempenho, usabilidade, confiabilidade e segurança. Na prática, como observa Sommerville, a separação entre essas categorias nem sempre é nítida, pois um requisito aparentemente não funcional pode dar origem a requisitos funcionais derivados ao ser detalhado.
Pressman e Maxim acrescentam que a documentação de requisitos deve incluir também as regras de negócio — restrições que governam o domínio do problema e que condicionam o comportamento do sistema sem serem, elas mesmas, funcionalidades (PRESSMAN; MAXIM, 2021). Um exemplo clássico é a regra de que um aluno pode emprestar no máximo três livros simultaneamente: ela não é uma função do sistema, mas uma restrição do domínio que afeta diretamente o comportamento das funções de empréstimo.
Casos de uso e a escrita estruturada de cenários
Um caso de uso captura um contrato entre as partes interessadas de um sistema acerca de seu comportamento (COCKBURN, 2001). Diferentemente de uma simples lista de funcionalidades, o caso de uso descreve a interação passo a passo entre um ator e o sistema para atingir um objetivo específico. Essa narrativa estruturada permite que analistas, desenvolvedores e testadores compartilhem a mesma compreensão sobre o comportamento esperado.
Cockburn propõe que cada caso de uso seja documentado com os seguintes campos: identificador, nome, ator principal, partes interessadas e seus interesses, pré-condições, garantias mínimas, garantias de sucesso (pós-condições), gatilho, cenário principal de sucesso e extensões (cenários alternativos e de exceção) (COCKBURN, 2001). A estrutura pode ser apresentada em formato resumido (uma tabela de poucas linhas), casual (narrativa livre) ou completo (com todos os campos), a depender da criticidade do requisito e da maturidade do projeto.
Cenário principal de sucesso
O cenário principal (também chamado de fluxo básico ou happy path) descreve a sequência de passos que ocorre quando tudo dá certo. Cada passo é uma sentença simples no formato "sujeito + verbo + complemento", indicando se a ação é do ator ou do sistema (COCKBURN, 2001). A clareza desse cenário é fundamental porque ele serve de referência para todos os demais — os cenários alternativos são definidos como desvios em relação a ele.
Valente reforça que o cenário principal deve conter entre 3 e 9 passos no nível de abstração adequado, evitando detalhes de interface gráfica e mantendo o foco no comportamento essencial do sistema (VALENTE, 2020). Quando o cenário principal precisa de mais passos, isso frequentemente indica que o caso de uso deveria ser dividido ou que sub-casos de uso deveriam ser extraídos via relacionamento de inclusão.
Cenários alternativos e de exceção
Os cenários alternativos (ou extensões, na terminologia de Cockburn) descrevem o que acontece quando uma condição do cenário principal não é atendida. A notação mais difundida usa o número do passo de desvio seguido de uma letra, por exemplo: "3a — O sistema identifica que o aluno não cumpriu os pré-requisitos" (COCKBURN, 2001). Cada extensão deve indicar claramente a condição de ativação (quando ela ocorre), as ações executadas e o ponto de retorno ao cenário principal — ou, se for o caso, que o fluxo é encerrado.
Uma boa prática é percorrer sistematicamente cada passo do cenário principal perguntando "o que pode dar errado aqui?" (COCKBURN, 2001). Isso garante que nenhuma condição de falha relevante seja esquecida. As extensões mais comuns incluem entradas inválidas, dados não encontrados, violações de regras de negócio, indisponibilidade de recursos e cancelamentos pelo usuário. Pressman e Maxim recomendam que cada cenário alternativo seja rastreável à regra de negócio ou restrição que o originou, criando uma malha de rastreabilidade entre requisitos, regras e cenários (PRESSMAN; MAXIM, 2021).
Modelo de especificação de caso de uso
A tabela a seguir apresenta um modelo de especificação baseado em Cockburn, com adaptações para uso acadêmico e profissional:
| Campo | Descrição |
| Identificador | Código único (ex.: UC-01) |
| Nome | Verbo no infinitivo + complemento (ex.: Realizar Matrícula) |
| Ator principal | Quem inicia a interação |
| Pré-condições | Estado obrigatório do sistema antes da execução |
| Pós-condições | Estado do sistema após a execução bem-sucedida |
| Fluxo principal | Passos numerados do cenário de sucesso |
| Fluxos alternativos | Desvios identificados por passo + letra (ex.: 3a) |
| Regras de negócio | Referências às RN aplicáveis |
| Rastreabilidade | Vínculo com RF, história de usuário e artefatos |
Fonte: adaptado de Cockburn (2001) e Pressman e Maxim (2021).
Boas práticas organizacionais
A organização do documento de requisitos é tão importante quanto o conteúdo dos requisitos individuais. A ISO/IEC/IEEE 29148 recomenda que o documento seja estruturado de forma coerente, com índice, referências cruzadas e controle de versão, evitando redundância e garantindo que cada requisito seja expresso de forma independente e rastreável (ISO/IEC/IEEE, 2018). A seguir, são apresentadas as boas práticas mais recorrentes na literatura.
Identificação unívoca: cada requisito, regra de negócio e caso de uso deve ter um código único (RF-01, RN-01, UC-01) que permita referenciá-lo em qualquer outro artefato do projeto — matriz de rastreabilidade, plano de testes, backlog e contratos (SOMMERVILLE, 2011).
Priorização explícita: o uso de esquemas de priorização como MoSCoW (Must, Should, Could, Won't) ou a técnica de Kano ajuda a comunicar ao time de desenvolvimento quais requisitos são essenciais e quais podem ser adiados (PRESSMAN; MAXIM, 2021).
Separação de interesses: o documento deve separar claramente o que o sistema faz (requisitos funcionais) do como ele faz (decisões de projeto), evitando que restrições de implementação contaminem a especificação de comportamento (VALENTE, 2020).
Linguagem precisa: Cockburn recomenda frases na voz ativa, no presente, com sujeito explícito em cada passo. Devem-se evitar termos vagos como "adequado", "rápido" ou "amigável" — substituindo-os por métricas verificáveis (COCKBURN, 2001). A ISO/IEC/IEEE 29148 complementa esse ponto ao orientar o uso de verbos modais padronizados: shall (deve) para requisitos obrigatórios, should (deveria) para recomendações e may (pode) para permissões (ISO/IEC/IEEE, 2018).
Rastreabilidade bidirecional: cada requisito deve ser rastreável tanto para trás (à sua origem — entrevista, ata, norma) quanto para frente (ao artefato que o implementa — código, caso de teste, protótipo). Matrizes de rastreabilidade cruzada são o instrumento mais usado para garantir essa propriedade (SOMMERVILLE, 2011).
Revisão e validação iterativa: Sommerville e Sawyer destacam que o documento de requisitos deve ser revisado conjuntamente por clientes, analistas e desenvolvedores em ciclos curtos, usando técnicas como inspeção formal, prototipação e walkthroughs (SOMMERVILLE; SAWYER, 1997). A validação precoce reduz significativamente o custo de correção de defeitos em fases posteriores do projeto.
Exemplo prático: Documento de Requisitos do SIGMAT
Para consolidar os conceitos apresentados, segue um exemplo de Especificação de Requisitos de Software (ERS) baseado na estrutura da ISO/IEC/IEEE 29148 (ISO/IEC/IEEE, 2018) e nas recomendações de Sommerville (SOMMERVILLE, 2011). O sistema utilizado como referência é o SIGMAT — Sistema de Matrícula em Disciplinas de uma universidade fictícia. Cada seção apresenta uma amostra representativa dos itens; os demais são indicados pela notação XX-NN.
Especificação de Requisitos de Software
SIGMAT — Sistema de Matrícula em Disciplinas
Versão 1.0 — Abril de 2026
1 Introdução
1.1 Objetivo
Este documento descreve os requisitos funcionais, não funcionais e as regras de negócio do SIGMAT. Destina-se à equipe de desenvolvimento, aos gestores acadêmicos e aos representantes dos alunos que participam da validação do sistema (ISO/IEC/IEEE, 2018).
1.2 Escopo
O SIGMAT abrange os processos de matrícula, cancelamento de matrícula, consulta de disciplinas ofertadas, gerenciamento de oferta pela secretaria e emissão de comprovantes. O sistema não cobre lançamento de notas, controle de frequência nem gestão financeira.
1.3 Definições, siglas e abreviações
| Termo | Definição |
| SIGMAT | Sistema de Matrícula em Disciplinas |
| ERS | Especificação de Requisitos de Software |
| UC | Caso de uso (Use Case) |
| RF | Requisito funcional |
| RNF | Requisito não funcional |
| RN | Regra de negócio |
1.4 Referências
ISO/IEC/IEEE 29148:2018; Regimento Geral da UFA, Resolução nº 42/2025 (Normas de Matrícula); Plano de Ensino do Semestre 2026.1.
2 Descrição geral do produto
2.1 Perspectiva do produto
O SIGMAT é um sistema web novo que substituirá o processo manual de matrícula por formulários em papel. Será integrado ao Sistema Acadêmico Central (SAC) para consulta de histórico e ao módulo de autenticação institucional (SSO). Não possui dependência de hardware especializado.
2.2 Funções do produto
Em resumo, o SIGMAT realizará: matrícula e cancelamento de matrícula em disciplinas; consulta de disciplinas ofertadas por semestre; gerenciamento de oferta pela secretaria; emissão de comprovante de matrícula; verificação automática de pré-requisitos, vagas, créditos e conflito de horário.
2.3 Características dos usuários
| Ator | Descrição | Nível técnico |
| Aluno | Usuário com matrícula ativa que solicita inscrição em disciplinas. | Básico |
| Secretaria | Funcionário que gerencia oferta de disciplinas e resolve pendências. | Intermediário |
| Sist. Pré-requisitos | Módulo interno que valida a aprovação em disciplinas anteriores. | — |
Fonte: elaborado pelo autor.
2.4 Restrições
O sistema deve funcionar nos navegadores Chrome, Firefox e Edge (duas últimas versões estáveis). A autenticação será delegada ao SSO institucional (SAML 2.0). O banco de dados deve ser PostgreSQL 15 ou superior, conforme padrão da DTI.
3 Requisitos específicos
3.1 Requisitos funcionais
| ID | Nome | Descrição | Prioridade |
| RF-01 | Realizar Matrícula | O sistema deve permitir que o aluno solicite matrícula em uma disciplina ofertada no semestre corrente, desde que atendidas as pré-condições de pré-requisitos, vagas, créditos e horário. | Must |
| RF-02 | Consultar Disciplinas | O sistema deve permitir a consulta de disciplinas ofertadas, com filtros por curso, turno, professor e disponibilidade de vagas. | Must |
| RF-03 | Cancelar Matrícula | O sistema deve permitir que o aluno cancele uma matrícula confirmada, desde que dentro do prazo regulamentar de 7 dias (RN-06). | Must |
| RF-04 | Gerenciar Oferta | O sistema deve permitir que a secretaria cadastre, altere e remova disciplinas ofertadas no semestre, incluindo professor, horário, sala e número de vagas. | Must |
| RF-05 | Emitir Comprovante | O sistema deve gerar comprovante de matrícula em PDF, contendo todas as disciplinas confirmadas do aluno no semestre, com horários e códigos de registro. | Should |
| RF-NN | … | Demais requisitos funcionais do SIGMAT. | — |
Fonte: elaborado pelo autor com base em ISO/IEC/IEEE (2018).
3.2 Requisitos não funcionais
| ID | Categoria | Descrição | Métrica |
| RNF-01 | Desempenho | O sistema deve responder a qualquer consulta de disciplinas em tempo máximo de 2 segundos, sob carga de até 500 usuários simultâneos. | ≤ 2 s (P95)* |
| RNF-02 | Disponibilidade | O sistema deve estar disponível durante o período de matrícula com uptime mínimo de 99,5%, exceto janelas de manutenção previamente comunicadas. | ≥ 99,5% |
| RNF-03 | Segurança | Todas as operações de matrícula e cancelamento devem ser registradas em log de auditoria imutável, contendo identificação do usuário, data/hora e ação realizada. | 100% das ops. |
| RNF-04 | Usabilidade | O processo de matrícula em uma disciplina deve ser concluído em no máximo 3 passos de interação a partir da tela de consulta de disciplinas. | ≤ 3 cliques |
| RNF-NN | … | Demais requisitos não funcionais do SIGMAT. | — |
Fonte: elaborado pelo autor com base em Sommerville (2011).
*P95 (percentil 95): indica que 95% de todas as requisições medidas devem ter tempo de resposta igual ou inferior ao valor especificado. É preferível à média porque esta mascara picos individuais de latência (ISO/IEC/IEEE, 2018).
3.3 Regras de negócio
| ID | Regra | Descrição | Origem |
| RN-01 | Limite de créditos | O aluno pode cursar no máximo 28 créditos por semestre. | Res. 42/2025, art. 15 |
| RN-02 | Pré-requisitos | O aluno só pode se matricular em disciplina cujos pré-requisitos foram cumpridos com aprovação. | Res. 42/2025, art. 18 |
| RN-03 | Conflito de horário | Não é permitida matrícula em disciplinas com sobreposição total ou parcial de horário. | Res. 42/2025, art. 20 |
| RN-04 | Vagas | A matrícula só é confirmada se houver vaga disponível na turma. Caso contrário, o aluno pode optar por entrar na lista de espera. | Res. 42/2025, art. 22 |
| RN-05 | Período de matrícula | Matrículas só podem ser realizadas dentro do período definido no calendário acadêmico do semestre. | Calendário 2026.1 |
| RN-06 | Prazo de cancelamento | O cancelamento de matrícula é permitido até 7 dias corridos após a data de confirmação. | Res. 42/2025, art. 25 |
| RN-NN | … | Demais regras de negócio do SIGMAT. | — |
Fonte: elaborado pelo autor com base na Resolução nº 42/2025 da UFA (fictícia).
4 Casos de uso
4.1 Visão geral
O SIGMAT possui 8 casos de uso (UC-01 a UC-08), organizados em torno de dois atores humanos (Aluno e Secretaria) e um ator de sistema (Sistema de Pré-requisitos). O diagrama de casos de uso correspondente deve ser produzido como artefato complementar a esta ERS.
4.2 UC-01 — Realizar Matrícula em Disciplina
| Campo | Valor |
| Identificador | UC-01 |
| Nome | Realizar Matrícula em Disciplina |
| Ator principal | Aluno |
| Partes interessadas | Aluno (obter vaga); Secretaria (manter oferta regular); Coordenação (cumprir carga mínima) |
| Pré-condições | 1) Aluno autenticado via SSO; 2) Período de matrícula aberto (RN-05). |
| Pós-condições (sucesso) | 1) Matrícula registrada no banco; 2) Vaga decrementada na turma; 3) Registro gravado no histórico de operações. |
| Gatilho | Aluno seleciona a opção "Matricular-se" na tela de consulta de disciplinas. |
| Regras de negócio | RN-01, RN-02, RN-03, RN-04, RN-05 |
| Rastreabilidade | RF-01; RNF-01 (desempenho); RNF-03 (auditoria) |
Fonte: elaborado pelo autor com base em Cockburn (2001).
Fluxo principal (cenário de sucesso)
| Passo | Responsável | Ação |
| 1 | Aluno | Acessa a tela de matrícula e seleciona a disciplina/turma desejada. |
| 2 | Sistema | Verifica se o período de matrícula está aberto (RN-05). |
| 3 | Sistema | Consulta os pré-requisitos da disciplina e valida se o aluno os cumpriu (RN-02). |
| 4 | Sistema | Verifica se há vaga disponível na turma selecionada (RN-04). |
| 5 | Sistema | Verifica se o total de créditos do aluno, somado à disciplina, não excede 28 (RN-01). |
| 6 | Sistema | Verifica se não há conflito de horário com disciplinas já matriculadas (RN-03). |
| 7 | Sistema | Confirma a matrícula, decrementa a vaga, grava no histórico e exibe a confirmação ao aluno. |
Fluxos alternativos
| Passo | Condição | Ação do sistema | Retorno |
| A1 — Período encerrado (desvio do passo 2) | |||
| 2a | O período de matrícula não está aberto. | Exibe mensagem: "Período de matrícula encerrado. Consulte o calendário acadêmico." | Encerra UC |
| A2 — Pré-requisito não cumprido (desvio do passo 3) | |||
| 3a | Um ou mais pré-requisitos não foram aprovados. | Exibe lista de pré-requisitos pendentes com código e nome de cada disciplina. | Volta ao 1 |
| A3 — Sem vagas (desvio do passo 4) | |||
| 4a | Não há vaga na turma. | Informa que não há vagas e oferece opção de lista de espera. | — |
| 4b | Aluno aceita lista de espera. | Registra o aluno na lista de espera com posição e data/hora. | Encerra UC |
| 4c | Aluno recusa lista de espera. | — | Volta ao 1 |
| A4 — Limite de créditos excedido (desvio do passo 5) | |||
| 5a | A matrícula ultrapassaria 28 créditos. | Exibe créditos atuais, créditos da disciplina solicitada e o excedente resultante. | Volta ao 1 |
| A5 — Conflito de horário (desvio do passo 6) | |||
| 6a | Há sobreposição de horário. | Exibe as disciplinas em conflito com seus respectivos dias e horários. | Volta ao 1 |
Fonte: elaborado pelo autor com base em Cockburn (2001).
5 Matriz de rastreabilidade (amostra)
| RF | UC | RN aplicáveis | RNF relacionados |
| RF-01 | UC-01 | RN-01, RN-02, RN-03, RN-04, RN-05 | RNF-01, RNF-03 |
| RF-02 | UC-02 | — | RNF-01, RNF-04 |
| RF-03 | UC-03 | RN-06 | RNF-03 |
| RF-04 | UC-04 | RN-04, RN-05 | RNF-03 |
| RF-05 | UC-05 | — | RNF-04 |
| RF-NN | UC-NN | … | … |
Fonte: elaborado pelo autor com base em Sommerville (2011).
6 Histórico de revisões
| Versão | Data | Autor | Descrição da alteração |
| 1.0 | 12/04/2026 | Equipe SIGMAT | Versão inicial da ERS com RF-01 a RF-05, RNF-01 a RNF-04, RN-01 a RN-06, UC-01 completo. |
O exemplo acima apresenta amostras representativas de cada seção do documento, sinalizadas pela notação XX-NN no último item de cada tabela. Em um documento real, todas as seções seriam exaustivamente preenchidas com a totalidade dos requisitos, casos de uso e regras do sistema, conforme recomendado pela ISO/IEC/IEEE (2018).
Considerações finais
A documentação de requisitos não é um artefato burocrático: é a base sobre a qual se apoiam todas as decisões de projeto, implementação e teste. A escrita estruturada de cenários — com fluxos principais e alternativos claramente delimitados — transforma intenções vagas em especificações verificáveis. As boas práticas organizacionais aqui reunidas, respaldadas pelas normas internacionais e pela literatura consagrada da engenharia de software, oferecem um ponto de partida sólido para estudantes e profissionais que desejam produzir documentos de requisitos com qualidade e rigor.
Referências
COCKBURN, Alistair. Writing effective use cases. Boston: Addison-Wesley, 2001. (Agile Software Development Series). Disponível em: https://books.google.com/books/about/Writing_Effective_Use_Cases.html. Acesso em: 12 abr. 2026.
ISO/IEC/IEEE. ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. 2. ed. Geneva: ISO, 2018. Disponível em: https://www.reqview.com/doc/iso-iec-ieee-29148-templates/. Acesso em: 12 abr. 2026.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011. Disponível em: https://engsoftmoderna.info/cap3.html (capítulo de referência aberta). Acesso em: 12 abr. 2026.
SOMMERVILLE, Ian; SAWYER, Pete. Requirements engineering: a good practice guide. Chichester: John Wiley & Sons, 1997.
VALENTE, Marco Tulio. Engenharia de software moderna: princípios e práticas para desenvolvimento de software com produtividade. Belo Horizonte: ASERG/DCC/UFMG, 2020. Disponível em: https://engsoftmoderna.info/. Acesso em: 12 abr. 2026.
Fonte:
Visto no Brasil Acadêmico
Comentários