...
| Practice Area | Checkpoint | Yes/No | Evidences | How to? | |||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Architecture | Has the Use case/functional requirement’s corresponding APIs been included in all relevant projects reviews with the Architecture Committee (ARC)? | Architecture walkthrough to understand how each project contributes on Release Use Case. ARC to organize the walkthrough. | |||||||||||||||||||||||||||||||||||||||||||
| Is there a plan to address the findings the API review? | Link to plan | The plan could be as simple as a Jira issue to track the implementation of findings or a documented plan within the wiki. | |||||||||||||||||||||||||||||||||||||||||||
| Does the team clearly understand that no changes in the API definition is allowed without formal TSC review and approval? | NA | In the case some changes are necessary, bring the request to the TSC for review and approval. | |||||||||||||||||||||||||||||||||||||||||||
Is there any changes in the scope, functionalities, deliverable, dependency, resources, API, repositories since M1 milestone? | If Yes, please a link to the evidence of these changes. | Critical point to understand is that change is inevitable, and that right timing and clear communication to the community will ease the process of accepting changes. | |||||||||||||||||||||||||||||||||||||||||||
| Provide link to the API Documentation. |
See interface description in BBS Broadband Service Use Case (Dublin)#FullSystemContextbbs-system-context |
...