A few weeks ago I wrote about a post on ways to improve the development of product requirements at the onset of a new product development project. Last week I came across an interesting article on tips to write a better functional specification. Both are extremely important documents used to guide the efforts of all design team members and and ensure that the project’s objectives are ultimately met.
What’s the difference between product requirements and functional specifications?
Product requirements outline how a business problem will be solved by the creation of a new product, whereas functional specifications or requirements describe the function of the product and how it will solve the problem. Product requirements are generally broader in nature, whereas functional specs are more specific and written in more technical language.
Every design project starts with the creation of a formal functional specification. This becomes the roadmap by which all design participants must travel to hopefully arrived at a successful product launch. By definition, a functional specification is a document that describes the critical requirements and features of a proposed product. Each functional requirement is defined quantitatively to avoid ambiguity and errors and is typically defined within a range of values that are considered acceptable.
Problems arise when specifications not followed
Once clients and designers and engineers agree upon a working document outlining the project’s general requirements and begin work, the functional specification sometimes can stray, causing confusion. This can result from over-descriptiveness in an attempt to appease everyone. Often problems stem from the belief that the functional specification must fully describe and define every functionality and feature in exhaustive detail.
K. Ouajjani shared an article in the Mechanical Design Forum. She described a functional specification as a map of a meadow leading towards 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.
With this visual in mind, here are 10 tips to help when writing a functional specification for any 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 are 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 if your customer is German and you’re working with a team of Chinese, Italians and Hungarians, you will all still understand a FAST diagram.
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
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.
