Um documento de requisitos de negócio (BRD) é a ponte entre as partes interessadas do negócio e as equipas técnicas — capta o que o negócio precisa e traduz isso em requisitos que os programadores conseguem construir. Com a Trupeer, pode poupar horas na elaboração de BRDs começando com um modelo gratuito de documento de requisitos de negócio, personalizando-o com as suas orientações de marca e transformando BRDs longos em walkthroughs em vídeo que toda a gente consegue, de facto, acompanhar.

Os projetos raramente falham porque ninguém escreveu os requisitos. Falham porque o que foi escrito era demasiado vago para não haver discordância. Toda a gente assinou um documento dizendo que o sistema deveria ser "amigável e rápido" e, quatro meses depois, descobrem que queriam dizer três coisas diferentes.

Um documento de requisitos de negócio vale a pena ser escrito quando permite a discordância antes de o desenvolvimento começar, e não depois. Este modelo foi criado para isso: cada requisito é numerado, priorizado e acompanhado por critérios de aceitação suficientemente específicos para se poder discutir já agora.

Transferir o modelo de documento de requisitos de negócio

Gratuito, editável, sem marca de água. A maioria das equipas usa o Word para o documento e o Excel para a tabela de requisitos quando a contagem passa cerca de trinta.

O que é um documento de requisitos de negócio?

Um documento de requisitos de negócio, ou BRD, define o que um negócio precisa de um projeto e porquê, antes de alguém decidir como o construir. Define o problema, o âmbito, as partes interessadas, os próprios requisitos e os critérios pelos quais o resultado será avaliado.

A sua função real é o acordo. Um BRD é o documento que toda a gente assina para confirmar que compreende a mesma coisa, razão pela qual o teste útil de um BRD não é se é bem escrito, mas se é suficientemente específico para que alguém possa levantar objeções.

Como personalizar este modelo na Trupeer

Passo 1: Abrir a secção de Modelos

Vá à secção de Modelos no menu principal.

Passo 2: Selecionar e abrir um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Passo 3: Expandir a visualização do modelo

Se necessário, expanda a visualização do modelo para ver o layout completo e os detalhes com clareza.

Passo 4: Editar o modelo

Clique em Editar para começar a modificar o modelo selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guardar o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Guardar para guardar o modelo atualizado como seu.

Passo 6: Pré-visualizar e afinar o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a Pré-visualização.

A partir do ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o pretende.

Com um modelo de documento de requisitos de negócio, pode:

• Poupar horas na escrita: Ignore a página em branco com uma estrutura usada por BAs e PMs experientes.

• Alinhar negócio e tecnologia: Secções integradas ligam objetivos do negócio a requisitos funcionais.

• Manter-se fiel à marca: Aplique o seu logótipo, fontes e cores usando o kit de marca da Trupeer.

• Comunicar com clareza: Transforme BRDs densos em walkthroughs em vídeo para revisões das partes interessadas.

• Padronizar em todos os projetos: Use o mesmo modelo de BRD para cada iniciativa.

• Atingir equipas globais: Traduza BRDs para 65+ idiomas com um clique.

Porque precisa de um documento de requisitos de negócio

• O âmbito torna-se algo para apontar em vez de algo para lembrar. A maioria das disputas sobre âmbito são falhas de documentação, não de má-fé.

• Os requisitos ganham prioridades; por isso, quando o tempo fica curto, corta-se deliberadamente em vez de cortar o que quer que fique por fora.

• As suposições ficam registadas, que é quando alguém nota a errada.

• Os critérios de aceitação existem antes do desenvolvimento, por isso "concluído" não é decidido por quem for mais insistente no fim.

• A passagem de testemunho resiste à saída de pessoas. Os projetos que perdem o analista de negócio a meio do caminho são aqueles em que um BRD se paga por si mesmo, de imediato.

• Os fornecedores conseguem apresentar propostas com base em algo real. Um BRD vago gera uma proposta ampla e um projeto com muitas solicitações de alteração.

O que inclui um documento de requisitos de negócio

• Controlo do documento: versão, autor, data, distribuição e estado de aprovação.

• Resumo executivo: o que é o projeto e porquê, num parágrafo.

