MEE.1 Mechanical Requirements Analysis

Linked Knowledge Nuggets:
arrow_forward "8 quick wins for a clean requirements analysis"

person Author: 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?

arrow_forward "AI supported requirements management"

person Author: 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?"

person Author: 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"

person Author: Process Fellows
Involve testers, safety experts, UX and product managers in the review. Each brings a unique perspective — and helps uncover hidden assumptions.

• O1 The Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements are specified.
• O2 The Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements are structured and prioritized.
• O3 The Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements are analyzed for correctness, verifiability, and technical feasibility.
• O4 The impact of Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements on the Operating Environment (Operating Environment = Operating Environment is the context in which the considered system works.) is analyzed.
• O5 Consistency (Consistency = Consistency addresses content and semantics and ensures that Information items are not in contradiction to each other.
  Consistency is supported by bidirectional traceability.
  
  See also chapter D.3.) and bidirectional traceability (Traceability = Traceability refers to the existence of references or links between Information items.
  Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.
  
  See also chapter D.3.) are established between the Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and the Upper System (Upper System = The system into which the system or component under consideration is directly integrated is called the upper system.) Requirements and/or Upper System (Upper System = The system into which the system or component under consideration is directly integrated is called the upper system.) Architecture.
• O6 Consistency (Consistency = Consistency addresses content and semantics and ensures that Information items are not in contradiction to each other.
  Consistency is supported by bidirectional traceability.
  
  See also chapter D.3.) and bidirectional traceability (Traceability = Traceability refers to the existence of references or links between Information items.
  Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.
  
  See also chapter D.3.) are established between the Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements and the Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and/or Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Architecture.
• O7 The Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements are agreed and communicated to all affected parties.

BP1 Specify Mechanical Requirements. ( O1 )

Use the Upper (Mechanical) System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and the Upper (Mechanical) System (System = A system consists of at least two elements which can be either a system or a component.) Architecture as well as changes to the Upper (Mechanical) System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and Upper (Mechanical) Architecture to identify and document functional and non-functional Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements according to defined characteristics for requirements.

Note 1: Characteristics of requirements are defined in standards such as ISO IEEE 29148, ISO/IEC IEEE 24765, ISO 26262-8:2018, or the INCOSE Guide for Writing Requirements.
Note 2: Mechanical Requirements should include tolerances as necessary.
Note 3: Examples for defined characteristics of requirements shared by technical standards are verifiability (i.e., verification criteria (Verification criteria = Verification criteria define the qualitative and quantitative criteria for verification of a requirement.
Verification criteria demonstrate that a requirement can be verified within agreed constraints. (Additional Requirement to 17-00 Requirements specification)) being inherent in the requirements text), unambiguity/comprehensibility, freedom from design and implementation, and not contradicting any other requirement).
Note 4: In case of mechanical-only development, the System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and the System (System = A system consists of at least two elements which can be either a system or a component.) Architecture refer to a given operating environment (Operating Environment = Operating Environment is the context in which the considered system works.). In that case, stakeholder requirements (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirements, 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 mechanic.

Linked Knowledge Nuggets:
arrow_forward "INCOSE Guide to writing requirements v4 - Summary Sheet"

person Author: 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"

person Author: 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 Mechanical Requirements. ( O2 )

Structure and prioritize the Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) 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 or stakeholder (Stakeholder = People and organizations such as customers, sponsors, the performing organization, or the public who are actively involved in the project or whose interests are positively or negatively affected by the performance or completion of the project.
They may also exert influence over the project and its deliverables.) needs via e.g., definition of release (Release = A physical product delivered to a customer, including a defined set of functionalities and properties.) scopes (e.g. A-/B-/C-Sample). Refer to Automotive SPICE® 4.0 (SPL.2).

Linked Knowledge Nuggets:
arrow_forward "How do I bring levels to my requirement chaos?"

person Author: 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 Mechanical Requirements. ( O3 )

Analyze the specified Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements including their interdependencies to ensure correctness, technical feasibility, verifiability and to support project management regarding project estimates.

Note 7: See MAN.3 for project feasibility and project estimates.
Note 8: Technical feasibility can be done based on given System (System = A system consists of at least two elements which can be either a system or a component.) Architectures (e.g., platform or standard product kits) or by means of prototype development.

Linked Knowledge Nuggets:
arrow_forward "How to handle conflicting requirements?"

