Treinamento

Análise de Negócio
Objetivos
• Apresentar técnicas e práticas de análise de negócios com foco em requisitos
de software.
Agenda
• Técnicas de Levantamento de Requisitos
• Analista de Negócio
• Feature
• User Story e Critérios e Aceitação
• Relato de Bugs
• Requisitos Não Funcionais
• Fluxos
• Personas
• BPMn
• DoR e DoD
• Demo (Review)
• Rastreabilidade
• Product Backlog Building
• Ferramentas de Estratégia
Benefícios
• Estabelecer um ponto de equilíbrio, definir uma linguagem comum, que facilite
o entendimento e a comunicação entre o pessoal de negócio e os
desenvolvedores.
• Facilitar o entendimento entre os envolvidos
• Ter uma linguagem objetiva, simples e comum
• Usar diversas técnicas para melhorar a comunicação e o entendimento
• Otimizar o tempo de entendimento da solicitação
Técnicas de Levantamento de
Requisitos
Atividades macro
• Sommerville (2003) propõe um processo genérico de levantamento e análise que contém as
seguintes atividades:

• Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio

da aplicação;
• Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para
descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa
atividade;
• Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os
organiza em grupos coerentes;
• Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos
apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
• Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais
importantes do que outros. Esse estágio envolve interação com os stakeholders para a
definição dos requisitos mais importantes;
• Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e
consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
Entrevistas
• A entrevista é normalmente a primeira técnica utilizada.
• Analistas entrevistam clientes para definir os objetivos gerais e restrições que o
software deverá ter.
• A entrevista deve ser feita de forma objetiva visando obter o máximo de
informações do cliente.
• Diversas seções de entrevistas podem ser marcadas.
• Entrevista com os usuários geralmente é a técnica mais utilizada para coleta de
informações.
Entrevistas - Dicas
• Informe qual é objetivo da entrevista e como a pessoa poderá contribuir.
• Escolher os entrevistados certos, ou seja, aqueles que podem e querem dar
informação.
• Fazer mais que uma entrevista para o mesmo tema. A diversidade de visões
podem ajudar no entendimento .
• Respeitar horários.
• Escutar o entrevistado.
• Manter “o foco” da entrevista.
Questionários
• Preenchimento de questionário é uma técnica eficiente para coleta de
informações, principalmente quando o número de usuários é muito grande.
Questionários - Dicas
• Faça um workshop para explicar o qual é objetivo do questionário.
• O questionário deve ser objetivo e de fácil preenchimento.
• Não faça um questionário muito longo, pois, responde-lo pode ser cansativo e
desinteressante.
• Estabeleça prazos para entrega do questionário.
• Ajude as pessoas com dúvidas sobre as questões.
Observações in-loco
• Observação permite capturar “como” os usuários fazem suas atividades e
tarefas.
• Na observação in loco os analista devem estar inseridos na rotina de trabalho
da organização tentando entender e descrever as principais atividades que são
realizadas.
• Na observação devem ser identificadas quais as atividades podem ser
automatizadas, quem são os potenciais usuários, quais tarefas eles querem
realizar com a ajuda do sistema, etc.
• A observação deve ser complementada com entrevistas específicas com os
futuros usuários.
Observações in-loco - Dicas
• Informe qual é objetivo da observação.
• Escolher os observados certos, ou seja, aqueles que podem e querem dar
informação.
• Observar pessoas diferentes para obter a diversidade de visões.
• Respeitar a privacidade dos observados.
• Respeitar horários.
• Não fazer inferências.
• Seja discreto.
Workshop
• Além de ser uma técnica para coleta de informação, o Workshop é uma
ferramenta de prototipação.

• Participantes: desenvolvedores, usuários, cliente (PO) e etc.

• Fazer uma sessão de “brainstorming” para geração de ideias e estórias.

• Algumas estórias do usuário estarão prontas para implementar.
• Outras serão “Épicos”. No futuro elas deveram ser decompostas.
• Não existe a necessidade de priorização.
Workshop - Regras
• O objetivo é a quantidade, ao invés de qualidade. Ou seja, aqui a ideia é
identificar e escrever o máximo de Estórias do Usuário possíveis.
• Foco no “alto nível de abstração”, ou seja, não perder tempo detalhando ou
discutindo demais alguns assuntos.
• Não julgar as ideias. A menos que seja algo fora do propósito, algumas Estórias
do Usuário que pareçam inúteis, podem dar vazão a outras ideias.

