Visão do Produto e do Projeto

1. Visão do Produto

1.1. Declaração de Posição

O Venci na Promo é um site focado em diminuir o desperdício de alimentos e produtos em razão da falta de visibilidade dos mesmos quando estão perto do vencimento. Para isso, um estabelecimento comercial em Brasília irá fornecer incentivos (pontos ou cupom de desconto) para esta compra.

De acordo com dados do IBGE, cerca de 30% dos alimentos produzidos no país acabam sendo jogados fora, o equivalente a cerca de 46 milhões de toneladas de alimentos por ano. Por isso, buscamos despertar nas pessoas uma mentalidade e comportamento mais humanos, responsáveis e empáticos, usando o voluntariado como grande ferramenta de transformação.

Na Tabela 1, apresentamos um quadro geral que resume o posicionamento do produto.

Fator	Descrição
Para	Pessoas que desejam comprar produtos em conta e estabelecimentos que desejam evitar o desperdício dos seus produtos
Quem	Deseja diminuir o desperdício e garantir um mundo mais sustentável
O Venci na Promo	É um site de compra e venda de produtos perto do vencimento
Que	Contém um estabelecimento que rapidamente está divulgando seus produtos e o horário de entrega
Ao contrário de	Outros sites e-commerces que não disponibilizam a data de validade dos produtos
Nosso produto	Irá englobar um estabelecimento que deseja evitar o desperdício de produtos por conta da data de validade fornecendo promoções que incentivam clientes a comprar produtos

Tabela 1: Posicionamento do produto. Fonte: Grupo GPT, 2023.

1.2. Objetivo do Produto

O objetivo principal do Venci na Promo pode ser descrito como:

Fornecer uma ferramenta que auxilie na resolução do problema do desperdício de alimentos próximos ao prazo de validade.

Resumidamente, pretende-se atingir este objetivo através da disponibilização de um sistema que faça a ponte entre estabelecimentos comerciais e seus clientes, divulgando promoções sobre esses produtos, fornecendo meios de compra e/ou distribuição de cupons de desconto e facilitando a organização da logística destas transações.

1.3. Tecnologias utilizadas

React

React é uma biblioteca JavaScript de código-aberto para construção de interfaces de usuário.

Node.js

Node.js é um ambiente de tempo de execução JavaScript de código aberto e multiplataforma.

MongoDB

MongoDB é um sistema gerenciador de banco de dados relacional. A princípio, a equipe utilizava o MySQL, porém tomou-se a decisão de migrar do MySQL para o MongoDB, uma mudança estratégica que visa aprimorar o desempenho, a escalabilidade e a flexibilidade de nosso projeto.

Docker

Docker é uma plataforma de código aberto para criação e administração de ambientes isolados.

O Docker Compose é uma ferramenta para definir e executar aplicativos Docker de vários contêineres.

Jest

O Jest é um framework de teste de JavaScript de código aberto, amplamente utilizado e conhecido por sua simplicidade e eficiência na execução de testes em projetos JavaScript.

2. Visão Geral do Projeto

2.1. Organização do Projeto

Na Tabela 2, apresentamos quais papéis e pessoas responsáveis pelos mesmos compõem a equipe.

Perfil	Atribuições	Responsável	Participantes
Scrum Master	Garantir que o time se oriente pelos valores e práticas do Scrum	Sabrina	Cainã, Charles, Gabrielly e Lucas
Product Owner	Atualizar o escopo do produto, organizar o escopo das sprints, validar as entregas	Sabrina	Sabrina
Desenvolvedor	Codificar o produto e realizar testes	Gabrielly	Cainã, Charles, Lucas e Sabrina
Analista de Qualidade	Garantir a qualidade do produto, garantir o cumprimento do conceito de pronto, realizar inspeções de código	Charles	Charles e Sabrina
Cliente	Fornecer as informações necessárias para construção do backlog e validar as entregas	Daniel	Daniel

Tabela 2: Papéis. Fonte: Grupo GPT, 2023.

2.2. Planejamento das Fases e/ou Iterações do Projeto

Abaixo, na Tabela 3, apresentamos como está planejado o desenvolvimento do projeto, dividindo as tarefas entre as sprints.