person Author: 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 Mechanical Requirements will have on elements (Element = The term Element is a collective term for virtual or physical objects on architecture, design, and verification level on the left and right side of the "V-Model".
An architecture specifies the elements of the system. Elements are hierarchically decomposed into smaller elements down to the components which are at the lowest level of the architecture.) in the Operating Environment (Operating Environment = Operating Environment is the context in which the considered system works.).

Linked Knowledge Nuggets:
arrow_forward "How to handle conflicting requirements?"

person Author: 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.

BP5 Ensure consistency and establish bidirectional traceability. ( O5, O6 )

1. Ensure consistency (Consistency = Consistency addresses content and semantics and ensures that Information items are not in contradiction to each other.
Consistency is supported by bidirectional traceability.

See also chapter D.3.) and establish bidirectional traceability (Traceability = Traceability refers to the existence of references or links between Information items.
Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.

See also chapter D.3.) between the Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and the Upper System (Upper System = The system into which the system or component under consideration is directly integrated is called the upper system.) Requirements.
2. Ensure consistency (Consistency = Consistency addresses content and semantics and ensures that Information items are not in contradiction to each other.
Consistency is supported by bidirectional traceability.

See also chapter D.3.) and establish bidirectional traceability (Traceability = Traceability refers to the existence of references or links between Information items.
Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.

See also chapter D.3.) between the Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements and the Upper System (Upper System = The system into which the system or component under consideration is directly integrated is called the upper system.) Architecture.
3. Ensure consistency (Consistency = Consistency addresses content and semantics and ensures that Information items are not in contradiction to each other.
Consistency is supported by bidirectional traceability.

See also chapter D.3.) and establish bidirectional traceability (Traceability = Traceability refers to the existence of references or links between Information items.
Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.

See also chapter D.3.) between the Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements and the Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Requirements.
4. Ensure consistency (Consistency = Consistency addresses content and semantics and ensures that Information items are not in contradiction to each other.
Consistency is supported by bidirectional traceability.

See also chapter D.3.) and establish bidirectional traceability (Traceability = Traceability refers to the existence of references or links between Information items.
Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.

See also chapter D.3.) between the Mechanical Component (Component = Components (physical or virtual) are the lowest level elements of the mechanical architecture for which the component design is further defined.) Requirements and the Mechanical System (System = A system consists of at least two elements which can be either a system or a component.) Architecture.

Note 9: Redundant traceability (Traceability = Traceability refers to the existence of references or links between Information items.
Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.

See also chapter D.3.) is not intended.
Note 10: Bidirectional traceability (Traceability = Traceability refers to the existence of references or links between Information items.
Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.

See also chapter D.3.) supports consistency (Consistency = Consistency addresses content and semantics and ensures that Information items are not in contradiction to each other.
Consistency is supported by bidirectional traceability.

See also chapter D.3.), and facilitates impact analyses of change requests, and demonstration of verification (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) coverage (Coverage = There are:

• all objects
  
• relevant objects
  
• mapped objects

Coverage is a measure used to describe the ratio of mapped objects to relevant objects for a specific purpose.

For instance:

• Requirements coverage: ratio of mapped system requirements versus relevant system requirements
  
• Dimensional test coverage: ratio of tested dimensions versus total numbers of dimensions
  
• Elements test coverage: degree of tested elements versus all created elements
  
• Verification coverage for critical characteristics: ratio of tested or verified (e.g. production process capability – CpK) critical characteristics based on control plan

). Traceability (Traceability = Traceability refers to the existence of references or links between Information items.
Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.

See also chapter D.3.) alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.
Note 11: In case of mechanical development only, the system (System = A system consists of at least two elements which can be either a system or a component.) requirements and system (System = A system consists of at least two elements which can be either a system or a component.) architecture refer to a given operating environment (Operating Environment = Operating Environment is the context in which the considered system works.). In that case, consistency (Consistency = Consistency addresses content and semantics and ensures that Information items are not in contradiction to each other.
Consistency is supported by bidirectional traceability.

See also chapter D.3.) and bidirectional traceability (Traceability = Traceability refers to the existence of references or links between Information items.
Traceability supports coverage analysis, impact analysis, requirements implementation status tracking etc.

See also chapter D.3.) can be ensured between stakeholder requirements (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirements, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice, etc.) and mechanic requirements.

Linked Knowledge Nuggets:
arrow_forward "Consistency vs. Traceability – What’s the Difference?"

person Author: 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?"

person Author: 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"

person Author: 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 "

person Author: 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.