• No final do workshop devemos ter uma visão mais clara do produto suas
funcionalidades e será mais fácil identificar, escrever e refinar as estórias do
usuário.
Prototipagem
• Protótipo tem por objetivo explorar aspectos críticos dos requisitos de um
produto, implementando de forma rápida um pequeno subconjunto de
funcionalidades deste produto.
• O protótipo é indicado para estudar as alternativas de interface do usuário;
problemas de comunicação com outros produtos; e a viabilidade de
atendimento dos requisitos de desempenho.
• As técnicas utilizadas na elaboração do protótipo são várias: interface de
usuário, relatórios textuais, relatórios gráficos, entre outras.
Prototipagem
• Alguns dos benefícios do protótipo são as reduções dos riscos na construção
do sistema, pois o usuário chave já verificou o que o analista captou nos
requisitos do produto.
• Para ter sucesso na elaboração dos protótipos é necessária a escolha do
ambiente de prototipagem, o entendimento dos objetivos do protótipo por
parte de todos os interessados no projeto, a focalização em áreas menos
compreendidas e a rapidez na construção.
Boas práticas
• Preparação: Prepare-se previamente e de forma adequada para as atividades
planejadas, as quais são geralmente realizadas através de entrevistas,
questionários, brainstorms e workshops.
• Stakeholders: Mapeie (com antecedência) quem serão os participantes do
processo, quais os seus papéis no projeto e na organização e quais são os seus
níveis de conhecimento e influência. É imprescindível que as pessoas corretas
sejam envolvidas o quanto antes.
• Postura: Busque sempre a efetividade nas comunicações, assim como procure
demonstrar ponderação durante as situações de conflito.
• Entendimento: Procure focar no entendimento do problema e evitar
conclusões precipitadas. Nesse primeiro momento o mais importante é saber
escutar.
Boas práticas
• Experiências passadas: Utilize de forma positiva as experiências vividas
anteriormente para ajudar a melhor compreender o problema. Evite
considerar que o problema atual é igual a algum outro que tenha sido
resolvido em um cliente ou projeto passado.
• Documentação: descreva o problema de forma clara e objetiva. Em caso de
dúvidas, consulte o cliente e evite inferências. Procure usar exemplos citados
pelos stakeholders. A adoção de diagramas e figuras sempre ajuda na
documentação e entendimento dos requisitos. A criação de protótipos
também contribui para o entendimento comum da solução proposta.
• Validação: Faça com que os stakeholders validem a documentação, verificando
o entendimento do problema e as melhorias desejadas e eventualmente façam
solicitações de mudanças.
Cenários
• Cenários contêm informações que podem ser extraídas mais detalhadamente
com o objetivo de detalhar os cenários.
• Além dos cenários, a análise do perfil dos usuário e das tarefas que eles
executam permitem um maior conhecimento do domínio, possibilitando uma
melhor especificação dos requisitos.
• Conhecer a situação atual e antecipar o impacto que um novo sistema deve ter
é fundamental para o seu sucesso.
• Cenários são uma maneira excelente de representar, para clientes e usuários,
os problemas atuais e as possibilidades que podem surgir.
• Em resumo, os cenários permitem compreensão dos problemas atuais pelos
analistas e antecipação da situação futura pelo clientes e desenvolvedores.
Cenários - Exemplos
Cenários - Exemplos
Exemplos
• Exemplo
Considere o seguinte cenário sobre um caixa eletrônico.

• Questão de elicitação do cenário:

• Como posso sacar R$ 100,00 do caixa eletrônico?
• Cenário: Primeiro ponha o seu cartão do banco no caixa eletrônico, digite a sua senha
e pressione o botão "saque rápido". Depois pegue o dinheiro.

• As duas sentenças do cenário acima contém quatro proposições: CLIENTE -- põe --

CARTÃO
CLIENTE -- digita -- SENHA
CLIENTE -- pressiona -- BOTÃO-DE-SAQUE-RÁPIDO
CLIENTE -- pega -- DINHEIRO
Exemplos
Story Mapping
• A US Mapping é uma técnica ágil utilizada para levantar e organizar requisitos,
exigindo apenas a combinação de
• um mediador experiente,
• uma parede (tão grande quanto o projeto),
• muitos post-its,
• canetões, fita crepe e os
• convidados que podem e devem contribuir para a visão dos desejos relativos ao produto
• Ideal fazer com até 10 pessoas.
• Quanto ao tempo, pode durar um turno, um dia ou mais, conforme estiver claro para
os participantes quanto ao entendimento do que esperam do produto, quão
complexo pode ser,
• Mas mais que regras de tempo é importante bom senso e um facilitador experiente.
• Tudo isto, é claro, contando com as pessoas certas – PO, UX, SEO, executivo, key
users, referências do business, técnicas e criativas.
Story Mapping - Benefícios
1. Ajuda a entender, como o todo, o que o sistema faz.
2. Ajuda a entender o que as pessoas estão construindo.
3. Ajuda a fazer um planejamento de Release e que todo mundo entenda.
4. Visão mais clara do que é preciso fazer primeiro e o valor agregado.
5. Ponto de colaboração.
6. Capta requisitos e priorizá-los de uma forma ágil.
7. Divertido
Preparação e ambientação
Desenvolvimento
Release Plan
Story Mapping - Etapas
Exemplo
Backlog Grooming
• Cuidar do product backlog significa gerenciar o backlog. Isso é necessário, já
que o product backlog muda e evolui com o conhecimento da equipe e
contato dos usuários com o produto.
Backlog Grooming - Definição
• A equipe (ou parte da equipe, incluindo o proprietário do produto) se reúnem
regularmente para "novo product backlog", em uma reunião formal ou
informal que pode levar a qualquer um dos seguintes:
• A descoberta de novos itens, assim como alteração e remoção de itens antigos.
• Quebrar Estórias muito grandes (épicos).
• A priorização dos itens do backlog (trazendo os mais importantes para o topo).
• Preparar e refinar os itens mais importantes para a próxima reunião de planejamento.
• Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas).
• Incluir Critérios de Aceitação.
Product Backlog Grooming Steps
• Passo 1: Analisar o feedback

• Passo 2: Integrar a aprendizagem

• Passo 3: Decida o que fazer a seguir

Product Backlog Grooming Steps
• Etapa 4: Criar Pequenas Histórias

• Passo 5: Pronta para implementação

Analista de Negócio
A importância da especificação
• Ou seja, repare que nos exemplos citados anteriormente, informar para quem
e por que a funcionalidade está sendo desenvolvida ajudou o desenvolvedor a
tomar decisões mais alinhadas com a necessidade do cliente. Isto tem como
consequência um ganho significativo de qualidade!

• O Analista de Negócio não pode se comportar como um “tirador de pedido”