Sprint	Entrega	Data de início	Data de fim
Sprint 0	Definição do problema e solução	04/04/2023	10/04/2023
Sprint 1	Definição do produto, projeto e tecnologias	11/04/2023	17/04/2023
Sprint 2	Metodologia, processos, procedimentos e alinhamento do produto	18/04/2023	24/04/2023
Sprint 3	Visão do Produto e Projeto	25/04/2023	01/05/2023
Sprint 4	Definição do Backlog do Produto	02/05/2023	08/05/2023
Sprint 5	Validação do Backlog do Produto e Definição do MVP	09/05/2023	15/05/2023
Sprint 6	Protótipo de alta fidelidade	16/05/2023	22/05/2023
Sprint 7	US03 e US04	23/05/2023	29/05/2023
Sprint 8	US01, US02	30/05/2023	13/06/2023
Sprint 9	US06, US13, US15, US16, US05, US08 e Validação do MVP 1	14/06/2023	27/06/2023
Sprint 10	US09, US10	20/06/2023	27/06/2023
Sprint 11	US11, US14	28/06/2023	03/07/2023
Sprint 12	US06, US07, US09, US10, US12	04/07/2023	10/07/2023
Sprint 13	US09	11/07/2023	17/07/2023
Sprint 14	Validação do MVP 2	11/07/2023	17/07/2023

Tabela 3: Planejamento das fases do projeto. Fonte: Grupo GPT, 2023.

2.3. Matriz de Comunicação

O WhatsApp e o Discord serão as principais formas de comunicação utilizadas pela equipe. A seguir, na Tabela 4, apresentamos o quadro da matriz de comunicação definida pela equipe.

Descrição	Envolvidos	Periodicidade	Produtos Gerados
Planejamento das atividades	Equipe do Projeto	Semanalmente	Planejamento do que será feito no ciclo da Sprint
Acompanhamento das atividades	Equipe do Projeto	Diariamente	Relato por parte dos membros da equipe no discord sobre o andamento individual das partes do projeto
Encontros com o cliente	Equipe do Projeto e cliente	Quinzenal	Validação do Produto
Retrospectiva	Equipe do Projeto	Semanalmente	Identificação de oportunidades de melhoria
Comunicar situação do projeto	Equipe do Projeto, monitora e professor	Pontos de Controle	Apresentação dos resultados gerados

Tabela 4: Matriz de Comunicação. Fonte: Grupo GPT, 2023.

2.4. Gerenciamento de Riscos

O gerenciamento de riscos refere-se ao planejamento de como a equipe lidará com questões que podem ameaçar o desenvolvimento esperado do projeto. É feito através da identificação de fatores de risco potenciais, do planejamento de como lidar com estes fatores caso venham a acontecer e também do monitoramento dos mesmos ao longo da duração do projeto. É um processo que ocorre durante todo o ciclo de vida do projeto, e novos fatores de risco podem ser adicionados à medida que sejam identificados.

Abandono do projeto: A equipe pode tomar medidas para minimizar as chances de abandono do projeto, como a realocação de responsabilidades e a diminuição no escopo.
Abandono da disciplina por parte dos integrantes: É importante garantir que haja uma comunicação clara e aberta entre a equipe e que as expectativas sejam estabelecidas e comunicadas claramente. Isso pode ajudar a minimizar o abandono da disciplina, pois os membros da equipe entenderão as expectativas esperadas para o projeto.
Adição de membros à equipe do projeto: Quando novos membros são adicionados à equipe, a dinâmica do projeto pode mudar, e a equipe deve se adaptar a essas mudanças para garantir que o trabalho continue fluindo sem problemas.
Afastamento das atividades por motivos de saúde ou pessoais: Em casos de afastamento por motivos pessoais, é importante garantir que a equipe tenha tempo suficiente para se preparar e ajustar às mudanças na equipe. A transição adequada pode ajudar a garantir que o trabalho continue sem problemas e que a qualidade do trabalho não seja comprometida.
Alteração de escopo: A falta de compreensão do cliente sobre o que é possível realizar no projeto, mudanças nas necessidades do cliente ou imprevistos que surgem durante a execução do projeto.
Comunicação Ineficiente entre stakeholders: A falta de comunicação clara e efetiva entre os stakeholders pode levar a perda ou má interpretação de informações importantes. Isso pode causar atrasos e custos adicionais no projeto.
Comunicação ineficiente entre os integrantes da equipe: Quando a comunicação não é efetiva, a equipe pode ter dificuldades em colaborar, alcançar seus objetivos e atender às expectativas do cliente.
Sobrecarga de trabalho de membros da equipe: é importante que o gerente do projeto defina claramente as responsabilidades de cada membro da equipe. Isso ajuda a evitar situações em que uma pessoa é sobrecarregada com tarefas que não são de sua responsabilidade.

