Palestra dada no TDC Porto Alegre, em 2013. Nela falo um pouco sobre os métodos que tive contato para fazer levantamento de requisitos e qual foi a minha experiência dentro dessa área.

1. So, tell me what you want…
@JulianoRibeiro

3. É FÁCIL ENTENDER O
DESEJO DO CLIENTE?

11. COMO APROXIMAR
QUEM PEDE DE QUEM FAZ?

12. Técnicas Tradicionais
• Questionários
• Entrevistas
• Observação
• Análise de documentos

13. Técnicas de elicitação de grupo

14. Prototipação
• O uso de protótipo auxilia na elicitação e
validação dos requisitos de sistema.
• A prototipação pode ser utilizada para elicitar
requisitos quando há um alto grau de
incerteza ou quando é necessário um rápido
feedback dos usuários.

16. Use Cases

17. Use Cases
• Descreve a sequência de interações e deve ser
escrito nos termos de um modelo formal. O
objetivo de um Use Case é prover detalhes
suficientes para sua compreensão em si
mesmo.
• Deve ser entregue como um documento
único.

19. User Stories

20. User Stories
• Provê uma apresentação fácil de compreender e
de forma concisa sobre uma determinada
informação. São geralmente numa linguagem
informal e contém o mínimo de detalhes,
deixando os demais dados aberto à
interpretação. Elas devem ajudar a entender o
que o software deve englobar.
• Deve ser acompanhada por critérios de aceitação
para ajudar a elucidar os comportamentos aonde
as histórias pareçam ambíguas.

21. Como um <papel>,
eu quero/desejo <objetivo/desejo>
então <benefício/razão>

22. User stories (histórias de usuário)
• Um descrição informal dos requisitos
• São trabalhadas e amadurecem à medida que a
análise progride
• Buscam apenas representar e não documentar
22
Como estudante
Quero comprar livros
Para poder estudar
Como professor
Quero comprar livros
Para poder preparar aulas

23. Quebrando épicos em histórias menores
23
23
Como?
Sistema deve
ser seguro
Risco baixo
para os opera-
dores
Baixos riscos
e falhas na
utilização
Baixo risco ou
quebra de má-
quinas
Deslig. auto-
mático em so-
brecarga
Deve ser
controlado por
um sensor

24. Independent
Negotiable
Valuable
Estimatable
Small
Testable
I
N
V
E
S
T
24

25. Testes de Aceitação
• Certificam que as história implementadas correspondem
ao que o cliente necessita
• Existem diversas formas de escrever ATs:
– Tabela-verdade
– Cenários
• Responsabilidade pela escrita em Scrum: Product Owner
• Devem ser automatizados o máximo possível
• Exemplo:
“O usuário gostaria de poder logar no sistema via web e ter acesso
apenas a uma determinada área do banco de dados”
Que testes poderiam ser escritos?
25

26. Boas
User Stories
descrevem um
PROBLEMA
e não a
SOLUÇÃO

27. Obrigado
@JulianoRibeiro
juliano@massimus.com