Tag Archives: Requirements Capture

Creating Product Specifications

Posted on by
Reply

Requirements Capture versus Product Specification

In our post on Requirements Capture I looked at how we can go about understanding what a product has to do, who it has to do it for, and how to assess that. The output of this process is often referred to as a Product Specification or more specifically a Product Technical Specification.

 

One way to think of this is that Requirements Capture is a pull process, where as Product Specification is often a push process.

 

I was amused to read Jama Software’s blog on this topic where they show a number of ways to go about writing the Product Specification. My favourite was their description of letting the development team write the specification.

 

Developers Write the Specifcation

Developers Write the Specification

We see a lot of this with web development where the web developers want to try a particular tool or technique so they use it for your project whether that is good for you or not. Below is a summary  of the other options and some common pitfalls.

 

Customer Supplied Specifications

If the customer is writing from a marketing perspective or a specific opportunity then you can end up with a very useful Product Specification. But if it purely a sales driven process then you often end up with the following combination:

 

  • superset of the features of all other products on the market
  • at a price 10% below the cheapest product on the market

 

This generally leads to a project doomed to fail or at the very least puts the product in a price war with a race to the bottom of the market. At the very least, it can put a straight jacket on the product and significantly reduce the likelihood of commercial success.

 

A marketing driven process will determine where in the market a product can be and at what price, for who and a clear strategy for competing with the other offerings.

 

Ask the customer

As Steve Jobs famously said, “don’t ask them, they don’t know”.  This isn’t always true, but the client often doesn’t know what is possible and part of the role of Product Developers is to give good guidance on Technology Selection to give the product an edge in the market.

 

Otherwise, you just deliver what they asked for without caring about their success. I often think this is one thing we offer. We care about the client’s success.

 

Analyse across all constraints

This is the process we try and use.  And it is well captured in this image from Jama Software.

 

Product Specification

Product Specification

 

To be successful, a product should:

 

  • be possible and affordable with available technology you can actually buy or deploy
  • solve a well defined problem in an acceptable manner
  • fit within the constraints of either the manufacturing capability, logistics capability or market channels available

 

The last point is often overlooked. I was recently asked why we couldn’t design a product that cost $20 to make, have the range of a mobile phone, be manufactured in quantities of 100 of on demand, a development budget of under $20,000 and be able to be deployed with no infrastructure costs. This is an example of a wish list that can’t be realised as it is currently expressed. However, when we looked at it from a different perspective, we were able to come up with a solution. The questions we asked were:

 

  • why do they want it?
  • who do they wanted it for?
  • what problem is it meant to solve?
  • what is solving that problem worth to the end user / buyer?
  • what is the manufactured volume versus unit price trade-off?
  • what can it really cost to develop and manufacture and still be profitable?

 

And suddenly the impossible can become possible. In this case they knew their market well. It was just an example of the customer starting with a specification rather than using the resources around them to get to a specification that could lead to commercial success.

 

And ultimately, that is where a Product Specification is meant to lead to: commercial success.

 

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 © 2015 Successful Endeavours Pty Ltd.

Electronics Design: Requirements Capture

Posted on by
Reply

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.