Please enable JavaScript.
Coggle requires JavaScript to display documents.
Elicitação de requisitos de software (Granularidade de requisitos (:anchor…
Elicitação de requisitos de software
Tipos de requisitos (de sistema)
Definição de requisitos
Funcionalidade ou capacidade do sistema (Req de sistema) - Visão sistemica
Necessidade do stakeholder (Req de usuário) - Visão de negócio
Documentação
Funcional
Funcionalidades que o sistema precisa ter
Não funcional
Qualidade
Restrição
Técnicas de elicitação de requisitos
:heavy_plus_sign:Ao buscar requisitos esperados
:studio_microphone:Entrevista
Formal
Informal
Como fazer
Prepare-se
Escolha o ambiente para fazer a reunião
Conheça os stakeholders
O que fazem
Qual o nivel de autoridade
Quem são
Quanto tempo terá disponivel
Escolha das ferramentas que serão usadas
Pode utilizar Observação
Escolha os stakeholder corretos
Execução
Saber fazer uma entrevista
Comunique-se bem
Linguagem não-verbal
Remova qualquer pensamento negativo da cabeça
Acredite no projeto
Empatia
Mostrar para o stakeholder que de alguma forma voces pensam igual e estão com os mesmos objetivos.
Estude o negócio
Objetivo
Tirar o conhecimento de dentro da cabeça do stakeholder
Trazer o que aconteceu no mundo objetivo para o mundo subjetivo do engenheiro de requisitos ou mesmo do stakeholder
Se possivel faça Observação, em seguida Aprendizagem e depois a Entrevista
:heavy_check_mark:Questionário
Muitos usuários
Estatística
Sem feedback
:eye:Observação
Sem interferir
Lute para criar esse tipo de cultura na empresa
:books:Aprendizagem
Entrar na empresa como estágiario
:silhouette:Modelagem de casos de uso
:heavy_minus_sign:Ao buscar requisitos obvios
Buscar conceitos chaves
Perceber quais os conceitos o stakeholder repete com frequência
Pergunte o que ele quer dizer com esses termos
Pergunte mesmo que você pense que saiba
Leia documentos
Procure em sistemas existentes
Faça pesquisas na internet sobre as palavras chaves
Sempre valide um óbvio quando você achar que encontrou
Procure pessoas ou stakeholders que possam trazer mais conhecimento sobre o assunto
:heavy_plus_sign::heavy_plus_sign:Ao buscar requisitos surpresas
Brainstorming
Fale coisas ridiculas
Se fossemos destruir tudo e fazer do zero o que você faria
Técnica dos seis chapéus
Técnica de analogia
Tras uma situação hipotética, resolve ela, e então retorna a situação real
É como foi encinado no curso da Udacity para resolver problemas
Categorias de requisitos
Categorização por satisfação do stakeholder
Óbvios
Ele não fala, mas deve ser feito
Não possui muito impacto na satisfação
Gera muita insatisfação se não cumpridos
A principal fonte de requisitos aqui é documentação, ou um sistema em funcionamento.
Surpresa
Aprender a achar
Impactam positivamente a satisfação do cliente
A principal fonte aqui é técnicas de criatividade como Brainstorm
Esperados
Entender o que foi aprendido
Gera satisfação
Gera insatisfação se não cumpridos
A principal fonte de requisitos aqui é o stakeholder (procure
Passo - a - Passo
Trabalhe na elicitação dos esperados (se são realmente necessários)
Trabalhe nas elicitações do óbvio
Trabalha nas elicitações das surpresas
Modelo KANO
Modelo QFD
Tópicos de comunicação
Teoria dos tópicos de comunicação
Emissor
Emita validações para o receptor para chama-lo a conversa
Você concorda? Você entendeu?
Receptor
Feedback
Linguagem não-verbal
Ruídos
Email
Online
Coisas que podem causar mal entendidos
Rapport (PNL)
Visão geral de documentação
Linguagem natural
Geram mais ruídos, ambiguidades
São mais baratas
User Stories
Modelos
Exigem conhecimento técnico
Diminuiem os ruídos
UML
Estabeleça regras de como será documentado
Uma documentação boa utiliza as duas formas (modelos + LN)
Caso de uso pode ser usado para elicitar e já documentar
Perfil do engenheiro de requisitos
Papel no mercado
Engenheiro de requisitos
Está preocupado em definir como a tecnologia pode dar suporte aos processos de negócio
Não está preocupado em resolver processos de negócio
Trabalho com requisitos de sistema
Todos esses perfis lidam com a intersecção entre o dominio de negócios e o domínio de tecnologia
Analista de negócio
Está preocupado com os processos de negócio da empresa. Se estão corretos ou podem ser diferentes
Se preocupa em utilizar a tecnologia para melhorar o negócio
Trabalha com requisitos de negócio
Product Owner
Segundo a literatura, está imerso no domínio do negócio.
Na prática, depende da empresa, pode até ser alguém totalmente técnico
Trabalha com requisitos de negócio
Na prática todos esses conceitos se misturam. O ponto é que a engenharia de requisitos trata-se de fazer a intersecção entre dominio de negócios e tecnologia
Engenheiro de requisitos se confunde com Analista de Negócio no mercado
Comunicador
Mediador
Resolvedor de problemas
Não pode ser um trator ou gerador de conflitos
Conhecimento de negócio
Quando tiver falando com alguém de negócio eu sou bT
Quando tiver falando com alguém de tecnologia eu sou Bt
Conhecer do negócio não é ter razão.
Se você souber mais do que o T ou B, finja que não saiba. Nunca confronte, sugestione.
Estabelecer parcerias
Granularidade de requisitos
:anchor:Busque pontos de ancoragem
Quanto mais conhecimento sobre o assunto tiver mais pontos de ancoragem, estude o assunto
Muitas vezes o stakeholder começa a entrar nos detalhes logo no início, isso prejudica o processo. Pois primeiro é preciso ancorar.
Em uma abordagem Top-Down (Ancore no Top onde está os genéricos)
Como definir o nível de detalhamento necessário para a elicitação de requisitos
Estabeleça regras de comunicação
Não adianta o stakeholder ficar falando detalhes que não são importantes no momento
Num primeiro momento apenas peça para ele definir os processos do negócio
Você pode utilizar um mapeanto de processos
Você pode usar um diagramas de caso de uso
o detalhamento será feito conforme for necessário entrar em cada processo
Defina a complexidade
Quanto mais complexo o negócio mais grossa deve ser a granularidade
Estorias de Usuário permitem que a granularidade não afine antecipadamente
A granularidade está o mais fina possível quando o desenvolvedor está pronto para implementar
Granularidade da documentação
Deve ser o mais simples possível
Dependendo da afinidade entre o cliente e o engenheiro o documento precisa ser um pouco mais detalhado
Não estresse demais em casos de usos ou estórias de usuárioa
Tem muita similaridade com Impact Mapping em fazer o que é mais importante primeiro