Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions docs/internals/requirements/requirements.rst
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,7 @@ This section provides an overview of current process requirements and their clar
Req, 'tool_req__docs' in id and implemented == "YES" and "Requirements" in tags and status == "valid", 'tool_req__docs' in id and implemented == "PARTIAL" and "Requirements" in tags and status == "valid", 'tool_req__docs' in id and implemented == "NO" and "Requirements" in tags and status == "valid", 'tool_req__docs' in id and "Requirements" in tags and status != "valid"
Arch, 'tool_req__docs' in id and implemented == "YES" and "Architecture" in tags and status == "valid", 'tool_req__docs' in id and implemented == "PARTIAL" and "Architecture" in tags and status == "valid", 'tool_req__docs' in id and implemented == "NO" and "Architecture" in tags and status == "valid", 'tool_req__docs' in id and "Architecture" in tags and status != "valid"
DDesign, 'tool_req__docs' in id and implemented == "YES" and "Detailed Design & Code" in tags and status == "valid", 'tool_req__docs' in id and implemented == "PARTIAL" and "Detailed Design & Code" in tags and status == "valid", 'tool_req__docs' in id and implemented == "NO" and "Detailed Design & Code" in tags and status == "valid", 'tool_req__docs' in id and "Detailed Design & Code" in tags and status != "valid"
Verif, 'tool_req__docs' in id and implemented == "YES" and "Verification Evidence" in tags and status == "valid", 'tool_req__docs' in id and implemented == "PARTIAL" and "Verification Evidence" in tags and status == "valid", 'tool_req__docs' in id and implemented == "NO" and "Verification Evidence" in tags and status == "valid", 'tool_req__docs' in id and "Verification Evidence" in tags and status != "valid"
TVR, 'tool_req__docs' in id and implemented == "YES" and "Tool Verification Reports" in tags and status == "valid", 'tool_req__docs' in id and implemented == "PARTIAL" and "Tool Verification Reports" in tags and status == "valid", 'tool_req__docs' in id and implemented == "NO" and "Tool Verification Reports" in tags and status == "valid", 'tool_req__docs' in id and "Tool Verification Reports" in tags and status != "valid"
Other, 'tool_req__docs' in id and implemented == "YES" and "Process / Other" in tags and status == "valid", 'tool_req__docs' in id and implemented == "PARTIAL" and "Process / Other" in tags and status == "valid", 'tool_req__docs' in id and implemented == "NO" and "Process / Other" in tags and status == "valid", 'tool_req__docs' in id and "Process / Other" in tags and status != "valid"
SftyAn, 'tool_req__docs' in id and implemented == "YES" and "Safety Analysis" in tags and status == "valid", 'tool_req__docs' in id and implemented == "PARTIAL" and "Safety Analysis" in tags and status == "valid", 'tool_req__docs' in id and implemented == "NO" and "Safety Analysis" in tags and status == "valid", 'tool_req__docs' in id and "Safety Analysis" in tags and status != "valid"
Expand Down Expand Up @@ -820,6 +821,28 @@ Testing
Docs-AS-Code shall provide a way to gather statistics on linkages to implementation(source_code_links) & tests(testlink) for all needs.
It shall also be possible to filter these by type and use the provided statistics in the documentation (via diagrams drawn from it etc.)

🔎 Verification Evidence
########################

.. tool_req:: Support machine-readable inspection records
:id: tool_req__docs_inspection_record_need
:tags: Verification Evidence
:implemented: YES
:version: 1
:satisfies: gd_req__verification_checks
:parent_covered: NO: process wording defines verification checks, while the tool models a first-class inspection record artifact.

Docs-as-Code shall support a machine-readable inspection record need type.

The need type shall:

* use ``mod_insp`` as directive type
* classify the inspection by ``inspection_type`` and ``inspection_state``
* record the checklist reference and reviewer list via ``checklist_ref`` and ``reviewers``
* link the inspection to the verified module via ``belongs_to``
* link the inspected artifacts via ``inspects``
* allow links to backing evidence via ``evidence``

🧪 Tool Verification Reports
############################

Expand Down
49 changes: 49 additions & 0 deletions src/extensions/score_metamodel/metamodel.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -933,6 +933,47 @@ needs_types:
fully_verifies: ANY
partially_verifies: ANY

# Formal inspection evidence modeled as a first-class artifact.
# req-Id: tool_req__docs_inspection_record_need
mod_insp:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not fully understand how this will be used. My assumption based on the example in eclipse-score/persistency#330 is that it is a part of the verification report but has one instance per each inspection evidence. E.g. in baselibs this would be about ten records for requirements inspections (one per avery component). Comments given based on this assumption.

