Histórias de Usuário

Fundamentos de Engenharia
de Software
Elicitação de Requisitos e Histórias de Usuário
Professor: Bruno Gadelha
Monitores: Jo Pereira e Romualdo Costa
Adaptado por: Keren Guimarães
1

Agenda
1. Elicitação de Requisitos;
2. Definição e características de Histórias de
Usuários;
3. Por que criar Histórias de Usuário?
4. Composição das Histórias;
5. Critérios de Aceitação;
6. Cenários.
2

Elicitação de
Requisitos
3

Elicitação de Requisitos
●
●
●
●
Trata-se da identificação do requisito em si;
É a fase em que são extraídas informações dos clientes sobre o que se deseja que
seja construído;
Também conhecida como Levantamento de Requisitos;
Nesta fase que o profissional busca informações como:
○ Funcionalidades que o sistema deve ter;
○ Regras de negócios;
○ Restrições;
○ Usabilidade e etc.
4

Elicitação de Requisitos
●
●
●
●
Trata-se da identificação do requisito em si;
É a fase em que são extraídas informações dos clientes sobre o que se deseja que
seja construído;
Também conhecida como Levantamento de Requisitos; (ERRADO)
Nesta fase que o profissional busca informações como:
○ Funcionalidades que o sistema deve ter;
○ Regras de negócios;
○ Restrições;
○ Usabilidade e etc.
5

Elicitação de Requisitos
●
●
●
Existem diversas formas de elicitação de requisitos, que atendem diversos
objetivos diferentes;
Para o caso de sistemas que não são de missão crítica, recomenda-se a criação de
Histórias de Usuários:
○ um documento simplificado de especificação de requisitos
São utilizados nos cenários de sistemas cujos requisitos estão sujeitos a
mudanças, mas não são críticos.
6

O que é uma
História de
Usuário?
7

Histórias de Usuário - Definição
●
●
●
●
É uma técnica pragmática para elicitação de requisitos;
É uma descrição curta e em linguagem simples;
Representa as funcionalidades desejadas pelo usuário;
É a menor unidade de trabalho em uma estrutura ágil.
8

Histórias de Usuário – Características (INVEST)
●
●
●
Independentes:
○ Não devem se sobrepor a outra, sendo assim, deve ser possível
desenvolvê-las em qualquer ordem;
Negociáveis:
○ Devem ser co-criadas pelo cliente e pelos desenvolvedores, e
sendo aptas a responder às mudanças quando necessário;
Valiosas:
○ Têm que agregar valor para o negócio;
○ Não há presença de histórias que tratam de situações técnicas
do projeto;
9

Histórias de Usuário – Características (INVEST)
●
●
●
Estimáveis:
○ Deve ser possível estimar o tamanho de uma história com o
objetivo de verificar em quanto tempo é possível implementá-la;
Sucintas:
○ Para facilitar o entendimento e estimativa delas;
○ Histórias mais complexas são posicionadas no final do backlog;
Testáveis:
○ Deve ser possível serem validadas;
○ Ter critérios de aceitação objetivos.
10

Histórias de Usuário
11

Por que criar Histórias de Usuário?
●
●
●
●
●
Atividades de Engenharia de Requisitos ocorrem ao longo de todo o
desenvolvimento;
Troca-se um documento de centenas de páginas por conversas frequentes;
O requisito pode ser explicado para a equipe sempre que surgir alguma
incongruência;
Elas favorecem a comunicação verbal em vez da escrita;
São compatíveis com o Manifesto Ágil.
12

Como escrever
uma História de
Usuário?
13

Histórias de Usuário + Técnica 3C
●
História de Usuário = Cartão + Conversa + Confirmação
●
Cartão:
○ Mostra a visão do cliente
○ Feito com linguagem simples
○ Com poucas palavras
○ Serve para mostrar as funcionalidades esperadas para o sistema
14

Histórias de Usuário + Técnica 3C
●
História de Usuário = Cartão + Conversa + Confirmação
●
Conversa:
○ Entre cliente e desenvolvedor;
○ Clientes explicam e detalham o que escreveram nos cartões
○ Substitui especificações textuais e completas;
○ Utilizada para incluir o cliente no processo.
15

Histórias de Usuário + Técnica 3C
●
História de Usuário = Cartão + Conversa + Confirmação
●
Confirmação:
○ É um teste de alto nível;
○ São também chamados de Testes de Aceitação de Histórias;
○ Serve para verificar se a história foi implementada conforme esperado;
○ NÃO é um teste automatizado.
16

