O desenvolvimento de produtos de software começa com o entendimento claro e detalhado das necessidades dos usuários, dos requisitos de negócio e das características essenciais do produto. A documentação é a ferramenta para mapear, comunicar e validar todos os aspectos essenciais do projeto.

Quando elaborada de maneira adequada, a documentação de software pode agilizar todo o processo de desenvolvimento. Cada documento gerado ao longo do projeto constitui parte do nosso entregável como profissionais de negócios e de produto, e deve ser elaborado e revisado durante todas as fases da resolução do problema. Considerando essa perspectiva documental, destacamos três categorias principais:

• Documentação de requisitos: é um conjunto de informações detalhadas que descrevem as funcionalidades, características e restrições que um sistema ou produto deve atender. Esses requisitos servem como base para o desenvolvimento, teste e validação do software, proporcionando uma compreensão clara das expectativas e necessidades do cliente ou usuário final.
• Documentação de Negócio: abrange informações relacionadas aos processos, estratégias, políticas e práticas operacionais de uma organização. Pode incluir manuais de procedimentos, políticas internas, planos de negócios, documentos regulatórios, entre outros.
• Documentação de Produtos: se concentra nas informações associadas a um produto específico. Pode incluir manuais do usuário, guias de instalação, documentação técnica, notas de versão, especificações de design, entre outros. Esses documentos auxiliam usuários, desenvolvedores e outros stakeholders na compreensão e utilização eficaz do produto.

Documentação de Requisitos:

A documentação descreve como cada requisito atende as necessidades do negócio. A especificação de requisitos serve como um contrato entre o negócio (cliente) e o time de desenvolvimento, e é obrigatória e fundamental para garantir o processo de implementação.

Etapas do Item Backlog:

• Identificar: ao criar um item de backlog, evite excessos nos detalhes, foque no "Porquê" da história e no valor que ela agrega ao negócio.
• Analisar: durante o designer da solução, busque a melhor forma de implementação. Nesse momento, as interações serão super importantes para adicionar os detalhes realmente relevantes para o requisito.
• Validar: ao negociar, apresente e discuta os itens com as partes interessadas. Conversas face a face são mais eficientes do que documentação extensa.
• Documentar: ao chegar em um consenso, documente o necessário antes da execução. Você pode utilizar a estrutura básica fornecida abaixo, caprichando nos critérios de aceitação e apresentando o requisito visualmente quando possível. Mantenha a documentação atualizada refletindo alterações, atualizações e decisões importantes.
• Gerenciar: mantenha comunicação aberta com o time e stakeholders. Acompanhe a entrega e uso da solução, capturando novas necessidades para o backlog com base nos critérios de priorização do projeto.

Estrutura básica para Requisitos:

Na documentação de requisito definimos e detalhamos "O que" precisa ser feito. Os requisitos devem ser descritos sem gerar dupla interpretação ou ambiguidade, preferencialmente utilizando critérios de aceitação mensuráveis para eliminar subjetividade na avaliação.

É essencial estruturar um modelo claro para o documento, garantindo que todos possam compreendê-lo. Este modelo pode ser desenvolvido em colaboração com a equipe e pode ser composto pelos seguintes itens:

