Modelos de especificação funcional gratuito: passo a passo para uma experiência de desenvolvimento mais tranquila

O foco do Agile é encontrar a maneira mais eficiente de entregar um produto útil a um usuário. No desenvolvimento ágil, os documentos e processos tradicionais de requisitos funcionais são às vezes considerados financeiramente proibitivos. No entanto, planos e esboços mais detalhados podem aumentar a clareza.

Uma das ferramentas mais comuns e necessárias do Agile é a história do usuário. A história do usuário adiciona recursos para contextualizar o que precisa ser realizado. Você pode agrupar histórias de usuários similares para formar epics ágeis. Assim como nas especificações tradicionais de requisitos funcionais, a história do usuário descreve a tarefa ou recurso, mas não diz como os desenvolvedores devem fazer a implementação.

A história do usuário segue a seguinte sintaxe: "Como usuário, eu quero ter algo que gere algum benefício para mim". Veja alguns exemplos:

• Como motorista, eu quero saber quando a bateria do carro precisa ser substituída.
• Como cozinheiro, quero que uma tela com a receita se mantenha aberta enquanto eu cozinho.
• Como gato, quero minha porção de comida liberada na minha tigela às 16h todo dia.

Para testar se uma história de usuário está bem desenvolvida, aplique a sigla INVEST.

• Independent (independente): a história se sustenta?
• Negotiable (negociável): você pode mudar ou remover esta história sem impactar o resto do projeto?
• Valuable (valioso): essa história tem valor para o usuário final?
• Estimable (estimável): você consegue estimar o tamanho da história?
• Small (curta): a história do usuário é curta o suficiente?
• Testable (testável): é possível testar essa história?

Para fins de gestão de projetos, é possível dar um nome e uma identificação numerada às histórias dos usuários na ferramenta de rastreamento. Além disso, você pode marcar a prioridade de desenvolvimento, o sprint e o status da história. As histórias vão para a lista de pendências do produto Agile.

Os modelos da história do usuário são geralmente bastante simples: eles se concentram em identificar o papel do usuário, sua tarefa e o que a tarefa deve realizar. Além disso, o modelo a seguir inclui um espaço para identificar a história e as informações do ciclo de desenvolvimento.

Baixe o modelo simples da história do usuário

Excel | Word

O planejamento de um site exige uma alta compreensão da tecnologia necessária e um entendimento detalhado de quem usará o site e o que você (como proprietário do site) deseja que os usuários realizem. As histórias dos usuários empregadas no desenvolvimento Agile podem ajudar você a se concentrar nas necessidades dos usuários. Outras perguntas também ajudam a contextualizar o site.

O seguinte modelo de especificação de website faz uma série de perguntas para ajudar você a definir o propósito do site, para quem ele é desenvolvido, as atividades que os usuários realizarão no site e outras considerações especiais, como padrões de segurança PCI para transações financeiras.

Baixe o modelo de requisitos funcionais do site

Word

Download do modelo de especificação técnica do site

Excel

Ao desenvolver software e outras tecnologias com o método Cascata, você pode com frequência usar um modelo tradicional de requisitos ou especificações funcionais. Os requisitos funcionais listam os recursos e funções do que o produto "deve" fazer. Por exemplo: "O vácuo deve captar partículas menores que cinco mm".

‌ Baixe o modelo de especificações funcionais — Word

Você pode preferir um modelo com mais foco nos requisitos do negócio. Este modelo minimalista oferece espaço para você detalhar a finalidade do seu produto ou atualização no contexto de seus objetivos comerciais, além das considerações de design de alto nível.

‌ Baixe o modelo de requisitos funcionais — Word

 

Você pode criar casos de uso para muitos tipos de produtos, incluindo sites e software. Os casos de uso se concentram em tarefas que um usuário deve realizar com o produto. Por se concentrarem nas tarefas, os documentos de casos de uso ajudam a orientar os desenvolvedores na criação de produtos focados no usuário. Esses documentos também impedem que os interessados interpretem erroneamente o projeto do produto. Use este modelo de caso de uso para definir atores, etapas e ramos de uma tarefa.

Baixe o modelo de caso de uso

Word

Um documento de especificação funcional (FSD), também conhecido como documento de requisitos funcionais (FRD), é considerado por muitos especialistas em gestão de projetos e desenvolvimento de software como a ferramenta essencial para evitar a confusão e o mal direcionamento de um projeto.

