Introduction to Product Requirements Documentation for New Hardware Products

What does a practical, hands-on product developer or maker dislike the most? In my experience, I would say spending time writing documentation instead of designing interesting stuff.

Article Technical Rating: 6 out of 10

This is a guest post by Roberto Weiser of Developpa.io.

Usually, when a product developer has a clear understanding about the function of the device, he/she jumps straight into the design.

This is great, as there’s nothing better than having an early proof of concept prototype to show stakeholders you can make it.

Get your FREE Ultimate Guide - How to Develop and Prototype a New Electronic Hardware Product in 2024

However, after the proof of concept stage issues can arise if the engineer starts picking components and designing the schematics without first having formalized the functions, behavior, operating parameters and the expected performance of the device.

Always focus on the big picture before you dig down into all of the little details.

What is a product requirement?

A product requirement is simply the definition of what your device is intended to do. It is the formal description and agreement of the expected functionality of the product, and an indication of its true performance in the field.

Imagine you have to describe your electronic product idea in one sentence, as best as you can, using a mix of technical and colloquial terms. Let’s say for example, that a friend who knows a bit about engineering asks you:

“What’s that idea you had the other day?”

“I love to grow my own chilies. However, I travel a lot so I can’t always water them as much as I should, or take care of them when I’m away. It struck me last night, that I could somehow build a device that would automatically water and care for the plants…”

“So how do you do plan on doing that?”

“I’ll build a box that monitors key parameters such as soil moisture, light and temperature. This then switches on a light, or waters the plants depending on what the plant needs. By connecting this device to the internet I’ll be able to monitor these parameters while I’m away.”

From this simple description of the product you can already extract a few functional requirements such as the ability to sense soil moisture, ambient light and temperature.

You can also see that there is an explanation of what it is required to achieve the core function of the device rather than how to implement this function. This is true for all requirement definitions (there are exceptions of course).

In a nutshell: Requirements are structured statements that describe what a product should do, not how it does it.

Why are requirements useful?

Requirements are not just bureaucratic pieces of paperwork that a company uses to ensure its design team has fulfilled all of their obligations.

Product requirements are a very useful and necessary work product for the design engineer and project manager alike, and they can save you money and months of extra work.

Find out what you need in technical terms

By properly categorizing and defining the functions, properties, attributes and constraints of your electronic product, you can get a clearer overview of what you actually need to design.

Also, it allows you to separate the product functionalities so they can be researched and achieved on their own.

Team agreement and understanding of the product

Having a requirements document where all the functions, properties, attributes and constraints are defined is very useful in a project where more than one person is working.

It allows everyone to be on the same page and have a clear definition of what they are developing.

In my last job, when someone new joined the project, the first thing we would toss to him/her, would be a printout of the requirements documents and a system-level block diagram.

Project progress tracking

This one is for project managers or team leaders. A structured breakdown of the device’s functionalities and technical needs can be used to setup tasks for a team, or to track the project using a tool such as a Gantt chart.

It can also function as a delivery milestone to indicate that the project has been completed, once all of the product requirements have been successfully achieved.

Expenditure justification

Is one of the requirements of the product related to a technology that has never been used, or is not within the field of knowledge of the development team?

This situation will require the company to hire external talent and therefore increase the expenditure of the project.

For example, in my last job we designed a battery management system for an electric car. The project had strict safety requirements with the battery.

Because our company did not specialize in battery chemistry and technology, we had to hire an external consultant to help assess safety risks.

Get your FREE Ultimate Guide - How to Develop and Prototype a New Electronic Hardware Product in 2024

Problems down the line

This is probably the most useful aspect of requirements. More than one project has run over budget or been delayed because requirements were not met. Consider the following example:

Suppose that you are building an electric car (ambitious project, right?), and you have to design a battery management system that senses current, so you can determine the state of charge of the battery (by counting coulombs).

Say you design your current measurement circuit without performing a worst-case analysis, and you assume the accuracy of the measurement is sufficient since you selected an IC advertised as being accurate.