2.5. Critérios de Replanejamento

São condições que podem ocorrer durante o projeto que exijam uma revisão e adaptação do planejamento original. Deve ser feito o acompanhamento desses critérios a cada sprint, garantindo a qualidade do projeto até sua finalização.

Alteração nos requisitos: Pode ser que ao longo do projeto surjam novas necessidades, diante disso, é importante que a equipe esteja preparada para lidar com essas alterações, avaliando seus impactos e definindo um plano adequado.
Riscos não previstos: Mesmo com um planejamento bem feito, sempre existe a possibilidade de que riscos não previstos ocorram durante o projeto. A equipe deve estar preparada para identificar esses riscos e definir um plano de ação para amenizá-los.
Alterações não previstas: Pode ser que haja mudanças no ambiente externo que possam impactar o desenvolvimento do projeto, como uma mudança de legislação, por exemplo, diante disso é importante que o projeto esteja estruturado de forma flexível para se adaptar a essas mudanças.
Atrasos: É importante que o planejamento do projeto seja realista e que a equipe trabalhe dentro dos prazo e metas estabelecidos, trabalhando de forma colaborativa visando maximizar a produtividade.

3. Metodologia

3.1. Abordagem de desenvolvimento de software

Para Sommerville (2018), a escolha da abordagem de desenvolvimento de software pode ser facilitada através do esforço de responder uma série de perguntas sobre o sistema, o time de desenvolvimento e os stakeholders envolvidos, abarcando assim questões técnicas, humanas e organizacionais. A Figura 1 ilustra os pontos abordados pelas perguntas do método de Sommerville (2018). Listamos abaixo as perguntas propostas pelo método e as respostas para cada categoria.

Figura 1: Fatores que influenciam a escolha do desenvolvimento dirigido por plano ou ágil. Fonte: Sommerville, 2018.

Questões Técnicas

Qual é o tamanho do sistema que está sendo desenvolvido? É um software de pequeno porte.
Que tipo de sistema está sendo desenvolvido? Uma aplicação Web de complexidade de pequena a média.
Qual é a vida útil prevista para o sistema? A princípio, vida útil de curta a média duração.
O sistema está sujeito a controle externo? Sim, pelo cliente e pelo acompanhamento da disciplina.

Questões Humanas

Qual é o nível de competência dos projetistas e programadores do time de desenvolvimento? O time é multidisciplinar, com pessoas tendo experiência e sendo competentes em áreas diversas do desenvolvimento de projetos de software.
Como está organizado o time de desenvolvimento? O time é pequeno, e apesar de terem papéis definidos, todos devem participar da maioria das atividades.
Quais são as tecnologias disponíveis para apoiar o desenvolvimento do sistema? Há um bom escopo ferramental e tecnológico, descrito no tópico 1.3.

Questões Organizacionais

É importante ter uma especificação e um projeto (design) bem detalhados antes de passar para a implementação — talvez por motivos contratuais? Não, partes do sistema podem ser construídas durante toda a duração do projeto.
É realista uma estratégia de entrega incremental, na qual o software é entregue aos clientes ou outros stakeholders e um rápido feedback é obtido? Sim, pois há proximidade do cliente com o Product Owner e a equipe de desenvolvimento.
Os representantes do cliente estarão disponíveis e dispostos a participar do time de desenvolvimento? Não, o desenvolvimento será feito todo pela equipe, sendo o cliente responsável por acompanhar o trabalho e dar os devidos feedbacks.
Existem questões culturais que possam afetar o desenvolvimento do sistema? Não, pois o time é novo e não tem apego a determinado método de desenvolvimento.

Levando em consideração todas as respostas do grupo às perguntas sugeridas por Sommerville (2018), chegou-se às seguintes conclusões:

O software a ser desenvolvido é pequeno, de pequena a média complexidade e vida útil curta, o que indica que um processo ágil pode ser suficiente, não sendo necessário um esforço tremendo de documentação para realizar comunicação entre a equipe e o cliente;
O time de desenvolvimento será o principal responsável pelo desenvolvimento, é composto por pessoas experientes com as tecnologias necessárias e as mesmas são ferramentas produtivas e que facilitam a comunicação entre o time, assim, a metodologia ágil pode ser aplicada facilmente.
A implementação pode começar a ser realizada antes da completa especificação do produto, assim como podem ser feitas pequenas entregas incrementalmente, das quais podem ser recebidos feedbacks rapidamente.