Embora o FSD seja frequentemente associado ao desenvolvimento de software e da web, ele tem um função importante em cada projeto, seja o lançamento de um novo produto, uma atualização, o desenvolvimento de um produto de software ou item tangível, ou o estabelecimento de mudanças de processo ou organizacionais. Os documentos de especificação funcional apresentam as expectativas comerciais e de engenharia. Todas as partes interessadas analisam e aprovam o documento. O resultado é um documento de referência para o produto proposto que se dirige a todas as partes da organização, dos codificadores aos projetistas e pessoal de vendas.

Você pode usar um modelo de documento de especificação funcional para garantir a inclusão de todas as informações essenciais de desenvolvimento em um documento. Além disso, os modelos garantem que, a cada nova iniciativa, as equipes se concentrem nos requisitos do produto em vez de perder tempo determinando o projeto do documento de especificações. Os modelos devem ser personalizados para atender às necessidades exclusivas de cada equipe ou empresa.

Tradicionalmente, os FRDs tendem a ser longos, secos e, muitas vezes, técnicos. Mas tais documentos podem não ser necessários nem úteis. Como o objetivo do documento de requisitos funcionais é ampliar o projeto para todos os interessados, os FRDs evitam longas discussões técnicas. Embora seja possível incluir muitos tipos de requisitos e informações de suporte (veja a lista abaixo), a melhor prática é descrever as intenções básicas do FRD. Em sua essência, o documento deve descrever o contexto e as características e funções a serem desenvolvidas. Um documento de projeto técnico é criado com base nas especificações aceitas dos requisitos funcionais. O FRD não deve duplicar os outros requisitos ou documentos de processo.

Os documentos de especificações funcionais seguem um processo de aprovação: os usuários corporativos verificam se a solução atende às suas necessidades e os revisores técnicos analisam se a solução descrita pode ser implementada. Frequentemente, os principais revisores são testadores, usuários finais, redatores técnicos e proprietários de produtos ou sistemas. O documento é declarado concluído quando todos concordam com o conteúdo. Em seguida, algumas organizações começam a desenvolver um documento de arquitetura de sistemas.

Uma especificação de requisitos funcionais serve como um documento de referência para toda a equipe. Ele mostra o que os desenvolvedores de produtos devem desenvolver, o que testadores devem testar, o que os redatores devem documentar e o que os vendedores devem vender. Uma especificação funcional por escrito mostra que o projeto e a intenção foram cuidadosamente considerados antes do início do desenvolvimento. Também ilustra que, após a aprovação das especificações, as expectativas de todos os interessados são as mesmas. Não se deve escrever as especificações para preencher o documento após o produto ter sido codificado.

Alguns analistas de negócios e desenvolvedores distinguem as especificações funcionais dos requisitos funcionais dizendo que os requisitos descrevem o que o software deve fazer e as especificações descrevem como deve fazê-lo. Na prática, essas duas funções se combinam.

Modelos de documentos de especificações (ou requisitos) funcionais poem ter diversos formatos. Esse formato é determinado de acordo com as necessidades da empresa.

• Requisitos funcionais: são tradicionalmente desenvolvidos para software e outras tecnologias que utilizam o método de desenvolvimento Cascata. Os requisitos funcionais listam os recursos e funções do que o produto "deve" fazer. Por exemplo: "O vácuo deve captar partículas menores que cinco mm".
• Casos de uso: os casos de uso muitas vezes existem por conta própria. Entretanto, as empresas que valorizam a experiência do usuário geralmente incorporam casos de uso aos requisitos funcionais. Utilize as funções e recursos definidos nos casos no contexto das ações do usuário. Por exemplo, "O usuário toca duas vezes na tela do celular. A tela se ilumina. O usuário desliza a tela para a direita para desbloquear o celular e a funcionalidade".
• História do usuário: formam o núcleo do desenvolvimento ágil ao descreverem o design do produto como o que o usuário precisa fazer. Esta abordagem enxuta ajuda as equipes a entregar valor aos usuários da maneira mais eficiente. Histórias de usuários seguem este formato: "Como usuário, eu quero fazer algo que gere algum benefício para mim".

Normalmente, os analistas de negócios e líderes técnicos criam modelos e especificações funcionais para compartilhar com as partes interessadas comerciais e técnicas, que fornecem análises para garantir que as entregas estejam dentro do esperado.