• Objetivos do negócio, expressos como resultados mensuráveis em vez de atividades.

• Contexto e declaração do problema: o que está a acontecer agora e o custo disso.

• Âmbito: o que está incluído e, explicitamente, o que está fora.

• Partes interessadas: quem é afetado, quem decide, quem assina.

• Estado atual, tal como é de facto.

• Requisitos do negócio, numerados, priorizados, com critérios de aceitação em cada um.

• Suposições, restrições e dependências.

• Riscos, com responsáveis.

• Resumo de custos e benefícios, e o retorno esperado.

• Cronograma e marcos principais.

• Critérios de sucesso para o projeto como um todo.

• Glossário, porque metade das disputas sobre requisitos são disputas de vocabulário.

• Bloco de validação.

• Anexos: mapas de processos, dados, ecrãs, análise de suporte.

A estrutura do modelo

Dez a vinte páginas é normal para um projeto de média dimensão. Acima de trinta, a tabela de requisitos costuma já ter absorvido decisões de design que pertencem a uma especificação funcional.

Como escrever um requisito que resiste à revisão

Esta é a competência completa. Um requisito está bem escrito quando duas pessoas que discordam conseguem, ao lê-lo, saber que discordam.

Fraco: O sistema deve ser amigável.
Melhor: Um novo utilizador tem de conseguir submeter uma reclamação sem formação, medido por 8 em 10 utilizadores de teste a concluírem a submissão sem ajuda em menos de 3 minutos.

Fraco: Os relatórios devem carregar rapidamente.
Melhor: O relatório mensal de resumo tem de ser apresentado em 4 segundos para um conjunto de dados com até 50.000 linhas.

Fraco: Os gestores precisam de visibilidade das aprovações.
Melhor: Um gestor tem de conseguir ver todas as reclamações à espera da sua aprovação, ordenadas por data de submissão, num único ecrã sem filtragem.

Fraco: O sistema deve integrar com a área financeira.
Melhor: As reclamações aprovadas têm de ser publicadas no sistema de contabilidade em 15 minutos, incluindo centro de custo e código de IVA, com falhas registadas e reprocessadas automaticamente.

O padrão em cada melhoria é o mesmo. Dê nome a quem precisa, ao que é específico e à condição em que concordaria que isso foi alcançado. Palavras para desconfiar nos seus próprios rascunhos: amigável, robusto, sem falhas, intuitivo, rápido, flexível, escalável, fácil. Cada uma esconde uma decisão que alguém vai tomar mais tarde sem si.

Priorizar requisitos com MoSCoW

Requisitos sem prioridades tornam-se todos obrigatórios por defeito e, depois, a primeira pressão do calendário força cortes arbitrários.

A disciplina que faz o MoSCoW funcionar: não mais do que cerca de 60% dos requisitos devem ser Deve ter. Se tudo for um Deve ter, tem uma lista de desejos com uma coluna de prioridade. E a lista Não terá esta vez é a mais valiosa, porque é o registo escrito do que foi conscientemente adiado em vez de ser esquecido.

A tabela de requisitos

Cada requisito precisa de um ID, porque "o requisito de reporte" é ambíguo assim que existem dois. A fonte importa porque, no quarto mês, alguém vai perguntar quem pediu isto e "o negócio" não é uma resposta.

Matriz de rastreabilidade

A verificação de que nada foi descartado em silêncio e de que nada está a ser construído sem razão.

Duas falhas aparecem imediatamente. Um requisito sem caso de teste não será verificado e um item de especificação funcional que não remete para nenhum requisito é algo que está a ser construído sem que ninguém tenha pedido. Ambos são comuns e ambos são baratos de encontrar desta forma.

Exemplo de documento de requisitos de negócio

Um exemplo trabalhado abreviado, para poder ver o nível de especificidade.

Projeto: Substituição do sistema de despesas. Versão: 1.2. Autor: Analista de negócio. Aprovadores: Diretor Financeiro, Diretor de TI, Diretor de RH.

Objetivos do negócio. Reduzir o tempo médio de reembolso de despesas de 24 dias úteis para 10. Reduzir em 50% o tempo da equipa financeira gasto no processamento de despesas, atualmente 14 horas semanais. Alcançar 95% de conformidade com a política nas despesas submetidas, atualmente 71%.

