Lista de Verificação da Entrega 2
Este documento apresenta uma lista de verificação para avaliar os artefatos produzidos na Entrega 2, tantos para o grupo e o grupo +1. As tabelas 1, 2 e 3 foram elaboradas com base no plano de ensino e na lista de verificação sugerida pelo professor, André Barros de Sales, sendo uma lista de verificação que será usada na inspeção da entrega 2.
Objetivo
- Fornecer critérios claros para verificação dos artefatos da Entrega 2;
- Garantir a padronização e qualidade dos documentos produzidos;
- Facilitar o processo de revisão pelos integrantes do grupo;
- Assegurar que todos os itens exigidos estejam completos e corretos.
Metodologia
A abordagem selecionada para esta verificação é uma versão adaptada da técnica de inspeção. Criada por Fagan na IBM em 1976, inicialmente para analisar códigos de software, essa metodologia envolve uma avaliação formal dos artefatos desenvolvidos com o objetivo de identificar possíveis falhas. A Figura 1 ilustra as fases propostas por Fagan para esse procedimento.
Figura 1: Etapas da Inspeção de acordo com Fagan.
Fonte: SOMMERVILLE
Lista de Verificação - Baseada no plano de ensino
Tabela 1 – Lista de Verificação 1
| ID | Item de Verificação | Autor | Referência |
|---|---|---|---|
| 1 | A Especificação do Perfil do usuário possui informação de: idade, experiência, atitudes e tarefas primárias. | André Barros de Sales | |
| 2 | Um cronograma (data e horário) e local para realização da elicitação dos requisitos com o cliente e/ou persona do projeto? | André Barros de Sales | |
| 3 | No mínimo três técnicas de elicitação foram utilizadas? | André Barros de Sales | |
| 4 | A participação do cliente e/ou persona na elicitação de requisitos? | André Barros de Sales | |
| 5 | A gravação e o(s) registro(s) da elicitação dos requisitos (pré-rastreabilidade)? | André Barros de Sales | |
| 6 | Um cronograma (data e horário) e local para realização da priorização dos requisitos com o cliente e/ou persona do projeto? | André Barros de Sales | |
| 7 | No mínimo duas técnicas de priorização foram utilizadas? | André Barros de Sales | |
| 8 | A participação do cliente e/ou persona no processo de priorização? | André Barros de Sales | |
| 9 | A gravação e o(s) registro(s) da atividade de priorização dos requisitos? | André Barros de Sales | |
| 10 | Cada integrante da equipe elaborou pelo menos um item do conteúdo da disciplina com referência bibliográfica da fonte e foto do texto referência? | André Barros de Sales |
Fonte: Lucas Alves.
Lista de Verificação - Itens Técnicos e Documentais
Tabela 2 – Lista de Verificação de itens Técnicos e Documentais
| ID | Item de Verificação | Autor | Referência |
|---|---|---|---|
| 1 | O histórico de versão está padronizado no repositório? - Uso de convenções consistentes para registrar alterações no repositório do projeto. | André Barros de Sales | |
| 2 | Referências e bibliografia estão incluídas nos artefatos? - Citação correta de fontes utilizadas para fundamentar o projeto e seus artefatos. | André Barros de Sales | |
| 3 | Tabelas e imagens possuem legenda e fonte, e são citadas no texto? - Elementos visuais devidamente legendados, com fontes citadas e contextualizadas no texto. | André Barros de Sales | |
| 4 | Existe introdução explicando os artefatos desenvolvidos? - Texto introdutório explicando a função e o conteúdo dos artefatos apresentados. | André Barros de Sales | |
| 5 | O cronograma executado possui responsáveis e datas? - Planejamento real com datas e responsáveis, refletindo o que foi efetivamente feito. | André Barros de Sales | |
| 6 | As atas de reunião contêm data, horário, participantes e objetivos? - Documentos com registro formal das reuniões, contendo data, hora, participantes e objetivos. | André Barros de Sales | |
| 7 | As gravações de reuniões foram salvas? - Arquivos de vídeo das reuniões, armazenados para consulta futura. | André Barros de Sales | |
| 8 | As apresentações no YouTube estão configuradas como "não listado"? - Garantia de que os vídeos estão acessíveis apenas para quem tiver o link, respeitando a privacidade. | André Barros de Sales |
Fonte: Lucas Alves.
Lista de Verificação - Perfil de Usuário
Tabela 3 – Lista de Verificação do Peril de Usuário
| ID | Item de Verificação | Autor | Referência |
|---|---|---|---|
| 1 | O perfil do usário foi definido claramente de forma que auxilia no recrutamento dos futuros participantes? | Ana Luiza Soares | |
| 2 | Há a faixa etária do usuário ? | Isaque Camargos | |
| 3 | O perfil possui dados sobre a frequência e forma de uso da tecnologia por esse usuário? | Kaleb Macedo | |
| 4 | Foram identificadas aplicações ou ferramentas mais utilizadas? | Lucas Alves | |
| 5 | Está alinhado com funcionalidades reais do sistema? | Matheus de Alcântara | |
| 6 | O perfil é tratado como um artefato interativo, passível de revisão e refinamento ao longo do projeto? | Othavio Bolzan | |
| 7 | Os dados dos usuários foram adequadamente coletados? | Yzabella Miranda |
Fonte: Lucas Alves.
Lista de Verificação - Personas
Tabela 4 – Lista de Verificação de Personas
| ID | Item de Verificação | Autor | Referência |
|---|---|---|---|
| 1 | A persona tem uma história que o contextualiza com sua realidade, no caso a sua identidade? | Kaleb Macedo |  Livro IHC |
| 2 | A persona está definida como usuário primário, secundário, outro stakeholder ou anti-usuário, quem não vai utilizar o sistema, logo não deve influenciar? | Ana Luiza Soares |  Livro IHC |
| 3 | A persona foi definida com base nos objetivos do domínio de atividade do usuário? | Yzabella Miranda | Livro IHC |
| 4 | Aponta frustrações ou problemas enfrentados com sistemas anteriores? | Matheus de Alcântara |  Livro Interaction Design: Beyond Human-Computer Interaction |
| 5 | As habilidades da persona identificada não se limitam ao nosso produto em específico? | Isaque Camargos | Livro IHC |
| 6 | A persona possui expectativas sobre como o sistema ou produto deve funcionar? | Lucas Alves | Livro IHC |
| 7 | Os requisitos da persona estão detalhados? | Othavio Araujo Bolzan | Livro IHC |
| 8 | Há ao menos uma persona por papel de usuário? | Isaque Camargos | Barbosa, S. D. J. et al., Livro IHC |
| 9 | Tem uma imagem ou representação visual que a torne memorável? | Lucas Alves | Livro IHC |
| 10 | A persona é derivada de dados reais coletados com usuários ou stakeholders reais? Possíveis usuários típicos? | Kaleb Macedo | Livro IHC |
Fonte: Kaleb Macedo.
Lista de Verificação - Entrevista
Tabela 5 – Lista de Verificação de Entrevista
| ID | Item de Verificação | Autor | Referência |
|---|---|---|---|
| 1 | O tipo de entrevista (estruturada, semiestruturada, não estruturada) foi respeitado? | Isaque Camargos | |
| 2 | As perguntas ou tópicos estavam claros, sem termos técnicos ou jargões inadequados? | Isaque Camargos | |
| 3 | As perguntas abertas foram exploradas com aprofundamento quando as respostas foram superficiais? | Isaque Camargos | |
| 4 | O roteiro foi previamente definido ? | Isaque Camargos | |
| 5 | As perguntas do roteiro seguiram uma ordem lógica ? | Isaque Camargos | |
| 6 | O entrevistador manteve o foco no objetivo da entrevista ? | Isaque Camargos | |
| 7 | O entrevistador manteve uma postura neutra ? | Isaque Camargos | |
| 8 | O entrevistador se apresentou ? | Isaque Camargos | |
| 9 | O entrevistador fez um período de aquecimento ? | Isaque Camargos | |
| 10 | O entrevistador concluiu a reunião formalmente ? | Isaque Camargos |
Fonte: Isaque Camargos.
Lista de Verificação - Introspecção
Tabela 6 – Lista de Verificação de Introspecção
| ID | Item de Verificação | Autor | Referência |
|---|---|---|---|
| 1 | A introdução apresenta de forma clara a técnica de introspecção aplicada? | Lucas Alves | |
| 2 | O artefato explicita a metodologia utilizada e identifica os participantes? | Lucas Alves | |
| 3 | Existe cronograma com data e horário da aplicação da técnica para cada participante? | Lucas Alves | |
| 4 | As tabelas de requisitos estão organizadas com tipo, descrição, ID e status de implementação? | Lucas Alves | |
| 5 | Há distinção clara entre requisitos funcionais e não funcionais? | Lucas Alves | |
| 6 | Os requisitos possuem rastreabilidade com os códigos das listas principais (ex: RF01, RNF02)? | Lucas Alves | |
| 7 | O artefato contém considerações finais com análise crítica dos resultados da introspecção? | Lucas Alves | |
| 8 | Há link de vídeo de apresentação da elicitação no YouTube incluído no documento? | Lucas Alves | |
| 9 | O histórico de versões está presente e padronizado com data, descrição e autores/revisores? | Lucas Alves | |
| 10 | Tabelas possuem legendas e fontes, e estão devidamente referenciadas no corpo do texto? | Lucas Alves |
Lista de Verificação - Questionário
Tabela 7 – Lista de Verificação do Questionário
| ID | Item de Verificação | Autor | Referência |
|---|---|---|---|
| 1 | As funcionalidades mais utilizadas ou apontadas como importantes pelos usuários foram efetivamente mapeadas como requisitos funcionais? | Kaleb Macedo |  Livro Engenharia de Requisitos |
| 2 | As dificuldades técnicas citadas pelos usuários (ex: lentidão, instabilidade, falta de clareza) foram traduzidas em requisitos não funcionais claros? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 3 | As sugestões textuais espontâneas (como melhorias desejadas e novos recursos) foram analisadas para originar requisitos adicionais ou melhorias? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 4 | Existe uma classificação explícita e correta entre requisitos funcionais (RF) e não funcionais (RNF)? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 5 | Requisitos relacionados à acessibilidade e usabilidade contemplam todos os públicos (ex: idosos, leitores de tela, navegação por smartphone)? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 6 | Os requisitos estão justificados por evidências quantitativas ou qualitativas oriundas da pesquisa? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 7 | Os principais problemas citados pelos usuários (ex: ausência de extrato diário, busca ineficiente) foram abordados em requisitos específicos? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 8 | Há sinalização clara de quais requisitos ainda não foram implementados, com potencial para priorização futura? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 9 | A experiência do usuário real (UX) foi utilizada para sugerir mudanças de interface, navegação ou hierarquia de informações? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 10 | O relatório oferece recomendações objetivas de evolução com base nos dados coletados, indo além da descrição dos problemas? | Kaleb Macedo | Livro Engenharia de Requisitos |
Fonte: Kaleb Macedo.
Lista de Verificação - Moscow
Tabela 8 – Lista de Verificação do Questionário
| ID | Item de Verificação | Autor | Referência |
|---|---|---|---|
| 1 | As personas foram devidamente consideradas na priorização (motivações, frustrações, objetivos, dispositivo de acesso)? | Kaleb Macedo |  Livro Engenharia de Requisitos |
| 2 | Cada requisito funcional foi classificado com base na sua importância para a persona primária e secundária? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 3 | A priorização levou em conta os critérios de frequência de uso e criticidade da funcionalidade? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 4 | Requisitos do tipo Must foram claramente identificados e estão implementados ou planejados com prioridade máxima? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 5 | Requisitos do tipo Should e Could foram registrados com justificativas para priorização em fases futuras? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 6 | Os requisitos Won’t foram definidos com clareza, indicando que não serão tratados nesta versão do sistema? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 7 | A tabela final de MoSCoW está organizada de forma legível, por tipo de requisito (Funcional / Não Funcional) e por persona? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 8 | Há documentação ou registro da participação dos stakeholders ou personas no processo de priorização? | Kaleb Macedo | Livro Engenharia de Requisitos |
| 9 | A lista de requisitos priorizados será utilizada como base para o planejamento incremental de entregas e releases? | Kaleb Macedo | Livro Engenharia de Requisitos |
Fonte: Kaleb Macedo.
Lista de Verificação – Glossário
Tabela 9 – Lista de Verificação do Peril de Usuário
| ID | Descrição da verificação | Participante | Evidência |
|---|---|---|---|
| 1 | Verificar se a elaboração do glossário foi iniciada já nas atividades de elicitação, durante a análise do domínio do problema e das necessidades de negócio. | Ana Luiza Soares |  (VAZQUEZ, Bruno; SIMÕES, André; ALBERT, Endrew. Engenharia de requisitos: software orientado ao negócio. 1. ed. Rio de Janeiro: Elsevier, 2013.) |
| 2 | Verificar se foram identificados termos únicos para o domínio, que não aparecem em outros contextos do projeto. | Ana Luiza Soares |  (VAZQUEZ, Bruno; SIMÕES, André; ALBERT, Endrew. Engenharia de requisitos: software orientado ao negócio. 1. ed. Rio de Janeiro: Elsevier, 2013.) |
| 3 | Verificar se foram capturados termos que têm mais de uma definição, evitando ambiguidades. | Ana Luiza Soares |  (VAZQUEZ, Bruno; SIMÕES, André; ALBERT, Endrew. Engenharia de requisitos: software orientado ao negócio. 1. ed. Rio de Janeiro: Elsevier, 2013.) |
| 4 | Verificar se foram incluídos termos com definição local distinta do senso comum, garantindo clareza para todos os envolvidos. | Ana Luiza Soares |  (VAZQUEZ, Bruno; SIMÕES, André; ALBERT, Endrew. Engenharia de requisitos: software orientado ao negócio. 1. ed. Rio de Janeiro: Elsevier, 2013.) |
| 5 | Verificar se foram listados termos com potencial de causar dificuldades de entendimento, sustentando a pesquisa junto às partes interessadas. | Ana Luiza Soares |  (VAZQUEZ, Bruno; SIMÕES, André; ALBERT, Endrew. Engenharia de requisitos: software orientado ao negócio. 1. ed. Rio de Janeiro: Elsevier, 2013.) |
| 6 | Verificar se foram considerados termos técnicos do negócio (jargões, processos internos etc.). | Ana Luiza Soares | VAZQUEZ, Bruno; SIMÕES, André; ALBERT, Endrew. Engenharia de requisitos: software orientado ao negócio. 1. ed. Rio de Janeiro: Elsevier, 2013. |
| 7 | Verificar se foram incluídas abreviações e siglas relevantes ao escopo, com suas respectivas explicações. | Ana Luiza Soares |  (VAZQUEZ, Bruno; SIMÕES, André; ALBERT, Endrew. Engenharia de requisitos: software orientado ao negócio. 1. ed. Rio de Janeiro: Elsevier, 2013.) |
| 8 | Verificar se foram mapeados termos que são sinônimos ou antônimos, usando remissivas simples e cruzadas para facilitar a consulta. | Ana Luiza Soares |  (VAZQUEZ, Bruno; SIMÕES, André; ALBERT, Endrew. Engenharia de requisitos: software orientado ao negócio. 1. ed. Rio de Janeiro: Elsevier, 2013.) |
Fonte: Autoria de Ana Luiza Soares
Lista de Verificação – Técnica: Grupo Focal
Tabela 10 – Lista de Verificação do Grupo Focal
| ID | Item de verificação | Autor | Referência |
|---|---|---|---|
| Q1 | O objetivo da reunião está claro para todos os participantes? | Matheus de Alcântara |  |
| Q2 | A reunião foi realizada com representantes dos usuários? | Matheus de Alcântara | |
| Q3 | Foi definida uma pauta com os principais temas da discussão? | Matheus de Alcântara |  |
| Q4 | O facilitador conduziu a sessão de forma neutra e produtiva? | Matheus de Alcântara |  |
| Q5 | Os participantes foram incentivados a dar suas opiniões livremente? | Matheus de Alcântara | |
| Q6 | A sessão foi gravada ou registrada por alguém para garantir que nada fosse perdido? | Matheus de Alcântara | |
| Q7 | Foi preparado algum material de apoio, como protótipos ou exemplos, para facilitar a discussão? | Matheus de Alcântara | |
| Q8 | Os resultados da reunião serão compartilhados com os envolvidos para revisão e complementação? | Matheus de Alcântara | |
Autor: Matheus de Alcântara
Lista de Verificação - $100
Tabela 11 – Lista de Verificação 100 Dólares
| ID | Item de Verificação | Autor | Referência |
|---|---|---|---|
| 1 | A equipe de priorização recebeu exatamente 100 dólares imaginários para distribuir? | Isaque Camargos | |
| 2 | Nenhum requisito recebeu mais do que 100 dólares ? | Isaque Camargos | |
| 3 | A soma de todos os valores deu exatamente 100 dólares ? | Isaque Camargos | |
| 4 | Foi feito a média dos valores que cada requisito recebeu ? | Isaque Camargos | |
| 5 | A parte interessada foi instruída para evitar manipulações nos valores ? | Isaque Camargos | |
| 6 | A distribuição de dinheiro foi feita com base no desejo das partes interessadas ? | Isaque Camargos | |
| 7 | Se o dinheiro acabou, todo o resto foi dado com valor 0 ? | Isaque Camargos | |
| 8 | Cada participante realizou sua própria alocação de forma independente ? | Isaque Camargos |
Fonte: Isaque Camargos.
Lista de Verificação – Técnica: First Things First
Tabela 12 – Lista de Verificação First Thing First
| ID | Descrição da verificação | Participante | Evidência |
|---|---|---|---|
| 1 | Verificar se todos os requisitos foram listados em uma planilha, considerando dependências lógicas entre eles. | Ana Luiza Soares |  (SERRANO; SERRANO, Aula 07, p. 37, 2023) |
| 2 | Confirmar se o benefício relativo de cada requisito foi avaliado em escala numérica (1 a 9) com participação do cliente. | Ana Luiza Soares |  (SERRANO; SERRANO, Aula 07, p. 38, 2023) |
| 3 | Assegurar que a penalidade relativa (impacto de não implementar o requisito) foi definida em escala numérica (1 a 9). | Ana Luiza Soares |  (SERRANO; SERRANO, Aula 07, p. 38, 2023) |
| 4 | A coluna valor total é a soma de (peso do benefício × valor do benefício) + (peso da penalidade × valor da penalidade). | Ana Luiza Soares |  (SERRANO; SERRANO, Aula 07, p. 38, 2023) |
| 5 | Verificar se o custo relativo da implementação está entre 1 e 9. | Ana Luiza Soares |  (SERRANO; SERRANO, Aula 07, p. 38, 2023) |
| 6 | Os desenvolvedores levaram em consideração os custos com base em fatores como complexidade de implementação, interface necessária, potencial de reutilização e níveis de testes e documentação. | Ana Luiza Soares |  (SERRANO; SERRANO, Aula 07, p. 39, 2023) |
| 7 | Assegurar que a priorização seguiu a fórmula: Valor % / (Custo % × Peso + Risco % × Peso). | Ana Luiza Soares |  (SERRANO; SERRANO, Aula 07, p. 38, 2023) |
| 8 | Verificar se a lista final de requisitos foi ordenada em ordem decrescente de prioridade calculada. | Ana Luiza Soares |  (SERRANO; SERRANO, Aula 07, p. 39, 2023) |
Fonte: Autoria de Ana Luiza Soares
Lista de Verificação – Técnica: Three Level Scale
Tabela 13 – Lista de Verificação Three Level Scale
| ID | Descrição da verificação | Participante | Evidência |
|---|---|---|---|
| 1 | Verificar se todos os requisitos foram listados em três categorias. | Yzabella Miranda | |
| 2 | Confirmar se a prioridade foi extabelecida por uma tabela de importância x urgência | Yzabella Miranda | |
| 3 | Verificar se existe uma priorização pra cada requisito. | Yzabella Miranda | |
| 4 | Confirmar se as partes interessadas concordaram na prioritização da escala de importância x urgência | Yzabella Miranda | |
| 5 | As prioridades altas são importantes e urgentes? | Yzabella Miranda | |
| 6 | As prioridades médias são importante, mas não são urgentes? | Yzabella Miranda | |
| 7 | As prioridades baixas não são importantes e urgentes? | Yzabella Miranda | |
| 8 | O número de altas está elevado? | Yzabella Miranda |
Fonte: Autoria de Yzabella Miranda
Tradução das imagens da Tabela 11
Essa tradução foi feita com auxilio do Chat GPT.
Figura 1: Imagem 1 de fonte da tabela 9
Fonte: Software Requirements
Tradução: A priorização diz respeito à alocação cuidadosa de recursos limitados para alcançar o benefício máximo a partir do investimento que uma organização faz em um projeto. Uma maneira de tornar a priorização mais tangível é representá-la em termos de um recurso real: dinheiro. Neste caso, é apenas dinheiro fictício, mas ainda assim é dinheiro.
Dê à equipe de priorização 100 dólares imaginários para trabalhar. Os membros da equipe alocam esses dólares para "comprar" itens que gostariam que fossem implementados a partir do conjunto completo de requisitos candidatos. Eles atribuem mais dólares aos requisitos de maior prioridade.
Se um requisito for três vezes mais importante para um stakeholder do que outro requisito, ela poderia, por exemplo, atribuir nove dólares ao primeiro requisito e três dólares ao segundo. Mas 100 dólares é tudo o que os priorizadores têm — quando o dinheiro acabar, nada mais poderá ser implementado, pelo menos na versão do projeto em que estão focando no momento.
Uma abordagem é permitir que diferentes participantes do processo de priorização realizem suas próprias alocações de dólares e, em seguida, somar o total de dólares atribuídos a cada requisito para ver quais aparecem coletivamente como os de maior prioridade.
Figura 2: Imagem 2 de fonte da tabela 9
Fonte: Software Requirements
Tradução: A abordagem dos cem dólares não é uma má forma de fazer um grupo pensar em termos de alocação de recursos com base na prioridade. No entanto, Davis (2005) aponta várias maneiras pelas quais os participantes podem "manipular" o processo para distorcer os resultados. Por exemplo, se você realmente, REALMENTE quiser um requisito específico, pode atribuir todos os seus 100 dólares a ele para tentar colocá-lo no topo da lista.
Na prática, no entanto, você nunca aceitaria um sistema que implementasse apenas aquele único requisito. Nem esse esquema leva em consideração a quantidade de esforço necessária para implementar cada um dos requisitos. Se você puder obter três requisitos, cada um avaliado em $10 pelo mesmo esforço que um único avaliado em $15, é mais vantajoso ficar com os três. O esquema baseia-se apenas no valor percebido de certos requisitos por um grupo específico de stakeholders, o que é uma limitação comum de muitas técnicas de priorização.
Outra técnica de priorização é baseada em dinheiro real, não fictício. Na técnica “objective chain” de Joy Beatty e Anthony Chen (2012), você atribui um valor em dólares estimado que representa o quanto cada funcionalidade proposta contribui para os objetivos de negócios do projeto. Assim, é possível comparar o valor relativo das funcionalidades entre si e selecionar quais implementar primeiro.
Tradução das imagens da Tabela 10
Essa tradução foi feita com auxilio do Chat GPT.
Figura 3: Imagem 1 de fonte da tabela 7
Fonte: Software Requirements
Tradução: Tire boas notas Atribua a alguém que não está participando ativamente da discussão a função de escriba, responsável por tomar notas precisas. As notas da sessão devem conter uma lista de participantes, convidados que não compareceram, decisões tomadas, ações a serem realizadas e quem é responsável por cada uma, questões pendentes e os pontos principais das discussões. Infelizmente, analistas de negócios (BAs) às vezes conduzem sessões de elicitação sem um escriba dedicado e precisam assumir esse papel. Se você estiver nessa situação, esteja preparado para escrever em taquigrafia, digitar rapidamente ou usar um dispositivo de gravação (se os participantes concordarem). Canetas de áudio podem traduzir notas manuscritas para formato eletrônico e vinculá-las ao áudio gravado da discussão. Você também pode usar quadros brancos e papéis nas paredes e fotografá-los.
Prepare perguntas com antecedência para eliminar parte do pensamento improvisado necessário para manter a conversa fluindo. Crie uma notação abreviada para capturar uma pergunta que surgir enquanto alguém está falando, para que você possa voltar a ela rapidamente quando tiver uma oportunidade. Não tente capturar diagramas em softwares complicados de diagramação; apenas fotografe diagramas esboçados ou desenhe rapidamente à mão.
Figura 4: Imagem 2 de fonte da tabela 7
Fonte: Software Requirements
Figura 5: Imagem 3 de fonte da tabela 7
Fonte: Software Requirements
Tradução: Grupos focais Um grupo focal é um grupo representativo de usuários que se reúne em uma atividade facilitada de elicitação para gerar contribuições e ideias sobre os requisitos funcionais e de qualidade de um produto. As sessões de grupos focais devem ser interativas, permitindo que todos os usuários tenham a chance de expressar suas opiniões. Grupos focais são úteis para explorar atitudes, impressões, preferências e necessidades dos usuários (IIBA 2009). Eles são particularmente valiosos se você estiver desenvolvendo produtos comerciais e não tiver acesso direto a usuários finais dentro de sua empresa.
Frequentemente, você terá uma base de usuários grande e diversificada para selecionar, então escolha os membros do grupo focal com cuidado. Inclua usuários que tenham usado versões anteriores ou produtos semelhantes ao que você está implementando. Escolha um grupo de usuários do mesmo tipo (e realize vários grupos focais para diferentes classes de usuários) ou selecione um grupo que represente todo o espectro de classes de usuários, garantindo que todos estejam igualmente representados.
Os grupos focais devem ser facilitados. Você precisará mantê-los no tópico, mas sem influenciar as opiniões expressas. Pode ser útil gravar a sessão para que você possa voltar e ouvir atentamente os comentários. Não espere análises quantitativas de grupos focais, mas sim muito feedback subjetivo que pode ser avaliado e priorizado à medida que os requisitos são desenvolvidos. Sessões de elicitação com grupos focais se beneficiam de muitas das mesmas dicas descritas anteriormente para workshops. Participantes de grupos focais normalmente não têm autoridade de tomada de decisão para os requisitos.
Como utilizar esta lista de verificação
-
Para cada item da lista, o revisor deve:
- Verificar se o artefato atende ao critério especificado
- Marcar como "Conforme" ou "Não conforme"
- Para itens não conformes, adicionar comentários específicos sobre o que precisa ser corrigido
- Sempre incluir referências a exemplos ou páginas específicas onde os problemas foram encontrados
Referências
Barbosa, S. D. J.; Silva, B. S. da; Silveira, M. S.; Gasparini, I.; Darin, T.; Barbosa, G. D. J. (2021) Interação Humano-Computador e Experiência do usuário. Autopublicação. ISBN: 978-65-00-19677-1. Pg 144 - 148 .Disponível em: Interação Humano-Computador e Experiência do usuário.Acesso em: 30 de abril de 2024
SERRANO, Milene; SERRANO, Maurício. Requisitos – Aula 07. Disponível em: https://aprender3.unb.br/pluginfile.php/3096092/mod_resource/content/2/Requisitos%20-%20Aula%2007.pdf. Acesso em: 3 maio 2025.
SALES, André Barros de. Plano de Ensino – Requisitos de Software: REE012025 – Turma 03. Brasília: Universidade de Brasília, Faculdade UnB Gama, 2025. 7 p. Acessado em: 23 de abril de 2025
VAZQUEZ, Bruno; SIMÕES, André; ALBERT, Endrew. Engenharia de requisitos: software orientado ao negócio. 1. ed. Rio de Janeiro: Elsevier, 2013. Disponível em: https://aprender3.unb.br/pluginfile.php/3096085/mod_resource/content/4/Elicitacao%20de%20Req%202.pdf. Acesso em: 3 maio 2025.
WIEGERS, Karl; BEATTY, Joy. Software Requirements. 3. ed. Redmond. Microsoft Press, 2013. ISBN 978-0-7356-7966-5. p. 321 - 322 Disponível em: Software Requirements .Acesso em: 01 de maio de 2025
REQUISTOS DE SOFTWARE. Planejamento da Verificação da Etapa 1 do Grupo 2. Disponível em: site. Acesso em: 8 jun. 2025.
SOMMERVILLE, Ian. Engenharia de software. 08. ed. São Paulo: Pearson Addison Wesley, 2007.
Histórico de Versões
| Versão | Data | Descrição | Autor(es) | Revisor(es) |
|---|---|---|---|---|
1.0 |
23/04/2025 | Criação do documento | Lucas Alves e Kaleb Macedo | Ana Luiza Soares |
1.1 |
01/05/2025 | Adição da Lista da entrevista | Isaque Camargos | Ana Luiza Soares |
1.2 |
01/05/2025 | Atualizando lista de perfil de usuário | Lucas Alves | Ana Luiza Soares |
1.3 |
01/05/2025 | Criação da Lista de Personas | Kaleb Macedo | Ana Luiza Soares |
1.4 |
01/05/2025 | Adição da Lista da técnica $100 | Isaque Camargos | Ana Luiza Soares |
1.5 |
02/05/2025 | Correção de bug de fotos | Isaque Camargos | Ana Luiza Soares |
1.6 |
03/05/2025 | Adição da lista de verificação do Glossário e adição dos títulos nas tabelas | Ana Luiza Soares | Yzabella Miranda |
1.7 |
03/05/2025 | Adição da lista de verificação do First Thing First | Ana Luiza Soares | Yzabella Miranda |
1.8 |
04/05/2025 | Adição da lista de verificação do Questionário | Kaleb Macedo | Yzabella Miranda |
1.9 |
04/05/2025 | Adição da lista de verificação do Grupo Focal | Matheus de Alcântara | Ana Luiza Soares |
2.0 |
04/05/2025 | Adicionando a tabela de verificação introspecção | Lucas Alves | Kaleb Macedo |
2.1 |
04/05/2025 | Adicionando a tabela de verificação da técnica de Three Level Scale | Yzabella Miranda | Matheus de Alcântara |
2.2 |
04/05/2025 | Adição da tabela de verificação do Moscow | Kaleb Macedo | Lucas Alves |
2.3 |
06/06/2025 | Adição de tópico referente a metodologia da lista de verificação junto a um link de fonte. | Yzabella Miranda | Isaque Camargos |