Engenharia de Requisitos

5. Engenharia de Requisitos

5.1 Atividades e Técnicas de ER

Elicitação e descoberta

Entrevistas semiestruturadas: encontros periódicos com a cliente para compreender o jogo físico, seus princípios pedagógicos, o corpus de morfemas e as expectativas em relação à versão digital, identificando tanto requisitos declarados quanto requisitos latentes.
Análise documental: estudo do relatório final do projeto original, do material didático e das peças físicas do jogo, para reconstruir o vocabulário pedagógico e a identidade visual do MorfoBlocos.
Observação do contexto real de uso: acompanhamento da aplicação do jogo físico em sala de aula, quando possível, para capturar requisitos latentes que emergem do uso real e dificilmente apareceriam em entrevistas.
Triangulação de fontes de informação: cruzamento sistemático entre entrevistas, análise documental e observação, de modo a confrontar percepções e consolidar um entendimento compartilhado sobre o problema e suas causas.

Análise e Consenso

Workshops de Requisitos: encontros colaborativos com a cliente para discutir escopo, resolver divergências de interpretação e construir entendimento compartilhado sobre aspectos pedagógicos e de conteúdo.
Priorização MoSCoW: classificação das funcionalidades em Must have, Should have, Could have e Won't have for now, junto à cliente, para definir o escopo do MVP e registrar desejáveis para evolução futura.
Matriz Avaliação Técnica × Valor de Negócio: posicionamento das características de produto em uma matriz que cruza valor percebido pela cliente com esforço técnico estimado, orientando a sequência de entregas.
Negociação e resolução de conflitos: mediação estruturada de divergências entre requisitos — por exemplo, entre fidelidade ao jogo físico e viabilidade no prazo do semestre — com registro das decisões e suas justificativas. Declaração de Requisitos

Declaração de Requisitos

Narrativas descritivas: usadas para declarar requisitos de negócio em linguagem natural, articulando o problema identificado na seção 1.4, o valor esperado para a cliente e as restrições do contexto do projeto.
Histórias de usuário: declaração dos requisitos de usuário no formato "Como , quero , para ", organizadas em backlog de produto e utilizadas no planejamento das sprints.
Critérios de aceitação Given/When/Then: cada história de usuário será acompanhada por critérios de aceitação em formato estruturado, explicitando condição inicial, ação e resultado esperado de forma verificável.
Catálogos de RFs e RNFs: os requisitos funcionais serão declarados no padrão "verbo no infinitivo + objeto" (por exemplo, "Combinar morfemas para formar palavras"); os requisitos não funcionais serão organizados segundo o modelo URPS+, conforme orientação do template da disciplina.
Catálogo de regras de negócio: as regras morfológicas do português — quais combinações de morfemas são válidas e a qual processo de formação cada resultado corresponde — serão declaradas em catálogo próprio, distinto dos requisitos funcionais, conforme a definição de regra de negócio adotada pelo livro-texto.

Representação de Requisitos