Assim, foi definido que a melhor abordagem a ser adotada é a abordagem de desenvolvimento de software ágil.

Para garantir a entrega de um produto de alta qualidade, é fundamental adotar uma abordagem iterativa e colaborativa no processo de Engenharia de Requisitos. No caso do produto em questão, que visa a distribuição, mesmo que tenha apenas um cliente no momento, é essencial haver uma iteração contínua entre o dono do produto, os desenvolvedores e o feedback do cliente, como proposto por Sommerville. É importante que o backlog do produto e protótipos sejam utilizados para validar as necessidades do cliente. A adaptação contínua do processo de ER, também proposta por Sommerville, é necessária para atender às necessidades específicas do produto e do projeto, garantindo que o desenvolvimento seja eficaz.

Fatores Técnicos

Integração Contínua
Refatoração Contínua
TDD
Design Emergencial

Fatores Organizacionais

Planejamento do projeto
ScrumXP
Comunicação
Sprint reviews e retrospectivas
Equipe multidisciplinar

3.2. Processo de Software

Foi definida a utilização do ScrumXP que é uma metodologia ágil que combina duas abordagens: Scrum e Extreme Programming (XP). O objetivo dessa metodologia é melhorar a qualidade do produto e aumentar a produtividade da equipe. O fator decisivo para a escolha desse método foi seu foco na colaboração entre a equipe e o cliente que é envolvido no processo de desenvolvimento desde o início e fornece feedback regular para a equipe. Isso ajuda a garantir que o produto final atenda às necessidades do cliente e evita retrabalho desnecessário.

Essa metodologia é baseada em práticas do scrum como o desenvolvimento em ciclos curtos denominados sprints, além de cerimônias como a daily scrum, a sprint planning, sprint review e sprint retrospective. Além disso, incorpora várias práticas do XP, incluindo a programação em pares, desenvolvimento orientado a testes e integração contínua.

3.3. Processo de Engenharia de Requisitos

De acordo com George Marsicano (2023), na Engenharia de Software, os modelos de processos e ciclos de vida de desenvolvimento de software definem as etapas necessárias para a construção do software, e um ponto em comum entre os modelos é a necessidade de uma etapa dedicada à compreensão dos problemas a serem solucionados e à definição de "o quê" será feito. A esta etapa dá-se o nome de Engenharia de Requisitos (ER). Ainda segundo o autor, as atividades da Engenharia de Requisitos são as mesmas em processos dirigidos a plano e processos ágeis, entrentanto, a filosofia por detrás destes processos faz com que estas atividades sejam realizadas de forma diferente segundo cada uma das abordagens. Desta forma, a definição da abordagem e do processo de software influenciam diretamente na escolha do processo de engenharia de requisitos a ser utilizado, de modo que alguns processos tem maior harmonia com uma abordagem e não se integram bem nas atividades de outra abordagem.

A respeito das atividades da Engenharia de Requisitos, George Marsicano (2023) as divide em grupos de atividades que se correlacionam entre si de forma iterativa. O autor utiliza a representação da figura de um átomo para ilustrar a forma como as atividades podem se relacionar entre si de forma iterativa e equilibrada. A Figura 2 traz a representação do modelo proposto pelo autor.

As atividades listadas pelo autor são:

Elicitação e descoberta: baseia-se nas atividades de elicitação - extrair, obter ou provocar uma resposta, reação ou informação de alguém ou de algo - e descoberta - encontrar algo que antes não era conhecido ou não estava disponível. As fontes da elicitação podem ser diversas, desde stakeholders, até IAs, pesquisas ou sistemas existentes. Deve-se atentar aos requisitos funcionais e não funcionais, assim como descobrir quem são os interessados, seus problemas, necessidades, desejos e expectativas, além de outros fatores que podem representar possibilidades ou restrições ao produto de software.
Análise e consenso: envolve a análise - analisar os requisitos em sua forma “bruta” - e o consenso - conciliar as fontes de informação em direção a um entendimento comum sobre o conjunto de requisitos.
Declaração: diz respeito à comunicação dos requisitos entre os envolvidos, por meio de linguagem natural, estruturada ou não, de maneira escrita e/ou oral (face a face, áudio, vídeo) em diferentes níveis degranularidade (mais detalhes, menos detalhes, agrupados ou divididos).
Representação: é a produção da apresentação dos requsitos em modelos e/ou visualizações do produto, podendo ser informal, semiformal ou formal.
Verificação e Validação: estas atividades dizem respeito à qualidade dos requisitos. A validação é uma forma de constatar a qualidade externa, confirmando (ou não) se a solução correta está sendo construída. Já a verificação é voltada para a qualidade interna, e busca confirmar (ou não) de que o que a solução ou requisito está sendo feita da maneira correta.
Organização e Atualização: este tópico refere-se a manutenção do conjunto de requisitos do produto adequadamente, organizados e atualizados ao longo do tempo. Na organização estabelece-se a maneira como os requisitos do produto serão estruturados (lista, mapa), rastreados, refinados e priorizados com base no framework de requisitos adequado ao produto e/ou projeto, e a atualização é o esforço de manter a organização dos requisitos sempre em seu estado mais atual, diante das possíveis mudanças e consenso entre as fontes de requisitos.

Figura 2: Atividades da Engenharia de Requisitos. Fonte: George Marsicano, 2023.

Uma vez descritas as atividades da Engenharia de Requisitos, há que se definir uma abordagem ou processo para realizar as mesmas. O International Requirements Engineering Board (IREB), na publicação Handbook for the CPRE Foundation Level according to the IREB Standard, de Glinz e autores (2022), apresenta um método de definição de processo de Engenharia de Requisitos baseado na análise das diferentes "facetas" do processo. Deve ser feita a análise sobre quais extremos de cada eixo correspondem ao que se sabe e ao esperado do produto a ser desenvolvido, e a partir daí e do que já foi definido do ciclo de vida e do processo de software, define-se um processo a ser seguido para a execução das atividades da ER. Na Figura 3, apresentamos o esquema das facetas do processo.

Figura 3: Facetas do processo de Engenharia de Requisitos. Fonte: Glinz et al, 2022.

Analisando as descrições das facetas do processo de ER, chegamos à conclusão de que o processo será iterativo, exploratório e orientado ao mercado. Os seguintes aspectos foram levados em consideração nesta análise:

os requisitos não são completamente conhecidos desde o início;
podemos fazer ciclos curtos de feedback pela proximidade do time de desenvolvimento com o cliente;
será necessária a priorização e negociação de requisitos devido à duração do projeto;
apesar de haver um cliente, ele é uma referência para o desenvolvimento do projeto, cujo objetivo é poder ser utilizado por clientes diversos, com usuários em pontencial não identificáveis individualmente;
os requisitos serão prioritariamente elicitados pela equipe do projeto, mas com participação do cliente.

A partir destas observações e também da definição da abordagem e ciclo de vida ágil e da utilização do processo de desenvolvimento ScrumXP, conclui-se que o processo de Engenharia de Requisitos a ser utilizado será o Orientado a Produto.

3.4. Ferramentas

Ferramentas de Execução do Projeto

Para alcançar os objetivos do projeto utilizaremos Javascript que é uma linguagem de programação usada tanto no frontend quanto no backend, para auxiliar sua utilização utilizaresmos os frameworks ReactJS e NodeJS, respectivamente. Utilizaremos também o NestJS que é um framework modular que ajuda a desenvolver aplicativos NodeJS. Usaremos o Jest como ferramenta de testes do JavaScript para identificar e corrigir bugs, o Docker para empacotar aplicativos em contêineres isolados e, por fim, o MySQL para gerenciamento de banco de dados.

WhatsApp e Discord

Estas duas ferramentas foram utilizadas para a comunicação do grupo e apoio na realização dos rituais das metodologias de desenvolvimento adotadas. Dailys e comunicação em gerais feitas no WhatsApp, e reuniões de planning, review e retro feitas pelo Discord.

Git e GitHub

As ferramentas foram utilizadas para versionamento de código e repostório do projeto. Foi utilizado também o recurso do GitHub pages para exposição da documentação do projeto e entregas da disciplina.

Git Projects

O Git Projects é uma ferramenta de gerenciamento de projetos embutida no GitHub, que permite aos usuários organizar, acompanhar e gerenciar o progresso de suas tarefas e projetos.

Figma

