It's worth investing the time to draw up an accurate specification document

Henk Koopmans, head of sales and marketing at design consultancy Plextek, believes four steps should be considered when putting together a product requirement specification. "The first step, which we often see is missed out, is a certain amount of preparation," said Koopmans. He noted that when a person or department writes a specification, they tend to write it solely from their perspective when, in reality, they should be taking input from other teams. According to Koopmans, taking input initially from various departments will yield a more holistic and effective starting point. While a market requirement specification describes how much market share a product could have, the product specification asks how it will address that market need. This step, says Koopmans, highlights the purpose of the project to all those who will work with the document. The third step is to assemble user scenarios and use cases. These envisage who is going to use the product – not just the end users, but also those who will ship and install it. "Many of the problems we see with specifications are because user scenarios and use cases haven't been taken into consideration," Koopmans observed. "Of course, the further you go down the path of product development, the harder it is to undo or rectify these obvious things." Step four is what Koopmans refers to as remembering the product principles. As the specification is handed to a development department or to an external company, it's very easy to lose sight of what the product was initially about. According to Tim Fowler, commercial director of Cambridge Consultants' wireless division, conveying understanding is vital at all stages of the process. "If you describe something in a lot of detail, but the readership doesn't know what it means, then you haven't solved the problem because you need to share understanding," he said. "If the decision maker is not an engineer, it's important that you specify the impact of their decisions in a way they can understand." For example, it might be easy to describe something like a basic screw, but when you're specifying a product that's conceptually out of the ordinary, you need a way to make it comprehensible. "That involves more than just text," he suggested. "Typically, it will involve models and other types of communication that help the user understand what the specification is about." Indeed, specifications are not limited to long sets of prose; they can include prototypes to find the right communication mechanism that enables understanding. With CAD and 3d printing being more accessible, it is now much easier to create the look and feel of the product. "We use a whole range of techniques," said Fowler. "From physical model making, storyboarding what it means to the users, simple behavioural models, animation and even more sophisticated prototypes as part of the process of helping develop the specification." Communication is just one of the many pitfalls that can be encountered when writing a specification. Many of these issues are simply due to the nature of what is being discussed. For example, there are more formal specifications when it comes to software, which can sometimes be proven mathematically. But often, it's subjective. "How do you specify when something is attractive or simple to use?" noted Fowler. Take audio quality as an example. "Whether it sounds nice is a very subjective thing." It should also be remembered that these challenges will differ from company to company. Koopmans drew the comparison between a large, tier one defence supplier and a start up. The defence supplier is likely to have a lot of processes in place, so its specification writing is detailed, structured and defined. "While that works very well, it can also be so rigorous, so detailed and so rigid that, actually, they've specified innovation out of it," warned Koopmans. "You can be too detailed or too descriptive." At the other end of the spectrum is the start up, where the situation could be the other way round. "There's a real tendency for start ups to continue adding features because they're keen that the first product they get to market is a cracking one," said Koopmans. The problem with this approach is that it just increases development time. When it comes to innovation, Koopmans believes that, with many products, the simpler they are, the more innovative the customer becomes as they discover how to use it. "You can overspecify; have too many features in the product," he said. "A lot of the innovation could come from the user." In this respect, Koopmans suggests it's important to have a clear decision making tree which describes which features are vital, as well as those that won't delay the shipment of the product if they're left out. "It's really important to have this sort of structure because when timescales slip – and they do – you have to make a real conscientious decision." Fowler also emphasised that the specification has to account for change. "Having a process that allows you to change the specification as you go – to reflect reality – is quite important," he said. "The skill in specification writing is getting the first go as good as possible, but having the wherewithal to understand when things that are important emerge, and to be able to handle those effectively." It is important the specification process has a contingency strategy and can be handled in terms of risk management. This is particularly relevant to electronics, where room must be given for configurability. Fowler used basestations as an example. He described how it's possible to design the circuit so it can handle multiple bands with only a small number of component changes, meaning customisation options are available late in the process and don't require huge amounts of re engineering. "If adding new features means you have to redesign the entire thing," added Koopmans, "it means you haven't really specified it properly from day one." Both Fowler and Koopmans agree about the importance of including project management and traceability in the specification. "It's very easy to write down a specification and get someone to agree with it," said Fowler. "It's much harder to write it down, get someone to agree with it and actually find that it was correct." This comes down to the fact that, despite all the technology involved, specifications are a very human process. With this in mind, Koopmans concluded the focus should always be put on product value. "That's what it's all about," he said. "Somebody needs to buy it, use it and be excited about it."