From 66846627678f222a518072f1cbf3c6c9f254ffe8 Mon Sep 17 00:00:00 2001 From: arthur-suares Date: Mon, 16 Dec 2024 21:36:04 -0300 Subject: [PATCH 1/4] docs: correcao no topico 3 --- docs/sections/2-docPage/3-estrategiasEngSoftware.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/sections/2-docPage/3-estrategiasEngSoftware.md b/docs/sections/2-docPage/3-estrategiasEngSoftware.md index 813cf12..eebbae7 100644 --- a/docs/sections/2-docPage/3-estrategiasEngSoftware.md +++ b/docs/sections/2-docPage/3-estrategiasEngSoftware.md @@ -39,7 +39,7 @@ Fonte: Elaborado pelos autores (2024) Conforme explicitado na figura 1, o processo de desenvolvimento de software mais indicado para o projeto é o Scrum/XP, uma combinação do Extreme Programming (XP) com o framework de gestão de projetos Scrum. Tanto Scrum, quanto XP foram desenvolvidos no contexto de abordagem ágil de desenvolvimento de software e ciclo de vida do produto iterativo e incremental. -O diferencial do Scrum/XP para o Unified Process na escolha através do framework já mencionado, foi a não existência de requisitos de alta confiabilidade. Por outro lado, a escolha do Scrum/XP já era desejada pelo time de desenvolvimento devido a experiências anteriores bem sucedidas com o processo. +O diferencial do Scrum/XP para o FDD na escolha através do framework, foi a flexibilidade de requisitos. Por outro lado, a escolha do Scrum/XP já era desejada pelo time de desenvolvimento devido a experiências anteriores bem sucedidas com o processo. --- ####Referências: From 7de1191452c57ac5d5cbd878e37152f7c1081b78 Mon Sep 17 00:00:00 2001 From: arthur-suares Date: Mon, 16 Dec 2024 21:58:30 -0300 Subject: [PATCH 2/4] docs: correcao no topico 4 --- docs/sections/2-docPage/4-engenhariaRequisitos.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/docs/sections/2-docPage/4-engenhariaRequisitos.md b/docs/sections/2-docPage/4-engenhariaRequisitos.md index 8c1baca..a334092 100644 --- a/docs/sections/2-docPage/4-engenhariaRequisitos.md +++ b/docs/sections/2-docPage/4-engenhariaRequisitos.md @@ -30,13 +30,6 @@ **Critérios de aceitação:** São definidos critérios de aceitação, ou seja, é acordado junto com os stakeholders do projeto e o Project Owner o que uma User Story precisa ter para ser aceita. Sendo isso feito para que ambas as partes, equipe de desenvolvimento e stakeholders, tenham compreensão do que determinada funcionalidade ou item precisa ter para ser considerada concluída. - -**Definition of Ready (D.O.R.):** É usado um conjunto de critérios que visam qualificar quando uma User Story está pronta para ser trabalhada. Garantindo que a equipe de desenvolvimento tenha informações claras necessárias para começar a implementar a funcionalidade. - - -**Definition of Done (D.O.D.):** É também utilizado um conjunto de critérios que visam descrever o que determinada funcionalidade precisa ter para ser considerada concluída e finalizada, testada e poder ser entregue para o cliente. - - **Debates e incorporação de Feedback:** A equipe de desenvolvimento apresenta o que foi desenvolvido. Ao receber o feedback do cliente acerca da funcionalidade desenvolvida a equipe faz a incorporação desse feedback à funcionalidade. From d735782692ceb218ab4a52354535e8f911d68a35 Mon Sep 17 00:00:00 2001 From: arthur-suares Date: Mon, 16 Dec 2024 22:01:43 -0300 Subject: [PATCH 3/4] docs: correcao no topico 9 --- docs/sections/2-docPage/9-backlogDeProduto.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/sections/2-docPage/9-backlogDeProduto.md b/docs/sections/2-docPage/9-backlogDeProduto.md index 4418e7a..92f4038 100644 --- a/docs/sections/2-docPage/9-backlogDeProduto.md +++ b/docs/sections/2-docPage/9-backlogDeProduto.md @@ -83,7 +83,7 @@ Em outras palavras, caso o nível de esforço seja nível 1, por exemplo, isto s - **2:** Agrega valor médio ao produto, contribuindo moderadamente para a satisfação dos usuários ou objetivos do negócio. - **3:** Agrega alto valor, sendo essencial para o sucesso do produto e trazendo impacto significativo para os usuários ou para o negócio. -Para calcular a **prioridade** das funcionalidades com base nos três níveis de avaliação (Esforço, Valor Agregado e UX), iremos utilizar uma fórmula que combine os pesos de cada critério. O objetivo é priorizar funcionalidades que agreguem mais valor e ofereçam uma boa experiência ao usuário, mas com menor esforço. +Para calcular a **prioridade** das funcionalidades com base nos três níveis de avaliação (Esforço, Valor Agregado), iremos utilizar uma fórmula que combine os pesos de cada critério. O objetivo é priorizar funcionalidades que agreguem mais valor e ofereçam uma boa experiência ao usuário, mas com menor esforço. **Prioridade = (4 * Valor_Agregado) - Esforço** @@ -129,13 +129,12 @@ RQNF06 | 3 | 1 | 11 ## 9.3 - MVP -Decidido durante a produção do Workshop Lean Inception, foi estabelecido o MVP do produto de software da Família do Sítio e a sua versão de incremento baseando-se na definição de 3 categorias, como dito na seção anterior: +Decidido durante a produção do Workshop Lean Inception, foi estabelecido o MVP do produto de software da Família do Sítio e a sua versão de incremento baseando-se na definição de 2 categorias, como dito na seção anterior: - Esforço de Execução; - Valor Agregado; -- Impacto na experiência do Usuário: -Com esta técnica, foi possível elencar as funcionalidades de maior valor agregado e impacto na experiência do usuário para as primeiras produções feita pelo time. Dessa forma, as funcionalidades **que estão em MVP**, são: +Com esta técnica, foi possível elencar as funcionalidades de maior valor agregado para as primeiras produções feita pelo time. Dessa forma, as funcionalidades **que estão em MVP**, são: ### 9.3.1 - Requisitos Funcionais From e32e3080259e0a8360ef0b10760e236e1baecf61 Mon Sep 17 00:00:00 2001 From: arthur-suares Date: Mon, 16 Dec 2024 22:04:39 -0300 Subject: [PATCH 4/4] docs: correcao do topico 4.1.6 --- docs/sections/2-docPage/4-engenhariaRequisitos.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/docs/sections/2-docPage/4-engenhariaRequisitos.md b/docs/sections/2-docPage/4-engenhariaRequisitos.md index a334092..8e2b459 100644 --- a/docs/sections/2-docPage/4-engenhariaRequisitos.md +++ b/docs/sections/2-docPage/4-engenhariaRequisitos.md @@ -59,11 +59,7 @@ Antes da validação com o cliente, a equipe realiza reuniões internas para rev ### 4.1.6 Organização e Atualização de Requisitos -**Product Backlog Building (PBB):** Essa técnica organiza os requisitos em um formato hierárquico, desde os objetivos de negócio até as histórias de usuário, ajudando a manter o backlog atualizado, alinhado às necessidades dos stakeholders e adaptável ao longo do desenvolvimento. As etapas incluem: -1. **Definir os objetivos de negócio**: Identificar as metas que o produto deve alcançar. -2. **Identificar funcionalidades**: Mapear as principais funcionalidades para atender aos objetivos. -3. **Criar histórias de usuário**: Detalhar as funcionalidades em partes menores, descritivas e acionáveis. -4. **Priorizar o backlog**: Organizar os itens para maximizar valor e minimizar riscos. +A organização foi feita com base no Lean Inception. Utilizando a fórmula **Prioridade = (4 * Valor_Agregado) - Esforço** ## 4.2 Engenharia de Requisitos e o Scrum/XP