Processo de Engenharia de Requisitos¶

Documento de Referência de Processo¶

Versão: 1.0 Escopo: Define o processo de Engenharia de Requisitos (ER) a ser seguido no início de cada ciclo de desenvolvimento de software, da elicitação até a geração dos artefatos que alimentam o desenvolvimento.

1. Objetivo¶

Este documento define o pipeline de Engenharia de Requisitos adotado, especificando as técnicas, artefatos, nomenclatura, regras de rastreabilidade e a manutenção da linguagem ubíqua (Glossário) usadas em cada fase, de modo que o processo possa ser replicado de forma consistente em qualquer projeto/ciclo de desenvolvimento.

2. Visão Geral do Pipeline¶

FASE 1: Elicitação de Requisitos ----------> Técnica: KAOS;
FASE 2: Análise e Negociação --------------> Técnicas: Classificação, Priorização, Modelagem;
FASE 3: Especificação/Documentação --------> Documento de Requisitos em camadas + Diagramas UML + Matriz de Rastreabilidade + Glossário;

Cada fase consome a saída da fase anterior. As Fases 1-3 são as formalmente definidas neste processo.

O Glossário atua de forma transversal permeando todas as fases.

3. FASE 1 — Elicitação de Requisitos (KAOS)¶

3.1 Técnica¶

Uso do framework KAOS (Knowledge Acquisition in autOmated Specification), de abordagem orientada a metas (Goal-Oriented Requirements Engineering).

3.2 Procedimento¶

Passo	Atividade	Saída
1	Identificar Termos de Domínio extraídos das metas para evitar ambiguidades	Entradas no Glossário
2	Definir as metas raízes (objetivo estratégico de negócio)	Meta G-000
3	Refinar a meta raiz em submetas via árvore AND/OR, perguntando “Como?” (desce) e “Por quê?” (sobe)	Metas G-00X hierárquicas
4	Realizar Análise de Obstáculos (Obstacle Analysis) em metas de risco	Obstáculos (OBS-000) e metas de resolução
5	Realizar Atribuição de Agentes (Agent Assignment) — definir se a meta é responsabilidade do sistema (software) ou de um agente humano/ambiente	Metas operacionalizáveis (candidatas a Requisito Funcional)

3.3 Nomenclatura¶

Elemento	Formato do ID	Exemplo
Meta	`G-000` (hierárquico, com sufixos por nível)	`G-000`, `G-001`, `G-001.2.1.b.1`
Obstáculo	`OBS-000`	`OBS-014`

3.4 Artefato de saída¶

Documento 02-Goals-KAOS.md — documento único contendo todas as metas do projeto, cada uma com: Descrição, Backward (meta pai), Forward (RF originado), Obstáculo relacionado (se houver), Agente responsável (quando aplicável).

4. FASE 2 — Análise e Negociação¶

4.1 Técnicas usadas¶

Tabela de Classificação de Requisitos;
Matriz de Priorização;
Modelagem: Diagrama de Contexto, Casos de Uso, Diagrama de Casos de Uso, User Stories (derivadas dos Casos de Uso).

4.2 Classificação de Requisitos¶

Toda meta operacionalizável da Fase 1 é convertida em requisito e classificada:

Campo	Valores possíveis
Tipo	Funcional (RF) / Não Funcional (RNF)
Subtipo (se RNF)	Desempenho, Segurança, Usabilidade, Confiabilidade, etc.
Origem	ID da meta KAOS

4.3 Matriz de Priorização¶

Critério	Escala
MoSCoW	Must / Should / Could / Won’t

4.4 Modelagem¶

Artefato	Propósito	Nível de abstração
Caso de Uso (textual)	Detalhar o comportamento passo a passo de uma funcionalidade: fluxo principal, fluxos alternativos, exceções e critérios de aceitação	Requisitos (detalhamento)
Diagrama de Casos de Uso	Mapear o escopo funcional do sistema: quais atores existem e quais funcionalidades cada um pode acessar, incluindo relações entre casos de uso (`<<include>>`, `<<extend>>`)	Requisitos (visão geral)
User Stories	Derivadas de cada fluxo (principal/alternativo) de um Caso de Uso	Requisitos → ponte para o Backlog

Regra de derivação: cada fluxo de um Caso de Uso (principal, alternativo, exceção) pode gerar uma User Story independente e testável isoladamente.

4.5 Artefatos de saída da Fase 2¶

Requisitos classificados e priorizados;
Casos de Uso esboçados;
Diagrama de Casos de Uso;
User Stories esboçadas.

5. FASE 3 — Especificação/Documentação¶

5.1 Princípio estrutural¶

Cada tipo de artefato pertence a um documento único e isolado, contendo todas as instâncias daquele tipo no projeto. A ligação entre documentos é feita exclusivamente por referência de ID (rastreabilidade), nunca por duplicação de conteúdo.

O Glossário é a exceção transversal que dita a nomenclatura em todos os documentos.

5.2 Ordem dos artefatos¶

Glossário (Transversal) + KAOS (Metas) → Requisito Funcional → Épico → Caso de Uso → User Story → Task → Caso de Teste

5.3 Estrutura de documentos¶

Requisitos/
 01-Glossario.md
 02-Goals-KAOS.md
 03-Requisitos.md
 04-Epicos.md
 05-Casos-de-Uso.md
 06-diagrama-casos-de-uso.md
 07-User-Stories.md
 08-Tasks.md
 09-Casos-de-Teste.md
 10-Matriz-de-Rastreabilidade.md

5.4 Regra de rastreabilidade Backward/Forward¶

Campo	Símbolo	Pergunta	Aponta para
Backward	`<`	De onde este artefato veio?	Camada anterior
Forward	`>`	O que este artefato gera/implementa?	Camada seguinte

6. Convenção Geral de Nomenclatura de IDs¶

Camada	Prefixo	Exemplo
Meta (KAOS)	`G-000`	G-001
Obstáculo	`OBS-000`	OBS-014
Requisito Funcional	`RF-000`	RF-014
Requisito Não Funcional	`RNF-000`	RNF-008
Épico	`EPIC-000`	EPIC-07
Caso de Uso	`UC-000`	UC-07
User Story	`US-000`	US-041
Task	`TASK-000`	TASK-118
Caso de Teste	`TC-000`	TC-014

7. Fluxograma Resumido do Processo Completo¶

0. Registrar termos de negócio/técnicos no Glossário
        ↓
1. Definir meta raiz (KAOS)
        ↓
2. Refinar em submetas + obstáculos + agentes (KAOS)
        ↓
3. Converter metas operacionais em Requisitos (RF/RNF)
        ↓
4. Classificar e priorizar Requisitos
        ↓
5. Agrupar Requisitos relacionados em Épicos  
        ↓
6. Modelar: Casos de Uso → Diagrama de Casos de Uso → User Stories
        ↓
7. Detalhar cada Caso de Uso (fluxos principal/alternativo) + Diagrama de Casos de Uso
        ↓
8. Derivar User Stories de cada fluxo do Caso de Uso
        ↓
9. Quebrar User Stories em Tasks técnicas
        ↓
10. Definir Casos de Teste que validam Task/US/UC/RF
        ↓
11. Consolidar tudo na Matriz de Rastreabilidade