docs: ultimos ajustes

Co-authored-by: JÉSUS GABRIEL  <[email protected]>

docs/sections/entregas/unidade3/VeriVal-PBB-CalorieExplorer.md

@@ -1,6 +1,9 @@
 # Verificação e Validação - PBB do Projeto Calorie Explorer
 
-Para a fase de verificação, foi utilizado a metodologia de Checklist
+# 1. Verificação
+A verificação do PBB (Product Backlog Building) para o projeto Calorie Explorer foi conduzida utilizando um checklist para avaliar se todos os elementos fundamentais do Canvas PBB foram atendidos. Entre os pontos verificados, constatou-se que o Canvas PBB está devidamente identificado com o produto, e os problemas e expectativas do cliente foram corretamente listados. Também foram criadas personas, e as ações associadas a essas personas foram mapeadas, incluindo o que fazem atualmente e o que desejam fazer com o sistema. As funcionalidades foram definidas com base nas ações das personas, identificando os problemas que cada funcionalidade resolve e os benefícios que trazem.
+
+No entanto, durante a verificação, foram observadas algumas inconsistências: o PBI "Fazer atualizações e melhorias" não segue corretamente o modelo ARO, apresentando ausência do objeto, e alguns PBIs foram organizados sem seguir a prioridade estabelecida. Além disso, as histórias de usuário, que deveriam ser derivadas diretamente dos PBIs, não seguiram o modelo de escrita proposto, o que gerou inconsistências na forma como as histórias foram elaboradas em relação aos PBIs originais.
 
 Pergunta | Check | Comentários
 -------- | ----- | ----------
@@ -18,7 +21,10 @@ Foram criadas as histórias de usuário usando o PBI, personas e benefícios | N
 As histórias de usuários possuem critérios de aceitação | SIM | -- 
 Os PBIs estão organizados verticalmente pelo valor de prioridade | NÃO | As US's foram montadas e receberam o seus códicos sem considerar a ordem de prioridade estabelecido nos PBIs.
 
-Para a validação, também utilizamos o checklist, porém aqui avaliamos a qualidade de cada um dos itens desenvolvidos.
+## 2. Validação
+A validação do PBB envolveu uma análise detalhada da qualidade e coerência de cada item desenvolvido, comparando-os com o contexto do estudo de caso HealthNet. Os problemas e expectativas identificados foram considerados apropriados e relevantes, assim como as personas e suas atividades. As funcionalidades criadas foram bem associadas às personas e apresentaram um nível adequado de granularidade. No entanto, foi identificado que, em alguns casos, os benefícios descritos para as funcionalidades não eram suficientemente específicos, abrangendo vantagens que poderiam se aplicar a múltiplas funcionalidades, o que comprometeu a clareza.
+
+Adicionalmente, observou-se que as User Stories não estavam alinhadas ao modelo padrão de escrita, que envolve a estrutura "Eu, como [persona], posso [ação], para [valor de negócio]". Além disso, os critérios de aceitação, embora relevantes, foram redigidos de maneira inadequada, apresentando a visão das personas como executoras dos critérios, o que dificulta a compreensão das condições necessárias para o funcionamento da User Story. A reformulação dos critérios para um formato mais imparcial e padronizado é necessária para melhorar a qualidade das validações.
 
 Pergunta | Check | Comentários
 -------- | ----- | ----------
@@ -35,4 +41,10 @@ Os PBIs são coerentes com as funcionalidades com a qual estão associados | SIM
 Os PBIs foram escritos com o mesmo modelo (Estão padronizados) | SIM | --
 As USs estão estruturadas no formato: "Eu, como [persona], posso [ação], para [valor de negócio]" | NÃO | Nenhuma das User Story seguem o modelo de escrita.
 Os critérios de aceitação estão coerentes com a US a qual estão associados | SIM | -- 
