4 Engenharia de Requisitos

Engenharia de Requisitos é o processo de identificar, analisar, documentar e gerenciar os requisitos de um sistema. Seu objetivo é garantir que as necessidades e expectativas dos stakeholders (como clientes e usuários) sejam corretamente compreendidas e transformadas em especificações claras para o desenvolvimento do software, com base em técnicas e práticas.

Técnicas são métodos ou abordagens usadas para coletar, analisar e validar os requisitos. Exemplos incluem entrevistas, análise de personas, criação de cenários, entre outros. Essas técnicas ajudam a entender o que precisa ser desenvolvido.

Práticas são as atividades ou ações específicas que são realizadas durante o processo de engenharia de requisitos, como reuniões de planejamento, revisão de documentos ou validação com stakeholders. Elas são o que a equipe faz para aplicar as técnicas e atingir os objetivos de engenharia de requisitos.

4.1 Atividades e Técnicas de ER

Planejamento da Release

Elicitação e descoberta:
- Entrevistas: As entrevistas com os clientes da empresa Auto Rei Tintas terão como objetivo compreender de forma mais aprofundada as necessidades do cliente, oferecendo uma visão detalhada para o desenvolvimento do projeto. Esse processo permitirá entender as dificuldades enfrentadas pelos clientes, identificar as funcionalidades essenciais para atender suas demandas e explorar como um catálogo online pode facilitar o acesso às informações e produtos de maneira eficiente. Além disso, será possível avaliar a importância de um canal de contato direto e prático com o vendedor, permitindo ao cliente discutir e negociar condições de compra de forma ágil e conveniente, sem a necessidade de deslocamento físico.
- Brainstorming: O brainstorming com os stakeholders visa gerar diversas ideias e soluções para os desafios enfrentados pelos clientes, ampliando as possibilidades de funcionalidades e melhorias para o negócio. Esse processo colaborativo contribui para identificar oportunidades, inovar e criar soluções mais alinhadas às necessidades do cliente e aos objetivos da empresa.
Declaração:
- Registro dos requisitos: serão demonstrados ao cliente os requisitos separadas para aquele lançamento em questão, e registrados.
Análise e consenso:
- Análise de Custo / Benefício: Por meio de uma reunião com o stakeholder da AutoRei Tintas, verificaremos a viabilidade de implementar cada requisito considerando os recursos disponíveis atualmente levando em consideração as tecnologias já implementadas na loja.
- Análise de Objetivos de Domínio: Alinhar com a equipe de desenvolvimento e o cliente os requisitos às necessidades e restrições do domínio de aplicação do sistema.
- Negociação: Uma troca de opiniões entre a equipe e o stakeholder da AutoRei Tintas para resolver conflitos ou diferenças em relação aos requisitos e a viabilidade dos mesmos.
- Resolução de conflito: Parte do processo de negociação, mas com foco específico em lidar com desacordos ou incompatibilidades, já existentes ou que podem vir a surgir, entre os interesses das partes envolvidas.
Verificação e Validação:
- Confirmação de requisitos: Conferir se os requisitos foram bem definidos e implementáveis.
Organização e atualização:
- MoSCoW: (Must Have, Should Have, Could Have, Won't Have), as histórias de usuário são priorizadas de acordo com sua relevância e impacto no MVP com base na avaliação, de cada funcionalidade, feita pelos integrantes.

Planejamento da Sprint

Análise e consenso:
- Análise de Personas: Com a análise das personas criadas, será utilizada pra entender melhor os usuários e a finalidade da aplicação.
- Histórias: As histórias de usuário serão utilizadas para desenvolver as funcionalidades da aplicação, e puxar do backlog para sprint.
- Cenário: De acordo com o cenário, compreender as prioridades da aplicação.
Verificação e Validação:
- Checklist de Validação: Criar os critérios de aceitação junto ao cliente, para melhor desenvolvimento.
Organização e atualização
- User Story Mapping: Utilizar histórias de usuários para criar e organizar o backlog

Execução da Sprint

Representação:
- Prototipagem: As prototipagens serão utilizadas a fim de demonstrar ao cliente as funcionalidades e entender se estão de acordo com o desejado.
Verificação e Validação:
- Revisão de requisitos: A revisão dos requisitos ocorrerá concomitantemente com a atividade de representação de modo a registrar e alterar as mudanças necessárias para o projeto vindas do cliente e da equipe em si.
Organização e atualização:
- Revisão do backlog: Durante a execução da sprint, o backlog será constantemente atualizado de modo a identificar quais tarefas estão em andamento, finalizadas ou ainda presentes no backlog.

Sprint Review

Verificação e atualização:
- Qualidade de requisitos: A qualidade dos requisitos será garantida através de um roteiro de validação e um roteiro de verificação.
Declaração:
- Incorporar Feedback, Negociação: Incorporar o feedback recebido na revisão da sprint permite ajustar as user stories conforme necessário, enquanto a negociação ajuda a decidir quais ajustes são prioritários, respeitando o escopo e as limitações do projeto.

Retrospectiva

Nenhuma atividade de requisitos foi identificada na retrospectiva. Contudo, outros tipos atividades fazem parte desse processo, como:

Análise e organização
- Discussões em grupo: Serão importantes a fim de organizar não só elementos do projeto como a equipe em si, nos preparando para as próximas sprints
- análise de causas: identificação de problemas ou questões que dificultaram o andamento do projeto e entrosamento da equipe.
Atualização do Processo
- Atualização do Workflow: atualização de elementos organizacionais os quais regem o andamento do trabalho que está sendo feito pela equipe.

4.2 Engenharia de Requisitos e o ScrumXP

Fase do ScrumXP	Atividades ER	Prática	Técnica	Resultado Esperado
Planejamento da Release	Elicitação e Descoberta	Levantamento de Requisitos	Entrevistas, Brainstorming, Análise de Domínio de Negócio	Requisitos de alto nível identificados e Objetivos da release bem definidos
	Declaração	Registro dos Requisitos	Temas, Épicos e User Stories	Histórias de usuário documentadas que descrevem os requisitos da versão de maneira clara e objetiva
	Análise e consenso	Priorização dos Requisitos	User Story Mapping	histórias de usuário priorizadas
	Verificação e Validação	Verificar e validar os requisitos levantados	Definition of Done (DoD) e Definition of Ready (DoR)	Definições de Ready e Done das histórias de usuário no geral da release
	Organização e atualização	Elencar os requisitos levantados de acordo com os critérios de prioridade	MoSCoW, User Story	Lista de requisitos organizada com o grau de prioridade
Planejamento da Sprint	Análise e consenso	Reunião de Planejamento	Análise de Personas, Histórias e Cenários	Lista de Personas, Histórias priorizadas
	Verificação e Validação	Entrevistas com Stakeholders, Revisão de documento	Checklist de Validação, Entrevista	Resultados do Checklist, Critérios de aceitação definidos
	Organização e atualização	Organização e priorização de requisitos	User Story Mapping	backlog organizado
Execução da Sprint	representação	Prototipação (criação de uma representação visual)	Protótipo com uso de frameworks como figma	Uma visualização que oriente a equipe de desenvolvimento na implementação
	Verificação e Validação	Validar requisitos	Revisar os requisitos com base nos critérios de aceitação	Garantir que requisitos estão de acordo com os critérios de aceitação e qualidade
	Organização e Atualização	Revisão do Backlog	Revisão do Backlog da Sprint	Backlog atualizado e alinhado com os objetivos da sprint em andamento
Sprint Review	Verificação e atualização	serão verificados e validados os requisitos	Roteiro de Validação, Roteiro de Verificação	qualidade de requisitos
	Declaração	Atualização de User Stories	Incorporar Feedback, Negociação	User stories ajustadas conforme feedback recebido durante a revisão da sprint
Retrospectiva	Análise e organização	Revisão do processo	Discussões em grupo, análise de causas	Melhorias identificadas e aplicáveis ao processo de engenharia de requisitos

Histórico de Versões

Versão	Data	Descrição	Autor(es)	Revisor(es)
`1.0`	26/11/2024	Criação do Documento	Paulo Henrique	Johan, Paulo Henrique, Mariana Letícia, Mateus Cavalcante e Diogo
`1.1`	16/12/2024	Atualizando e corrigindo tabela 4.2	Mariana Letícia e Mateus Cavalcante	Johan, Paulo Henrique, Mariana Letícia, Mateus Cavalcante e Diogo