personAuthor: Manuel Schmidt, Alexander Feulner
How is modern requirements engineering implemented in practice, and what role does artificial intelligence play across the entire lifecycle—from creation and analysis to the quality assurance of requirements?
Together with our partner Innovigate, the developer of the Tracelane tool, we illustrate this with a practical demonstration. Tracelane is a modern requirements management tool with an intelligent AI assistant that creates, analyzes, evaluates, and provides concrete suggestions for improvement.
school
Webinar recording and slides
arrow_forward "How do I bring levels to my requirement chaos?"
personAuthor: Timo Karasch
First, our processes constantly ask us to specify requirements. Then we have to bother with quite a lot of documents and specifications. Even the relevant literature cannot explain to me in an understandable way what the difference between all these requirements is supposed to be. And finally, an assessor comes and evaluates my specification as insufficient.
This is the end of it! In this webinar we want to bring levels into our requirements chaos. Using simple examples, we will show the different types of requirements and learn a few helpful methods for working with requirements.
school
Webinar recording and slides
arrow_forward "Requirements are not just for engineers"
personAuthor: Process Fellows
Involve testers, safety experts, UX and product managers in the review. Each brings a unique perspective — and helps uncover hidden assumptions.
arrow_forward "Systems Engineering - Why the heck do we need this?"
personAuthor: Alexander Feulner
The increasing complexity, shortened development times, distributed development, heightened cost pressures, technological change, and organizational transformations are just a few of the challenges facing the current development.
If these statements seem unfamiliar to you, we congratulate you warmly. For all those who are confronted with these challenges on a daily basis, we present the methodology of ‘Systems Engineering’ in our webinar and answer the question: "Why the heck do we need this?". This webinar is tailored not only for system developers but also for professionals in various domains including software development, hardware development, testing, project management and more.
school
Webinar recording and slides
arrow_forward "What is the difference between need, expectation and requirement?"
personAuthor: Process Fellows
Typically the terms Need, Expectation, and Requirement are distinguished as follows:
A Need describes a fundamental problem or desire of a stakeholder that should be addressed. It is often vague and not directly actionable. Needs arise from the stakeholder’s context, goals, or challenges.
Example: “I want to be able to work faster.”
An Expectation is a stakeholder’s specific idea or assumption about how a Need might be fulfilled. It is subjective and can be expressed explicitly or implicitly.
Example: “I expect the system to automatically suggest options.”
A Requirement is a documented, verifiable, and actionable specification derived from a Need or Expectation. It serves as the basis for design, implementation, and testing.
Example: “The system shall display three relevant suggestions to the user within 2 seconds.”
Summary:
Need: motivates development
Expectation: expresses a concrete idea
Requirement: a clearly defined, verifiable specification describing what is expected to be fulfilled
This distinction helps structure the process of eliciting, analyzing, and documenting requirements.
# PROCESS PURPOSE
The purpose is to gather, analyze, and track evolving stakeholder needs and requirements throughout the lifecycle of the product and/or service to establish a set of agreed requirements.
# PROCESS OUTCOMES
O1
continuing communication with the stakeholder is established;
O2
Stakeholder expectations are understood, and requirements are defined and agreed.
O3 (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) changes arising from stakeholder needs are analyzed to enable associated (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) assessment and impact management.
O4
Determination of (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) status is ensured for all affected parties.
# BASE PRACTICES
BP1
Obtain stakeholder expectations and requests. (
O1 )
Obtain and define stakeholder expectations and requests through direct solicitation of stakeholder input, and through review of stakeholder business proposals (where relevant) and other documents containing inputs to (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …), and consideration of the target operating and (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) environment.Note 1: Documenting the stakeholder, or the source of a stakeholder requirement, supports (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) agreement and change analysis (see BP2 and BP3).
personAuthor: Process Fellows
Go beyond “the customer said so.” Capture stakeholder needs with context, rationale, and validation criteria. Use personas, usage scenarios, or interviews. Make it testable – even if it’s fuzzy.
This is not an easy task - but crucial to project success and the invest will be returned on within all subsequent processes.
BP2
Agree on requirements. (
O2 )
Formalize the stakeholder’s expectations and requests into requirements. Reach a common understanding of the set of (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) among affected parties by obtaining an explicit agreement from all affected parties.Note 2: Examples of affected parties are customers, suppliers, design partners, joint venture partners, or outsourcing parties.Note 3: The agreed (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) may be based on feasibility studies and/or cost and schedule impact analysis.
Linked Knowledge Nuggets: arrow_forward "How to handle conflicting requirements?"
personAuthor: Process Fellows
Don’t sweep conflicts under the rug. Document them. Bring stakeholders together. Use impact analysis. Ultimately ensure consistency. Clarity today avoids chaos tomorrow.
arrow_forward "The role of assumptions in (system) requirements analysis"
personAuthor: Process Fellows
When deriving system requirements, assumptions fill the gaps. Example: assuming 4G connectivity is always available. Make such assumptions explicit and document their impact. Validate together with stakeholders if such assumptions are correct! If they change, system behavior might too – and that needs tracking.
Analyze all changes made to the (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) against the agreed (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …). Assess the impact and (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.), and initiate appropriate change control and mitigation actions.Note 4: Requirements changes may arise from different sources as for instance changing technology, stakeholder needs, or legal constraints.Note 5: Refer to SUP.10 Change Request Management, if required.
BP4
Communicate requirements status. (
O1, O4 )
Ensure all affected parties can be aware of the status and disposition of their requirements including changes and can communicate necessary information and data.
# OUTPUT INFORMATION ITEMS
15-51
Analysis results (
O3 )
Identification of the object under analysis.
The analysis criteria used, e.g.:
selection criteria or prioritization scheme used
decision criteria
quality criteria
The analysis results, e.g.:
what was decided/selected
reason for the selection
assumptions made
potential negative impact
Aspects of the analysis may include
correctness
understandability
verifiability
feasibility
validity
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
MAN.5 Risk Management
MAN.6 Measurement
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
PIM.3 Process Improvement
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
13-52
Communication evidence (
O1, O2 )
All forms of interpersonal communication such as
e-mails, also automatically generated ones
tool-supported workflows
meeting, verbally or via meeting minutes (e.g., daily standups)
podcast
blog
videos
forum
live chat
wikis
photo protocol
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
PIM.3 Process Improvement
REU.2 Management of Products for Reuse
SUP.1 Quality Assurance
SUP.11 Machine Learning Data Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
Used by these process attributes:
PA2.1 Performance Management
17-00
Requirement (
O2 )
An expectation of functions and capabilities (e.g., non- (Functional requirement = A statement that identifies what a product or process must accomplish to produce required behavior and/or results.)), or one of its interfaces
from a black-box perspective
that is verifiable, does not imply a design or implementation decision, is unambiguous, and does not introduce contradictions to other requirements.
A requirements statement that implies, or represents, a design or implementation decision is called “Design Constraint”.
Examples for requirements aspects at the system level are thermal characteristics such as
heat dissipation
dimensions
weight
materials
Examples of aspects related to requirements about system interfaces are
connectors
cables
housing
Examples for requirements at the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) level are
lifetime and mission profile, lifetime robustness
maximum price
storage and transportation requirements
functional behavior of analog or digital circuits and logic
quiescent current, voltage impulse responsiveness to crank, start-stop, drop-out, load dump
temperature, maximum (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) heat dissipation
power consumption depending on the operating state such as sleep-mode, start-up, reset conditions
frequencies, modulation, signal delays, filters, control loops
power-up and power-down sequences, accuracy and precision of signal acquisition or signal processing time
computing resources such as memory space and CPU clock tolerances
maximum abrasive wear and shearing forces for e.g., pins or soldering joints
requirements resulting from lessons learned
safety related requirements derived from the technical safety concept
Used by these processes:
HWE.1 Hardware Requirements Analysis
MLE.1 Machine Learning Requirements Analysis
SWE.1 Software Requirements Analysis
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
17-54
Requirement Attribute (
O2, O3, O4 )
Meta-attributes that support structuring and definition of (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) scopes of requirements.
Can be realized by means of tools.
Note: usage of requirements attributes may further support analysis of requirements.
SYS.1
Requirements Elicitation
