Requirements Review

One of the most disheartening experiences as a design engineer is to work long and hard developing a gadget only to find out at the end that it does not do what the client wanted or what the end customer needs. How does this happen? In our experience, it stems from an unholy rush to start designing something without first taking the time to carefully consider what the product must do to satisfy the customer’s needs.

So how do you find out what the requirements for a product are? Often our client has a very good understanding of the needs and wants of the end customer, but this is often poorly documented, or stored only in the minds of a few key personnel. Sometimes, even they do not know, and it is imperative to commence the project with some well designed market research and customer surveys. The requirements for a product should be listed in a Product Specification.

Drafting a good Product Specification is without a doubt the toughest and most important part of the product development process. The challenge is to concisely and precisely list all of the things that the product must do. Common section headings in specifications are; Environment – the conditions the product must work in, Function – what it must do, Performance – how well it must do it, Durability – the life requirements, and User Interface – how it must interact with the user. It is vital to avoid prescriptive specifications that may limit the options at the next stage – Concept Generation. For instance, rather than saying “the trap shall incorporate a U shaped element constructed of steel wire which shall impact the neck of the mouse with impact energy of no less than 2 joules”, it is much more effective to say “1. The trap shall apply an impact loading to the neck of the mouse, 2. The impact load shall be adequate to cause immediate fracture of the spinal column”.The first approach pre-empts the design solution and may not produce the desired outcome which is, you guessed it, to build a better mousetrap. The second just lists what it is we want to achieve, and gives the designer flexibility in terms of how to achieve it. Note that even the second approach is prescriptive, as it dictates that the mouse must be killed by fracturing the spinal column. This may be because the animal welfarists dictate this method, otherwise a better approach may be to specify; “1. The trap shall cause the death of a mouse entering it. 2. Death shall occur in a humane manner” (maybe even refer to a generic standard here that specifies humane ways of killing things). Subsequent clauses may go on to specify that you don’t want blood splattered all over the walls, can’t involve the release of poison gases that cause all humans in the area to die also, etc.

When a detailed Product Specification has been drafted, it is imperative that the client signs off on it, to ensure that everyone is in agreement that it accurately and fully describes the product they desire. Keep in mind that the specification can be amended as new requirements come to mind during the design process. This is quite common, particularly for products requiring a significant amount of research and development (R&D) during the design process. Keep in mind also that it is likely that you (or the client more specifically) will want to test prototypes and the final product against these requirements, so it helps to structure the requirements in such a way that standard or simple tests can be employed wherever possible.

Also be warned; watch your words. Saying “the trap shall not corrode or otherwise be degraded after 100 hours of salt spray testing” means that avoidance of corrosion in these circumstances is mandatory, whereas replacing “shall” with “should” means that it is your preference for corrosion to be avoided in these circumstances but it is not essential. The alternative “it is desirable that the trap not corrode or otherwise be degraded after 100 hours of salt spray testing” means nothing more than this would be a nice bonus if it were to happen.

Next page.