A Requirements Traceability Matrix (RTM) is considered a basic concept to keep software development on track.
However, not many people know that this tool can be used just as effectively in electronic product design.
Table of Contents
HOW TO CREATE RTM FOR ELECTRONIC PRODUCT DESIGN?
| Wonder what an RTM for Electronic Product Design looks like? |
| Requirement Traceability Matrix Excel |
| Note: Make sure you read the tab “instructions” first. |
A Requirements Traceability Matrix (rtm) is generally an excel table, in which every specification of a product is defined as a testable requirement. This allows you to create reliable high-quality electronic products.
In manufacturing, RTM can also stand for ‘Release to Manufacturing’, they are closely linked though!
Download our Requirement traceability matrix excel for a clear example of an RTM used for electronic product design.
WHY USE AN RTM?
Requirements Traceability Matrix (RTM) Assures Quality of Your Electronic Product
RTM brings many benefits, most of which are directly linked to Quality Assurance (QA), which comes as no surprise as RTM is often considered the embodiment of QA.
To some RTM development, and QA may sound like a tedious job that hopefully someone else will do at the end of the process. It is, however, the very opposite. QA is something you must set up at the very beginning to realize your dream product as fast as possible, in a robust way.
Requirements Matrix is the ideal tool to do this because it organizes and keeps track of all key specifications during the creation of an electronic product:
- Translate each business requirement into a functional requirement
- Know exactly what the product needs to do
- Know what the Team needs to do to achieve this
- Track each requirement to see if it has been met & adequately tested
Nobody wants a Samsung Note 7 style recall. By using an RTM everyone can sleep soundly, knowing that only quality products will be shipped which will delight their users.
Requirements traceability matrix (RTM) shows you how to approach the feature and how you’ve gotten where you are
An RTM provides forward traceability, which ensures completeness of the product by making sure all test cases are performed, all requirements are met and no functionality or feature is missed.
On top of forwarding traceability, a Requirements Traceability Matrix (RTM) also provides backward traceability! This means you can compare potential new uses for the product to the original requirements, to make 100% sure the product is up to this new task.
An RTM also effectively keeps track of design decisions, so that lessons learned in one product can be used in other products as well.
And finally, an RTM is also THE way for a new team member to get familiar with a product in the design stage.
You ask them to perform QA for it. This will allow them to learn about every little detail in regards to the components, functionality, user interface, certifications, etc. of the product.
HOW TO CREATE RTM FOR ELECTRONIC PRODUCT DESIGN
Create Categories
We suggest you create different categories and subcategories according to the essence of your product.
Use these categories to sort all the features of the product which is about to be designed. Below are listed seven simple example categories used for electronic product design.
| Environmental | 1 | Protection against ingress of water and dust |
| Min. and max. temperature the devices have to work in |
E.g. The product shall be able to operate at an environmental temperature ranging from 0°C to 50°C.
| Handling | 2 | Drop Test |
| Vibration Test | ||
| Shipping | ||
| Installation | ||
| Hits & Scratches |
E.g. The product shall be able to withstand a drop from a height of 50 cm without taking any damage.
| Electrical Interface | 3 | Input Power |
| Ports | ||
| Signal Levels | ||
| Components & Location |
E.g. The product shall have a 3V low power battery.
| Performance | 4 | Noise |
| Latency | ||
| Range | ||
| Battery consumption | ||
| Heat | ||
| Power output | ||
| Error rate | ||
| Durability |
E.g. The color of the product’s outer shell shall not fade within 1,000 hours of UV exposure.
| Functionality | 5 | Power |
| Set up | ||
| Operation | ||
| Interface | ||
| Protocols |
E.g. The product’s green LED shall blink twice after a successful transaction has taken place.
| Physical | 6 | Dimensional |
| Appearance | ||
| Parts & Location | ||
| Labeling |
E.g. The thickness of the product shall be no more than 20mm.
| Regulatory | 7 | Certifications |
E.g. The product shall be compliant with EN 301 489-1 V2.2.1 (2019-03) standard. (Radio equipment and services – Common technical requirements).
Then, using these categories, you split up all the requirements of the desired product.
Give every requirement a code to identify it and a priority level. Requirements with higher priority levels shall be fulfilled first. It is essential to have a column for comments and feedback since, QA is all about communication, exchanging ideas, asking questions, solving doubts, etc.
We recommend preserving this extra information as long as possible. It will become very valuable in the future as part of the lessons learned during past experiences.
Writing Requirements
The first rule of an RTM is that a requirement is only a requirement if it can be tested.
Just this rule in itself will save your team a lot of discussion and needless iterations.
Second, you must realize that requirements are split into two distinct groups:
- Statements regarding what the product shall have
- Statements regarding what the product shall be capable of doing
Both these statements are required to achieve the functionality the product was designed for.
To write a good requirement, keep in mind what the eventual functionality is and whether the product is capable of achieving that in different scenarios.
For example, what will happen when the user presses a specific button? How will the user interface work? What certification tests will it need to pass?
Then, when you have a good idea of possible requirements, you write them all down using the list of good practices to follow below.
Good practices for creating requirements are:
Use SHALL for mandatory statements, WILL for declarations of purpose which are non-mandatory, SHOULD for preferences or desired goals and MAY for suggestions or allowances.
A requirement should state ‘what’ is needed, not ‘how’ it is done.
❌ The firmware of the product shall have a timer and every 10 seconds it will activate a LED for 0.3 seconds.
✔️ The product’s LED shall blink every 10 seconds.
Each requirement must be verifiable.
❌ The product’s width shall be enough for a hand to fit in.
✔️ The product’s width shall be 10 cm.
A requirement should define the performance of the product, not the actions of the user.
❌ The user shall press the button to start the game.
✔️ The game shall start 1 second after the user presses the button.
Avoid using passive voice.
❌ The product shall be wrapped in foam for shipping. (By who?)
✔️ The product shall be inside a bag of foam for shipping.
Avoid Vague and General Terms
They result in requirements that are often difficult or even impossible to verify or allow for multiple interpretations. Things to avoid are:
Superlatives
❌ The product shall be the cheapest NRF reader on the market.
Subjective language (Ex. User-friendly, easy to use, cost-effective).
❌ The product shall have colors liked by kids.
Vague pronouns (Ex: it, that, this)
❌ This LED shall blink twice after the game starts.
✔️ The red LED shall blink twice to notify the user that the game started.
Ambiguous adverbs and adjectives (Ex: almost always, significant, minimal)
❌ The product shall have a significant battery life.
✔️ The product’s battery shall last 1000 hours.
Comparative phrases (Ex: better than, higher quality)
❌ This product version shall be better than the previous one.
Loopholes (Ex: if possible, as appropriate, as applicable)
❌ If possible, the product shall turn off after 30 minutes of no user interaction.
✔️ The product should turn off after 30 minutes of non-user interaction.
Negative statements
❌ The red LED shall not blink when the game is over.
✔️ The red LED shall be prevented from blinking when the game is over.
For more details, visit chapter 5 of 29148-2011 IEEE Requirements Engineering for Systems and Software.
RTM DEVELOPMENT
Build your Requirement Traceability Matrix RTM as soon as possible, preferably right at the start of the design of a new electronic product.
One of the main reasons to build an RTM this early is to have traceability of the decisions made in the process of designing the product.
When do these first decisions take place? As soon as you and your team start to write down the initial specifications.
Maybe later in the process (once a working prototype has been created), there will be a moment to consolidate it using doubts and concerns generated in the process of building the first Proof of Concept.
However, the earlier you start building an RTM, the more depth your documentation will have and the better you can keep track of your design process history. This is especially important for medical products.
IS IT WORTH THE TIME TO DEVELOP AN RTM?
The short answer is yes! If you’re serious about bringing a product to market it is very much worth investing time into building an RTM, as it will most definitely save you time during the creation of the product.
To illustrate how an RTM can improve your design process, have a look at the example below. In this exercise, team members are asked to draw a picture based only on oral instructions.
This ‘game’ will be played multiple times with the same team members, with the game being slightly changed as it is repeated.
The desired drawing
Game iteration 1: No questions can be asked. Instructions can’t be repeated.
Example of the instructions given:
- Instruction 1. Draw a circle at the bottom of the page.
- Instruction 2. Draw a rectangle on top of the circle…
The best result we have ever obtained is the drawing to the right.
As you can see, it’s not exactly what was desired.
Game iteration 2: Questions are now allowed and instructions can be repeated.
Example of the instructions given and questions asked:
- Instruction 1. Draw a circle at the bottom of the page.
- Question: Radius? How big?
As you can see in the new result to the right, allowing people to ask questions and share information really helps to get the drawing more similar to the desired result.
However, the result is still not 100% accurate. Now in response to the results, there are questions you should yourselves:
- Why is the drawing not identical to the initial one?
- Is everybody asking enough questions?
- Am I making sure everybody understands my instructions?
- Should I give more details?
REQUIREMENT RELATIONSHIP MATRIX FREQUENTLY ASKED QUESTIONS
As mentioned before, every requirement shall be verifiable.
Create a list of test scenarios to verify each of the requirements in your matrix. Every scenario must correspond to only one requirement. It should not try to validate multiple requirements at the same time.
Once the test scenarios are defined, test your device, mark every scenario as Accomplished, or Failed. Report the results and start working on getting the list 100% accomplished.
There is no better way to get better than practicing, repeating, and asking, making sure everything is as clear as possible. This is why, if you have any questions… contact us on LinkedIn!
Our expert QA team will be happy to solve all your doubts based on our experience.
