Cross-functional Requirement team meeting - 30/01/2023

Owned by Steve Conrad
Last updated: Jan 30, 2023
2 min read

Agenda:

  • Review of existing non-functional requirements and security requirements documents

  • Decide on scope of work for Phase 1 (Feb-March)

  • Define and divide tasks for first sprint, populate backlog

  • Plan meeting cadence and how we want to work

 

Links:

Current non-functional requirements document: Architecture and Nonfunctional Requirements | GovStack Specification

Current security requirements document: Security Requirements | GovStack Specification

 

Notes:

Meelis: mandatory requirements are hard to define - they are constantly evolving. One approach would be to have a few mandatory requirements - not too many that would make it hard to track and comply.

Participants don’t have much bandwidth to rework. Can take time to review.

Set goals for why these requirements are important. For country engagement and implementation, as well as for compliance with DPGs.

Questions:

How should the documents be structured - separate non-functional and security requirements?

  • Non-functional requirements could be focused on what a DPG needs to do - getting things up and running and becoming compliant. Baseline for new and existing products.

  • Security requirements could be oriented around implementations - a second phase to ensure best practices for a secure deployment.

Security - 3 phases:

  • Foundational - how we think about security in our design

  • Implementation - how are we building our products securely

  • Deployment - how are we creating a secure system as we deploy

Security certification

  • Is there some kind of certification for security? How do we ensure and build trust in the framework

  • How can we define in-built security? How can vendors validate the code that they have built. Can they provide some kind of documentation on process.

Non-functional requirements:

  1. Show what a product needs to do to become part of a GovStack (look at the 3 phases the Uwe developed)

  2. Small list of mandatory requirements - REST, Docker, webhooks, etc. Perhaps different/expanded requirements for each different phase.

Non-functional requirements should define what an adaptor or API gateway means

For adaptors - what are the tools we recommend or can use to do those API and payload transformations? OpenHIM? API Gateway?

Call out that orchestration should happen using the workflow BB.