Requirements were gathered during interviews and conversations with the end users and the Product Owner. The functional requirements for the new system are much the same as those for the current system. Most observations from the end users concerned non-functional requirements.
The functional and non-functional requirements are specified below.
The next step will be to translate these requirements into:
EPICs - large functional requirements that deliver areas of functionality that is completed within the project. EPICs contain Features.
Features - smaller functional requirements that deliver areas of functionality that is completed within an increment (4-12 weeks). Features contain User Stories.
User Stories - smaller functional requirements that deliver areas of functionality that is completed within a Sprint (2 weeks). User Stories contain Tasks. Task breakdown of User Stories will take place during Backlog Refinement meetings during Sprints once the project team is assembled.
Themes - deliver cross cutting elements of the project; usually non-functional requirements.
Requirements from Current System
To be completed
Requirements from User Research During Evaluation
Requirement 1
A service that doesn't crash | |
---|---|
As a | Revalidation Administrator |
I Want | a reliable service that doesn't crash all the time |
So that | I can do my work without the frustration of an unreliable system |
MoSCoW | |
Priority | |
Notes | I saw the system crash twice at Thames Valley and once at West Midlands, so this is not an infrequent occurrence. |
Requirement 2
Align HEE deferral reasons with GMC deferral reasons | |
---|---|
As a | Revalidation Administrator |
I want | to align (cross refer) my deferral reasons with the GMCs |
So that | I can continue to use my local deferral reasons but report to the GMC more accurately |
MoSCoW | |
Priority | |
Notes | The GMCs deferral reasons don’t align with the deferral reasons used by Designated Bodies. Linking local deferral reasons to GMC reasons will allow better local reporting of deferral reasons while keeping the GMC ones more accurate. |
Requirement 3
Automatic Connection | |
---|---|
As a | Revalidation Administrator |
I want | Trainees to automatically connect to my Local Office on the day they start training with us |
So that | Trainees are connected to the right Local Office at the right time, thereby avoiding extra clerical effort to ensure they are connected properly |
MoSCoW | |
Priority | |
Notes |
Requirement 4
Automatic Notification of Outcome 6 | |
---|---|
As a | Revalidation Administrator |
I want | an automatic notification from TIS when a Trainee is awarded an Outcome 6 |
So that | I know the Trainee is eligible for Revalidation without having to search for them. |
MoSCoW | |
Priority | |
Notes |
Requirement 5
Automatically check for Trainees under notice | |
As a | Revalidation Administrator |
I want | the Revalidation service to tell me when Trainees that are not under notice should be. |
So that | I don't have to manually reconcile my list of Trainees with the All Doctors list from GMC Connect |
MoSCoW | |
Priority | |
Notes |
Requirement 6
Be able to see Trainee’s evidence for Revalidation | |
---|---|
As a | Revalidation Administrator |
I want | to be able to see the three elements of a Trainee's evidence (Form R part B, Trainee ARCP, Trainee Concerns) |
So that | I can process all the information to support a Trainee's Revalidation at one time. |
MoSCoW | |
Priority | |
Notes |
Requirement 7
Be notified of outcomes from GMC | |
---|---|
As a | Revalidation Administrator |
I want | to know when the CMG has reached an outcome |
So that | I can track the progress of revalidations I have submitted to the GCM |
MoSCoW | |
Priority | |
Notes |
Requirement 8
Bring forward Revalidation date using TIS | |
---|---|
As a | Revalidation Administrator |
I want | To be able to use TIS to bring forward a Doctor's revalidation date |
So that | I don't have to waste time switching systems and logging into GMC Connect to bring forward revalidation dates |
MoSCoW | |
Priority | |
Notes | This will require cooperation from GMC as they will have to provide a new API. |
Requirement 9
Bulk upload of concerns data | |
---|---|
As a | Revalidation Administrator |
I want | to be able to upload multiple documents to the concerns log in one go |
So that | I don't have to keep repeating the same operation over and over again. |
MoSCoW | |
Priority | |
Notes |
Requirement 10
Bulk upload of historic Form R data | |
---|---|
As a | Revalidation Administrator |
I want | to be able to upload multiple Form Rs to Revalidation in one go |
So that | I don't have to keep repeating the same operation over and over again. |
MoSCoW | |
Priority | |
Notes | This should be tackled as part of migration to the new Revalidation service, but might be needed once live if not all Form R data is available at migration time. |
Requirement 11
Create Out of Programme “line in placements” | |
---|---|
As a | Revalidation Administrator |
I want | to see an Out of Programme" line in a Trainee's placement history to cover periods when they are not training" |
So that | there are no breaks in the Trainee's legitimate training history otherwise I have to chase round to find out if there is a genuine gap in the placement history |
MoSCoW | |
Priority | |
Notes |
Requirement 12
Create a snapshot of Revalidation data | |
---|---|
As a | Revalidation Administrator |
I want | to hold a snapshot of the information supplied for the revalidation |
So that | I can see the evidence the revalidation recommendation was made on if there are queries about the case in the future |
MoSCoW | |
Priority | |
Notes |
Requirement 13
Display Revalidation submission date in core TIS | |
---|---|
As a | Revalidation Administrator |
I want | to see the Trainee's revalidation submission date in Core TIS |
So that | This could go in Personal Details -> GMC Details |
MoSCoW | |
Priority | |
Notes | This could go in Personal Details -> GMC Details |
Requirement 14
Do not show the details of training doctors | |
---|---|
As a | Revalidation Administrator |
I want | to not want training doctors appearing in Revalidation |
So that | I don't see inappropriate connections or data |
MoSCoW | |
Priority | |
Notes | When a trainee becomes a training doctor their details still show up as a Trainee |
Requirement 15
Don’t show military trainees | |
---|---|
As a | Revalidation Administrator |
I want | military trainees not to be displayed in my lists |
So that | I don't have to sort through military trainees to find the trainees I should be dealing with |
MoSCoW | |
Priority | |
Notes | This only seems to be a problem in the West Midlands Designated Body. Military trainees have their own training and revalidation programmes not associated with the HEE designated bodies. |
Add Comment