Guia Extra: Engenharia de Software e Modelagem UML • Bloco 1: Processo de Software

🗺️ Mapa Conceitual do Capítulo

flowchart LR
    subgraph ENGENHARIA_REQUISITOS["Processo Cíclico de Engenharia de Requisitos (ISO/IEC/IEEE 29148)"]
        direction TB
        V["1. Estudo de Viabilidade\n(Econômica, Técnica e Operacional)"]
        E["2. Elicitação & Análise\n(Entrevistas, JAD, Etnografia, Prototipação)"]
        S["3. Especificação Formal\n(RF · RNF FURPS+ / ISO 25010 · Regras de Negócio)"]
        VA["4. Validação & Homologação\n(Verificabilidade, Consistência, Casos de Teste)"]
        
        V --> E --> S --> VA
        VA -.->|"Defeitos e Inconsistências Detectados"| E
    end

    VA --> DOC["Documento de Requisitos (SRS)\nBaseline Aprovada"]
    DOC --> GEST["Gestão de Mudanças & Matriz de Rastreabilidade Bidirecional"]

    style ENGENHARIA_REQUISITOS fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style S fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style VA fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
    style GEST fill:#fff3e0,stroke:#ff9800,stroke-width:2px

🎯 1. A Importância Estratégica dos Requisitos de Software

Um requisito de software é a declaração de um serviço ou capacidade que o sistema deve fornecer, ou de uma restrição e condição operacional que o sistema deve satisfazer. Estatísticas consolidadas do Standish Group (CHAOS Report) revelam que mais de 50% das falhas catastróficas em projetos de TI têm como causa raiz deficiências em requisitos: especificações incompletas, requisitos ambíguos, expectativas irreais de stakeholders e ausência de envolvimento contínuo dos usuários.

💡 O Paradoxo da Engenharia: Não adianta construir o software com código perfeito e testes automatizados se você construiu o sistema errado (Verification vs Validation). A Engenharia de Requisitos garante que o software resolva o problema real do negócio.

🗣️ 2. Técnicas Avançadas de Elicitação de Requisitos

A elicitação não é um processo passivo de “coleta”, mas uma investigação técnica ativa. Os stakeholders muitas vezes não sabem articular suas necessidades ou descrevem a solução técnica em vez do problema de negócio.

Técnica de Elicitação Mecânica e Execução Melhor Aplicação Prática
Entrevistas Estruturadas Roteiro guiado individual com perguntas abertas e fechadas. Entender responsabilidades e dores específicas de cada perfil de usuário.
Workshops JAD (Joint Application Design) Reuniões intensivas mediadas reunindo usuários, POs e arquitetos na mesma sala. Resolver requisitos conflitantes entre diferentes departamentos com consenso ágil.
Observação Passiva (Shadowing / Etnografia) O engenheiro de requisitos acompanha o dia a dia do usuário no local de trabalho. Descobrir o fluxo real de trabalho e exceções que o usuário esquece de relatar.
Prototipação Rápida (Wireframes Interativos) Mockups navegáveis de baixa a alta fidelidade (Figma/Penpot). Validar a experiência de uso antes de escrever qualquer linha de código backend.
Engenharia Reversa de Documentos Inspeção de planilhas Excel, formulários físicos e relatórios fiscais. Mapear regras de domínio implícitas e formatos de dados consolidados.

📝 3. Classificação e Modelos de Qualidade (FURPS+ e ISO/IEC 25010)

Os requisitos dividem-se em três grandes categorias taxonômicas:

  1. Requisitos Funcionais (RF): Descrevem o comportamento do sistema, transformações de dados e respostas a estímulos de entrada.
  2. Requisitos Não-Funcionais (RNF): Definem atributos de qualidade de serviço e restrições arquiteturais da solução.
  3. Regras de Negócio e Domínio (RD): Imposições legais, regulatórias ou políticas corporativas que existem independentemente de haver um software.

O Modelo FURPS+ (Hewlett-Packard)

  • F - Functionality: Recursos, capacidades e segurança.
  • U - Usability: Fatores humanos, consistência e ergonomia.
  • R - Reliability: Frequência de falhas, recuperabilidade (MTBF e MTTR).
  • P - Performance: Tempo de resposta, throughput e consumo de recursos.
  • S - Supportability: Manutenibilidade, testabilidade e configurabilidade.
  • ”+” (Restrições Adicionais): Restrições de design, implementação, interface e físicas.

⚖️ 4. O Critério da Verificabilidade (Testability)

A qualidade mais crítica de um requisito de engenharia é a não-ambiguidade e verificabilidade: se não for possível desenhar um teste automatizado ou manual que comprove de forma binária (Passou / Falhou) que o requisito foi satisfeito, ele está mal especificado.

graph TD
    A["Requisito Ambíguo (Inaceitável)"] -->|"Refatoração com Métricas SMART"| B["Requisito Verificável (Padrão de Engenharia)"]
    style A fill:#ffebee,stroke:#e53935,stroke-width:2px
    style B fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
❌ Requisito Ambíguo e Frágil ✅ Requisito Verificável e Mensurável (Padrão Ouro)
“O sistema deve ser rápido e tolerar picos de acesso.” [RNF01] O endpoint /api/pedidos deve processar 1.500 req/s com latência no percentil p95 menor que 200ms sob estresse.
“A interface gráfica precisa ser intuitiva para qualquer pessoa.” [RNF02] Um operador novato deve ser capaz de emitir uma nota fiscal em até 90 segundos após 30 minutos de treinamento.
“O banco de dados deve ser seguro contra acessos indevidos.” [RNF03] Todas as senhas devem ser armazenadas com hash Argon2id (custo m=64MB, t=3, p=4); a chave do banco deve ter rotação anual.

📊 5. Matriz de Rastreabilidade Bidirecional

A rastreabilidade garante que o projeto mantenha uma cadeia de evidências ligando a solicitação do cliente aos artefatos de código e testes:

  • Rastreabilidade para Frente (Forward Traceability): Garante que nenhum requisito aprovado foi esquecido durante o desenvolvimento.
  • Rastreabilidade para Trás (Backward Traceability): Evita o Scope Creep (adição de funcionalidades não autorizadas que ninguém pediu) e permite analisar o impacto de uma mudança.
ID Requisito Descrição Resumida Stakeholder Caso de Uso / Feature Componente Código Caso de Teste QA
[RF001] Autenticação com 2FA via OTP Gerente de Segurança UC01 - Login Seguro auth/totp_service.go test_totp_valido()
[RF002] Estorno automático em cartão Dir. Financeiro UC08 - Cancelar Compra billing/refund.go test_estorno_gateway()
[RNF005] Criptografia em trânsito TLS 1.3 Compliance PCI Infraestrutura Web Ingress Nginx TLS audit_ssl_labs()