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.
- Can be used to meet:
- WRP-1237 - Getting issue details... STATUS
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):
See the technical design below |
| 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 |
| If a request |
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 |
Traceability Data Model
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|