Requirements Capture

Product Development is the core process your use when you have a great idea for a new product, or an improved version of an existing one. The very first step is to define what it is meant to do.

 

This first step is known as Requirements Capture. And requirements break down into two categories:

 

• User Requirements
• Engineering Requirements or Technical Requirements

 

These are related to each other and it is often useful to look at them in the right sequence. I’ll explain why later. Let’s look at what each involves.

 

User Requirements

This is a description of the product from the perspective of the user. It is written in the language of the user and describes what the product does and how it is used by the user.

 

We work with both technical and non-technical clients and the one thing they both have in common is that they can both write a document like this. It is also important that the focus begins with the user. Otherwise we can get carried away with the technical side of things and forget a real human being is going to have to use it one day. Concepts like Intuitive can have very different meaning to Engineers and the general public. So it is important to start with the user’s perspective.

 

Technical Requirements

This is what you end up with when you analyse the User Requirements through the lens of technology. We are translating from the user perspective to the technical perspective or engineering perspective.

 

As an example, the User Requirement might be that it complies with the relevant standards. This will translate to it passing C-Tick requirements for sale of product in Australia as part of the Technical Requirements.

 

Another example is that the User Requirement is that it must run off a pair of AA Batteries for six months. This then translates into a Technical Requirement that its average current consumption must be less than 0.57mA. If you are wondering how I came up with that then the maths goes like this:

 

An AA alkaline battery = 2500mAh so the average current consumption has to be 2500mAHr / (24 hours * 365.25 days per year / 2) = 0.57mA.

 

That is the sort of analysis that is done every day by Engineers every day.

 

Requirements Analysis

The reason that it is important to look at User Requirements first is that we technical professionals love technology. And we love all the answers to the How questions. If we don’t focus on the What questions we can end up with a beautiful piece of technology that no-one actually has a use for.

 

User Requirements = What

 

Technical Requirements = How

 

So there is quite a difference in how Engineers think compared to the rest of the world. For some other examples you might like to also look at these posts:

 

• Requirements Management (Visualisation)
• Software Estimation
• Software Documentation
• Engineers Think Like (Visualisation)

 

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2014 Successful Endeavours Pty Ltd.