Rich Picture no formato AS-IS / TO-BE: representação sistêmica (contextual) utilizada na seção 1.3 para contrastar o cenário atual do jogo físico com o cenário proposto para a solução digital, capturando atores, fluxos e limitações do contexto.
Diagrama de Ishikawa (6M's): utilizado na seção 1.4 para organizar a análise das causas do problema identificado, distribuindo os fatores contribuintes pelos eixos Método, Máquina, Mão de Obra, Material, Medida e Meio Ambiente.
Mapa de Stakeholders e Matriz Poder × Interesse: representações sistêmicas (contextuais) utilizadas na seção 1.6 para classificar os stakeholders conforme sua influência e interesse, orientando a estratégia de comunicação da equipe ao longo do projeto.
Protótipos de baixa fidelidade e storyboards: produzidos durante as sprints para apoiar a validação de fluxos de uso com a cliente antes da implementação, mantendo-se no escopo da ER conforme a delimitação do SWEBOK v4.0.
Fluxos de navegação e de estados conceituais: usados em nível conceitual para representar caminhos de uso do estudante (por exemplo, da seleção de morfemas ao recebimento de feedback), sem detalhar elementos de interface ou lógica interna.

Verificação e Validação de Requisitos

Revisão interna pela equipe: antes de cada sprint, os requisitos refinados serão revisados pelos membros da equipe para verificar clareza, consistência, completude e testabilidade.
Validação com a cliente ao final de cada sprint: nas reuniões de revisão de sprint, a cliente avaliará o incremento entregue, confirmando que os requisitos implementados atendem a suas expectativas pedagógicas e ao problema declarado na seção 1.4.
Definition of Ready (DoR) e Definition of Done (DoD): o DoR define as condições mínimas para um item entrar em sprint; o DoD define as condições para considerá-lo concluído. Atuam como filtros de qualidade antes e depois do desenvolvimento.
Testes de aceitação baseados em critérios declarados: cada história de usuário será testada contra seus critérios de aceitação no formato Given/When/Then, tornando a validação objetiva e rastreável.

Organização e Atualização de Requisitos

Product Backlog único: histórias de usuário, RFs, RNFs e regras de negócio serão mantidos em um backlog único, priorizado pela Product Owner (a cliente) e continuamente refinado.
Refinamento contínuo do backlog: ao longo de cada sprint, equipe e cliente revisarão o backlog, atualizando prioridades, detalhando itens para as próximas sprints e ajustando o escopo conforme o aprendizado adquirido.
Aplicação do princípio DEEP: o backlog será mantido Detalhado adequadamente, Estimado, Emergente e Priorizado, conforme prática consolidada no desenvolvimento ágil.
Controle de versões dos artefatos de requisitos: a visão do produto, o backlog e os demais artefatos serão mantidos em repositório versionado, preservando histórico de decisões e rastreabilidade de mudanças.
Matriz de rastreabilidade: matriz que conecta objetivos específicos, características de produto, requisitos funcionais e não funcionais, regras de negócio e critérios de aceitação, assegurando que cada decisão técnica permaneça ligada ao problema declarado na seção 1.4.

5.2 Engenharia de Requisitos e o XP

As atividades da Engenharia de Requisitos, suas práticas e técnicas são mapeadas, a seguir, às cerimônias do Scrum adotadas pela equipe para a condução do projeto MorfoBlocos Digital. Embora o processo escolhido seja o ScrumXP — combinando o framework Scrum para gerenciamento com as práticas técnicas do XP para engenharia —, optou-se por organizar a tabela em torno das cerimônias do Scrum por serem os momentos formais de tomada de decisão e validação no ciclo iterativo, conforme descrito na seção 4.10 do livro-texto.

Importante: as atividades da ER não ocorrem de forma estritamente sequencial dentro de cada cerimônia. Conforme apresentado no capítulo 5 do livro-texto, elas são entrelaçadas e se retroalimentam ao longo do projeto, de modo que a ordem das linhas da tabela é apenas de apresentação — não de execução obrigatória.

Cerimônia do Scrum	Atividade ER	Prática	Técnica	Resultado esperado
Refinamento do Product Backlog	Elicitação e Descoberta	Levantamento contínuo de requisitos e compreensão do domínio.	Entrevistas semiestruturadas com a cliente, análise documental do jogo físico, triangulação de fontes.	Itens do backlog detalhados e compreensão compartilhada do problema com a cliente.
	Análise e Consenso	Priorização contínua e definição de escopo dos próximos itens.	Priorização MoSCoW, Matriz Avaliação Técnica x Valor de Negócio, workshops com a cliente.	Backlog priorizado, com trade-offs explicitados e funcionalidades críticas no topo.
	Declaração	Detalhamento dos itens do backlog em diferentes níveis de abstração.	Histórias de usuário, critérios de aceitação Given/When/Then, catálogos de RFs, RNFs e regras de negócio.	Itens do backlog declarados em linguagem compreensível, rastreáveis ao problema da seção 1.4.
	Representação	Representação sistêmica do contexto e do problema.	Rich Picture AS-IS/TO-BE, Mapa de Stakeholders, Matriz Poder x Interesse, Diagrama de Ishikawa.	Entendimento compartilhado sobre o contexto, os atores e o escopo do sistema.
Planejamento da Sprint	Análise e Consenso	Análise de viabilidade e seleção dos itens da sprint.	Discussão em equipe, análise de dependências, programação em pares (XP).	Consenso sobre a meta da sprint e os itens selecionados para o Sprint Backlog.
	Declaração	Refinamento final dos critérios de aceitação dos itens selecionados.	Definition of Ready (DoR), critérios Given/When/Then.	Histórias de usuário com critérios verificáveis e prontas para desenvolvimento (Ready).
	Representação	Evolução de protótipos para apoiar a implementação.	Protótipos de baixa e média fidelidade, fluxos de navegação conceituais.	Representações que orientam a implementação e antecipam validações com a cliente.
Daily Scrum	Elicitação e Descoberta	Esclarecimento pontual de dúvidas sobre requisitos em desenvolvimento.	Conversas curtas com a cliente quando necessário, registro de impedimentos relacionados a requisitos.	Impedimentos de ER identificados e tratados com agilidade durante a sprint.
	Organização e Atualização	Atualização incremental do estado dos itens em desenvolvimento.	Sincronização sobre progresso, registro de descobertas que impactam o backlog.	Visibilidade contínua do estado dos itens da sprint frente aos requisitos declarados.
Revisão da Sprint	Verificação e Validação	Validação do incremento entregue com a cliente.	Demonstração do incremento funcional, revisão contra critérios de aceitação, Definition of Done (DoD).	Incremento validado pela cliente, com feedback registrado para ajuste de itens futuros.
	Organização e Atualização	Repriorização do backlog com base no aprendizado da sprint.	Refinamento do backlog, negociação colaborativa, princípio DEEP.	Product Backlog repriorizado e atualizado com itens de maior valor para a próxima sprint.
Retrospectiva da Sprint	Organização e Atualização	Reflexão sobre o processo de ER e ajuste de práticas.	Discussão estruturada da equipe sobre como os requisitos foram tratados, identificação de melhorias.	Ajustes nas práticas e técnicas de ER para a próxima sprint, artefatos consistentes e rastreáveis.
	Verificação e Validação	Verificação da qualidade dos artefatos de requisitos produzidos.	Revisão interna pela equipe dos artefatos da sprint, controle de versões.	Artefatos de requisitos verificados e versionados ao final de cada sprint.

O mapeamento apresentado evidencia onde cada atividade da ER tem maior ênfase em cada cerimônia do Scrum, sem sugerir uma ordem rígida de execução. As práticas técnicas do XP — como programação em pares, TDD, integração contínua e refatoração — permeiam a execução da sprint e dão suporte à qualidade dos requisitos implementados, em coerência com os valores de comunicação, feedback, simplicidade e confiança que sustentam a prática da Engenharia de Requisitos descrita no capítulo 5 do livro-texto.