Especificações funcionais descrevem como um relatório ou transação deve funcionar e ser interagido pelo usuário. Isso inclui o que o relatório fará, como os usuários irão interagir com ele e como ele será visualizado. Criar especificações funcionais ajuda a orientar o desenvolvimento do software e gerenciar as expectativas dos clientes.

1. What are Functional Specifications?
Contributed by Sivaraj
Functional specifications (functional specs), in the end, are the blueprint for how you want a
particular report and transaction to look and work. It details what the report will do, how a user will
interact with it, and what it will look like. By creating a blueprint of the report or transaction first, time
and productivity are saved during the development stage because the programmers can program
instead of also working out the logic of the user-experience. It will also enable you to manage the
expectations of your clients or management, as they will know exactly what to expect.
A key benefit of writing up a Functional Spec is in streamlining the development process. The
developer working from the spec has, ideally, all of their questions answered about the report or
transaction and can start building it. And since this is a spec that was approved by the client, they are
building nothing less than what the client is expecting. There should be nothing left to guess or
interpret when the spec is completed.
Functional Specification
A functional specification (or sometimes functional specifications) is a formal document used to
describe in detail for software developers a product's intended capabilities, appearance, and
interactions with users. The functional specification is a kind of guideline and continuing reference
point as the developers write the programming code. (At least one major product development group
used a "Write the manual first" approach. Before the product existed, they wrote the user's guide for
a word processing system, then declared that the user's guide was the functional specification. The
developers were challenged to create a product that matched what the user's guide described.)
Typically, the functional specification for an application program with a series of interactive windows
and dialogs with a user would show the visual appearance of the user interface and describe each of
the possible user input actions and the program response actions. A functional specification may also
contain formal descriptions of user tasks, dependencies on other products, and usability criteria.
Many companies have a guide for developers that describes what topics any product's functional
specification should contain.
For a sense of where the functional specification fits into the development process, here are a typical
series of steps in developing a software product:
Requirements:
This is a formal statement of what the product planners informed by their knowledge of the
marketplace and specific input from existing or potential customers believe is needed for a new
product or a new version of an existing product. Requirements are usually expressed in terms of
narrative statements and in a relatively general way.
Objectives: Objectives are written by product designers in response to the Requirements. They
describe in a more specific way what the product will look like. Objectives may describe
architectures, protocols, and standards to which the product will conform. Measurable objectives are
those that set some criteria by which the end product can be judged. Measurability can be in terms of
some index of customer satisfaction or in terms of capabilities and task times. Objectives must
recognize time and resource constraints. The development schedule is often part or a corollary of the
Objectives.
Functional specification.: The functional specification (usually functional spec or just spec for short) is
the formal response to the objectives. It describes all external user and programming interfaces that
the product must support.
Design change requests: Throughout the development process, as the need for change to the
functional specification is recognized, a formal change is described in a design change request.
Logic Specification:
The structure of the programming (for example, major groups of code modules that support a similar
function), individual code modules and their relationships, and the data parameters that they pass to
each other may be described in a formal document called a logic specification. The logic specification
describes internal interfaces and is for use only by the developers, testers, and, later, to some extent,
the programmers that service the product and provide code fixes to the field.
User documentation:
In general, all of the preceding documents (except the logic specification) are used as source
material for the technical manuals and online information (such as help pages) that are prepared for

2. the product's users.
Test plan: Most development groups have a formal test plan that describes test cases that will
exercise the programming that is written. Testing is done at the module (or unit) level, at the
component level, and at the system level in context with other products. This can be thought of as
alpha testing. The plan may also allow for beta test. Some companies provide an early version of the
product to a selected group of customers for testing in a "real world" situation.
The Final Product:
Ideally, the final product is a complete implementation of the functional specification and design
change requests, some of which may result from formal testing and beta testing. The cycle is then
repeated for the next version of the product, beginning with a new Requirements statement, which
ideally uses feedback from customers about the current product to determine what customers need
or want next.
Most software makers adhere to a formal development process similar to the one described above.
The hardware development process is similar but includes some additional considerations for the
outsourcing of parts and verification of the manufacturing process itself.
Quais são as especificações funcionais?Contribuição de Sivaraj Especificações
funcionais (especificações funcionais), no final, são o modelo de como você quer um
relatório específico e de transação para estudar e trabalhar. Ele detalha que o relatório
vai fazer, como um usuário interage com ele, eo que ele vai ficar. Ao criar um modelo
do relatório ou transacção em primeiro lugar, tempo e produtividade são salvos durante
a fase de desenvolvimento, porque os programadores podem programar em vez de
também trabalhar fora da lógica da experiência do usuário. Ele também irá permitir que
você gerencie as expectativas de seus clientes ou de gestão, como eles vão saber
exatamente o que esperar. Um dos principais benefícios de escrever uma especificação
funcional é na racionalização do processo de desenvolvimento. O desenvolvedor que
trabalha a partir da especificação tem, idealmente, todas as suas perguntas respondidas
sobre o relatório ou transacção e pode começar a construí-la. E uma vez que esta é uma
especificação que foi aprovado pelo cliente, eles estão construindo nada menos do que o
que o cliente está esperando. Não deve ser nada de adivinhar ou interpretar quando a
especificação é concluída. Especificação Funcional A especificação funcional (ou às
vezes especificações funcionais) é um documento formal usado para descrever em
detalhes para desenvolvedores de software destinados capacidades de um produto,
aparência, e interações com os usuários. A especificação funcional é um tipo de
orientação e ponto de referência continua como os desenvolvedores a escrever o código
de programação. (Pelo menos um grupo de desenvolvimento principal produto utilizado
um "Escreva o primeiro manual" abordagem. Antes que o produto existia, que escreveu
o guia do usuário para um sistema de processamento de texto, em seguida, declarou que
o guia do usuário foi a especificação funcional. Os desenvolvedores foram desafiados a
criar um produto que se equiparou ao que o guia do usuário descrito.) Normalmente, a
especificação funcional para um programa de aplicação com uma série de janelas
interativas e diálogos com um usuário poderia mostrar o aspecto visual da interface do
usuário e descrever cada uma das ações possíveis de entrada do usuário e as ações de
resposta do programa. A especificação funcional também pode conter descrições
formais de tarefas do usuário, dependências de outros produtos, e os critérios de
usabilidade. Muitas empresas têm um guia para desenvolvedores que descreve quais os
tópicos especificação funcional de qualquer produto deve conter. Para uma noção de
onde a especificação funcional se encaixa no processo de desenvolvimento, aqui estão
uma série típica de passos no desenvolvimento de um produto de software: Requisitos:
Esta é uma declaração formal de que os planejadores do produto informados pelo seu
conhecimento do mercado e entrada específica de clientes existentes ou potenciais
acreditam é necessário para um novo produto ou uma nova versão de um produto
existente. Requisitos são geralmente expressos em termos dos enunciados das narrativas

3. e de uma forma relativamente geral. Objetivos: Objetivos são escritos por designers de
produtos em resposta às exigências. Eles descrevem de forma mais específica o que o
produto será semelhante. Os objetivos podem descrever arquiteturas, protocolos e
padrões a que o produto estará em conformidade. Objetivos mensuráveis são as que
definir alguns critérios pelos quais o produto final pode ser avaliado. Mensurabilidade
pode ser em termos de algum índice de satisfação do cliente ou em termos de
capacidades e tempos de tarefas. Os objetivos devem reconhecer limitações de tempo e
recursos. O cronograma de desenvolvimento é muitas vezes parte ou um corolário dos
objectivos. Especificação funcional:. A especificação funcional (especificação funcional
ou apenas geralmente especificação para o short) é a resposta formal aos objectivos. Ele
descreve tudo o usuário externo e interfaces de programação de que o produto deve
suportar. Projete solicitações de mudança: Ao longo do processo de desenvolvimento,
como a necessidade de alteração da especificação funcional é reconhecida, uma
mudança formal é descrito em um pedido de alteração de design. Especificação lógica:
A estrutura da programação (por exemplo, grandes grupos de módulos de código que
suportam uma função semelhante), módulos de código individuais e as suas relações, e
os parâmetros de dados que eles passam uns com os outros pode ser descrito num
documento formal chamado uma especificação lógica. A especificação lógica descreve
as interfaces internas e é apenas para uso pelos desenvolvedores, testadores e, mais
tarde, em certa medida, os programadores que o serviço do produto e fornecer correções
de código para o campo. Documentação do usuário: Em geral, todos os documentos
anteriores (com excepção da especificação lógica) são utilizados como fonte de material
para os manuais técnicos e informações em linha (tais como as páginas de ajuda) que
são preparados para os utilizadores do produto. Plano de teste: A maioria dos grupos de
desenvolvimento têm um plano de teste formal que descreve casos de teste que
exercitam a programação que está escrito. O teste é feito no módulo (ou unidade) nível,
no nível de componente, e ao nível do sistema em contexto com outros produtos. Isto
pode ser pensado como alpha. O plano também pode permitir teste beta. Algumas
empresas fornecem uma versão inicial do produto para um grupo selecionado de
clientes para testar em um "mundo real" situação. O produto final: Idealmente, o
produto final é uma implementação completa da especificação funcional e pedidos de
mudança de design, alguns dos quais podem resultar de teste formal e beta de teste. O
ciclo é então repetido para a próxima versão do produto, começando com uma
declaração novas exigências, que, idealmente, usa o feedback dos clientes sobre o
produto atual para determinar o que os clientes precisam ou querem seguinte. A maioria
dos fabricantes de software aderir a um processo de desenvolvimento formal semelhante
ao descrito acima. O processo de desenvolvimento de hardware é semelhante, mas
inclui algumas considerações adicionais para a terceirização de peças e de verificação
do processo de fabricação em si.