Histórias de Usuário + Técnica 3W
●
●
A técnica 3W se preocupa com o conteúdo das Histórias de Usuário
Utiliza o seguinte padrão:
●
●
●
Quem (Who):
○ Usado para referenciar para quem está sendo construída essa História (a persona);
O quê? (What):
○ Funcionalidade esperada;
Por quê? (Why):
○ Motivação para a escrita dessa história;
17

Template
COMO
● Quem é a persona atingida por essa história?
EU QUERO
● O que minha persona deseja executar?
PARA
● O que minha persona espera como resultado?
18

Exemplo
COMO professor
EU QUERO lançar as notas do período
PARA que os alunos saibam se foram aprovados ou não
19

Critérios de
aceitação
20

Histórias de usuário - Critérios de Aceitação
●
●
●
●
●
●
São como checklists;
Servem para garantir que a História esteja entregando o que foi pedido;
Funcionam em caráter de funcionalidade para entrega de valor ao usuário;
Devem ser escritos de forma clara para que sejam entendidos por todos;
São independentes de implementação;
Podem ser feitos de diversas formas, como por exemplo:
○ A partir de tópicos;
○ Com a criação de cenários para aplicar as Histórias.
21

Cenários
22

Definição dos cenários em histórias de usuário
●
●
●
Auxiliam a entender a História;
Mostram os caminhos que o usuário deve percorrer para chegar com sucesso ou
não ao fim da tarefa;
Como funciona:
○ Desenvolvedores criam comportamentos esperados para as funcionalidades a serem
implementadas;
○ As Histórias são validadas com base nos comportamentos criados.
23

Cenários
DADO
● Utilizado para especificar uma pré-condição;
QUANDO
● Utilizado para especificar quando será executada uma ação;
ENTÃO
● Utilizado para produzir um resultado determinado, após validação da etapa anterior;
E
●
Utilizado caso seja necessário mais de uma interação no fluxo;
MAS
●
Utilizado após uma validação negativa do ENTÃO;
OU
●
Utilizado caso haja mais de alternativa no fluxo.
24

Exemplo
DADO QUE o vendedor consulta o cliente
E insere um CNPJ inválido
QUANDO apertar no botão “Consultar”
OU clicar fora do campo de CNPJ
ENTÃO uma mensagem informando “CNPJ Inválido, por favor coloque um CNPJ válido”
deve ser exibida.
25

Exemplo
26

Hora de Praticar
1. Com base na descrição do sistema a seguir, elabore duas histórias de
usuário e um cenário para cada história, com critérios de aceitação.
O sistema permite que os alunos se matriculem em disciplinas, consultem suas notas e
frequências, solicitem documentos e serviços, e acessem conteúdos didáticos. Ele também
permite que os professores lancem notas e frequências, gerenciem as turmas e os conteúdos, e
comuniquem-se com os alunos. O sistema ainda permite que os coordenadores acompanhem
o desempenho dos alunos e dos professores, definam as ofertas de disciplinas, e resolvam
pendências acadêmicas. Além disso, ele é integrado com o sistema financeiro da instituição,
que controla as mensalidades, bolsas e descontos dos alunos.
O sistema é composto por vários módulos, cada um responsável por uma funcionalidade
específica. Os módulos se comunicam entre si por meio de interfaces padronizadas. O sistema
utiliza um banco de dados relacional para armazenar as informações acadêmicas. Ele é
acessado pelos usuários por meio de uma interface web ou de um aplicativo móvel. O sistema
possui mecanismos de segurança, autenticação e autorização para garantir a
confidencialidade, integridade e disponibilidade dos dados.
27

Bibliografia
●
●
●
VALENTE, M. T. Engenharia de software moderna: princípios e práticas para
desenvolvimento de software com produtividade. Minas Gerais: Universidade
Federal de Minas Gerais, 2020.
COSTA, D.. Elicitação de Requisitos: Levantamento de requisitos e técnicas de
Elicitação. Devmedia, 2014. Disponível em:
<https://www.devmedia.com.br/elicitacao-de-requisitos-levantamento-derequisitos-e-tecnicas-de-elicitacao/31872>.
Acesso em: 23/11/2022
SOARES, F.. Histórias de usuário: Desmistificando a escrita de User Story. DTI
Digital, 2021. Disponível em: <https://www.dtidigital.com.br/blog/historias-deusuario/>.
Acesso em: 14/11/2022
28