Você pode usar especificações funcionais ao desenvolver novos softwares e atualizações. Também pode usá-los para alterações na engenharia organizacional e de sistemas, desenvolvimento web e muito mais. Os usuários das especificações incluem os seguintes grupos:

• Desenvolvedores, que codificam o produto
• Designers, que criam a interface do usuário (IU) para o software, dispositivo ou site
• Testadores, que garantem o funcionamento correto do código de acordo com a especificação
• Profissionais de marketing, que preparam documentos de geração de demanda da nova funcionalidade
• Equipes de vendas, que vendem o recurso e o produto
• Redatores técnicos ou de assistência ao usuário, que documentam como o produto funciona para administradores, usuários finais e outras funções

Apesar de existirem muitas combinações e permutações, os documentos de especificação funcional (DSF) e os documentos de requisitos comerciais (BRD) são, às vezes, separados.

BRDs descrevem os requisitos comerciais de nível mais alto para um produto (o que um produto faz). BRDs evitam detalhes técnicos em favor de uma fundamentação detalhada para o produto. Uma compreensão clara do que o produto oferece e por que ele é necessário pode muitas vezes ajudar a orientar o desenvolvimento através de disputas sobre a direção do produto. Os FSDs podem se concentrar em delinear as características e funcionalidades do produto que você precisa para atingir seu objetivo final.

Criar um produto, seja tangível ou transacional, pode envolver a geração de muitos documentos. Os modelos de especificação funcional pode ser usado em conjunto com qualquer um dos seguintes itens:

• Requisitos do usuário: este documento representa o que o usuário espera que o produto faça. Alguns profissionais consideram que a exigência do usuário é uma parte do documento de requisitos funcionais. Se este documento existir, deverá ser incluído em seu processo geral de desenvolvimento. No desenvolvimento ágil, os requisitos do usuário (expressos como histórias do usuário) são considerados o coração dos requisitos funcionais.
• Requisitos do produto: usado indistintamente com um documento de requisitos de mercado, este documento detalha a finalidade de um produto.
• Documentos de processos executivos: este documento detalha um processo executivo.
• Avaliações das necessidades comerciais: este documento descreve as lacunas entre as condições atuais e as condições comerciais desejadas.
• Especificações técnicas de projeto: este documento descreve (com os mínimos detalhes) os elementos de programação necessários para o projeto proposto.
• Documentos de validação: os documentos de validação podem incluir uma matriz de rastreabilidade (que rastreia as características durante todo o processo de desenvolvimento), planos de teste e requisitos de operação.
• Requisitos de sistemas: este documento esboça uma alta expectativa para um sistema ou produto.
• Requisitos comerciais: este documento descreve as principais razões para a criação ou atualização de um produto.
• Casos de uso: este documento oferece detalhes funcionais e contexto para características a partir de uma perspectiva do usuário.
• História do usuário: este documento é utilizado principalmente para o desenvolvimento ágil. Ela comunica a intenção do produto, detalhando o que o usuário fará com ele.

Os requisitos podem ser classificados como especificações funcionais e não funcionais (o quê e como).

• Requisito funcional: descreve um comportamento, atividade ou resultado esperado de um produto ou sistema. Por exemplo, "Filtrar partículas da água" ou "Imprimir uma página". Os requisitos funcionais comuns incluem funções administrativas, autorização e autenticação, rastreamento e relatórios de auditoria, e regras comerciais.
• Requisito não funcional: descreve como algo funciona, o que também pode ser considerado uma restrição, atributo ou parâmetro. Se a palavra em inglês que descreve o processo termina em "ity", não é funcional. Os exemplos incluem usabilidade, manutenção e segurança, além de desempenho e exigências regulatórias.

No SAP, um documento de especificações funcionais é uma descrição do produto do ponto de vista das partes interessadas, com expectativas precisas sobre como cada recurso se relaciona com o SAP. Você cria especificações funcionais depois de combinar o FSD e o documento de requisitos de software em um só.

No mínimo, os FRDs devem incluir estes elementos:

• A quem o produto se destina
• Quem tem autorização para usar o produto
• Entradas no sistema
• O que cada tela deve fazer
• Fluxos de trabalho do sistema
• Saídas
• Exigências regulatórias abordadas pelo produto
• Exigências comerciais específicas de sua empresa

Uma descrição por escrito das funções desejadas é uma parte essencial do desenvolvimento do produto, mas a forma que o modelo de requisitos funcionais assume também deve ser regida pelas necessidades da sua equipe.

