Review user stories template doc

[jordonezlucena]

Template link:
https://github.com/camaraproject/rep_main/blob/main/WorkingGroups/Commonalities/documentation/Deliverables/Userstory-template.md @

[shilpa-padgaonkar]

Should "acceptance criteria" be a part of user story?
Should NFRs be added as an optional requirement for a user story?

[jordonezlucena]

1. My interpretation is that acceptance criteria should be part of the API Test Plan (ATP), not of the user story -- but I'm open to hear any other comments in this direction. IMO, the objective of an user story is to define a set of actions targeting an application scenario, describing the steps your system needs to follow to go from A (pre-conditions) to B (post-conditions). Any conditions that prevent the successful completion of this journey shall be captured in the user story (to allow for traceability and troubleshoot when designing API solutions) -- hence the 'exception' tab.

2. Very good point, Shilpa. I think it depends on the considered use case. If there is a KPI tied to the use case (e.g. have this QoD on demand fulfilled in less than X seconds), for sure, because there's a direct impact on API solution and underlying systems. But for other functionality related scenarios, NRF may not be needed. According to your great suggestion, my proposal is to include an additional row in the table representing NRF, and mark this row as optional. WDYT?

[shilpa-padgaonkar]

@jordonezlucena Thanks a lot. Yes, NRF as optional row would be perfect.

[T-sm]

Template moved to https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/Deliverables/Userstory-template.md

[Kevsy]

Created Pull Request 24

• distinguished between 'Actors' and 'Roles'
• added 'end user' as an actor and explained why
• added 'privacy by design' in 'Linking user story to API design section

[jordonezlucena]

@Kevsy: thanks for your good suggestions. Please see my comments inline below

• distinguished between 'Actors' and 'Roles' -> I see your point. However, with the new separation, does it make sense to mark 'Actors' field as optional and 'role' filed as mandatory. From CAMARA viewpoint, I don't think we should restrict API usage to a particular actor. For example, the QoD API can be invoked by an hyperscaler or a large-scale content service provider or both. What's important for us is to define the customer role (user, administrator, business manager) that will consume the API. WDYT?
• added 'end user' as an actor and explained why -> ok.
• added 'privacy by design' in 'Linking user story to API design section -> agree, and very good point.

[Kevsy]

Thanks @jordonezlucena - yes I agree with your good points. I have changed the text in PR 24 to better focus on Roles.

[T-sm]

Thank you for your reviews, since there are no further comments this issue will be closed as agreed during our last Commonalities Workgroup meeting.