Functional specifications are an unambiguous statement of what the product or service is supposed to do. It still does not explain exactly how this is done. It is the social contract between those who do the work and everyone else. It defines what we are supposed to do and how we’ll know when we’ve done it.

I believe that one of the roots of human suffering is implied social contracts.

Functional specifications are an exhaustive discussion of:
* features and functionality
* the kind and a description of the information to be managed
* a description of the business rules that apply to the information being managed
* imports/exports needed
* integrations needed
* work flows or use cases that show how the product or service is used
* any special security or privacy requirements

The functional specifications are many things to many people:
* to engineers it defines the work to be done
* to customers it defines what will be accomplished when the work is done
* to project managers it defines the milestones that can be tracked
* to SQA specialists it provides critical clarity on what the product is expected to do
* to all team members it provides a central place to find all information about what the product is supposed to do

In short, it is the
social contract between those who create the product or service and everyone else. By writing it down, everyone suffers less. This is an example of how transparency reduces harm.

If an engineer creates the functional specifications they must be approved by the stakeholders. If a stakeholder creates the functional specifications they must be approved by the engineer(s).

If an engineer thinks the functional specifications are incomplete or inaccurate, they need to speak up before they accept the project, or as soon as possible in any case. Treat it as an issue with the functional specifications using your favorite
issue tracking system. If issues prevent other work from being done, mention that in the issue and give it a higher priority.

If the stakeholders think the functional specifications are incomplete or inaccurate they should specify what they think is missing and return it to the engineer for additional work.

The functional specifications are a proposal: while it is still just words it isn’t very hard to change it.

Through a collaboration of stakeholders and one or more engineers the functional spec is iteratively refined until it meets everyone’s needs.

It is crucial that the functional specifications are agreed upon before any significant work on the project begins. Work can still begin (perhaps) on the parts of the project that are not encumbered by the ambiguity or incompleteness of the functional specifications.