-Os critérios de aceitação informam apenas as condições para a US funcionar | NÃO | Os critérios de aceitação foram escritos como se as personas realizassem os critérios. Deverá ser feito pensado em qualquer usuário.
+Os critérios de aceitação informam apenas as condições para a US funcionar | NÃO | Os critérios de aceitação foram escritos como se as personas realizassem os critérios. Deverá ser feito pensado em qualquer usuário.
+
+
+## Histórico de Versão:
+Data | Versão | Descrição | Autor | Revisores 
+---- | ------ | --------- | ----- | ---------
+04/09/24 | 1.0 | Criação do documento | Daniel Rodrigues | Jésus Gabriel

docs/sections/historiasUsuarios/US.md

@@ -56,7 +56,7 @@ F06 | EP04 |	Autenticação e Cadastro de Conta
 Para a produção do sistema RISo, foram identificadas 11 User Stories, que descrevem as funcionalidades a serem desenvolvidas do ponto de vista dos usuários.
 
 Nº | Título | História de Usuário
--- | ------ | --------- 
+-- | ------ | -------------------
 US01 | Cadastrar e Logar na Conta | Eu como usuário, devo ser capaz de me cadastrar e logar na plataforma, para que eu possa utilizar das funções do software e ter a segurança de meus dados.
 US02 | Cadastrar Empresa-Unidade | Eu como usuário, devo ser capaz de registrar uma nova Unidade/Empresa, para que os dados obtidos pelo sistema RISO seja acessada apenas pelos associados à esta Unidade/Empresa.
 US03 | Adicionar Colaboradores | Eu como Administrador da Unidade/Empresa, devo ser capaz de adicionar colaboradores a partir de um código aleatório gerado no ato da criação da Unidade/Empresa, para que mais pessoas possam acompanhar os dados obtido pelo sistema RISO.
@@ -69,6 +69,38 @@ US09 | Visualizar gráfico de média de sorrisos por pessoa por dia, semana e m
 US10 | Visualizar dados de taxas gerais de risos | Eu como usuário e usuário administrador, devo ser capaz de visualizar uma taxa em porcentagem que exibe a quantidade de pessoas capturadas para o levantamentos dos dados no dia e quantas dessas riram, para que eu obtenha dados aprofundados da taxa de sorrisos.
 US11 | Integrar em uma câmera única no Caixa | O Sistema, deve ser capaz de capturar e realizar o reconhecimento de sorrisos com uma câmera especializada do cliente, para que o sistema RISO seja devidamente aplicado ao contexto do cliente.
 
+Para definir suas prioridades, foi considerado a frequência de uso da US e seu valor de negócio. Ao final é feito o somatório dos dois critérios para se obter a prioridade total: **Prioridade = (Frequência de Uso) + (Valor de Negócio)**.
+
+User Story | Frequência de Uso | Valor de Negócio | TOTAL
+---------- | ----------------- | ---------------- | -----
+US01 | 4 | 3 | 7
+US02 | 1 | 2 | 3
+US03 | 4 | 3 | 7
+US04 | 2 | 1 | 3
+US05 | 2 | 2 | 4
+US06 | 5 | 3 | 8
+US07 | 5 | 3 | 8
+US08 | 4 | 3 | 7
+US09 | 4 | 4 | 7
+US10 | 3 | 2 | 5
+US11 | 5 | 3 | 8
+
+Sendo assim, as US's em sua ordem de prioridade é:
+
+Código da US | Prioridade Total
+------------ | ----------------
+US06 | 8
+US07 | 8
+US11 | 8
+US01 | 7
+US03 | 7
+US08 | 7
+US09 | 7
+US10 | 5
+US05 | 4
+US02 | 3
+US04 | 3
+
 Com base nos Épicos já categorizados, o agrupamento das User Stories em Features, mantendo-as nos respectivos Épicos, ficou da seguinte forma:
 
 Código do Épico	| Código da Feature |	Título da Feature	| Código das US Associadas