In the mechanical engineering and design world, many things seem trickier to begin with than they actually are. Writing a formal specification is one of those things. Because of its perceived complexity, some people do away with it altogether and others write a quick one just for the sake of audits. Most don’t understand the important role the specification plays in the overall design process. In addition, there is confusion about how exactly a functional specification is written.
A functional specification is a document that describes the critical requirements and features of a design project. Each functional requirement is defined quantitatively to avoid ambiguity, and is normally defined within a range of values which are considered acceptable.
However, once general requirements are agreed upon with the client and the designers begin to work, the functional specification can sometimes stray from a neat, quantitative document. Problems can arise due to over-descriptiveness, trying to make everyone happy, being too specific with one requirement at the expense of another, etc. Most of these problems arise from the belief that the functional specification must fully describe and define every functionality and feature in exhaustive detail.
Think of the functional specification as a map of a meadow leading toward a big red X, with a few red dots that mark the path, rather than a highly scaled map with hundreds of red dots at 0.001 precision marking every single point on the path.
It is understandable that some people need the reassurance of a bulletproof plan (often to keep management happy). However, this is the job of a project plan, and not the functional specification. Ultimately, the functional specification cannot be fully written until the very end of the project. When a mechanical designer fully understands this, flexibility in ideas and space for creativity are available. This also avoids the possibility of making false promises to the customer at the beginning of the project.
Here are 10 great tips for writing a functional specification for a mechanical engineering project:
Tip 1: Understand the requirements
It is vitally important to understand the requirements correctly and list them clearly. Spend as much time as you need on them but make sure to fully realize what the client needs and expects from you.
Tip 2: Translate requirements into quantitative values
The main Xs on your design map should be translated into numbers or ranges. If a major requirement can’t be translated into a number, then it’s not a major one. Your client shouldn’t give you such an undefined requirement in the first place because it could be a waste of time and money for both of you.
Tip 3: Build from the requirements
The requirements are like the roots that are the foundation of your mechanical tree. Take a vegetal approach and look at the requirements of your requirements, the environments, and the compulsory tools to achieve them, but don’t go too far with it. Using this approach, every new requirement will be directly linked to a fundamental one and its existence can’t be questioned.
Tip 4: Give secondary requirements a range
Usually, the minor requirements come as a means to fulfil the main ones. Also, they normally won’t necessarily have a specific value but a range. This will help later when the choice of a value will depend on the designer and won’t really affect the mechanical system. By noticing you have a recurrent range in other requirements, the designer can choose a value that will fit most cases and cut back on your production costs while unifying your construction parts, making it easier to track, buy and change them.
Tip 5: Develop the external requirements
Once you are done with the internal requirements of your machine, you can build a set of external requirements that define the design’s interaction with the environment. These usually describe the shell parts, the security components, or the protection systems. It is possible to get carried away with many external requirements, but remember that this is a functional specification that merely sets the primary pace for your design, so no need to get too descriptive.
Tip 6: Define the external requirements
These requirements should be the least quantitative ones. Yet, thanks to advances made in quality, security and protection fields, you can easily quantify them by quoting standards or assigning systems, whether they are mechanical ones used to prevent accidents, or management ones that quality departments build onsite.
Tip 7: Define the control criteria
How do we know that a requirement is valid or fulfilled? Means of control are often disregarded yet very important, even in the first steps of the design. Defining a requirement and setting a value or a range for it won’t be useful if you can’t actually make it reach such a value or fulfil its goal. How you control that can be as simple as a visual control or as elaborate as adding a sensor. This might even result in the creation of a new requirement.
Tip 8: Organize your requirements
You may sometimes encounter functional specifications written in paragraphs, but this format is not recommended. There is nothing better for a functional specification than a good FAST (Functional Analysis System Technique) diagram. If you are a mechanical designer with a handful of requirements and numbers, the FAST display is a neat and efficient writing format for a functional specification. Even f your customer is German and you’re working with a team of Chinese, Italians and Hungarians, you will all still understand a FAST diagram.
The FAST diagram is an elaborate tree that takes start from one main requirement (see basic example in Fig.1). From this point, you branch out the additional requirements that are directly linked to the main one, and then define the technological solutions that will be involved in each.
Fig.1: Basic example of a FAST diagram
In our example, the client asked for a machine that will simultaneously emboss four pipes in the holes of a certain part. The main requirement is therefore the simultaneous embossing of four pipes in four holes with a force of 20 KN, at 2.4m/s velocity. This will result in several secondary requirements that define the translation, speed and force required. Furthermore, those requirements might lead to a third set of requirements that will describe the support system and even more details. Finally there will be the technological solutions setting that will list the parts, manufactured or available to buy, that the machine will require.
Tip 9: Add a flexibility scale
According to some senior engineers, this is an unnecessary category to add. However, it can save time when you have a flexibility scale that you apply to each secondary requirement. Giving a range doesn’t define how much you can modify a requirement or whether or not you can remove it. Taking the time to define a flexibility scale, then adding a branch to every secondary requirement can make it easier to decide what to modify and how.
Tip 10: Use technical language
We spoke about this point in the introduction. This is critical for every scientific and engineering discipline. If technical language is not used a functional specification can be left wide open to personal interpretation. Be precise and specific with your language.
