Considere que será desenvolvido um sistema para controlar a compra e venda de produtos de uma lanchonete. De que forma a engenharia de requisitos pode auxiliar no processo de criação do documento de requisitos? Utilize exemplos para ilustrar a sua resposta.

Passo 1

O que o enunciado pede: explicar de que forma a engenharia de requisitos pode auxiliar no processo de criação do documento de requisitos para um sistema que controla compra e venda de produtos de uma lanchonete, usando exemplos para ilustrar.
Informações fornecidas (implícitas no enunciado): temos um domínio pequeno/operacional (lanchonete) com necessidades de vendas, compras, estoque e relatórios; o objetivo é produzir um documento de requisitos (SRS / Especificação de Requisitos).
O que vou entregar: um passo a passo de como a engenharia de requisitos atua (fases, técnicas e artefatos) e exemplos práticos para cada etapa aplicados ao caso da lanchonete.

Passo 2

O que é e qual o objetivo da engenharia de requisitos (explicação didática curta).
  • Engenharia de requisitos é o conjunto de atividades que identifica quem são os interessados (stakeholders), o que eles precisam, analisa e documenta essas necessidades em requisitos claros, testáveis e gerenciáveis.
  • Objetivo prático: reduzir dúvidas, evitar retrabalho e permitir que equipe de desenvolvimento, cliente e testadores concordem sobre o que será construído.
    Exemplo rápido: sem engenharia de requisitos, o programador pode fazer uma “tela de vendas” que não zera o estoque ou não imprime cupom fiscal — resultando em retrabalho. Com requisitos bem definidos isso é evitado.

Passo 3

Identificação de stakeholders para a lanchonete (por que é importante e exemplos concretos).
  • O passo de identificação responde: quem usa o sistema, quem é afetado e quem toma decisões?
  • Stakeholders típicos (exemplos para a lanchonete):
    • Caixa / atendente: precisa registrar vendas rápido, receber pagamentos, emitir recibo.
    • Gerente/proprietário: precisa controlar estoque, ver relatórios de vendas, configurar preços e promoções.
    • Fornecedor: precisa receber pedidos de compra/compra automática.
    • Cliente: espera rapidez no atendimento e opções de pagamento.
    • Contador / financeiro: precisa de relatórios fiscais e integração com notas fiscais.
    • Suporte/TI e administrador do sistema: precisa gerenciar usuários, backup e atualizações.
  • Como ajuda o documento: cada requisito pode ser ligado a um stakeholder — assim ninguém “aparece” com uma exigência tarde demais.

Passo 4

Técnicas de elicitação (como descobrir requisitos reais) com exemplos práticos.
  • Entrevistas individuais: sentar com o caixa e pedir que descreva, passo a passo, como faz uma venda. Exemplo: perguntar “o que faz quando um cliente pede desconto?” — pode revelar necessidade de autorização do gerente.
  • Observação / shadowing: acompanhar o pico do almoço para ver gargalos (ex.: demora ao buscar item no cardápio digital). Isso revela requisitos de performance e usabilidade.
  • Workshops / JAD (reunião facilitada): reunir gerente, caixa e fornecedor para mapear fluxo de compra e venda. Resultado: consenso sobre etapas e prioridades.
  • Protótipo rápido (paper mockup): desenhar tela de checkout e validar com atendentes — alterações rápidas antes de codar.
  • Análise de documentos existentes: checar planilhas atuais de estoque e notas fiscais para entender dados necessários.
    Cada técnica traz requisitos que muitas vezes não aparecem em entrevistas isoladas.

Passo 5

Classificação: requisitos funcionais vs não funcionais (o que são e exemplos claros).
  • Requisito funcional (FR): descreve um comportamento do sistema — “o que o sistema deve fazer”.
    • Exemplo FR1: “O sistema deverá permitir registrar uma venda contendo um ou mais itens do cardápio, com quantidade e preço unitário.”
    • Exemplo FR2: “O sistema deverá decrementar automaticamente o estoque ao finalizar a venda.”
    • Exemplo FR3: “O sistema deverá gerar e imprimir recibo fiscal e cupom para cada venda.”
  • Requisito não funcional (NFR): qualidade do serviço, restrições e atributos medíveis — “como o sistema deve ser”.
    • Exemplo NFR1 (performance): “O sistema deverá processar e confirmar uma venda em no máximo 5 segundos sob carga normal.”
    • Exemplo NFR2 (segurança): “Os dados de cartão deverão ser transmitidos conforme padrão PCI-DSS e nunca armazenados em texto claro.”
    • Exemplo NFR3 (disponibilidade): “O sistema deverá ter disponibilidade mínima de 99% no horário de funcionamento da loja.”
  • Por que separar? Facilita testes: FR têm testes funcionais diretos; NFR têm critérios medidos (tempo, disponibilidade, entropia de senha etc).