• Título do card: deve ser curto, objetivo e facilitar a identificação do propósito da demanda.
• Declaração de Valor: Eu como [persona], Quero [objetivo(s)], Para [benefícios da funcionalidade]. Essa declaração proporciona foco no usuário, clareza sobre o propósito e os benefícios esperados da funcionalidade.
• Objetivos da demanda: descrição do requisito de maneira geral, pode ser apresentado em tópicos e detalhados durante a especificação das regras de negócio.
• Contexto: apresentação do cenário atual e as mudanças previstas.
• ​Público alvo:​ definição do usuário final para quem o sistema ou funcionalidade está sendo desenvolvido.
• Protótipo ou Mockup: representações visuais e ou interativas de uma funcionalidade. Eles oferecem uma prévia visual do produto, permitindo validar conceitos, interações e design antes da implementação.
• Fluxos e diagramas: representações visuais que ilustram o comportamento, interações e processos do sistema. Fluxos descrevem sequências de passos, enquanto diagramas, como diagramas de caso de uso ou fluxogramas, fornecem uma visão gráfica das relações entre componentes.
• Requisito Funcional: descrição detalhada das regras de negócio, dos serviços ou funcionalidades do sistema. O nível de detalhamento varia conforme o tipo de software, as expectativas dos usuários e do tipo de sistema que está sendo desenvolvido.
• Requisito Não funcional: documentação explícita de aspectos como segurança, precisão, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.
• Restrições de Uso:​ condições específicas que impactam como a funcionalidade pode ser utilizada, como restrições técnicas, legais ou de desempenho.
• Impactos e Risco: identificação dos impactos e possíveis riscos associados à demanda.
• Integração com outros sistemas:  descrição de como será feita a integração com outros sistemas, caso seja necessário.
• Critérios de aceite: definição de condições mensuráveis que devem ser atendidas para que o requisito seja considerado concluído.
• Escopo técnico: descrição de como será a implementação do requisito. Esse item deve ser capturado em conjunto com o time de desenvolvimento.
• Formalização dos aprovadores: o processo de formalização pode ocorrer através da movimentação do card no board, durante o refinamento com o time e stakeholders, ou através da comunicação por e-mail.

DoR - Definition of Ready

A prática do Definition of Ready implica que o time só inicie uma tarefa quando todos os critérios do DoR estiverem atendidos. A não conformidade pode impactar negativamente o processo de desenvolvimento, produtividade e desempenho do time.

Não existe um padrão para definir os critérios do DoR. Cada equipe precisa avaliar o que é indispensável para iniciar uma tarefa ou um projeto.

Aqui estão alguns exemplos do que pode compor o DoR de um time na DB1:

• O requisito deve ter a definição do problema a ser resolvido;
• O requisito deve ser refinado e aprovado pelo time de desenvolvimento;
• O requisito devem ter sido refinado e aprovado pelos principais stakeholders;
• O requisito deve seguir as boas práticas do conceito INVEST ou outra técnica similar;
• O requisito deve ter claramente a definição do Entregável e valor entregue ao usuário/negócio;
• Antes do Refinamento técnico: o requisito deve possuir desenho, protótipo ou diagrama para demonstrar onde está o problema (o que precisa ser feito/qual problema estamos resolvendo). O desenho não deve tentar solucionar o problema (como) fazer;
• Após Refinamento Técnico: o requisito deve possuir desenho, protótipo ou diagrama para demonstrar como o problema será resolvido (cenário atual x cenário adequado);
• O requisitos devem possuir critérios de aceite claros e objetivos.

Documentação de Negócio e Produto

Durante o projeto são criados diversos artefatos que não se restringem aos requisitos e que podem ser utilizados para documentar o negócio e o produto. Pensar na documentação como uma extensão ao desenvolvimento faz com que esse processo se torne mais fluido e orgânico. A seguir um exemplo de itens que podem compor essa documentação:

• Time: apresenta os membros do time de desenvolvimento e lideranças diretas envolvidos no projeto
• Stakeholders: engloba todas as partes interessadas, como clientes, usuários finais e qualquer entidade que possa influenciar ou ser impactada pelo projeto, assegurando uma comunicação efetiva e alinhamento de expectativas.
• Estratégia e Visão: Inclui artefatos como o plano de negócios, propósito e regras gerais. A clareza desse item permite o direcionamento mais assertivos das ações.
• Métricas: aborda as métricas utilizadas para avaliar o progresso e o desempenho do projeto ou produto, proporcionando uma base objetiva para a tomada de decisões.
• Glossário do projeto: fornece uma lista de termos específicos utilizados no contexto do projeto, promovendo uma compreensão uniforme entre os membros da equipe.
• Marketing: apresenta os artefatos utilizados para descrever e promover o projeto, abordando estratégias de divulgação e posicionamento no mercado.
• Fluxos: inclui diagramas que representam visualmente os processos envolvidos no projeto, facilitando a compreensão das interações e sequências de atividades.
• Regulatório: Envolve documentos relacionados a requisitos e conformidades regulatórias que impactam o projeto.
• Mercado: apresenta estudos de benchmarking realizados, oferecendo insights sobre a posição do projeto em relação ao mercado.
• Técnico: Contém toda a documentação técnica necessária, incluindo referências e suporte para a equipe técnica, garantindo um desenvolvimento consistente e padronizado.