Linked Knowledge Nuggets: arrow_forward "8 quick wins for a clean requirements analysis"
personAuthor: Process Fellows
Use a clear requirements template, define ownership, maintain traceability, differentiate between functional and non-functional requirements, apply quality checklists, involve stakeholders early, and ensure version control. And yes – always think: Can I test/ verify this?
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 "Software Requirements Analysis and Architectural Design"
personAuthor: Process Fellows
SWE.1 & SWE.2 define how software requirements are derived from system input and structured into a clear, consistent software architecture. The processes ensure traceability, logical breakdown, and well-founded design decisions for scalable and maintainable software.
school
PF_SWE.1_SWE.2_Software Requirements Analysis and Architecture _Extract.pdf
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 establish a structured and analyzed set of software requirements consistent with the system requirements, and the system architecture.
# PROCESS OUTCOMES
O1
Software requirements are specified.
O2
Software requirements are structured and prioritized.
O3
Software requirements are analyzed for correctness and technical feasibility.
O4
The impact of software requirements on the operating environment is analyzed.
O5
Consistency and bidirectional traceability are established between software requirements and system requirements.
O6
Consistency and bidirectional traceability are established between software requirements and system architecture.
O7
The software requirements are agreed and communicated to all affected parties.
# BASE PRACTICES
BP1
Specify software requirements. (
O1 )
Use the system requirements and the system architecture to identify and document the functional and non- (Functional requirement = A statement that identifies what a product or process must accomplish to produce required behavior and/or results.) for the software according to defined characteristics for requirements. Note 1: Characteristics of requirements are defined in standards such as ISO IEEE 29148, ISO 26262-8:2018, or the INCOSE Guide for Writing Requirements. Note 2: Examples for defined characteristics of requirements shared by technical standards are verifiability (i.e., (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) criteria being inherent in the requirements text), unambiguity/comprehensibility, freedom from design and implementation, and not contradicting any other requirement). Note 3: In case of software-only development, the system requirements and the system architecture refer to a given operating environment. In that case, (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. …) can be used as the basis for identifying the required functions and capabilities of the software. Note 4: The (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.)-software-interface (HSI) definition puts in context (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) and therefore it is an interface decision at the system design level. If such a HSI exists, then it may provide input to software requirements.
personAuthor: Process Fellows
Yes, SWE.1.BP1 speaks about system requirements and system architecture to derive the SW requirements from. But: SW requirements don’t all come from the system level. Some emerge during architecture or interface planning on SW level itself, e.g. boundary conditions and design constraints. That is an iterative process, and this is okay.
By the way, design constraints that originate already in stakeholder requirements are typical.
arrow_forward "INCOSE Guide to writing requirements v4 - Summary Sheet"
personAuthor: Process Fellows
The INCOSE Guide to Writing Requirements is a comprehensive resource developed by the Requirements Working Group (RWG) of the International Council on Systems Engineering (INCOSE). It provides best practices and structured guidance for writing high-quality requirements in systems engineering. The guide contains
Characteristics of "good" requirements
Writing rules
Boilerplates / templates
Quality aspects for requirement sets
Common pitfalls when specifying requirements
The guide is available for free for INCOSE members, there is a small fee for non-members. The linked summary sheet is available for free for everybody.
school
External link to pdf file published at INCOSE website
arrow_forward "Specifying behavior under all conditions"
personAuthor: Process Fellows
It’s not just about sunny-day scenarios. Requirements should specify as well handling of failure cases, degraded modes, and edge conditions. Ask: what happens if X fails or behaves oddly?
BP2
Structure software requirements. (
O2 )
Structure and prioritize the software requirements. Note 5: Examples for structuring criteria can be grouping (e.g., by functionality) or expressing product variants. Note 6: Prioritization can be done according to (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) or stakeholder needs via e.g., definition of (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) scopes. Refer to SPL.2.BP1.
Linked Knowledge Nuggets: 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
BP3
Analyze software requirements. (
O3 )
Analyze the specified software requirements including their interdependencies to ensure correctness, technical feasibility, and to support (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) management regarding (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) estimates. Note 7: See MAN.3.BP3 for (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) feasibility and MAN.3.BP5 for (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) estimates. Note 8: Technical feasibility can be evaluated based on e.g., platform or product line, or by prototyping.
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.
BP4
Analyze the impact on the operating environment. (
O4 )
Analyze the impact that the software requirements will have on elements in the operating environment.
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.
Ensure consistency and establish bidirectional traceability between software requirements and system architecture. Ensure consistency and establish bidirectional traceability between software requirements and system requirements. Note 9: Redundant traceability is not intended. Note 10: There may be non-functional system requirements that the software requirements do not trace to. Examples are process requirements or requirements related to later software product lifecycle phases such as incident handling. Such requirements are still subject to (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.). Note 11: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other. Note 12: In case of software development only, the system requirements and system architecture refer to a given operating environment. In that case, consistency and bidirectional traceability can be ensured between (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 software requirements.
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
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 traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP6
Communicate agreed software requirements and impact on the operating environment. (
O7 )
Communicate the agreed software requirements, and the results of the analysis of impact on the operating environment, to all affected parties.
# OUTPUT INFORMATION ITEMS
15-51
Analysis results (
O3, O4 )
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 (
O7 )
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
13-51
Consistency Evidence (
O5 )
Demonstrates bidirectional traceability between artifacts or information in artifacts, throughout all phases of the life cycle, by e.g.,
tool links
hyperlinks
editorial references
naming conventions
Evidence that the content of the referenced or mapped information coheres semantically along the traceability chain, e.g., by
performing pair working or group work
performing by peers, e.g., spot checks
maintaining revision histories in documents
providing change commenting (via e.g., meta-information) of database or repository entries
Note: This evidence can be accompanied by e.g., Definition of Done (DoD) approaches.
Used by these processes:
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
SUP.8 Configuration Management
SUP.10 Change Request 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.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
17-00
Requirement (
O1, 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 )
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.
SWE.1
Software Requirements Analysis
