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.