ou mero “escriba de requisitos”
Características de requisitos de software ágeis
• Os requisitos são definidos de forma iterativa e incremental
• Os requisitos são mantidos em backlogs, não em um documentos de requisitos
• Os requisitos não passam por um processo formal de “contratos”
• Os requisitos da solução são definidos através de conversas entre a equipe e os
usuários
• O trabalho de análise de negócio é feito em incrementos
• O analista de negócio trabalha em uma equipe de forma colaborativa
• Há mais comunicações verbais e visuais do que documentos em papel
• Apenas o trabalho suficiente é feito
• O cliente tem que estar próximo da equipe
• O feedback deve ser rápido
Boas Práticas de Comunicação
• Ter uma linguagem comum
• Ter simplicidade
• Ser objetivo
• Usar diversas técnicas para melhorar a comunicação e o entendimento
• Dar preferência a comunicação face-a-face

• Objetivo da boa comunicação: Facilitar o entendimento

Analista de Negócio
• Um Analista de Negócio é qualquer pessoa que exerça atividade de análise de
negócio, não importando qual seja seu cargo, função ou papel.
• Entendimento do negócio e contexto
• Ponte entre o desenvolvimento e o cliente
• Homologação com equipe e cliente
• Escrita das estórias de usuário
Responsabilidades do Analista de Negócio
• As atividades que analistas de negócios incluem:
• Elicitar (identificar) as necessidades reais das partes interessadas
• Fazer o alinhamento entre design das soluções e as necessidades das partes interessadas
• Compreender problemas da empresa e metas
• Analisar necessidades e soluções
• Elaborar de estratégias
• Desenvolver soluções
• Impulsionara mudança e
• Facilitar a colaboração das partes interessadas
Competências do Analista de Negócio
• Ser bom ouvinte
• Ser um bom questionador
• Ser observador
• Escrever bem
• Ser organizado
• Ser criativo
Competências do Analista de Negócio
• Para conhecer o negócio, o Analista de Negócio, precisa ter:
• Visão de Negócio (Estratégia)
• Visão de Processos (Operação)
• Visão de Valor de Tecnologia
Visão de Negócio
Visão de Processos
Visão de Valor da Tecnologia
Dicas importantes
• O cliente sabe mais do que você sobre o negócio dele. Ele vive aquilo.
• A equipe de negócio deve facilitar o fluxo das informações e garantir o
entendimento
• Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em
conjunto e diariamente, durante todo o curso do projeto.
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos
ágeis se adequam a mudanças, para que o cliente possa tirar vantagens
competitivas.
Feature
Solução
FDD - Feature Driven Development
• Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é
uma metodologia ágil para gerenciamento e desenvolvimento de software.
• Ela combina as melhores práticas do gerenciamento ágil de projetos com uma
abordagem completa para Engenharia de Software orientada por objetos,
conquistando os três principais públicos de um projeto de software: clientes,
gerentes e desenvolvedores.
FDD - Estrutura
FDD: Processo 1: DMA-Desenvolver um Modelo
Abrangente
• É uma atividade inicial que abrange todo o projeto, realizada por membros do domínio do negócio e
por desenvolvedores, sob a orientação de um modelador de objetos experiente, no papel de
arquiteto-líder.

• Realiza-se um estudo dirigido sobre o escopo do sistema e seu contexto. Então, são realizados
estudos mais detalhados sobre o domínio do negócio para cada área a ser modelada. Após cada
estudo dirigido sobre o domínio, pequenos grupos são formados por membros do domínio do
negócio sendo estudado e por desenvolvedores, que comporão seus próprios modelos que
satisfaçam o domínio em questão. Os pequenos grupos apresentam seus modelos para serem
revisados por parceiros e para discussão. Um dos modelos propostos, ou uma combinação dos
modelos, é selecionada por consenso, tornando-se, assim, o modelo para aquela área do domínio do
negócio. Realiza-se, então, uma combinação do modelo da área do domínio dentro de um modelo
abrangente, ajustando a forma do modelo se for necessário.

• O modelo de objetos é, então, iterativamente atualizado em seu conteúdo pelo processo nº 4

“Detalhar por Funcionalidade”.

http://heptagon.com.br/fdd1
FDD: Processo 2: CLF-Construir a Lista de
Funcionalidades
• É uma atividade inicial que abrange todo o projeto, para identificar todas as
funcionalidades que satisfaçam aos requisitos.
• Uma equipe, geralmente composta apenas por programadores-líderes do
processo nº 1, é formada para decompor funcionalmente o domínio em áreas
de negócio, atividades de negócio dentro delas e passos dentro de cada
atividade de negócio, formando assim a lista categorizada de funcionalidades.
A categorização de mais alto nível para a lista de funcionalidades vem da
divisão do domínio feita pelos especialistas do domínio no processo nº 1.

http://heptagon.com.br/fdd2
Explicação
• É um pedaço de funcionalidade que agregue valor aos negócios.
• Expressa na forma ARO <action> <result> <object>.

• Características:
• Ele deve fornecer o valor do negócio
• Deve ser estimável - ele deve ter definição suficiente para a equipe de
desenvolvimento para fornecer uma estimativa do trabalho envolvido na sua
implementação
• Ele deve ser pequeno o suficiente para caber dentro de uma iteração -
portanto, se for muito grande, deve ser subdividida
• Ele deve ser testável - você deve entender o que automatizado ou teste
manual uma característica deve passar a fim de ser aceitável para o cliente
Exemplo
• Calcular o total de uma venda
• Calcular a quantidade total vendida por um varejista para uma descrição de
produto.
• Imprimir comprovante de itens com descontos
• Registrar preço por EAN
• Solicitar número de autorização da finalizadora
• Limitar o peso máximo da balança
• Efetuar acréscimo em um item

