4. Engenharia de Requisitos

4.1 Atividades e Técnicas de ER 📌

4.1.1 — Elicitação e Descoberta

Entrevista com Stakeholders: serão conduzidas entrevistas com o cliente da VB e seus colaboradores, a fim de compreender suas necessidades, expectativas e principais dificuldades relacionadas à prestação do serviço de lavagem automotiva. As informações obtidas servirão de base para a definição dos requisitos do sistema WaveON.
Brainstorming: será aplicado em reuniões internas da equipe de desenvolvimento, com o objetivo de estimular a geração de ideias de funcionalidades e soluções. Essa técnica permitirá explorar alternativas diversas e selecionar as mais adequadas às demandas da VB.

4.1.2 — Análise e consenso

User Story Mapping (USM) — método transversal: o USM é aplicado de forma contínua e transversal em todo o processo de ER, não apenas na análise e consenso. Ele organiza a jornada por objetivos, atividades, passos e histórias (US), orienta a priorização (MoSCoW + ICE) e dá origem ao Backlog do Produto e ao MVP.
Priorização MoSCoW: será empregada para classificar os requisitos em Must, Should, Could e Won’t, auxiliando na definição das funcionalidades que deverão ser implementadas nos primeiros protótipos e das que poderão ser postergadas.
Priorização ICE: também será utilizada para apoiar a priorização, atribuindo valores de impacto, confiança e facilidade de implementação a cada requisito. Esse método fornecerá objetividade e facilitará o consenso entre equipe e stakeholders.

4.1.3 — Declaração de Requisitos

User Story: os requisitos serão descritos no formato de histórias do usuário, por exemplo: “Eu, como cliente, quero poder pagar por pix adiantado o serviço.” Essa forma de documentação tornará a comunicação mais clara e centrada no valor para o usuário. As histórias são derivadas e organizadas pelo USM, garantindo rastreabilidade entre objetivos, atividades, passos e US.

4.1.4 — Representação de Requisitos:

Mapa Mental: será elaborado para representar visualmente os requisitos identificados, agrupando funcionalidades e relacionando-as aos objetivos do negócio. Essa técnica ajudará a manter uma visão global do sistema.
Mockups / Baixa fidelidade: protótipos iniciais para cliente e admin (ver evidências em Evidências de Execução).
Protótipos de Alta Fidelidade: referência publicada no Figma: https://www.figma.com/design/G5HVjXRLeve1BeBBazx2S8/WaveOn---UI-UX-Design?node-id=0-1&t=1De0YUykvUV4vG3U-1

Esses protótipos aproximam a experiência do usuário da versão final do sistema, possibilitando testes realistas e validação mais precisa junto ao cliente da VB.

As representações (mapa mental, mockups e protótipos) são orientadas pelo USM para preservar o fluxo da jornada e a priorização acordada.

4.1.5 — Verificação e Validação de Requisitos

Checklist de Validação e Verificação: será utilizado para revisar os requisitos documentados, garantindo consistência, completude e alinhamento com os objetivos do projeto..
Definition of Ready(DoR): será aplicada para garantir que um requisito tenha clareza e detalhamento suficientes antes de ser incluído em uma iteração de desenvolvimento.
Definition of Done(DoD): será estabelecida para definir critérios de aceitação de cada requisito, assegurando que cada incremento esteja implementado, testado e integrado antes de ser considerado concluído.
Revisão Informal ou Formal: revisões informais ocorrerão a cada ciclo de prototipação junto ao cliente, enquanto revisões formais serão realizadas em marcos de entrega, consolidando o alinhamento com a VB.
Feedback do Cliente: será coletado continuamente durante as validações dos protótipos e incrementos entregues, permitindo ajustes rápidos e validação constante dos requisitos.

A verificação e validação consideram as histórias mapeadas pelo USM e seus critérios de aceitação, assegurando que o fluxo de valor (objetivos→atividades→passos→US) esteja coberto e rastreado.

4.1.6 — Organização e Atualização de Requisitos

Backlog do Produto derivado do USM: o backlog é derivado diretamente do USM (mapa de objetivos→atividades→passos→US). Embora o RAD não tenha backlog nativo, adotamos o Backlog do Produto para organização dinâmica e rastreabilidade, mantendo alinhamento com o USM e com as priorizações MoSCoW/ICE.

4.2 Engenharia de Requisitos e o RAD 🏗️

Cada ciclo do RAD será composto pelas quatro fases principais: Planejamento de Requisitos, Design do Usuário, Construção e Transição/Implementação.
O processo se repetirá até que o sistema esteja completo, com entregas incrementais a cada ciclo. O Cronograma de Entregas estrutura a organização e quantidade de ciclos necessários para garantir a entrega do MVP.

Fases do Processo RAD	Atividades ER	Prática	Técnica	Resultado Esperado
Planejamento de Requisitos	Elicitação e Descoberta	Levantamento de requisitos	Entrevistas com Stakeholders, Brainstorming	Entendimento de problemas, identificação de funcionalidades e lista de necessidades
	Análise e Consenso	Priorização dos Requisitos	USM (método transversal; ver 4.1.2), Priorização MoSCoW, Priorização ICE	Escopo e funcionalidades essenciais definidos e priorizados pelo USM + critérios.
	Verificação e Validação	Validação de Requisitos	Checklist de Verificação e Validação, DoR	Confirmação de que requisito entrega valor
	Declaração	Registro dos requisitos	User Story	Histórias de usuário detalhando funcionalidades mapeadas no USM.
	Organização e Atualização	Organização dos requisitos implementados ou atrasados	Backlog do Produto (derivado do USM)	Backlog atualizado e rastreado ao USM
Design de Usuário	Representação de Requisitos	Prototipagem	Mapa Mental, Mockups, Protótipos de Alta Fidelidade	Ciclo iterativo de prototipagem, teste e refinamento.
	Verificação e Validação	Validação de Requisitos	Revisão Informal ou Formal, Feedback do Cliente	Revisão formal do Designer com os Desenvolvedores e validação de prototipagem com o cliente.
Construção	Verificação e Validação	Verificação de implementação	Critérios de aceitação, Revisão informal ou formal, DoD	Confirmação de que entrega atende requisito
Transição/Implementação	Verificação e Validação	Apresentação ao cliente dos incrementos desenvolvidos ao longo do Ciclo.	Feedback do Cliente.	Funcionalidades avaliadas com base no retorno dos clientes.
	Organização e Atualização	Organização dos itens de backlog (US/épicos) implementados ou replanejados	Backlog do Produto (derivado do USM)	Backlog atualizado e rastreado ao USM

Histórico de Versão 🔄

Data	Versão	Descrição	Autor(es)	Revisor(es)
26/11/2025	1.0	Correções de tópicos no documento	Bernardo Watanabe	Anna Brandão