...
- Request management is only for content authoring request management. Mapping request management is not included in this project.
- Users on request management service have been logged-in via Identity Management Service (IMS).
Requirements - Separate project -not done
| # | Title | User Story | Importance | Notes |
|---|
| 1 | Creation and monitoring of requests by those who submitted them | As a requester, I want to create and track the progress of the requests I submitted. | | Status |
|---|
| subtle | true |
|---|
| colour | Red |
|---|
| title | Must |
|---|
|
| |
| 2 | Management of requests as a manager | As a request manager, I want to manage projects and relevant requests | | Status |
|---|
| subtle | true |
|---|
| colour | Red |
|---|
| title | Must |
|---|
|
| |
| 3 | Management of requests as an author | As an author, I want to manage requests assigned to me so that I can can change the status of the request when I need. | | Status |
|---|
| subtle | true |
|---|
| colour | Red |
|---|
| title | Must |
|---|
|
| |
| 4 | Management of request as a requester | As a requester, I want to manage the requests submitted by me so that I can follow up with author who is assigned to my tickets | | Status |
|---|
| subtle | true |
|---|
| colour | Red |
|---|
| title | Must |
|---|
|
| |
| 5 | Sending an e-mail message to the requesting user when the request status has been changed | As a requester/an author, I want to receive emails of updates on the request submitted by me/the request assigned to me | | Status |
|---|
| subtle | true |
|---|
| colour | Yellow |
|---|
| title | Should |
|---|
|
| |
| 6 | Advanced and efficient search tool | As a requester/an author, I want to search requests by text, ID, etc. | | Status |
|---|
| subtle | true |
|---|
| colour | Red |
|---|
| title | Must |
|---|
|
| |
| 7 | Integration to other authoring processes in Orchestration Service | As a user, I want to integrate the request management service with other services. | | Status |
|---|
| subtle | true |
|---|
| colour | Red |
|---|
| title | Must |
|---|
|
| |
| 8 | Providing increased visibility into request fulfillment (track request status from entry to completion) | As a user, I want to see all requests I have permission to access. | | Status |
|---|
| subtle | true |
|---|
| colour | Yellow |
|---|
| title | Should |
|---|
|
| |
| 9 | Providing an online catalog that lists all services available to a requester (add/edit/retire concept, add/edit/retire description, add/edit/retire relationship, etc.) | As a requester, I want to see a catalog that lists of all types of requests I can submit, so that I can submit the request by using provided request format. | | Status |
|---|
| subtle | true |
|---|
| colour | Red |
|---|
| title | Must |
|---|
|
| |
Status in workflow of request-concent
New: when a request is submitted, it will be in this state until accepted by an author for authoring.
Accepted: this state is intended to let the requestor know the request meets the criteria to be in scope for the international release of SNOMED CT.
Under authoring: when an author starts working on a request, it will enter this state.
Pending clarification: when an author needs to clarify the finer detail of a particular request, it will enter this state. When a request for clarification to a requestor is not answered within 12 weeks from the date the clarification is requested, then the request can be closed with a state of Rejected.
On hold: when a request for a specific project, which requires at least two member countries request the same concept, it will be in this state until the second member submitted the same request.
Approved: once the edit has been made and approved for release, it will enter this state.
Rejected: if a request is out of the scope of international release SNOMED CT, it will enter this state.
Withdrawn: if the requestor want to withdraw the request, it will enter this state. However, a request cannot be withdrawn after it is under authoring. At this point, request will be closed.
Appeal: if a request is rejected by an author, and the requestor appeal it, it will enter this state. The authoring team will carefully review appealed request and the rationale provided and will make a final decision.
Appeal rejected: if a request is rejected and appealed, and author decides to reject it again, it will enter this state. Appeal will not be possible on this request after it entered this state. In order to ask author to reconsider their decision, a new request needs to be submitted by requestor.
Closed: if a request is rejected and no appeal, it will enter this state. Another case is after released the content change(s) in an accepted request, it will enter this state.
User interaction and design
Case 1: Request is accepted and has no need to clarify with requestor or put on hold for any reason.
Case 2: Request needs to be clarified with requestor then accepted.
Case 3: Original request is rejected but requestor appeals the request and appealed request is accepted.
Case 4: Original request is rejected but requestor appeals the request and appealed request is rejected.
Case 5: Original request is rejected after it is under authoring but requestor appeals the request and appealed request is rejected.
| Gliffy Diagram |
|---|
| |
|---|
| name | rejected in authoring |
|---|
|
Case 6: Original request is rejected after it is under authoring but requestor appeals the request and appealed request is approved.
| Gliffy Diagram |
|---|
| |
|---|
| name | rejected in authoring and appealed is approved |
|---|
|
Case 7: Original request is rejected and no appeal.
| Gliffy Diagram |
|---|
| |
|---|
| name | Rejected and no appeal |
|---|
|
Case 8: Request is withdrawn before accepted by project lead/author.
| Gliffy Diagram |
|---|
| |
|---|
| name | Withdrawn before accepted |
|---|
|
Case 9: Request is withdrawn after accepted but before it is under authoring.
| Gliffy Diagram |
|---|
| |
|---|
| name | withdrawn after accepted. |
|---|
|
Questions
Below is a list of questions to be addressed as a result of this requirements document:
...