Ferramenta de design de interface do usuário baseada na web que permite a colaboração em tempo real, prototipagem interativa e criação de designs de alta fidelidade para aplicativos e sites. Foi utilizada para a confecção dos protótipos do projeto.

3.5. Rituais

Rerefe-se a todos os processos que acontecerão dentro da Sprint

Atividades	Método	Ferramenta	Entrega
Sprint Planning	Reunião em grupo	Discord e Git Projects	Issues referentes aos requisitos da sprint
Daily	Reunião assíncrona	Discord e WhatsApp	Relatório sobre frência na reunião, atividades da equipe e impedimentos
Sprint Review	Apresentação	Discord, GitHub, Git Projects, GitPages	Validação do Produto
Sprint Retrospective	Reunião e brainstorm	Discord, EasyRetro e GitPages	Levantamento dos pontos fortes e aspectos de melhorias da equipe, afim de melhorar a sua qualidade de desenvolvimento

3.6. Arquitetura

Visão Geral da Arquitetura

A Figura 1 apresenta a visão geral da arquitetura do projeto, representando todos os serviços e suas relações.

Arquitetura

Figura 1 - Diagrama de Visão Geral da Arquitetura

Serviços

Frontend: Para o frontend, optaremos por utilizar uma arquitetura do tipo Single Page Application (SPA), seguindo o padrão Component-Based Architecture, com base na estrutura de desenvolvimento web React. Essa escolha foi feita devido à ampla utilização no mercado e aos benefícios que essa arquitetura oferece, como uma experiência de usuário aprimorada em termos de fluidez e responsividade, facilidade de reutilização de código, modularidade e facilidade de manutenção.
Backend: No backend, adotaremos a arquitetura em camadas padrão MVC (Model, View, Controller). Essa arquitetura é amplamente utilizada no mercado e foi escolhida devido à familiaridade da maioria da equipe com ela.

MVC

4. Atividades

4.1. Requisitos e Planejamento

Atividade	Métodos	Ferramentas	Entrega
Elicitação e Descoberta	Brainstorming	Google Meet, Google Docs e Discord	Conversas entre a equipe e o cliente buscando extrair informações para a definição dos requisitos.
Análise e Consenso	Brainstorming e Análise de Viabilidade	Google Meet	Conversas entre a equipe e o cliente buscando ter um consenso dos requisitos.
Declaração	Temas, Épicos e Histórias de usuários	Google Docs, GitHub Pages e Mural	Comunicação clara e com linguagem natural de uma forma a deixar claro os requisitos estabelecidos.
Organização e Atualização	Product Backlog e Matriz de Priorização	Mural e GitHub Pages	Organização, visualização e acompanhar o estado de cada requisito na estrutura do SAFe.
Representação	Prototipar interface	Paint e Figma	Apresentação visual de baixa e alta fidelidade dos requisitos simulando a sua aplicação final.
Verificação e Validação	Checklists, Revisão e Inspeção dos requisitos	Google Docs e Mural	Lista de requisitos alinhada com os objetivos do produto

4.2. Prototipação

Atividade	Método	Ferramenta	Entrega
Interface de usuário	Prototipagem de Baixa fidelidade	Paint	Protótipo para entendimento inicial da aplicação
Interface de usuário	Prototipagem de Alta fidelidade	Figma	Protótipo das interfaces do aplicativo

4.3. Implentação

Atividade	Método	Ferramentas	Entrega
Codificação do produto	Pair Programming	VSCode e GitHub	Desenvolvimento das entregas do MVP1 e MVP2
Validação do produto com o cliente	Reunião	Discord	Validar se as entregas realizadas pela equipe atendem aos requisitos
Testes	Teste de aceitação, teste de integração, teste unitário	VsCode e GitHub	Identificação e correção de erros no desenvolvimento da aplicação

5. Lições Aprendidas

Unidade 1

Durante esta unidade, tivemos a oportunidade de aprender algumas lições importantes sobre a organização de requisitos de um projeto. Uma das principais lições foi a importância de compreender as necessidades do usuário antes de começar a organizar os requisitos. Ao entender o que o usuário deseja e precisa, podemos garantir que o projeto atenda às suas expectativas e requisitos. Aprendemos também a dar prioridade aos requisitos, que são essenciais para o sucesso do projeto. Também aprendemos a manter uma comunicação aberta e constante com todas as partes interessadas, incluindo usuários e membros da equipe do projeto, a fim de garantir que todos estejam alinhados e trabalhando juntos para alcançar os objetivos do projeto. Essas lições são fundamentais para garantir que o projeto seja bem-sucedido e entregue resultados satisfatórios aos usuários.

