Statement of Requirements for UK Supreme Court Case Management System

Project Information Project SRO: Rowena Collins-Rice Workstream: Systems (IS) Project Director: Charles McCall IS Project Kevin Dalby Manager

IS Workstream Graham Mackenzie IS Workstream Laura Bushell Manager - Manager – Infrastructure Applications Last Amended 19 May 08 Version V1.0 Project Code A204 File location Operational - Supreme Court Implementation Programme - (TRIM) Supreme Court Information Systems Project - Statement of requirements (OPR/063/010/30)

Document Control and Administration Document History

Version Version Summary of Changes Author Number Date 0.1 10/03/08 First draft Laura Bushell 0.1 27/04/08 First draft – incorporate review Laura Bushell comments from Kevin Dalby and Graham Mackenzie 1.0 09/06/08 Second draft following Laura Bushell comments from Herbert Street, Charles McCall, Stephen Foot and Kevin Dalby

Table of Content

1.0 Purpose of Document…………………………………………………..3

2.0 Background………………………………………………………………3

3.0 General Functionality………………………………………………...…6

4.0 Case Progression System……………………………………………..9

5.0 Diary/Calendar Management…………………………………………14

6.0 Document Repository…………………………………………………14

7.0 Reporting………………………………………………………………...19

8.0 Audit………………………………………………………………………21 ii

9.0 Records Retention…………………………………………………….. 22

10.0 Non-functional requirements…………………………………...23

ANNEXES

Annex A - Supreme Court Case Management System Project Costing & Estimation Service (PCES) Report

Annex B - Supreme Court Business Processes (awaiting completion of accompanying word doc to processes)

Annex C - Judicial Office Templates (awaiting templates from JO)

Annex D - JCPC Office Templates

Annex E - Table of Required Fields (awaiting clarification from JO)

Name Issue Doc. Ref.: Date Page ii SUPREME COURT CASE MANAGEMENT SYSTEM REQUIREMENTS BASELINE

Supreme Court CMS Requirements V1.0 Page: ii SUPREME COURT CASE MANAGEMENT SYSTEM REQUIREMENTS BASELINE

1.0 PURPOSE OF DOCUMENT

1.1 This document forms the baseline requirement for the Supreme Court IT Case Management System for both Supreme Court and the Judicial Committee for the Privy Council (JCPC) staff and judiciary. These requirements will be forwarded to Logica to inform their proposals for a Case Management Solution for the Supreme Court and JCPC.

1.2 This document sets out the latest position on detailed requirements for the Case Management System by combining the high level requirements approved by the Law Lords. Included in Annex A as part of the Project Costing and Estimation Service (PCES), with the detailed requirements information captured through user workshops, visits to both Judicial Office and the JCPC, documentation gathering and the requirements set out in the Justices’ IT Requirements paper. The user workshops included the Justices, Judicial Office and JCPC staff, Legal Assistants and Secretaries. Facilitated by members of the Supreme Court Programme Team with input from eDG Business Design Authority and Matthew di Rienezo, a consultant acting as IT adviser to the Justices.

2.0 SUPREME COURT INFORMATION SYSTEM PROJECT BACKGROUND

2.0.1 The Supreme Court Information Systems (SCIS) workstream is part of the mission critical Business Implementation Project (BIP) which forms part of the Supreme Court Implementation Programme being undertaken by the Department. It is a crucial strand of that programme, and will be of high interest to Parliament, the general public, and the media, including that in other countries.

2.0.2 The Supreme Court will commence operations in September/October 2009 and will be the final court of appeal for UK judicial proceedings. It will be an organisation independent from all of the territorial court services (England & Wales, Scotland and Northern Ireland). It will sit at the pinnacle of the judicial system within the United Kingdom.

2.0.3 The Supreme Court will be located in the Middlesex Guildhall from June 2009 following extensive renovation and refurbishment of the building. The JCPC will be relocated to the Supreme Court building at the same time. 2.0.4 Following the creation of the Supreme Court the Law Lords will become Justices, for the purpose of this document the Law Lords have been entitled Justices

2.0.5 This Project will deliver the required Information Systems for an independent Supreme Court. It will include providing appropriate courtroom technology, library facilities and Case Management System (CMS). The JCPC who will be co-located at the Middlesex Guildhall will also share systems with the Supreme Court including the selected CMS solution.

2.0.6 This proposed CMS system will enhance the current ways of working and will augment the capabilities of the Supreme Court and JCPC to manage cases, thereby enhancing their national and international reputation. The essence is to deliver a modern strategic integrated case management system for the Court that will enhance its administrative processes and assist the judiciary by providing:  A Case Progression System (CPS) to record and manage the progression of cases including managing the progression (not calculation) of taxation (assessment of bill of costs) cases;  A Diary Management System to maximise effective use of Judicial and courtroom resources;

