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 | Description | Notes |
|---|---|---|
| Each content request task will be associated to one authoring task. | ||
| Each authoring task may be associated with many requests and have multiple SCT content changes | ||
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:
| Question | Outcome |
|---|---|