Engenharia de Requisitos no Projeto
Apesar de sabermos que o processo de engenheria de requisitos (ER) é flexível, de modo que alguns processos começam antes de outros sem necessariamente seguir um ordem linear. O nosso processo de ER se constitui de maneira linear e essa construção nos possibilitou o retorno do backlog do MVP1 e MVP2 da forma mais concisa possível.
Na fase de Elicitação e Descoberta foram utilizadas as seguintes técnicas:
-
Análise de Problemas (Diagrama de causa e efeito, 5 porquês): Aqui conseguimos levantar os possíveis problemas que seriam solucionados pelo projeto.
-
Análise de Concorrente: Aqui descobrimos que o projeto não possui um concorrente direto, pois estamos cobrindo lacunas das soluções já existes. Além disso, descobrimos o que falta nos apps de organização da atualidade no que tange o planejamento e a organização viagens.
-
Brainstorming: Nessa fase do processo de Elicitação fizemos uma reunião de Brainstorming e levantamos uma lista de requisitos que poderiam ser desenvolvidos no decorrer da disciplina.
-
Prompt IA: Este foi uma Metodologia Inovadora do processo da ER fizemos solicitações e perguntamos ao ChatGPT da OpenIA de modo que ele gerasse outputs(saídas) de forma a gerar mais requisitos que, por ventura, passaram despercebidos no processo de debates e Brainstorming. Além de possíveis cadegorizações, em temas e épicos listando suas possíves user(s) stories.
Na fase de Análise e Consenso foram utilizadas as seguintes técnicas:
-
Negociação: A equipe conversou com o cliente com relação a primeira lista (feita na fase de elicitação - rascunho) levando a chegar em uma outra lista mais concisa e filtrada se tratando de seu valor para o negócio.
-
Análise de Risco: Analisamos os riscos da possiblidade de alguns requisitos não serem desenvolvido à tempo e eventuais clomplexidades que poderiam ser impecilho no desenvolvimento destes requisitos.
-
Análise de Viabilidade: Foi feito uma lista ordenada, na qual os primeiros elementos seriam os considerados pelos membros da equipe os que seriam mais viável para serem desenvolvidos no período da disciplina e os ultimos elementos os menos viáveis. Além disso, foi feito uma primeira categorização de possíveis temas por cores.
Na fase de Declaração foram utilizadas as seguintes técnicas:
-
Temas: Os temas são um conjunto de vários Épicos diferentes.
-
Épicos: As User Stories foram separadas em Épicos para uma maior rastreabilidade.
-
User Stories: Nossos requisitos foram estruturados como User Stories, seguindo este padrão:
- Eu, como QUEM SOU EU, desejo QUAL O REQUISITO, para QUAL O VALOR DE NEGÓCIO DO REQUISITO
Na fase de Verificação e Validação foram utilizadas as seguintes técnicas:
-
Feedback:
-
Verificação: Recebemos o feedback da verificação de nossos requisitos através do professor George Marsicano. Devido à isso, retiramos um requisito e fizemos leves alterações em outros.
- Validação: Recebemos o feedback da validação de nossos requisitos através do nosso cliente. Foi feita uma reunião na qual ele validou os requisitos decididos e o escopo do projeto.
Na fase de Organização e Atualização foram utilizadas as seguintes técnicas:
-
Pontos por história: Para decidirmos quais requisitos entrariam no MVP1 e quais entrariam no MVP2, atribuímos uma pontuação para cada requisito. Os requisitos foram avaliados em:
-
Valor de Negócio : Pontuação varia de 1 à 10;
- Viabilidade : Pontuação varia de 1 à 5;
- Complexidade : Pontuação varia de 5 à 1;
Totalizando então um máximo de 20 pontos para cada requisito.
-
MoSCoW (Must Have, Should Have, Could Have, Won't Have): A partir da pontuação obtida por cada requisito, alocamos eles em suas devidas categorias do MoSCoW de acordo com estes critérios:
-
Must Have: Requisitos com pontuação maior que 15, ou aqueles com pontuação igual à 15 e valor de negócio igual à 10.
- Should Have: Requisitos com pontuação igual à 15 e valor de negócio menor que 10, ou aqueles com pontuação igual à 14.
- Could Have: Requisitos com pontuação menor que 14.
- Won't Have: Não teve requisitos nesta categoria.
Tabela de pontuação dos requisitos
Com base nisto definimos o MVP1 como os requisitos presentes na categoria Must Have e o MVP2 como os requisitos presentes nas categorias Should Have e Could Have.