Requirements & Milestones - Phase 1
Target release | Phase 1 |
|---|---|
Delivery Date | Q4 2015 |
Document status | FINAL |
Document owner | @Rory Davidson |
Developers | Hunter MacDonald |
User Accounts & Dashboard
Requirement | Description | Epic | Milestone | Notes |
|---|---|---|---|---|
Users must log in through the IHTSDO IMS | Details can be found here unnamed link | User Accounts | #1 |
|
Users must be able to register through the IMS | Registration details can be found at the link above | User Accounts | #1 |
|
Admin users should be able to log in | A specific user group will exist to identify is a user has admin/staff access | User Accounts | #1 |
|
CRS users should be able to see a list of the batches and tickets that only they have previous submitted | These tickets are represented as JIRA 'issues' which can be accessed through the JIRA REST API | User Dashboard | #1 | The tickets should be recorded against their batches in a traceability DB (could be RDBMS or other) |
Admin users should be able to view and search for all the tickets in the system | They should be able to filter by:
| User Dashboard | #1 |
|
New Request Entry
Requirement | Description | Epic | Milestone | Notes |
|---|---|---|---|---|
User must be able to enter a new request | The requestor can choose select easily to create a new request. | New Request | #1 | This would be a single way in which takes the user (which could also be staff/admin) to the next choice of a file upload, or single/multiple requests entered directly |
Each new request must be linked to a category | Categories are available here - 5.4 Categories of Change | New Request | #1 |
|
The provided fields should be part of the request | Request fields can be seen here 5.6 Change Request Structure | New Request | #1 | Some of these fields should may be able to be extrapolated by using a simpler view the SCA editing panel |
The User must be able to enter multiple requests as part of 'new request' | Each entry in the request will automatically be assigned its own JIRA issue but linked to the original bacth | New Request | #2 |
|
Simple QA should be carried on each single request | This will involve:
| QA | #2 |
|
Batch Import
Screen shot design starting point here
Requirement | Description | Epic | Milestone | Notes |
|---|---|---|---|---|
Users must be able to upload data using the existing import file format | File template can be seen here - SIRS_Batch_Template.xls | Batch Import | #2 | The users may be external or staff/admins |
The file uploaded will be assigned a batch identifier |
| Batch Import | #2 |
|
Each line/request in the file uploaded must be created as separate tickets | Each ticket will be linked to the relevant batch id in order to track the whole batch | Batch Import | #2 |
|
Request Assignment
Requirement | Description | Epic | Milestone | Notes |
|---|---|---|---|---|
Each line/request in the file uploaded must be created as separate tickets | Each ticket will be linked to the relevant batch id in order to track the whole batch | Batch Import | #2 |
|
Admin users should be able to assign multiple tickets to a single authoring task and author | An admin should be to select a number of tickets from a search list and assign them to an authoring task within an authoring project | Ticket Assignment | #2 | Tickets to do not need to be part of the same batch and could be from different batches. In the traceability DB, the new authoring task ID should be recorded against each ticket. |
Traceability
Requirement | Description | Epic | Milestone | Notes |
|---|---|---|---|---|
Each request status should be linked to the work task that is has been assigned to | When a work task status changes, this status should be reflected in the request JIRA issue | Request Status | #3 | 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 | 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 | #3 |
|
Users are notified when a request status changes | When a request status changes as above, then the relevant requesting user should receive a notification email | Notifications | #3 |
|
Request Feedback & Response
Requirement | Description | Epic | Milestone | Notes |
|---|---|---|---|---|
A staff/admin user should be able to send a question back to the originating requestor for clarification |
| Feedback | #3 |
|
The requestor should receive notification when feedback has been given in order to go directly into the original request and view the feedback |
| Notifications Feedback | #3 |
|
User Cases
Request for new concept
Request for change to an existing concept
Add, change or retire descriptions
Correction of errors in existing concepts
Add, change or retire relationships
Request for retirement of an existing concept
Request for modeling of a new sub domain
Request for new Refsets
Request for existing Refsets to be amended
Request for new attributes to be added or changed within existing content
Request for new attributes to be introduced
Request for existing attributes to be removed
Request for enhancement (clean-up) of areas of SNOMED CT
Request for changes to the concept model changes to editorial policy statements
Changes to textual definitions (e.g. "surgical procedure")
Request for Quality initiative to address specific quality issues within the Terminology
Request for new cross map to another Terminology or Classification
New cross map product
Request for change to existing cross map
New map within an existing IHTSDO cross map product
Change to cross map within an existing IHTSDO cross map product
Translation (where it is within the jurisdiction of the IHTSDO)
New concept to be translated
Change / correction of existing translation for a concept
Request for translation to a new language not currently provided by the IHTSDO. A new translation product.
Request terms to be added or excluded from national extensions (this function should be undertaken by National Release Centres)
JIRA Issues Table
JIRA P1 and P2s
Key | P | Summary | Status | Sprint | Original Estimate | Remaining Estimate | Assignee | Notes |
CRS-187 | 1 | NEW |
|
|
| Unassigned | Data migration | |
CRS-146 | 1 | IN PROGRESS | Phase 2 - Sprint 4 | 1 week | 1 week | Data migration | ||
CRS-213 | 2 | BACKLOG |
|
|
| Unassigned | This can be closed as related ticket (CRS-189) has been resolved | |
CRS-201 | 2 | NEW | Sprint 8 |
|
| Unassigned | Added to Sprint 8, can use tooltips to clarify the terms | |
CRS-234 | 2 | NEW |
|
|
| Unassigned | User guide links for status changes: https://confluence.ihtsdotools.org/display/SCTCR/Managing+Submitted+Requests+Screen | |
CRS-179 | 2 | NEW |
|
|
| Unassigned | As Rory commented on related ticket CRS-271, This ticket is not implemented for day 1 due to missing endpoint from IHTSDO | |
CRS-227 | 2 | NEW |
|
|
| Unassigned | Need confirmation whether we should proceed with this ticket since the field the user want to remove is in the batch file template and current SIRS system | |
CRS-240 | 2 | NEW | Sprint 8 |
|
| Unassigned | Already in sprint 8 | |
CRS-253 | 2 | NEW | Sprint 8 |
|
| Unassigned | Already in sprint 8 | |
CRS-242 | 2 | NEW | Sprint 8 |
|
| Unassigned | Already in sprint 8 | |
CRS-248 | 2 | IN PROGRESS | Sprint 7, Sprint 8 |
|
| Already in sprint 8 | ||
CRS-185 | 2 | IN PROGRESS | Sprint 6, Sprint 7, Sprint 8 |
|
| Already in sprint 8 | ||
CRS-191 | 2 | NEW | Sprint 8 |
|
| Unassigned | Already in sprint 8 | |
CRS-200 | 2 | IN PROGRESS | Sprint 8 |
|
| Already in sprint 8 | ||
CRS-147 |
| IN PROGRESS | Phase 2 - Sprint 1, Phase 2 - Sprint 2, Phase 2 - Sprint 4, Sprint 6, Sprint 7, Sprint 8 | 2 weeks | 2 weeks | Already in sprint 8 | ||
CRS-230 | 3 | NEW | Sprint 8 |
|
| Unassigned | Already in sprint 8 | |
CRS-137 | 3 | IN PROGRESS | Sprint 6, Sprint 7 | 2 weeks, 4 days, 4 hours | 2 weeks, 4 days, 4 hours | Finished the items in feedback list from Chris Swires (https://confluence.ihtsdotools.org/display/SCTCR/FE+Update+Recommendations). Will continue if more feedback added | ||
CRS-176 | 3 | [LOCAL][IHTSDO TOOLS] the User action should be disabled while loading data of a request | CLOSED | Phase 2 - Sprint 4, Phase 2 - Sprint 5 |
| Unassigned | Closed | |
CRS-275 | 3 | IN PROGRESS | Sprint 8 |
|
| Waiting for feedbacks | ||
CRS-142 | 3 | IN PROGRESS |
|
|
| Data migration | ||
Copyright © 2025, SNOMED International