Anotações do curso Requirements gathering in business analysis - Coursera

Tenho usado bastante a estrutura que vi no curso “Requirements gathering in business analysis” para escrever histórias de usuário para um projeto que estou liderando. Como estou consultando frequentemente as anotações do curso, decidi transformar os conceitos em post, para facilitar o meu trabalho.

Esse post tem as minhas anotações traduzidas (o curso é ministrado em inglês), que não necessariamente vão formar um texto totalmente compreensível por quem não assistiu ao curso. Também não incluí todas as anotações, somente aquilo que estou usando mais no dia a dia.

Requirements Engineering Framework

O Requirements Engineering Framework é uma abordagem estruturada, mas flexível, que ajuda a capturar todos os detalhes necessários para atender às necessidades dos stakeholders.

Stakeholders: pessoas ou grupos afetados pelo projeto.

O framework é formado por 5 estágios:

1. Elicitação
2. Análise
3. Validação
4. Documentação
5. Gestão

O framework é não linear, ou seja, as etapas podem acontecer fora de ordem.

Incremento

O incremento representa uma parte significativa da funcionalidade que foi totalmente desenvolvida e está pronta para uso.

É entregue em uma janela de tempo.

Iteração

Iterações são ciclos de desenvolvimento dentro da metodologia ágil, que geralmente duram duas semanas.

Comece com o desenvolvimento incremental para construir uma base sólida e então use o desenvolvimento iterativo para refinar e melhorar o seu produto.

Requisitos funcionais

Requisitos funcionais representam o que os stakeholders querem que o sistema ou o processo faça.

Requisitos não funcionais

Requisitos não funcionais tendem a ser mais técnicos.

INVEST

Útil para avaliar requisitos.

É um acrônimo formado pelos elementos:

• Independent - Independente
• Negotiable - Negociável
• Valuable - Com valor
• Estimable - Estimável
• Small - Pequena
• Testable - Testável

Validação de requisitos

A validação de requisitos consistem em avaliar todos os requisitos e garantir que seguem atendendo às necessidades dos stakeholders.

Histórias de usuário

As histórias de usuário são formadas pelos 3 C’s:

• Card - Cartão
• Conversation - Conversa
• Confirmation - Confirmação

Cartão

Formato:

• Como [PAPEL],
• quero [O QUÊ],
• para [POR QUÊ].

Conversa

As conversas acontecem entre os stakeholders e o time de desenvolvimento.

Confirmação

A confirmação é demonstrada como uma série de testes que vão provar o que foi expresso no cartão. Também pode sesr chamada de critérios de aceite.

Formato:

• Dado [QUE ESTOU EM DETERMINADA SITUAÇÃO],
• quando [EU FAÇO ALGUMA COISA],
• então [ISSO ACONTECE].

Épico

As histórias se juntam para entregar um item maior, de mais alto nível, com menos detalhes, que representa para os stakeholders algo mais parecido com parte do processo de negócio.

Product backlog

Uma lista de histórias que têm informações suficientes para serem consideradas para desenvolvimento.

Se você fez o curso, espero que essas anotações tenham te ajudado a relembrar os conceitos. Caso não tenha feito, espero que tenha dado visibilidade sobre os conceitos envolvidos no levantamento de requisitos.

Até a próxima!

Copiar link