Feedback Template
Source ID/Section | Comment | Feedback Type | Jira Issue |
|---|---|---|---|
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 - Getting issue details... STATUS |
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 “ | 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 - Getting issue details... STATUS |
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. DR-105 - Getting issue details... STATUS | Next | |
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 | |
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 |