Version History

Value Propositions

Governments, the priority users of GovSpecs, shall be able to improve the following:

1. Architecture: Planing of a system architecture and its software components

2. Building Block Scope: Scoping and gathering of functional requirements of software components

3. National Interoperability: Standardizing interface requirements to improve technical interoperability

4. International Interoperability: Follow GovStack’s recommendations to join international interoperability agreement and therefore enable cross-border use cases

5. AI-Readiness (new with GovSpecs Strategy 2.0): Let AI consume Building Block API endpoints to customize citizen services using Building Blocks

These value propositions are especially true if scope of software component = scope of GovStack Building Block

For value proposition 1, GovStack offers in its specifications the “Architecture and Nonfunctional Requirements” for overall system architecture planning as well as for each Building Block a high-level “Description” to identify the software components which scope resembles GovStack Building Blocks.

For value proposition 2, GovStack offers in its specifications “Key Digital Functionalities”, “Functional Requirements”, “Data Structures” and individually additional chapters to define the functional scope of a Building Block in a planned system architecture.

For value proposition 3 and 4, GovStack offers in its specifications architectural “cross-cutting requirements” as well as “Service API” to improve technical interoperability between software components and Building Blocks.

Open

Simple Visualisation of GovSpec Value Proposition

Business Requirements in Spec Development

The above mentioned value propositions are generated by the working groups who derive technical specifications from business requirements:

1. Exemplary use cases/government services https://govstack-global.atlassian.net/wiki/spaces/GH/pages/1165295619

2. Organisational realities in governments https://govstack-global.atlassian.net/wiki/spaces/GH/pages/1188134920/Organisational+Requirements?atlOrigin=eyJpIjoiNmU0NGU5NTM0MWI0NGJlZDhkMWMzYWFiMTkzMGJhNjgiLCJwIjoiYyJ9 (resulting in e.g. distributed system, see IM BB; Tenant-Function, see CMS BB)

3. Openness to common policies (e.g. EU or Indian ID Policies)

   1. Requirements shall not aim for technical compatibility with specific national or regional policies

   2. Instead, requirements shall only describe a state where an implementation compliant to every considered policies is still possible

4. Universal Declaration of Human Rights and https://www.dpi-safeguards.org/

The commonalities (or lowest common denominator) of these business dimensions shall be taken.

These common business requirements inform the 1) technical requirements and 2) its requirement status/priority:

• REQUIRED = Minimum Viable Product (can serve citizens with the minimal functionalities)

• RECOMMENDED = Recommended functional scope

Software Market Requirements in Spec Development

The above mentioned value propositions are only valid with actual software applications fulfilling the functional scope of Building Blocks. In addition, the value propositions are improved by software applications not fulfilling the functional scope but by being ready for integration.

1. Building Block Software https://govstack-global.atlassian.net/wiki/spaces/GH/pages/76906515

2. Integration-ready software https://govstack-global.atlassian.net/wiki/spaces/GH/pages/1052868638

The affiliation to one of the categories above is measured in GovStack as “compliance”. For definition of the term, see https://pubs.opengroup.org/togaf-standard/ea-capability-and-governance/chap06.html

For Building Block software, the compliance is measured against the individually listed requirements and its priority/status. The REQUIRED scope of a Building Block Specification MUST at least be fulfilled by 2 different software applications on the market.

For integration-ready software, the compliance is measured against the [to be defined] These are software components which are not matching the REQUIRED scope of Building Blocks. Often times, they are sector-specific (monolithic) software components for which the software providers would like to state a readiness to be integrated on the edges of a GovStack architecture.