Sem nenhuma das seções mencionadas, os requisitos começam a perder valor e sentido. Muitas vezes, quando sou chamado para dar consultoria, vejo times ágeis e especificações de sistemas como um “punhado de gente bem-intencionada que não consegue escrever ou muitas vezes ler o livro que ganharam”.

Introdução
A ideia do desenvolvimento deste conteúdo didático é fazer com que você possa se recordar do que
você já aprendeu de forma a mantê-lo(a) focado no desafio e ter praticamente tudo do precisa para
desenvolvê-lo num lugar só.

Você também encontrará leituras e material complementares que, sinceramente te alerto, serão
essenciais no aprofundamento e desenvolvimento desse desafio. Muitas pessoas e discentes
comentam que muitos RH de empresas pedem experiência aos candidatos. Com certeza, é bastante
estranho pedir por algo dessa natureza a quem está tentando entrar, ou desenvolver, uma carreira.
Porém, com esses desafios você tem a oportunidade de mostrar que desenvolveu seu aprendizado
e que está pronto para qualquer desafio de seleção de pessoas para concorrer de igual para igual
com qualquer outro candidato.

Vamos aproveitar para recordar agora?!

Requisitos Ágeis
Primeiramente, algumas constatações. Muitas vezes, no início de minha carreira vi projetos com
dificuldades porque seus requisitos eram mal elaborados, muitas vezes sem sentido, e eu me sentia
um completo inútil. Eu olhava para os “requisitos” e eles não eram nada mais do que um quadro com
uma infinidade de notas e postites. Eu era desenvolvedor e tinha muitas dúvidas e, em geral, todas as
pessoas envolvidas, clientes, usuários, desenvolvedores, analistas de negócios, arquitetos de
solução e inclusive os testadores, não têm um bom entendimento do sistema como um todo e quais
são as várias personas que usam o sistema. Claro que faltava, também creio eu, a todas essas pessoas,
se apropriarem de verdade do conhecimento e dos processos do negócio. Minha sorte foi que, o
tempo e a dedicação sempre trazem frutos, para o bem ou para o mal. No meu caso, foi para o bem!

Então respire fundo e se prepare para pensar e analisar muito em profundidade, pois analistas de
sistemas criados no raso jamais enfrentaram grandes tempestades e ondas avassaladoras, acredite.
Aqui serão apresentadas dicas preciosas para você desenvolver seu trabalho com menos incerteza,
vindas de um “velho marujo”.

Um bom requisito deve dizer a cada membro do público exatamente qual é a funcionalidade
esperada e nunca gerar uma miríade de perguntas de todos os envolvidos. Frequentemente, é difícil
solicitar informações a um cliente, mas documentar para desenvolvedores nunca deve ser tão difícil.
E nesse caso você vai possuir múltiplos “chapéus”; ora será analista de negócios, ora desenvolvedor,
ora etc.

Bons requisitos precisam de:

Histórias de usuários;

Testes de Aceitação do Usuário;

Fluxo de Trabalho;

Detalhes dos Requisitos;

Wireframes.

Sem nenhuma das seções mencionadas, os requisitos começam a perder valor e sentido. Muitas
vezes, quando sou chamado para dar consultoria, vejo times ágeis e especificações de sistemas
como um “punhado de gente bem-intencionada que não consegue escrever ou muitas vezes ler o
livro que ganharam”. Daí fica realmente difícil construir algo se nem entendemos o português que
está escrito, não é mesmo?! Cada seção de análise traz muito para a mesa e muitas vezes são
julgadas como uma “perda de tempo”, porém, quando vamos codificar, fazem toda a diferença.

Olhe só:

Histórias de Usuários
Indica todos os cenários dos usuários envolvidos. O padrão mundial disso é:

Como ALGUM PAPEL,
EU QUERO FAZER ALGUMA COISA, PARA
QUE POSSA OBTER ALGUNS BENEFÍCIOS.

Ou seja,

Por exemplo,

Entendeu o que esperamos de você. Dezenas de cartões de história do usuário completos, claros,
concisos, especificando a ação e o que se espera, incluindo para que serve.

Por favor, pense como um profissional, e você vai pensar, “mas sou aluno”, sim todos nós somos
alunos, incluindo o autor desse material, mas atitude é tudo e é isso que queremos de você. Atitude
positiva e construtiva!

As histórias de usuários são essenciais para definir exatamente quem fará o quê e por quais razões.