Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

📜 CAPÍTULO 07: ESPECIFICAÇÃO DE REQUISITOS (ERS)

A Especificação de Requisitos de Software (ERS) é o documento oficial que descreve o que o sistema deve fazer. Na engenharia moderna, ela serve como o "Contrato Técnico" que unifica a visão do desenvolvedor em Home Office com a estratégia do CEO na Matriz. 🛡️🧩


🎯 Objetivo do Capítulo

Aprender a estruturar um documento de especificação profissional seguindo padrões internacionais (IEEE), garantindo que todos os endpoints, regras e metadados estejam documentados antes da codificação.


🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, um cliente externo contratou a empresa para desenvolver um módulo de Gestão de Frotas. Durante a reunião, o cliente disse: "Ah, e eu quero que o sistema seja integrado com o meu ERP antigo".

"Se você não colocar essa integração no documento de ERS, o desenvolvedor não saberá que precisa criar esse conector, e o cliente poderá cobrar a entrega sem pagar o custo extra da integração. O ERS é a sua proteção jurídica e técnica."


🧠 Estrutura Padrão da ERS

Abaixo, a organização funcional que você encontrará em ferramentas de documentação como o Confluence da sua Squad:

Bloco de DocumentaçãoDescrição e Valia Prática
Glossário e DomínioDicionário de jargões (Ex: O que significa 'TED' ou 'PIX' neste contexto?).
Objetivos e NegócioA necessidade global. O que a plataforma resolve comercialmente?
Modelagem de ArquiteturaDesenhos de infraestrutura, bancos de dados e fluxo de eventos.
Especificação TécnicaDetalhamento rota por rota REST, JSONs de entrada/saída e User Stories.

📊 O Papel da Documentação

graph TD
    ERS(["Repositório Confluence / ERS"])
    ERS --> DEV["Devs: Transformam ERS em CÓDIGO"]
    ERS --> CLI["Business: Transforma ERS em VALOR"]
    ERS --> TEST["QA: Transforma ERS em TESTES"]
    
    style ERS fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px

🔍 Estudo de Caso: Locadora Tech (ERS.01)

Imagine uma plataforma de empréstimos digitais (Streaming). O Arquiteto da TecProExpress mapeou as seguintes entidades:

  • 👤 Usuário Titular: Nome, CPF (único), Hash de Senha.
  • 👥 Dependentes: Atrelados ao titular via Foreign Key. Recebem Tokens JWT limitados.
  • 🎬 Catálogo de Filmes: Endpoint POST /api/movies para persistir metadados e links de Blob Storage.

[!TIP] Dica Arquitetural: Nunca confie na memória. Software complexo leva meses para ser construído. Se uma regra de negócio mudar na Sprint 15 e não for atualizada no ERS, o time de QA testará a funcionalidade errada e o erro só aparecerá em produção. 🧠🛡️


💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: O ERS serve para três momentos críticos: No Início (Barreira Contratual), No Meio (Guia de Implementação) e No Fim (Critério de Aceite). Se você pular essa documentação, como provará para o cliente que o sistema está "Pronto"? (Resposta: Sem o ERS, o sistema nunca estará pronto, pois o cliente sempre pedirá 'mais uma coisinha'). 🧠🛡️