One reason that caused the longest delays in the launch of embedded products in our experience has been unclear and changing requirements. When the requirements were poorly defined, we often had to rewrite the code, redesign the circuit and PCB, and even redefine the architecture. This made the development inefficient, caused a lot of wasted hours, and increased the customer’s time to market.
What we at Oxeltech learned was to be assertive with the customers and work hard on clarifying their project requirements first. This often meant that they had to look into their product market fit and make courageous decisions about core features. But once that is done, the project plan and time to market become more predictable.
Beyond poor requirements, there are other factors that slow down product development. More on that you can read in our other blog.
How Do You Define “Requirement”?
A simplified definition of a requirement can be:
“A capability or condition needed to solve a problem.”
There are two aspects to this definition.
- capability (feature) or condition that is clearly defined
- the problem, that feature solves
Both aspects should be clear to the development team in order for them to stay focused, minimize waste and bring your product to market fast.
A typical product has several such “requirements”, which together define the desired product.
Focus on “What” Not “How”
If the development team is clear on “What” problem their system will solve, they will find optimal ways of “How” to develop it. By focusing on outcomes, you can cut the unnecessary scope and iterations.
To be clear, the “Hows” (implementation details) are important and must be decided by the development team in detail. The development team ensures that “Hows” (implementation details) address efficiently “What” problem they are solving.
The problem is jumping to the “How” (the implementation details) before being clear on the “What” (the problem the customer is trying to solve).
Ensure that You Have Collected ALL the Requirements
Requirements should include ALL the desired features and constraints of the product so that the development team is sure about the technical goals and the project management team can estimate costs and schedule accurately. Unclear, missing, or infeasible requirements will always lead to delays and cost overruns.
When clarifying requirements, ensure that you discuss the following types of requirements for embedded and electronic systems:
- Functional and performance requirements: Define the expected behavior of the system and an acceptable range of performance measures.
- Interface requirements: Define the interaction of the system with external hardware, software, and operator/user.
- Constraints for which no trade-off is allowed.
- Environmental requirements: Define the operating conditions.
- Safety requirements: Define which safety standards need to be followed.
- Certification requirements: Define which certifications the product needs to comply with (such as CE, UL, FCC, etc.).
These two practices will ensure that no requirements are missed
- Repeated discussions with stakeholders about functions, interfaces, constraints and use cases before finalizing requirements
- A survey of similar products in the market and looking at their specifications and reported problems to refine the requirements
How Do I Know if a Requirement is Well-Defined?
A well-defined requirement will have the following characteristics
- Necessary
- Unambiguous
- Complete
- Feasible
- Verifiable
- Consistent
1. Necessary
The requirement defines an essential capability or constraint.
| Example of a Bad Requirement | Example of a Good Requirement |
| Design a remote light control. The user should be able to turn home appliances on or off and adjust settings like brightness and speed depending upon the appliance controlled.
Remark: If the goal is to develop a remote light control, the requirement includes non-essential capabilities that are beyond the scope of the project, which focuses only on controlling living room lights. It introduces complexity by including control over all appliances and various settings.
|
The home automation device shall allow users to control the living room lights remotely using the mobile application. The user should be able to turn the lights on or off and adjust the brightness from 0% to 100%.
|
2. Unambiguous
The statements are clear and can only be interpreted in one way.
| Example of a Bad Requirement | Example of a Good Requirement |
| The home automation device shall allow users to control the lighting from their mobile devices and adjust the settings as needed.
Remark: The term “control the lighting” and “adjust the settings” are vague and can be interpreted in multiple ways. It’s unclear what specific controls are available (e.g., on/off, brightness adjustment), and “as needed” lacks precise meaning, leading to potential misinterpretations. |
The home automation device shall allow users to control the living room lights remotely using the mobile application. The user should be able to turn the lights on or off and adjust the brightness from 0% to 100%.
|
3. Complete
The requirement fully describes the capability, including interaction details, response time, and feedback.
| Example of a Bad Requirement | Example of a Good Requirement |
| The home automation device shall allow users to control the living room lights remotely using the mobile application.
Remark: This requirement is incomplete because it does not specify the extent of control (e.g., on/off, brightness adjustment), how the control should be implemented in the application, the response time, or feedback to the user. It lacks the necessary details to fully understand the capability.
|
The home automation device shall allow users to control the living room lights remotely using the mobile application. The user should be able to turn the lights on or off and adjust the brightness from 0% to 100%.
|
4. Feasible:
The requirement considers technical constraints (Wi-Fi connection, mobile app compatibility) and is achievable.
| Example of a Bad Requirement | Example of a Good Requirement |
| The home automation device shall allow users to control the living room lights remotely using the mobile application. The user should be able to
Remark: It is not feasible to support all the languages in the world so that user can freely choose any language. A clear and feasible number of languages must be provided. |
The home automation device shall allow users to control the living room lights remotely using the mobile application. The user should be able to
|
5. Verifiable
The criteria for success are clear, and the acceptance tests are well-defined to ensure the requirement can be verified.
| Example of a Bad Requirement | Example of a Good Requirement |
| The home automation device shall allow users to control the living room lights remotely using the mobile application, making the lighting experience pleasant and user-friendly.
|
The home automation device shall allow users to control the living room lights remotely using the mobile application. The user should be able to turn the lights on or off and adjust the brightness from 0% to 100%.
Verifiable: This requirement is structured and worded such that its realization can be proven. The criteria and acceptance tests are specific, measurable, and testable, allowing verification that the requirement has been met.
|
6. Consistent:
The requirement is unique and does not conflict with other requirements.
| Example of a Bad Requirement | Example of a Good Requirement |
The home automation device shall allow users to control the living room lights remotely using the mobile application. The user should be able to:
Remark: This requirement conflicts with the fundamental functionality of remote control, which requires network connectivity to function.
|
The home automation device shall allow users to control the living room lights remotely using the mobile application. The user should be able to
|
By ensuring that the requirements are well-defined, clear, and feasible, development teams can work efficiently to meet project goals, reducing the risk of delays and rework.
If you’re interested in a detailed study of good practices of requirement writing for embedded and electronic systems, you can go through “INCOSE – Guide for Writing Requirements”
Summary
Defining product requirements clearly at the start of the project helps reduce wasted effort and time in development. This requires a clear understanding at the beginning of the project, which core problems the product aims to solve. Change requests cannot be fully eliminated, but should be minimized if delays and cost-overruns are to be avoided. This is even more relevant for embedded and electronic development because of the considerable production costs and manufacturing time needed for each hardware iteration.