Supreme Court CMS Requirements V1.0 Page: 3 SUPREME COURT CASE MANAGEMENT SYSTEM REQUIREMENTS BASELINE

 A Document Repository System (DRS) that stores the full case file and case bundle, when filed by the parties in electronic format and stores electronic communications relating to the case;  In order to comply with MOJ strategic fit and achieve project delivery time scales, the Court expects this system to be supplied with the maximum use of existing commercial off the shelf (COTS) technology and little or no software development. However, it is accepted that there will be a degree of configuration required meeting its specific needs.  The Court would expect any interfaces between the case management product and any other software applications (e.g. document repository and diary management systems) to be proven. 2.0.7 It is essential that the system is future proofed to ensure that the system is sustainable in terms of being supported and compatible with developing technology and software upgrades in so far as is currently possible, and must fit with the strategic development of MoJ infrastructure.

2.1 COMMERCIAL BACKGROUND

2.1.1 A Request was raised by MOJ on 5th October 2007 with Logica, to undertake a product review of existing commercial off the shelf (COTs) case management packages against a high level set of requirements to explore the market and confirm business case assumptions. A subsequent Project Costing & Estimation Service (PCES) was conducted jointly by Logica and the MOJ of an initial 28 systems. Logica produced report PCES 016 on 14th December 2008 recommending the following 3 products for further investigation once detailed requirements were captured:

 Objective  Open Text  Alfresco -an Open Source solution

2.1.2 In addition following the inclusion of the JCPC to the project scope, their current system JCIS will be included in the next round of evaluation.

2.1.3 The PCES was conducted through a joint working relationship with Logica and the MOJ SCIS Project Team, which proved to be highly effective. It is envisaged that the procurement exercise will be conducted in a similar manner. The Logica PCES Report is attached to this document at Annex A which includes the High-level Case Management Systems Requirements, background information and figures for the Judicial Office and JCPC and should be read in conjunction with this document.

2.2 Business Processes

2.2.1 A series or process workshops were held between January and April 2008, attended by staff from the Supreme Court and the JCPC, Justices, Legal Assistants, Secretaries, Matthew di Rienzo and members of the SCIP. The purpose of the workshops was to detail, agree and sign off the core to be business processes for the Supreme Court and JCPC.

2.2.2 The following agreed processes are included at Annex B:

 Supreme Court Permission to appeal  Supreme Court Notice of Appeal

 Supreme Court Assessment of Costs  JCPC Permission to Appeal  JCPC Notice of Appeal  JCPC Assessment of Costs

2.3 Requirement Numbering

2.3.1 A format for requirement numbering has been included in this document. This precedes each requirement to clearly identify it, and to differentiate requirements from headings, comments, additional information, background information etc that are not requirements.

2.3.2 In order to present commonality across the workstream, all requirements will utilise the same numbering format. The following detail the agreed numbering system, for example the CMS requirement one is shown as 1.1.1 (the first 1 indicates it is a Logica related requirement, the second indicates it is a CMS requirement, and the third 1 indicates it is CMS requirement number one):  Logica – 1.1  Atos – 2.1  L!berata – 3.1

2.3.3 The requirements, both functional and non-functional have been scored using the MoSCoW rating system:

 Must have requirements, those requirements that are mandatory are indicated by (M) after the requirement number.  Should have requirements, those that are highly desirable but not mandatory are indicated by (S) after the requirement number.  Could have requirements, those that are desirable by the system are indicated by (C) after the requirement number.  Wont have requirements, those that will not be delivered by the system are indicated by (W) after the requirement number.

3.0 GENERAL FUNCTIONALITY

3.1 Requirements

Number Description Priority Comment 1.1.1 All services described in this M For clarity, the system will be paper must be compliant with installed on MOJ environment departmental and government I.T and will therefore be subject to security policies. the standard MOJ facilities and The Ministry of Justice's IT limits. However, Supreme Court security policy supports the reserves the right to differ if this Ministry of Justice security policy inhibits business performance. and has the same authority and applicability. This IT security policy is derived from the national government security policy, as defined within the manual of protective security, and is compliant with the British standard for information security management (BS7799 - Part 2).

The department's IT systems are crucial to the effective running of the department's business. The objective of IT security is to ensure business continuity and minimise damage by preventing and minimising the impact of IT security incidents. This policy applies to all of the department's IT systems, including those provided or managed by an IT service provider. It covers the use of IT equipment, the information processed on those systems and documentation about those systems, irrespective of location.

1.1.2 The system must pre-populate M standard letters and templates drawing on metadata already stored in the underlying systems, parties names, addresses, dates etc 1.1.4 Appropriate error message should S be displayed when a user attempts to make an invalid entry 1.1.5 Users must enter the system via a M desktop icon on a Supreme Court networked PC. 1.1.6 The supplier must detail any M

Number Description Priority Comment additional hardware required to deliver the solution over and above the standard MOJ build. 1.1.7 High speed scanner(s) will be M The supplier is not required to required, scanning software must supply scanners as part of this interface with the Supreme Court requirement system to ensure the user can save scanned documents seamlessly from the scanner onto the case record.

