HWE.1 Hardware 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.

arrow_forward "What is the difference between need, expectation and requirement?"

person Author: Process Fellows
Typically the terms Need, Expectation, and Requirement are distinguished as follows:

1. 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.”
2. 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.”
3. 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.

• O1 Hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements are specified.
• O2 Hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements are structured and prioritized.
• O3 Hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements are analyzed for correctness and technical feasibility.
• O4 The impact of hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements on the operating environment is analyzed.
• O5 Consistency and bidirectional traceability are established between hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements and system requirements.
• O6 Consistency and bidirectional traceability are established between hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements and system architectural design.
• O7 The hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements are agreed and communicated to all affected parties.

BP1 Specify hardware requirements. ( O1 )

Use the system requirements, and the system architecture including interface definitions, to identify and document the functional and non-functional requirements (Functional requirement = A statement that identifies what a product or process must accomplish to produce required behavior and/or results.) of the hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) 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: Examples for defined characteristics of requirements shared by the above-mentioned standards are verifiability (i.e., verification (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 hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.)-only development, the system requirements and the system architecture refer to a given operating environment. In that case, stakeholder requirements (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 hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.).
Note 4: The hardware (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 software and therefore is an interface decision at the system design level. If such a HSI exists, then it may provide input to hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements.

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 hardware requirements. ( O2 )

Structure and prioritize the hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements.
Note 5: Examples for structuring criteria can be grouping (e.g., by functionality) or variants identification.
Note 6: Prioritization can be done according to project (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 (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?"

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 hardware requirements. ( O3 )

Analyze the specified hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements including their interdependencies to ensure correctness, technical feasibility, and to support project (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 (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 (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 (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: The analyses of technical feasibility can be done based on a given hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) design (e.g., platform) or by 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 )

Identify the interfaces between the specified hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) and other elements of the operating environment. Analyze the impact that the hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements will have on these interfaces and the operating environment.

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 )

Ensure consistency and establish traceability between hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements and the system architecture. Ensure consistency and establish traceability between hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements and system requirements.
Note 9: Redundant traceability is not intended.
Note 10: There may be non-functional hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) requirements that the hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) design does not trace to. Examples are development process requirements. Such requirements are still subject to verification (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 = 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 hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) 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 (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 hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) 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.