Declaração do problema. As despesas são submetidas numa folha de cálculo e enviadas por e-mail. O encaminhamento de aprovações é manual, os recibos chegam separadamente e 29% das despesas violam a política sem serem detetadas antes do pagamento. A área financeira gasta cerca de 14 horas por semana a perseguir, e o reembolso demora em média 24 dias úteis face ao compromisso de 10 dias no manual dos colaboradores.

Incluído no âmbito. Submissão de despesas, captura de recibos, validação de política, encaminhamento de aprovações, publicação no sistema de contabilidade, notificação ao colaborador.
Fora do âmbito. Reconciliação de cartão corporativo, definição de taxa de quilometragem, integração com salários, migração de despesas históricas para além de 12 meses.

Requisitos.

Suposições. A estrutura organizacional atual no sistema de RH é correta e mantida. O sistema de contabilidade disponibiliza uma API suportada. Os limites da política não mudarão durante a implementação.

Restrições. Orçamento de £85.000. Deve entrar em produção antes do novo ano financeiro. Sem contratação adicional na área financeira.

Riscos. Os dados da linha de reporte no reporting de RH provam ser pouco fiáveis, sob responsabilidade do Diretor de RH, mitigado por uma auditoria antes do desenvolvimento. A adoção por parte dos aprovadores é lenta, sob responsabilidade do Diretor Financeiro, mitigada por formação dos gestores e por um período paralelo de duas semanas.

Critérios de sucesso. Reembolso médio igual ou inferior a 10 dias úteis dentro de um trimestre após o go-live. Tempo de processamento da área financeira igual ou inferior a 7 horas semanais. Conformidade com a política igual ou superior a 95%.

Requisitos de negócio vs requisitos funcionais vs requisitos técnicos

A fonte de confusão mais comum neste tema e a razão pela qual muitos BRDs são, na prática, especificações com o título errado.

O teste: se um requisito menciona um ecrã, um campo, um botão ou um componente do sistema, já se desviou para o território funcional. Os requisitos de negócio devem resistir a uma mudança completa da solução. Se trocou de fornecedores e metade do seu BRD ficou inválida, metade nunca foi um requisito de negócio.

Quem prepara um documento de requisitos de negócio e quem o assina

Preparado pelo analista de negócio, ou pelo product owner ou gestor de projeto quando não existe analista. Escrito com as partes interessadas, e não para elas, porque um BRD produzido isoladamente é assinado sem ser lido, o que é pior do que não ter um BRD.

Assinado pelas pessoas que podem ser responsabilizadas: o patrocinador do negócio, o responsável pelo orçamento e os responsáveis de cada função cujo trabalho muda. Adicione o responsável de TI ou o responsável pela entrega, confirmando que os requisitos são compreendidos e não apenas que são alcançáveis.

A assinatura que mais importa é a da pessoa que, no quarto mês, será questionada se isto foi acordado.

Como escrever um documento de requisitos de negócio

1. Estabeleça primeiro o objetivo do negócio, como um número. Se ninguém conseguir indicar o resultado mensurável, a recolha de requisitos vai produzir uma lista de funcionalidades em vez de um documento.

2. Identifique as partes interessadas e os direitos de decisão antes de recolher qualquer coisa. Saber quem pode dizer sim evita a maioria das reversões tardias.

3. Documente o estado atual com honestidade, incluindo as soluções alternativas. É aqui que os requisitos reais se escondem.

4. Recolha requisitos através de entrevistas e observação, não apenas de uma sessão de trabalho. As sessões de trabalho revelam o que as pessoas dizem que precisam. A observação revela o que fazem.

5. Escreva cada requisito com critérios de aceitação associados, na mesma sessão. Adicionar critérios mais tarde significa escrevê-los a partir da memória.

6. Priorize com MoSCoW e mantenha a linha na proporção do Deve ter.

7. Registe suposições, restrições e dependências de forma explícita. Suposições não escritas viram disputas.

8. Construa a matriz de rastreabilidade à medida que avança, em vez de no fim.