1.1.8 A function must be provided for all M dates to be manually excluded for any time calculation. To specify working and sitting days for the purpose of calculating timelimits, for prompts or actions and to set the sitting days in the diary function. This function must be provided by the user level supervisor. 1.1.8 All functions described in this M requirement must allow for multi- user access, creation, entry and deletion. But also be possible to restrict, e.g. only certain user levels can delete certain information. Depending on user level 1.1.9 The system must have a thin- M client web-based interface 1.1.10 The system must be equally M accessible remotely via secure logon from any internet connected computer 1.1.11 The Justices should be able to S It is recognised that when on logon from home or via their other internet-connected judicial laptops to the system computers a key fob (or other without using a key fob or other additional security device) is additional security device likely to be necessary. 1.1.12 The system must provide a search M facility using a variety of search criteria, case name and number, case type, date of final judgement and date of issue

1.0 Complaints

3.2.1 Requirement

Number Description Priority Comment 1.1.13 The system must be capable of M allocating a unique complaint reference number for each case entered on the system

1.1.14 The system must be capable of M producing standard letters which will form the basis of a response to a complaint 1.1.15 The system must allow for the M complaint to be sub-categorised by way of complaint type

4.0CASE PROGRESSION SYSTEM

4.0.1 Advanced case management is a key requirement of the Supreme Court IT System. Both the JCPC and JO actively manage their cases it is imperative that the System is pro-active in progressing the cases at each stage.

4.0.2 Whilst the selected system will manage both JCPC and Supreme Court cases, it is vital that the system reflects that the courts are independent of each other. By means of correspondence branding and providing a unique identifier to denote JCPC or Supreme Court cases.

4.0.3 It is envisaged that the delivered solution will make extensive use of Events, Triggers and Prompts to help court staff manage the cases processed each year. The implemented system will completely replace the many paper-based systems in use at present.

4.0.4 Both the JO and JCPC currently use templates for all of their letters and notices, copies of which are at Annexes D & E. These letters and notices are not in a prescribed format merely an illustration of the type of content required.

4.0.5 The number of cases initiated and processed each year in the JO and JCPC are:

House of Lords JCPC Information 2005 2006 2005 2006 Applications for leave to 240 219 38 60 appeal presented Appeals presented 87 73 71 105 Days sat 120 109 89 103 Appeals disposed of 102 94 57 70 Devolution Appeals 4 2

4.1 Requirements

Number Description Priority Comment 1.1.16 Case Management System must be Sufficiently intuitive and user friendly to operate such that minimal user training is required. In particular:

Number Description Priority Comment 1.1.16.1 Each screen should be clear and easy to read 1.1.16.2 Users should not have to scroll up or down to see information on a screen Clear error messages must be presented 1.1.16.3 The help function for key fields must be clear and presented in plain english 1.1.16.4 Navigation between screens must be presented clearly – for example next and previous buttons, Indicators that system has completed an action and indicators when it is necessary for user to wait for system to process something 1.1.16.5 Seamless link between the case progression screens, the document repository and calendar function

1.1.17 The system must require case data to be M entered only once. 1.1.18 The system must allow the electronic receipt M of applications to initiate a case, case papers and correspondence and from commencement of the Supreme Court. 1.1.19 The system must be able to store unique M case information, as input by the administration including: the names of the parties; the type of appeal; details of legal representation for each party, details of order appealed against; details of Lower court appealed against and jurisdiction. 1.1.21 The system must include a diary reminder M function or ability to produce a daily report that notifies the administration of due dates for completion of events on individual cases. 1.1.22 The system must provide a facility to link to M electronic communications (e.g. email) between the Court and parties to the case stored in the Document Repository by reference to the individual case to which the Parties to the case can include:  Appellant  Respondent  Interventory relate (at any time during a case an Intervener Application can be issued by a party, the Intervener, who wishes to be joined to the action) 1.1.23 The system must be able to export details of the case and parties onto the Supreme Court and JCPC websites these include:  Details of applications for permission to appeal  Applications for appeal  Details should include party names,

Number Description Priority Comment counsel, solicitors, short summary (“headnote”) of legal issues and relevant dates 1.1.24 The system must be capable of exporting M decisions on applications and judgements on appeals. In the appeal cases of great interest press releases and/or lay summaries must be made available 1.1.25 The system must provide a facility to link to M the electronic case documentation stored in the Document Repository from the case record in the case progression module. 1.1.26 The system must provide a seamless link to M the Diary management function and back 1.1.27 The system must allow the listing of: M 1.1.27.1 Appeals 1.1.27.2 Cross- applications 1.1.27.3 Intervener applications 1.1.28 The system must prompt the user when fields M have not been completed/populated i.e. at point of data entry user must be prompted if mandatory field not completed or field completed in wrong format. 1.1.29 The system must provide a facility that allows M for the production of standard templates. Either letters or directions/orders, populated with case specific information obtained from the data retained within the system. 1.1.30 The system must provide a facility to store M any completed templates and letters produced. As part of the audit record for the management of a case through the full process, and to allow for any future retrieval of templates produced 1.1.31 The system must provide a facility to produce M and store the case summary in an exportable web format. 1.1.32 The system must provide a facility to produce M and store the final judgment of the Court in an exportable web format. The judgment is the final order outlining the overall ruling on the appeal and the views of the individual Justices who participated in the appeal. 1.1.33 The system must record the receipt of either M The fees schedule fees and the value of the fee or fees is currently in draft exemption requests when lodging appeals or and is due to be leave to appeal. The system will not be finalised in 2008 required to perform a financial accounting functionality. 1.1.34 The system must connect the diary reminder M function to the requirement to produce standard letters, notices and forms for distribution to parties