Passo 6

Como escrever requisitos bons (regras práticas, com exemplos bons e ruins).
  • Regras: cada requisito deve ser único, atômico, mensurável/testável, sem ambiguidade, e não prescrever solução (quando possível).
  • Exemplo ruim: “A interface tem de ser bonita.” (vago, impossível de testar).
  • Exemplo bom: “A interface de vendas deverá permitir que o atendente complete uma venda com até 10 itens em no máximo 20 segundos, medidos a partir do primeiro item escaneado até a confirmação do pagamento.” (testável e mensurável).
  • Estrutura recomendada de um requisito no documento: ID, título, descrição, prioridade, critérios de aceitação, rastreabilidade (para qual use case / teste se refere), responsável.
  • Exemplo de requisito escrito no SRS:
    • ID: R-001
    • Título: Registrar venda presencial
    • Descrição: “O sistema deverá permitir cadastrar e finalizar vendas presenciais com itens do cardápio, calcular total, aplicar impostos e descontos autorizados.”
    • Prioridade: Must
    • Critérios de aceitação: “Ao finalizar, gera cupom, reduz estoque e cria registro de venda com data/hora e operador.”

Passo 7

Use cases e user stories (como documentar fluxos e porque ajudam) com exemplos passo a passo.
  • Use case (fluxo completo): útil para capturar cenários, fluxos alternativos e exceções.
    • Exemplo: Use case “Realizar venda” — ator: Caixa.
      • Fluxo básico:
        1. Caixa seleciona itens do cardápio ou escaneia códigos.
        2. Sistema calcula total e impostos.
        3. Cliente escolhe forma de pagamento (dinheiro/cartão).
        4. Sistema efetua pagamento e imprime cupom fiscal.
        5. Sistema decrementa estoque e registra venda.
      • Fluxos alternativos: pagamento com cartão negado; aplicação de desconto por gerente; cancelamento antes da finalização; devolução parcial.
  • User story (ágil): pequena, fácil de entender e com critérios de aceitação.
    • Exemplo: “Como caixa, quero registrar uma venda e escolher pagamento em cartão para que o cliente receba o comprovante e o estoque seja atualizado.”
    • Critérios de aceitação: lista de passos com resultados observáveis (ex.: “dado que os itens foram adicionados, quando eu selecionar pagamento cartão e a autorização for aprovada, então o sistema imprime o cupom e reduz o estoque”).
  • Por que isso ajuda? Use cases cobrem cenários reais e exceções, user stories tornam requisitos entregáveis em iterações curtas.

Passo 8

Critérios de aceitação e testabilidade (exemplos concretos).
  • Cada requisito deve ter critérios que permitam verificar se está implementado corretamente.
  • Exemplo de critérios para “Decrementar estoque”:
    • Pré-condição: produto X tem quantidade 10 em estoque.
    • Ação: registrar venda com 3 unidades do produto X.
    • Resultado esperado: novo estoque do produto X = 7; registro de venda com referência ao lote; log de alteração com usuário e timestamp.
  • Esses critérios viram casos de teste automatizados ou scripts de aceitação.

Passo 9

Requisitos não funcionais detalhados e métricas que ajudam a especificá-los (com exemplos aplicáveis).
  • Desempenho: “suporte a 40 vendas por hora sem latência acima de 5 segundos por transação.”
  • Escalabilidade: “capacidade de adicionar segunda filial com sincronização diária de produtos.”
  • Segurança: “autenticação com senha com ao menos 8 caracteres e logs de auditoria mantidos por 2 anos.”
  • Conformidade fiscal: “geração de arquivo para o sistema da prefeitura/SEFAZ conforme layout X.”
    Definir números evita interpretações subjetivas.

Passo 10

Prototipagem e wireframes para validar requisitos com usuários (prática e exemplo).
  • Fazer telas de baixa fidelidade (papel) para validar fluxo de vendas com o atendente. Ex.: testar se a posição dos botões torna o processo mais rápido.
  • Fazer protótipos de alta fidelidade para validar integração com impressora fiscal e modo offline.
  • Benefício: identifica requisitos ocultos (ex.: necessidade de modo offline quando a internet cair).

Passo 11

Priorização dos requisitos (técnicas e exemplo prático para a lanchonete).
  • Técnica MoSCoW (Must, Should, Could, Won’t): define o que é obrigatório para a entrega mínima.
    • Exemplos:
      • Must: registrar venda, aceitar dinheiro e cartão, emitir cupom fiscal, atualizar estoque.
      • Should: relatórios diários de vendas por produto.
      • Could: integração com aplicativo de delivery.
      • Won’t (nesta release): fidelidade por pontos.
  • Priorizar evita gastar tempo com funcionalidades de baixo valor antes do essencial.

Passo 12