9. Distribua para revisão com um prazo e um revisor nomeado por secção. "Algum comentário?" para uma lista de distribuição produz silêncio.

10. Leve as partes interessadas por isso numa sessão antes de pedir assinaturas, depois estabeleça a linha de base da versão e gerira as alterações formalmente a partir desse ponto.

Variantes do modelo de documento de requisitos de negócio

Uma nota sobre a versão ágil: um BRD e um backlog não estão em competição. O BRD capta o porquê e o que o negócio precisa, o que muda lentamente. O backlog capta o que é construído a seguir, o que muda constantemente. As equipas que abandonam o BRD por completo tendem a perder o fio do porquê e a redescobri-lo como argumento.

Boas práticas

• Escreva requisitos que alguém possa recusar. A falta de clareza é lida como acordo e gera disputas mais tarde.

• Um requisito por linha. Qualquer coisa que contenha "e" é provavelmente dois.

• Anexe critérios de aceitação imediatamente, nunca mais tarde.

• Numere tudo e nunca volte a numerar. Coloque os IDs antigos de lado.

• Registe a fonte de cada requisito.

• Mantenha as soluções fora disso. No momento em que nomeia um ecrã ou um campo, começou a desenhar.

• Defina cada termo ambíguo no glossário. Palavras como "despesa", "utilizador" e "aprovado" significam coisas diferentes para departamentos diferentes.

• Estabeleça a linha de base da versão na validação e gerira as alterações formalmente depois.

• Mantenha a lista fora do âmbito visível. Evita mais creep de âmbito do que qualquer outra secção.

Erros comuns

• Requisitos não falsificáveis. "Intuitivo" e "robusto" não podem ser testados, por isso são interpretados no momento do desenvolvimento por quem estiver mais perto.

• Sem prioridades, por isso tudo é obrigatório até o prazo forçar cortes arbitrários.

• Soluções disfarçadas de requisitos. Restringem o desenho antes de alguém avaliar as opções.

• Sem critérios de aceitação, por isso "concluído" vira uma negociação.

• Falta a secção fora do âmbito. A prevenção mais barata de creep de âmbito que existe.

• Escrito para as partes interessadas em vez de com elas. É assinado sem ser lido.

• Suposições deixadas por escrever. Todos os projetos têm suposições e as não registadas são as que o fazem falhar.

• Nunca atualizado após a validação. Os requisitos mudam e uma linha de base sem manutenção deixa de ser a referência em que ninguém confia.

• Sem rastreabilidade, por isso descartes em silêncio são descobertos nos testes de aceitação do utilizador.

Capture o estado atual registando-o

Abra o modelo na Trupeer AI, aplique o seu kit de marca para que o BRD corresponda aos restantes documentos do seu projeto e edite qualquer secção diretamente. A configuração está no guia do modelo.

A secção do estado atual é onde os BRDs são mais fracos, porque escrever como algo funciona hoje demora mais do que qualquer orçamento prevê e falha sempre em incluir as soluções alternativas. Registe o processo existente uma vez e a Trupeer AI produz a documentação escrita do estado atual com capturas de ecrã capturadas automaticamente, além de um walkthrough em vídeo narrado que pode anexar como apêndice. Os fornecedores que fazem propostas com base no seu BRD compreendem uma gravação de dois minutos mais depressa do que quatro páginas de texto.

Registe. Documente. Traduza-o para 65+ idiomas para equipas de entrega offshore. Guarde-o na sua base de conhecimento. Trupeer it.

Perguntas Frequentes

Existe um modelo gratuito de documento de requisitos de negócio em Word?

Sim. O Word é o formato principal, com notas de orientação em cada secção que apaga à medida que escreve, além da tabela de requisitos e do bloco de validação pré-construídos. Transferência gratuita, sem registo, sem marca de água.

Posso transferir um modelo de documento de requisitos de negócio em Word gratuitamente?

Sim. Todos os formatos são transferências gratuitas sem necessidade de conta. Use-o em tantos projetos quanto quiser.

Existe um modelo de documento de requisitos de negócio em formato Word doc?

Sim, é incluída uma versão .doc para sistemas e bibliotecas de documentos mais antigos que não lidam com .docx de forma limpa.