Number Description Priority Comment 1.1.35 The system must provide a facility that allows M for the effective progression of the taxation of costs procedures defined in business process diagrams. To include the production of standard letters, notices and forms, together with the production of the final costs order. The system will not be required to perform a financial accounting functionality to calculate the costs, merely track and record progression of taxation (Bill of costs) cases. 1.1.36 The system must be accessible to the M Justices and Administration via a departmental device regardless of their location through secure broadband. 1.1.37 The system should generate a separate S unique identifier sequence to distinguish between JCPC and Supreme Court cases. 1.1.38 The system must badge the Supreme Court M and JCPC cases as separate systems and ring fence them within the same system. 1.1.39 The standing data in the implemented system M must be able to be configured locally by authorised court staff as required by court procedural changes. 1.1.40 The standard templates, correspondence and M notices should be clearly defined as JCPC or Supreme Court to ensure the independence of each court 1.1.41 The system could have wireless networking C capability within the Supreme Court building for the Justices to allow them full network access from portable devices (laptops, PDAs etc) 1.1.42 The system must provide access to a M restricted level of case information via the Supreme Court website to parties to the case via secure sign on.

4.2 Workflow

4.2.1 Requirements

Number Description Priority Comment 1.1.43 The system must allow event types to be set M List of required up by User Administrator as a pick table fields listed at Annex E 1.1.44 The system must provide for event sub-types M List of required to be set up as a pick table to further define fields listed at events Annex E 1.1.45 The system must allow the set up standard M events that will act as triggers for creating

Number Description Priority Comment events in Cases when required. 1.1.46 The triggering event must provide these M parameters: 1.1.46.1 Identification of one or more further events that are expected to follow the specified event 1.1.46.2 A set time limit in days within which each expected further event should occur without an overdue prompt being signalled 1.1.46.3 One or more event types (e.g. document types) that will identify what events (e.g. documents) will be provided when the event occurs (e.g. document arrives). 1.1.46.4 If the case needs referring to the Justice/Registrar 1.1.46.5 Whether or not the event closes the case.

1.1.47 The system must allow for a choice of M timescales within an event if necessary. The standard timescale which an event will occur may vary for two reasons:  Different case types may predicate different times  A judge may direct a variation 1.1.48 The system must provide facilities for a M variation of timescales from the set process flow if required (as set up by the System Administrator) to be associated with the event. 1.1.49 For any case it must be possible to add M events from a set list of additional events and identify them by picking the event type from a table. This function will be controlled by the Systems Administrator 1.1.50 It must be possible for the user to create non- M standard events – that do not have expected following events - but with the ability to specify a due date after which a prompt will be displayed if the event has not been marked as complete or the prompt cancelled from the case 1.1.51 It must be possible for users to create free- M standing events – ie which do not affect a particular case. From a set list of additional events. This function will be controlled by the systems administrator. 1.1.52 It should be possible to display a list of all S events that have been entered for a case.

4.3 Prompts

4.3.1 Requirements

Number Description Priority Comment 1.1.53 When adding an event there must be an M For clarity, not all option to set up a prompt(s) to notify the user events will generate when an action is due. prompts.

1.1.54 It must be possible for the Systems M For clarity, Cancel Administrator to cancel any prompt. The Prompts will be System Administrator must be able to cancel available for display the following prompts: for users with management or administrator rights 1.1.55 It must be possible to set up prompts with a M ‘multiparty’ option. A case can have more than one party, when an action is due it must be possible to specify which party has completed the event whilst continuing to track parties that have not completed the event.

4.4 Contact

4.4.1 Requirements

Number Description Priority Comment 1.1.56 The system must allow a user to record M details of the customers preferred method of contact – telephone, email, fax or letter 1.1.57 The system must allow the user free range M narrative to record details of contact, reason for call, matter discussed

5.0 DIARY/CALENDER MANAGEMENT

5.0.1 The Supreme Court and JCPC have specific listing requirements whilst sharing a judicial resource. The pending cases are set down for hearing at a termly ‘horses for courses’ meeting, the Office Managers of the Supreme Court and JCPC attend the meeting with details of all cases to be listed for appeal and allocate the case to the Justices and courtrooms. The overall hearing time estimate and availability of the parties legal representatives are supplied by the parties. The agreed date for the appeal hearing is then notified to all parties involved in the case.

5.0.2 The Justices sit on a panel to hear the cases in a public hearing, the panels are usually made up of 3 Justices but on occasion there can be as many as 9 Justices hearing a case. It is envisaged that the listing information could be accessed by other court staff and by the Justices, for information on their cases and those being heard by their colleagues. The electronic diary will replace the current paper based diary at the JO.

5.1 Requirements