Outro aspecto muito importante bastante discutido foi a escolha de métodos de desenvolvimento, definição de ciclos de vida e de processos de engenharia de requisitos. Essas escolhas são realizadas a partir da reflexão sobre o projeto que se planeja fazer e são determinantes sobre todo o processo de construção do projeto. Foi possível perceber como esses diferentes pontos se complementam e codependem entre si, e durante a unidade houve o esforço da turma e do grupo em buscar a combinação mais adequada e harmônica para o projeto, dados o tempo e os recursos disponíveis e o escopo desejado.

Houveram desafios quanto à organização da equipe no que diz respeito à divisão de tarefas entre os membros e também ao gerenciamento de tempo. Por vezes, algumas pessoas acabaram ficando sobrecarregadas com as tarefas. Quanto ao gerenciamento do tempo, o grupo teve dificuldade em realizar as tarefas com antecedência, conforme havíamos planejado inicialmente, assim como houve dificuldade em marcar reuniões, tendo sido necessário realizá-las em horários inadequados.

Unidade 2

Para o grupo, no geral, essa unidade foi muito importante para aprender a respeito da prática de todas as fases do processo de Engenharia de Requisitos. Foi muito importante ter contato com a discussão a respeito dos aspectos humanos e sociais da Engenharia de Requisitos, aprendendo a equilibrar os desejos e necessidades dos stakeholders com as condições do projeto. Aprendemos muito a respeito da elicitação de requisitos, que é uma fase crucial no processo de desenvolvimento de software, pois envolve compreender profundamente as necessidades e expectativas dos stakeholders para garantir que o sistema atenda aos seus objetivos.

Em relação à organizaçao interna do grupo, alguns problemas relatados na Unidade 1 voltaram a ocorrer. Precisamos melhorar nossa comunicação, transmitir de forma eficiente o trabalho de cada pessoa e melhorar a proatividade e divisão de tarefas entre a equipe. Aprendemos que é importante também estabelecer uma constância de reuniões a cada sprint, cumprindo os rituais do Scrum mais adequadamente. Para isso, o primeiro passo vai ser a organização pessoal e do grupo com horários e reuniões.

Outro ponto de melhora para a próxima unidade é utilizarmos com mais frequência o auxílio fornecido para a monitora, que está sempre disponível, porém temos subutilizado a sua experiência disponibilidade em ajudar. Ainda sobre a monitoria, devemos como grupo e individualmente melhorar a frequência de feedbacks, assim podendo receber orientações que auxiliem a lidarmos com os problemas do grupo.

Unidade 3

Durante a unidade 3, tivemos a oportunidade de aprender ainda mais. Aprendemos sobre a importância do planejamento antecipado, compreendendo como ele contribui para o sucesso do projeto. Sobre como o conteúdo abordado nos ajudou a aprofundar nosso conhecimento sobre a elicitação de requisitos e aprimorar nossa compreensão das necessidades dos stakeholders. A organização interna do grupo também melhorou significativamente, com reuniões mais frequentes e uma distribuição mais equilibrada de tarefas.

A monitora desempenhou um papel crucial nessa unidade. Buscamos sua ajuda com mais frequência e ela sempre nos recebeu de forma acolhedora e disposta a oferecer suporte. Aproveitamos ao máximo sua experiência e orientação para lidar com desafios específicos e melhorar nosso desempenho e nossa entregas. Percebemos a importância de buscar feedbacks regulares, tanto da monitora quanto entre os membros do grupo. Essa prática nos permitiu corrigir erros, aperfeiçoar nossas habilidades e garantir um progresso constante ao longo da unidade.

Apesar dos esforços para melhorar nossa organização e planejamento, enfrentamos desafios decorrentes do curto prazo de entrega durante esta unidade. Mesmo com uma maior proatividade e uma distribuição mais equilibrada de tarefas, ainda nos deparamos com diversas dificuldades ao trabalharmos em conjunto.

Como resultado dessas lições, nos sentimos mais preparados para enfrentar os desafios futuros. Aprendemos a importância do planejamento, da comunicação eficiente, da colaboração em equipe e do aproveitamento adequado dos recursos disponíveis, incluindo a valiosa assistência da monitora.

