Ir para o conteúdo

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.