diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/404.html b/404.html new file mode 100644 index 0000000..d71a94f --- /dev/null +++ b/404.html @@ -0,0 +1,1450 @@ + + + +
+ + + + + + + + + + + + + + +Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
08/09/2024 | +0.1 | +Criação do documento | +Danilo Melo | +
Durante o processo de inspeção dos casos de uso, cada item foi verificado individualmente, utilizando uma metodologia baseada em checklist. Para cada item do checklist, uma resposta binária foi atribuída, avaliando se o item atende aos critérios de qualidade previamente definidos. Esse processo garante que cada caso de uso esteja em conformidade com os padrões esperados e pronto para ser considerado no ciclo de desenvolvimento.
+Nº | +Itens | +
---|---|
1 | +O caso de uso apresenta uma descrição clara? | +
2 | +O caso de uso apresenta o fluxo principal? | +
3 | +O caso de uso apresenta o fluxo alternativo? | +
4 | +O caso de uso apresenta o fluxo de exceção? | +
5 | +O caso de uso apresenta uma pós-condição? | +
6 | +O caso de uso apresenta rastreabilidade? | +
UC | +1 | +2 | +3 | +4 | +3 | +4 | +
---|---|---|---|---|---|---|
UC01 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC02 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC03 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC04 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC05 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC06 | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC07 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC08 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC09 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC10 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC11 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC12 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC13 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC14 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC15 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC16 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC17 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC18 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC19 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC20 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
UC21 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
08/09/2024 | +0.1 | +Criação do documento | +Patricia Helena | +
Utilizando a metodologia de inspeção por meio de um checklist, as características das Especificações Suplementares foram verificadas individualmente, resultando em uma resposta para cada pergunta do checklist, podendo ser 'sim' ou 'não'. Esse processo permite uma averiguação da qualidade de cada um dos itens, assegurando que os requisitos estejam em conformidade com os padrões esperados.
+Nº | +Perguntas | +
---|---|
1 | +Todos os requisitos estão descritos de forma clara? | +
2 | +A especificação abrange todos os aspectos essenciais relacionados aos requisitos não funcionais? | +
3 | +Os requisitos de desempenho descrevem de forma clara as condições e níveis de operação? | +
4 | +Os requisitos de segurança descrevem de forma clara as condições e níveis de proteção? | +
5 | +Os requisitos de usabilidade descrevem de forma clara as condições e níveis de facilidade de uso? | +
6 | +Os requisitos de compatibilidade descrevem de forma clara as condições e níveis de integração com outros sistemas? | +
7 | +Os requisitos de manutenção descrevem de forma clara as condições e níveis de suporte e atualização? | +
Especificações Suplementares | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +
---|---|---|---|---|---|---|---|
Especificação Suplementar | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
08/09/2024 | +0.1 | +Criação do documento | +Samara Letícia | +
O processo de inspeção dos NFR Framework foi realizado utilizando uma metodologia baseada em checklist. Para cada pergunta do checklist, uma resposta binária foi atribuída, avaliando se o item atende aos critérios.
+Nº | +Perguntas | +
---|---|
1 | +Todos os requisitos não funcionais relevantes foram identificados? | +
2 | +As metas de qualidade foram devidamente classificadas? | +
3 | +Cada meta foi descrita como um softgoal, permitindo a flexibilidade necessária para ajustes? | +
4 | +As dependências entre softgoals foram mapeadas e documentadas? | +
5 | +A notação gráfica do NFR Framework está bem organizada e fácil de seguir? | +
6 | +O diagrama visual representa corretamente as interações e impactos entre os softgoals? | +
Diagrama | +1 | +2 | +3 | +4 | +5 | +6 | +
---|---|---|---|---|---|---|
Usabilidade | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Desempenho | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
08/09/2024 | +0.1 | +Criação do documento | +Patricia Helena | +
Utilizando a metodologia de inspeção por meio de um checklist, as características da Argumentação foram verificadas individualmente, resultando em uma resposta para cada pergunta do checklist, podendo ser 'sim' ou 'não'. Esse processo permite uma averiguação da qualidade de cada um dos itens, assegurando que os requisitos estejam em conformidade com os padrões esperados.
+Nº | +Perguntas | +
---|---|
1 | +As legendas e explicações estão claras? | +
2 | +A argumentação atinge uma conclusão consistente? | +
3 | +A notação de argumento utilizada segue um padrão específico e é respeitada ao longo do documento? | +
4 | +As questão citadas foram devidamente respondidas? | +
5 | +É possível rastrear a origem dos argumentos? | +
Argumentação | +1 | +2 | +3 | +4 | +5 | +
---|---|---|---|---|---|
A01 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
A02 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
07/09/2024 | +0.1 | +Criação do documento | +Carlos Eduardo Rodrigues | +
Durante o processo de inspeção dos itens do backlog, cada item foi verificado individualmente, utilizando uma metodologia baseada em checklist. Para cada pergunta do checklist, uma resposta binária foi atribuída, avaliando se o item atende aos critérios de qualidade previamente definidos. Esse processo garante que cada requisito esteja em conformidade com os padrões esperados e pronto para ser considerado no ciclo de desenvolvimento.
+Nº | +Perguntas | +
---|---|
1 | +A história é clara e objetiva? | +
2 | +A história apresenta épico? | +
3 | +A história é separada por tema? | +
4 | +A história possui um ID em ordem crescente? | +
5 | +A história é priorizada pelo modelo MoSCoW? | +
6 | +A história identifica o usuário principal? | +
7 | +A história apresenta link(s) do(s) seu(s) respectivo(s) rastreamento(s)? | +
8 | +A história é suficientemente pequena para ser concluída dentro de um ciclo de sprint? | +
US | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +
---|---|---|---|---|---|---|---|---|
US001 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US002 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US002 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US003 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US004 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US005 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US006 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US007 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US008 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
US009 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
US010 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
US011 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
US012 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
US013 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
US014 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US015 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US016 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US017 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US018 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US019 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US020 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US021 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US022 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US023 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
US024 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US025 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US026 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
US027 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
US028 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US029 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US030 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +✔️ | +
US031 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +❌ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
07/09/2024 | +0.1 | +Criação do documento | +Patricia Helena | +
09/09/2024 | +0.2 | +correção dos cenários | +Patricia Helena | +
Utilizando a metodologia de inspeção por meio de um checklist, as características de cada cenário foram verificadas individualmente, resultando em uma resposta para cada pergunta do checklist, podendo ser 'sim' ou 'não'. Esse processo permite uma averiguação da qualidade de cada um dos cenários, assegurando que os requisitos estejam em conformidade com os padrões esperados.
+Nº | +Perguntas | +
---|---|
1 | +O cenário possui um título descritivo? | +
2 | +O objetivo usado naquele cenário esta claro? | +
3 | +O cenário possui um contexto claro? | +
4 | +Os atores pertencentes do cenário estão descritos? | +
5 | +O cenário descreve os recursos necessários? | +
6 | +O cenário possui episódios coerentes? | +
7 | +As possiveis restrições estao descritas? | +
8 | +O cenário possui (hyperlinks) com os léxicos? Se sim, estão todos em ordem? | +
C | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +
---|---|---|---|---|---|---|---|---|
C01 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
C02 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
C02 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
C03 | +✔️ | +❌ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
C04 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
C05 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C06 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C07 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C08 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C09 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C10 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C11 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C12 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C13 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C14 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C15 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C16 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C17 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C18 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C19 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C20 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C21 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C22 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C23 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C24 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C25 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C26 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C27 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C28 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C29 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C30 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
C31 | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
08/09/2024 | +0.1 | +Criação do documento | +Samara Letícia | +
O processo de inspeção dos modelos Epic foi realizado utilizando uma metodologia baseada em checklist. Para cada pergunta do checklist, uma resposta binária foi atribuída, avaliando se o item atende aos critérios.
+Nº | +Perguntas | +
---|---|
1 | +O modelo está claramente definido, com uma descrição concisa e compreensível? | +
2 | +O modelo está alinhado aos seus objetivos? | +
3 | +O escopo do modelo está bem delimitado, sem ser muito amplo ou vago? | +
4 | +O modelo foi dividido em User Stories ou tarefas menores e gerenciáveis? | +
5 | +Cada história ou tarefa derivada tem um objetivo claro e pode ser entregue de forma independente? | +
6 | +Todas as dependências e impactos foram identificados e documentados? | +
7 | +A estimativa de tempo e esforço foi feita para o Modelo e suas histórias derivadas? | +
Diagrama | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +
---|---|---|---|---|---|---|---|
Modo de Jogo | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
Exploração | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +❌ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
08/09/2024 | +0.1 | +Criação do documento | +Danilo Melo | +
Durante o processo de inspeção dos itens do léxico, cada item foi verificado individualmente, utilizando uma metodologia baseada em checklist. Para cada item do checklist, uma resposta binária foi atribuída, avaliando se o item atende aos critérios de qualidade previamente definidos. Esse processo garante que cada léxico esteja em conformidade com os padrões esperados e pronto para ser considerado no ciclo de desenvolvimento.
+Nº | +Itens | +
---|---|
1 | +Clareza e Simplicidade: Cada termo é descrito de maneira clara e objetiva, evitando ambiguidade. | +
2 | +Consistência: A documentação é feita de maneira consistente seguindo um padrão em todo o documento. | +
3 | +Inclusão de Sinônimos: O léxico deve listar sinônimos ou termos alternativos comuns para cada conceito | +
4 | +Definição Contextual: As definições fornecem o contexto de uso, indicando onde e como cada termo é utilizado no sistema. | +
L | +1 | +2 | +3 | +4 | +
---|---|---|---|---|
L01 | +✔️ | +✔️ | +✔️ | +✔️ | +
L01 | +✔️ | +✔️ | +✔️ | +✔️ | +
L01 | +✔️ | +✔️ | +❌ | +✔️ | +
L01 | +✔️ | +✔️ | +✔️ | +✔️ | +
L05 | +✔️ | +✔️ | +✔️ | +✔️ | +
L06 | +✔️ | +✔️ | +✔️ | +✔️ | +
L07 | +✔️ | +✔️ | +✔️ | +✔️ | +
L08 | +✔️ | +✔️ | +✔️ | +✔️ | +
L09 | +✔️ | +✔️ | +✔️ | +✔️ | +
L10 | +✔️ | +✔️ | +✔️ | +✔️ | +
L11 | +✔️ | +✔️ | +✔️ | +✔️ | +
L12 | +✔️ | +✔️ | +✔️ | +✔️ | +
L13 | +✔️ | +✔️ | +✔️ | +✔️ | +
L14 | +✔️ | +✔️ | +✔️ | +✔️ | +
L15 | +✔️ | +✔️ | +✔️ | +✔️ | +
L16 | +✔️ | +✔️ | +✔️ | +✔️ | +
L17 | +✔️ | +✔️ | +✔️ | +✔️ | +
L18 | +✔️ | +✔️ | +✔️ | +✔️ | +
L19 | +✔️ | +✔️ | +✔️ | +✔️ | +
L20 | +✔️ | +✔️ | +✔️ | +✔️ | +
L21 | +✔️ | +✔️ | +✔️ | +✔️ | +
L22 | +✔️ | +✔️ | +✔️ | +✔️ | +
L23 | +✔️ | +✔️ | +✔️ | +✔️ | +
L24 | +✔️ | +✔️ | +❌ | +✔️ | +
L25 | +✔️ | +✔️ | +✔️ | +✔️ | +
L26 | +✔️ | +✔️ | +✔️ | +✔️ | +
L27 | +✔️ | +✔️ | +✔️ | +✔️ | +
L28 | +✔️ | +✔️ | +✔️ | +✔️ | +
L29 | +✔️ | +✔️ | +❌ | +✔️ | +
L30 | +✔️ | +✔️ | +✔️ | +✔️ | +
L31 | +✔️ | +✔️ | +✔️ | +✔️ | +
L32 | +✔️ | +✔️ | +✔️ | +✔️ | +
L33 | +✔️ | +✔️ | +✔️ | +✔️ | +
L34 | +✔️ | +✔️ | +✔️ | +✔️ | +
L35 | +✔️ | +✔️ | +✔️ | +✔️ | +
L36 | +✔️ | +✔️ | +✔️ | +✔️ | +
L37 | +✔️ | +✔️ | +✔️ | +✔️ | +
L38 | +✔️ | +✔️ | +✔️ | +✔️ | +
L39 | +✔️ | +✔️ | +✔️ | +✔️ | +
L40 | +✔️ | +✔️ | +✔️ | +✔️ | +
L41 | +✔️ | +✔️ | +✔️ | +✔️ | +
L42 | +✔️ | +✔️ | +✔️ | +✔️ | +
L43 | +✔️ | +✔️ | +❌ | +✔️ | +
L44 | +✔️ | +✔️ | +✔️ | +✔️ | +
L45 | +✔️ | +✔️ | +✔️ | +✔️ | +
L46 | +✔️ | +✔️ | +✔️ | +✔️ | +
L47 | +✔️ | +✔️ | +✔️ | +✔️ | +
L48 | +✔️ | +✔️ | +✔️ | +✔️ | +
L49 | +✔️ | +✔️ | +✔️ | +✔️ | +
L50 | +✔️ | +✔️ | +✔️ | +✔️ | +
L51 | +✔️ | +✔️ | +✔️ | +✔️ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
07/09/2024 | +0.1 | +Criação do documento | +Carlos Eduardo Rodrigues | +
O processo de inspeção das personas foi realizado utilizando uma metodologia baseada em checklist. Para cada pergunta do checklist, uma resposta binária foi atribuída, avaliando se o item atende aos critérios.
+Nº | +Perguntas | +
---|---|
1 | +A persona tem uma descrição clara e objetiva? | +
2 | +A persona inclui informações sobre idade, profissão e contexto de vida? | +
3 | +A persona apresenta motivações e objetivos específicos relacionados ao jogo? | +
4 | +A persona possui frustrações ou desafios bem definidos? | +
5 | +A persona identifica as principais necessidades do usuário? | +
6 | +A persona está baseada em dados reais ou entrevistas com usuários? | +
7 | +A persona inclui uma representação visual? | +
Persona | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +
---|---|---|---|---|---|---|---|
Sarah | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Arthur | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Victor | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
08/09/2024 | +0.1 | +Criação do documento | +Samara Letícia | +
O processo de inspeção dos diagramas Rich Picture foi realizado utilizando uma metodologia baseada em checklist. Para cada pergunta do checklist, uma resposta binária foi atribuída, avaliando se o item atende aos critérios.
+Nº | +Perguntas | +
---|---|
1 | +O diagrama é fácil de entender sem explicações adicionais? | +
2 | +Os elementos visuais (símbolos, ícones, desenhos) são claros e consistentes? | +
3 | +Todos os componentes principais do sistema ou problema estão representados? | +
4 | +As interações e relacionamentos importantes entre os elementos estão bem ilustrados? | +
5 | +Todos os atores relevantes estão representados? | +
6 | +O diagrama está organizado visualmente, facilitando a leitura? | +
7 | +O diagrama simplifica adequadamente a complexidade do sistema sem perder informações essenciais? | +
Diagrama | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +
---|---|---|---|---|---|---|---|
Visão Geral | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Exploração | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Personagem | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Criação de Mundos | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +✔️ | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
08/09/2024 | +0.1 | +Criação do documento e adição dos requisitos funcionais | +Samara Letícia | +
09/09/2024 | +0.2 | +Adição RF54 a RF61 | +Carlos Eduardo Rodrigues | +
Validação é o processo de submeter os requisitos à aprovação externa da equipe de software, verificando se atendem às necessidades dos stakeholders e evitando custos de correções.
+Após levantarmos os requisitos, testamos e validamos cada um em diferentes ambientes do jogo.
+Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
11/09/2024 | +0.1 | +Criação do documento | +Patrícia Helena | +
Criação e validação do protótipo de uma nova funcionalidade para o jogo Minecraft: MAPA INTERATIVO. O objetivo foi prototipar uma ferramenta que facilitasse a navegação e a exploração do mundo do jogo. Após a criação do protótipo, foi aplicado um questionário a 13 jogadores para avaliar a aceitação e a eficácia da nova funcionalidade.
+Versão 1 - Autora: Patricia Helena
+ +Versão 1 - Autora: Patricia Helena
+ +Todo o Questionário foi feito e respondido pela plataforma do GoogleForms.
+ +Versão 1 - Autora: Patricia Helena
+ + +Versão 1 - Autora: Patricia Helena
+ + +Versão 1 - Autora: Patricia Helena
+ + +Versão 1 - Autora: Patricia Helena
+ +Versão 1 - Autora: Patricia Helena
+ + +Versão 1 - Autora: Patricia Helena
+ + +Versão 1 - Autora: Patricia Helena
+ + +Versão 1 - Autora: Patricia Helena
+ + + + + + + + + + + + + +Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
31/07/2024 | +0.1 | +Criação do documento inicial e adição da introdução | +Patrícia Helena | +
31/07/2024 | +0.2 | +Analise de Protocolo 1 e 2 | +Samara Letícia | +
31/07/2024 | +0.3 | +Analise de Protocolo 3 e 4 | +Patrícia Helena | +
01/08/2024 | +1.0 | +Aplicação de MoSCoW em todas as análises | +Patrícia Helena | +
Trata-se de um método onde o usuário é solicitado a realizar uma tarefa enquanto, simultaneamente, explica em voz alta o processo que está seguindo. Analisamos diferentes modos de jogo do minecraft.
+Todas as descrições e ações do usuário são feitas em voz alta para que o Analisador consiga acompanhar cada passo e classifica-los por prioridades.
+Vídeo da Analise do modo sobrevivência, Hardcore e multiplayer
+ + +Vídeo da Analise do criativo
+ + +Relator: Patrícia Helena
+Analisador: Samara Letícia
+Modo de jogo : Sobrevivência
O método foi realizado com uma pessoa que já conhecia o minecraft, os objetivos eram explorar um pouco o mapa, conseguir recursos, descobrir estruturas e interagir com os mobs.
+Ela entra no Minecraft Launcher com sua conta já logada e cria o mundo no modo Sobrevivência. Anda pelo mapa através do teclado com as teclas w, a, s e d. Coleta um pouco de madeira e usa a ferramenta crafting do jogo para criar uma mesa de trabalho. Cria uma ferramenta com ela e a usa para coletar carvão e pedra. Ela explora outras partes do mapa como o rio, e após minerar um pouco chega a uma caverna. Após explorar um pouco a caverna ela encontra um mob e tem um combate com ele, que após ser derrotado, libera drops usuária. Após explorar um pouco a caverna a usuária encontra um minério raro e uma nova estrutura da atualização, chamada de Trial Chamber. Após explorar um pouco essa estrutura, o personagem da usuária morre após ser espetado por um cacto e volta no local de início do jogo.
+Código | +Requisito | +Descrição | +Prioridade | +
---|---|---|---|
AP1.1 | +Cadastro | +Usuário ter conta no minecraft | +C | +
AP1.2 | +Uso do Teclado | +O usuário se locomove através do teclado | +M | +
AP1.3 | +Mouse | +O usuário interage com o mundo através do mouse | +S | +
AP1.4 | +Inventário | +Os recursos ficam no inventário do usuário | +M | +
AP1.5 | +Dicionário de Itens | +Recurso com explicação de todos os itens ja descobertos | +M | +
AP1.6 | +Mesa de trabalho | +O usuário precisa dela para fazer ferramentas eficientes | +S | +
AP1.7 | +Minérios | +Através dos minérios é possível conseguir novas ferramentas | +S | +
AP1.8 | +Alimento | +O jogo oferece diferentes tipos de alimento para o personagem do usuário não morrer de fome | +M | +
Legenda - técnica de priorização:
+Relator: Patrícia Helena
+Analisador: Samara Letícia
+Modo de jogo : Hardcore
O método foi realizado com uma pessoa já familiarizada com Minecraft, tendo experimentado anteriormente todos os recursos do modo [sobrevivência]. Desta vez, a usuária explorou as características únicas do modo Hardcore.
+Após criar um novo mundo, ela notou imediatamente a diferença na interface de vida do modo Hardcore. Para explorar a mecânica de vida única desse modo, ela subiu em uma colina alta e deliberadamente caiu, esvaziando sua barra de vida. Ao fazer isso, ela percebeu que não podia retornar ao jogo no mesmo local, sendo forçada a entrar no modo espectador. Assim, sua jornada naquele mapa chegou ao fim, destacando a intensidade das consequências no modo Hardcore.
+Código | +Requisito | +Descrição | +Prioridade | +
---|---|---|---|
AP2.1 | +Vida única | +O usuário tem apenas uma vida, tornando o jogo mais desafiador e definitivo | +S | +
AP2.2 | +Modo espectador após a morte | +Após a morte, o usuário só pode entrar no modo espectador e não pode interagir mais com o mundo | +M | +
AP2.3 | +Dificuldade Fixa | +O jogo é automaticamente definido na dificuldade mais alta e não pode ser alterado | +M | +
AP2.4 | +Sem cheats | +Os comandos de cheats são desabilitados, garantindo a integridade do desafio | +S | +
Legenda - técnica de priorização:
+Relator: Samara Letícia
+Analisador: Patícia Helena
+Modo de jogo : Criativo
O método foi realizado com uma pessoa que já conhecia o minecraft, com objetivo de Criatividade e contrução
+A usuária, já experiente no jogo e com cadastro feito na plataforma, entrou no modo Criativo e [criou um novo mundo] do zero. Imediatamente, notou as diferenças da HUB em relação aos outros modos de jogo. Aproveitando a principal característica do modo Criativo, que é a capacidade de voar, ele explorou o ambiente. Ao acessar o inventário, que contém todos os itens disponíveis no jogo, decidiu iniciar um dos diversos objetivos possíveis: a construção de estruturas. Utilizando os recursos ilimitados do inventário(diferencial do modo Criativo), o usuário construiu uma casa simples como demonstração.
+Código | +Requisito | +Descrição | +Prioridade | +
---|---|---|---|
AP3.1 | +Inventário criativo | +Neste modo o inventario possui TODOS os itens do jogo | +M | +
AP3.2 | +Locomoção eficiente | +O usuário consegue sobrevoar com rapidez pelo mapa, facilitando as criações | +S | +
AP3.3 | +Blocos com mesma resistência | +O usuário consegue colocar blocos e quebra-los com apenas um comando | +S | +
AP3.4 | +Inventário completo | +Neste modo o inventario possui TODOS os itens do jogo | +M | +
AP3.5 | +Imortalidade | +O usuário não precisa se preocupar com vida nem com barra de fome neste modo, focando assim na criatividade e nao sobrevivência | +M | +
AP3.6 | +Ambiente Pacifico | +Mobs hóstis ignoram a presença do usuário | +S | +
AP3.7 | +Clima e hora do dia ajustáveis | +O usuário pode alterar o clima e a hora do dia conforme necessário para suas criações | +S | +
Legenda - técnica de priorização:
+Relator: Patrícia Helena
+Analisador: Samara Letícia
+Modo de jogo : multiplayer
O método foi realizado com uma pessoa que já conhecia o minecraft, com objetivo de socialização e cooperação
+A usuária, já experiente no jogo e com cadastro feito na plataforma, clicou na aba de multiplayer e selecionou a opção de adicionar um novo servidor. Ela inseriu o IP do servidor e rapidamente se conectou. Dentro do servidor privado, notou a quantidade de jogadores e novos recursos disponíveis, como um chat repleto de comandos e vários modos de jogos personalizados. Para testar essas funcionalidades, ela entrou em uma competição de construção, onde competiu com outros jogadores. O objetivo era escolher um tema e construir algo relacionado; a melhor construção ganhava a rodada. No início da rodada, percebeu que o modo de jogo era criativo para melhor fluidez da construção. Após alguns minutos construindo, a rodada terminou e começou a votação das construções, onde nossa usuária ficou em oitavo lugar.
+Código | +Requisito | +Descrição | +Prioridade | +
---|---|---|---|
AP4.1 | +Suporte para Vários Jogadores | +O servidor deve suportar a conexão simultânea de múltiplos jogadores sem queda de desempenho | +M | +
AP4.2 | +Sistema de chat | +Deve haver um sistema de chat integrado para comunicação entre jogadores, com suporte a comandos especiais | +S | +
AP4.3 | +Modos de jogos personalizados | +O servidor deve permitir a criação e personalização de diversos modos de jogo, como construção, sobrevivência e PvP | +S | +
AP4.4 | +Sistema de votação | +Durante competições, deve haver um sistema de votação justo e intuitivo para escolher as melhores construções ou desempenhos | +S | +
AP4.5 | +Eventos Programados | +O servidor deve permitir a criação e agendamento de eventos e competições especiais para os jogadores | +S | +
Legenda - técnica de priorização:
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
29/07/2024 | +0.1 | +Criação do documento | +Danilo Melo, Carlos Eduardo, Patricia Helena | +
O brainstorming é uma técnica de geração de ideias que estimula a criatividade e a inovação em ambientes colaborativos, promovendo a liberdade de expressão e a ausência de críticas durante a fase inicial de propostas. Entre as abordagens, destacam-se o Brainwriting, onde os participantes escrevem suas ideias em papel, favorecendo os mais introvertidos, e o Brainstorming em Grupo, guiado por um facilitador que garante a participação equitativa de todos. Ambas as técnicas visam criar um ambiente seguro e colaborativo, onde as ideias podem ser livremente compartilhadas e desenvolvidas, resultando em soluções mais inovadoras.
+Na primeira etapa, utilizamos a técnica de Brainwriting por meio de um board no Miro, que foi dividido em quatro categorias: Elementos do Jogo, Modos de Jogo, Mecânica de Jogo e Comunidade e Multiplayer. Cada participante foi incentivado a contribuir com suas ideias em cada uma dessas categorias. A atividade foi realizada durante uma chamada no Google Meet, permitindo a colaboração em tempo real e garantindo que todos os participantes pudessem interagir e desenvolver as ideias uns dos outros.
+Elementos do Jogo | +Modos de Jogo | +Mecânicas de Jogo | +Comunidade e Multiplayer | +
---|---|---|---|
Ferramentas | +Espectador | +Exploração | +Cooperação | +
Criaturas | +Criativo | +Trocas | +Entretenimento | +
Nether | +Aventura | +Criar Mundo | +Socialização | +
Biomas | +Sobrevivência | +Mineração | +Servidores | +
Animais | +Hardcore | +Craft | +Chat | +
Minérios | ++ | Construção | +Eventos | +
Armaduras | ++ | Redstone | +Skins | +
Chefes | ++ | Combate | +Competições | +
Itens | ++ | Agricultura | +Missões | +
Poções | ++ | Encantamentos | +Mods | +
Alimentos | ++ | Criar Animal | ++ |
Estruturas | ++ | Inventário | ++ |
End | ++ | Farms | ++ |
Overworld | ++ | + | + |
Blocos | ++ | + | + |
Barcos | ++ | + | + |
Clima | ++ | + | + |
Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
31/07/2024 | +0.1 | +Criação do documento | +Danilo Melo | +
01/08/2024 | +0.2 | +Classificação dos requisitos | +Danilo Melo | +
06/09/2024 | +0.3 | +Correção de duplicata | +Carlos Eduardo | +
Introspecção é uma técnica muito rica e profunda. Consiste em entender quais propriedades o sistema deve possuir para que seja um sucesso. Demanda o Engenheiro de Requisitos imaginar o que ele gostaria, se ele tivesse que desempenhar uma dada tarefa, com os equipamentos disponíveis e demais recursos.
+Foi feita uma introspecção ao visualizar diferentes fluxos de usuários na plataforma, com base nas definições estabelecidas após o Brainstorming e definição de personas. A introspecção foi estruturada em formato de storytelling, focando nos diversos tipos de usuários da aplicação.
+Sarah deseja poder criar construções impressionantes no jogo para compartilhar com seus seguidores. Seu plano é erguer um castelo extremamente realista, um projeto que demanda uma atenção meticulosa aos detalhes e uma ampla gama de recursos do jogo. No entanto, Sarah enfrenta um desafio: sua agenda está bastante apertada, deixando-a com pouco tempo livre para se dedicar ao processo de coleta de materiais, que pode ser um dos aspectos mais demorados e tediosos da construção. Portanto, ela busca uma solução que permita a realização do projeto sem a necessidade de passar por essa fase de coleta extensiva.
+Código | +Descrição | +Prioridade | +Classificação | +
---|---|---|---|
INT1.1 | +Deve existir um modo de jogo onde o jogador possuí recursos ilimitados (Modo Criativo) | +Must | +Funcional | +
INT1.2 | +O jogador deve ser capaz de voar no Modo Criativo | +Must | +Funcional | +
INT1.3 | +O jogador deve ser capaz de remover blocos | +Must | +Funcional | +
INT1.4 | +O jogo deve ter um sistema de salvamento automático | +Must | +Não funcional | +
INT1.5 | +O jogador deve ter acesso a todos os itens de forma prática | +Must | +Funcional | +
INT1.6 | +O jogador dever ser capaz de colocar alguns blocos na hotbar | +Must | +Funcional | +
INT1.7 | +O jogador deve ser capaz de compartilhar o seu mapa com outro jogador | +Could | +Funcional | +
Após explorar diversos jogos de exploração, Arthur está em busca de uma nova experiência que combine exploração da natureza com desafios moderados. Ele deseja jogar um jogo que permita enfrentar esses desafios de maneira cooperativa com seus amigos, criando uma experiência de jogo mais envolvente e colaborativa. Além disso ele espera encontrar alguma forma de melhorar os seus itens para ficar mais forte durante sua jornada.
+Código | +Descrição | +Prioridade | +Classificação | +
---|---|---|---|
INT2.1 | +Deve existir um modo de jogo onde o jogador pode morrer (sobrevivência) | +Must | +Funcional | +
INT2.2 | +O jogador deve ter uma quantidade limitada de vida | +Must | +Funcional | +
INT2.3 | +O jogador deve ser capaz de criar ferramentas | +Must | +Funcional | +
INT2.4 | +O jogador deve ser capaz de atacar os inimigos | +Must | +Funcional | +
INT2.5 | +O jogador deve ser capaz de escolher a dificuldade do jogo | +Should | +Funcional | +
INT2.6 | +Um jogador deve ser capaz de entrar no mundo de outro jogador | +Should | +Funcional | +
INT2.7 | +O jogador deve ser capaz de acessar o chat | +Should | +Funcional | +
INT2.8 | +O mundo deve ser gerado com diversos biomas | +Must | +Funcional | +
INT2.9 | +O jogador deve ser capaz de melhorar o material dos seus itens | +Must | +Funcional | +
INT2.10 | +O jogador deve ser capaz de encantar os seus itens | +Should | +Funcional | +
INT2.11 | +Quando um inimigo morrer ele deve deixar um drop | +Must | +Funcional | +
INT2.12 | +O jogador deve ter uma barra de fome | +Must | +Funcional | +
Victor é apaixonado por jogos que oferecem um alto nível de dificuldade, sempre buscando se desafiar ao conquistar todas as conquistas disponíveis. Por isso, ele espera que o jogo ofereça um modo mais desafiador, com inimigos progressivamente mais poderosos. Além disso, ele deseja um sistema de conquistas robusto, que torne os desafios ainda mais dinâmicos e estimulantes.
+Código | +Descrição | +Prioridade | +Classificação | +
---|---|---|---|
INT3.1 | +Deve existir um modo de jogo onde o jogador pode morrer permanentemente(Hardcore) | +Should | +Funcional | +
INT3.2 | +Cada dimensão deve ter diferentes inimigos | +Must | +Funcional | +
INT3.3 | +Devem existir inimigos de diferentes dificuldades | +Should | +Funcional | +
INT3.4 | +O jogo deve apresentar um sistema de conquistas | +Should | +Funcional | +
INT3.5 | +O jogador deve poder acessar o sistema de conquistas a qualquer momento | +Should | +Funcional | +
INT3.6 | +O jogador deve ser capaz de compartilhar suas conquistas com outras pessoas | +Won't | +Funcional | +
INT3.7 | +O jogo deve possuir chefes | +Must | +Funcional | +
Slide Requisitos Aula 7 - Milene Serrano e Maurício Serrano
+ + + + + + + + + + + + + +Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
26/07/2024 | +0.1 | +Criação do documento | +Danilo Melo, Patricia Helena, Carlos Eduardo | +
01/08/2024 | +0.2 | +Adição da transcrição | +Danilo Melo | +
A técnica MoSCoW é uma metodologia de priorização utilizada em gerenciamento de projetos, especialmente em desenvolvimento de software. MoSCoW é um acrônimo que representa quatro categorias de priorização:
+A técnica MoSCoW ajuda equipes a gerenciar recursos de forma eficaz, assegurando que as partes mais críticas do projeto sejam concluídas primeiro e proporcionando uma forma clara de comunicar prioridades aos stakeholders.
+Para aplicar essa técnica, utilizamos um quadro na ferramenta Miro e realizamos uma reunião via Google Meet. Em seguida, usamos as informações obtidas durante o brainstorming para dividir os elementos nas quatro categorias do MoSCoW.
+Must Have | +Should Have | +Could Have | +Won't Have | +
---|---|---|---|
Modo sobrevivência | +Dimensões | +Mini-games | +Carros | +
Blocos básicos | +Sistema de redstone | +Skins | +Estações do ano | +
Sistema de inventário | +Diversidade de mobs | +Mods | +Narrativa extensa | +
Construção | +Diversidade de Minérios | +Shaders | +Pay to win | +
Criação de mundos | +Encantamentos | +Sistemas Automáticos | +Realismo excessivo | +
Mobs básicos | +Biomas | +Atualizações temáticas | +Conteúdo Violento | +
Sistema de craft | +Chefes | +Interação com os NPCs | +Linearidade | +
Exploração | +Agricultura | +Móveis | +Conteúdos pagos exclusivos | +
https://rockcontent.com/br/blog/metodo-moscow/
+ + + + + + + + + + + + + +Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
01/08/2024 | +0.1 | +Criação do documento inicial e adição da introdução e SWOT do modo Sobrevivência | +Patrícia Helena | +
01/08/2024 | +0.2 | +SWOT do modo Sobrevivência | +Patrícia Helena | +
01/08/2024 | +0.3 | +SWOT do modo Hardcore | +Patrícia Helena | +
01/08/2024 | +0.4 | +SWOT do modo Criativo | +Patrícia Helena | +
01/08/2024 | +1.0 | +SWOT do modo Multiplayer | +Patrícia Helena | +
A análise SWOT ajuda a desenvolver estratégias eficazes ao fornecer uma visão clara dos pontos fortes e fracos internos, bem como das oportunidades e ameaças externas.
+A análise SWOT é uma ferramenta de planejamento estratégico usada para identificar e avaliar os aspectos internos e externos que podem impactar um projeto, negócio ou iniciativa. O termo "SWOT" é um acrônimo que representa quatro elementos:
++ | Interno | +Externo | +
---|---|---|
Positivo | +Forças | +Oportunidades | +
+ | - Comunidade ampla | +- Crescente popularidade dos jogos online | +
+ | - Alta personalização e mods | +- Expansão em mercados emergentes | +
+ | - Facilidade de criação de servidores | +- Colaborações e parcerias com outras marcas | +
+ | - Grande variedade de modos de jogo | +- Desenvolvimento de novas tecnologias de jogo | +
Negativo | +Fraquezas | +Ameaças | +
+ | - Problemas de latência em servidores | +- Concorrência de outros jogos multiplayer | +
+ | - Complexidade na configuração inicial | +- Problemas de segurança e hacking | +
+ | - Necessidade de moderação ativa | +- Mudanças nas preferências dos jogadores | +
+ | - Dependência de terceiros para servidores | ++ |
+ | Interno | +Externo | +
---|---|---|
Positivo | +Forças | +Oportunidades | +
+ | - Experiência de jogo desafiadora | +- Crescente interesse em jogos de sobrevivência | +
+ | - Grande sensação de progresso | +- Potencial para novas expansões e DLCs | +
+ | - Diversidade de biomas e recursos | +- Desenvolvimento de novas mecânicas de jogo | +
+ | - Sistema de crafting profundo | ++ |
Negativo | +Fraquezas | +Ameaças | +
+ | - Pode ser frustrante para novatos | +- Concorrência de outros jogos de sobrevivência | +
+ | - Dependência de tempo para progresso | +- Problemas técnicos e bugs | +
+ | - Repetitividade a longo prazo | +- Cair na monotonia | +
+ | - Necessidade de gerenciamento de recursos | +- Possíveis problemas de balanceamento | +
+ | Interno | +Externo | +
---|---|---|
Positivo | +Forças | +Oportunidades | +
+ | - Alta intensidade e desafio | +- Comunidade de jogadores hardcore crescente | +
+ | - Grande senso de realização | +- Torneios e competições de sobrevivência | +
+ | - Modo de jogo para jogadores experientes | +- Desenvolvimento de novas mecânicas extremas | +
+ | - Permanente, aumenta a tensão | ++ |
Negativo | +Fraquezas | +Ameaças | +
+ | - Alto risco de frustração | +- Perda de jogadores devido à dificuldade | +
+ | - Menor acessibilidade para iniciantes | +- Bugs ou problemas técnicos que podem prejudicar a experiência | +
+ | - Falta de novos objetivos a longo prazo | +- Concorrência com outros jogos de alta dificuldade | +
+ | - Alto impacto de erros ou falhas | +- Mudanças nas preferências de jogos dos jogadores | +
+ | Interno | +Externo | +
---|---|---|
Positivo | +Forças | +Oportunidades | +
+ | - Liberdade total para criação | +- Expansão em plataformas educacionais | +
+ | - Acesso a todos os recursos do jogo | +- Potencial para colaborações com artistas e designers | +
+ | - Ideal para construção e design | +- Desenvolvimento de novas ferramentas de construção | +
+ | - Ambiente pacífico e sem hostilidade | ++ |
Negativo | +Fraquezas | +Ameaças | +
+ | - Pode ser menos desafiador | +- Concorrência com outras plataformas de construção | +
+ | - Falta de objetivos específicos | +- Possíveis problemas de direitos autorais com criações | +
+ | - Dependência de criatividade do jogador | +- Mudanças nas tendências e preferências dos jogadores | +
+ | - Potencial para tédio a longo prazo | +- Problemas técnicos que afetam a construção | +
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
20/08/2024 | +0.0.1 | +Criação e divulgação do questionário | +Carlos Eduardo e Samara Letícia | +
21/08/2024 | +0.1 | +Pesquisa e criação do documento | +Carlos Eduardo | +
Este documento tem como objetivo apresentar os resultados de uma pesquisa exploratória realizada tanto na internet quanto através de questionários aplicados aos jogadores. A finalidade principal foi conduzir uma engenharia reversa, visando identificar funcionalidades recentemente adicionadas ao jogo, além de entender as percepções e opiniões dos jogadores sobre essas novas atualizações.
+A pesquisa foi divulgada em grupos de jogadores de minecraft no Discord e facebook.
+As pesquisas realizadas permitiram identificar diversas atualizações que foram bastante aguardadas pela comunidade e que introduziram novas funcionalidades ao jogo.
+Os aldeões receberam uma reformulação, com novas dinâmicas e profissões. Além disso, foram introduzidos os Pillagers, inimigos dos Villagers, que representam uma nova ameaça às vilas.
+Muito solicitada pela comunidade, a Atualização Aquática trouxe novos biomas oceânicos, introduziu novas dinâmicas e desafios, e adicionou vida marinha ao jogo. Novos mobs, um novo Boss, e o Templo do Oceano foram implementados, criando um desafio novo para os jogadores.
+Esta atualização introduziu novos mobs, estruturas, e três novos biomas ao Nether. A exploração do submundo se tornou mais frequente com a introdução de novas mecânicas e desafios.
+Trouxe várias novidades, principalmente focadas em novas funcionalidades e blocos relacionados a cavernas e montanhas. Algumas das novidades:
+Uma das adições desta atualização foi a Câmara do Julgamento, onde os jogadores enfrentam hordas temporárias de inimigos gerados por spawners. Ao superar esse novo tipo de desafio, os jogadores são recompensados.
+Outras importantes adições:
+Sabemos que muitas pessoas não gostam de responder questionários, especialmente quando são longos. Com isso em mente, foi criado um questionário curto, com apenas três perguntas, mas que o grupo julgou ser suficientes para o propósito.
+O formulário foi divido em duas seções:
+Confira as respostas do questionário aqui.
+Com base no questionário e na pesquisa realizada, abaixo estão os requisitos identificados.
+Código | +Descrição | +
---|---|
QP1 | +Deve haver novos blocos decorativos para expandir as opções de construção e paisagismo. | +
QP2 | +Devem ser adicionados novos biomas e ruínas para exploração. | +
QP3 | +Deve haver armaduras para que possam proteger os lobos durante o jogo. | +
QP4 | +Deve ser adicionada uma nova arma de dano em área para facilitar combates enfrentando múltiplos inimigos de uma só vez | +
QP5 | +Deve haver a inclusão de novos biomas do Nether, adicionando desafios para incentivar a exploração do submundo. | +
QP6 | +Deve ser introduzido um telescópio, permitindo aos jogadores maior alcance de visão. | +
QP7 | +Deve ser melhorada a dinâmica de interação com aldeões, com novas profissões e comportamentos | +
QP8 | +Deve haver mais opções de personalização para mobs de estimação. | +
QP9 | +Deve haver um sistema de crafting automático, que permita aos jogadores automatizar processos. | +
QP10 | +Deve haver vida marinha, incluindo novos mobs desafiadores. | +
QP11 | +Deve haver mais atualizações focadas em cavernas e montanhas, expandindo os blocos e recursos disponíveis. | +
QP12 | +Deve haver a inclusão do minério de cobre. | +
QP13 | +Nova mecânica de defesa contra raios, com a introdução de blocos como o para-raios. | +
QP14 | +Deve ser incluídos novos mobs de animais. | +
QP15 | +Novo sistema de iluminação, com lâmpadas de cobre. | +
QP16 | +Deve haver novas estruturas geradas como masmorras subterrâneas, com novos desafios e recompensas. | +
QP17 | +Deve haver novos inimigos | +
QP18 | +Novos eventos e desafios temporários com recompensas exclusivas | +
Adegilson. Minecraft: Seria a atualização 1.21 a maior desde o update do Nether?. Acesso em: ago de 2024. Disponível em: https://nationpop.com.br/seria-a-atualizacao-1-21-a-maior-desde-o-update-do-nether/
+
Boddy, ZACHARY. The Minecraft 1.21 update is official, with automated crafting, trial dungeons, and a brand-new mob. Acesso em: ago de 2024. Disponível em: https://www.windowscentral.com/gaming/minecraft/the-minecraft-121-update-is-official-with-automated-crafting-trial-dungeons-and-a-brand-new-mob
+
+
Boddy, ZACHARY. Minecraft 1.21 'Tricky Trials Update' FAQ: Release date, features, mobs, snapshots, and other questions answered. Acesso em: ago de 2024. Disponível em: https://www.windowscentral.com/gaming/minecraft/minecraft-1-21-update-faq
+
+
Minecraft Wiki. Edição Java 1.17. Acesso em: ago de 2024. Disponível em: https://minecraft.fandom.com/pt/wiki/Edi%C3%A7%C3%A3o_Java_1.17
+
+
Histórico de Revisão
+Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
21/08/2024 | +0.1 | +Criação do documento | +Carlos Eduardo | +
08/09/2024 | +0.2 | +Atualizando a tabela | +Danilo Melo | +
Abaixo estão reunidos os requisitos que foram observados no minecraft a respeito da qualidade do sistema, como desempenho, segurança e usabilidade. Estes requisitos ajudam a garantir que o jogo ofereça uma experiência de usuário satisfatória.
+Categoria | +Código | +Requisito | +
---|---|---|
Desempenho | +RNF1 | +O jogo deve ter um tempo de resposta rápido para ações dos jogadores, como movimentação e interação com blocos. | +
Desempenho | +RNF2 | +O jogo deve minimizar a latência de rede para garantir uma experiência de jogo suave em modos multiplayer. | +
Desempenho | +RNF3 | +O chat deve funcionar de forma fluida e sem atrasos perceptíveis. | +
Desempenho | +RNF4 | +Deve haver opções para ajustar a qualidade gráfica, incluindo resolução, distância de renderização e efeitos visuais. | +
Segurança | +RNF5 | +O jogo deve ter mecanismos para proteger as contas dos jogadores contra acessos não autorizados. | +
Usabilidade | +RNF6 | +A interface do usuário deve ser intuitiva e fácil de navegar. | +
Usabilidade | +RNF7 | +O jogo deve fornecer feedback visual e auditivo claro para as ações dos jogadores. | +
Usabilidade | +RNF8 | +O jogador deve ser capaz de personalizar atalhos de teclado e controles. | +
Usabilidade | +RNF9 | +O jogo deve incluir um sistema de ajuda relevante durante a gameplay. | +
Compatibilidade | +RNF10 | +O jogo deve ser compatível com diferentes plataformas como PC, consoles e dispositivos móveis. | +
Compatibilidade | +RNF11 | +Deve haver suporte para diferentes resoluções e configurações de gráficos. | +
Compatibilidade | +RNF12 | +O jogo deve oferecer suporte a mods e plugins em diferentes plataformas. | +
Requisitos Adicionais | +RNF13 | +O jogo deve suportar múltiplos idiomas. | +
Requisitos Adicionais | +RNF14 | +O jogo deve permitir a personalização de skins e pacotes de textura. | +
Requisitos Adicionais | +RNF15 | +O menu de pausa deve ser acessível durante o jogo e deve permitir que os jogadores acessem as configurações ou saiam do jogo facilmente. | +
Requisitos Adicionais | +RNF16 | +O jogo deve permitir que os jogadores personalizem os controles de entrada de acordo com suas preferências. | +
Requisitos Adicionais | +RNF17 | +O jogo deve permitir aos jogadores ajustar o volume do som e da música separadamente. | +
Requisitos Adicionais | +RNF18 | +O jogo deve ter um sistema de salvamento automático para evitar perda de progresso. | +
Data | +Versão | +Descrição | +Autor(es) | +
---|---|---|---|
06/09/2024 | +0.1 | +Criação do documento inicial e adição dos RF1 a RF23 e RNF1 | +Carlos Eduardo Rodrigues | +
07/09/2024 | +0.2 | +Adição RF24 a RF52 e RNF2 | +Carlos Eduardo Rodrigues | +
08/09/2024 | +0.3 | +Adição RF53 | +Carlos Eduardo Rodrigues | +
09/09/2024 | +0.4 | +Adição RF54 a RF60 e RNF3 a RNF25 | +Danilo Melo | +
09/09/2024 | +0.5 | +Adição RF61 | +Carlos Eduardo Rodrigues | +
Código | +Requisito | +Técnica(s) | +
---|---|---|
RF1 | +O usuário deve ser capaz de criar, entrar e gerenciar uma conta no Minecraft. | +Análise de Protocolo | +
RF2 | +O usuário deve ser capaz de se locomover utilizando o teclado. | +Análise de Protocolo | +
RF3 | +O usuário deve ser capaz de interagir com o mundo utilizando o mouse. | +Análise de Protocolo | +
RF4 | +Os recursos devem ser armazenados no inventário do usuário. | +Análise de Protocolo, Brainstorming, MoSCoW, Introspeccao | +
RF5 | +O jogo deve possuir um dicionário com a explicação de todos os itens descobertos pelo usuário. | +Análise de Protocolo | +
RF6 | +O usuário deve precisar de uma mesa de trabalho para fabricar ferramentas eficientes. | +Análise de Protocolo | +
RF7 | +O jogo deve permitir que, através de minérios, o usuário crie novas ferramentas. | +Análise de Protocolo, Brainstorming, MoSCoW | +
RF8 | +O jogo deve oferecer diferentes tipos de alimentos para evitar que o personagem do usuário morra de fome. | +Análise de Protocolo, Brainstorming | +
RF9 | +No modo hardcore, o usuário deve ter apenas uma vida, tornando o jogo mais desafiador e definitivo. | +Análise de Protocolo, Introspeccao | +
RF10 | +No modo hardcore, após a morte, o usuário deve ser capaz de entrar apenas no modo espectador, sem interagir com o mundo. | +Análise de Protocolo | +
RF11 | +No modo hardcore, o jogo deve ser definido automaticamente na dificuldade mais alta e não pode ser alterado. | +Análise de Protocolo | +
RF12 | +No modo hardcore, os comandos de cheats devem estar desabilitados para garantir a integridade do desafio. | +Análise de Protocolo | +
RF13 | +Deve existir um modo de jogo onde o jogador pode exercitar a sua criatividade | +Análise de protocolo | +
RF14 | +No modo criativo, o usuário deve ser capaz de sobrevoar rapidamente pelo mapa para facilitar as criações. | +Análise de Protocolo, Introspeccao | +
RF15 | +O usuário deve ser capaz de colocar e quebrar blocos com apenas um comando no modo criativo. | +Análise de Protocolo, Introspeccao | +
RF16 | +O usuário deve ter acesso a todos os itens do jogo no modo criativo. | +Análise de Protocolo, Introspeccao | +
RF17 | +O usuário não deve precisar se preocupar com vida ou barra de fome no modo criativo, focando apenas em criar. | +Análise de Protocolo | +
RF18 | +Mobs hostis devem ignorar a presença do usuário no modo criativo. | +Análise de Protocolo | +
RF19 | +No modo criativo, usuário deve ser capaz de alterar o clima e a hora do dia conforme necessário para suas criações. | +Análise de Protocolo | +
RF20 | +Deve haver um sistema de chat para comunicação entre os jogadores, com suporte a comandos especiais. | +Análise de Protocolo, Brainstorming, Introspeccao | +
RF21 | +Jogos multiplayer devem permitir a criação e personalização de diversos modos de jogo, como construção, sobrevivência e PvP. | +Análise de Protocolo, Brainstorming | +
RF22 | +Jogos multiplayer devem fornecer um sistema de votação justo e intuitivo durante competições para escolher as melhores construções ou desempenhos. | +Análise de Protocolo, Brainstorming | +
RF23 | +Em Jogos multiplayer deve ser possível a criação e agendamento de eventos e competições especiais para os jogadores. | +Análise de Protocolo | +
RF24 | +O jogador dever ser capaz de colocar alguns blocos na hotbar. | +Introspeccao | +
RF25 | +O jogador deve ser capaz de compartilhar o seu mapa com outro jogador. | +Introspeccao | +
RF26 | +Deve existir um modo de jogo onde o jogador pode morrer (sobrevivência) | +Introspeccao, Brainstorming, MoSCoW | +
RF27 | +Com exceção dos modos Criativo e Espectador, o jogador deve ter uma quantidade limitada de vida | +Introspeccao | +
RF28 | +O jogador deve ser capaz de criar ferramentas | +Introspeccao | +
RF29 | +O jogador deve ser capaz de atacar os inimigos | +Introspeccao | +
RF30 | +Com exceção do modo hardcore, o jogador deve ser capaz de escolher a dificuldade do jogo | +Introspeccao | +
RF31 | +O mundo deve ser gerado com diversos biomas | +Introspeccao | +
RF32 | +O jogador deve ser capaz de melhorar o material dos seus itens | +Introspeccao | +
RF33 | +O jogador deve ser capaz de encantar os seus itens | +Introspeccao | +
RF34 | +Quando um inimigo morrer ele deve deixar um drop | +Introspeccao | +
RF35 | +O jogador deve ter uma barra de fome | +Introspeccao | +
RF36 | +Cada dimensão deve ter diferentes inimigos | +Introspeccao, Questionário | +
RF37 | +Devem existir inimigos de diferentes dificuldades | +Introspeccao | +
RF38 | +O jogo deve apresentar um sistema de conquistas | +Introspeccao | +
RF39 | +O jogador deve poder acessar o sistema de conquistas a qualquer momento | +Introspeccao | +
RF40 | +O jogador deve ser capaz de compartilhar suas conquistas com outros jogadores | +Introspeccao | +
RF41 | +O jogo deve possuir chefes | +Introspeccao | +
RF42 | +Deve haver blocos decorativos para expandir as opções de construção e paisagismo. | +Questionário | +
RF43 | +Deve haver ruínas, cavernas, montanhas e masmorras subterrâneas, com desafios e recompensas para que os jogadores realizem explorações. | +Questionário | +
RF44 | +Deve haver armaduras para os jogadores e seus animais de combate. | +Questionário | +
RF45 | +Deve haver armas de dano em área para facilitar combates enfrentando múltiplos inimigos de uma só vez | +Questionário | +
RF46 | +Os biomas do Nether, devem possuir desafios e recompensas únicas para incentivar a exploração do submundo. | +Questionário | +
RF47 | +Deve haver mobs pacíficos com profissões | +Questionário | +
RF48 | +Os jogadores devem ser capazes de personalizar os seus mobs de estimação. | +Questionário | +
RF49 | +Deve haver um sistema de crafting automático, que permita aos jogadores automatizar processos. | +Questionário | +
RF50 | +Deve haver diferentes tipos de minérios e recursos | +Questionário | +
RF51 | +Deve haver diferentes tipos de mobs de animais. | +Questionário | +
RF52 | +Deve haver eventos e desafios temporários com recompensas exclusivas | +Questionário | +
RF53 | +O jogador deve ser capaz de criar novos mundos no minecraft | +Brainstorming, Análise de protocolo | +
RF54 | +Deve haver uma interface intuitiva | +NFR | +
RF55 | +Deve haver opções de acessibilidade | +NFR | +
RF56 | +Deve haver dicas contextuais | +NFR | +
RF57 | +Deve haver opções de legenda | +NFR | +
RF58 | +Deve haver opção de narração | +NFR | +
RF59 | +Deve haver opção de altocontraste | +NFR | +
RF60 | +Deve haver temas e pacotes de recursos | +NFR | +
RF61 | +Deve haver uma barra indicando o nível da armadura | +Brainstorming, Questionário | +
Código | +Requisito | +Técnica(s) | +
---|---|---|
RNF1 | +O servidor deve suportar a conexão simultânea de múltiplos jogadores sem queda de desempenho. | +Análise de Protocolo | +
RNF2 | +O jogo deve ter um sistema de salvamento automático | +Introspeccao | +
RNF3 | +Deve haver compatibilidade entre diferentes dispositivos | +NFR | +
RNF4 | +A latência entre os jogadores e a resposta do servidor deve ser mínima | +NFR | +
RNF5 | +Um servidor deve limitar a capacidade máxima de jogadores | +NFR | +
RNF6 | +O mapa deve ser carregado de acordo com o campo de visão do jogador | +NFR | +
RNF7 | +O jogo deve ter um tempo de resposta rápido para ações dos jogadores, como movimentação e interação com blocos. | +Requisitos não funcionais | +
RNF8 | +O jogo deve minimizar a latência de rede para garantir uma experiência de jogo suave em modos multiplayer. | +Requisitos não funcionais | +
RNF9 | +O chat deve funcionar de forma fluida e sem atrasos perceptíveis. | +Requisitos não funcionais | +
RNF10 | +Deve haver opções para ajustar a qualidade gráfica, incluindo resolução, distância de renderização e efeitos visuais. | +Requisitos não funcionais | +
RNF11 | +O jogo deve ter mecanismos para proteger as contas dos jogadores contra acessos não autorizados. | +Requisitos não funcionais | +
RNF12 | +A interface do usuário deve ser intuitiva e fácil de navegar. | +Requisitos não funcionais | +
RNF13 | +O jogo deve fornecer feedback visual e auditivo claro para as ações dos jogadores. | +Requisitos não funcionais | +
RNF14 | +O jogador deve ser capaz de personalizar atalhos de teclado e controles. | +Requisitos não funcionais | +
RNF15 | +O jogo deve incluir um sistema de ajuda relevante durante a gameplay. | +Requisitos não funcionais | +
RNF16 | +O jogo deve ser compatível com diferentes plataformas como PC, consoles e dispositivos móveis. | +Requisitos não funcionais | +
RNF17 | +Deve haver suporte para diferentes resoluções e configurações de gráficos. | +Requisitos não funcionais | +
RNF18 | +O jogo deve oferecer suporte a mods e plugins em diferentes plataformas. | +Requisitos não funcionais | +
RNF19 | +O jogo deve suportar múltiplos idiomas. | +Requisitos não funcionais | +
RNF20 | +O jogo deve permitir a personalização de skins e pacotes de textura. | +Requisitos não funcionais | +
RNF21 | +O menu de pausa deve ser acessível durante o jogo e deve permitir que os jogadores acessem as configurações ou saiam do jogo facilmente. | +Requisitos não funcionais | +
RNF22 | +O jogo deve permitir que os jogadores personalizem os controles de entrada de acordo com suas preferências. | +Requisitos não funcionais | +
RNF23 | +O jogo deve permitir aos jogadores ajustar o volume do som e da música separadamente. | +Requisitos não funcionais | +
RNF24 | +O jogo deve ter um sistema de salvamento automático para evitar perda de progresso. | +Requisitos não funcionais | +
RNF25 | +Deve ser possível desativar o salvamento automático | +NFR | +