Electronics Design: Requirements Capture

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.

 

User Requirements

User Requirements

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.

 

Technical Requirements

Technical Requirements

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:

 

 

Does this work

Does this work?

 

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.

Visualisation: Part 4

Viewpoints matter

How does the world look to you?

 

This is often one of the areas where Engineers and Customers can get out of step. And in particular, is a big issue for Software Development and IT systems. Check out the image below.

 

Round or Square Columns

Round or Square Columns

Technical professionals such as Engineers and Software Developers tend to be detail driven and so probably look at the system from the ground up. So we would see round columns.

 

Entrepreneurs and Business Owners tend to see the world from the top down and so would see square columns. And this difference in perspective can be a problem in implementing a solution that works for the customer.

 

So here we have an image that represents the potential difference between the Engineer Viewpoint and Customer Viewpoint.

 

Requirements Management

The real issue here is Requirements Management. This is one aspect of Software Development where I like the V Model for Software Development and the European Space Agency Software Engineering process. It splits the problem down into steps and also lets you know whose language the documents at the step are written in. So User Requirements are written in the language of the user. Technical Requirements are written in the language of the technical professionals. And Requirements Analysis is required to determine the relationship between the different viewpoints. For most projects the analysis is used to translate User Requirements to Technical Requirements. So now we can all have a viewpoint that we understand and it is linked.

 

The V Model for Software Development

V Model

The general steps are:

 

  • User Requirements – in the language of the user
  • Product Requirements – in the language of the user and relevant standards and market needs
  • Technical Requirements – derived from both the above and in the language of the technician
  • Functional Decomposition – breaking the problem down into specific functions to be performed
  • Architectural Decomposition and Requirements Allocation – working out that is done in hardware, software, locally, remotely …
  • Detailed Design and Module Specifications – specific modules to be designed and tested

 

So we move from user language to technical language in a structured way that allows us to understand was is required and make sure nothing has been missed.

 

User Requirements and Technical Requirements

Requirements Analysis

Product Development Process

The Product Development Process is intended to ensure that the product meets its requirements and is delivered on time and on budget. And regardless of the size of the project the above steps are required. Who does them and how they are done is less important than that they are done. Smaller projects might not require a formal approach but any significant project certainly does. And this also helps to overcome the difference in viewpoint between Technical Professionals and their Customers.

 

The image for today’s blog post was provided courtesy of Dr Marc Dussault, The Exponential Growth Strategist who is always on the look out for examples of antimimeticisomorphism, which I am sure you’ll agree this is!

 

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