Functional Scope of the Sandbox

Persona: “Policy Decision Maker” (Government, non-technical)

• HIGH I want to experience an (LOW end-to-end) use case (e.g. from new-born child registration to healthcare provision) so that I can understand the complexity of the complete business logic and usage of BB throughout the whole process.

• NEW HIGH I (Service designers) want to experience exemplar digital services designed based on user needs, user journeys and life events, enabled using reusable software components, generic workflows (web/voice flows), and UX/UI best practices (responsive design & accessibility).

• NEW HIGH I want to experience important BB functionalities (BB scenarios), without being embedded in sectoral use cases, so that I can test the same standard process (e.g. issuing a new ID) with multiple BB candidates

• HIGH I want to be guided in and around the sandbox itself for demonstration purposes so that I can get the full technical and non-technical picture without specific domain knowledge.

• HIGH I want to see the BB interaction while clicking through a use case so that I can understand the distributed BB approach and combination of BB.

• HIGH I want to see the interaction between users (e.g. Citizen and civil servant) so that I can imagine the interaction between citizens of my country and my ministry employees.

• HIGH I want to click through sector-diverse use cases with calling out used workflows (semi-generic) and used BB (generic) so that I can understand the conceptual abstraction layers of the SDG Digital Investment Framework.

• MEDIUM I want to be informed about reuse of workflows among offered use cases in the sandbox so that I can understand dependencies between use cases.

• MEDIUM I want to access resources that proof the usage of the GovStack Implementation Playbook when prototyping the shown use case/services by the GovStack team (e.g. documentation after each step) so that I see proof of the theoretical framework.

• MEDIUM I want to experience BB-based use case without any access barrier (login, deployment time, different credentials for user groups e.g. switching between citizen and civil servant view) so that I do not lose attention and can access without tech experience.

• MEDIUM I want to see the assumptions and framework conditions (e.g. organizational setup) the use cases/sandbox is based on so that I can compare it with the conditions in my country.

• LOW I want to see that the system is restricted and designed for different user groups (citizen, admin, civil servant) so that I see security and user management/rights being addressed.

• SELECTION PROCESS I want to click through use cases and used common workflows that are of high importance for my country so that I can convince my colleagues/superiors.

• LOW I want to see what happens if a Government does not use the BB approach so that I can see benefits of the approach.

Persona: “Maintainer at Government” (Government, technical)

• HIGH I want to deploy the sandbox with different BB candidates so that I can experience the interchangeability of software components.

• HIGH As an IT expert in a Ghanian ministry/contracted IT consultant I want to be able to select for each BB 1 out of 3 Govstack-Compliant applications and deploy them with a particular use-case configuration so that I can understand Govstack interoperability concept and consider using the architecture and methodology in my own digital transformation. (Owner: Taylor Downs )

• HIGH I want to test the performance and other metrics (e.g. latency, network speed, response time, compression, carbon footprint) so that I can evaluate the potential usage of the architecture.

• HIGH I want to read an up-to-date documentation (technology stack, licenses, architecture diagram,…) so that I can inform myself about details of use software and architecture.

• HIGH I want to experience accessibility and UX so that I can assess the usability for my target group.

• MEDIUM I want to create self-hosted instance of the sandbox so that I can analyze the system in a safe environment

• MEDIUM I want to be able to access and change source code or any other aspect in a safe environment, so that I can showcase a customized deployment to my colleagues/superiors.

• MEDIUM I want to get a blueprint for DevSecOps environment so that I can build up my own BB-based system.

• MEDIUM I want to see the infrastructure performance requirements that is needed to assess the sustainability of the BB based approach.

• MEDIUM I want to check the administration and maintainability concept so that I can evaluate the potentially needed Maintenace efforts.

• LOW I want to save my custom sandbox deployment so that I can continue working with it another time.

• LOW I want to change API so that I can test integration with the test environment of my country.

• LOW I want to get security recommendations on how to set up such an environment so that I can build a secure testing ground for my country's systems.

Persona: “CEO / Entrepreneur” (of a company supplying a BB candidate, technical)

• MEDIUM I want to run functional and API requirements-based test scripts (and possibly other compliance checks, see status of compliance concept) so that I can proof compliance of my software product.

• MEDIUM I want to deploy a sandbox instance with my BB candidate so that I can advertise my product as a possible component of the GovStack BB-based system.

• LOW I want to see how my organization can suggest my BB candidate to be integrated into the GovStack sandbox so that I can showcase our spec-compliant software product.

Requirements with abbreviations are taken from the ToR

Automated Testing Requirements

HIGH Usage of the existing BB repo structures, sketched out here: Sandbox Procurement and Tech Committee Overlap
LOW TSTA.1 Automated test scheduling, executing and reporting shall be manageable in a central, multi-user environment.
MEDIUM TSTA.2 Automated tests shall be reusable and customizable in order to run in different environments and by different GovStack implementing actors.
MEDIUM TSTA.3 Automated tests shall follow a unified reporting and monitoring.

Manual Testing Requirements

LOW TSTM.1 Guides shall describe user scenarios which cover as much functional
requirements as possible.
LOW TSTM.2 Guides shall include adversarial scenarios for basic security testing.

Quality Requirements