• Mais exemplos
Exemplo
Exemplo
Exemplo
Exemplo
Exemplo
Exemplo
Exemplo
Mapa de Funcionalidades
Exemplo
Exemplo
Exemplos
• Site Portal
• ClickPygg
User Story e Critérios de
Aceitação
Solução
O que é uma história de usuário?
• Uma história de usuário descreve funcionalidades que tragam valor para o
usuário de um sistema de software. Elas são compostas de três aspectos:
• Uma descrição por escrito da história que será usada para planejar e como um lembrete
• Conversas sobre a história que servem para aprofundar os detalhes da história
• Testes que transmitem e documentar detalhes e como ela será utilizada quando
implementada
Conceito 3C
• O conceito do 3C é baseado em iniciar com a escrita de uma ideia em um
cartão, para que possamos lembrar. O cartão é o primeiro C. E ele leva ao
próximo, gerando um “lembrete para a conversação”.
• Que é o que precisamos gerar, conversas. O objetivo com isto é validar as
ideias, com pessoas que podem ajudar no tópico. O melhor nestas conversas é
criar exemplos que ajudem a validar a mesma.
• Estes exemplos acabam virando depois cenários de aceitação da história. Se é
um cálculo, exemplos de cálculos. Através deste processo, criamos um “cartão
executável“. E este é o nosso segundo C.
Conceito 3C
• Estas conversas ajudam o time a identificar alguns atributos para os cartões,
exemplo?
• senso de valor
• prioridade
• risco associado
• qualquer-atributo-que-o-time-consiga-ver-valor
• O terceiro C é sobre confirmação. Através das conversas com o time e clientes
poderemos entender como validar o cartão e confirmar que o que temos
definido é o necessário para “fazer acontecer“. E então é isto que precisamos
buscar, confirmação! E dos nossos clientes! Eles irão confirmar sua ideia e
ajudar a mesma a crescer.
Características das histórias de usuário
• Colaboração com cliente: A história do Usuário é escrita em colaboração entre
os desenvolvedores e o cliente.
• A prioridade é satisfazer o cliente, entregando o mais rápido possível e de
forma contínua software que tenha valor: Para satisfazer o cliente é preciso
entendê-lo. A história ajuda a melhorar o entendimento da necessidade do
cliente para que ocorra a entrega de valor.
• Conversa é SEMPRE a melhor forma de comunicação: Converse com o seu
cliente, escreva a história do usuário e transmita para equipe na Reunião de
Planejamento (Planning Meeting).
História do Usuários x
Especificações de Requisitos
• A maior diferença está no nível de detalhe. História do Usuários só devem
fornecer detalhes suficientes para “chegar” no entendimento do que deve ser
feito e facilitar a estimativa de velocidade da equipe.
• Quando escrevemos uma História o foco é nas necessidades do usuário,
devemos evitar os detalhes técnicos, tais como descrição de tecnologia,
desenho das interfaces do usuário, wireframes, modelo de dados, algoritmos e
etc.
Boa Prática: Mantenha a História focada nas necessidades do usuário e nos
benefícios.
O Modelo
Padrão de escrita
• Existem 3 informações que são fundamentais nas histórias de usuário, são elas:
• Quem? Para quem estamos desenvolvendo a funcionalidade.
• O que? Uma descrição resumida da funcionalidade em si.
• Por que? O motivo pelo qual o cliente precisa desta funcionalidade. Se possível citando o
valor de negócio obtido.

• Normalmente para responder as três perguntas citadas acima nós usamos o

SENDO... POSSO... PARA QUE...
Padrão de escrita
• SENDO um vendedor que realiza 50 visitas por dia
• POSSO consultar as últimas compras de cada cliente
• PARA QUE ao chegar no cliente eu possa consultar qual foi sua última compra,
e assim conseguir negociar com ele estando melhor informado.

• Repare que no SENDO nós identificamos o perfil do usuário que vai usar a
funcionalidade, no POSSO a funcionalidade em si que precisa ser desenvolvida
e no PARA QUE a motivação da funcionalidade, incluindo o valor de negócio.
Padrão de escrita
• Com estas informações, o desenvolvedor vai conseguir trabalhar “mais
armado”, e provavelmente vai criar uma funcionalidade mais bem elaborada
do que se recebesse apenas a necessidade do cliente, sem o detalhamento de
quem vai usar e por que vai usar.
História de Usuário Mínima
Exemplos
Conversas
• No SCRUM as conversas geralmente acontecem na Reunião de Planejamento
da Sprint (Planning Meeting)
• Também durante o desenvolvimento da Sprint.
• Mas, também elas podem ocorrer durante o Workshop de Requisitos e de
Escrita de História que é realizado antes da Reunião de Planejamento.
• Ela deve acontecer sempre que for necessário
Conversas

Cliente Analista de Negócio

Equipe de Desenvolvimento
Testes de aceitação
• Toda história deve ser associada a pelo menos um Teste de Aceitação, o ideal é
ter um conjunto de testes. Estes testes definem as respostas que a
funcionalidade deve fornecer de acordo com a utilização por parte do usuário.
Estes testes se materializam na forma de “scripts” que indicam os resultados
desejados (esperados) bem como os resultados indesejados e que não devem
ser providos pelo sistema.