Rastreabilidade de requisitos (por que é essencial) com um exemplo simples.
  • Rastreabilidade liga requisitos a use cases, casos de teste e entregas. Facilita impacto de mudanças e validação.
  • Exemplo textual de traço: R-001 (Registrar venda) -> Use Case UC-01 -> Teste T-01, T-02 -> Documento de design D-01.
  • Se R-001 muda (ex.: adicionar troca de cupom), o impacto nos testes e no design fica evidente.

Passo 13

Gerenciamento de mudanças e controle de versões (processo prático).
  • Estabelecer baseline (versão do SRS) e procedimento de solicitação de mudança (Change Request): descrição da mudança, motivo, impacto em custo/prazo e decisão de aprovação.
  • Exemplo: gerente pede “venda por delivery” no meio do projeto. Criar CR que avalia banco de dados, UI, integração com entregadores e custo. Se aprovado, atualizar SRS e roadmap.

Passo 14

Modelagem de dados e diagramas (o que incluir no documento e exemplo).
  • Documentar o modelo de dados mínimo: entidades e relacionamentos ajudam a definir requisitos de dados.
    • Exemplo textual de entidades: Produto(id, nome, preco, estoque, data_validade), Venda(id, data, operador, total), ItemVenda(venda_id, produto_id, quantidade, preco_unitario), Fornecedor(id, nome, prazo_entrega).
  • Diagrama ER e diagramas de casos de uso no SRS melhoram o entendimento entre desenvolvedores e stakeholders.

Passo 15

Validação do documento de requisitos (como provar que o SRS está correto).
  • Revisões em grupo com stakeholders, walkthroughs de use cases, testes de aceitação definidos e protótipos validados.
  • Exemplo de sessão de validação: simular uma venda com protótipo, testar cancelamento parcial, validar fluxo com caixa e gerente e anotar correções para atualizar o SRS.

Passo 16

Qualidade do SRS: checklist prático para garantir um bom documento (aplicável na prova também).
  • Cada requisito tem ID, versão, autor e data.
  • Requisitos são: testáveis, não ambíguos, priorizados, rastreáveis e com critérios de aceitação.
  • SRS contém: escopo, stakeholders, requisitos funcionais, requisitos não funcionais, use cases, data model, wireframes, plano de validação e plano de gerenciamento de mudanças.
  • Exemplo prático: antes de “assinar” o SRS, rodar checklist com o gerente e com 2 atendentes.

Passo 17

Exemplo de um requisito completo no formato sugerido (modelo prático que pode ser copiado para o SRS)
  • ID: R-010
  • Título: Venda presencial com cartão
  • Descrição: “O sistema deverá permitir que o atendente registre uma venda e processe pagamento por cartão através de integração com a máquina Cielo/Pay. Em caso de autorização positiva, deve gerar cupom fiscal e confirmar a venda; em caso negativo, deverá atualizar o usuário com motivo e permitir tentativa alternativa.”
  • Prioridade: Must
  • Critérios de aceitação:
    • Dado que a venda está montada, quando o atendente selecionar pagamento por cartão e a autorização for aprovada em até 5 segundos, então o sistema imprime cupom fiscal e reduz estoque.
    • Quando rejeitada, o sistema mostra motivo de rejeição e não altera o estoque.
  • Rastreabilidade: ligado ao use case UC-01 e teste de aceitação T-05.

Passo 18

Dicas práticas para aplicar isso na prova (resumindo como pensar a resposta do ponto de vista de engenharia de requisitos).
  • Primeiro identifique stakeholders e escreva 3 requisitos funcionais essenciais e 2 não funcionais mensuráveis.
  • Mostre uma técnica de elicitação (ex.: entrevista com caixa) e um artefato (use case ou user story).
  • Explique como priorizar (MoSCoW) e cite uma métrica de aceitação (tempo, disponibilidade ou número).
  • Por fim, destaque rastreabilidade e controle de mudanças — isso mostra maturidade do processo.

Resposta

A engenharia de requisitos auxilia criando um processo sistemático para descobrir, analisar, documentar, validar e gerenciar o que o sistema da lanchonete deve fazer e como deve se comportar; isso inclui identificar stakeholders (caixa, gerente, fornecedor, contador), usar técnicas (entrevistas, observação, protótipos), escrever requisitos claros e testáveis (FR e NFR) com critérios de aceitação, priorizá‑los (MoSCoW), modelar fluxos e dados (use cases, ER), garantir rastreabilidade e controlar mudanças — tudo isso reduz ambiguidade, evita retrabalho e facilita testes/entregas. Exemplos práticos: R-001 “Registrar venda” com critérios que descrevem fluxo básico e exceções; NFR de performance “venda confirmada em ≤5s”; uso de protótipo de tela de checkout para validar necessidade de modo offline.

Exercícios relacionados