Preencha o formulário e gere um documento de escopo completo em Markdown, pronto para copiar ou baixar.
Preencha ao menos o nome do projeto ou o objetivo para gerar o documento.
Um documento de escopo (também chamado de scope statement ou declaração de escopo) é o contrato interno que define o que será feito e, igualmente importante, o que não será feito em um projeto de software. Ele responde perguntas essenciais antes mesmo do primeiro commit:
Responder essas perguntas por escrito, antes de codificar, é a forma mais econômica de evitar retrabalho: mudar texto custa zero; mudar código em produção custa muito.
Scope creep é o crescimento não planejado e incremental do escopo durante o projeto — pequenas adições que, individualmente, parecem razoáveis, mas que coletivamente atrasam entregas, inflam custos e esgotam o time. A raiz do problema costuma ser a ambiguidade: se o escopo não diz que algo está fora, qualquer parte interessada pode argumentar que está dentro.
A seção Fora de escopo resolve isso ao nomear explicitamente o que não será feito nesta versão ou contrato. Exemplos típicos: integração com sistema legado X, suporte a idioma Y, relatórios avançados, aplicativo mobile. Ao documentar a exclusão, você cria uma referência objetiva para responder a pedidos de expansão: "Conforme acordado no escopo, relatórios avançados estão fora desta fase — podemos abrir um novo ciclo para isso."
Use um nome curto, memorável e sem ambiguidade. Evite nomes genéricos como "Sistema Novo" ou "Plataforma". Prefira: "Portal de Reservas — v1", "API de Pagamentos Recorrentes", "Dashboard de Monitoramento de Frota".
Escreva em 2–5 frases o problema que o projeto resolve e o resultado esperado para o negócio. Uma boa fórmula: "[Ator] precisa [fazer algo] para [alcançar resultado]. Hoje, [problema atual]. Este projeto entrega [solução] que resulta em [benefício mensurável]."
Liste o que o sistema deve fazer — comportamentos e funcionalidades observáveis pelo usuário. Use linguagem de ação: "Permitir que o usuário...", "Exibir relatório de...", "Enviar notificação quando...". Evite detalhes de implementação (banco de dados, framework) — esses vão na Stack.
Qualidade e restrições do sistema que não são funcionalidades em si: desempenho ("resposta em até 500 ms para 95% das requisições"), disponibilidade ("99,5% mensal"), segurança ("dados em repouso criptografados com AES-256"), escalabilidade, acessibilidade (WCAG 2.1 AA), compatibilidade de navegadores, compliance (LGPD, PCI-DSS).
O que será efetivamente entregue ao final: "Código-fonte no repositório Git", "Deploy em ambiente de produção AWS", "Documentação da API (OpenAPI 3.0)", "Manual do usuário", "Suite de testes automatizados com cobertura mínima de 80%".
Itens que foram discutidos mas deliberadamente excluídos desta versão. Seja específico: "Aplicativo mobile (apenas web responsivo nesta fase)", "Integração com sistema ERP legado", "Relatórios personalizados pelo usuário", "Suporte ao idioma inglês".
Condições que o time assume como verdadeiras para que o escopo seja viável. Se uma premissa se mostrar falsa, o escopo precisa ser renegociado. Exemplos: "O cliente fornecerá acesso ao ambiente de homologação até a semana 2", "A API do parceiro estará disponível e documentada antes do início da integração", "A equipe de QA terá dois membros dedicados".
Eventos incertos que, se ocorrerem, impactam prazo, custo ou qualidade. Para cada risco, indique a probabilidade percebida e o impacto. Exemplos: "Mudança de requisitos na fase de integração (alta probabilidade, alto impacto)", "Indisponibilidade de fornecedor de API de terceiro (baixa probabilidade, alto impacto)".
Condições objetivas e verificáveis que definem "projeto concluído". Cada critério deve ser testável sem ambiguidade: "Todas as histórias de usuário de alta prioridade passam nos testes de aceitação", "Tempo de resposta da API é menor que 300 ms em carga de 100 req/s (ambiente de homologação)", "Zero vulnerabilidades críticas no relatório de SAST".
Liste as principais tecnologias escolhidas: linguagem(ns), frameworks, banco de dados, infraestrutura, serviços de terceiros. Isso alinha expectativas sobre o que o time precisa saber e sobre eventuais restrições de licença ou custo.
Pode ser uma data ("30 de setembro de 2025"), duração ("12 semanas"), ciclos ("4 sprints de 2 semanas") ou marco de negócio ("até o lançamento do produto — Q3 2025"). Inclua a data de início se já estiver definida.
O documento gerado pela ferramenta usa a sintaxe Markdown padrão (CommonMark), compatível com GitHub, GitLab, Notion, Confluence (via plugin), Obsidian, VS Code e a maioria das ferramentas de documentação modernas.
ESCOPO.md ou docs/scope.md no repositório.Não. Ao fechar a aba ou atualizar a página, o conteúdo digitado é perdido — copie ou baixe o documento antes de sair.
Sim. O documento é gerado como texto simples. Após copiar ou baixar o arquivo .md,
edite-o em qualquer editor de texto — VS Code, Notepad, Obsidian, Typora ou diretamente no
GitHub. O Markdown gerado segue sintaxe padrão e não usa extensões proprietárias.
Com adaptações, sim. A estrutura gerada cobre os elementos centrais de um escopo técnico. Para uma proposta comercial completa, você provavelmente precisará acrescentar seções de precificação, cronograma detalhado, responsabilidades do cliente e cláusulas contratuais. Use o documento como ponto de partida e adapte o tom para o contexto (interno ou externo).
Não há limite imposto pela ferramenta. Adicione quantos itens forem necessários em cada lista dinâmica. Itens deixados em branco são automaticamente ignorados na geração do documento.
Sim. O formulário não é limpo ao gerar o documento — você pode ajustar campos e gerar novamente quantas vezes quiser. Use o botão "Limpar" apenas quando quiser começar um escopo novo do zero.
As seções foram inspiradas em práticas consolidadas do PMBOK (Project Management Body of Knowledge) e em frameworks ágeis como Scrum e SAFe, adaptadas para o contexto de projetos de software. A estrutura é intencionalmente agnóstica à metodologia — funciona tanto para times que trabalham com sprints quanto para projetos waterfall ou contratos de escopo fechado.
Absolutamente. Um documento de escopo é útil mesmo para projetos individuais: ele força você a articular o objetivo, as funcionalidades e os limites antes de codificar, reduzindo o risco de escopo infinito (o famoso "vou adicionar só mais uma feature").
Premissas são condições que o time assume como verdadeiras sem confirmação formal. Documentá-las serve para dois propósitos: (1) alertar as partes interessadas sobre dependências externas que podem invalidar o escopo se não se concretizarem; (2) criar uma base objetiva para renegociação caso uma premissa se mostre falsa durante o projeto.