• Os Testes de Aceitação devem ser mais detalhados do que as histórias. Isto, por
duas razões:
• A primeira e mais importante: Para validar se a História do Usuário foi corretamente
implementada (codificada).
• E a segunda: Para prover o máximo de informações sobre a História.
BDD (Behavior Driven Development)
• É uma metodologia de desenvolvimento ágil que estimula a participação de todos os
membros da equipe, desenvolvedores, analistas e gestores do projeto.
• Utilizando o conceito de linguagem ubíqua onde o foco é o fluxo em que o código deve ser
escrito, não gerando a necessidade de conhecimentos técnicos, permitindo então que
qualquer pessoa com conhecimento técnico ou não possa montar os cenários de teste.
• Exemplo: Todos devem usar os mesmos termos tanto na linguagem falada quanto no código.
Isso significa que, se durante uma conversa com um cliente do sistema de cobrança, por
exemplo, ele disser: “Temos que emitir a fatura para o cliente antes da data limite”, vamos
ter no nosso código alguma coisa do tipo:
• Uma classe para a entidade Cliente;
• Uma classe para a entidade Fatura;
• Algum serviço que tenha um método emitir;
• Algum atributo com o nome de data limite.
• Essa linguagem ubíqua deve ser compreendida por todos e não pode haver ambiguidades.
Práticas de BDD
• Estimular a participação de todas as partes no processo.
• Enfatiza o detalhamento posterior
• Para desenvolver uma funcionalidade, utiliza-se exemplos de seu
comportamento.
• Automatização dos exemplos e das histórias de usuário.
Princípios e metodologia
• No BDD há um princípio, uma metodologia:
• Dado que (Given)
• Quando (When)
• Então (Then)

• Essa metodologia não é obrigatória, mas é largamente utilizada pelos

desenvolvedores do mundo todo que adotam o BDD.
Exemplos – User Story
• Lembrando a história de usuário:

• SENDO um vendedor que realiza 50 visitas por dia

• POSSO consultar as últimas compras de cada cliente
• PARA QUE ao chegar no cliente eu possa consultar qual foi sua
• última compra, e assim conseguir negociar com ele estando melhor informado.
Cenários de Testes de Aceitação
• Cenário 1: Estoque disponível
• Dado que o estoque da coca-cola é de 50 unidades
• Quando informo uma venda de 40 unidades
• Então a venda é registrada E o estoque passa a ser de 10 unidades

• Cenário 2: Estoque indisponível