Unidade 4

Para o grupo, a unidade 4 foi uma unidade particularmente "corrida". Percebemos que por mais que tenhamos conseguido fazer tudo o que nos propomos, as atividades da unidade exigiram uma dedicação ainda maior do que as das unidades anteriores. As atividades de Engenharia de Requisitos que foram feitas na disciplina exigiram bastante ajuda da monitora, e por vezes tiveram que ser refeitas, mas compreendemos que tudo faz parte do processo de aprendizagem e crescimento.

Quanto às atividades referentes ao desenvolvimento do projeto, foi na unidade 4 que juntamos as pontas de algumas questões, levamos outras questões para revisão do professor, da monitora e também do cliente, para que pudéssemos ter um produto alinhado com as expectativas e acordos de todos. Por vezes, foi feito retrabalho de algumas funcionalidades ou artefatos, e aprendemos com isso a importância do planejamento, das revisões e da comunicação entre o grupo, com o cliente, com o professor e com a monitora.

No geral, chegamos ao final do período de duração da disciplina com muitos aprendizados e lições para a vida. Um dos consensos do grupo é de que foi muito interessante poder compartilhar os diversos conhecimentos de cada pessoa da equipe. Aprendemos uns com os outros, cada um utilizando suas habilidades em prol do grupo e ajudando seus pares a evoluir em conhecimento técnico, acadêmico e interpessoal.

Por último, mas não menos importante, registramos aqui que a forma como o trabalho foi realizado nos permitiu aprender profundamente questões chave da Engenharia de Requisitos, assim como nos permitiu praticar a aplicação de técnicas que serão muito úteis em nossas carreiras de Engenheiros de Software.

6. Referências

Handbook IREB CPRE Foundation Level, Version 1.1.0, september 2022.

MARSICANO, George. Requisitos de Software: Introdução a Engenharia de Requisitos (ER). Brasília, 2023. Disponível em: https://aprender3.unb.br/course/view.php?id=18123. Acesso em: 29 abr. 2023.

SOMMERVILLE, Ian. Engenharia de software. 10.ed. São Paulo: Pearson Education do Brasil, 2018.

Visão do Produto e Projeto. Wiki Requisitos - Dubium. Disponível em: https://mdsreq-fga-unb.github.io/2022.2-Dubium/visao/. Acesso em: 19 de abril de 2023.

Visão do Produto e Projeto. Wiki Requisitos - GetPet. Disponível em: https://mdsreq-fga-unb.github.io/2022.2-GetPet/#/pages/Vis%C3%A3odoProdutoeProjeto. Acesso em: 19 de abril de 2023.

Visão do Produto e Projeto. Wiki Requisitos - MedicaCerto. Disponível em: https://mdsreq-fga-unb.github.io/2023.1-Remediario/entregas/unidade1/VisaoProdutoProjeto. Acesso em: 17 de junho de 2023.

7. Histórico de Versão

Data	Versão	Descrição	Autor(es)
19/04/2023	1.0	Criação do documento, adição dos tópicos 1 e 2	Cainã Freitas, Charles Serafim, Gabrielly Assunção, Lucas Heler e Sabrina Berno
26/04/2023	1.1	Criação da aba entregas, adição dos tópicos 3 e 4	Cainã Freitas, Charles Serafim, Gabrielly Assunção, Lucas Heler e Sabrina Berno
29/04/2023	1.2	Adição do método de Sommerville, processo de software e processo de ER, correções nos objetivos	Charles Serafim e Gabrielly Assunção
29/04/2023	1.3	Adição da metodologia ScrumXP	Charles Serafim e Gabrielly Assunção
15/05/2023	1.4	Adição da arquitetura do projeto	Cainã Freitas
25/05/2023	1.5	Adição das lições aprendidas na Unidade 2	Cainã Freitas, Charles Serafim, Gabrielly Assunção, Lucas Heler e Sabrina Berno
15/06/2023	1.6	Atualização do cronograma das sprints com as US	Sabrina Berno
17/06/2023	1.7	Atualização das tecnologias e ferramentas, arquitetura e atividades	Charles Serafim e Sabrina Berno
20/07/2023	1.8	Adição das Lições Aprendidas da Unidade 4	Cainã Freitas, Charles Serafim, Gabrielly Assunção, Lucas Heler e Sabrina Berno