Number Description Priority Comment 1.1.58 The system must provide a listing facility to: M 1.1.58.1 Allow cases to be allocated to a panel of Justices 1.1.58.2 Allocate a particular courtroom on a particular day 1.1.58.3 At specified time according to hearing time estimates and availability of legal representatives. 1.1.59 The system must provide viewable, printable M electronic cause lists populated from case summary field Providing full parties, representative and case details for the court and high-level case name and party details for public lists. 1.1.60 The system must have the facility to produce M cause lists in termly, weekly and daily formats. 1.1.61 The system must provide a facility to store M cause lists in an exportable web format to enable the cause lists to be exported daily to the Supreme Court and JCPC websites 1.1.62 The system could be able to allocate a C Justice to an application for appeal (based on calendar availability and expertise) and manage it proactively with the help of prompting technology throughout its lifecycle. 1.1.63 The system must be able to support the M administrative functions of the JCPC. 1.1.64 A separate diary must be available for JCPC M cases to be listed 1.1.65 To ensure that Justices and the S Administration can work remotely and access the case information when not at Middlesex Guildhall, i.e. from home. The system should be accessible to the Justices and Administration regardless of their location 1.1.66 The diary must have controls built in to M ensure that over listing does not occur. The facility to overwrite these controls must be possible at management level.

6.0 DOCUMENT REPOSITORY

6.0.1 The aim of the Document Repository system (DRS) is to open up new, more efficient ways of submitting (lodging) documents at court for customers and allowing easier and quicker access to the trial bundle by the judiciary and administration, thereby providing a more efficient service.). It is envisaged that in the future authorised parties will be able to lodge documents directly into the case file via the website using password protection.

6.1 Requirements

