🎯 ATIVIDADE 03: ENGENHARIA DE REQUISITOS (FR E NFR)

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da indústria, aprendendo a redigir o contrato técnico que guiará todos os programadores. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

• Diferenciar Requisitos Funcionais (RF) (O que o sistema faz) de Requisitos Não-Funcionais (RNF) (Como o sistema se comporta).
• Redigir requisitos com alto rigor técnico utilizando o padrão de escrita: "O sistema deve...".
• Aplicar uma matriz de priorização de requisitos (Essencial, Importante, Desejável).

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, após o seu time decidir utilizar a metodologia ágil (Atividade 02), a diretoria começou a bombardear a equipe com ideias para o novo App de Rastreamento. O diretor de Vendas quer que o App tenha "um mapa bem bonito e rápido". O diretor de Logística quer "um botão de pânico para o motorista".

Ouvindo essas demandas soltas, os desenvolvedores não sabem o que programar primeiro, nem como medir se o mapa é "bonito e rápido" o suficiente.

"Seu desafio é atuar como Engenheiro de Requisitos. Você deve traduzir as falas confusas e abstratas da diretoria em Requisitos Funcionais e Não-Funcionais matemáticos, testáveis e priorizados, criando a lista mestra que o time de desenvolvimento vai usar para trabalhar."

🧠 Fundamentos: A Teoria Traduzida

A Engenharia de Requisitos é a arte de extrair a verdade. Se o requisito for mal escrito, o programador criará o código errado.

Funcional vs Não-Funcional

• Funcional (RF): É uma ação. É um botão que você clica, uma tela que abre, um cálculo que é feito. (Ex: "O sistema deve calcular o frete").
• Não-Funcional (RNF): É a infraestrutura, a performance, a segurança. Você não clica num RNF, você o sente. (Ex: "O cálculo do frete deve ser respondido em menos de 2 segundos").

📊 Visualizando a Lógica

[!TIP] Use sempre o padrão "O sistema deve [AÇÃO] quando [CONDIÇÃO]". Nunca use adjetivos (bonito, rápido, seguro), use métricas exatas!

flowchart LR
    A["Fica abstrata do cliente:<br/>'O app tem que ser seguro'"] --> B{"Filtro do Engenheiro"}
    B --> C["RNF01: O sistema deve exigir<br/>uma senha de 8 caracteres<br/>alfanuméricos no login."]

📖 Exemplo Guiado

Abaixo, veja como categorizar e escrever requisitos de forma profissional.

📊 Priorização MoSCoW dos Requisitos da TecProExpress

flowchart TD
    subgraph MUST [Must Have - Essencial]
        M1["RF01: Login do Motorista"]
        M2["RF02: Listar Entregas do Dia"]
    end
    subgraph SHOULD [Should Have - Importante]
        S1["RF03: Roteirização Automática"]
    end
    subgraph COULD [Could Have - Desejável]
        C1["RF04: Som ao atribuir carga"]
    end
    MUST --> SHOULD --> COULD

    style MUST fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style SHOULD fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style COULD fill:#fffde7,stroke:#fbc02d,stroke-width:2px

🛠️ Estrutura de Documentação de Requisitos

# Lista de Requisitos (App Rastreio Express)

## Requisitos Funcionais (RF)
| ID | Descrição | Prioridade |
| :--- | :--- | :--- |
| RF01 | O sistema deve permitir que o motorista faça login via CPF e Senha. | Essencial |
| RF02 | O sistema deve listar as entregas do dia em ordem de distância. | Importante |
| RF03 | O sistema deve emitir um som quando um novo pacote for atribuído. | Desejável |

## Requisitos Não-Funcionais (RNF)
| ID | Categoria | Descrição |
| :--- | :--- | :--- |
| RNF01 | Performance | A listagem de entregas deve carregar em < 2 segundos. |
| RNF02 | Segurança | As senhas devem ser criptografadas em BCrypt no banco. |

🔍 Detalhamento da Documentação:

• A Prioridade salva projetos. Se o prazo apertar, o time corta os requisitos "Desejáveis" para garantir que o "Essencial" suba para produção.
• Categorias de RNF: Podem ser de Performance, Segurança, Usabilidade ou Tecnológicas.

🛠️ Prática Obrigatória 1: A Lista de Requisitos

Cenário: O projeto semestral da sua equipe (criado na Atividade 01).

1. Crie uma tabela com pelo menos 10 Requisitos Funcionais (RF).
2. Crie uma tabela com pelo menos 5 Requisitos Não-Funcionais (RNF).
3. Utilize estritamente a nomenclatura formal (RF01, RNF01) e o padrão de escrita "O sistema deve".
4. Para os Funcionais, indique se a prioridade é: Essencial, Importante ou Desejável.

🏁 Resultado Esperado (Para sua Referência)

Duas tabelas organizadas e limpas, sem ambiguidades, onde qualquer programador saberia exatamente o que fazer ao lê-las.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas documentações técnicas:

1. Salve o arquivo de documentação com o nome Atividade_03.md na pasta es-atv-03-requisitos/ do seu repositório GitHub.
2. Certifique-se de fazer o commit e push para o repositório público.
3. Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Imagine que você escreveu o seguinte requisito: "RF04: O sistema deve ter uma tela de relatórios legais". Durante a entrega, o cliente recusou o sistema dizendo que o relatório não era "legal" o suficiente. Como engenheiro, onde esteve o erro e como você reescreveria esse requisito para se proteger de recusas futuras? 🧠🛡️