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.
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:
- Caixa seleciona itens do cardápio ou escaneia códigos.
- Sistema calcula total e impostos.
- Cliente escolhe forma de pagamento (dinheiro/cartão).
- Sistema efetua pagamento e imprime cupom fiscal.
- 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.
- Fluxo básico:
- Exemplo: Use case “Realizar venda” — ator: Caixa.
- 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.
- Exemplos:
- 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.