Exemplo de Especificação Funcional

Web Development Functional Specifications Document

Especificação funcional – Estrutura do documento (2ª parte)

Bom, depois de um longo tempo, volto a tratar de especificação funcional, agora abrangendo mais o documento em si, já que a nossa última conversa (apesar do adiantar do assunto nos comentários) foi somente uma breve introdução do assunto.

Percebi que muitas pessoas chegaram até aqui pelos mecanismos de busca, procurando informações sobre o tema, então novamente gostaria de informar que a estrutura e o estudo aqui proposto é um conjunto de práticas que, com a minha experiência acadêmica e profissional, entendi que são as mais próximas da realidade de um projeto de software. Conforme o passar dos anos e adquirindo mais experiência com o tema, certamente mudarei alguns pontos de vista, talvez até todos. O aprendizado contínuo derruba alguns paradigmas e isto é natural.

A conversa agora parece supérflua, mas não é. Conversaremos sobre a estrutura do documento de especificação funcional, que deve ser o padrão no projeto. A principio “padrão” e “estrutura” parecem remeter ao mesmo sentido, então vamos tirar as possíveis dúvidas:

• Padrão: quando digo padrão quero dizer que existe um modelo de documento a qual sua empresa ou você irá adotar para especificar funcionalmente todas as necessidades do seu cliente.

  Todos os documentos partem deste modelo, que possui uma estrutura comum, ou seja, todos seus documentos de especificação funcional serão reconhecidos e identificados pela mesma forma.

  Se há equipes diferentes que terão como meta a especificação de documentos funcionais de partes ou módulos diferentes de um mesmo sistema, os documentos de saída de cada equipe deverão possuir a mesma padronização.

  Você deve pensar: “Mas isto é muito lógico para ser explicado”, concordo! Mas geralmente existem diversos tipos de especificação funcional dispostas para um mesmo projeto, principalmente se existem diferentes equipes trabalhando diferentes frentes. É importante que logo no início do projeto este documento seja apresentado como padrão;

• Estrutura: logicamente se é determinado um padrão, a estrutura também é padronizada, ou seja, é padrão para todos os documentos terem a mesma estrutura. Mas a estrutura a ser padronizada deve ser organizada de uma forma clara, objetiva e estruturada para que os processos vindouros após a finalização da especificação identifiquem as soluções propostas deste documento.

A meta então é debater uma estrutura para a padronização do documento de especificação funcional.

Primeiramente é importante definir a formatação da documentação, processo simples para os editores eletrônicos de textos atuais, como a escolha da fonte e o tamanho (recomendo Times New Roman com 12pt), margens, tabulações, cabeçalho e rodapé, títulos e subtítulos. É necessária a paginação, de preferência no formato “página atual/quantidade de páginas”.

Agora vamos falar sobre a estrutura em si, esta estrutura foi pensada com partes básicas de um projeto, porém projetos variam de necessidade, ou seja, um projeto de desenvolvimento de software tem necessidades e particularidades diferentes de um projeto de estruturação de rede, pense neste documento como ele realmente deve ser: uma forma de explicar o que deve ser feito para resolver um problema. Se a estrutura do documento está estruturada de uma forma a gerar dúvidas em seu entendimento que dirá o desenvolvimento da solução.

Esta estrutura pensada está ordenada da seguinte forma:

A capa: Ela deve conter as identificações básicas, porém importantes para o documento, que são: nome e/ou logo da sua empresa, o título do documento: “Especificação funcional”, descrição do projeto, se houver divisão do projeto por partes da solução deve-se colocar a descrição da parte da solução (Exemplo: Projeto: Controle de Locadora, Frente: Controle de estoque), Autor(es) do documento.

Índice: básico.

Controle de versão: deverá iniciar em 0 ou 1, com o nome do autor da versão, data de atualização da versão e motivo da atualização. Cada mudança na especificação funcional deverá conter o registro de versões para nortear as mudanças de escopo dentro do documento de especificação funcional.

Descrição da solução: este é a parte principal do documento, é onde será solucionado o diagnóstico do cliente, nos ateremos em breve a este conteúdo.

Quadro de referências: contém as palavras ou termos utilizados no documento que não são de conhecimento do cliente. Como o cliente deverá assinar este documento ele deverá também entender os termos descritos neste.