title: Module Inspection Record
prefix: mod_insp__
mandatory_options:
# req-Id: tool_req__docs_common_attr_safety
safety: ^(QM|ASIL_B)$
# req-Id: tool_req__docs_common_attr_security
security: ^(YES|NO)$
# req-Id: tool_req__docs_common_attr_status
status: ^(valid|invalid)$
# req-Id: tool_req__docs_inspection_record_need
inspection_type: ^(requirements|architecture|implementation|traceability|safety_analysis|security_analysis|other)$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are only inspections of type "requirements|architecture|implementation"

inspection_state: ^(planned|in_review|rework_required|approved)$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

state "planned" is the same as having a checklist document in "draft" state, "in_review" would be as long as the PR to fill out the checklist is in draft/open, "rework_required" would mean checklist has a "NO", "approved" means all checkpoints are "YES". Expect this is filled out automatically?

checklist_ref: ^.*$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in your example this links to a template (gd_temp), but why have this attribute? information can be derived already from "inspection_type"

reviewers: ^.*$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what importance has this for the verification report (same for moderator and approver below)

optional_options:
checklist_type: ^(req|arc|impl|safety|security|custom)$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

somehow a duplicate of "inspection_type"

moderator: ^.*$
approver: ^.*$
findings_total: ^[0-9]+$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure this can be determined automatically.

findings_open: ^[0-9]+$
pr_link: ^https://github\.com/[^/]+/[^/]+/pull/\d+$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which PR? What is it needed for?

correction_issue: ^https://github\.com/[^/]+/[^/]+/issues/\d+$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it really needed here? can be seen in checklist (linked in below "evidence")

inspection_date: ^[0-9]{4}-[0-9]{2}-[0-9]{2}$

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you use this for? I do not think you can judge from the date if it is still valid.

mandatory_links:
# req-Id: tool_req__docs_inspection_record_need
belongs_to: mod
inspects: ANY
optional_links:
# req-Id: tool_req__docs_inspection_record_need
contains: ANY

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"contains" makes no sense in inspection record (at least if it is the same usage as in verification report). Or do you want to pack inspection records in inspection records?

evidence: ANY
approved_by: role
supported_by: role
tags:
- inspection
- verification_evidence

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is not an evidence?

parts: 3


# https://eclipse-score.github.io/process_description/main/permalink.html?id=gd_temp__change_decision_record
dec_rec:
Expand Down Expand Up @@ -1068,6 +1109,14 @@ needs_extra_links:
incoming: partially_verified_by
outgoing: partially_verifies

evidence:
incoming: evidence_for
outgoing: evidence

inspects:
incoming: inspected_by
outgoing: inspects


##############################################################
# Graph Checks
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
..
# *******************************************************************************
# Copyright (c) 2026 Contributors to the Eclipse Foundation
#
# See the NOTICE file(s) distributed with this work for additional
# information regarding copyright ownership.
#
# This program and the accompanying materials are made available under the
# terms of the Apache License Version 2.0 which is available at
# https://www.apache.org/licenses/LICENSE-2.0
#
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************
#CHECK: check_options


.. Base architecture and requirement objects used by inspection record tests

.. feat:: Inspection Feature
:id: feat__inspection_feature
:security: YES
:safety: ASIL_B
:status: valid

.. comp:: Inspection Component
:id: comp__inspection_component
:security: YES
:safety: ASIL_B
:status: valid
:belongs_to: feat__inspection_feature

.. mod:: Inspection Module
:id: mod__inspection_module
:security: YES
:safety: ASIL_B
:status: valid
:includes: comp__inspection_component

.. comp_req:: Inspection Requirement
:id: comp_req__inspection__sample
:reqtype: Functional
:security: YES
:safety: ASIL_B
:status: valid

Requirement text for inspection record tests.


.. Valid machine-readable inspection record need
#EXPECT-NOT[+2]: does not follow pattern

.. mod_insp:: Inspection Record Valid
:id: mod_insp__inspection__valid
:safety: ASIL_B
:security: YES
:status: valid
:inspection_type: requirements
:inspection_state: approved
:checklist_ref: gd_chklst__req_inspection
:reviewers: reviewer_a,reviewer_b
:checklist_type: req
:findings_total: 1
:findings_open: 0
:inspection_date: 2026-06-24
:belongs_to: mod__inspection_module
:inspects: comp_req__inspection__sample


.. Invalid inspection_state value in module inspection record
#EXPECT[+2]: mod_insp__inspection__bad_state.inspection_state (approved_late): does not follow pattern

.. mod_insp:: Inspection Record Invalid State
:id: mod_insp__inspection__bad_state
:safety: ASIL_B
:security: YES
:status: invalid
:inspection_type: architecture
:inspection_state: approved_late
:checklist_ref: gd_chklst__arch_inspection_checklist
:reviewers: reviewer_a
:belongs_to: mod__inspection_module
:inspects: comp_req__inspection__sample
Loading