Existe um modelo gratuito de documento de requisitos de negócio em PDF?

Sim. O PDF é o formato de linha de base apenas de leitura, que é o que partilha depois da validação para que a versão aprovada não possa ser editada por acidente.

Existe um exemplo de documento de requisitos de negócio em PDF?

Sim. O exemplo trabalhado do sistema de despesas acima está incluído como um exemplo completo em PDF, com dez requisitos, critérios de aceitação, prioridades MoSCoW, suposições e riscos. Ler um BRD finalizado é a forma mais rápida de calibrar o quão específico o seu precisa de ser.

Onde posso transferir um modelo de documento de requisitos em Word?

Nesta página, em Word, .doc, Google Docs, Excel e PDF. Tudo gratuito. Se precisar da especificação funcional em vez dos requisitos de negócio, é um documento separado e a diferença é explicada acima.

O que é um BRD?

Um documento de requisitos de negócio. Indica o que um negócio precisa de um projeto e porquê, antes de serem tomadas decisões sobre como o construir, e serve como o documento que as partes interessadas assinam para confirmar uma compreensão partilhada.

O que deve incluir um documento de requisitos de negócio?

Controlo do documento, resumo executivo, objetivos mensuráveis do negócio, declaração do problema, âmbito com exclusões explícitas, partes interessadas, estado atual, requisitos numerados com prioridades e critérios de aceitação, suposições, restrições, dependências, riscos, custos e benefícios, cronograma, critérios de sucesso, glossário e validação.

Qual é a diferença entre requisitos de negócio e requisitos funcionais?

Os requisitos de negócio indicam o que o negócio precisa e porquê, independentemente de qualquer solução. Os requisitos funcionais indicam o que o sistema tem de fazer para os cumprir. "As despesas têm de ser reembolsadas em 10 dias úteis" é um requisito de negócio. "O sistema encaminha as despesas para o aprovador indicado na linha de reporte de RH" é funcional. Um requisito de negócio deve resistir à mudança de fornecedores.

Quanto tempo deve ter um documento de requisitos de negócio?

Dez a vinte páginas para um projeto de média dimensão. Projetos pequenos podem ser feitos em cinco. Depois de trinta, a secção de requisitos costuma já ter absorvido desenho funcional que pertence noutro lugar.

Quem escreve o documento de requisitos de negócio?

O analista de negócio, ou o product owner ou gestor de projeto quando não existe analista. Deve ser escrito com as partes interessadas, e não para elas, uma vez que um BRD produzido isoladamente é assinado sem ser lido.

Quem valida um BRD?

O patrocinador do negócio, o responsável pelo orçamento e o responsável de cada função cujo trabalho muda, além do responsável pela entrega ou de TI a confirmar que os requisitos são compreendidos. A validação deve seguir uma sessão de walkthrough, e não um e-mail de distribuição.

Quantos requisitos deve ter um BRD?

Quantos forem necessários para o âmbito, mas se estiver acima de cerca de oitenta, verifique se o detalhe funcional se infiltrou. Um sinal útil é a proporção do Deve ter: acima de aproximadamente 60%, a priorização não foi feita corretamente.

O que é uma matriz de rastreabilidade?

Uma tabela que liga cada requisito ao objetivo do negócio que serve, à especificação funcional que o aborda e ao caso de teste que o verifica. Apanha requisitos que nunca serão testados e trabalho que está a ser construído sem remeter para nenhum requisito.

Posso personalizar este modelo de documento de requisitos de negócio?

Sim, cada versão é totalmente editável. Apague as secções que não se aplicam em vez de deixar títulos vazios e adapte a tabela de requisitos ao seu próprio esquema de prioridades se não usar MoSCoW. Na Trupeer AI, também pode aplicar o seu kit de marca para que o BRD corresponda à restante documentação do seu projeto.

Modelos relacionados

• Modelo de plano de projeto

• Modelo de plano de gestão de projeto

• Modelo de documentação do projeto

• Modelo de documentação técnica

• Modelo de documentação de software

• Modelos de documentação de testes

• Modelo de processo de negócio

• Modelo de plano de gestão da mudança

• Modelo de plano de negócio