Planejamento da Verificação
Introdução
O seguinte documento tem como objetivo realizar uma análise criteriosa dos artefatos entregues pelo Grupo 7, a fim de identificar possíveis pontos de melhoria em seu projeto. Esta verificação visa contribuir para o aprimoramento da qualidade e eficiência do trabalho desenvolvido pela referida equipe, não sendo o propósito depreciar ou menosprezar suas realizações. Utilizando uma abordagem baseada em fundamentos acadêmicos, buscar-se-á uma avaliação minuciosa dos elementos apresentados, com o intuito de fornecer recomendações construtivas e embasadas para otimização do projeto. Nesse contexto, valoriza-se o esforço empreendido pelo Grupo 7 e reconhece-se a importância desse processo de verificação para o aprimoramento contínuo do trabalho desenvolvido.
Metodologia
Para realizar a verificação dos artefatos entregues pelo Grupo 7, será adotada a metodologia de verificação proposta por Michael Fagan na IBM, amplamente reconhecida na área de engenharia de software. Essa abordagem consiste na aplicação de checklists estruturados, os quais são criados com base nos requisitos, padrões e melhores práticas estabelecidos para o projeto em questão. Os checklists são listas de verificação que contêm uma série de critérios a serem avaliados para cada artefato, abrangendo aspectos como coerência, completude, consistência, conformidade com as especificações, entre outros [1]. Através dessa metodologia, busca-se uma verificação sistemática e abrangente dos artefatos, proporcionando uma análise estruturada e objetiva, com o intuito de identificar possíveis falhas, lacunas ou áreas que demandam aprimoramento. A aplicação dos checklists permitirá uma avaliação consistente e padronizada, contribuindo para uma análise mais precisa e fundamentada dos artefatos entregues pelo Grupo 7.
A seguir será apresentado os checklists feitos para a avaliação dos artefatos de cada etapa.
Etapa 1
Checklist Etapa 1 |
---|
Substituir pela pergunta |
Tabela 1: Checklist da Etapa 1 (Fonte: Arthur,2023)
Etapa 2
Na tabela 3 - Perfil de Usuário
Número | Pergunta | Resposta |
---|---|---|
1 | Os dados foram obtidos por meio de pesquisas, entrevistas, observação ou análise de dados existentes? | Sim |
2 | Os usuários foram agrupados em segmentos com base em características comuns? | Sim |
3 | Foram criadas personas fictícias que representem perfis típicos de usuários, com base nas informações coletadas | Sim |
4 | As porcentagens de usuários em cada segmento foram determinadas? | Sim |
Na tabela 4 - Personas
Número | Pergunta | Resposta |
---|---|---|
5 | Foram identificados os objetivos e as tarefas que os usuários desejam realizar ao interagir com o sistema ou produto? | Sim |
6 | As personas contém Nome, Idade, Gênero, Status, Objetivos, Habilidades, Relacionamentos, Requisitos e Expectativas? | Sim |
7 | Possui entre 3 a 12 personas? | Sim |
8 | Possui justificativa do número de personas? | Sim |
9 | Possui uma antipersona? | Sim |
Na tabela 5 - Brainstorming
Número | Pergunta | Resposta |
---|---|---|
10 | Possui local, data e horário da reunião de Brainstormig? | Sim |
11 | Está especificado o papel de cada participante do Brainstorming? | Não |
12 | Foram utilizadas técnicas para incentivar a geração de ideias?(palavras-chave, imagens ou diagramas) | Não |
Na tabela 7 - Storytelling
Número | Pergunta | Resposta |
---|---|---|
13 | Os registros da atividade de priorização dos requisitos foram adequadamente documentados? | sim |
14 | As histórias conseguem comunicar claramente a visão e as necessidades dos usuários para os membros da equipe de desenvolvimento? | sim |
15 | O Storytelling incorpora elementos emocionais e contextuais para criar empatia e compreensão dos usuários e suas necessidades? | sim |
16 | O Storytelling aborda as restrições e limitações do sistema, fornecendo informações importantes para a equipe de desenvolvimento considerar durante a implementação? | não |
17 | As histórias do Storytelling foram validadas e verificadas por meio de revisões e feedback dos stakeholders relevantes para garantir sua precisão e adequação? | não |
Na tabela 8 - Escala de três níveis
Número | Pergunta | Resposta |
---|---|---|
18 | A priorização levou em consideração os critérios importância e urgência? | sim |
19 | Os níveis de priorização foram divididos em Alta, Média e Baixa? | sim |
20 | O modelo de quadrante utilizado para classificar os requisitos foi visualmente intuitivo e facilmente compreensível para os stakeholders? | sim |
21 | As dependências entre requisitos foram consideradas no processo de ranqueamento e priorização, garantindo que requisitos dependentes tenham prioridades consistentes? | sim |
Na tabela 9 - MosCow
Número | Pergunta | Resposta |
---|---|---|
22 | Cada requisito foi adequadamente classificado como Must Have (Deve ter), Should Have (Deveria ter), Could Have (Poderia ter) ou Won't Have (Não terá)? | sim |
23 | A participação do cliente e/ou personas foi ativamente envolvida no processo de priorização, garantindo que suas perspectivas e necessidades sejam consideradas? | sim |
24 | Foi realizada uma revisão cuidadosa para garantir que nenhum requisito importante tenha sido negligenciado ou erroneamente classificado, evitando a exclusão indevida de requisitos essenciais? | sim |
25 | Os requisitos classificados como Won't Have (Não terá) foram revisados e justificados adequadamente, assegurando que a exclusão desses requisitos não afete negativamente o escopo e os objetivos do projeto? | sim |
Na tabela 10 - Baseada em valor, custo e risco
Número | Pergunta | Resposta |
---|---|---|
26 | Foram priorizados os requisitos com base no valor que eles agregam ao negócio? | sim |
27 | Foram priorizados aqueles que ajudam a mitigar os riscos mais críticos ou que possuem menor nível de incerteza? | sim |
28 | Foram priorizados aqueles com maior ROI ou benefícios mais significativos? | não |
29 | Foi considerado o impacto dos requisitos na satisfação e na experiência do cliente. | sim |
30 | Foi considerada a complexidade e a interdependência dos requisitos. Priorizar aqueles que são mais simples e independentes, permitindo uma entrega mais rápida e uma menor probabilidade de erros ou atrasos. | sim |
Etapa 3
Checklist Etapa 3 |
---|
Substituir pela pergunta |
Tabela 3: Checklist da Etapa 3 (Fonte: Débora,2023)
Etapa 4
Os seguintes checklists de verificação foi criado por meio do estudo das referências utilizadas para a construção dos artefatos da quarta etapa do Grupo 7. As perguntas de número 1, 14, 23 e 24 foram baseadas no plano de ensino da matéria de Requisitos de software. As perguntas 2 à 12 foram baseadas no livro Engenharia de Requisitos da Sheila Reinehr, enquanto as de 18 à 22 foram baseadas na dissertação "NFR4ES: Um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados" de Reinaldo Antônio. As demais foram feitas pelo avaliador Natan Tavares Santana. Os resultados da execução da verificação de acordo com esse checklist pode ser verificada nesse link.
Histórias de Usuário
A tabela 4 a seguir possui as perguntas do checklist que será utilizado para fazer a verificação do artefato de Histórias de Usuário.
Número | Pergunta |
---|---|
1 | As histórias de usuário seguem o padrão de voz de usuário?³ |
2 | As histórias de usuário estão escritas em primeira pessoa de acordo com o modelo de voz do usuário?³ |
3 | As histórias de usuário possui o papel (quem) de acordo com o modelo de voz de usuário?³ |
4 | As histórias de usuário possui a ação (o que) de acordo com o modelo de voz de usuário?³ |
5 | As histórias de usuário possui o resultado da ação ou o valor de negócio (porque) de acordo com o modelo de voz de usuário?³ |
6 | Nas história de usuário, o papel representa quem se beneficiará da funcionalidade, e não quem está solicitando a funcionalidade?³ |
7 | Nas histórias de usuário, é usado um termo representando o perfil em vez do termo genérico "usuário"?³ |
8 | É explicado o papel dos stakeholders quanto a criação e/ou validação das histórias de usuário? (Autoria Própria) |
9 | Todas as histórias de usuário são independentes?³ |
10 | As histórias de usuária foram validadas como negociáveis e valiosas pelo PO?³ |
11 | As histórias de usuário aparentam ser estimáveis e pequenas de modo que poderiam ser alocados à uma sprint?³ |
12 | As histórias de usuário possuem critérios de aceitação os quais permitem que elas sejam testáveis?³ |
Tabela 4: Checklist de verificação do artefato "Histórias de Usuário" (Fonte: Natan,2023)
Backlog
A tabela 5 a seguir possui as perguntas do checklist que será utilizado para fazer a verificação do artefato de Backlog.
Número | Pergunta |
---|---|
13 | Foi usado uma metodologia para a construção do backlog?⁴ |
14 | É explicado como a metodologia DEEP foi utilizada no backlog? (Autoria Própria) |
15 | O backlog possui épicos e temas bem definidos e descritos?⁴ |
16 | O PO participou da construção e/ou da validação do backlog?⁴ |
17 | Foi documentado se o PO pediu alguma mudança no backlog? (Autoria Própria) |
Tabela 5: Checklist de verificação do artefato "Backlog" (Fonte: Natan,2023)
NFR Framework
A tabela 6 a seguir possui as perguntas do checklist que será utilizado para fazer a verificação do artefato de NFR Framework.
Número | Pergunta |
---|---|
18 | Os softgoals NFR representam requisitos não-funcionais?² |
19 | Os softgoals de operacionalização representam soluções de implementação para satisfazer softgoals NFR ou outros softgoals de operacionalização?² |
20 | Os softgoal de afirmação fornecem as razões para as decisões de desenvolvimento?² |
21 | Os softgoals NFR possuem um tipo e pode possuir um ou mais tópicos?² |
22 | Os tipos de contribuição seguem as definições apresentada na dissertação "NFR4ES: Um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados"?² |
23 | Os impactos foram corretamente propagados?⁴ |
24 | Foi construído cartões de especificação de acordo com o modelo apresentado na dissertação "NFR4ES: Um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados" ou de alguma outra referência?⁴ |
25 | Os diagramas documentados estão legíveis? (Autoria Própria) |
Tabela 6: Checklist de verificação do artefato "NFR Framework" (Fonte: Natan,2023)
Referência bibliográfica
- [1] Gerência e Qualidade de Software - Aula 06 - Técnica de revisão, Fábio Levy Siqueira. Disponível em: https://www.youtube.com/watch?v=nA1BVDd9GUE- Acesso em 12/06/2023
- [2] SILVA, Reinaldo Antônio da. NFR4ES:Um Catálogo de Requisitos Não-Funcionais para Sistemas Embarcados. Recife, 2019. Disponível em: https://repositorio.ufpe.br/handle/123456789/34150#:~:text=Neste%20trabalho%20foi%20desenvolvido%20um,n%C3%A3o%2Dfuncionais%20em%20sistemas%20embarcados./ Lido em: 12 jun. 2023.
- [3] REINEHR, Sheila. Engenharia de Requisitos. Porto Alegre: Sagah, 2020. Lido em: 12 jun. 2023.
- [4] SALES, André Barros. Plano de ensino da disciplina. Disponível em: https://aprender3.unb.br. Acesso em: 16 de junho de 2023.
Tabela de Versionamento
Data | Versão | Descrição | Autor | Revisor |
---|---|---|---|---|
12/06/2023 | 1.0 |
Criação da introdução do documento | Natan Santana | Clara Ribeiro |
03/07/2023 | 2.0 |
Adição das referências | Natan Santana | Clara Ribeiro |