Please enable JavaScript.
Coggle requires JavaScript to display documents.
UE 3 Elicitar Requisitos (N2) (Técnicas de elicitação (Aspectos…
UE 3 Elicitar Requisitos (N2)
Fontes de requisitos
As bases da elicitação de requisitos são o contexto do sistema e as fontes de requsiitos
A Engenharia de requisitos tem a atribuição de coletar e compilar as metas e requisitos das diversas fontes de requisitos
Informações sobre os stakeholders:
Nome
Função (papel)
Dados pessoais e de contato
Disponibilidade ao longo do projeto (quando e onde)
Relevância do stakeholder
Área e nível de expertise
Objetivos e interesses em relação ao projeto
Dependendo da cultura empresarial, pode ser recomendável ter um acordo verbal ou escrito com os stakeholders a respeito de suas atribuições, responsabilidades, autoridade, etc.
Existem 3 tipos diferentes de fontes de requisitos
Stakeholders
São pessoas ou organizações que influenciam os requisitos de um sistema
Documentos
Contém informações importantes que podem fornecer requisitos
Sistemas em operação
Podem ser sistemas anteriores ou legados, bem como sistemas concorrentes. Os stakeholdes podem formar uma ideia sobre o sistema atual e solicitar extensões ou modificações com base em suas impressões
Categorização de requisitos conforme o modelo de kano
A satisfação dos clientes pode ser classificada em 3 categorias
Fatores básicos de satisfação (dissatisfiers)
São propriedades evidentes e pressupostas (conhecimento subconsciente)
Devem ser atendidas pelo sistema de qualquer maneira
Mesmo plenamente atendidos, não geram uma atitude positiva por parte do stakeholders
Técnicas de observação são muito apropriadas para elicitar requisitos detalhados e fatores básicos de satisfação
Fatores esperados de satisfação (satisfiers)
São propriedades explicitamente exigidas do sistema (conhecimento consciente)
Quando essas propriedades são atendidas, os stakeholders ficam contentes e satisfeitos
Se algumas das propriedades exigidas estiverem faltando, o stakeholder provavelmente não aceitará o produto
Esses fatores podem ser elicitados muito bem com técnicas de pesquisa
Fatores de entusiasmo/inesperados (delighters)
São propriedades do sistema que o stakeholder não conhece ou espera, e que ele descobre apenas ao utilizar o sistema - uma surpresa agradável e útil (conhecimento inconsciente)
Pode ser descoberto também quando o engenheiro de requisito as propõe
Técnicas de criatividade são as mais indicadas para elicitar esse tipo de fatores
Com o passar do tempo, os fatores inesperados se transformam em fatores esperados e em fatores básicos, conforme o usuário vai se acostumando às propriedades do sistema
Ao elicitar requisitos todas as 3 categorias devem ser consideradas
Os antigos fatores esperados de satisfação (satisfiers) são parcialmente cobertos pelos atuais fatores básicos de satisfação
Técnicas de elicitação
Aspectos importantes que influenciam a escolha de uma ou outra técnica de elicitação:
Fatores de risco
Na maioria dos casos, esses fatores são consequência de influências humanas, organizacionais e técnicas
Influências humanas
Para assegurar uma comunicação de alta qualidade entre o engenheiro de requisitos e os stakeholders, é importante determinar o tipo de requisito, o nível esperado de detalhamento do requisito e a experiência do engenheiro de requisitos e dos entrevistados
Influências organizacionais
Inclui a distinção entre contratos de preço fechado e contratos de prestação de serviço, ou se o sistema a ser criado é um novo desenvolvimento ou uma extensão de um sistema legado, bem como disponibilidade de tempo e deslocamento dos stakeholders
Influências técnicas ou conteúdo operacional
Se o sistema for muito complexo, é recomendável utilizar uma abordagem estruturante durante a elicitação para desconstruir os conteúdos operacionais em partes compreensíveis
Nível de detalhamento esperado dos requsitos
Requisitos abstratos podem ser elicitados por meios de técnicas de criatividade
Técnicas baseadas em pesquisa ou observações podem ajudar a elicitar requisitos com nível médio de detalhamento
Requisitos minuciosamente detalhados podem ser elicitados com técnicas centradas em documentos
Diferentes técnicas de elicitação são necessárias para os diferentes produtos da engenharia de requisitos
Técnicas de pesquisa
Têm por objetivo elicitar as mais precisas e imparciais declarações possíveis dos stakeholders
Entrevista
O engenheiro de requisitos faz perguntas previamente determinadas para um ou mais stakeholders e documenta as respostas
A principal desvantagem dessa técnica é o tempo que ela consome
Questinário
Questionários podem elicitar grande número de informações em curto espaço de tempo e a baixo custo
Uma desvantagem de utilizar um questionário é que ele somente pode ser utilizado para coletar os requisitos que o engenheiro de requisitos já conhece ou conjectura
Para elaborar um questionário apropriado exige muito tempo e requer conhecimento profundo do domínio em questão
Técnicas de criatividade
Têm a finalidade de desenvolver requisitos inovadores, esboçar uma visão inicial do sistema e elicitar fatores inesperados de satisfação
Brainstorming
Essa técnica é particularmente eficaz quando envolve um grande número de pessoas de diversos grupos de stakeholders
Vantagem: é possível coletar um grande número de ideias em um curto espaço de tempo, e diversas pessoas podem expandir essas ideias colaborativamente
Desvantagem: é menos eficaz quando a dinâmica do grupo é confusa ou quando há membros muito dominantes no grupo
Forma: Ideias são coletadas durante certo período de tempo, geralmente grupos de 5 a 10 pessoas. As ideias são documentadas por um moderador sem serem discutidas, julgadas ou comentadas. Os participantes usam ideias dos outros para desenvolver novas ideias originais ou modificar ideias existentes. Mais tarde, as ideias coletadas são submetidas a uma análise rigorosa
Brainstorming paradox
É uma modificação do brainstorming tradicional
As ideias coletadas são eventos que não devem acontecer
Riscos podem ser identificados antecipadamente com esse método, e medidas preventivas podem ser desenvolvidas
Mudança de perspectiva
Essa técnica é extraordinariamente benéfica quando os stakeholders não conseguem expressar seu conhecimento sem imparcialidade, ou quando estão obstinadamente presos a suas opiniões
Não pode ser aplicada se os requisitos exigem um nível de detalhamento muito preciso
Chamado método seis chapéus: cada chapéu representa uma perspectiva específica adotada por cada participante
As soluções daí resultantes abordam o problema a partir de perspectivas diferentes
Técnicas de analogia
Nessa técnica os problemas que o projeto enfrenta são comparados a uma situação análoga que ocorre na natureza
As soluções proporcionadas pela natureza são investigadas e então transferidas de volta ao projeto
Demanda muito tempo à disposição
Brainwriting (Método 6-3-5)
Usada quando existem muitos membros dominantes no grupo ou a dinâmica do grupo é confusa
Forma: 6 participantes, cada um escreve 3 ideias numa folha de papel. Esta folha é repassada aos outros membros, que comentam e desenvolvem as ideias recebidas, processo se repete por 5 vezes
Técnicas baseadas em documentos
Reutilizam soluções e experiências feitas com sistemas existentes
Técnicas baseadas em documentos devem ser combinadas com outras técnicas de elicitação para que a validade dos requisitos elicitados possa ser determinada
Arqueologia de sistema (Engenharia Reversa)
É uma técnica que extrai informações necessárias para construir um novo sistema a partir da documentação ou da implementação de um sistema legado, ou de um sistema concorrente
É a única técnica que pode assegurar que todas as funcionalidades do legado serão implantadas no sistema novo
A técnica é usada quando o conhecido explícito sobre a lógica do sistema foi parcialmente ou completamente perdido
Leitura baseada em perspectiva
É aplicada quando documentos precisam ser lidos a partir de uma perspectiva específica
Isso permite uma análise estritamente focada em partes específicas da documentação existente
Reutilização
Requisitos que foram compilados anteriormente e atualizados para um determinado padrão de qualidade podem ser reutilizados
Através da reutilização dos requisitos, os custos com os procedimentos de elicitação podem ser significatimente reduzidos
Técnicas de observação
Quando especialistas de domínio não se dispõem a dedicar o tempo necessário para compartilhar sua expertise com o engenheiro de requisitos ou se eles não são capazes de expressar e representar seu conhecimento, as técnicas de observação são muito úteis
Durante a observação o engenheiro de requisitos observa os stakeholders enquanto trabalham
O engenheiro de requisitos documenta todos os passos e dessa forma elicita os processos que o sistema deverá suportar, bem como potenciais erros, riscos e questões em aberto
Técnicas de observação são muito apropriadas para elicitar requisitos detalhados e fatores básicos de satisfação
Essa técnica não é indicada para o desenvolvimento de novos processos
Observação de Campo
O engenheiro de requisitos acompanha os usuários do sistema no próprio local de trabalho, observa e documenta os processos e procedimentos operacionais executados
A partir dessas observações, o engenheiro de requisitos formula os requisitos
Essa técnica é apropriada para procedimentos operacionais que são difíceis de expressar verbalmente
Só pode ser utilizada se os procedimentos são fisicamente visíveis
Apprenticing
Nessa técnica o engenheiro de requisitos precisa ativamente aprender ou realizar os procedimentos dos stakeholders
Dessa forma, ele pode vivenciar requisitos que os stakeholders consideram absolutamente óbvios e por isso não conseguem elucidar
Técnicas de apoio
Funcionam como apoio adicional para as técnicas de elicitação e procuram compensar eventuais pontos fracos e desvantagens da técnica de elicitação selecionada
Mapas mentais
Cria-se uma representação gráfica dos relacionamentos e das interdependências refinadas entre termos
São usados como técnica de apoio para o brainstorming ou brainstorming paradox
Workshops
Em reunião conjunta, o engenheiro de requisitos e os stakeholders elaboram os objetivos do sistema ou detalhes de uma certa funcionalidade
Cartões CRC
Aspectos do contexto e seus respectivos atributos e propriedades são anotadas em fichas de arquivo. Requisitos são formulados utilizando essas fichas
Gravações de áudio e vídeo
São apropriadas para elicitar requisitos quando os stakeholders não estão disponíveis, quando o orçamento é limitado ou quando o sistema é altamente crítico
A desvantagem dessa técnica é que os stakeholders muitas vezes têm a sensação de estarem sendo supervisionados ao serem filmandos
Modelar sequências de ações
Documenta a visão externa do sistema a ser desenvolvido
Um caso de uso possui um evento desencadeador (trigger) que dispara o caso de uso, bem como um resultado esperado (outcome)
Cada caso de uso é uma funcionalidade que deve ser suportada pelo sistema a ser desenvolvido
Protótipos
São apropriados para questionar requisitos estabelecidos e elicitar requisitos em situações onde os stakeholders apenas têm uma vaga compreensão do que necessita ser desenvolvido
Consequências potenciais de requisitos novos ou modificados podem mais facilmente ser identificados
O uso de técnicas de elicitação apropriadas é uma competência decisiva para o sucesso do projeto. Os melhores resultados são alcançados com uma combinação de várias técnicas diferentes de elciitação
As técnicas de elicitação têm por objetivo revelar tanto os requisitos subconscientes (que atendem aos fatores básicos de satisfação) quanto os requisitos conscientes (que atendem aos fatores esperados de satisfação) e inconscientes (que atendem aos fatores de entusiasmo) dos stakeholders
O principal objetivo de todas as técnicas de elicitação é auxiliar o engenheiro de requisitos a identificar o conhecimento e os requisitos dos stakeholders
Não existe um método universal para elicitar esses requisitos
Fatores mais influentes na escolha de técnicas apropriadas de elicitação
A distinção entre requisitos conscientes, inconscientes e subconscientes a serem elicitados
As restrições em termos de tempo e de orçamento, bem como de disponibilidade dos stakeholders
A experiência do engenheiro de requisitos com determinada técnica de elicitação
As oportunidades e riscos do projeto
É recomendável combinar diferentes técnicas, pois isso minimiza muitos dos riscos inerentes ao projeto
Engenheiros de requisitos
Direitos e deveres
Falar a linguagem dos stakeholders
Familiarizar-se inteiramente com o domínio da aplicação
Criar um documento de requisitos
Ser capaz de apresentar resultados de trabalho (por meio de diagramas e gráficos)
Manter um relacionamento respeitoso com stakeholders
Apresentar suas ideias e alternativas, bem como seus resultados
Permitir que os stakeholders demandem propriedades do sistema que venham a simplificar e facilitar sua utilização
Assegurar que o sistema atenda às exigências funcionais e de qualidade dos stakeholders
Stakeholders
Direitos e deveres
Introduzir o engenheiro de requisitos no domínio da aplicação
Suprir o engenheiro de requisitos com requisitos
Documentar cuidadosamente os requisitos
Tomar decisões em tempo hábil
Respeitar as estimativas de custo e viabilidade feitas pelo engenheiro de requisitos
Priorizar requisitos
Inspecionar os requisitos que o engenheiro de requisitos documenta
Aderir ao processo de mudança previamente determinado
Respeitar o processo de engenharia de requisitos implantado
Resumo
É importante estabelecer inicialmente um acordo sobre direitos e responsabilidades mútuas entre os stakeholders e o engenheiro de requisitos para facilitar a comunicação e a cooperação, bem como integrar os stakeholders no processo de elicitação
A escolha da técnica de elicitação correta para o respectivo projeto é feita pelo engenheiro de requisitos com base nas restrições culturais, organizacionais e de domínio encontradas