• Dado que o estoque da coca-cola é de 50 unidades
• Quando informo uma venda de 60 unidades
• Então a venda não é registrada e é exibida na tela a mensagem “estoque insuficiente!”
Cenários de Testes de Aceitação
• Repare que nos exemplos anteriores nós usamos o “Dado que” para indicar o
cenário atual, o “quando” para indicar a ação do usuário, e o “Então” para
indicar como o software vai reagir.
• Podemos também usar o “E” e o “OU” para criar cenários de teste ainda mais
ricos.
Importante
• Você não precisa escrever os critérios de aceitação exatamente desta forma.
Mas é interessante que você registre de alguma forma os testes que devem ser
realizados para enriquecer a história de usuário e também para que ela possa
ser bem testada.
Mais exemplos...
• Saque no Caixa Eletrônico e Validando Tamanho do Arquivo
Tema
• Temas são coleções ou conjuntos de User Stories que estão relacionadas e,
assim, podem ser agrupadas.
• Razões para agrupar User Stories em temas incluem, entre outras:
• juntas definem uma meta de negócios específica;
• são provenientes de um mesmo épico;
• pertencem a um Time de Desenvolvimento em um ambiente com múltiplos times
trabalhando a partir de um mesmo Product Backlog.
• O agrupamento de User Stories em temas relacionados a metas de negócios
pode facilitar o trabalho de ordenação do Product Backlog em planejamentos
mais longos, mantendo-se o foco em quais metas são mais importantes de
serem atingidas primeiro ao invés de manter-se o foco em itens individuais.
Exemplo
Épico
• Épicos são User Stories que representam itens grandes demais ou sem
detalhes suficientes para serem desenvolvidos. Enquanto épicos, essas User
Stories somente necessitarão de mais detalhes quando ganharem prioridade.
• À medida que ganha prioridade, o épico ou parte dele evolui para User Stories
menores
• Os épicos são difíceis de planejar e estimar.
Exemplo
O conceito INVEST
• INVEST é um acrônimo (em inglês), que pode nos ajudar a revisar as histórias
de usuário para verificar se elas foram bem escritas.
• Independent (deve ser independente)
• Negotiable (deve ser negociável)
• Valuable (deve agregar valor para o cliente)
• Estimable (deve ser possível estima-la)
• Small (deve ser pequena)
• Testable (deve ser testável)
INVEST
Resumindo
• Uma boa história de usuário não deve depender de outra, deve ser possível
negociá-la de forma que você possa alterar sua prioridade e ordem de
execução com o cliente, deve agregar valor, deve ser estimável, deve ser
pequena (até para poder ser estimada), e deve ser testável.
Decompor histórias
• Decompor histórias de usuários de itens do Product Backlog maiores até que
eles sejam pequenos o suficiente para caber em um sprint.
• Pode começar a decomposição de uma história de alguns sprints com
antecedência para que possa ser implementado, principalmente se a história é
grande ou complexo.
• Permite reunir o feedback necessário de clientes, usuários e outras partes
interessadas antes de detalhar o item.
Exemplo
Exemplo
Quebrando História do Usuário em Tarefas
• Devemos buscar meios para facilitar a estimativa de velocidade da equipe,
quebrar a história em tarefas pode fazer que todos os membros da equipe
visualizem todas as tarefas que devem ser feitas para implementar a História
do Usuário.
Exemplo
Utilizar SMART para tarefas
SMART
• Específico: A tarefa deve ser específica o suficiente para que todos possam
entende-la. Ela deve ser simples, objetiva e concisa. Isso ajuda as pessoas a
compreender quais as tarefas devem ser adicionadas para completar história
do usuário
• Mensurável: Saber medir as tarefas é fundamental, pois, precisamos saber
quantas tarefas será possível fazer dentro da Sprint. Lembre-se de incluir
também as tarefas técnicas, tais como teste de aceitação. Para mensurar as
tarefas o ideal é conhecer a velocidade do time.
• Realizável: As tarefas podem ser feitas ? Existem algum débito técnico ou algo
que cause algum impedimento na realização das tarefas ? A equipe deve
identificar tudo aquilo que é necessário para realização da tarefa na reunião de
planejamento da Sprint.
SMART
• Relevante: Cada tarefa deve ser relevante, contribuindo para a história do
usuário. Todas tarefas consideradas irrelevantes para entrega da história deve
ser eliminada ou guardadas para uma próxima iteração. Somente as tarefas
relevantes devem fazer parte da Sprint.
• Time-Boxed: O Time-box (duração fixa) é um conceito aplicado a Sprint e não
as tarefas. Contudo, as tarefas devem caber dentro da Sprint. O time deve fazer
todas as tarefas do Sprint Backlog para que a meta da Sprint seja atingida,
quando isto não acontece será necessário negociar com o PO ou as tarefas
voltaram para Backlog.
Evolução das Histórias de Usuário
Funil do Ciclo de Vida
Product Backlog Iceberg
Hierarquia de Requisitos
Boas práticas
• Comece com histórias objetivas
• Fatie o bolo
• Escreva histórias fechadas
• Coloque as restrições nos cartões
• Escreva no horizonte
• Evite a interface de usuário o maior tempo possível
• Escreva para um usuário específico
• Inclua os papéis de usuários
• Escreve para a persona protagonista
Boas práticas
• Escreva em voz ativa
• Não enumere os cartões de users stories
• Descrever os bugs como critério de aceitação
• Não esqueça o propósito
• Combine mais do que uma técnica
Bed Smells
• User Stories muito curtas
• Histórias interdependentes
• História com muitos detalhes
• Pensar muito a frente
• Valor do negócio não explícito
• Funcionalidades desnecessárias
• Cliente não escrever, não confirmar e não priorizar
• Detalhes de UI antecipados
• Detalhes específicos de tecnologia, projeto e algoritmos
Dicas...
• Qualidade de software começa na especificação.
• Se a especificação do software é ruim, o resultado do trabalho provavelmente
será um software igualmente ruim.
• Além de “o que fazer” o desenvolvedor também merece saber “para quem” e
“por que” cada funcionalidade será desenvolvida.
• Dedique atenção especial aos critérios de aceitação. Eles estão diretamente
ligados a como seu software será testado.
• Define as técnicas e padrões de escrita para facilitar a leitura e também
otimizar o tempo de entendimento da solicitação.
Relato de Bugs
Solução
Antes de relator o bug
• Antes de reportar um bug, tenha certeza que:
• Isto é um bug: verifique se não é problema de configuração ou ambiente
• O bug já foi reportado: relacione a solicitação do cliente ao problema já reportado
• Utilize a última versão do sistema: Verifique se o problema foi corrigido na versão mais
recente
• Existe solução de contorno: Informe a solução de contorno ao cliente
Modelo
• LOCAL:
• Nome do Sistema - Módulo e Menu relacionado
• VERSÃO:
• Identificar em que versão do sistema envolvido o problema pode ser repetido.
Importante identificar se o problema pode ser repetido na última versão.
• PRÉ-CONDIÇÕES:
• Identifique o que deve estar configurado no ambiente para que o problema possa ser
repetido;
• Pode ser uma lista de configurações a serem marcadas;
• Ou simplesmente a indicação de que uma base de dados específica deve ser usada.
Modelo
• PASSOS PARA REPRODUÇÃO DO ERRO:
• 1) Monte uma lista indicando os passos que devem ser realizados para repetir o erro;
• 2) Você pode ser específico e identificar o que deve ser preenchido em cada campo;
• 3) Principalmente se uma base de dados específica está sendo usada para trabalhar;
• 4) Deve ser possível para qualquer pessoa repetir o erro lendo esta lista de passos.
• ERRO:
• Mostrar o erro que está acontecendo. Pode ser com uma identificação do que está
acontecendo de errado - e muito importante: mostrar contexto de negócio identificando
porque a situação atual é um erro.
• Anexe logs, print de telas, vídeos, backups de tabelas, bds, etc.
Modelo
• SITUAÇÃO DESEJADA:
• Descreva a situação que o sistema vai mostrar, identifique configurações que não estão
sendo consideradas, mostre o que deve ser modificado pensando em regras de negócio
para resolver a situação.
Exemplo
• LOCAL:
• SoftVendas – Módulo Mobile – Tela de vendas de produtos
• VERSÃO:
• Identificado na última versão (03.50), o problema não ocorre em versões anteriores.
• PRÉ-CONDIÇÕES:
• Acessar o ambiente de homologação;
• Logar com usuário “alfredo”, senha “xyz9988”;
Exemplo
• PASSOS PARA REPRODUÇÃO DO ERRO:
• 1) Uma vez já logado no sistema mobile, acesse o menu “Vendas”;
• 2) Selecione um cliente qualquer e abra uma nova venda;
• 3) Na tela de listagem de produtos, selecione qualquer produto;
• 4) Após selecionar um produto informe a quantidade a ser vendida (pode ser 10), e no
campo desconto informe um desconto (pode ser 10% de desconto)

