Welcome to Coua’s documentation!¶
Indices and tables¶
Coua checks your data items against a certification standard.
Quick Start¶
coua init
coua check
Usage¶
Before Coua can check the data-items, they first need to be be converted into N-Quads (.nq). There are many different tools which can do this using mapping specifications in RML format (RMLMapper, morph-kgc). Coua provides a number of these mappings from the data-item formats in the mappings directory of the source distribution and can use morph-kgc to ingest these files.
Provided mappings for data-item are:
JUnit
Cobertura
Needy
Mantra
Coua trace format
Coua requirements and use-cases
For this to work, your data needs to contain additional N-Triples declaring which data is to be used as DO-178C data items. For the mapped data-items listed above, this information already is declared by Coua. To manually add the items, simply declare rdfs:subClass and rdfs:subProperty relations from your classes and properties to the DO-178C ontology of Coua. See coua/ontologies/junit/junit.ttl for an example.
To configure coua to check your artifacts, create a configuration file containing the configuration for morph-kgc.
mode: Standard to check the project against
artifacts.*.morph: Settings for morph-kgc, each section
# coua.toml
checks = ["do178c"]
[do178c]
software = "https://example.org/my-software"
software_level = "A"
[artifacts.Junit.morph]
file_path = "junit.xml"
mappings = "mappings/junit.ttl"
[artifacts.Cobertura.morph]
file_path = "coverage.xml"
mappings = "mappings/cobertura.ttl"
[artifacts.Traces.morph]
file_path = "traces.json"
mappings = "mappings/traces.ttl"
By default, coua check produces an output file coua.nq containing all the triples used during checking.
Coua also contains a Sphinx extension that you can use to render information from the data-items into a human-readable documentation. The extension contains a set of pre-defined directives for common documentation required by DO-178C. You need to configure the extension so that it knows where to find the data to render. Here we use the same N-Triples from coua.nq as before.
# doc/source/conf.py
extensions = [ "coua" ]
coua_load = [("coua.nq", "application/n-triples")]
You can use the directives inside a reStructuredText document like so
.. coua:source_code_coverage_matrix::
Adding support for new data formats¶
Add a new mapping file to mappings/ that specifies how to ingest the data.
Add a new ontology to coua/ontologies/ that describes the properties and classes of the ingested data.
(optional) In this ontology, specify which classes and properties will be used in queries for DO-178C by using subClass and subProperty.
(optional) Add custom queries for your ontology to coua/ontologies/<your-ontology>/select and coua/ontologies/<your-ontology>/ask. They are available as YourOntology.select() and as part of YourOntology.check() respectively.
Software and associated software level¶
Software |
SWL |
|---|---|
https://dlr.de/ft/ssy/coua |
A |
Check results¶
Check |
Status |
Description |
|---|---|---|
Coua UC check |
passed |
All Use-Cases are covered by at least one requirement. |
DO-178C A-2-1 |
passed |
High-level requirements are developed. |
DO-178C A-2-4 |
passed |
Low-level requirements are developed. |
DO-178C A-3-6 |
passed |
High-level requirements are tracable to system requirements. |
DO-178C A-4-6 |
passed |
Low-level requirements are tracable to high-level requirements. |
DO-178C A-5-1 |
passed |
Source Code complies with low-level requirements. |
DO-178C A-5-5 |
passed |
Source Code is tracable to low-level requirements. |
The following objectives require an independent review:
“DO-178C A-5-1”, “DO-178C A-7-7”
This report is machine-generated and is only binding once signed by a human.
Requirements¶
Req00¶
Level: System Level Requirement
Description: The software is automatically checked for certifiability.
Rationale: Missing
Req01¶
Level: High Level Requirement
Description: The certification framework shall provide a library of functions for ingesting artifacts produced by COTS tools.
Rationale: In a typical Git-based workflow, CI provides automated checks of the software development process and software and tests. The results of these checks are provided in various machine-readable formats.
Traces: Req05
Req02¶
Level: High Level Requirement
Description: The framework shall provide means for describing the interfaces, inputs and outputs of custom COTS tools.
Rationale: Missing
Traces: Req05
Req03¶
Level: High Level Requirement
Description: The certification report shall include all certification objectives and references to all required evidences it has access to.
Rationale: Missing
Traces: Req12
Req04¶
Level: High Level Requirement
Description: While CI is in use, when changes are committed to the SCM, Coua shall generate a certification report.
Rationale: Missing
Traces: Req20
Req05¶
Level: System Level Requirement
Description: Coua shall be able to ingest requirements, evidences, justifications and data-items from artifacts produced by COTS tools.
Rationale: Missing
Req06¶
Level: Low Level Requirement
Description: Coua shall provide means to specify how to obtain artifacts created by other tools.
Rationale: Missing
Traces: Req02
Source Code: parse_artifacts
Req08¶
Level: High Level Requirement
Description: Coua shall provide means to extend the ontologies of generalized standards such as DO-178C to project-specific certification objectives
Rationale: Missing
Traces: Req00
Req09¶
Level: High Level Requirement
Description: Coua shall provide means to identify which objectives were used to perform verification and validation in the certification report.
Rationale: Missing
Traces: Req12
Req10¶
Level: High Level Requirement
Description: Coua shall track the association between artifacts like requirements, test cases, source code and object code (tracing).
Rationale: Missing
Traces: Req00
Req100¶
Level: High Level Requirement
Description: Coua shall provide the current satisfiability of the relevant objectives.
Rationale: Missing
Traces: Req00
Req11¶
Level: High Level Requirement
Description: Coua shall track the association between artifacts and objectives.
Rationale: Missing
Traces: Req00
Req12¶
Level: System Level Requirement
Description: Coua shall generate a certification report.
Rationale: Missing
Traces: Req12
Req13¶
Level: Low Level Requirement
Description: While Coua performs validation activities, if any failing satisfiable objectives are encountered, Coua shall indicate to the CI that its activities have failed.
Rationale: Missing
Traces: Req100
Source Code: check_cmd
Req14¶
Level: Low Level Requirement
Description: While Coua performs validation activities, if any failing unsatisfiable objectives are encountered, Coua shall not indicate that its activities have failed.
Rationale: Missing
Traces: Req100
Req15¶
Level: Low Level Requirement
Description: Coua shall provide a way to mark objectives as unsatisfiable
Rationale: Missing
Traces: Req100
Req16¶
Level: Low Level Requirement
Description: Coua shall provide a way to remove the unsatisfiable mark from objectives.
Rationale: Missing
Traces: Req100
Req17¶
Level: Low Level Requirement
Description: While CI is in use, Coua shall signal failed objectives as errors
Rationale: Missing
Traces: Req100
Source Code: check_cmd
Req18¶
Level: Low Level Requirement
Description: Coua shall ingest artifacts in the Static Analysis Results Interchange Format (SARIF) format.
Rationale: Missing
Traces: Req01
Req19¶
Level: High Level Requirement
Description: Coua shall be executable independently of CI, e.g. locally on a developer’s or tester’s computer
Rationale: Missing
Traces: Req00
Req20¶
Level: System Level Requirement
Description: Coua shall be executable in CI
Rationale: Missing
Req21¶
Level: Low Level Requirement
Description: Coua shall provide means for ingesting artifacts from the local filesystem
Rationale: Missing
Traces: Req01
Source Code: parse_artifacts
Test Cases: test_requirements_property_is_parsed, test_all_subjects_recognized
Req22¶
Level: Low Level Requirement
Description: When Coua produces a certification report, where data from artifacts is used, Coua shall include data about the tools that produced the artifacts.
Rationale: Missing
Traces: Req03
Req23¶
Level: Low Level Requirement
Description: If the ontology contains syntactical errors, then Coua shall refuse to evaluate the ontology and produce a meaningful error message.
Rationale: Missing
Traces: Req01
Req24¶
Level: Low Level Requirement
Description: If an artifact contains syntactical errors, then Coua shall refuse to produce a certification report that includes it and issue a meaningful error message.
Rationale: Missing
Traces: Req01
Req25¶
Level: Low Level Requirement
Description: Coua shall allow for importing requirements data in a Comma Separated Values (CSV) format.
Rationale: Missing
Traces: Req01
Source Code: parse_artifacts
Req26¶
Level: Low Level Requirement
Description: Coua shall specify an ontology for requirements data.
Rationale: Missing
Traces: Req32
Source Code: load_ontologies, CouaOntology, COUA
Req27¶
Level: High Level Requirement
Description: Coua shall allow for defining custom content in the certification report.
Rationale: Missing
Traces: Req12
Req28¶
Level: Low Level Requirement
Description: Coua shall allow a project to run custom queries on the ontologies.
Rationale: Missing
Traces: Req100
Source Code: CheckResult, Ontology
Req29¶
Level: High Level Requirement
Description: Coua shall provide a well-defined output schema for the certification report.
Rationale: Missing
Traces: Req12
Req31¶
Level: High Level Requirement
Description: When a new version of the component is released, the artifact archive shall version and permanently record all software, configuration and non-reproducible artifacts that are required for recreating the certification report for that version.
Rationale: Missing
Traces: Req00
Req32¶
Level: High Level Requirement
Description: The ontologies shall model all necessary knowledge from the certification objectives that specify what is required for certification approval.
Rationale: Missing
Traces: Req00
Req33¶
Level: Low Level Requirement
Description: Coua shall be able to ingest ontologies in the OWL2 format.
Rationale: Missing
Traces: Req02
Source Code: load_ontologies
Req34¶
Level: Low Level Requirement
Description: The certification report shall clearly display which objective is satisfied.
Rationale: Missing
Traces: Req100
Source Code: CouaCheckTable
Req35¶
Level: Low Level Requirement
Description: If the certification report indicates that all objectives are met, Coua shall make it clear that this is not guaranteed.
Rationale: Missing
Traces: Req100
Source Code: CouaDO178CWithIndependence
Req36¶
Level: Low Level Requirement
Description: The certification report shall clearly display whether an objective has regressed.
Rationale: Missing
Traces: Req100
Req37¶
Level: Low Level Requirement
Description: The certification report shall mark failing satisfiable objectives.
Rationale: Missing
Traces: Req100
Source Code: CouaCheckTable
Req38¶
Level: Low Level Requirement
Description: The certification report shall mark not yet satisfiable objectives.
Rationale: Missing
Traces: Req100
Source Code: CouaNotImplemented
Req39¶
Level: Low Level Requirement
Description: When an objective is violated, the certification report shall highlight the precise artifacts that are the source of the violation.
Rationale: Missing
Traces: Req100
Req40¶
Level: Low Level Requirement
Description: The certification report shall be human-readable.
Rationale: Missing
Traces: Req03
Req41¶
Level: Low Level Requirement
Description: The certification report shall be machine-readable.
Rationale: Missing
Traces: Req03
Source Code: run_checks
Req42¶
Level: Low Level Requirement
Description: The certification reports shall have the same contents in both human- and machine- readable forms.
Rationale: Missing
Traces: Req03
Req43¶
Level: Low Level Requirement
Description: The certification report shall include all failed objectives.
Rationale: Missing
Traces: Req100
Source Code: CouaCheckTable
Req44¶
Level: Low Level Requirement
Description: The certification report shall present unsatisfiable objectives less prominently.
Rationale: Missing
Traces: Req100
Req45¶
Level: Low Level Requirement
Description: While the artifacts provide the required information, the certification report shall include all data items and evidences required to build an assurance case.
Rationale: Missing
Traces: Req03
Req46¶
Level: Low Level Requirement
Description: The certification framework shall allow for defining custom content in the rendered certification report.
Rationale: Missing
Traces: Req03
Req47¶
Level: System Level Requirement
Description: Coua shall finish producing the report in a time that allows for fast feedback during development.
Rationale: Missing
Req48¶
Level: System Level Requirement
Description: Coua shall use not more than half of the memory that is available in the CI or in the development requirement.
Rationale: Missing
Req50¶
Level: Low Level Requirement
Description: Coua shall validate if the objectives for certification of the project are satisfied
Rationale: Missing
Traces: Req100
Source Code: run_checks, CheckResults
Req51¶
Level: Low Level Requirement
Description: Coua shall be able to access trace data from mantra.db.
Rationale: Missing
Traces: Req02
Source Code: MantraOntology
Req52¶
Level: High Level Requirement
Description: Coua shall provide its functionality via a command line interface (CLI).
Rationale: Missing
Traces: Req00
Req53¶
Level: Low Level Requirement
Description: Coua shall provide a CLI command to check the objectives.
Rationale: Missing
Traces: Req52
Req54¶
Level: Low Level Requirement
Description: Coua shall provide a CLI command to trace requirements from Python source code.
Rationale: Missing
Traces: Req52
Source Code: run
Req55¶
Level: Low Level Requirement
Description: Coua shall provide a CLI command to initialize a project for use with Coua.
Rationale: Missing
Traces: Req52
Source Code: init_config, init_cmd, run
Req56¶
Level: High Level Requirement
Description: Coua shall be configurable using a configuration file
Rationale: Missing
Traces: Req00
Req57¶
Level: Low Level Requirement
Description: Coua shall allow for configuration of the ontologies to check against.
Rationale: Missing
Traces: Req52
Source Code: parse_config, init_config, check_cmd
Req58¶
Level: Low Level Requirement
Description: Coua shall allow for configuration of the kinds locations and mappings of the data items.
Rationale: Missing
Traces: Req52
Source Code: parse_config, parse_malkoha_output, parse_morph_config, parse_artifacts, infer_mappings, init_config
Req59¶
Level: High Level Requirement
Description: Coua shall provide a plugin that generates documentation about the certifiability status of the software.
Rationale: Missing
Traces: Req00
Req60¶
Level: Low Level Requirement
Description: Coua shall provide a directive that renders a list of requirements.
Rationale: Missing
Traces: Req59
Source Code: CouaDO178CRequirementsList, ref_thing, Requirement, CouaTableDirective, CouaDO178CRequirementsSection
Req61¶
Level: Low Level Requirement
Description: Coua shall provide a directive that renders a tracability matrix.
Rationale: Missing
Traces: Req59
Source Code: CouaDO178CTracabilityMatrix, CouaCrosstabDirective
Req62¶
Level: Low Level Requirement
Description: Coua shall provide a directive that renders a coverage matrix.
Rationale: Missing
Traces: Req59
Source Code: CouaDO178CRequirementsTestCoverageMatrix, CouaCrosstabDirective
Req63¶
Level: Low Level Requirement
Description: Coua shall provide a directive that renders status of each certification objective.
Rationale: Missing
Traces: Req59
Source Code: CouaCheckTable
Req64¶
Level: Low Level Requirement
Description: Coua shall provide the directives as a Sphinx extension.
Rationale: Missing
Traces: Req59
Source Code: setup, CouaDomain
Req65¶
Level: Low Level Requirement
Description: Coua shall use the same data for the checks as for generating the documents.
Rationale: Missing
Traces: Req59
Source Code: load_store
Req66¶
Level: Low Level Requirement
Description: Coua shall provide a directive for rendering use cases and their coverage by high level requirements.
Rationale: Missing
Traces: Req59
Source Code: CouaUseCaseSection, CouaUseCaseCoverageMatrix
Req67¶
Level: Low Level Requirement
Description: Coua shall issue an warning if the input data items have no defined relation to the checked ontology.
Rationale: Missing
Traces: Req100
Source Code: CouaException, check_is_do178c, CoberturaOntology
Req68¶
Level: High Level Requirement
Description: Coua shall provide an ontology for DO-178C.
Rationale: Missing
Traces: Req00
Req69¶
Level: Low Level Requirement
Description: Coua shall provide an ontology for JUnit test reports.
Rationale: Missing
Traces: Req01
Source Code: load_ontologies, JUnit, JunitOntology
Req70¶
Level: Low Level Requirement
Description: Coua shall provide an ontology for cargo-needy trace data.
Rationale: Missing
Traces: Req01
Source Code: MantraOntology, load_ontologies, Mantra
Req71¶
Level: Low Level Requirement
Description: Coua shall provide an ontology for cargo-needy trace data.
Rationale: Missing
Traces: Req01
Source Code: load_ontologies, Needy, NeedyOntology
Req72¶
Level: Low Level Requirement
Description: Coua shall provide an ontology for its own trace format for Python source code.
Rationale: Missing
Traces: Req01
Source Code: load_ontologies, Traces, TracesOntology
Req73¶
Level: Low Level Requirement
Description: Coua shall provide an ontology for its own trace format for Python source code.
Rationale: Missing
Traces: Req01
Source Code: load_ontologies, Cobertura
Req74¶
Level: Low Level Requirement
Description: Coua shall provide a way to only apply the objectives of DO-178C that are required for a given software level.
Rationale: Missing
Traces: Req68
Source Code: DO178COntology
Req75¶
Level: Low Level Requirement
Description: Coua shall provide a way to configure the software level of a software.
Rationale: Missing
Traces: Req68
Source Code: check_cmd, SoftwareLevel
Req76¶
Level: Low Level Requirement
Description: Coua shall apply the configured software level before checks are performed.
Rationale: Missing
Traces: Req68
Source Code: activate_software_level, DO178COntology
Req77¶
Level: Low Level Requirement
Description: Coua shall render the software level as part of the certification report.
Rationale: Missing
Traces: Req68
Source Code: CouaDO178CSoftwareLevelDirective
Req78¶
Level: Low Level Requirement
Description: Coua shall notify the reader of the reviewer that independence is required for an objective.
Rationale: Missing
Traces: Req68
Source Code: CouaDO178CWithIndependence
Req79¶
Level: Low Level Requirement
Description: Coua shall contain a directive that allows the developer to render the list of objectives that require independent review in the report.
Rationale: Missing
Traces: Req68
Source Code: CouaDO178CWithIndependence
Req80¶
Level: Low Level Requirement
Description: Coua shall provide a namespace for DO-178C terms.
Rationale: Missing
Traces: Req68
Source Code: DO178C
Req81¶
Level: Low Level Requirement
Description: Coua shall provide a parser for coverage information in the cobertura format.
Rationale: Missing
Traces: Req01
Source Code: parse_cobertura_output, CoberturaParser
Use cases¶
Check Objectives¶
ID: UC01
Title: Check Objectives
Story: As the certification authority I want to be able to inspect all relevant data and documents for certification so that I can verify that sufficient evidence is provided to show that the certification objectives are completed.
Goal: DLR-SMART1
Scope: Certification Report
Level: User
Actor: Certification Authority
Stakeholder: Vendor | Certification Authority
Trigger: The certification liaison process enters a new iteration.
Pre: The Software Accomplishment Summary is created by the CI.
Flow: The vendor prepares the certification report along with all supporting materials. | The certification authority reviews the materials and determines compliance. | The certification authority submits their findings to the vendor. | The certification authority obtains the report along with the supporting materials from the vendor.
Post: The certification authority can determine which objectives are not completed. | The certification authority can determine that all objectives are completed.
Extension: As a vendor I want the report to clearly state if all objectives are met so that I can determine when the report is ready to be handed in to the CA.
Continuous Testing¶
ID: UC02
Title: Continuous Testing
Story: As a software developer I want the CI to check the progress towards the certification objectives so that I can prevent regressions and assess the effectiveness of my attempts to make progress towards the objectives.
Goal: DLR-SMART2
Scope: Certification Report
Level: User
Actor: Developer
Stakeholder: Developer | Tester
Trigger: A developer submits code or documents to the SCM.
Pre: Transformations for creating evidences from the artifacts are available. | The projects defines which evidence to use for which objective. | The CI produces or discovers artifacts that can be used for generating evidence towards the certification objectives, such as trace-data, test-results, requirements, coverage data.
Flow: The CI runs the certification framework, producing a certification report.
Post: The CI indicates the progress towards each objective and which change produces a regression.
Extension: As a reviewer I want to check the certification status before accepting changes to the software so that no regressions from the certification objectives are made when applying a change.
Retrieve Artifact¶
ID: UC03
Title: Retrieve Artifact
Story: As the vendor I want to retrieve or reproduce the software, configuration, required build environment, test environment, artifacts, evidences and certification progress during any point during any iteration of the software life cycle so that I can trace defective changes and make corrective changes to previous versions.
Goal: DLR-SMART2
Scope: ADF
Level: System
Actor: System Integrator
Stakeholder: Developer | Systems Integrator
Trigger: A change of the software, its requirements or its configuration items is accepted.
Pre: All changes to the software, configuration and non-reproducible artifacts that represent the state of the project at a given time during the software lifecycle are versioned and permanently recorded.
Flow: The developer or systems integrator reproducibly recreates or retrieves all artifacts. | The developer or systems integrator makes a checkout of the revision in question from the SCM.
Post: The results from running the certification framework to evaluate the objectives is identical to previous runs using the same revision. | The artifacts are identical to the artifacts that were previously created using the revision.
Extension: As a software developer or systems integrator I want to reproduce a previous state of the integrated software to reproduce a situation in which a fault occurs so that I can identify the defective change.
Use COTS Tools¶
ID: UC04
Title: Use COTS Tools
Story: As a developer I want to use artifacts provided by my existing tooling as inputs for the certification framework so that I can check my certification progress.
Goal: DLR-SMART3
Scope: TDF
Level: User
Actor: Developer
Stakeholder: Developer | Reviewer
Trigger: An output of a COTS tool is to be used as an input for the certification framework.
Pre: The certification framework provides a means for describing how artifacts are created by custom tools. | The certification framework provides ingestion methods for some pre-defined artifact types.
Flow: The developer defines which artifact type the artifact has using the ADF and the tool which creates the artifact type using the TDF.
Post: The definitions are used by the certification framework to discover or create the artifacts and ingest them.
Extension: As a developer, I want the certification framework to provide default definitions for some tools, so that I don’t have to provide my own.
Shared Reality¶
ID: UC05
Title: Shared Reality
Story: As a developer I want the certification framework to produce the same results every time I give it the same inputs as someone else so that everyone has a shared reality of the current certification status of the project.
Goal: DLR-SMART3
Scope: ADF
Level: System
Actor: Developer
Stakeholder: Developer | Reviewer | Certification Authority
Trigger: The certification status is queried by a stakeholder.
Pre: The project’s artifacts are reproducible in a way that they do not change if they are created twice from the same data.
Flow: All stakeholders run the certification framework using the same version of the artifacts. | The artifacts are reproducibly retrieved or created.
Post: All stakeholders get the same certification results.
Extension: As the certification authority I want to inspect the identical report as the developer so that I am sure to certify the right revision of the product.
Defining Ontologies¶
ID: UC06
Title: Defining Ontologies
Story: As the vendor I want to define my own extensions to the certification objectives to check additional or adapted objectives so that I can adapt my processes to the requirements of the CA.
Goal: DLR-SMART2
Scope: Ontologies
Level: User
Actor: Vendor
Stakeholder: Vendor
Trigger: The CA requires that an objective or requirement that is not explicitly specified by an ontology for an existing regulation is added.
Pre: The certification framework defines ontology classes for objectives, data-items, evidences and other outputs.
Flow: The vendor adds definitions for the objectives including what inputs are needed to evaluate them.
Post: The objective is related to other objectives and evaluated by the certification framework using the artifacts.
Extension: As the certification authority I want to have a mechanised description of the objective and its inputs to have a common and definite language with the vendor.
Tracking Artifact Dependencies¶
ID: UC07
Title: Tracking Artifact Dependencies
Story: As the vendor I want to track down why an objective is not completed so that I can take appropriate action.
Goal: DLR-SMART2
Scope: ADF
Level: User
Actor: Vendor
Stakeholder: Developer | Vendor | Certification Authority
Trigger: Changes are made to the product.
Pre: An ontology links objectives to input and output artifacts. | The inputs and outputs are tracable onto each other if there is a relationship between them and this relationship is expressed in the ontology.
Flow: The certification framework evaluates the relationships between the inputs and outputs and traces them back to objectives. | The relationship is displayed as part of the certification report.
Post: An incomplete objective is detected by tracing the defect from individual artifacts to one or more objectives.
Extension: As the CA I want to inspect the report to verify that each objective has been completed.
Tracing¶
ID: UC08
Title: Tracing
Story: As a developer I want to track the contents of artifacts like requirements, test cases, source code and object code onto each other so that I can use the tracing as a data-item.
Goal: DLR-SMART3
Scope: ADF
Level: User
Actor: Software Developer
Stakeholder: Developer | Reviewer
Trigger: A new artifact is added.
Pre: The artifact types that should be traced are modeled using the ADF.
Flow: The certification framework understands the defition and can use the contents of the artifacts for tracing. | The developer uses an existing class defintion or creates a new class definition for the ADF inside an ontology. | The developer declares that a specific artifact is of that type.
Post: The report shows the tracing between the artifacts.
Extension: As the certification authority I want to inspect the report to verify that sufficient coverage of requirements, source and object code exists.
Machine-Readable Certification Report¶
ID: UC09
Title: Machine-Readable Certification Report
Story: As a developer I want the certification report to be machine-readable so that it be processed by additional tools.
Goal: DLR-SMART2
Scope: Certification Report
Level: User
Actor: Developer
Stakeholder: Developer
Trigger: The certification report is created.
Pre: The certification report is generated in a standardized format.
Flow: The certification report data is created and serialized in the standardized format.
Post: The report data is displayed by the COTS tools.
Extension: As the vendor, I want to archive the report data to make historical data of my product searchable.
Incremental Certification¶
ID: UC10
Title: Incremental Certification
Story: As a developer, during development, I want to be able to mark objectives which have not yet been worked on as not achievable, so that I can focus on the progress of the objective(s) I am working on.
Goal: DLR-SMART10
Scope: Certification Report
Level: User
Actor: Developer
Stakeholder: Developer | Reviewer | Vendor
Trigger: An objective that is currently not completed, but is planned to be completed in the future.
Pre: The list of objectives for a project is known.
Flow: The developer marks the objective as not achievable using the manifest file.
Post: The certification framework reports the failures of objectives, but the failures of marked objectives are featured less prominently.
Extension: As a developer, I want to remove the marker from the objective I am working on so that I am notified of regressions.
Source Code Tracability Matrix¶
Req06 |
Req13 |
Req17 |
Req21 |
Req25 |
Req26 |
Req28 |
Req33 |
Req34 |
Req35 |
Req37 |
Req38 |
Req41 |
Req43 |
Req50 |
Req51 |
Req53 |
Req54 |
Req55 |
Req57 |
Req58 |
Req60 |
Req61 |
Req62 |
Req63 |
Req64 |
Req65 |
Req66 |
Req67 |
Req69 |
Req70 |
Req71 |
Req72 |
Req73 |
Req74 |
Req75 |
Req76 |
Req77 |
Req78 |
Req79 |
Req80 |
Req81 |
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
COUA |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CheckResult |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CheckResults |
✓ |
|||||||||||||||||||||||||||||||||||||||||
Cobertura |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CoberturaOntology |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CoberturaParser |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaCheckTable |
✓ |
✓ |
✓ |
✓ |
||||||||||||||||||||||||||||||||||||||
CouaCrosstabDirective |
✓ |
✓ |
||||||||||||||||||||||||||||||||||||||||
CouaDO178CRequirementsList |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaDO178CRequirementsSection |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaDO178CRequirementsTestCoverageMatrix |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaDO178CSoftwareLevelDirective |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaDO178CTracabilityMatrix |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaDO178CWithIndependence |
✓ |
✓ |
✓ |
|||||||||||||||||||||||||||||||||||||||
CouaDomain |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaException |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaNotImplemented |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaOntology |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaTableDirective |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaUseCaseCoverageMatrix |
✓ |
|||||||||||||||||||||||||||||||||||||||||
CouaUseCaseSection |
✓ |
|||||||||||||||||||||||||||||||||||||||||
DO178C |
✓ |
|||||||||||||||||||||||||||||||||||||||||
DO178COntology |
✓ |
✓ |
||||||||||||||||||||||||||||||||||||||||
JUnit |
✓ |
|||||||||||||||||||||||||||||||||||||||||
JunitOntology |
✓ |
|||||||||||||||||||||||||||||||||||||||||
Mantra |
✓ |
|||||||||||||||||||||||||||||||||||||||||
MantraOntology |
✓ |
✓ |
||||||||||||||||||||||||||||||||||||||||
Needy |
✓ |
|||||||||||||||||||||||||||||||||||||||||
NeedyOntology |
✓ |
|||||||||||||||||||||||||||||||||||||||||
Ontology |
✓ |
|||||||||||||||||||||||||||||||||||||||||
Requirement |
✓ |
|||||||||||||||||||||||||||||||||||||||||
SoftwareLevel |
✓ |
|||||||||||||||||||||||||||||||||||||||||
Traces |
✓ |
|||||||||||||||||||||||||||||||||||||||||
TracesOntology |
✓ |
|||||||||||||||||||||||||||||||||||||||||
activate_software_level |
✓ |
|||||||||||||||||||||||||||||||||||||||||
check_cmd |
✓ |
✓ |
✓ |
✓ |
✓ |
|||||||||||||||||||||||||||||||||||||
check_is_do178c |
✓ |
|||||||||||||||||||||||||||||||||||||||||
infer_mappings |
✓ |
|||||||||||||||||||||||||||||||||||||||||
init_cmd |
✓ |
|||||||||||||||||||||||||||||||||||||||||
init_config |
✓ |
✓ |
✓ |
|||||||||||||||||||||||||||||||||||||||
load_ontologies |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
|||||||||||||||||||||||||||||||||||
load_store |
✓ |
|||||||||||||||||||||||||||||||||||||||||
parse_artifacts |
✓ |
✓ |
✓ |
✓ |
||||||||||||||||||||||||||||||||||||||
parse_cobertura_output |
✓ |
|||||||||||||||||||||||||||||||||||||||||
parse_config |
✓ |
✓ |
||||||||||||||||||||||||||||||||||||||||
parse_malkoha_output |
✓ |
|||||||||||||||||||||||||||||||||||||||||
parse_morph_config |
✓ |
|||||||||||||||||||||||||||||||||||||||||
ref_thing |
✓ |
|||||||||||||||||||||||||||||||||||||||||
run |
✓ |
✓ |
✓ |
|||||||||||||||||||||||||||||||||||||||
run_checks |
✓ |
✓ |
||||||||||||||||||||||||||||||||||||||||
setup |
✓ |
Requirements Test Coverage Matrix¶
Req21 |
|
|---|---|
https://llg.cubic.org/docs/junit#testcase/test_all_subjects_recognized |
✓ |
https://llg.cubic.org/docs/junit#testcase/test_requirements_property_is_parsed |
✓ |
Use-Cases Coverage Matrix¶
Low-Level Requirements not yet implemented¶
ID |
Description |
|---|---|
Req14 |
While Coua performs validation activities, if any failing unsatisfiable objectives are encountered, Coua shall not indicate that its activities have failed. |
Req15 |
Coua shall provide a way to mark objectives as unsatisfiable |
Req16 |
Coua shall provide a way to remove the unsatisfiable mark from objectives. |
Req18 |
Coua shall ingest artifacts in the Static Analysis Results Interchange Format (SARIF) format. |
Req22 |
When Coua produces a certification report, where data from artifacts is used, Coua shall include data about the tools that produced the artifacts. |
Req23 |
If the ontology contains syntactical errors, then Coua shall refuse to evaluate the ontology and produce a meaningful error message. |
Req24 |
If an artifact contains syntactical errors, then Coua shall refuse to produce a certification report that includes it and issue a meaningful error message. |
Req27 |
Coua shall allow for defining custom content in the certification report. |
Req29 |
Coua shall provide a well-defined output schema for the certification report. |
Req36 |
The certification report shall clearly display whether an objective has regressed. |
Req39 |
When an objective is violated, the certification report shall highlight the precise artifacts that are the source of the violation. |
Req40 |
The certification report shall be human-readable. |
Req42 |
The certification reports shall have the same contents in both human- and machine- readable forms. |
Req44 |
The certification report shall present unsatisfiable objectives less prominently. |
Req45 |
While the artifacts provide the required information, the certification report shall include all data items and evidences required to build an assurance case. |
Req46 |
The certification framework shall allow for defining custom content in the rendered certification report. |
Req47 |
Coua shall finish producing the report in a time that allows for fast feedback during development. |
Req48 |
Coua shall use not more than half of the memory that is available in the CI or in the development requirement. |