DS & II

Capítulo 04 - Engenharia de Requisitos

Leitura de 4 min

🚀 Capítulo 04: Engenharia de Requisitos (Tema: Sherlock Holmes)

NOTE

Este capítulo utiliza a temática de Sherlock Holmes para explicar a Engenharia de Requisitos. Investigue o que o cliente diz para descobrir o que ele realmente precisa!

1. 🎯 Objetivo da Aula

Compreender o conceito de Engenharia de Requisitos, aprendendo a diferenciar Requisitos Funcionais de Requisitos Não-Funcionais e a importância de validar as necessidades do cliente.

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

O detetive Sherlock Holmes é contratado por um cliente desesperado que diz: “Alguém roubou meu diamante de dentro do cofre trancado!“.

  • Sherlock não aceita a primeira história como verdade absoluta. Ele investiga a cena, faz perguntas capciosas e descobre que o cliente, na verdade, tinha esquecido o diamante no bolso do casaco! O cliente achava que sabia o que tinha acontecido, mas estava errado.

Na Engenharia de Software, os clientes agem exatamente assim. Eles chegam dizendo: “Quero um sistema igual ao Facebook”. Se você simplesmente fizer o que eles pedem, vai entregar um produto errado e caro. Você precisa agir como o Sherlock Holmes! Precisa investigar o negócio do cliente, fazer perguntas e descobrir os Requisitos reais do sistema. Seu desafio é desvendar o mistério do que o cliente realmente precisa!

🧠 Fundamentos: A Teoria Traduzida

Um Requisito é uma condição ou capacidade que o sistema deve atender. Nós os dividimos em dois grandes grupos:

⚙️ 1. Requisitos Funcionais (O que o sistema FAZ):

Descrevem as funções e ações que o sistema deve ser capaz de realizar.

  • Exemplo: “O sistema deve permitir que o usuário recupere a senha por e-mail”.
  • Exemplo: “O sistema deve emitir um relatório de vendas em PDF”.

🛡️ 2. Requisitos Não-Funcionais (Como o sistema É):

Descrevem as qualidades, restrições e características do sistema. Não são ações, mas como o sistema se comporta.

  • Exemplo (Desempenho): “O sistema deve carregar as páginas em menos de 2 segundos”.
  • Exemplo (Segurança): “As senhas dos usuários devem ser guardadas com criptografia”.
  • Exemplo (Disponibilidade): “O sistema deve ficar no ar 24 horas por dia, 7 dias por semana”.

4. 📖 Exemplo Guiado: Elicitação de Requisitos

Como o “Sherlock Engenheiro” descobre os requisitos? Usando técnicas de Elicitação (extração):

  1. Entrevistas: Conversar diretamente com quem vai usar o sistema.
  2. Brainstorming: Reunião de chuva de ideias com a equipe e o cliente.
  3. Observação: Ir até a empresa do cliente e ver como eles trabalham hoje no papel para entender o fluxo.

5. 🛠️ Prática Obrigatória 1: Funcional ou Não-Funcional?

Classifique os requisitos abaixo como Funcional ou Não-Funcional:

  1. O aplicativo deve rodar tanto em celulares Android quanto em iPhones.
  2. O usuário deve conseguir cancelar a sua assinatura com apenas dois cliques.
  3. O sistema deve fazer o backup de todos os dados automaticamente todos os dias às 2h da manhã.
  4. O sistema deve permitir o pagamento usando cartão de crédito e PIX.

6. 🛠️ Prática Obrigatória 2: O Cliente Confuso

Um cliente pede para você construir um site de vendas e diz: “Eu quero que o site seja muito rápido!“.

  1. Isso é um requisito funcional ou não-funcional?
  2. Dizer apenas “muito rápido” é uma boa descrição de requisito para um engenheiro? Como você reescreveria esse requisito de forma que pudesse ser testado depois? (Dica: Use números).

7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)

  1. Faça o Commit: No GitHub Desktop, digite a mensagem (ex: Finaliza Capítulo 04 EngSoftware) e clique em Commit to main.
  2. Envie para a Nuvem (Push): Clique em Push origin.

8. 📂 Estrutura de Pastas

extra_engenharia_de_software/
├── capitulos/
│   ├── capitulo_04_requisitos.md
│   └── codigos/
│       └── cap04/
│           └── lista_requisitos.txt

💡 Checkpoint de Lógica

Um erro em um requisito descoberto no início do projeto custa barato para consertar. O mesmo erro descoberto depois que o sistema está pronto pode custar o cancelamento de todo o contrato!

10. 🔥 Desafio de Fixação

Pesquise o que significa a sigla SRS (Software Requirements Specification) ou Especificação de Requisitos de Software.

🔑 Gabarito de Código/Fórmulas

Gabarito da Prática 1:

  1. Não-Funcional (Portabilidade/Compatibilidade).
  2. Funcional (Ação de cancelar assinatura).
  3. Não-Funcional (Confiabilidade/Backup).
  4. Funcional (Ação de pagar). Gabarito da Prática 2:
  5. É um requisito Não-Funcional (Desempenho).
  6. Não. “Muito rápido” é algo subjetivo (o que é rápido para mim pode ser lento para você). O ideal é usar métricas claras.
  7. Sugestão de reescrita: “O sistema deve processar a finalização da compra e exibir a tela de confirmação em no máximo 3 segundos sob carga normal”.

← Capitulo Anterior | Proximo Capitulo →

Visão de gráfico

Backlinks