One Page Guide: Guide to Specfifications

What’s the issue?

An alarming issue is that most electronic product developments fail ROI requirements (even fail to materialise at all) at the first attempt. Why? – poor management of expectations because specifications aren’t thorough.

Specifications (detailed, written, mutually approved descriptions of requirements) are the only vehicle by which expectations can be managed properly, but it is unfortunate that misunderstanding of the scope and effect of the different types of specification is widespread. Misunderstanding of this topic is the most common cause of project failure. Some aphorisms follow in the bullets below:

• There are multiple levels of specification and the level at which a project is determines the cost and delivery of a given project.
• Specifications must be reviewed constantly during the course of a project. This means that there is a running cost associated with them.
• Only the most focused or simple projects don’t change during a project’s duration. This means there is a knock-on development cost/time associated with the changes that are inevitable during the course of most projects. 
• The most common area of confusion lies between Engineering Specification and the Product and Performance Specifications. Engineering Specifications define precisely what must be done to achieve all expectations at a level that would allow engineers to simply develop without even knowing the product’s purpose. It is only Engineering Specifications that can have fixed and firm quotes with predictable delivery. All other levels of specification have risk/time/cost associated with them.
• Development projects that have run on specifications that have to be ‘dusted off’ at the time of test are likely to be those which fail to satisfy. Projects that have dynamic activity with specifications through the entire development are those that tend to succeed. 

What are the different specification types and what are they for?

The EM classifies specifications as follows:

• Business Specification: A definition of commercial requirements. It could reasonably be asserted that many/most of these are not the concern of the developer, but it is not then reasonable to make a developer accountable for unstated commercial requirements. The minimum measure that should be in a Business Specification is a prime cost for the product in question (effectively manufacturing cost), but the most thorough form of Business Specification derives its requirements from every section of a Business Plan. So, why can’t a client just ask for the cheapest possible? The reason is that there is a development cost associated with making the manufacturing cost as cheap as possible that consequently affects ROI. The bullets below put some flesh on the bones of this:
  • Components would normally be chosen from reputable suppliers that aren’t necessarily the cheapest. If cheap supply coupled with reliability is sought it is necessary for an engineer to do a considerable amount of costly research.
  • The design may be affected. An orthodox and ‘known to work’ method might be changed to save cost, but this knocks on into extra work to ensure the design and production aren’t compromised by such choices.
  • There may also hidden additions to manufacturing cost from a minimum manufacturing cost requirement. It may be necessary to do more auditing of suppliers or inspection after following a cheapest possible route. 
• Story Specification: A Story Specification may not seem serious in the company of the Business, Product, Performance, etc., Specifications, but it is in that it fulfils the requirements of the ISO 9001 Quality Standard (Customer feedback and focus) and tunes the project to the client’s needs. Scientists, engineers and accountants tend to view the world objectively, but nearly everyone else sees it subjectively, i.e., emotional satisfaction is paramount. This Hegelian philosophy perhaps needs an example to make it clearer. A client might want an electric go-kart. Engineers will tend to leap straight to the physical solution by asking questions like: What size electric motor do you want? What is the sharpest bend it must be able to go round? How far must it go before it needs to be re-charged, etc. Unfortunately, this is not typically how a client thinks as any salesperson will explain. What drives us is how we feel. Appealing to emotions and senses is critical if customer satisfaction is to be achieved, and this is what the Story Specification does. A good example relates to wealth. People  don’t say they want to have a net asset worth of £2,000,000. ‘I want to be rich’ is more likely to be said, and that is really ‘I want to feel rich’. Some good questions to both sell the product and make sure the product satisfies are:
  • Do you want to go fast?
  • Are you trying to be green with the design?
  • Is comfort important to you?
  • Which is most important: speed or driving experience?
  • Do you enjoy off-roading?
  • How safe do you want to be?

          The Story Specification asks questions like these to probe a client’s emotional response to a project, and what his/her senses require. 

• Product Specification: The Product Specification is a definition of the product’s function and features (block diagram often).  The performance is specified at a later stage, but it is necessary to specify every function and feature the product is expected to have. The principle of the Product Specification is best illustrated by example. Let’s imagine that the product is a wearable device that measures ECG (heart beat waveform). The following elements might be present in the Product Specification (note this is not rigorous – just example):
  • Overall description: a watch like device that measures and displays ECG on the front face of itself.
  • Screen that displays the ECG in question.
  • Strap that allows attachment to user’s wrist.
  • Transducer that measures electrical signals associated with the heart.
  • Electronics that receives transducer signals and processes them for display.
  • Energy source – likely a battery.
  • Firmware that displays results and controls function of the device.
  • Enclosure to hold above.
  • Whatever other elements may be required.
