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):
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-23Getting 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)
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 |
---|---|