• ERRO:
• Mesmo após informar o desconto, o valor total do produto segue sendo o mesmo que
era antes (sem o desconto).
Exemplo
• SITUAÇÃO DESEJADA:
• Que o valor total do produto considere o desconto aplicado, ou seja:
Valor total do produto = (Valor unitário * Quantidade) – Desconto.
Exemplo: Se valor do produto é 90,00, a quantidade informada é 10, e o percentual de
desconto é informado é 10%, então o valor total do produto deve ser 810,00.
Requisitos não funcionais
Solução
Requisitos não funcionais
• Eles impactam a experiência do usuário, e influenciam decisões de arquitetura
e design.
• Diz respeito aos aspectos técnicos que o seu sistema deve cumprir, tais como
questões relacionadas com o desempenho, problemas de confiabilidade e
problemas de disponibilidade.

• Tipos de requisitos não funcionais: Segurança, Performance, Usabilidade,

Confiabilidade, Padrões
Exemplos
• Registrar um produto na impressora fiscal X em menos de 1 segundo
• Requisitos mínimos para Android: Versão 2.3 ou superior e smartphone com
tela mínima de 3 polegadas com resolução média
• O sistema funcionará em nossa infraestrutura técnica existente
• O sistema deve estar disponível 99,99% do tempo para todo o período de 24
horas.
Fluxos
Solução
Explicação
• Os fluxogramas são uma técnica de modelagem introduzido em 1940/50 e
popularizado para o desenvolvimento estruturado na década de 1970 (Gane e
Sarson 1979), bem como modelagem de negócios.
Diagrama de Sequência
• Um diagrama de sequência descreve a maneira como os grupos de objetos
colaboram em algum comportamento ao longo do tempo. Ele registra o
comportamento de um único caso de uso e exibe os objetos e as mensagens
passadas entre esses objetos no caso de uso.
Diagrama de atividade
• O Diagrama de atividade é um diagrama definido pela Linguagem de
Modelagem Unificada (UML), e representa os fluxos conduzidos por
processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de
controle de uma atividade para outra. Comumente isso envolve a modelagem
das etapas sequenciais em um processo computacional.
Diagrama de atividade
Exemplo
Exemplos
Diagrama de caso de uso
• O diagrama de casos de uso corresponde a uma visão externa do sistema e
representa graficamente os atores, os casos de uso, e os relacionamentos entre
estes elementos. Ele tem como objetivo ilustrar em um nível alto de abstração
quais elementos externos interagem com que funcionalidades do sistema, ou
seja, a finalidade de um diagrama de caso de uso é apresentar um tipo de
diagrama de contexto que apresenta os elementos externos de um sistema e
as maneiras segundo as quais eles as utilizam.
Exemplo
Exemplo
Exemplos
Exemplo
Personas
Solução
Personas
• Oportunidade de entendimento e empatia ao conhecermos melhor cada
personagem, nos aproximando da realidade cotidiana deles.
• É uma forma de entrarmos na pele dos personagens que estarão presentes na nossa
caminhada, reduzir a distância entre nós, quem são, como pensam, influenciam e são
influenciados.
• Em startups, é um fator crítico de sucesso, precisando ser permanentemente
reavaliado e validado, sempre a procura de um melhor entendimento para
eventual redirecionamento.
• Inferimos qual seu perfil social (idade, hábitos, atividades, hobby), qual o seu
comportamento visível no trabalho (habilidades e atitudes) e quais são suas
necessidades (objetivos).
• Discute-se os objetivos da solução a ser construída, que é na prática a consolidação
das necessidades e objetivos de cada persona consolidados em objetivos gerais.
Personas
• Exemplo de resultado: Features, Objetivos e Personas, respectivamente em
azul, laranja e verde
Personas
Personas
• Mais exemplos
 BPMn
Business Process Model and Notation
Solução
Conceito
• O Business Process Model and Notation (BPMN, anteriormente conhecido como
Business Process Modeling Notation) (em português Notação de Modelagem de
Processos de Negócio) é uma notação da metodologia de gerenciamento de
processos de negócio e trata-se de uma série de ícones padrões para o desenho de
processos, o que facilita o entendimento do usuário.
• A modelagem é uma etapa importante da automação pois é nela que os processos
são descobertos e desenhados. É nela também que pode ser feita alguma alteração
no percurso do processo visando a sua otimização. A notação também pode ser
utilizada para a modelagem de Arquitetura de Processos.
• Foi desenvolvido pela Business Process Management Initiative (BPMI) e atualmente é
mantida pelo Object Management Group já que as duas organizações se fundiram
em 2005. Em março de 2011, a versão atual do BPMN é a 2.0.[1]
• A BPMN, desde o início, foi apoiada por várias empresas de renome mundial no
segmento de modelagem de processos, sendo uma resposta independente de
fornecedor de solução à demanda de modelagem de processos.
Elementos
• A modelagem em BPMN é feita através de diagramas simples, com um pequeno conjunto de
elementos gráficos. Isto facilita que os usuários de negócio, bem como os desenvolvedores,
entendam o fluxo e o processo. As quatro categorias básicas de elementos são as seguintes:
• Objetos de Fluxo
• Eventos, Atividades, Gateways
• Objetos de Conexão
• Fluxo de Sequência, Fluxo de Mensagem, Associação
• Swim lanes
• Pool, Lane
• Artefatos
• Objeto de Dados, Grupo, Anotação
• Obs: No BPMN versão 2.0 os Objetos de Conexão tem mais um elemento, "Associação de
Dados". Nessa versão foi adicionada mais uma categoria básica, "Dados".
• Estas quatro categorias de elementos nos dão a oportunidade de fazer um diagrama de
processos de negócio simples (BPD). Também é permitido em BPD, construir seu próprio
tipo de um Objeto de Fluxo ou um Artefato para tornar o diagrama mais compreensível.
Exemplos
• Exemplo Comanda
• Peguei emprestado
• Cartão Saúde
DoR e DoD
Solução
Conceito de “ready” - DoR
• Uma funcionalidade está especificada o suficiente para compor uma Sprint.
• Exemplos:
• Escrito com clareza e foi entendido por todos da equipe
• Possui granularidade suficiente para ser desenvolvido em um timebox.
• Testabilidade comprovada através de critérios de aceite.

