Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Attendees

 

Meeting Notes

Agenda

Presenter

Duration

Discussion

  • Review pending action items

  • Risk register

Esther Ogunjimi

10 minutes

TC Process - Meetings and Responsibilities

Jira Legacy
serverSystem JIRA
serverIdf5c6bdaf-d23e-347d-a1e8-579e20a81dda
keyTECH-175

Technical Risk Register

  • Some BB WG are having low attendance

Updates to non-functional requirements

Steve Conrad

5 minutes

Non-functional requirements

Convene a small team (3-5 people) for 1 1/2 to 2 months to rework this document. Any volunteers?

Triage issues here: https://govstack-global.atlassian.net/jira/software/c/projects/TECH/issues/?jql=project%20%3D%20%22TECH%22%20AND%20text%20~%20%22Feedback%20on%20specifications%22%20ORDER%20BY%20created%20DESC 

Indicated volunteers

  • Wes

  • Rachael

Ramkumar - the doc need to be qualified

Steve - it will be part of the mandate of the working group to find the right name

Present Unconditional Social Cash Transfer (USCT) use case

Wes Brown Steve Conrad Wes Brown 15 minutes

20 minutes

USCT Use Case

Next steps:

Ramkumar - there could be example of multiple implementations that could link to the UC scenario definition document.

There should be an agreed naming convention for consistency.

Wes - The ID can be simplified by sector.

Steve - the envisioned process for this is, when PC hands over the UC doc, TC will identify the first step to work on, and then, create the example implementation for each of the steps in the UC.

Each BB would be the Lead for implementing the example for that step i.e Registration BB will take the lead for registration step. Then work with other BB teams where there are interactions to be defined.

Ramkumar - Not to get too technical with the UC doc but add the technicality in the BB specification appendix - under the API definitions (these will include what is an API and the call that will be utilised to implement the API in order to generate a set of test sequence etc). This can be linked back to the BB definition template.

Steve - this will inform the testing team on the creation of the actual API spec - what is API foot print and pay load etc.

Ramkumar - what is the level of clarity for defining the API? The current flow is defining what you do and get, but it does not care about the format and how it is presented, which should come first or last or JSON, all these are not part of the present doc. The doc is not in specific format but it is readable for a non technical person.

Recap of standards discussion and recommendation

Steve Conrad Taylor Downs

30 minuts

Retrospective

Steve Conrad

30 minutes

Taylor Downs

Steve Conrad

20 minutes

Image Added

Will this change our approach to testing? Compliance? Sandbox?

Steve

  • what level of specificity/ detail are we providing as GS?

  • Do we want GS to actually define data standard specifically?

There are two approaches as defined in the diagram above

  1. Having a strict data standard that must be adhered to by any BB.

  2. Not defining the data element or format - generic

Uwe - how sector specific does GS want to be? and will it make sense to have sector specific of data standard for GS?

So far, it could make sense to describe things down to the attribute.

The health sector already has loads of standards and it will not be useful for GS to come up with some set of standards.

Sector applications and data standard should be developed by the people in the sector in a way that it will make sense and not the defined generically.

Wes - We are not talking about defining context standard for things. For the purposes of BBs to define API within the BB, the API define in BB should be specific enough to show what should be part of the end point - have common understanding of how to use the APIs and not just abstract API.

Ramkumar - Need to have a baseline to test what is being built - have minimum data set for UC

Have a reference frame to adapt to be GS.

Martin - it will not be the adaptor approach when building something against information mediator but a clear cut product direct API call and not intermediary buddy. Allow start forward calls or map to be attached to IM and not third party or intermediary.

Retrospective

Esther Ogunjimi

Steve Conrad

30 minutes

Review of meetings and responsibilities: TC Process - Meetings and Responsibilities

Link to retro board

Meeting Recording

 

...

 

Action Items

Decision

  •  UCST UC proposed process; get UC from PC ----> break it down into steps ----> create example templates or example implementations ----> assign to BB teams to work ----> testing/sandbox team will support with actual API definitions.
  •  Start looking at the specific UC next week and assigning them to relevant BBs