Later, you find out that the number of hours the vehicle can last without charging is less than expected. You may guess that the battery wasn’t sized properly, or the motor was not as efficient as promised.

But, you may not think to check the accuracy of the current measurement circuit. After all, you were just asked to design it and no one specified the required level of accuracy needed for these measurements.

In this example, accuracy, or rather inaccuracy, is the root of the problem. Because the required accuracy wasn’t specified from the beginning, the circuit designer didn’t take it into account.

Requirements gathering

Requirements can be created and drafted through elicitation and elaboration.

If you are working for an established company with a large client that submits a proper requirements document, then most of the requirements will be gathered through elicitation. This means the client will directly tell you what they need and want for the device.

Some elicited requirements are gathered directly from constraints such as regulations.

For example, the EU is making an effort to make electronics sustainable, so they have created the Removal of Hazardous Substance (RoHS) directive where they specify that electronics components should have less toxic materials such as lead and cadmium.

Therefore, if you want to sell your electronic product in the EU, a requirement is that all components must be RoHS compliant.

On the other hand, if you are developing your own product, working for a startup, or your client has no expertise in a certain subject, the requirements must be elaborated. Elaboration involves analysis in the form of decomposition and derivation.

Decomposition entails breaking a higher level requirement into lower level requirements.

For example, in a recent solar mobile charger and powerbank project, one of the requirements was to have a battery (obviously, as it is a powerbank). However, the technical specifications for this battery were not given.

Because of this situation, this requirement was elaborated through decomposition. The main parameters of a portable battery were researched, which included battery technology and size.

Using market analysis and considering other requirements, the following decisions were made:

Battery technology: it is clear that Lithium Polymer is the preferred battery technology. After doing some research, capacity wise, Li-Ion is better as it has a higher power density, however, they are more likely to explode.

In this case, a design decision must be made. What’s more important: more battery capacity or user safety? Definitely the safety of the user.

Battery size: some of the products researched are real power banks, packing up to 24Ah. Another requirement is that the powerbank can be charged using a small solar panel.

Having such a big battery will make this goal really hard to implement. Therefore a 4Ah battery was chosen as it is the lowest capacity battery available in commercial mobile powerbanks.

Elaboration by derivation requires the engineers to draw some inference. In other words, the client did not state the function directly, but the derived function is a necessary part of the system design.

Using our previous example, an elaborated requirement through derivation will be the addition of a connector, to attach the battery to the board.

To elicit and elaborate requirements there are a number of techniques available:

Brainstorming sessions

Useful at the very early stages when there is nothing concrete. Sit, preferably with some experts, and discuss the main functions of the product, taking into account the environment where it will be used and where it will be sold.

Use case and operational scenarios

Using similar products or just mental exercises, create use cases for your product to find out the functionalities and properties that it’s required to have.

Simulation and prototypes

Creating a proof of concept prototype or simulating a circuit can shed light on technical specifications that the product is required to have. This is useful for properties that are not easily seen or deduced by pure conceptual analysis.

Market analysis

Research current market trends and find what’s out there. This will give you feedback in two ways.

First, it will allow you to set your requirements so that your product is better than the competition.

Secondly, it will allow you to learn and detect the technical limitations with the technology that might exist.

If you research a successful product from an established company, they have already spent a good amount of time and energy determining the best requirements for their product, taking into account functionality, available technology and manufacturing costs.

Reverse engineering

You can always acquire a similar product and take it apart to see how it was built. Then, adapt your own requirements accordingly.

Types of requirements

Requirements can be categorized in many different ways, however, there are two main types:

Functional requirements: something that the system should do or provide.

Non-functional requirements: this refers to some property, quality or attribute that the product must possess i.e. a condition the system must meet, or a constraint under which it must operate.

For example, the solar mobile charger and powerbank has the functional requirement of measuring the battery temperature, and the non-functional requirement of being able to operate at a temperature range of 0 to 40 degrees Celsius.

Requirements you will need

Requirements must follow some rules and structure in order to be useful and fulfill their function. They must adhere to the following:

Unique

A requirement is its own entity, it cannot be a combination of two or more requirements.