Convenhamos que em diversas vezes usamos termos técnicos ou particulares para identificar uma solução ou um processo específico e o cliente não necessariamente precisa sabê-los. É importante então referenciarmos o que significa estes termos quando usados no documento, nesta sessão.

Por exemplo: “O cálculo do valor do aluguel será prorrateado quando da entrega antecipada em número de dias”. O que é prorrateado? Este termo para este caso deverá ser explicado nesta sessão do documento.

Anexos: Algumas vezes utilizamos de outros documentos para diagnosticar e especificar a solução, portanto estes documentos são as bases desta análise. É importante anexar estes documentos nesta sessão para talvez justificar posteriormente alguma lógica de solução. Recomendo o anexo das atas das reuniões no projeto.

Aceite: É o local onde será selado o pacto entre cliente e desenvolvedor.

É a assinatura de ambos que significa: O cliente entendeu o documento e concorda que o quê está escrito resolve seu problema e que o desenvolvedor terá que lhe entregar tudo o que está descrito neste documento. É a aprovação do contrato.

Basicamente (ufa) entendo que estes são as principais divisões da estrutura de um documento funcional, se você entende diferente ou entende que existem mais necessidades a serem citadas como importantes neste documento, não deixe de comentar, lembre-se que esta série de matérias é um bate papo entre eu e vocês sobre algo que temos em comum: a necessidade de entender melhor nosso cliente e fazer melhor aquilo que será a menina dos olhos dele.

Especificação funcional – Entendendo o desejo do cliente (Parte 1)

Você trabalha com desenvolvimento de soluções em tecnologia da informação? Então você vai entender direitinho o que eu estou falando!

Com a sua licença pelo trocadilho: cliente é como mulher, você pode até saber do que ele precisa, mas geralmente não sabe o que ele realmente deseja.

Sim, acredite em mim! Não é por maldade ou por falta de vontade que isto acontece. Talvez por uma deficiência na comunicação, talvez por dificuldade de expressão, talvez por falta de conhecimento da necessidade, enfim, centenas e centenas de motivos para que isso venha a acontecer.

Se você está do outro lado, como salvador da pátria, senhor das soluções há muito esperadas ou o responsável em deixar a vida de um monte de gente mais simples, amigo… Você convive com um problema e tanto.

Independente do tamanho do seu cliente (não tamanho físico, mas sim corporativo) ele está pagando por um desejo e você recebendo para realizá-lo. Se você não entende perfeitamente este desejo, provavelmente não entregará a solução correta ou pelo menos completa. E convenhamos, se isto acontecer você realmente está encrencado, pois qualquer que seja sua solução para este problema, será um prejuízo. Seja seu (mais provável), seja do cliente.

Por mais que isto é claro, muitas empresas não dão o devido valor para uma fase do projeto: o levantamento de requisitos para elaboração da especificação funcional.

Se você já é experiente em gestão de projetos ou já participou de alguns, pode pular os três próximos parágrafos, caso contrário, explicarei resumidamente o que seria este levantamento de requisitos na especificação funcional.

Podemos dizer que a especificação funcional é o primeiro documento a ser elaborado quando o projeto e software é iniciado, ou seja, após a sua viabilidade ser aprovada. Para não restar dúvida sobre este conceito, vamos abrir o leque e entender corretamente estes termos:

Projeto de software é uma execução de tarefas exercidas em um determinado tempo por um ou mais pessoas que tem por objetivo um resultado específico. Ele tem início, meio e fim. Envolve tipicamente a análise, especificação, o projeto (design), desenvolvimento, testes e/ou manutenções dos componentes de software e documentação associada.

A especificação funcional é o documento que contém o que o sistema deverá processar quando da sua entrega. Ele é um contrato contendo o que deve ser feito pelo prestador e o que será entregue ao cliente. Este documento é o coração do projeto.

Tendo entendido perfeitamente que é projeto e percebido a importância da especificação funcional, inicio aqui a primeira parte destas matérias sobre especificação funcional.

Adianto logo que os conceitos aqui expressos por mim são baseados em minhas experiências com o tema e não levantarei qualquer tipo de bandeira (CMM, PMBOK, Etc.) por mais que alguns de meus conceitos são graças a estas técnicas. Quero bater um papo sobre esta fase tão importante da vida do projeto.

Gostaria que os leitores deste humilde blog participassem com suas opiniões, experiências e visões sobre gestão de projetos, principalmente na expecificação funcional.