Attendees
@Nyoman Ribeka
Meeting Notes
Agenda | Presenter | Duration | Discussion | ||||||||
| 10 minutes | TC Process - Meetings and Responsibilities
| |||||||||
Updates to non-functional requirements | 5 minutes | Convene a small team (3-5 people) for 1 1/2 to 2 months to rework this document. Any volunteers? Indicated volunteers
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 | 20 minutes | Next steps:
Ramkumar - there could be example of multiple implementation 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 - It envisioned process for this will that, 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 utilise 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 | 20 minutes | .png?version=1&modificationDate=1673376428667&cacheVersion=1&api=v2) 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 determine the data standard? Thant must be adhere to by any BB as shown in the diagram above. Not defining the data element or format. Please refer to the picture diagram above. Uwe - how sector specific do GS want to be? So far, it could make sense to describe things down to attribute. The health sector already have some set of standard and it will be useful for GS to come up with some set of standard. Sector application 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 content defining standard for things. It will be helpful for the API to be specific enough for each BB - the context of how to use the API and not generic. Ramkumar - Need to have a baseline to test what is being built. Have a reference frame to adapt to be GS compatible. Steve - | |||||||||
Retrospective | 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.