MEDIUM QLTY.1 Accessibility: Use case frontends shall be usable by people with disabilities by “direct access” (i.e. unassisted) and "indirect access" meaning compatibility with a person's assistive technology.
HIGH QLTY.2 Compatibility: User interfaces shall be compatible to end user devices with latest versions of Microsoft Edge, Google Chrome, Mozilla Firefox and Apple
Safari browsers.
HIGH QLTY.3 Customizability: The system shall be flexible to add new use cases.
HIGH QLTY.4 Interchangeability: The system shall enable software products which act as building block implementations to be added or interchanged with other
software products.
HIGH QLTY.5 Interoperability: The system shall use open standards for all internal or external interfaces.
HIGH QLTY.6 Maintainability: The system shall be open for corrective, adaptive, perfective and preventive changes during the whole software life cycle.
HIGH QLTY.7 Open: The system shall use open standard, built on open-source software (where possible), support open development, use cloud-native standards and be publicly available (see also chapter on open source licences).
MEDIUM QLTY.8 Reliability: The system shall maintain reliability when scaled in real world use cases.
HIGH QLTY.9 Reproducibility/replicability: The system shall be easily replicable by other actors (e.g. implementing governments) through the means of documentation and providing DevSecOps guidance.
HIGH QLTY.10 Reusability: The System and its artifacts shall be developed to be reusable by other actors (e.g. published code, containers, testing suits, UI designs).
HIGH QLTY.11 Robustness: The system shall be able to perform with low bandwidth and
unreliable connectivity (act as a best practice reference to low-resource
environments).
HIGH QLTY.12 Testability: The system shall be (automatically) testable and validatable.
HIGH QLTY.13 Responsive: User interfaces adapt to screen size and allow displaying on mobile or kiosk devices.

Hosting Requirements

HIGH HOST.1 Scope: All components of the sandbox including information mediator building blocks, synthetic data storage and use cases, excluding all other interfacing building blocks, excluding procured foundational BB or BB provided by partnerships shall be hosted by the contractor.
MEDIUM HOST.2 Minimum types of environments: Integration, Staging and Production
HIGH HOST.3 Cloud based: The system shall run on a cloud-based infrastructure.
HIGH HOST.4 Provider agnostic: The setup shall be easily replicable on other cloud platforms to meet our principle of being neutral and generic (cloud native).
HIGH HOST.5 Availability: The system’s uptime shall be above 99.00% (max. of 7.31 hours downtime a month).
MEDIUM HOST.6 Recoverability: The system shall be subject of continuous back-up routine and a well-defined disaster-recovery process.
HIGH HOST.7 ISO27001 compliance: The hosting provider shall be certified under
ISO27001.
HOST.8 SOC 2 and 3 compliance: The hosting provider shall be certified under SOC and 3.

Synthetic data requirements

HIGH DATA.1 Use case relevant: The data shall comprise all use case relevant properties.
LOW DATA.2 Citizen representative: The data shall replicate all important statistical properties of real data.
HIGH DATA.3 No attribution: The data shall be fully synthetic which make identification of any single unit impossible. At the same time all variables are still fully available.

DevSecOps Environment

HIGH Contribute to and use deployment and configuration scripts of the BB repos, sketched out here: Sandbox Procurement and Tech Committee Overlap

HIGH WP_2.1 … use Open Container Initiative (OCI) compliant containers and Cloud Native Computing Foundation (CNCF) certified Kubernetes
HIGH WP_2.2 ... host in any general-purpose public/ private cloud, or multi-tenant environments, as well as in disconnected and classified
environments.
HIGH WP_2.3 … for automating the development and deployment activities as much as possible
MEDIUM WP_2.4 … support all the activities throughout the full DevSecOps lifecycle.
MEDIUM WP_2.5 CI/CD Orchestrator as the central automation engine of the CI/CD pipeline for managing the pipeline creation, modification, execution, and termination.
HIGH WP_2.6 Documentation and other assets for reuse of the GovStack
DevSecOps software factory by other actors.

MEDIUM DEV.1 Citizen-centric: Design is centered around typical high-priority user journeys and use cases related to the SDGs. Ideally, citizens are involved at certain stages of the development cycle.
HIGH DEV.2 Generic: No single/exclusive methodological product or supporting software product is required.
HIGH DEV.3 Standard-based: Captured and guided by industry-recognized standards.
HIGH DEV.4 Open: Published under open source or creative commons licence (see chapter 3.3.7).
HIGH DEV.5 Reusable: Reusable by other actors (e.g. implementing governments) to setup an own instance of the sandbox or implement the GovStack approach.
HIGH DEV.6 Agile: Quick and short cycles to setup, test and validate the sandbox/GovStack implementation and then go for the next iteration.
MEDIUM DEV.7 Efficient: Incorporating security checks while maintaining deployment speed (through e.g. automate security gates).
MEDIUM DEV.8 Security: Incorporate measures/steps in DevSecOps approach to increase security (also known as DevSecOps). Use supporting tools to scan for
dependencies and perform static code analysis (e.g. Snyk, SonarQube or
similar).
HIGH DEV.9 Documented: Document crucial activities, customizations, configurations or code (using documentation generated from the code, through e.g. docbook, asciidoc or similar)
HIGH DEV.10 Integrated: In case of the GovStack sandbox implementation, usage of tools the GovStack Community is already working with: Gitlab and Gitbook.