• Performance Specification: Having specified what must be in the design, it is necessary to establish all the performance measures that must be applied to each feature and function so that how the goal is to be achieved and to what level of importance is fully defined. The meaning of this is best illustrated by extending the contents of the Product Specification to cover the Performance Specification as below, noting that this is only illustrative and very far from prescriptive. The details below show how difficult this is – note that dry and sweaty skin must be covered – not done here but mentioned to illustrate how challenging this level of specification is:
  •  Screen: touch TFT; size less than one inch diagonal measurement; weight less than 25g; light power density at 1 metre (perpendicular) 1.93mW/cm2; monocolour – green; etc.
  • 2 strap types required (one 1/4 inch wide, other 1/2 inch wide); colour black; tensile strength of material > 50N/m2; immersible in water; fixing system such that signal transducers never lose contact with skin (not specific enough – needs more) etc.
  • Skin contact transducer (2 terminal) that measures electrical activity in the skin – signal > 2mV; operation between 70% and 95% humidity, etc.
  • Electronics that:
    •  has embedded to controller with firmware (memory, speed and other features must be specified)
    • filters 50Hz mains noise and at least its third harmonic (the level of filtering attenuation must be specified)
    •  Amplification and signal conditioning the signals from the transducer (hopelessly underspecified here but electronics engineers will know how much more is really required). 
    • Less than 50g in weight
    • Size meets dimensions and profile requirements (product designers would need to provide soft copy engineering files for this)
    • Max running current < 2mA; sleep current < 1 microamp.
    • Many other requirements
  •  Battery to last lifetime of product (what lifetime means in terms of duration and and use must be defined); supply max current; having dimensions and outline defined in mechanical drawings from product designer; safety electronics to shutdown is battery exceeds 55C; etc.
  • Firmware that carries out all functions defined in wireframes and specification UseCase and/or state diagrams – these documents are specialist and not presented here, but software/firmware must be fully described. There would be many more elements in this section.
  • Enclosure having fit, form and function as specified by the mechanical product designer’s specification – this explanatory guide can’t cover the detail that’s necessary for this section, but it is very significant. The aesthetic design is covered by it, any requirements for use in hazardous/challenging environments, etc.
  • Other requirements like compliance with international standards, generic requirements like drop testing – submersion in water, etc.
• Manufacturing Specification: If it is intended to produce the development in volume, it is critical that both manufacture and post shipment service receive attention. Typical elements that will require attention are:
  • Breakdown of design into testable subassemblies so that the consequences of inevitable production failures are reduced – catch failure early.
  • Capacity planning.
  • Quality planning.
  • Process planning.
  • Service requirements.
  • And more
• Feasibility Specification: There is a very simple test to confirm whether or not feasibility studies and test are required. Go through every clause in every specification above and answer the following questions (if the answer is no to either – feasibility is required). If feasibility work is required, it isn’t possible to do it on a fixed cost and delivery basis because its nature is by definition variable. This doesn’t mean it should be aimless – the desired outcome should be defined in writing and all work and tests geared towards it – and budget limits set.
  •  Can I define pass/fail criteria for each clause.
  • Can I define a test that will allow me to confirm results.
• Engineering Specification: If all the other specifications have been thoroughly executed, and Engineering Specification may be written. This specification will be such that it could be given to an engineer and it would be possible for him/her to design and develop the product without any other specification, or even knowledge of what the product does. If specification is at this level fixed budget and reasonably fixed delivery are feasible – if not delivery to time and budget cannot be guaranteed. 

How can I prescriptively define the requirements to ensure compliance?

How can the EM assure me that my development expectations are going to be met?

Yes! The ultimate benefit will be had if you work through the Business, Product, Performance, Feasibility and Manufacturing Specifications yourself and generate a prescriptive Engineering Specification. Even if that ES has to be reviewed and modified a very significant saving in time and money will result. That said, it involves a great deal of work – it will not be quick.

The EM would be delighted to give you further guidance if you need it – please click CONTACT US and we’ll take it from there.