Elicitar Requisitos

1. Técnicas de Elicitação

1.1. Objetivo

1.1.1. Identificar o conhecimento e os requisitos dos stakeholders

1.1.2. Recomendável combinar diferentes técnicas

1.2. Fatores mais influentes para escolha de técnicas

1.2.1. Distinção entre requisitos conscientes, inconscientes e sub-conscientes

1.2.2. As restrições em termos de tempo, orçamento e disponibilidade dos stakeholders

1.2.3. Experiência do engenheiro de requisitos com determinada técnica

1.2.4. Oportunidades e riscos do projeto

1.3. Técnicas de Pesquisa

1.3.1. Vantagens

1.3.1.1. Elicitar as mais precisas e imparciais declarações possíveis dos stakeholders a respeito de seus requisitos

1.3.1.2. Entrevista onde são feitas perguntas previamente determinadas

1.3.1.3. Levanta um grande número de  informações em pouco tempo e baixo custo

1.3.2. Desvatangens

1.3.2.1. Entrevistas consomem muito tempo

1.3.2.2. Questionários coletam apenas requisitos que o engenheiro de requisitos já conhece

1.3.2.3. Questionário requer tempo e conhecimento profundo do domínio em questão

1.3.2.4. Questionários não fornecem um feedback imediato

1.4. Técnicas de Criatividade

1.4.1. Objetivo de desenvolver requisitos inovadores

1.4.2. Técnica de Brainstorming

1.4.2.1. Ideias são coletas durante um período de tempo, por grupo de 5 a 10 pessoas

1.4.2.2. Vantagens

1.4.2.2.1. Muitas ideias coletadas em pouco tempo

1.4.2.2.2. Diversas pessoas podem expandir as ideias colaborativamente

1.4.2.3. Desvantagens

1.4.2.3.1. Menos eficaz quando a dinâmica de grupo é confusa

1.4.3. Técnica de Brainstorming paradox

1.4.3.1. Vantagens

1.4.3.1.1. São coletadas ideias do que não pode acontecer

1.4.3.2. Desvantagens

1.4.3.2.1. São as mesmas da técnica de brainstorming

1.4.4. Técnica de Mudança de Perspectiva

1.4.4.1. Técnica mais comum é a Six Thinking Hats (Seis Chapéus do Pensamento)

1.4.4.2. Vantagens

1.4.4.2.1. Stakeholders podem expressar suas ideias com imparcialidade

1.4.4.3. Desvantagens

1.4.4.3.1. Não poderá ser aplicada se os requisitos exigem um nível de detalhamento muito preciso

1.4.5. Técnicas de Analogia

1.4.5.1. Vantagens

1.4.5.1.1. Baseadas em analogia da natureza, por isso é uma fonte de solução comprovada e testada

1.4.5.2. Desvantagens

1.4.5.2.1. Exige pensamento analógico, muito tempo e domínio profundo da analogia

1.5. Técnicas Baseadas em Documentos

1.5.1. Objetiva reutilizar soluções e experiências feitas com sistemas existentes

1.5.2. Técnica arqueologia de sistemas

1.5.2.1. Vantagens

1.5.2.1.1. Assegura que todas as funcionalidades do sistema legado serão implementadas no novo sistema

1.5.2.2. Desvantagens

1.5.2.2.1. Produz grande quantidade de requisitos

1.5.2.2.2. Exige muito trabalho

1.5.3. Técnica de Leitura Baseada em Perspectiva

1.5.3.1. Vantagens

1.5.3.1.1. Análise estritamente focada

1.5.3.1.2. Partes específicas da documentação existente

1.5.3.2. Desvantagens

1.5.3.2.1. Conhecer muito bem o domínio para coloca-lo em perspectiva

1.5.4. Técnica de Reutilização

1.5.4.1. Vantagens

1.5.4.1.1. Custos com procedimentos de elicitação podem ser reduzidos

1.5.4.2. Reduzidos

1.5.4.2.1. Mais fácil de dizer, do que realmente fazer

1.6. Técnicas de Observação

1.6.1. Engenheiro de Requisitos observam os stakeholders enquanto trabalham

1.6.2. Técnica de Observação e Pesquisa de Campo

1.6.2.1. Vantagens

1.6.2.1.1. Apropriada para elicitar e compreender procedimentos operacionais

1.6.2.2. Desvantagens

1.6.2.2.1. Exigem que os procedimentos sejam fisicamente visíveis

1.6.3. Técnica de Apprenticing

1.6.3.1. Vantagens

1.6.3.1.1. Engenheiro de Requisitos pode vivenciar que os stakeholders consideram óbvios

1.6.3.2. Desvantagens

1.6.3.2.1. Alto custo e tempo

1.7. Técnicas de Apoio

1.7.1. Objetivo de funcionar como apoio às outras técnicas para compensar eventuais pontos fracos

1.7.2. Exemplos de técnicas de apoio são: mapas mentais (mind mapping), workshops, cartões CRC, gravações de áudio e vídeo, modelar sequencia de ações e protótipos

2. Categorização de Requisitos - Modelo de Kano

2.1. Fatores Básicos de Satisfação

2.1.1. Propriedades evidentes pressupostas, também conhecidos por dissatisfiers

2.1.1.1. Devem ser atendidos de qualquer maneira

2.2. Fatores Esperados de Satisfação

2.2.1. Propriedades explicitamente exigidas do sistema, também conhecidos por satisfiers

2.2.1.1. Conscientemente conhecidas e explicitamente exigidas

2.2.1.2. Stakeholders ficam contentes e satisfeiros

2.3. Fatores Inesperados de Satisfação

2.3.1. Propriedades do sistema que o stakeholder não conhece ou não espera. Descobre apenas ao utilizar o sistema. Conhecido por delighters.

2.3.1.1. Técnicas de criatividade são as mais indicadas para identificar esses requisitos antes

3. Fontes de Requisitos

3.1. Stakeholders

3.1.1. O engenheiro de requisitos tem a tarefa de coletar, documentar e consolidar as metas e requisitos conflitantes dos stakeholders

3.1.2. Acordos com os stakeholders geram direitos e deveres do Engenheiro de Requisitos e do Stakeholder

3.1.3. São influenciadores de requisitos de sistema

3.2. Documentos

3.2.1. Contém informações importantes para requisitos. Exemplos:

3.2.1.1. Normas e documentos legais

3.2.1.2. Documentos específicos do domínio

3.2.1.3. Documentos de requisitos do sistema legado

3.3. Sistemas em Operação

3.3.1. Sistemas anteriores ou do legado

4. Definição de Elicitar

4.1. Coletar e compilar as metas e requisitos das diversas fontes