Number Description Priority Comment 1.1.67 The DRS will enable the court to receive M documents in a variety of ways and for the court to store them electronically. Parties will be able to lodge documents (in predefined or specified formats by providing the court with the documents on DVD/CD-ROM/memory stick. 1.1.68 The DRS will provide a seamless link to the M case progression system and Diary/Calendar Management System. 1.1.69 The Supreme Court Justices and Justices M Assistants must be able to view the electronic case bundle for each appeal securely, regardless of their location. To ensure that Justices and Justices Assistants can work remotely and access the case bundle when not at Middlesex Guildhall, via a departmental device regardless of their location through secure broadband. i.e. from home. 1.1.70 The DRS must allow the user to search for M previous applications for leave, appeals, case summaries, decisions and judgments (since the inception of the Supreme Court by:  Party name  Date  Justice who heard the case  Legal issue/area of law  Counsel  Solicitor

1.1.71 The Administration must be able to export the M electronic hearing bundle in a common media format to the in-court PC. 1.1.72 The system must allow the facility to mark up M or bookmark specific sections of the case bundle. To allow the Justices to upload the version of the bundle annotated in court and enable a slimmed-down version of the bundle, consisting of only the booked marked pages/passages, to be automatically generated and printed upon return to the office. 1.1.73 The system must allow for updated versions M The Administration of the same document to be filed and will not be maintain version control and not overwrite responsible for earlier versions. The legal teams will be incorporating late required to provide an updated case bundle if authorities within ‘11th hour’ authorities are lodged. the case bundle. 1.1.74 Each Justices’ own documents must be M presented as a navigable and searchable document library, categorised by document type and case (as appropriate) accessible by the relevant Justice

Number Description Priority Comment 1.1.75 The DRS must provide access for the M Justices and Justices Assistants, whilst in the courtroom, to the electronic case bundle via their IT client device (e.g. Laptop PC) hardware solution. 1.1.76 The DRS must be of sufficient speed. The M Justices and Administration will not expect to spend significant time accessing the system to view the electronic case bundle. 1.1.77 An associated case folder should be S generated automatically within the DRS once a full appeal notice is registered on the CPS. 1.1.78 The Legal teams could securely export the C electronic case file direct to the DRS via the internet. 1.1.79 The system could provide a facility to store C the broadcast recording for each individual appeal hearing on the case file as part of the records management requirement before exporting to standard portable media after an agreed period. Only the substantive appeal hearing will be stored as part of the overall case record. This requirement has yet to be finalised, and is due to be included within the Practice directions in 2008. 1.1.80 The system must apply version control to all M documents. 1.1.81 The system must have the facility to record M the following dates in relation to any document: 1.1.81.1 Date of Receipt 1.1.81.2 Date created (not template creation date) 1.1.81.3 Date saved onto the system, 1.1.81.4 Date amended 1.1.81.5 Date deleted. 1.1.82 The System must have the facility to view M different versions of a record or document held within the System. 1.1.83 An online filing facility will require access to M a payment engine, to enable court fees to be paid by credit/debit cards, or on account, as appropriate 1.1.84 The DRS must enable the Justices to M produce and securely store judgements and non-judicial documents (e.g conference speeches, lectures etc). 1.1.85 All documents must be available via the M intranet (including remotely) so that they are available from anywhere without the use of memory sticks and other portable media 1.1.86 The DRS must allow web browser access M both within the Supreme Court and remotely

Number Description Priority Comment via secure logon over the internet. 1.1.87 The system must accept the electronic filing M In due course the of documents and whole bundles/bound concept of volumes via the Supreme Court website. bundle/bound Online filing, as opposed to other forms of volume filing will e-filing should become increasingly take account of mandatory. This will be stipulated in the the fact that its appropriate practice direction. constituent parts can be filed separately, although they will remain inter-linked by hyperlinks 1.1.88 The system must allow the filing of M documents and whole bundles/bound volumes in electronic form on CD.DVD or memory stick. The intention is that online filing via the Supreme Court website will increasingly supersede these other forms of electronic filing. This will be stipulated in the appropriate practice direction. 1.1.89 The system must allow court users to be M able to securely view appropriate aspects of their application and appeal information via secure logon 1.1.90 The DRS could provide increased electronic C collaboration between Justices in the drafting of judgments, whilst retaining the integrity of the master version. Functionality desired includes: 1.1.90.1 Version control to control document integrity 1.1.90.2 Track changes and comments feature in word to clearly record collaboration process. Track changes must be removed in the master versions

1.1.91 The System must meet current best practice M This comprises of for electronic records management. For the a statement of UK, this is set out in the series of requirements, publications from The National Archive metadata (TNA). TNA, formerly known as the Public standards and Records Office (PRO), published ‘Electronic definitions of Records Management Systems’ in 2002. terms in three [Will suppliers have these and will whole of documents these publications apply? – Currently  Volume 1, seeking clarification as to what/how ‘Functional much information is relevant] requirements for Electronic Records Management  Systems:

Number Description Priority Comment Statement of Requirements’ (2002 Final Version)  Volume 2, ‘Functional requirements for Electronic Records Management Systems: – Metadata Standard (2002 Final Version)’  Volume 3, ‘Functional requirements for Electronic Records Management Systems: References (2002 Final Version)’ These can be found at: www.nationalarchive s.gov.uk/electronicrec ords/reqs2002/

7.0 REPORTING

7.0.1 The reporting facility is key to the administration of the Supreme Court and the JCPC. The system should have the facility to produce a prescribed set of reports as identified below. The system should also have the facility to provide for the production of ad-hoc reporting as required, to support the development of the Business plan and Annual report, and for the purpose of measuring performance and trends.

7.1 Requirements

Number Description Priority Comment 1.1.92 The system must provide a facility for M interrogating all data fields and reporting on them using standard reports and ad-hoc reports configurable by The Court. The supplier must supply a list of all standard reports with example layouts and detail of how ad-hoc reports and queries are produced. It would also help if we could list the key reports we would like including key/sort fields.

1.1.93 The system must be able to generate the M following reports for both the JCPC and Supreme Court: 1.1.93.1 Numbers of petitions, types of cases and from which jurisdiction (country and type of case) 1.1.93.2 Numbers of petitions turned down and reasons 1.1.93.3 Details of the order being appealed ie names of Judges, Court appealed from and date order made 1.1.93.4 Information about the parties involved ie which party is the appellant/respondent; address and other information; details of counsel. 1.1.93.5 For criminal cases it will be necessary to retrieve details about the victims family 1.1.93.6 Ancillary applications eg for expedition, for permission to intervene, degree of sensitivity etc 1.1.93.7 Information about documents ie what bundles have been filed and what additional documents are awaited 1.1.93.8 Name of Judicial Assistant who is Assisting and any deadlines/targets for the Judicial Assistants 1.1.93.9Name of the Law Reporter who will be working on this case 1.1.93.10 General progress of application/appeal ie relevant target dates for referral to panel, target for listing etc 1.1.93.11 Judicial directions/orders ie details of Justices who granted permission in any directions given as to expedition, constitution of appeal court, number of Justices to sit 1.1.93.12 Judgment - name of Justice giving the judgment; date of circulation of draft; comments/further judgments anticipated 1.1.93.13 Facility to extract total numbers and types of cases heard plus outcomes 1.1.93.14 Numbers of devolution matters dealt with 1.1.93.15 Details of cases heard outside of London 1.1.94 The system must be able to generate the M following reports for taxation of costs for both the JCPC and SC: 1.1.94.1 Number of bills in respect of applications 1.1.94.2 Number of bills in respect of appeals 1.1.94.3 Dates of lodgement

1.1.94.4 Dates of taxation 1.1.94.5 Number of inter parties, legal aid (and within that s. 11 claims against LSC or unsuccessful funded client claims) or criminal bills 1.1.94.6 Number of bills from the different jurisdictions 1.1.94.7 Amounts claimed 1.1.94.8 Amounts taxed off 1.1.94.9 Net amounts allowed 1.1.94.10 Taxing fees 1.1.94.11 Certificate details 1.1.95 The system must be able to generate the M following reports for judicial statistics on taxation of costs for both the JCPC and SC: 1.1.95.1 Number of petitions for leave 1.1.95.2 Total allowed on taxed bills in respect of pets for leave 1.1.95.3 Average number allowed 1.1.95.4 Number of petitions of appeal 1.1.95.5 Total allowed on taxed bills in respect of petitions of appeal 1.1.95.6 Average number allowed. 1.1.95.9 Volumes on lodging of security money 1.1.95.10 Number of costs orders made

8.0 AUDIT

The audit trail that will allow the system administrator to interrogate various actions that are performed by users and provide reports for managers/users/audit purposes as necessary.

8.1 Requirement

Number Description Priority Comment 1.1.96 The minimum requirements must be a record M of:: 1.1.96.1 Login time and date 1.1.96.2 Case creation, including the date and time that a case was created, and by whom. 1.1.96.3 Addition of document to an event (a document may be a file such as a word document, an email, spreadsheet etc.) 1.1.96.4 Change User Profile 1.1.96.5 Logout time and date 1.1.96.6 Remove document from efile and mark on case record 1.1.97 The system must provide a facility to allow M the creation of some standard audit reports that can be generated, daily, weekly, monthly or annually. The system administrator shall

Number Description Priority Comment have the provision to create these reports. The reports would only make use of the audit logs fields. 1.1.98 It should be possible to record every activity S that occurs on a case as an event.

1.1.99 Cancelled prompts must not normally appear M on screen against a case but will remain in the system and carry audit trail information.

1.1.100 It must be possible to display a list of all non- M For clarity, The cancelled prompts that have been entered for prompts will be a case together with their due dates, who listed in due date cancelled them, when they were cancelled order showing the and why they were cancelled. most urgent at the top. 1.1.101 The system must be able to identify the user M who received, created, saved, amended or deleted a document/record through the use of a User stamp setting out the User, date and time the event took place.

9.0 RECORDS RETENTION

The current records retention period for the JO is 7 years once a case has been closed. The JCPC are currently drafting their retention rules. Full details of the JCPC and Supreme Court retention rules will be provided once finalised.

9.1 The Supreme Court fundamental retention rules are:

Number Description Priority Comment 1.1.102 The system must be configured to enable a M The retention retention period to be set by default and then period for the JCPC allow records pertaining to a case to be is currently being identified for potential destruction or agreed, it may not preservation after the set retention period has fully align with expired. Supreme Court retention rules 1.1.103 Supreme Court and JCPC Managers should S be able to select cases for permanent preservation. 1.1.104 The system must indicate the retention M schedule assigned for each case.

1.1.105 The system must archive case records and M associated documentation for the Supreme Court 7 years from date the case is closed. Unless the system administrator excludes a case from this process 1.1.106 The system must archive case records and M The retention associated documentation for the JCPC ** period for the JCPC years from date the case is closed. Unless is currently being

Number Description Priority Comment the system administrator excludes agreed, it may not fully align with Supreme Court retention rules 1.1.107 The archived case documents and case data M This function does must be able to be to be retrieved for viewing not necessarily prior to destruction. need to be performed by the system as long as the records are accessible 1.1.108 The system must enable closed cases to be M retained longer than retention schedule (before destruction) if case details are requested for another case. 1.1.109 The Supreme Court must ensure that case M data and documents associated with the case are destroyed simultaneously. 1.1.110 The system must not allow automatic deletion M of documents. 1.1.111 The system must maintain a history of M changes to retention schedules, the date the change was made, and the reason for the change along with who made the change. 1.1.112 The system must provide a mechanism for M the definition and later amendment of retention & disposal rules if the retention periods change.

1.1.113 The system must allow production of lists on M a annual basis that detail the case records that are required for destruction that year, where the paper file is located and any linked cases still active.

10.0 NON- FUNCTIONAL REQUIREMENTS

Introduction

This section contains the High Level Non-Functional requirements (NFRs) for the system. The Contractors proposal will include details of the delivery of NFRs contained in this do

10.1 Service Levels

The JCPC forms a part of the MOJ, JCIS is supported by Atos under the standard service levels. The JO system sits on the network at the House of Lords, supported by Parlimentary Information Communication Technology PICT. It is vital that the system has, as a minimum, equal support levels currently provided.

Number Description Priority Comment 1.1.114 The system must have appropriate levels of M

Number Description Priority Comment backup and disaster recovery procedures in place to protect the work of the Supreme Court 1.1.115 The system should be accessible to the S Justices and Administration regardless of their location. 1.1.116 The system must have as a minimum equal M Service levels as currently provided by PICT for the JO, the current JO Service Desk opening hours are:  During term time Monday – Thursday Friday 8.30 am – 8.00 pm 8.30 am – 6.00 pm 8.30 am – 6.00 pm  During recesses Monday – Friday 11.00 am – 3.00 pm  Weekends Saturday and Sunday  The Service Desk is closed on English bank holidays. 1.1.117 The system must as a minimum provide M equal levels of remote access as currently provided by PICT for the JO. There are currently four forms of remote access available to the JO: 1.1.117.1 Dial-up (Citrix): this is provided within the UK (free of charge via a 0800 number) and abroad (chargeable to the Member by the telephone provider) from any computer equipped with a modem and which is running the Windows 2000 operating system or later. It works from any mainstream telephone system. The necessary software is supplied as standard on all official laptop computers. A CD with installation and operational documentation can be provided For Members wishing to use private computers. 1.1.117.2 Members who borrow an official laptop computer are eligible to apply for a connection to the internet and Parliament via a high speed “ADSL Broadband” line installed in their homes. There is no charge for this service. This is known as “ISP/VPN”. ISP refers to the fact that Members will receive one free

Number Description Priority Comment Internet connection from Parliament’s own Internet Service Provider. This connection can be Used to access the internet without first needing to connect to Parliament. Members who then wish to connect to Parliament can do So via the internet using a “virtual private network” (VPN) Connection. 1.1.117.3 Members who wish to work from any computer or any internet connection – including commercial offices, airports, cafés, etc – are now able to use the new SSL service. This allows access to Parliamentary e-mail and the intranet and related Parliamentary Information systems from any mainstream Internet browser, Including non-Windows computers and private computers. For Security reasons, Members are issued with a key-sized “SSL token” Which generates an additional password. There is no charge for Access to the service, although Members will need to provide or pay For the cost of the internet connection. 1.1.117.4 Mobile computing: this provides remote access to Parliamentary email, calendar, contacts, and other functions using a Personal Digital Assistant (PDA) or SmartPhone that synchronises automatically over The mobile telephone network. In contrast to synchronising Outlook Via a cable connected to a PC, the information on the device is kept Up to date while on the move, and is updated as frequently as the 54 User requires (immediately, every 10 minutes, hourly etc) providing There is an adequate mobile telephone signal. The PDAs are multifunctional Devices, including mobile Word and Excel, a web browser, And other software. The devices work as mobile phones and include predictive text messaging.

10.2 Testing

The full Supreme Court Testing Strategy will be supplied and agreed with the Supplier

10.3 General Test Requirements

The points below must apply equally to all areas of testing including integration, load/stress, resilience and network testing, except where explicitly specified otherwise.

The term "test data" refers to the physical data on which "test scripts" are run.

Number Description Priority Comment 1.1.118 The Contractor must use the model court for M all aspects of testing including Factory Acceptance Tests (FAT), User Acceptance Tests (UAT) and performance. 1.1.119 The model court must be used for all M performance, regression and user acceptance testing. 1.1.120 The Contractor must produce the test data M but it must be approved by MOJ. 1.1.121 The test environment must not use live data M and any outputs produced must be clearly marked as test outputs and be directed to dedicated printers in the test environment. 1.1.122 For performance/capacity/stress testing the M test environment must have the same capacity as the live environment and be the same size/contain the same 1.1.123 The MOJ and Contractor must agree upon a M process for prioritising and classifying software defects and enhancements.

1.1 User Acceptance Testing (UAT) Requirements

Number Description Priority Comment 1.1.124 The Contractor must co-ordinate and run M UAT of the system. 1.1.125 The UAT scripts must be provided by the M MOJ but must include input from Contractor and be agreed by Contractor. 1.1.126 UAT must be conducted by the Supreme M Court and JCPC users under the supervision of the MOJi. 1.1.127 UAT must be performed on all new releases M of the system prior to rollout. 1.1.128 The Contractor MUST produce a UAT report M The Test for MOJ to sign off UAT as satisfactory. Strategy will provide

Number Description Priority Comment details of Acceptance Criteria.

10.5 Regression Testing Requirements

Number Description Priority Comment 1.1.129 The Contractor (assisted by key MOJ, JO and M Content of JCPC staff / users) must successfully perform Regression full regression testing for changes as Tests to be appropriate and for new releases. agreed 1.1.130 Contractor must advise MOJ where it is not M considered appropriate to conduct full regression testing.

10.6 Performance Testing Requirements Number Description Priority Comment 1.1.131 The Contractor must make available the M Performance results of all performance tests to form a tests and benchmark for future reference and to inform acceptance the agreement with MOJ of a SLA covering criteria to be performance levels for the system. determined and detailed in the MOJ Testing Strategy.

10.7 Site Acceptance Testing Requirements

Number Description Priority Comment 1.1.132 The Contractor must organise Site M Acceptance testing.

1.1.134 The Site Acceptance scripts must be agreed M with the MOJ prior to the tests. 1.1.135 The Contractor and MOJ must agree whether M Site Acceptance testing is required for a new version of the system. 1.1.136 The MOJ must indicate acceptance of (Site M Acceptance) upgrades prior to the upgrade going live.

10.8 Contract Change Note Procedure

Number Description Priority Comment 1.1.137 The CCN procedure must follow the standard M MOJ agreements.

GLOSSARY(needs expanding)

PCES – Project Costing and Estimating Service is an exercise conducted by the MOJ IT suppliers Logica and Atos to provide indicative costs and timescales for a product or service.

Event - An event is an activity associated with a case that is handled by SC or JCPC and recorded on the system. Examples – file statement of facts, fix a hearing, record receipt of correspondence.

Most events are of a standard type and they follow one another more or less in a standard sequence and within defined timescales. However, the sequence is often non-standard - events are omitted, timescales are exceeded and non-standard events or sequences of events are started at any time. To cope with the standard events, sequences and timescales the system will provide template events and relationships between events.

Prompts - A prompt is a note to users of the system that something should happen by a particular date. Prompts can have their dates changed and they can be cancelled. Some prompts can be automatically cancelled by the registration of a particular event against a case.

Practice Direction

Horses for Courses process

The Administration (ie court staff)

Overlisting

Headnote – short summary of legal issues

Intervener

Intervener Application

Case summary

Appeals

Cross Applications

Supreme Court CMS Requirements V1.0 Page: 28