Tell me what you want - Uma visão sobre análise de requisitos
Transferir como PPTX, PDF2 gostaram449 visualizações
O documento discute técnicas de elicitação de requisitos, incluindo questionários, entrevistas e prototipação, sendo esta última útil em situações de incerteza e requerindo feedback rápido dos usuários. Além disso, aborda o uso de 'use cases' e 'user stories' para descrever interações e requisitos de forma concisa e compreensível, enfatizando a importância de testes de aceitação. As boas 'user stories' devem focar em problemas, não em soluções.
Tell me what you want - Uma visão sobre análise de requisitos
- 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
- 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