You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 4
Next »
Goals
- Provide traceability and activity history across the authoring process
Background and strategic fit
To understand the status of a particular piece of work, and how it got to that state
Assumptions
- This links to the traceability requirements (below) on the Milestones page for the Content Request Service (CRS) development.
Traceability
Requirement | Notes |
---|
Each content request task, generated through CRS, will be associated to one authoring task. | This will be done via staff assigning a CRS request to an authoring task through CRS or possible JIRA to start with |
Each authoring task may be associated with many requests and have multiple SCT content changes | An authoring task may not be associated to a content request as well. |
Reports should be able to show what has changed within an authoring task once it has been promoted | Any content which is changed should be logged on each status change in a traceability datasource using (at a minimum): - changeactivity id (system generated id)
- sct id
- task id
- author id
- date modified
|
When a project is promoted, the information all the authoring tasks being promoted, along with the content changed on each task, should be available for reporting | Linked to the above... this would be a status change |
At each status change of an authoring task, any associated CRS task should be updated appropriately | This is linked to the requirement from CRS below &
CRS-23
-
Getting issue details...
STATUS
|
By having a track of content being worked on in authoring tasks, authors should be able to see if content they wish to edit/maintain is already being worked on by another author | This will likely end up in a screen (somewhere) which queries the 'traceability' db against a given SCT ID |
Traceability (copied from CRS)
Requirement | Description | Epic | Notes |
---|
Each request status should be linked to the work task that is has been assigned to
CRS-23
-
Getting issue details...
STATUS
| When a work task status changes, this status should be reflected in the request JIRA issue | Request Status | This is likely to be done by the orchestration service during authoring. When an authoring task changes status, it would check with the traceability DB and change the status of the relevant request tickets |
Each batch of requests should provide a quick view as to the status
CRS-22
-
Getting issue details...
STATUS
| When viewing a batch, there should be a quick summary view of the number of requests in the batch and their relevant status | Request Status | |
Users are notified when a request status changes
CRS-24
-
Getting issue details...
STATUS
| When a request status changes as above, then the relevant requesting user should receive a notification email | Notifications | |
Technical design
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document: