Lista de Verificação - Entrega 5
Introdução
Este artefato apresenta o planejamento da verificação dos artefatos desenvolvidos pelo grupo 4 e grupo 5 durante a Etapa 5 (Verificação e Validação).
Objetivos
O objetivo deste documento é registrar a lista de verificação da 5ª etapa do Grupo 4, que será utilizada para verificar artefatos do próprio grupo e do Grupo 5.
Metodologia
Através de reuniões, o grupo decidiu adotar a metodologia de verificação por inspeção desenvolvida por Fagan (Michael E. Fegan) em 1976. Dessa maneira, cada integrante participa na entrega do projeto nos prazos planejados. Cada artefato varificado gera um relatório anexado junto aos demais artefatos daquela entrega. Para responder às perguntas apresentadas nas listas de verificação o avaliador usará as opções Sim, Não, Incompleto ou Não se aplica. O avaliador tambem poderá escrever observações para cada item, se achar necessário.
Lista de Verificação
Tabela 1 ─ Lista de Verificação da Etapa 5: Verificação e Validação
| N° | Questão | Autor |
|---|---|---|
| Elicitação | ||
| 1 | O público alvo selecionado do questionário foi coerente com o aplicativo escolhido?fonte | Pedro Lopes |
| 2 | As perguntas desenvolvidas no questionário foram desenvolvidas com linguagem neutra e sem induzir o participante à uma resposta “desejada”?fonte | Pedro Lopes |
| 3 | O questionário foi testado antes de ser divulgado?fonte | Pedro Lopes |
| 4 | A técnica de brainstorming é caracterizada por coletar ideias em um determinado período de tempo, geralmente em grupos de 5 a 10 pessoas. As ideias são documentadas por um moderador sem discussão, julgamento ou comentários inicialmente. Os participantes usam ideias de outros participantes para desenvolver novas ideias originais ou modificar ideias existentes?fonte | Emivalto |
| 5 | A técnica de observação de campo é caracterizada pelo engenheiro de requisitos estar presente no local com o especialista ou os usuários do sistema e observar e documentar os processos e procedimentos operacionais que eles executam. Essas observações podem ser auxiliadas por gravações de áudio e vídeo?fonte | Emivalto |
| 6 | O questionário é uma técnica que utiliza perguntas abertas e/ou fechadas (ex: questões de múltipla escolha) para elicitar requisitos dos stakeholders. Se houver muitos participantes que precisam ser pesquisados, um questionário online é uma opção viável?fonte | Emivalto |
| 7 | Foi fornecido ao(s) participante(s) 100 dólares imaginários para ser usado durante a priorização dos requisitos?fonte | Artur |
| 8 | O(s) participante(s) da priorização alocou(aram) esses dólares para “comprar” itens que gostariam de implementar do conjunto completo de requisitos elicitados?fonte | Artur |
| 9 | Foram atribuídos mais dólares aos requisitos de maior prioridade?fonte | Artur |
| 10 | Foi atribuído todo o valor (100 dólares) a um único requisito a fim de colocá-lo no topo da lista, manipulando, assim, o processo de priorização e distorcendo os resultados?fonte | Artur |
| 11 | O entrevistado é um stakeholder (i. e., ele é alguém que se envolveria com o software cujos requisitos deseja-se elicitar), e possui conhecimento adequado para ser entrevistado?fonte | João Pedro |
| 12 | Foram criadas perguntas predeterminadas, no planejamento da entrevista?fonte | João Pedro |
| 13 | As respostas são documentadas, de forma que podem ser analisadas posteriormente?fonte | João Pedro |
| Priorização | ||
| 14 | A priorização dos requisitos foi feita/ validada com mais de um usuário?fonte | Pedro Lopes |
| 15 | As técnicas de priorização utilizadas levam em consideração a importância relativa dos requisitos para os usuários?fonte | Pedro Lopes |
| 16 | A técnica de priorização por Grupo de Foco é usada para identificar e classificar os requisitos mais importantes por meio da interação entre especialistas e stakeholders em um ambiente colaborativo?fonte | Emivalto |
| 17 | A priorização é realizada com base em critérios como custo, valor de negócio e risco, conforme discutido pelos participantes durante as sessões do grupo de foco?fonte | Emivalto |
| 18 | Os resultados das priorizações realizadas em grupos de foco são documentados para garantir rastreabilidade e consistência no desenvolvimento do projeto?fonte | Emivalto |
| 19 | Foi fornecido ao(s) participante(s) 100 dólares imaginários para ser usado durante a priorização dos requisitos?fonte | Artur |
| 20 | O(s) participante(s) da priorização alocou(aram) esses dólares para “comprar” itens que gostariam de implementar do conjunto completo de requisitos elicitados?fonte | Artur |
| 21 | Foram atribuídos mais dólares aos requisitos de maior prioridade?fonte | Artur |
| 22 | Foi atribuído todo o valor (100 dólares) a um único requisito a fim de colocá-lo no topo da lista, manipulando, assim, o processo de priorização e distorcendo os resultados?fonte | Artur |
| 23 | Há participação de stakeholders na priorização?fonte | João Pedro |
| 24 | Uma técnica mais analítica é empregada, quando os stakeholders não chegam em um consenso?fonte | João Pedro |
| 25 | Foram usados outros critérios durante a priorização, como por exemplo, importância para o negócio e impacto no usuário final, de acordo com as especificações do projeto?fonte | João Pedro |
| 26 | As respostas são documentadas, de forma que podem ser analisadas posteriormente?fonte | João Pedro |
| Cenários | ||
| 27 | Os cenários seguem o modelo de perguntas “Por que…?”, “Como…?” e “O que é…?” ? fonte | Pedro Lopes |
| 28 | Os cenários possuem detalhes do ambiente/ contexto, que ajudam a explicar os objetivos e ações dos atores?fonte | Pedro Lopes |
| 29 | Nos cenários, existe uma descrição do(s) ator(es) relevante para o contexto do cenário?fonte | Pedro Lopes |
| 30 | Os cenários são agrupados em casos de uso e documentam sequências exemplares de uso do sistema. Os casos de uso e cenários são uma das três formas independentes de documentar requisitos, junto com objetivos e requisitos do sistema?fonte | Emivalto |
| 31 | Um cenário principal descreve a sequência normal de interações entre o sistema e os atores, enquanto cenários alternativos descrevem variações do fluxo normal e cenários de exceção descrevem comportamentos de erro?fonte | Emivalto |
| 32 | Os cenários podem ser documentados usando diagramas de atividade UML, onde o fluxo de controle entre o cenário principal e os cenários alternativos e de exceção é representado por nós de decisão?fonte | Emivalto |
| 33 | Na descrição do(s) cenário(s) foi explorado como e quando um caso de uso começa?fonte | Artur |
| 34 | Na descrição do(s) cenário(s) foi explorado quando o caso de uso interage com os atores e quais dados eles trocam entre si?fonte | Artur |
| 35 | Na descrição do(s) cenário(s) foi explorado quando o caso de uso referencia ou mantém dados?fonte | Artur |
| 36 | Na descrição do(s) cenário(s) foi explorado como e quando o caso de uso termina?fonte | Artur |
| 37 | O cenário descreve um Caso de Uso?fonte | João Pedro |
| 38 | O número de passos de cada cenário está entre 3 e 10, inclusos?fonte | João Pedro |
| 39 | O Cenário possui um nome significativo e um evento ou condição para que o cenário aconteça?fonte | João Pedro |
| História de Usuário e Backlog | ||
| 40 | O backlog foi desenvolvido/ validado com um Product Owner?fonte | Pedro Lopes |
| 41 | As Histórias de Usuários são focadas em descrever “o que” é o item?fonte | Pedro Lopes |
| 42 | As Histórias de Usuário são pequenas, detalhadas e específicas?fonte | Pedro Lopes |
| 43 | As histórias de usuário são uma forma ágil de documentar requisitos do ponto de vista do usuário, seguindo geralmente o formato "Como [papel], eu quero [função] para que [benefício]", e são mantidas em um backlog priorizado?fonte | Emivalto |
| 44 | O Product Backlog é uma lista priorizada de todas as funcionalidades desejadas para o produto, sendo que os itens no topo do backlog devem ser mais detalhados e prontos para implementação do que os itens mais abaixo?fonte | Emivalto |
| 45 | As histórias de usuário no backlog devem ser independentes, negociáveis, valiosas, estimáveis, pequenas e testáveis, seguindo o acrônimo INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)?fonte | Emivalto |
| 46 | Foram especificados requisitos por meio de histórias do usuário?fonte | Artur |
| 47 | Foram especificados requisitos não funcionais por meio de histórias do usuário?fonte | Artur |
| 48 | As histórias do usuário criadas responderam às três perguntas: Quem se beneficia? O que se quer? Qual é o benefício?fonte | Artur |
| 49 | Cada História de Usuário tem um enunciado na forma “Como um [papel], eu desejo [funcionalidade], para que [razão para o uso da funcionalidade]”?fonte | João Pedro |
| 50 | As Histórias de Usuário estão organizadas em um Backlog?fonte | João Pedro |
| 51 | Os Backlog Items (as Histórias de Usuário) apresentam alguma forma de priorização?fonte | João Pedro |
| NFR Framework | ||
| 52 | O NFR Framework do grupo apresenta um catálogo?fonte | Pedro Lopes |
| 53 | O artefato NFR Framework possui os 3 tipos de softgoals?fonte | Pedro Lopes |
| 54 | O SoftGoal Operacional está definido de forma correta?fonte | Pedro Lopes |
| 55 | O NFR Framework é utilizado para documentar requisitos de qualidade do sistema, sendo que estes requisitos frequentemente influenciam mais a arquitetura do sistema do que os requisitos funcionais. Tipicamente, requisitos de qualidade são sobre desempenho, disponibilidade, confiabilidade, escalabilidade ou portabilidade?fonte | Emivalto |
| 56 | Os requisitos de qualidade devem ser quantificados sempre que possível para serem objetivos e verificáveis. Por exemplo, um requisito de qualidade relacionado ao desempenho do sistema poderia especificar que o sistema deve processar 95% de todas as consultas em 1,5 segundos?fonte | Emivalto |
| 57 | Os requisitos de qualidade devem ser mantidos separados dos requisitos funcionais na documentação, com documentação explícita de suas relações com os requisitos funcionais, pois frequentemente estão relacionados a diferentes requisitos funcionais?fonte | Emivalto |
| 58 | Os requisitos não funcionais identificados incluem todas as dimensões relevantes (como disponibilidade, eficiência, usabilidade, adaptabilidade e continuidade)?fonte | Artur |
| 59 | Existem métricas associadas aos requisitos não funcionais para monitoramento e avaliação contínua?fonte | Artur |
| 60 | O ciclo de vida dos requisitos não funcionais inclui análise, planejamento, arquitetura, engenharia, operação, monitoramento e melhorias?fonte | Artur | Rastreabilidade |
| 61 | No Rich Picture, os atores participam e recebem operações?fonte | Pedro Lopes |
| 62 | Todas as atividades que o sistema deve cumprir estão dentro do limite do sistema no Rich Picture?fonte | Pedro Lopes |
| 63 | No artefato de backward-from os requisitos elicitados são ligados às suas devidas fontes?fonte | Pedro Lopes |
| 64 | A rastreabilidade pré-RS (pre-requirements specification) refere-se aos links de rastreabilidade entre requisitos e os artefatos que são a base para os requisitos, como fontes ou origem de um requisito (artefatos anteriores)?fonte | Emivalto |
| 65 | A rastreabilidade pós-RS (post-requirements specification) compreende informações de rastreabilidade entre requisitos e artefatos de atividades de desenvolvimento subsequentes, como componentes, implementação ou casos de teste?fonte | Emivalto |
| 66 | A rastreabilidade entre requisitos mapeia as dependências entre requisitos, como quando um requisito refina outro requisito, o generaliza ou o substitui?fonte | Emivalto |
| 67 | A análise de impacto de mudança foi realizada de forma adequada?fonte | Artur |
| 68 | A rastreabilidade vertical foi realizada?fonte | Artur |
| 69 | A rastreabilidade foi implementada por meio de ferramentas de mapeamento de grafos ou matrizes bidimensionais?fonte | Artur |
| 70 | Os elos (ou vínculos) foram identificados e documentados durante a rastreabilidade dos requisitos?fonte | Artur |
| Elos de Toranzo | ||
| 71 | Considerando os níveis dos Elos de Toranzo, existem elos descritos pelo grupo que contemplam o nível ambiental (contexto onde a organização está inserida)?fonte | Pedro |
| 72 | Considerando os Principais tipos de Elos de Toranzo, elos do tipo “Recurso” (classe de origem possui dependência de recurso com a classe de destino) foram feitos?fonte | Pedro |
| 73 | Foram desenvolvidos elos do tipo “Satisfação” (classe de origem com dependência de satisfação com a classe destino)?fonte | Pedro |
| 74 | Os elos de rastreabilidade permitem verificar se um requisito foi implementado no sistema e identificar se a propriedade do sistema implementa o requisito especificado?fonte | Emivalto |
| 75 | Os elos de rastreabilidade auxiliam na análise de impacto durante o gerenciamento de mudanças, permitindo identificar os artefatos de requisitos que precisam ser alterados quando seus requisitos subjacentes sofrem uma mudança?fonte | Emivalto |
| 76 | Os elos de rastreabilidade podem ser representados através de referências textuais simples, hyperlinks, matrizes de rastreabilidade e grafos de rastreabilidade?fonte | Emivalto |
| 77 | A classificação das informações rastreadas no projeto contempla os quatro níveis: ambiental, organizacional, gerencial e de desenvolvimento?fonte | Artur |
| 78 | O modelo de rastreamento inclui instâncias de relacionamentos como 'satisfação', 'recurso', 'responsabilidade', ‘representação’, ‘alocado’, ‘agregação’ e ‘generalização’ para documentar as dependências entre os artefatos?fonte | Artur |
| 79 | O modelo de rastreamento utiliza uma matriz para representar e validar os relacionamentos entre as classes de informação?fonte | Artur |
Autores: Pedro Lopes, Emivalto Júnior, João Pedro, Artur Ricardo e Matheus Henrick
Fontes da Lista de Verificação
📑 Histórico de Versões
| Versão | Descrição | Autor(es) | Data de Produção | Revisor(es) | Data de Revisão |
|---|---|---|---|---|---|
1.0 |
Criação do documento | João Pedro | 03/02/2025 | ||
1.1 |
Correções para a entrega final | João Pedro | 09/02/2025 |