Unambiguous

All readers of the requirement should come to the same understanding of what the requirement is saying; therefore, there can be only one interpretation.

Normally, a contractor and client will define all requirements to make sure there’s no confusion that could cause problems in later stages.

Verifiable

A requirement is only as good as the procedure validating it. Validation and verification are an intrinsic part of the requirement.

If a requirement cannot be properly verified, then how will the engineer be certain that they have achieved the requirement?

Normally you would have an internal validation, where test engineers perform measurements to check that the hardware is functional and matches its design specifications and requirements.

This is followed by the design validation, where the product is tested more rigorously with its enclosure and at different temperatures and humidity. This verification stage also includes EMC testing.

Finally, the product will be tested on the field with real operating conditions or by incorporating it into a bigger system, or allowing it to interact with other devices.

Attributes

Requirements should be given attributes to support the previously mentioned requirements.

Title: A descriptive title of the requirement

ID: A unique identification that cannot be duplicated

Safety related: In some products where safety is important, classifying the requirement as safety relevant is good practice.

Priority: In some cases, it won’t be possible to achieve all requirements as they will conflict with each other. Assigning priorities gives the designer information to choose the most relevant requirement.

Source: This refers to the origin of the requirement, be it client, contractor, or external.

Rationale/Purpose: A short description of the requirement and why it exists.

Verification method: How is this requirement going to be verified? Testing, inspection, analysis?

Tracking info: The requirement must be traceable.

The following table is an example of how the attributes are applied to a requirement for passive components:

Attribute	Value
ID	261
Priority	High
Safety related	No
Source	Contractor
Purpose	Define the size of components
Verification method	Inspection
Note: All components selected must be of the smallest footprint possible in order to minimize the PCB dimensions. Surface-Mount Technology (SMT) components should be given priority over Through-Hole Technology (THT) components with allowed exceptions. The minimum SMT size should not be smaller than 0603 for ease of manufacturing, testing, and debug.

Managing requirements

It is often the case that more than 50% of a product requirement is modified before it is completed. A new technology may abruptly appear which needs to be incorporated, or a new regulation may force you to change a component.

Requirement changes need to be addressed and managed by the requirements engineer, systems engineer or project manager. Engineers need tools or software for assistance.

Get your FREE Ultimate Guide - How to Develop and Prototype a New Electronic Hardware Product in 2024

A requirement tool can automate and keep records of traceability and changes in history, as well as supporting the attachment of requirements validation results to name just a few functions.

It is also important to manage emerging requirements. These are requirements that only appear when the system is put together and could not be foreseen.

They must be allocated in the context of other requirements, in order to avoid “orphan requirements”.

One of the most popular requirements management tools used in industry is IBM Rational DOORS.

Requirements document for an electronic product

There is no single formula of a requirements document for an electronic product. Each device has its own specifications and particularities. To start with, most electronic products can follow these requirements categories:

Product Description: general high-level description of the product, it is best when accompanied by a system-level block diagram.

Design Requirements: what the product needs to have or be in terms of components and high level design.

Functional Requirements: functions the product is intended to do.

Environmental and functional environment requirements: related to its impact on the environment and where it performs its functions.

Mechanical requirements: enclosure related requirements.

Service life requirements: operating time and operating temperature.

Testing requirements: associated tests that the product needs to pass.

Conclusion

In this article, we have seen that product requirements are not a trivial task, and they cannot be avoided.

Requirements represent the backbone of any product by giving the engineer a set of design goals to achieve, and management a way to assess cost and project timings.

Requirements also need to be properly managed using a tool, particularly if the project is big and many people are working on it.

Also, it is worth saying that you shouldn’t dwell in the requirements stage forever. It is important to be clear about the device’s functions but don’t make the mistake of creating excessive paper work and forgetting about the actual development!

About the author

Roberto Weiser is an electronics design engineer with experience in audio electronics and battery systems for the electric vehicle. He currently works as a freelance engineer and is the founder and lead content writer at Developpa.io which focuses on electronics product development, sustainable design, and creating devices for the good of humanity.