Tell me what you want - Uma visão sobre análise de requisitos

314 visualizações

Publicada em

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.

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
314
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • JAD – IBM, consiste em colocar na mesma sala todos os envolvidos no uso da história para o brainstorm mais rico sobre o assunto.
  • Heitor Roriz Filho, MSc, CST
  • Heitor Roriz Filho, MSc, CST
  • Heitor Roriz Filho, MSc, CST
  • Heitor Roriz Filho, MSc, CST
  • Tell me what you want - Uma visão sobre análise de requisitos

    1. 1. So, tell me what you want… @JulianoRibeiro
    2. 2. É FÁCIL ENTENDER O DESEJO DO CLIENTE?
    3. 3. COMO APROXIMAR QUEM PEDE DE QUEM FAZ?
    4. 4. Técnicas Tradicionais • Questionários • Entrevistas • Observação • Análise de documentos
    5. 5. Técnicas de elicitação de grupo
    6. 6. 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.
    7. 7. Use Cases
    8. 8. 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.
    9. 9. User Stories
    10. 10. 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.
    11. 11. Como um <papel>, eu quero/desejo <objetivo/desejo> então <benefício/razão>
    12. 12. 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
    13. 13. 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
    14. 14. Independent Negotiable Valuable Estimatable Small Testable I N V E S T 24
    15. 15. 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
    16. 16. Boas User Stories descrevem um PROBLEMA e não a SOLUÇÃO
    17. 17. Obrigado @JulianoRibeiro juliano@massimus.com

    ×