• O nível de detalhamento e a clareza de uma user story/requisito é atingido

quando a equipe diz: Ah sim, Nós entendemos!
Conceito de “done” - DoD
• Uma funcionalidade só está completa quando submetida a critérios que
asseguram a sua qualidade.
• Exemplos:
• Desenvolvimento da funcionalidade
• Testes unitário
• Testes de integração
• Verificar se existem erros na build
• Avaliar o impacto de novas funcionalidades.

• O conceito de pronto só é atingido quando o que foi desenvolvido de fato

agrega algum valor para o cliente.
Demo (Review)
Sprint Review
• Demonstração para o cliente
• Utilizar critérios de aceitação
• Anotar feedback
• Atualizar backlog
Rastreabilidade
Rastreabilidade
• Rastreabilidade está, intimamente, ligada ao modelo de processo e ao próprio
processo de software.
• A partir de um processo definido e institucionalizado podemos recuperar
tudo aquilo que foi gerado para atender a especificação de um determinado
requisito.
• É importante salientar que para efetuar tal recuperação, de maneira eficaz, é
necessário utilizar uma ferramenta de gestão de processo de software.
• Já escolha do modelo se alinha com a volatilidade dos requisitos, fato este que
leva a maioria das empresas a utilizar o modelo incremental ou evolucionário.
Rastreabilidade
• Funcionalidades
• Documentos
• Códigos

• Exemplos:
• Confluence
• Mantis
Product Backlog Building
Product Backlog Building
• Product Backlog Building
Ferramentas de Estratégia
5W2H
Exemplo
Outras ferramentas
• Ferramentas Visuais para Estrategistas
Referencias
• http://historiasdeusuario.com.br
• Escrevendo Histórias do Usuário Eficazes – Rildo Santos
• http://pt.slideshare.net/Ridlo/escrevendo-estrias-do-usurio-eficazes?qid=a25c01be-ac4c-42cf-935d-
c07c4ab2f6d1&v=default&b=&from_search=1
• Analista de Negócio Ágil 3.0 – Rildo Santos
• http://pt.slideshare.net/Ridlo/analista-de-negcio-gil-30
• Análise de Negócio com Métodos Ágeis
• http://pt.slideshare.net/Ridlo/anlise-de-negcio-com-mtodos-geis
• http://www.romanpichler.com/blog
• Livro: User Stories Applied For Agile Software Development by Mike Cohn
• www.agilealliance.org
• http://www.agilebrazil.com/
• http://pt.slideshare.net/aolchik/agile-brazil-2013-impact-mapping-uma-abordagem-lean-
para-alcancar-os-seus-objetivos-de-negocio?qid=1162c2f6-a221-4856-b130-
100503fcb27d&v=qf1&b=&from_search=1
Referencias
• http://pt.slideshare.net/EnfocusSolutions/the-agile-business-analyst-41231700
• http://blog.andrefaria.com/sessoes-de-backlog-grooming-organizacao-do-backlog
• http://guide.agilealliance.org/
• http://www.brunonardini.com.br/processos-ageis/3-tecnicas-para-definir-e-
priorizar-user-stories
• http://pt.slideshare.net/swissq/introduction-priority-poker-en
• http://barryoreilly.com/2013/10/21/how-to-implement-hypothesis-driven-
development/
• http://agilemodeling.com/artifacts/changeCase.htm
• http://www.matera.com/br/2013/06/10/conceito-de-ready-and-done/
• http://maypun.blogspot.com.br/2011/04/retrospectiva-estrella-de-mar.html
• http://pt.slideshare.net/Ridlo/reumo-do-guia-babok-3-v1
Referências
• http://pt.slideshare.net/fabiogr/user-story-mapping-9594695
• http://www.slideshare.net/Ridlo/tcnicas-de-gesto-para-anlise-de-
negcio?qid=784a54ae-1eb0-4c06-95d1-0bd21c83978c&v=&b=&from_search=3
• https://www.dimap.ufrn.br/~jair/ES/c4.html
• http://heptagon.com.br/fdd-oque
• https://prezi.com/wzrm_icbitk4/engenharia-de-software-fdd/
• https://www.ibm.com/developerworks/community/blogs/tlcbr/entry/boas_praticas
_para_a_elicitacao_de_requisitos?lang=en
• http://imasters.com.br/artigo/18032/gerencia-de-projetos/elicitacao-de-requisitos-
e-suas-tecnicas?trace=1519021197&source=single
• https://luizaugeane.wordpress.com/2015/10/23/guia-babok-3-boas-praticas-para-
analise-de-negocio/
Obrigado!
 www.blpit.com.br

e-mail: gustavo.lima@blpit.com.br
Tel.: 55 16 3965-2324
Cel.: 55 16 99992-1678
Skype: gustavo.borges.lima

http://www.linkedin.com/company/blp-it-consultoria-e-solu-es-em-ti
br.linkedin.com/in/gustavolima