Questions regarding Graph Checks that check Process Requriements #804

What

Context

docs-as-code enforces the linkage rules below with graph checks: needs are selected by
type and attribute, and their linked needs are checked against a condition (either all
linked needs, or at least one).

While reviewing these checks against the tool requirements we found link attributes and
need types that no rule covers yet. Before we extend the checks, we need the process to
decide which of them the rules shall apply to.

(Found during the review: the check for tool_req__docs_arch_link_qm_to_safety_req was
inverted, i.e. unsafe links passed validation. This is fixed in docs-as-code.)

Questions

Architecture ↔ requirements (gd_req__arch_linkage_requirement)

• Q1: Mandatory requirement link for safety architecture elements?
  "Linked to at least one requirement with the same safety level" is only checked if the
  element has a fulfils link. fulfils is optional, so a safety element without any
  requirement link passes. Shall the link be mandatory for safety != QM?
• Q2: Dynamic views and modules?
  feat_arc_dyn, comp_arc_dyn and mod have safety / security and links
  (fulfils, belongs_to, includes), but are not architecture types, so no linkage
  rule applies to them. Shall they be covered?

Requirements ↔ requirements (gd_req__req_linkage_safety)

• Q3: covers (requirement → AoU)?
  Only derived_from is restricted (QM must not derive from ASIL). May a QM requirement
  cover an ASIL_B AoU?

Architecture ↔ architecture (gd_req__arch_linkage_safety_trace, gd_req__arch_linkage_security_trace)

• Q4: Which links shall "safety / security elements can only be linked against
  safety / security elements" apply to?
  Today only implements is checked, in practice only real_arc_int_op → logic_arc_int_op.

  Link	Source → target	Checked today
  implements	real_arc_int_op → logic_arc_int_op	✅
  implements	comp → logic_arc_int, real_arc_int_op	❌
  uses	comp, comp_arc_sta → logic_arc_int, real_arc_int_op; feat → logic_arc_int(_op)	❌
  consists_of	comp → comp	❌
  belongs_to	feat_arc_sta, comp → feat; comp_arc_sta → comp	❌
  includes, provides	feat, feat_arc_sta → logic_arc_int(_op)	❌
  included_by	logic_arc_int → feat; logic_arc_int_op → logic_arc_int; real_arc_int_op → real_arc_int	❌

  • Dependency (uses): a safety element using a QM element. Interference, so apply?
  • Realization (implements): an ASIL element implementing a QM interface "over-fulfils"
    it, which is allowed for requirements (derived_from). Apply?
  • Structure (belongs_to, included_by, includes, provides, consists_of): apply,
    and in which direction (safety element inside a QM parent vs. QM parts inside a
    safety element)?

General

• Q5: Security rules for requirements?
  Safety has requirement → requirement, architecture ↔ requirement and architecture →
  architecture rules. Security only has architecture → architecture. Intended?
• Q6: Invalid needs?
  Only the safety architecture → architecture rule exempts status == invalid needs.
  Shall invalid needs be exempt from all linkage rules, or from none?
• Q7: Workproducts → ASPICE 4.0?
  docs-as-code checks that workproducts only complies with ASPICE 4.0 IIC requirements
  or standard workproducts, but there is no process / tool requirement for it. Shall one
  be added?

Data model needed for open tool requirements

• Q8: "Same or higher ASIL" than what? (gd_req__saf_attr_mitigated_by,
  gd_req__saf_linkage_safety)
  At least one mitigated_by requirement shall have the same or a higher ASIL. FMEA /
  DFA needs have no safety attribute, so there is no ASIL to compare against.
  Proposal: the ASIL of the architecture element the FMEA / DFA violates.
• Q9: What is the "own" AoU of an architecture element? (gd_req__arch_linkage_aou)
  Static views shall not be linked to their own AoU via fulfils. An aou_req has no
  link to a component, so "own" is not modeled. How shall it be determined?

Acceptance Criteria (DoD)

Answered above questions.

How

No response