Registration Feedback

4.1 Overview…

I suggest, you align this section with rules in template: section 2 is place for setting the context (including all kinds of overviews), in the section 4 there should be list of specific and concise descriptions of key capabilities (all kind of administration and support functions, normally, not important here, it can be defined in the section 6). In that sense overview should rather go to the section 2. The idea of this section is to provide quick access for let’s say Solution Architect to all key functionalities of BB to understand whether this BB is useful or not for specific use cases.

Next

4.2.3

Screenshot are not appropriate for this section. You should just list capabilities, which can be understood by a Solution Architect, who already familiarised herself with sections 2 and 3. Every capability should just say WHAT system does. For example, see Payments BB section 4 as a good example.

Now

REG-83: Remove Screenshots from Key Digital Functionalities SectionDone

6.1.1 RE-8

I suggest, requirements descriptions here should be rather concise, prescribing what system should do or what user should be able to do. Extensive examples, like you have it in this requirement, are rather overcomplicating text here.

Ideally, the section 6 should be possible to use as technical specification in the RFP of procurement tender, when public sector organisation wants to acquire solution, which conforms to this specification.

Also, this specification should be used as the baseline for preparation of the UAT. That is why, every requirement should request for one and only one specific capability. Sentence like this one “In many cases, the process for the user/applicant contains multiple pre-and post-registration steps in order to achieve the final goal (e.g. applying for a healthcare program).“ is rather description of the context and not requirement per se.

Next

6.3

This section does not establish requirements. I suggest, it should be removed to some other parts. For example, this content may be referenced in the section 10.

Now

REG-84: Move 6.3 Coverage Map from the Functional Requirements SectionDone

7.2

It might be good idea to align section 3 Terminology with this section. For example, my first reaction was to see, what is the definition of the “Document“ - unfortunately, there is no Document in the terminology section.

Next

REG-110: Align terminology and resource map across chaptersAccepted

8.2

I suggest that API somehow is aligned with the resource model: I was trying to find terms “applicant“ and “application“ on resource model in the section 7.2 - but those terms are not there.

Also, there is a service GET applications. I was trying to find explanation of the “application“ in terminology section 3 and in the resource model section 7.2 - but there is no “application“ in those sections. I think, it is confusing and some alignment between section 3, 7 and 8 should be in place.

Next

REG-110: Align terminology and resource map across chaptersAccepted
REG-111: Align API endpoints Accepted

8.3

This section named “Operator user services“. Section 3 explains that operator processes requests from applicants. But resource model section 7.2 doesn't show nether operator or applicant, neither request. I think, it is confusing and some alignment between section 3, 7 and 8 should be in place.

Next

REG-110: Align terminology and resource map across chaptersAccepted