Software Compliance Concept
Version
Version | Changes | Author |
|---|---|---|
v2.1 | Added treatment of auditability classifier Added testing journey and test modes chapter | @Nico Lueck |
v2.0 | New compliance concept according to v2.0 release of architecture specifications + migration concept | @Nico Lueck |
v1.0 | Deleted KDF requirements from Requirement Specification Compliance and changed thresholds to 50/90% Changed name of Interface Compliance to API Compliance | @Steve Conrad @Nico Lueck |
v0.3 | Level 1 and Level 2 Compliance in different sub-categories | @Nico Lueck |
v0.2 | Categories of Partially and Fully Compliant | @Nico Lueck |
v0.1 | Categories of Compatibility and Compliance | @Nico Lueck |
Terminology
“Adapter” is a software component transponse data (e.g. HL7 2.5/3.0 <-> JSON Schema) and protocols (e.g. SOAP <-> REST). See also Architecture Specifications: https://govstack.gitbook.io/specification/architecture-and-nonfunctional-requirements/6-onboarding#6.1-adapters
Do not use “product” for “software” because of the risk of confusion with “GovStack products”
Do not use “Building Blocks” for “software” because it is also used to describe the functional scope/the specification, not the software.
Value Proposition
For governments, esp. procurers and implementation teams, the compliance check provides information for market research, software selection and market offerings to certain requirements (esp. Requirement Specification Compliance)
For software providers, the compliance check enables a transparent demonstration of software functionalities and technical alignment with BB specifications.
Compliance Testing Journey
Software provider informs itself about value proposition, procedure and compliance criteria on govstack.global
Software provider visits GovStack’s testing app and opens a draft compliance report
Software provider enters metadata about software (name, version, website etc.)
Software provider selects BBs and it’s version to test against (not selecting any BB is possible)
Software provider sees an status of compliance against all CFR + selected BBs (status overview at 0%)
Software provider selects one REQUIRED or RECOMMENDED requirement and follows the procedure according to the classifier,
Sub steps according to classifier see next chapter Compliance Testing Modes
Software provider submits the draft compliance report
GovStack team receives compliance report and checks all answers for completeness, optionally involves the working group to validate specific answers (esp. for operationally observable or auditable requirements)
GovStack team contacts software provider for potential clarifications or additional information
GovStack team approves or rejects compliance report
GovStack team published approved compliance reports on the testing app and govstack.global
GovStack team includes software provider in any upcoming visibility and engagement opportunities
Compliance Concept (migration in 2026)
The concept is based on the new classifier of observable and auditable requirements: https://specs.govstack.global/architecture/5-specification-framework/5.3-requirements-model#id-5.3.4-observability-classifiers
Compliance Categories
Integration Compliance (for BB and non-BB candidates) | Functional BB Compliance (Integration Compliance is prerequisite) |
|---|---|
100% REQUIRED OBSERVABLE & AUDITABLE architecture cross-functional requirements | 100% REQUIRED OBSERVABLE & AUDITABLE architecture cross-functional requirements |
X % of RECOMMENDED OBSERVABLE & AUDITABLE architecture cross-functional requirements | X % of RECOMMENDED OBSERVABLE & AUDITABLE architecture cross-functional requirements |
| 100% of REQUIRED OBSERVABLE & AUDITABLE cross-functional BB requirements |
| 100% of REQUIRED OBSERVABLE & AUDITABLE functional requirements of at least one Key Functionality (“KDF”) |
| X % of RECOMMENDED OBSERVABLE & AUDITABLE cross-functional and functional requirements |
Compliance Testing Modes
Observability Classifier | Test and validation procedure | Fall-back mode |
|---|---|---|
Observable Automatically testable |
| If test case does not exist, operationally observable procedure applies. |
Observable Manually testable |
| If test case does not exist, operationally observable procedure applies. |
Observable Operationally observable |
| No fall-back mode |
Auditable |
| No fall-back mode |
In the future, we aim to automatically validate operationally observable and auditable requirements as well.
Migration from Legacy to New Concept
The publication of Architecture and Non-Functional Specification 2.0.0 include major changes for how requirements are written and how software shall be tested against them. The changes in compliance measurement require another web application to be provided. Such a major change will be done step-by-step.
Migration Phase | Architecture Specs | Building Block Specs | Compliance Test |
|---|---|---|---|
Phase 1: Propagation of new format active | v2.X released | Not updated | Legacy Testing still valid |
Phase 2: Testability of CFR | v2.X released | Not updated | Testing against CFR 2.0 available + legacy testing |
Phase 3: Testability for BBs | v2.X released | Partially updated | Testing against CFR 2.0 and BB CFR+FR with occasional fall back mode available (+ legacy testing for not updated BBs) |
Phase 4: Ideal state of specs + test case maturity | v2.X released | Fully updated | Testing against CFR 2.0 and BB CFR+FR without fall back mode available |
Legacy Concept
Stages of Compliance
Title | GovStack Candidate Software | Non-compliant Software | Level 1 Compliance | Level 2 Compliance |
|---|---|---|---|---|
Def | Software that is potentially compliant | Software that does not fulfill Level 1 criteria of either Deployment, Integration or Requirement Specification Compliance. | Software requires considerable integration efforts. Software is partially aligned with the GovStack BB Specifications. All integration scenarios possible. | Software requires minimal integration efforts, if GovStack infrastructure and CI recommendation are followed. Software is highly aligned with the GovStack BB Specifications. All integration scenarios possible. |
Categories of Compliance
Deployment Compliance
Level 1 | Level 2 |
|---|---|
Must be deployable via container | To be defined (e.g. provide deployment and configuration scripts (Helm Chart in Kubernetes), run smoke tests ) |
|
|
API Compliance
Level 1 | Level 2 |
|---|---|
Fulfillment of at least one Service API (via adapter or native support) | Fulfillment of all of the Service APIs (via adapter or native support) |
| Fulfillment of all REQUIRED API related requirements in the Architecture BB specifications (ch. 5.1-5.4, 5.6, 5.13) |
Fulfillment of APIs can be tested using the provided test harness, see https://govstack-global.atlassian.net/wiki/spaces/GH/pages/221085697
Requirement Specification Compliance
Level 1 | Level 2 |
|---|---|
Fulfillment of at least 50% of the REQUIRED functional requirements stated in the respective BB specifications | Fulfillment of at least 90% of the REQUIRED functional requirements stated in the respective BB specifications |
Fulfillment of at least 50% of the REQUIRED cross-cutting requirements stated in the respective BB specifications | Fulfillment of at least 90% of the REQUIRED cross-cutting requirements stated in the respective BB specifications |
Evaluation Schema
Category | Criterion | Level 1 | Level 2 |
|---|---|---|---|
Deployment Compliance | Deployability via container |
| N/A |
API Compliance | Fulfillment of Service API requirements | >=1 | All |
| Fulfillment of REQUIRED API related requirements in the Architecture BB specifications (ch. 5.1-5.4, 5.6, 5.13) | Optional | All |
Requirement Specification Compliance | Fulfillment of REQUIRED cross-cutting requirements stated in the respective BB specifications | >50% | >90% |
| Fulfillment of REQUIRED functional requirements stated in the respective BB specifications | >50% | >90% |
Process
https://govstack-global.atlassian.net/wiki/spaces/GH/pages/256835595
Not Part of Compliance Concept/Process
Security, data privacy or code audits performed by GovStack
Providing developer resources to adapt solution to pass certain criteria
Overview list of manual compliance evaluations
Other Considerations
For any considerations taken in developing the concept and remarks for future additions to the concept, please have a look at https://govstack-global.atlassian.net/wiki/spaces/GH/pages/217284665