Introduction
Most, if not all, software projects have multiple sources of input: multiple customers having different or potentially even conflicting requirements, regulatory frameworks, and internal initiatives. While this can feel like chasing a moving target, clearly defining and freezing a set of requirements so development can move forward with confidence is essential. This is where requirements engineering activities become most valuable.
The key benefits of using applied requirements engineering are that it offers a variety of instruments, which can be applied regardless of the methodology or project phase. These instruments convert implicit information and problems to be solved into explicit, usable information. Finally, when applied effectively, a clear and well-defined set of both functional and non-functional requirements will be established. This clarity provides a solid foundation for impacted project members to build upon.
This blog article will first deep dive into the “four lenses” used in requirements engineering. Subsequently, the difference between solution space and problem space is discussed. In the end, some challenges are outlined, which a project may face and can be solved by the use of proper requirements engineering.
The Four Lenses of Requirements Engineering
One way to look at Requirements Engineering is through four lenses: Elicitation, Documentation, Validation, and Management. Each project blends these activities differently, depending on the industry, project maturity, available development time, and criticality (e.g. safety, security, compliance).
For each in-cabin monitoring feature developed by emotion3D, each lens [CPRE – Foundation Level – Handbook 1.2.0] and each related activity plays a key role:
- Elicitation activities are carried out to understand the stakeholders’ internal and external needs, ensure the requirements are agreed upon, and resolve conflicts related to requirements as soon as possible.
As an example, a requirements conflict is obtained for the feature “Distraction Detection” if Customer A wants “long distraction” to behave in a certain way and NCAP 2026 requires either a slightly different or more complex behavior. In this case, the conflict is resolved by reaching an agreement and selecting one of the two options, or by creating a new configuration (product variance).
- Documentation activities are about defining structures, that ensure the readability and comprehensibility of requirements for the roles and people who will use them, and providing evidence for various purposes (assessments, customer audits); it can include natural language, diagrams, or tables.
As an example, documentation can be established using a template over the structure of the requirements in natural language, or a template on the feature itself such that each functionality can be easily read, understood and analyzed.
- Validation activities refer to ensuring that the documented requirements meet the predetermined quality criteria, such as correctness and accuracy. They also focus on negotiating requirements and resolving requirement conflicts in order to reduce costs and risks at a later stage.
As an example,formal reviews are conducted with stakeholders involved, and issues are discussed and resolved collaboratively. Each reviewer contributes based on their role, influencing the requirement content or their attributes.
- Management activities ensure the lifecycle of a requirements product: from versioning, product variants, or dashboards to the even distribution of work among requirements engineers. Not to mention traceability and changes – all of this is an important part of requirements engineering.
As an example, periodic traceability reports are generated, which are sent to all the impacted project members, dashboards, which contain requirements decomposition tracking and status over how many are in work, in review or approved, are maintained.
Levels of Abstraction
One of the key tasks of requirements engineering is to clearly understand the high-level customer requirements and to translate it into information that is actionable for all stakeholders who work with the requirements. A useful mental model is the “problem space vs. solution space” model:
- Problem space is about uncovering what the customer really needs – and the context in which a specific need exists. The better the root causes behind their challenges are understood, the easier it becomes to define meaningful requirements.
E.g.: Definition of Drowsiness Detection in Problem space:
-
- The software shall support the detection of the driver when he/she becomes drowsy, to reduce accident risk.
-
- The drowsiness level shall be measured based on KSS (Karolinska Sleepiness Scale) levels.
-
- The drowsiness status shall be reported every 4 seconds.
- Solution space defines the area where features are created and refined to solve requirements’ high level problems. This is where engineering translates a high-level understanding into specific, testable, and implementable requirements.
E.g.: Definition of Drowsiness Detection in Solution Space:
-
- The software shall allocate a body/head for each configured seat based on .
-
- For each configured seat, the software shall output the drowsiness level for each detected occupant.
-
- The software shall implement a scoring system that tracks feature 1, feature 2, etc. (for example: eye gaze, yawning detection) for the drowsiness detection.
Conclusion
In the area of in-cabin monitoring, several challenges can be seen that can be resolved with proper requirements engineering:
- Frequent changes in customer expectations, often without formal change requests, disrupt planning and lead to inconsistencies.
- Conflicting needs between customer-specific requirements (e.g. specific logic for distraction detection) and external standards such as NCAP 2026 create alignment issues that must be resolved at the requirements level.
- Excessive focus on implementation details during early discussions shifts the conversation away from capturing what the system should do and toward how it should be built – blurring the line between requirements and design.
- Requirements traceability and coverage are often undervalued, which makes it difficult to assess completeness, and test readiness.
- Low emphasis on version control and change history leads to unclear evolution of the requirements baseline, possibly complicating audits and regression analysis.
In the end, having a proper requirements management workflow in place, as well as having excellent people for maintaining such a workflow are essential for building the right product. Requirements Engineering is not just about writing down what needs to be built. It’s about navigating a landscape shaped by industry context, project constraints, evolving stakeholder expectations, and sometimes even conflicting opinions and expectations.
The goal is always clear: capture the right requirements. But the journey to get there is anything but simple. It involves people, emotions, tacit knowledge, and an ever-shifting environment. The value lies not just in the destination – the final specification – but in how skilfully and thoughtfully this target is achieved.