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 "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 establish a structured and analyzed set of (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements consistent with 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. …).
# PROCESS OUTCOMES
O1
The (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements are specified.
O2
The (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements are structured and prioritized.
O3
The (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements are analyzed for correctness and technical feasibility.
O4
The impact of the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements on the operating environment is analyzed.
O5
Consistency and bidirectional traceability are established between the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements and 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. …).
O6
The (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements are agreed and communicated to all affected parties.
# BASE PRACTICES
intacs® Certified Process Expert (Automotive SPICE®)
Sponsored
The official intacs® certified training to become an Automotive SPICE® Process Expert.
Use 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. …) 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 (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) according to the 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 criteria being inherent in the requirements text), unambiguity/comprehensibility, freedom from design and implementation, and not contradicting any other requirement).
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 the system requirements. (
O2 )
Structure and prioritize the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements. Note 3: Examples for structuring can be grouping by functionality or product variants identification. Note 4: 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 requirements.) or stakeholder needs via, e.g., definition of (Release = A product delivered to a customer, including a defined set of functionalities and properties.) scopes. Please 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 the system requirements. (
O3 )
Analyze the specified (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) 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 requirements.) management regarding (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) estimates. Note 5: 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 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 requirements.) estimates. Note 6: Technical feasibility can be evaluated based on, e.g., platform or product line, or by means of prototype development or product demonstrators.
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.
BP4
Analyze the impact on the system context. (
O4 )
Analyze the impact that the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements will have on the elements in the relevant (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) context.
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 "What does 'System Context' actually mean?"
personAuthor: Process Fellows
The system context defines what’s inside your system boundary – and what’s not. It includes external systems, actors, and data exchanged. A good system context diagram highlights dependencies, clarifies interfaces, and prevents scope creep. Use simple boxes-and-arrows to visualize, and validate it with all stakeholders early.
BP5
Ensure consistency and establish bidirectional traceability. (
O5 )
Ensure consistency and establish bidirectional traceability between the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements and 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. …). Note 7: Bidirectional traceability supports consistency, facilitates the impact analyses of change requests, and supports the demonstration of coverage of 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. …). Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent. Note 8: There may be non-functional (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. …) that the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements do not trace to. Examples are process requirements. Such (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. …) are still subject to verification.
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 the agreed system requirements and the impact on the system context. (
O6 )
Communicate the agreed (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements, and the results of the impact analysis on the (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) context, to all affected parties.
# OUTPUT INFORMATION ITEMS
15-51
Analysis results (
O3, O4 )
Results of analysis of an object or (Task = A definition, but not the execution, of a coherent set of atomic actions.).Identifies:
Object under analysis
Analysis criteria
Selection criteria or prioritization scheme
Decision criteria
Quality criteria
Includes:
Decisions and selections performed
Assumptions and constraints
Evaluation criteria, for example correctness, completeness or consistency to a work product
Examples and references:
Verifiability analysis results, for example when a test machine becomes defective
Results of a feasibility analysis
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 (
O6 )
Evidence of interpersonal communication.Identifies:
Scope of information
Need for feedback, for example an expected confirmation within one week
Meta data, for example time when communication was done or how information was distributed.
Includes:
Personal information
Work-flows, for example within tools
Examples and References:
E-mails and other forms of memos
Verbal statements
Meeting minutes, for example in standups
Electronic media, for example webcasts, blog posts intranet forum
Chat protocols
Wiki pages
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 Reuse of Products
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 Process performance management process attribute
13-51
Consistency evidence (
O5 )
Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, (Task = A definition, but not the execution, of a coherent set of atomic actions.) and products throughout their lifecycle.Identifies:
Traceability information, for example hyperlinks, repository location or editorial references.
Naming conventions
Relevant artifacts
Revision and revision history information
Change documentation and analysis information
Includes:
Meta-information, for example database identifiers notes in Git commits comments
Examples and References:
Evidence of Definition of Done (DoD) adherence.
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 )
Statement that identifies an operational, functional, or design characteristic, which is unambiguous, testable, measurable, and necessary for product or process acceptability.Identifies:
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.))
Owner and origin of the requirement
Identification information
Boundaries, for example target price range
Includes:
Stakeholder viewpoint, for example black-box perspective
Design constraints, for example predefined and necessary implementation details.
Tolerances
Domain specific details, for example of safety and privacy standards
Examples and references:
ISO/IEC directive quote: “expression, in the content of a document, that conveys objectively verifiable criteria to be fulfilled and from which no deviation is permitted if conformance with the document is to be claimed”
ISO/IEC 42010:2007
(Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) level requirements for example mission profile, storage requirements of environment boundary definitions during environment test.
Operational expectations for example power consumption, crank behavior, heat dissipation boundaries.
Resource constraints, for example performance and memory space definition.
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 )
Information supporting structuring of requirements for specific context or intent.Identifies:
SYS.2
System Requirements Analysis