Ao desenvolver um modelo, ou ao considerar melhorias em um processo de desenvolvimento existente, pergunte o que desejam todos os interessados no resultado do produto. Cada formato oferece vantagens e desvantagens:

• As declarações "Shall" dos requisitos funcionais tradicionais tendem a precisar de contexto e estão mais sujeitas à interpretação do desenvolvedor.
• Os casos de uso oferecem contexto e detalhes, mas isso pode ser um obstáculo: o escopo pode se tornar demorado à medida que as necessidades reais do usuário se tornam claras. Requisitos menores podem se perder entre os casos de uso.
• A história do usuário oferece a vantagem de descrever as necessidades dos usuários no contexto das exigências comerciais. Entretanto, podem exigir um esforço extra (por exemplo, pesquisar a implementação adequada). Os desenvolvedores e outros interessados também podem se concentrar tanto em histórias individuais que excluem o contexto do produto.

Ao considerar que ferramenta usar para criar documentos de requisitos de software, as necessidades de sua organização são, mais uma vez, fundamentais. O que dá certo para outras empresas pode não dar certo para você.

• Gerenciamento de documentação: oferece uma das ferramentas mais fáceis e mais onipresentes para criar modelos e renderizar documentos. Muitos documentos de requisitos funcionais estão disponíveis como modelos de documentos.
• Software de planilha: planilhas permitem adicionar colunas conforme necessário. Eles também diminuem a pressão para elaborar frases perfeitas, porque você só precisa incluir os detalhes essenciais que um leitor necessita para desenvolver o produto correto.
• Plataforma Agile de gestão de projetos: muitas plataformas construídas propositadamente oferecem funcionalidade para detalhar requisitos ou histórias de usuários e incluem o acompanhamento de recursos.

Embora alguns requisitos sejam básicos e essenciais para transmitir a intenção do seu produto, outros podem ou não ser valiosos para o desenvolvimento de seu produto. O formato que você escolher também pode ser determinado pelo produto que você está desenvolvendo. Você pode usar a lista a seguir como um guia para preparar os requisitos funcionais:

• Seção frontal

  • Página de metadados: é um resumo do documento.
  • Instruções aos autores: explica as informações particulares exigidas por sua organização em um documento de especificações. Estas instruções podem aparecer na introdução ou em todo o modelo.
  • Número da versão
  • Alterar página de registro/revisão: no modelo e no documento de exigência publicado, você deve incluir todas as emendas, detalhes, datas e iniciais de quem fez a aprovação.
  • Bloco de aprovação: implica aprovar cada revisão e exigência com uma assinatura.
  • Lista de distribuição: alguns membros da equipe podem ser solicitados a revisar o documento. A visualização também pode ser restrita a apenas alguns membros da equipe.

• Visão geral

  • Descrição do produto
  • Visão geral das exigências comerciais
  • Escopo do trabalho (o que será e o que não será considerado)
  • Descrição do sistema atual
  • Convenções do documento
  • Terminologia (incluindo siglas)
  • Referências
  • Restrições e suposições gerais
     

• Funcionalidade

  • Processo executivo
  • Métodos propostos
  • Funções do usuário/comunidade de usuários
  • Casos de uso
  • Histórias dos usuários
  • Fluxos de trabalho dentro do sistema
  • Protótipos do projeto
  • Wireframes ou storyboards
  • Lista de recursos e descrições das funções
  • Requisitos de dados
  • Funcionalidade
  • Gerenciamento da configuração
  • Plataforma
  • Instalação
  • Portabilidade
  • Expansibilidade
  • Personalização
  • Impressão
  • Manuseio de erros
  • Suporte e manutenção
  • Internacionalização
  • Ajuda e documentação
     

• Outros softwares

  • Entradas, saídas e processamento
  • Interfaces externas
  • Interfaces de usuário
  • Interfaces de hardware
  • Interfaces de software
  • Interfaces de comunicação
  • Suporte à base de dados
     

• Atributos

  • Segurança
  • Confiabilidade, disponibilidade, facilidade de manutenção, usabilidade, compatibilidade
  • Requisitos regulatórios
     

• Anexos

  • Modelos de análise

Capacite seu pessoal para ir além com uma plataforma flexível desenvolvida para atender às necessidades da sua equipe e se adaptar conforme essas necessidades mudam. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período de tempo. Experimente o Smartsheet gratuitamente hoje mesmo.