# Especificação de Requisitos de Software (ERS)

> Modelo de referência didático. Substitua todos os exemplos pelas informações confirmadas com o cliente. Versão inicial: 0.1 — proposta, não aprovada.

## Controle do documento
| Campo | Valor |
|---|---|
| Projeto | [nome do projeto] |
| Proprietário do produto | [responsável] |
| Organização | [cliente] |
| Responsável técnico | [equipe] |
| Versão | 0.1 |
| Estado | Rascunho |
| Data | [AAAA-MM-DD] |

### Histórico de decisões e versões
| Data | Versão | Autor | Alteração | Aprovação |
|---|---|---|---|---|
| [data] | 0.1 | [responsável] | Primeira descoberta | Pendente |

## 1. Problema, contexto e resultado esperado
- **Problema atual:** O que ocorre, onde, com quem e com qual frequência?
- **Processo existente:** Etapas, exceções, sistemas e documentos utilizados.
- **Objetivo de negócio:** Qual mudança significativa se espera?
- **Indicadores de sucesso:** Como o cliente verificará resultados? Não inventar metas.
- **Fora do escopo:** O que deliberadamente não será desenvolvido?
- **Premissas e restrições:** Legais, orçamentárias, operacionais e técnicas.

## 2. Stakeholders e descoberta
| Perfil / ator | Necessidade | Fonte da evidência | Responsável por validar |
|---|---|---|---|
| [pessoa usuária] | [necessidade] | [entrevista ou observação] | [nome] |
| [gestor] | [necessidade] | [entrevista] | [nome] |

Entrevistas devem confirmar: qual é o problema, quais exceções acontecem, quais dados são necessários, quem autoriza ações e como o erro deve ser comunicado.

## 3. Fluxo atual e fluxo proposto
Descrever as etapas do processo existente com seus responsáveis, entradas, saídas, pontos de decisão, gargalos e exceções. Em seguida, propor um fluxo objetivo e submetê-lo à validação dos usuários.

## 4. Requisitos funcionais (RF)
Formato: **identificador + ator + evento + comportamento observável + critérios de aceite + prioridade + origem**.

| ID | Requisito | Prioridade | Origem | Estado |
|---|---|---|---|---|
| RF-001 | Usuário autenticado deve consultar apenas os próprios pedidos. | Alta | Entrevista [data] | Proposto |
| RF-002 | Gestor autorizado pode alterar o status de pedido e registrar motivo. | Média | Workshop [data] | Proposto |

**Exemplo de critérios de aceite RF-001**
- Dado um usuário autenticado com pedidos, quando acessar a lista, então verá somente seus pedidos.
- Dado um usuário sem pedidos, quando abrir a lista, então verá o estado vazio e orientação.
- Dado um pedido de outro usuário, quando tentar consultar o recurso diretamente, então receberá negação de acesso sem vazamento de dados.

## 5. Requisitos não funcionais (RNF)
Qualidades devem ser mensuráveis. Definir métrica, contexto, medição, prioridade e responsável pela aprovação.

| ID | Qualidade / restrição | Evidência de aceite |
|---|---|---|
| RNF-001 | Acessibilidade WCAG 2.2 AA aplicável aos fluxos críticos | Testes de teclado e tecnologias assistivas documentados |
| RNF-002 | Isolamento de dados entre organizações | Testes positivos/negativos de autorização por tenant |
| RNF-003 | Tempo de resposta dentro do SLO a ser acordado | Medições no cenário e carga definidos |
| RNF-004 | Recuperação após falha | Ensaio de backup/restore com objetivo de recuperação aprovado |

Não declarar percentuais ou limites sem acordo do cliente e evidência real.

## 6. Caso de uso — UC-001: Consultar pedido
- **Ator primário:** Cliente autenticado.
- **Objetivo:** Acompanhar status de um pedido.
- **Pré-condição:** Sessão válida, autorização e referência do pedido.
- **Gatilho:** Cliente seleciona um pedido na lista.
- **Fluxo principal:** sistema identifica o usuário; valida acesso; busca histórico; apresenta status e eventos.
- **Alternativa:** pedido inexistente → apresentar retorno neutro, sem exposição de outros usuários.
- **Exceção:** serviço indisponível → exibir erro recuperável e registrar evento técnico.
- **Pós-condição:** nenhuma mudança de estado do pedido.
- **RF relacionados:** RF-001.
- **RNF relacionados:** RNF-001, RNF-002.
- **Critérios de aceite:** cenários de sucesso, vazio, não autorizado e falha demonstrados.

## 7. Modelo de domínio e dados (a elaborar com o negócio)
Glossário compartilhado, entidades/agregados, regras, invariantes, identificadores, relacionamentos, eventos e política de retenção. Evitar criar banco ou tabelas diretamente a partir de campos de UI sem modelar as regras.

## 8. Integrações, segurança e privacidade
Inventário de sistemas, APIs, autenticação e privilégios mínimos, segregação por tenant, dados pessoais, ameaças, auditoria, logs, limites, recuperação e observabilidade.

## 9. Priorização, dependências e rastreabilidade
| Item | Prioridade MoSCoW | Dependências | Caso de uso | Teste |
|---|---|---|---|---|
| RF-001 | Must | Identity | UC-001 | T-001 |
| RNF-002 | Must | Autorização | UC-001 | SEC-001 |

## 10. Critérios de aceite globais / Definition of Ready
- [ ] Objetivo e escopo acordados com cliente.
- [ ] Requisitos identificados, priorizados e verificáveis.
- [ ] Casos de uso incluem exceções e regras de acesso.
- [ ] RNFs têm forma de medição e responsáveis.
- [ ] Dependências, riscos e dados sensíveis revisados.
- [ ] Desenho de alto nível e dúvidas abertas documentados.
- [ ] Responsáveis aprovam a versão e sabem como solicitar mudanças.

## 11. Riscos, dúvidas abertas e decisões
| ID | Questão / risco | Responsável | Prazo de decisão | Estado |
|---|---|---|---|---|
| D-001 | [pergunta concreta] | [nome] | [data] | Aberto |

## 12. Aprovação e gestão de mudanças
| Papel | Nome | Aceite / restrições | Data |
|---|---|---|---|
| Cliente / product owner | | | |
| Engenharia | | | |
| Segurança / compliance, se aplicável | | | |

**Regra:** toda mudança aprovada atualiza IDs, critérios, rastreabilidade, versão, decisões e evidências. Documento vivo, não especificação descartável.