SEC.1 Cybersecurity Requirements Elicitation

Linked Knowledge Nuggets:
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 "Fo(u)rces of Cybersecurity Engineering"

person Author: Timo Karasch, Florian Schmitt
Cybersecurity Goals, Controls, Requirements and Threats are important forces for cybersecurity engineering. It is nearly impossible to separate them in a timely manner. In fact, they influence each other during definition. This webinar gives a simple example of the interaction of these four forces and addresses the consistency to existing standards in Cybersecurity (ISO 21434 and Automotive SPICE for Cybersecurity). It shows a possible approach for implementation in your organization.

• 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 Cybersecurity goals (Cybersecurity goal = Concept-level cybersecurity requirement associated with one or more threat scenarios.) are specified.
• O2 Cybersecurity requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) are derived from cybersecurity goals (Cybersecurity goal = Concept-level cybersecurity requirement associated with one or more threat scenarios.).
• O3 Consistency (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and bidirectional traceability (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) are maintained between cybersecurity requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) and goals and between the cybersecurity goals (Cybersecurity goal = Concept-level cybersecurity requirement associated with one or more threat scenarios.) and the threat scenarios (Threat Scenario = Potential cause of compromise in cybersecurity properties of one or more assets in order to realize a damage scenario.).
• O4 The cybersecurity requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) are agreed and communicated to all affected parties.

BP1 Specify cybersecurity goals and cybersecurity requirements. ( O1, O2 )

Specify cybersecurity goals (Cybersecurity goal = Concept-level cybersecurity requirement associated with one or more threat scenarios.) for the threat scenarios (Threat Scenario = Potential cause of compromise in cybersecurity properties of one or more assets in order to realize a damage scenario.) according to the decisions regarding risk treatment to achieve risk reduction.
Specify functional and non-functional cybersecurity requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) for the cybersecurity goals (Cybersecurity goal = Concept-level cybersecurity requirement associated with one or more threat scenarios.). Specify these according to defined characteristics for requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.).
Note 1: This includes the refinement of requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) during iterations of this process.
Note 2: This includes requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) for post-development phases which may include production, operation, maintenance and decommissioning.
Note 3: Characteristics of requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) are defined in standards such as ISO IEEE 29148, ISO 26262-8:2018, or the INCOSE Guide To Writing Requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.).
Note 4: Examples for defined characteristics of requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) shared by technical standards are:

• verifiability (i.e., verification (Verification = Verification is confirmation, through the provision of objective evidence, that specified requirements have been fulfilled in a given work item.) criteria being inherent in the requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) text)
  
• unambiguity/comprehensibility
  
• freedom from design and implementation
  
• not contradicting any other requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.)

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 Ensure consistency and establish bidirectional traceability. ( O3 )

Ensure consistency (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and establish bidirectional traceability (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) between the cybersecurity requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) and the cybersecurity goals (Cybersecurity goal = Concept-level cybersecurity requirement associated with one or more threat scenarios.). Ensure consistency (Consistency = Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.) and establish bidirectional traceability (Traceability = The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.) between the cybersecurity goals (Cybersecurity goal = Concept-level cybersecurity requirement associated with one or more threat scenarios.) and the threat scenarios (Threat Scenario = Potential cause of compromise in cybersecurity properties of one or more assets in order to realize a damage scenario.).

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.