$PROJECT{C-NOMIS} - WhatDoTheyKnow€¦ · Web view2. Non-Functional Requirements 157 Functional Requirements. Req Id Hrchy Name Definition FUNC323 1 Prisoner Personal Details Prisoner

C-NOMIS RESTRICTED

1. FUNCTIONAL REQUIREMENTS.....................................................................2

2. NON-FUNCTIONAL REQUIREMENTS.......................................................157

document.doc Page 1 of 183 Created on 14/05/2023, 04:12:23

C-NOMIS RESTRICTED

1. FUNCTIONAL REQUIREMENTSReq Id Hrchy Name Definition

FUNC323 1 Prisoner Personal Details Prisoner Personal Details

FUNC324 1.1 Record Basic Personal Data Offender Details - record basic personal data.

FUNC325 1.1.1 Personal Details Personal Details - record and maintain Surname, Forename(s), Initials, Title, Date of Birth, Gender, Sexual Orientation, Ethnicity, Nationalities, faith & belief, marital status, disability, whether a parent, [redacted], dietary requirements, National Identity (for census reporting), multiple addresses (to eGIF standard format), telephone number(s).

FUNC326 1.1.1.1 Search Parameters Search Parameters - query the following data items OFFENDER SEARCH: Police National Computer number (PNC), Driving Licence number, CRO, National Insurance number, Legacy system number, Age, DOB, Alias Name, Alias DOB, Nationality, Ethnicity, [redacted].

FUNC327 1.1.1.2 Independent Numbers Independent Numbers - provide the facility for mobile phone numbers and email addressed (but not other types of phone number) not to be tied to a specific address.

FUNC328 1.1.1.3 Mandatory Offender Search Mandatory Offender Search - enforce a mandatory offender search before a user is allowed to create a new offender record.

FUNC329 1.1.1.4 No Fixed Address No Fixed Address - indicate 'No Fixed Address' in place of entering an address for a person recorded in the system who is of no fixed abode, or whose address is unknown.

FUNC330 1.1.1.5 Dual Nationality Dual Nationality - allow dual nationality to be input for an individual

FUNC331 1.1.1.6 Date of Birth When creating an Offender the system must enforce the entry of a Date of Birth. When a Date of Birth is recorded, the system must automatically derive and display the Offenders Age. Age must always be derived from the Offenders Date of Birth, i.e. it cannot be entered by the user'

FUNC332 1.1.1.7 Gender and Ethnicity Create offender, adding gender and ethnicity

FUNC333 1.1.1.8 Create Offender Intake Screen Create offender - Intake screen changes

FUNC334 1.1.1.9 Employment Targets Employment Targets

FUNC4335 1.1.1.10 Inclusion of Roma/Traveller data in C-NOMIS

A new requirement has been raised to include data on whether a prisoner belongs to the Roma/Treveller/Gypsy communities. This can be accommodated within the configuration of personal data in the application and does not involve any application development.

FUNC335 1.1.2 Physical Description Physical Description - record and maintain Height, Weight, Build, Complexion, Hair Colour, Distinguishing Marks.

FUNC336 1.1.3 Personal Documentation Personal Documentation - record and maintain multiple personal identification numbers.

FUNC337 1.1.4 Languages Languages


C-NOMIS RESTRICTED

Req Id Hrchy Name Definition

FUNC338 1.1.4.1 Language Capabilities Language Capabilities - record and maintain oral and reading ability in English and any other languages.

FUNC339 1.1.4.2 Translator Flag Translator Flag - set flag if prisoner is prepared to act as translator.

FUNC340 1.1.4.3 Interpreter Required Interpreter Required - record and maintain if the offender requires an interpreter.

FUNC341 1.1.5 Contact Details Contact Details - record and maintain multiple contacts, identified by type of relationship. Some contacts may need to be date stamped to ensure updated changes.

FUNC342 1.1.5.1 Solicitors Solicitors - provide a facility to associate one or more firm of solicitors with a court event within a court case.

FUNC343 1.1.6 Pregnancy Indicator Pregnancy Indicator - record if the prisoner is pregnant and expected date of the birth.

FUNC344 1.1.7 Offender Alias Alias - record and maintain any multiple identities that have been used by the offender including alias date of birth and alias gender.

FUNC345 1.1.8 Personal Details Maintenance Personal Details Maintenance - update personal details, including the date of any changes made.

FUNC346 1.1.8.1 Move Gender and Ethnicity Fields

Move gender field from screen OIDPINFO (Personal Information) to screen OIDPIDEN (Physical Identifiers). Move ethnicity field from screen OIDPIDEN (Physical Identifiers) to screen OIDPINFO (Personal Information). I.e. swap the gender and ethnicity fields.

FUNC347 1.1.9 Ex Service Personnel Indicator Ex Service Personnel Indicator - record whether an offender is ex service personnel.

FUNC348 1.1.10 Change Faith and Belief History Change of Faith and Belief History - maintain a history of an offender's religion including the date on which the faith and belief was changed and the previous and current religions.

FUNC349 1.1.11 Offender Record Merge Offender record merging functionality

FUNC350 1.2 Employment & Education Employment & Education - record offender's work and education experience.

FUNC351 1.2.1 Education History Education History - record and maintain education history and attainments for the offender.

FUNC352 1.2.2 Employment History Employment History - record and maintain previous non-custody and custody employment, employment status on release.

FUNC353 1.2.3 Occupations Occupations LOV

FUNC4552 1.2.4 Area of Study Selection Values The reference values for user selection in the ‘Area of Study’ field recorded on the existing screen ‘Education/Employment’ (OCDEDEMP) require analysis to include additional values representing courses run internal to the prison service.

FUNC354 1.3 Interests Interests etc - record offenders background information.

FUNC355 1.3.1 Smoker Status Smoker Status - record and maintain if the prisoner is a smoker.


C-NOMIS RESTRICTED


FUNC356 1.3.1.1 Smoker Status Validation Validate smoker status when assigning offender to a cell.

FUNC357 1.3.2 Alcohol Status Alcohol Status - record and maintain if the offender is dependant/non-dependant on alcohol. If dependent, state what action should be taken.

FUNC358 1.3.3 Drug Status Drug Status - record and maintain if the offender is dependant/non-dependant on drugs and, if dependent, if the offender requires detox.

FUNC359 2 Offender Assessment Offender Assessment

FUNC360 2.1 Assessment Needs Assessment Needs Monitoring - monitor assessment needs.

FUNC361 2.1.1 Assessment Scheduling Assessments Scheduling - automatically schedule designated assessments and allow manual override of scheduled dates.

FUNC2707 2.1.1.1 Workflow trigger on assessment review date

When an Assessment is performed, either the user or the system can specify a date by which a re-Assessment should be performed. A workflow trigger is required when the re-Assessment date is reached so that users are aware they should be re-Assessing the offender

FUNC362 2.1.2 Assessment Occurrence Assessment Occurrence - record the occurrence, requested and completed dates and author of an assessment (and agency if author not NOMS). Allow others 'on behalf of' author.

FUNC363 2.1.2.1 Capture OGRS Score As there is no feedback from Oasys until a later release, the need to capture the OGRS score for business functionality is now required. The OGRS score is necessary to inform decisions regarding referral to programmes and ECP placements. Currently in the NPS, the OGRS score is generated from a stand alone program and re-keyed into legacy systems. The same concept will continue in Tag.

FUNC364 2.1.3 Assessment Result Assessment Result - record the result and result date of an assessment.

FUNC365 2.2 Assessment Assistance Assessment Assistance - provide automatic assistance where appropriate to the assessment processes.

FUNC366 2.2.1 Assessment Factors Assessment Factors - provide the ability to note all contributory factors for input to assessment processes. Record the assessment input values and the author. See NPS Assessment Rules spreadsheet for details.

FUNC2706 2.2.1.1 Re-wording of CRAPP0069 - ASSESSMENT FACTOR SCORES

Release 1.1 needs to deliver the Risk PredictorLIDS currently calculates the 4 risk predictor outcomes which then populate Oasys and inform the Oasys risk score and sentence plan. This business practice must continue.This CR is to provide:-(a) The risk predictor assessment must be able to use the algorithm to calculate the 4 different risk outcomes from the responses.(b) A button report to print out the Risk Predictor including the calculated scores

FUNC367 2.2.2 Assessment Prediction Assessment Prediction - derive automatic prediction of assessment result via algorithms based on assessment factors, some of which may include conditional steps.

FUNC368 2.2.2.1 Default Security Category Default Security Category - set the default security category to [redacted] for all offenders before a security category assessment has been performed.

FUNC369 2.2.3 Assessment Prediction Override Assessment Prediction Override - provide means to manually override all automatic predictions, retaining record of who overwrote prediction.


C-NOMIS RESTRICTED


FUNC370 2.2.4 Assessment Results Assessment Results - provide an indicator on assessments or overrides which contravene specific business rules.

FUNC371 2.2.4.1 Multiple Scores Provide ability to define multiple scores for an assessment question which are specific to defined assessment factors

FUNC372 2.2.4.2 Save Incomplete Assessment Save incomplete Assessment and do not calculate until complete

FUNC373 2.2.4.3 Unapproved Assessments Report to identify un-approved assessments

FUNC374 2.2.4.4 Assessment Review Trigger Workflow trigger for assessment review

FUNC375 2.2.4.5 Evaluation Measures Functionality Use

Allow Evaluation Measures functionality to be used for any Assessment

FUNC376 2.2.5 Assessment LOV Assessment List of Values - provide LOVs (for results, decisions) which are relevant and specific to each assessment.

FUNC377 2.3 Assessment Authorisation Assessment Authorisation - ensure appropriate authorisation level.

FUNC378 2.3.1 Assessment Authorisation Detail Assessment Authorisation - record if an assessment requires authorisation, based on the grade or role of the completing user and, in the case of OASys on the Risk of Harm level.

FUNC379 2.4 Specific Risk Assessments Specific Risk Assessments - recognise all required assessment processes.

FUNC380 2.4.1 Initial Self-Harm Indicator Initial Self-Harm Indicator - record and maintain if the offender is considered as a particular self-harm risk [redacted]. The dates that the marker was set and closed should be available on screen.

FUNC381 2.4.2 Self-Harm Alert Self-Harm Indicator - provide an alert as part of the base offender header record when there is a self harm history.

FUNC382 2.4.3 ACCT (Self Harm) Assessment Self Harm ACCT Assessment

FUNC383 2.4.4 Risk Indicators Risk Indicators - record and maintain several risk indicators for the offender including vulnerability indicator, OASys ROH flag, MAPPA referral indicator, Area Child Protection Committee Registration indicator, VISOR flag. Risk indicators need to be visible in the Offender header. If design constraints limit this, there must at least be a warning flag with drill-down.

FUNC384 2.4.4.1 Lock Cell Sharing Risk Assessment Cell Sharing Risk Assessment - lock the Cell Sharing Risk Assessment form after section 1 and 2 are complete and before further sections are completed.

FUNC385 2.4.5 General Security Risk Indicator General Security Risk Indicator - record and maintain if the prisoner is considered likely to destabilise the general security of the establishment. record and maintain the reason for adding this marker.


C-NOMIS RESTRICTED


FUNC3139 2.4.6 Implementation of LSR for Risk Predictor(For loadbalance risk predictor results)

When nomis went live at Albany, the site had not completed all of their risk predictions etc. Whilst nomis 1.0 does have the capability to display risk predictor assesment results, and these were migrated on go live where available, it does not have the capability to actually ""do"" the predictions. Therefore this exercise is to load the balance of the risk prediction results into nomis that were not available at the time of the original migration."

[redacted]

FUNC386 2.5 Specific Needs Assessment Specific Needs Assessment - recognise all specific needs of the offender.

FUNC387 2.5.1 Disability Labels Disability labels

FUNC388 2.5.2 Healthcare Needs HealthCare Needs - record and maintain healthcare needs.

FUNC389 2.5.2.1 Facilities Required Record disability and facilities required

FUNC390 2.5.3 Baby Details Baby Details - record and maintain contact details (including phone number and address) of who will look after the baby when baby returns to the community or in an emergency.

FUNC391 2.6 IEP Level Incentives & Earned Privilege (IEP) Level - record all IEP levels and entitlements awarded for all offenders.

FUNC392 2.6.1 Record Overall Level IEP Level - record and maintain the overall assessed level: Enhanced (1), Standard (2) or Basic (3).

FUNC393 2.6.2 IEP Earnings IEP Earnings - record and maintain the establishment-specific IEP level impacts on type of employment activity.

FUNC394 2.6.3 IEP Spend Limits IEP Spend Limits - record and maintain the establishment-specific IEP level impacts on spend limits.

FUNC395 2.6.4 IEP Visit Allowances IEP Visit Allowances - record and maintain the establishment-specific IEP level impacts on visits.

FUNC3367 2.6.5 Default IEP Level On IEDT Transfer In

When a Prisoner record is received into the C-NOMIS system from the IEDT interface, and that record is not matched with an existing Prisoner record in C-NOMIS, the Prisoner record's IEP level will be set to a default IEP level. That default IEP level will be the C-NOMIS value of 'Standard'. If the Prisoner record received from the IEDT interface matches an existing Prisoner record in C-NOMIS then the IEP level will be set according to existing, previously defined merge rules. The merge rules will use the default IEP level as defined above for the Prisoner record received from the IEDT interface when determining the resultant merged Prisoner's IEP level.

FUNC4308 2.7 Assessment Completion & Locking

FUNC4309 2.7.1 Section Completion The system will provide a user with the ability to indicate the completion of a section of an Offender assessment, for sections of an assessment that have been configured by [redacted] to require completion.

FUNC4310 2.7.2 Record Section Completion User & Date

When a user indicates the completion of a section of an Offender assessment, the system will record and display on the section, the user who indicated completion and the date of completion.


C-NOMIS RESTRICTED


FUNC4311 2.7.3 Restrict Section Update When a user indicates the completion of a section of an Offender assessment, the system will only allow further updating of that section by [redacted].

FUNC4312 2.7.4 Assessment Completion The system will allow a user to indicate that an entire Offender assessment is complete.

FUNC4313 2.7.5 Record Assessment Completion User & Date

When a user indicates the completion of an entire Offender assessment, the system will record and display on the assessment, the user who indicated completion and the date of completion.

FUNC4314 2.7.6 Restrict Assessment Update When a user indicates the completion of an entire Offender assessment, the system will only allow further updating of that assessment by [redacted].

FUNC4315 2.7.7 Section Completion Configuration The system will provide the ability for [redacted] to configure which sections of each type of assessment maybe indicated by a user as complete and no longer updateable.

FUNC4316 2.7.8 Assessment Completion Configuration

The system will provide the ability for [redacted] to configure which types of assessment maybe indicated by a user as complete and no longer updateable.

FUNC396 3 Offender Administration Offender Administration

FUNC397 3.1 Prisoner Number Prisoner Number - associate a Prisoner Number to each prisoner.

FUNC398 3.1.1 Offender Number Allocation Offender Number Allocation - associate a unique number which will remain with the offender throughout his/her life and unique number for each separate arrest.

FUNC399 3.1.2 Offender Information Access Offender Information Access - allow all current offender information to be directly accessed via the offender Number.

FUNC400 3.1.3 Person Details Person Details - record and maintain details in a single record, which is associated with the current Offender Number and may (historically) be associated with several different offender numbers.

FUNC401 3.1.3.1 Skeleton Offender Record Skeleton Offender Record - provide the ability to enter basic data in the offender's record even if key data is unavailable. Contacts should be recordable against the entry. Skeleton entry should be able to be merged with an existing offender record.

FUNC402 3.1.4 Person Details Matching Person Details Matching - validate offender details and aliases entered against the records already held on the system to identify 'close matches'. If any existing record is identified as the person being received, allow the user to select this close match.

FUNC403 3.1.5 Offender Number Revision Offender Number Revision - allow to re-adopt an earlier offender Number or Offender Number, if reception initially fails to recognise that records already exist for this offender from earlier custody episodes.

FUNC404 3.1.6 PDP File Number PDP File Number - record the PDP file number ([redacted]).

FUNC405 3.1.7 Check Hold Markers Check Hold Markers - allow a check hold marker to be set against an offender for the purpose of stopping him being transferred. Alert the user if an attempt is made to transfer an offender with a check hold marker. Allow this alert to be overridden by the user.


C-NOMIS RESTRICTED


FUNC3102 3.1.8 Booking / Legacy Prison Number At the moment the Legacy “Prison number” is recorded on CNOMIS as the Booking number.This request is to include it as an Identifier on migration and when creating a “New Offender”, so that the staff in the establishment can search on the prisoner’s old number when they perform a “Global Search”.

FUNC406 3.2 Offender Classifications Offender Classifications - record the various classifications of the offender.

FUNC407 3.2.1 Offender Status Offender Status - record and maintain formal multiple status(es) of the offender. Display a high visibility flag for the status of the offender falling into certain categories (e.g. breach in progress, custody).

FUNC408 3.2.1.1 Offender Categorisation / Flags Offender categorisations/flags - provide the ability to flag categories of offender (e.g. PPO, looked after child).

FUNC409 3.2.1.2 Access by Lifer Unit Access by Lifer Unit - provide access to offender records for lifers regardless of the offender's location. That is, if the offender is in custody, on probation or out of jurisdiction (eg. Mental institution or Scotland).

FUNC410 3.2.2 E-List E-List - record and maintain if prisoner is identified as an escape risk and inclusive dates.

FUNC411 3.2.3 Offender Type Offender Type - record and maintain the appropriate (most applicable) offender types. It should also be possible to highlight offenders falling into particular categories (ie: persistent offenders, street crime etc).

FUNC412 3.2.3.1 Personal Officer on HMPS Hot Page Header block offender management

FUNC413 3.2.3.2 Legal Status on HMPS Hot Page Display legal status on HMP Hot page

FUNC414 3.2.4 Offender Sentence Type Offender Sentence Type - record and maintain the overall sentence type plus up to 12 components of the sentence. The components may have different start and end dates.

FUNC415 3.2.4.1 Single Sentence Form Single Sentence Form - provide a single form for court workers (or others) to enter a sentence with prison and probation elements, including supervision requirements.

FUNC416 3.2.4.2 Verified Result Flag Verified Result Flag - record that order commencement details have been confirmed with the sentencing court via a Verified Result flag.

FUNC417 3.2.4.3 Default Start Date for Sentence Requirement

Provide the ability to enable the start date for a Sentence Requirement (Order Requirement) to take the default value of the Sentence Date. The date must subsequently be editable

FUNC418 3.2.4.4 Allocation of Requirement Allocation of Requirement

FUNC419 3.2.5 Header Block Sentence Short Description

Header Block Sentence Short Description of sentence/order type

FUNC420 3.2.6 Resettlement Type Resettlement Type - record and maintain the identity of all resettlement programmes of which the offender is a beneficiary, e.g. PSP, Resettlement Passport, Job Centre Plus.

FUNC421 3.2.7 Rule 45/48 Indicator Rule 45/48 Indicator - record and maintain if the offender is under Rule 45/48 segregation and the reason for the segregation. Include in offender information display.


C-NOMIS RESTRICTED


FUNC422 3.2.8 Schedule 1 Schedule 1

FUNC423 3.2.8.1 Schedule 1 Warning Indicator Schedule 1 Warning Indicator - record and maintain if the offender is a schedule 1 offender as detailed on the definitive list. Display this in the Offender header with other flags.

FUNC424 3.2.8.2 Schedule 1 Informing Schedule 1 - record and maintain when a Social Services area and Police area were informed of a Schedule 1 offender. Also record the area names.

FUNC425 3.2.9 Limited Access Offenders Limited Access Offenders - allow only limited system access to the records of some named offenders.

FUNC426 3.2.9.1 [redacted] [redacted]

FUNC427 3.2.9.2 High Profile Offender Indicator High Profile Offender Indicator - indicate if the offender is High Profile (HP). [redacted]

FUNC428 3.2.9.3 Removal of High Profile Status Removal of High Profile Status - allow general access to the entire record of an offender, once high profile status has been removed.

FUNC429 3.2.9.4 High Profile Access High Profile Access - allow full access to records of HP offenders by user grade and location. This applies to current and historic offender records.

FUNC430 3.2.9.5 High Profile Limited Record High Profile Limited Record - allow all users (subject to access control) to see a limited record for HP offenders. This includes name, number, location, offence, movements, visiting information, but does not include parole report, case notes etc.

FUNC431 3.2.10 Details of Court Report Details of Court Report - record supervision requirements, activities, exclusions etc proposed on a court report as recommended by the report author in such a way as to enable statistical comparison against the court-ordered requirements. For those reports where specific requirements may be proposed (currently Standard Delivery PSR, Fast Delivery PSR, Deferred Sentence report and Oral report) then capture detailed information as listed in note. Breach reports supplied for a Breach hearing at court will also fall into this category.

FUNC432 3.2.11 Statute Code Field Length Increase field length of statute codes description

FUNC433 3.2.12 Mandatory Young Offender Flag Make Adult / Young Offender Flag mandatory in C-NOMIS

FUNC434 3.2.13 Mandatory Inmate Status Booking / Legacy Prison Number. Mandatory inmate status


C-NOMIS RESTRICTED


FUNC3101 3.2.14 Public Protection Sentence Outcomes

Those prisoners who were in for serving sentences passed under the Criminal Justice Act 2003 with specific public protection issues, were not being identified on reports and hot pages, due to a decision taken prior to go-live for HMP Albany, forced by deadlines and issues of complexity a decision, to migrate all sentence data under a generic code of “Migrated Sentence Data” with the understanding that at a later date the prison staff would be able to go back and update this to the correct sentence type (this was when there was only due to be a short gap between the Rel1.0 and 1.1 launches).

A step check to be entered into the migration routine which will instruct X-Tag to look for prisoners with the LIDS case statuses of either ISPPCJ03 or PPEXT/SENT (Indeterminate or Extended Sentence for Public Protection). Where this exists as a case status X-TAG is to skip the algorithm used to ascertain that the sentence is under the powers of CJA 1991 or 2003 and to default to a 2003 sentence type using the C-NOMIS sentence codes of IPP or PPEXT_SENT. Where these statuses were not found in the incoming LIDS date the system will use the Migrated Sentence Data and CJA determination algorithm as standard.

For Albany data: This would need to be a change made through the back end if the prison could supply a list of those prisoners who are currently in serving one of these sentences. Would need to know the prisoners’ name, number, the offences and dates of commission, with the sentence length and extension period length.

FUNC3133 3.2.15 Support for indeterminate sentences post-release

The creation of life licences is scheduled for a later version of C-NOMIS (1.3), when the Home Office Lifer Review and Recall section will have access to C-NOMIS. They are the government body resposible for the creation of such licences and for decisions about recall. Until then it will be necessary to migrate existing post-release indeterminate sentence prisoners from NPS and to be able to record these via the C-NOMIS application. The changes required may be limited to additional Licence codes and Licence status update reasons, but some investigation is required.

FUNC3136 3.2.15.1 Indeterminate Sentence Public Protection offenders

Indeterminate Sentence Public Protection (ISPP) offenders currently are not identifiable in any field in C-NOMIS.

FUNC435 3.3 Police Records Police Records - record information from police files.

FUNC436 3.3.1 Previous Conviction History Previous Conviction History - record and maintain the previous conviction and sentence history for the offender, including police cautions.

FUNC437 3.3.1.1 Summary of Conviction History Summary of Conviction History - record a brief summary of the offender's conviction history.


C-NOMIS RESTRICTED


FUNC438 3.3.2 Record Identifiers PNC, CRO, CPR and ASN - record the Police National Computer reference, Criminal Records Office number, Criminal Prosecution Reference, Arrest Summons Number and Legacy Case management ID. NOMIS must allow a user to record the following types of identifiers for an Offender:Police National Computer Reference (PNC)Criminal Records Office Number (CRO)Legacy Case Management IDFor the same Offender NOMIS must allow the user to record one or more identifiers of the same type (e.g. two CRO numbers).If one or more identifiers of the same type are recorded for the Offender, NOMIS must not allow these to be of the same value (e.g. the two CRO numbers must not be the same for the Offender)NOMIS must allow each identifier recorded for the Offender to be associated with any of the Offender's related aliases.If an identifier is associated with an Offender's alias, then NOMIS must still not allow the value of the identifier to be the same as identifiers of the same type associated with other aliases of the Offender (e.g. CRO for Alias 1 must not be the same as CRO for Alias 2, where Alias 1 and Alias 2 pertain to the same Offender).NOMIS must provide a warning to the user if they attempt to record a PNC identifier that has the same value as the PNC identifier for another Offender recorded on NOMIS. This warning must NOT prevent the user from recording the duplicate PNC identifier.If a duplicate PNC identifier is found by NOMIS then it must provide a facility to find and view basic details of the Offender or Offenders with the duplicate PNC identifier according to the access rights of the user.NOMIS must provide the facility to produce a data quality report indicating all Offender instances with duplicate PNC numbers.Any PNC identifier a user attempts to record must be validated by NOMIS according to the data format and validation rules specified by the NOMIS Data Standards document. PNC number must

FUNC439 3.3.3 Standard Format for CRO Validation Request for standard format for Criminal Records Office (CRO) Validation

FUNC440 3.4 Court Documents and Court Appearances

Court Documents and Court Appearances - record the possession of all court order documents and future court appearances.

FUNC441 3.4.1 Court Documents Held Court Documents Held - record and maintain the type, court, date received and expiry date of all court documents held for an offender.

FUNC442 3.4.1.1 Court Reports Court Reports - record the outcome of a court appearance, and where the outcome is a request for a report for the court, record details of the report and the court to receive the report.

FUNC443 3.4.1.2 Report Required by Court Provide the ability to identify the court that a report is required by, using the court named for the next court hearing.

FUNC444 3.4.1.3 Court Report Proposals Provide the ability to capture court report proposals as well as proposed sentences. A report proposal includes non-sentence proposals such as a psychiatric examination, medical examination, fine, driving disqualification etc.

FUNC445 3.4.2 Court Appearances Court Appearances - record and maintain [redacted] court appearances including type of appearance (remand, adjournment), due date for court report, pleas and directions dates for Crown Court and CPS area.

FUNC446 3.4.2.1 Supervising Court Supervising Court - designate an optional Supervising Court if different from the location of the hearing.

FUNC447 3.4.2.2 Default Start Time for Court List Entry

Provide the ability to enable a new entry on a Court List to be given a default start time of 10:00. This should happen for all entries on the Court List, whether added manually or generated automatically through the next event functionality. The time must subsequently be editable


C-NOMIS RESTRICTED


FUNC448 3.4.2.3 Call Address Screen from Court List Provide the ability to enable the address screen to be called from the create offender screen when that screen is accessed from the Court List. Access to the address screen should be optional (not automatic) from the create offender screen

FUNC449 3.4.2.4 Display Latest Court Provide the ability to always display the latest (most recent) court dealing with a case in the Court Cases block of the Court Cases screen

FUNC450 3.4.3 Court Diary Court Diary - record and maintain a list of persons appearing in a specified court on a specified day.

FUNC2401 3.4.4 Access for Court Workers An offender appears at a Court in an area in which they do not reside. (Hampshire offfender appears in a Sussex Court). The Sussex Court worker can only add the offender to the court list. [redacted]

The Change request is to get the system to automatically add the Court Location to the Contacts for this offender as a consequence of their being added to the Court list of that location. Hence the Sussex Court worker can proceed to enter relevant details, thus making them immediately available to Hampshire.

FUNC451 3.5 Charges and Outcomes Charges and Outcomes - record specific detail from the CJO documents held.

FUNC452 3.5.1 Charge and Indictment Information Charge and Indictment Information - record and maintain offence types, history of changes from charges to indictments and link these to court events using the CPR number. Allow free text to be entered for additional charge details.

FUNC453 3.5.1.1 Offence LOV Structure Reference Data Structure - provide additional structure in the Offence LOV to allow sorting by category, indicators or severity when selecting from a list of several thousand options.

FUNC454 3.5.1.2 Offence Searches Offence Searches - provide the ability to search on offence by category and by keyword.

FUNC455 3.5.1.3 Most Serious Offence Most Serious Offence - record manually and maintain an indication of the offender's most serious offence. This is displayed on the HMPS hotpage.

FUNC456 3.5.1.4 Offences Taken into Consideration Offences Taken into Consideration - provide a facility to record and update the number and financial value of offences taken into consideration.

FUNC457 3.5.1.5 Two Results with Different Offence Indicators

2 results with different offence indicators

FUNC458 3.5.1.6 Capture Sentence for Partial Result Capture sentence for partial result

FUNC459 3.5.1.7 Ordering Courts, Offences and Outcomes

Ordering courts, offences, outcomes

FUNC460 3.5.2 Custody Time Custody Time - record and maintain the time (allowed by the court) spent by a prisoner in custody before sentence and the location(s).

FUNC461 3.5.2.1 Latest Detention Date Latest Detention Date - calculate the latest-allowable detention date for an offender under either CJ Act.

FUNC462 3.5.3 CJS Case Numbers CJS Case Numbers - record and maintain CJS case numbers and the indictments/charges covered.


C-NOMIS RESTRICTED


FUNC463 3.5.4 Defendants Defendants - record and maintain details of all defendants and establish multiple links to CJS cases.

FUNC464 3.5.4.1 Co-Accused Co-accused - provide a facility to associate a co-accused offender with one or more offences within a case.

FUNC465 3.5.5 Court Details Court Details - record and maintain details of the court relating to the offender.

FUNC466 3.5.5.1 Local Justice Area Local Justice Area - designate a Local Justice Area for each court.

FUNC467 3.5.6 Pleas and Verdicts Pleas and Verdicts - record and maintain all pleas and verdicts against each charge.

FUNC468 3.5.7 Sentence Details Sentence Details

FUNC469 3.5.7.1 Record and Maintain Sentences Sentence Details - record and maintain sentences associated with the charges and multiple conditions of court orders. Components of the sentence must be associated with that sentence including lengths, dates and specified completion times. A free text field must be available to capture generic sentencing comments (this could include any remarks from the Judge

FUNC470 3.5.7.2 Custody Plus Requirements Custody Plus Requirements - record four standard requirements that may be imposed either by the court or during the custodial period (residence, mental health treatment, drug rehabilitation, alcohol treatment).

FUNC471 3.5.7.3 Specified Activity Detail Specified activity detail at sentencing

FUNC472 3.5.7.4 Predominant Case An offender may have more than one active legal case at any given time. Currently, when LIDS passes information to IIS, it also passes a flag to indicate which of the offender's cases is the predominant one. This predominance is determined by a ranking algorithm in LIDS. Nomis deals with Case and Sentence fundamentally differently than the legacy applications. Certain key information is missing i.e. Predominant case, or not mandatory in this release, i.e. Sentence Expiry Date. This means that the interfaces cannot currently provide the data in the manner that the legacy systems receive them today. This can lead to incorrect or misleading data being sent to IIS and LIDS. The removal ensures the correct sentence days are re-entered on LIDS and sent back to IIS for any transferred prisoners

FUNC473 3.5.8 Fines & Debts Fines & Debts

FUNC474 3.5.8.1 Outstanding Fines & Debts Outstanding Fines & Debts - record and maintain any fines or debts lodged against prisoner and record manually their effect on the sentence.

FUNC475 3.5.8.2 Fine or Debt Due Date Fine or Debt Due Date - record and maintain the due date of the fine (if the prisoner has been given time to pay a fine or debt).

FUNC4561 3.5.8.3 Fine Payment Before Sentence Start Date

When a user records a fine payment against an Offender’s fine sentence the system must allow all or some of the fine payment to be recorded on or before the start date of the sentence.

FUNC476 3.5.9 Sentence Quashed Sentence Quashed

FUNC477 3.5.9.1 Sentence Quashed Sentence Effect Sentence Quashed - record for a prisoner the effects on their sentence following an appeal decision.


C-NOMIS RESTRICTED


FUNC478 3.5.9.2 Seal Record after Sentence Quashed

Seal Record after Sentence Quashed - following a successful appeal, seal the affected portions of the record so that the details remain but are only updateable to certain users.

FUNC479 3.5.9.3 Conviction Quashed Conviction Quashed - record for a prisoner if a conviction is quashed following a successful appeal.

FUNC480 3.5.10 Harassment Order Harassment Order - record and maintain all persons involved. If the person is not an offender, record and maintain name and address.

FUNC481 3.5.11 Not for Release Marker Not for Release Marker - record and maintain if prisoner is not to be released from court or prison.

FUNC482 3.5.11.1 Check NFR Marker Prior to Release Check NFR marker prior to release - During the Release Offender from Custody process a check should be made to see if a Not For Release marker (alert) has been set on the offender record. If the alert has been set then the discharge officer should be warned that the offender should not be released

FUNC483 3.5.12 Court Outcome Court Outcome - record the outcome of a court appearance, which may be a subsequent appearance, adjournment, PSR request etc (excluding sentence).

FUNC484 3.5.13 Level of Seriousness Level of seriousness - record the court's view of the level of seriousness (single value) and the purpose of sentencing (multiple values) both at the time of the court requesting the PSR and at the time of sentencing.

FUNC485 3.5.14 [redacted] [redacted]

FUNC486 3.5.15 Hostel Rules Hostel Rules - hold Hostel rules for each hostel which can be printed and given to offender together with map/ travel directions.

FUNC487 3.5.16 Online Referral Forms Online Referral Forms - hold referral forms for each hostel which can be completed on line and electronically sent to the identiifed hostel.

FUNC488 3.5.17 Referral Details Referral Details - hold details of referrals made to each hostel, capturing at which hearing - first or subsequent - what the Police/ CPS position - RIC, RIPC, Unconditional bail, Conditional bsail to include hostel, not known.

FUNC489 3.5.18 Placement Referrals Placement Referrals - hold data of referrals offered a placement.

FUNC490 3.5.19 Bail Information Report Bail Information Report - hold the Bail Information Report which must be printable at the Court location the offender is appearing at. The report to be completed on screen after interview of the defendant and any enquires are made.

FUNC491 3.5.20 BIR Access BIR Access - allow bail Information assessment reports started in the community to be accessible by the prison based staff carrying out this function and vice versa.

FUNC4560 3.5.21 Partial, Final, Interim Offence Result Combinations

When a user records two results against an offence on the existing screen ‘Court Cases – OCDCCASE’, the system must only allow the following combinations of result types:

Final/Final

Partial/Partial

Interim/Interim

Final/Partial


C-NOMIS RESTRICTED


FUNC6349 3.5.22 Charge and Outcome Entry Validation

The system shall provide specific validation on entry of sentence, requirement, licence, licence condition and subsequent termination reasons:- Sentence Lengths (Terms) and Requirement Lengths need to have lengths validated as per relevant act e.g. CPO = 40-240 hours, Specified Activity = x-y days.- Requirement Length units should be derived by the application based on type e.g. UPW = hours, SA = days etc.- Terms for all NPS sentences should allow entry of months only, with validation e.g. CRO = 6-36 months.- Validation of age against sentence type e.g. to prevent entry of adult sentences for juveniles.- Termination reasons should be filtered for each requirement type and against each CJA e.g. Type 9 is no additonal requirement - only valid against CJA 1991 sentences.

FUNC492 3.6 Sentence Calculation Sentence Calculation - provide assistance in sentence calculation.

FUNC493 3.6.1 Calculate Sentence Duration & Key Dates

Sentence Calculation - automatically calculate the sentence duration and key dates, together with a calculation summary. 1991 and 2003 Acts only

FUNC494 3.6.2 Dates Maintenance Sentence Calculation / Dates Maintenance - allow manual adjustment or over-ride of the system-calculated sentence duration and key dates.

FUNC495 3.6.3 Documentation and Approval Sentence Calculation Documentation/Approval - generate sentence calculation documentation and record the approval of all new or changed sentence calculations.

FUNC496 3.6.4 Update Licence Start Date Licence start date needs to allow update for Release 1.1 as well as 1.0

FUNC497 3.6.5 Custody Time Limits Record custody time limits

FUNC498 3.6.6 Effective Sentence Length Effective Sentence Length

FUNC499 3.6.7 Automatic Main Offence Automatic Main Offence - derive the prisoners Main Offence automatically as part of sentence calculation.

FUNC3134 3.6.8 Validation of sentence key dates Offender's total sentence can be set negative by entering an SED override in the past. This in turn causes a negative value to populate the total sentences field on the risk predictor form. (defect 6540 refers)

FUNC4348 3.6.9 Supress Key Dates On Key Dates Screen

If a prisoner record has one or more active life sentences, and one or more active fixed term sentences concurrent with any of the life sentences, the system will suppress the display of all automatically calculated key dates for all fixed term sentences for that prisoner on the existing screen ‘Sentence Key Dates – (OIDSENKD)’.

FUNC4350 3.6.10 Supress Key Dates On Release Schedule

If a prisoner record has one or more active life sentences, and one or more active fixed term sentences concurrent with any of those life sentences, the system will suppress the display of all calculated and manually recorded auto release dates for that prisoner in the column ‘Auto Release’ on the existing screen ‘Release Schedules – (OIDRELSC)’. Auto release dates are defined as the ARD (Automatic Release Date), CRD (Conditional Release Date) and NPD (Non Parole Date).


C-NOMIS RESTRICTED


FUNC4554 3.6.11 Extended Sentences Imposed on or After 14/07/08

When calculating an Offender’s sentence key dates where a Criminal Justice Act 2003 Extended Sentence is recorded for the Offender, and the sentence is imposed on or after the 14th of July 2008 the system must:- calculate the Conditional Release Date as the half way point of the custodial part of the sentence. - not calculate a Parole Eligibility Date or Non-Parole Date.- calculate the Sentence Licence Expiry Date.

FUNC5948 3.6.12 Offender Management Act DTO

FUNC5949 3.6.12.1 Record DTO Transfer Submission The system must allow a user to record submissions made by an Establishment to the Youth Justice services with regards to a detainee’s Detention Training Order transfer to the community. The information that is recordable must include (to be confirmed):

- Date of Submission

- Type of Submission (for Early or Late Transfer)

- Agency Submitted to

- Date of Result

- Result (submission approved or rejected)

- Approved Transfer to Community Date (ATCD)

FUNC5950 3.6.12.2 Approved Transfer to Community Date as Release Date

Where no other sentence term exists for a detainee, the system must recognise a recorded Approved Transfer to Community Date as the detainee’s release date.

FUNC5951 3.6.12.3 Approved Transfer To Community Date on Release Schedule

When an Approved Transfer to Community Date has been recorded, it must be displayed on the existing screen ‘Release Schedules – (OIDRELSC)’ in the ‘DTO Mid Term’ column, replacing a calculated or overridden ‘Mid Term Date’ that would otherwise appear in this column.

FUNC5952 3.6.12.4 Approved Transfer To Community Date as Licence Start Date

When an Approved Transfer to Community Date has been recorded, the system must include it as the licence start date when producing a DTO licence.

FUNC5953 3.6.12.5 Approved Transfer To Community Date on Hot Page

When an Approved Transfer to Community Date has been recorded, the system must display this as the release date on the existing ‘Hot Page’.

FUNC5958 3.6.13 Civil Fines The system must provide the facility for a user to record and calculate terms imposed for civil fines and, where appropriate, the payment of civil fines. These imprisonment for default of payment do not receive remission, and can not form single terms with other sentences.

FUNC7699 3.6.14 Unlink Sentence Auto Start Date When a user changes a sentence recorded against an Offender from being ‘consecutive’, to ‘concurrent’, with another sentence recorded against the Offender, the system must change the ‘start date’ of the changed sentence to the ‘sentence date’ of that sentence.

FUNC7700 3.6.15 F986 Report Warrant Date When report F986 is produced for a fine sentence and a Court Appearance record exists for the date the Fine Term started, the system shall include the Warrant End Date on the report, this Warrant End Date shall be the latest Automatic Release Date (ARD) across all fine sentences for the offender case that is reported. Where an ARD does not exist then the Conditional Release Date (CRD) shall be used.


C-NOMIS RESTRICTED


FUNC500 3.7 [redacted] [redacted]





FUNC505 3.8 Offenders Relationships Offender's Relationships - record details of the offender's relationships.

FUNC506 3.8.1 Personal Officer Personal Officer - record and maintain the offender's personal officer(s), populated from a look-up table, showing officer name(s).

FUNC507 3.8.2 Offender Supervisor to Personal Officer

Change offender supervisor to personal officer

FUNC508 3.8.3 Listener Listener - record and maintain if the prisoner is a recognised 'listener'



FUNC511 3.8.6 Associations Associations - record and maintain any identified Associations between offenders.

FUNC512 3.8.7 Prisoner Not Suitable for Listener Prisoner not Suitable for Listener - record and maintain if the prisoner should not be allowed to become a Listener.


FUNC514 3.9 Offender Allocation Offender Allocation

FUNC515 3.9.1 New Work Alert New Work Alert - provide an indicator to staff that there is a new task or alert in his/her mailbox since last opened.

FUNC516 3.9.2 NOMS Offender Manager Location NOMS Offender Manager Location - identify and record the location of the NOMS Offender Manager.

FUNC517 3.9.3 NOMS Team Allocation NOMS Team Allocation - identify and record the team(s) who have responsibility for the offender. This will include the Offender Manager, Offender Supervisor, PSR writer, supervision provider, intervention provider etc.

FUNC518 3.9.3.1 Automated Team Set-Up Automated Team Set-up - provide an automatic process whereby virtual teams can be set up for workflow management.


C-NOMIS RESTRICTED


FUNC519 3.9.3.2 Court Worker Report Allocation Provide the ability to enable the Court Worker to either allocate a report request directly to an office/team or to assign the task (allocate) to the court administration team. Where a specific report author is known then the Court Worker should be able to allocate the report request to that person.

FUNC520 3.9.4 HMPS Establishment Allocation HMPS Establishment Allocation - record, allocate and maintain the name and id of the HMPS Establishment receiving the offender.

FUNC521 3.9.5 HMPS Offender Supervisor HMPS Offender Supervisor - record, allocate and maintain an Offender Supervisor for the offender.

FUNC522 3.9.6 Organisation Structure Organisation Structure - provide reports (current and historic) at the following staff grouping levels (both for HMPS, NPS and joint): National, regional, Area, sub-Area, sub-sub- Area, Office.

FUNC523 3.9.6.1 Staff Primary Address & Agency Location

Indicate staff primary address and primary agency location

FUNC524 3.9.7 Offender Manager Virtual Team Offender Manager Virtual Team - provide a facility when assigning an offender to an offender manager (primary owner) to also assign the offender manager to the offender's virtual team. If the staff member selected is an offender manager on more than one team, the user must select which of the team(s) to associate with the virtual team, otherwise the assignment defaults to the staff member's (only) team

FUNC525 3.9.8 Non Case Sensitive Search Non case sensitive search on outcomes

FUNC4342 3.10 Merge multiple bookings on a single NOMIS reference

Due to an oversight in the requirements there is no facility to merge bookings on a single NOMIS offender record. EDS receive 25 – 30 requests a day from LIDS users to perform this merge

FUNC3276 3.11 Criminal Justice & Immigration Act 2008


C-NOMIS RESTRICTED


FUNC10022

3.11.1 CJIA 2008 Sentence Calculation Rules – Release of Long Term Prisoners

For Offender records that meet the selection criteria defined below, and when calculating an Offender’s sentence key dates the system must:1) calculate their Conditional Release Date (CRD) as the halfway point of their sentence.2) record their Licence Expiry Date (LED) as equal to their Sentence Expiry Date (SED).3) no longer calculate their Parole Eligibility Date (PED). Selection criteria for Offenders under which items 1,2 and 3 above apply:- Offenders with Discretionary Conditional Release (DCR) sentences under the 1991 Criminal Justice Act with a term of 4 years or over.- AND with a Parole Eligibility Date (PED) on or after the 9th of June 2008.- AND who are not excluded because of the nature of their offences or length of sentence as defined below. Exclusion criteria:- Prisoners serving a sentence for a violent or sexual offence listed in Schedule 15 of the Criminal Justice Act 2003;- Prisoners serving a sentence for buggery under Section 12 of the Sexual Offences Act 1956 (SOA 1956);- "Existing Prisoners” i.e. those prisoners serving a custodial sentence prior to the commencement of Part 2 of the CJA 1991 on 1 October 1992. - Prisoners serving a sentence for a terrorism legislation offence for which the maximum penalty is a sentence of 10 years or over.- An offence of aiding, abetting, counselling, procuring or inciting any of the offences listed in Schedule 15, certain terrorism legislation offences, or buggery under section 12 of the SOA 1956; - An offence of conspiracy contrary to section 1(1) of the Criminal Law Act 1977 where the prisoner was conspiring to commit any of the offences listed in Schedule 15 or murder or any of the specified terrorism legislation offences or buggery under section 12 of the SOA 1956; (For example, where a warrant specifies that a prisoner has committed an offence of conspiracy establishments must identify the offence the prisoner conspired to commit in order to assess whether the offence of conspiracy falls within Schedule 15. If the prisoner conspired to commit a Schedule 15 offence or murder, the offence of conspiracy is a Schedule 15 offence);- An offence of attempt contrary to section 1(1) of the Criminal Attempts Act 1981 where the prisoner attempted to commit any of the offences listed in Schedule 15 or murder or any of the specified terrorism legislation offences or buggery under section 12 of the SOA 1956; (where a warrant specifies that a prisoner has committed an offence of attempt as defined above, establishments must identify the offence the prisoner attempted to commit in order to assess whether the offence of attempt falls within Schedule 15. If the prisoner attempted to commit a Schedule 15 offence or murder, the offence of attempt is a Schedule 15 offence).

FUNC10023

3.11.2 DCR Licence The system must provide a facility for an authorised user to produce a physical copy of a licence for an Offender as described in Annex B of PSI 17/2008.

FUNC10024

3.11.3 Bail Remand Credit Record The system must provide a facility for an authorised user to record against an Offender’s sentence, an additional type of remand for time spent during a bail period on an electronically monitored curfew. All interfaces and extracts that include the Offender’s Remand Types must account for this additional value as required by each interface.

FUNC10025

3.11.4 Bail Remand Credit Adjustment When remand for time spent during bail on an electronically monitored curfew is recorded against an Offender’s sentence the system must use this to credit the sentence it is recorded against with half the number of days recorded, if half the number of days is not a whole number then it must be rounded up before crediting. The system must take this credit into account when determining an Offender's calculated release dates.


C-NOMIS RESTRICTED


FUNC10026

3.11.5 Youth Rehabilitation Order Sentence When recording a Sentence against an Offender’s Court Case the system must provide the option to record an outcome of ‘Youth Rehabilitation Order’.All interfaces and extracts that include the Offender’s Sentence Types must account for this additional value as required by each interface.

FUNC10899

3.11.6 Youth Rehabilitation Order Outcome When recording a Court Outcome against an Offender’s Court Case the system must provide the option to record an outcome of ‘Youth Rehabilitation Order’. All interfaces and extracts that include the Offender’s Court Case Outcomes must account for this additional value as required by each interface.

FUNC10027

3.11.7 Violent Offender Order Sentence When recording a Sentence against an Offender the system must provide the option to record a sentence type of ‘Violent Offender Order’.All interfaces and extracts that include an Offender’s Sentence Types must account for this additional value as required by each interface.

FUNC10900

3.11.8 Violent Offender Order Outcome When recording a Court Outcome against an Offender the system must provide the option to record an outcome of ‘Violent Offender Order’. All interfaces and extracts that include an Offender’s Court Case Outcomes must account for this additional value as required by each interface.

FUNC10028

3.11.9 YRO Breach Offence When recording an offence against an Offender the system must provide the option to record ‘Breach of Youth Rehabilitation Order’. All interfaces and extracts that include an Offender’s Offences must account for this additional value as required by each interface.

FUNC10029

3.11.10 VOO Breach Offence When recording an offence against an Offender the system must provide the option to record ‘Breach of Violent Offender Order’. All interfaces and extracts that include an Offender’s Offences must account for this additional value as required by each interface.

FUNC10036

3.11.11 Fixed Term Recall Sentence When recording a Sentence against an Offender's Court Case the system must allow the user to select a sentence type of '28 Day Fixed Term Recall'.All interfaces and extracts that include the Offender’s Sentence Types must account for this additional value as required by each interface.

FUNC10037

3.11.12 Violent Order Document The system must provide the facility for a user to produce a Violent Order document. MORE DETAIL REQUIRED AS TO WHETHER THIS IS BEING DONE IN PRISONS AND HOW.


C-NOMIS RESTRICTED


FUNC10038

3.11.13 Indeterminate Imprisonment Status When recording the imprisonment status of an Offender the system must allow a user to select one of the following custody types:- ‘MLP, Adult Mandatory’- ‘DLP, Adult Discretionary’- ‘ALP, Automatic’- ‘HMP, Detention During Her Majesty’s Pleasure’- ‘IPP, Imprisonment for Public Protection’- ‘DPP, Detention for Public Protection’- ‘CFL (S93), Custody for Life – Mandatory’- ‘CFL (S94), Custody for Life – Discretionary’- ‘DFL, Detention for Life’ All interfaces and extracts that include the Offender’s Imprisonment Status must account for these additional values as required by each interface.

FUNC526 4 Recognition Technology Recognition Technology

FUNC527 4.1 Prisoner Biometrics Prisoner Biometrics - capture and match human biometrics for the prisoner.

FUNC528 4.1.1 Biometrics (Fingerprints) Capture Biometrics (Fingerprints) Capture - capture and retain biometrics by fingerprints.

FUNC529 4.1.2 Biometrics (Iris Scan) Capture Biometrics (Iris Scan) Capture - capture and retain biometrics by iris scan using the BIOAPI Standard.

FUNC530 4.1.3 Biometrics Recognition Biometrics Recognition - match biometric data against existing data within NOMIS. One to one match ie look up person and check biometric matches the person. Allow match without pre selection of an identified digit. Provide the facility to be able to access recognition function directly from tool bar as well as from other defined functions such as visits and reception.

FUNC531 4.1.4 Biometrics Database Search Biometrics Database Search - provide the facility to search a biometric database to identify a person. One to many match. Option to restrict biometric database to watch-list (ie only selected persons).

FUNC532 4.1.5 Biometrics Watch List Biometrics Watch-list - create a sub-set of the biometric database which includes Banned visitors. Need to be able to add / remove biometrics as visitor is banned / unbanned tied to the 'banned visitors, module within the TAG Visist package.

FUNC533 4.1.6 Biometrics Database Search (AFIS) Biometrics Database Search - provide the ability to search 1 to many records (AFIS system) via a biometric capture function.

FUNC2675 4.1.7 Biometric Evaluation Equipment Procurement

Purchase of ten x 2 manufacturer Single Fingerprint Scanners for evaluation and early adopter deployment and 10 print fingerprint scanner evaluation unit.


C-NOMIS RESTRICTED


FUNC3095 4.1.8 Change title of PD for Biometrics Whilst we do not believe that this is a CR, nevertheless, the biometrics report should show the following options to enable the Authority to take a view on feasibility and affordability.

In order for the correct options to be deployed within C-NOMIS in the correct manner it is imperative that a fully detailed and costed options report be created. It should state the costings within any report and contain the following options as a minimum:1. Integration of single fingerprint readers (ANSI /NIST compliant for IDENT 1 and IND compatibility) for offender registration and addition of readers to the Quantum catalogue.2. Integration of ten print readers (ANSI /NIST compliant for IDENT 1 and IND compatibility) for visitor registration.3. Enhancement of the central system and infrastructure to support the stated offender volumetrics (ANSI /NIST compliant for IDENT 1 and IND compatibility)4. Enhancement of the central system and infrastructure to support the stated visitor volumetrics (ANSI /NIST compliant for IDENT 1 and IND compatibility)5. Transfer mechanism for Offender biometric information to be transferred to the Police to the correct standard (currently non interface for 1.1 but required as an interface at a later stage nominally 1.2)6. Live capture of Images of Offenders and/or Visitors to the approved standard.7. [redacted]8. Support for mobile devices to operate as visitor and offender validation units.9. An AFIS capability to the agreed requirements but with costings for different response times (for example only, 1 minute, 2 minute, 5 minute, 10 minute.)10. The complete package.

FUNC3098 4.1.9 Change to Biometrics Clarification document

Following Biometrics review meeting on 04/04/07, some of the biometrics requirements set out in the Biometrics Clarification document ver 1.4 have been modified, principally to exclude several requirements from R1.1, and nominally place in R2.0 (i.e. after all legacy replacement has been achieved). A revised paper, ver 1.5 (dated 04/04/07 has been issued. Briefly, this puts the one-to-many fingerprint functionality and the AFIS database outside R1.1 to R1.3, with the exception of the banned visitors functions. EDS are requested to quote (a) for the biometrics functionality for R1.1 without the AFIS (one to many) fingerprint functionality (b) to quote for the biometrics functionality for R1.1 with the AFIS functionality (one to many) for the limited Visitors banned list, as agreed at the Biometrics meeting on 3 April.

FUNC3114 4.1.10 Biometrics Clarification document - version change from 1.5 to 1.6

version change following Authority agreement on reduced scope of biometrics for 1.1, 1.2 & 1.3

FUNC534 4.2 ID Card Technology ID Card Technology - provide ID card technology for prisoners and/or visitors.

FUNC535 4.2.1 Provision of Identity Badges Provision of Identity Badges - provide ability to produce an ID Card (or replacement) for a person held in NOMIS (Prisoner or Visitor). Record ID card issue details. Optionally include Chip and Pin capabilty including biometric data.

FUNC536 4.2.2 ID Card Production ID Card Production - provide audit report of prisoner ID cards issued

FUNC537 4.3 Electronics Photographs Electronic Photographs - capture and display electronic photographs for both offenders and visitors.

FUNC538 4.3.1 Electronic Photograph Capture Electronic Photograph Capture - capture and store electronic photographs

FUNC539 4.3.2 Electronic Photograph Update Electronic Photograph Update - provide the capability to update electronic photographs to accepted standard eg PITO.

FUNC540 4.3.3 Photographs on Documents Photographs on Documents - provide the ability to print photographs on selected documents and reports.


C-NOMIS RESTRICTED


FUNC541 4.3.4 Distinguishing Marks Photographs Distinguishing Marks Photographs - provide the capability to record electronic photographs to accepted standard eg PITO and comments of distinguishing marks.

FUNC542 4.3.5 Distinguishing Marks Photographs Update

Distinguishing Marks Photographs Update - provide the capability to update electronic photographs to accepted standard eg PITO and comments of distinguishing marks.

FUNC543 4.3.6 Distinguishing Marks Photogrpahs on Documents

Distinguishing Marks Photographs on Documents - provide the ability to print photographs of distinguishing marks on selected documents and reports.

FUNC2660 4.3.7 Digital Camera Early Adopters Digital camera selected by NOMS to provide mug-shot images to C-NOMIS Early Adopters needs to be validated by EDS Applied Engineering (AE) team against the Quantum Refresh platform.NOMS have selected and procured Fuji Finepix A345 digital cameras to be utilised by Early Adopters in the capture of mug-shot images within the C-NOMIS business process. These cameras will be attached to Quantum Refresh Desktop platform and data capture would be driven from this digital camera, [redacted]. Images would then be imported into C-NOMIS using the current Syscon TAG capability.EDS AE team will need to validate the compatibility of this camera with the Refresh platform and work with the C-NOMIS project team to prove the solution is fully integrated from both an application and infrastructure perspective. Any impact on the Refresh support model introduced by these devices will need to be considered.NOMS will need to identify users who are authorised to use the camera in Live Services, for inclusion in the AE Sanctuary profile.

FUNC2687 4.4 Addition of [redacted] to NOMIS and Quantum Sanctuary

Provide [redacted]

FUNC544 5 Visits Management Visits Management

FUNC545 5.1 Visit Planning Visit Planning - manage the process of planning a visit.

FUNC546 5.1.1 Visitor Approval Request Visitor Approval Request - record a prisoner request for a visitor.

FUNC547 5.1.1.1 Create Persons Screen Button A change should be made to add a 'new' button to the offenders approved visitor selection screen, this button will take the user to the create persons screen, once they have finished creating the person they will be taken back to the selection screen with the newly created visitor in the list ready for selection.

FUNC548 5.1.2 Visiting Orders Visiting Orders - generate and store a Visiting Order to be sent to a visitor.

FUNC549 5.1.3 Visiting Order Print Visiting Order Print - print for mailing a Visiting Order to be sent to visitors.

FUNC550 5.1.4 Visiting Order Update Visiting Order Update - update and reissue a Visiting Order.

FUNC551 5.1.5 Visiting Order Number Visiting Order Number - generate a unique visit order number.

FUNC552 5.1.6 Prisoner's Visit Allowance Prisoner's Visit Allowance - record and maintain for each prisoner the different types of local allowance.

FUNC553 5.1.6.1 Unused Visit Entitlement Unused Visit Entitlement - maintain a count of an offender's unused visit entitlement. This entitlement will continue to accumulate and can be manually modified.


C-NOMIS RESTRICTED


FUNC554 5.1.7 Accumulated Visits Accumulated Visits - record and maintain for each prisoner the authorization of accumulated visits.

FUNC555 5.1.8 Multiple Visitors Multiple Visitors - record and maintain details of all visitors attending the same visit and note the 'lead visitor' (point of contact).

FUNC556 5.1.9 Visits to Multiple Prisoners Visits to Multiple Prisoners - record and maintain details of all prisoners attending the same visit.

FUNC557 5.1.10 Internet Visits Booking Internet Visits Booking - provide an Internet interface to permit a potential visitor to progress a visit booking.

FUNC558 5.1.11 Book Social Visit Book Social Visit - record details of a requested visit, including time, location and (optionally for remand prisoners) a unique visit order number, including any visitor disability needs.

FUNC559 5.1.12 Book Non Social Visit Book Non Social Visit - record details of a requested visit, including time and location. Book Non Social Visit - record details of a requested visit, including time and location. If the non social visitor is an NPS representative then the visit must be automatically recorded on the probation schedule as well as the visits schedule.

FUNC560 5.1.13 Town Visits Town Visits - record details of a town visit. Town visits cause the offender's visit allowance to be reduced but do not require a VO or space to be booked in a visits room.

FUNC561 5.1.14 Approve or Reject a Visit Approve or Reject a Visit - record if the booking request is accepted or rejected and reason. A change should be made to add a 'new' button to the offenders approved visitor selection screen, this button will take the user to the create persons screen, once they have finished creating the person they will be taken back to the selection screen with the newly created visitor in the list ready for selection.

FUNC562 5.1.15 Validate Booking Request Validate Booking Request - check the request against the offender's existing scheduled events and activities.

FUNC563 5.1.16 Visit Allowance Validation Visit Allowance Validation - check against prisoner's visit allowance, including any accumulated allowance.

FUNC564 5.1.17 Visit Order Visit Order - provide facility to cancel Visit Order with reason. Visit Order - provide a facility for authorised users to cancel a Visit Order with cancellation reason. When a visit order is cancelled the offenders allowance must be re-adjusted to add the cancelled visit order to their allowance. Any visit bookings held against the visit order must be automatically cancelled

FUNC565 5.1.18 Visitor Numbers Visitor Numbers - validate visitor numbers against visitor seating/tables to prevent overbooking.


FUNC567 5.1.20 Governor Adjustments Governor Adjustments - allow a standard Visiting Order to be exchanged for a pre-defined number of Privileged Visiting Orders.


FUNC4332 5.1.22 Create Remand Visits rules and mandating

The system is capable of recording remand visits but there are no business rules or governors on the system to control the volume of VOs booked if establishments book remand visits on Prison NOMIS.

FUNC569 5.2 Visitor Details Visitor Details - record visitor details.


C-NOMIS RESTRICTED


FUNC570 5.2.1 Social Visitor Details Social Visitor Details - record and maintain the following visitor details: Surname, Forename, Middle Names, Address and Post Code, Telephone & e-mail contacts, Gender, Date of Birth, Relationship to prisoner.

FUNC571 5.2.2 Non Social Visitor Details Non-Social Visitor Details - record and maintain the following visitor details: Name, Company Address and contact details.

FUNC572 5.2.3 Unique Visitor Number Unique Visitor Number - allocate a unique (personal) number to each visitor.

FUNC573 5.2.4 Visitor Number Association Visitor Number Association - incorporate the unique visitor number into any tagging or ID card technology used.

FUNC574 5.3 Visitors Validation Visitors Validation - validate the visitor information against banned & approved lists.

FUNC575 5.3.1 Approved Prisoner Visitors Approved Prisoner Visitors - maintain the following prisoner restriction lists: Approved Child Visitors, Approved Visitors. A warning should be generated for anyone under the age of 18.

FUNC576 5.3.2 Validate Approved Visitor Validate Approved Visitor - validate visitor against prisoner's approved list when booking visit.

FUNC3117 5.3.2.1 Under Age person as lead Visitor

Two visitors can be created, one visitor over the age of 18 and one visitor under the age of 18. There is a warning message that highlights that the second visitor is underage when selecting visitors. When selecting the under-age visitor to be the lead visitor, there is no message warning the user that the lead visitor is underage and the user can carry on to log the under age visitor. Ssystem should actively prevent under age visitor from beinig recorded as lead visitor.

Currently documentation does not specify rules for this scenario and does not state that there should be any warning message displayed if a visitor under the age of 18 is selected as the lead visitor.

The validation rule is simply stated as: 'Only one visitor may be 'Lead Visitor'. One visitor must be selected'. This is not a defect. This appears an obvious oversight and a change to include this will maintain consistency within the application.Defect 6608 refers

FUNC577 5.3.3 Approved Official Visitors Approved Official Visitors - maintain a central list of official visitors, for example, probation officers, lawyers, job centre staff. Note that no VO is required for these visitors.

FUNC578 5.3.4 Banned Visitors Banned Visitors - record and maintain information on visitors that have been banned from visiting particular prisoners or establishments generally.

FUNC579 5.3.5 Banned / Restricted Visitor Warning Banned / Restricted Visitor Warning - warn the user when an attempt is made to book a visit with a banned or restricted visitor.

FUNC580 5.3.6 Banned Visitor Authorisation Banned Visitor Authorisation - record who authorised the visit, if a banned visitor is authorised to visit.

FUNC581 5.3.7 Visit Type Visit Type - record and maintain the visit type.



C-NOMIS RESTRICTED




FUNC585 5.3.11 Prisoner Restriction Warning Prisoner Restriction Warning - warn the user when an attempt is made to book a visit for a prisoner with restrictions [redacted]

FUNC586 5.4 Visit Details Visit Details - record details of the actual visit.

FUNC587 5.4.1 Actual Visit Details Actual Visit Details - record details of the actual visit including APVU indicator if appropriate


FUNC589 5.4.3 List of Selected Visits List of Selected Visits - provide list of selected visits and be able to record the actual visit details (as per E4a and E4b) for each selected visit, ie provide batch update screen.

FUNC590 5.4.4 Record of Visits Record of Visits - provide a list of a prisoner's Visit Orders and associated Visit Bookings and provide the ability to access the Visit Order or Visit Booking details directly from the list.

FUNC591 5.4.5 Visit Order Balance Visit order balance to be included in transfer report

FUNC592 6 Prisoner Finances Prisoner Finances

FUNC593 6.1 Manage Incomings Manage Incomings - record all prisoner credit transactions.

FUNC594 6.1.1 Received Monies Received Monies - credit to the prisoner's account all cash or cheques received by post.

FUNC595 6.1.2 Automatic Activity Earnings Update Automatic Activity Earnings Update - create automatic credit transactions for activity earnings. Needs to cater for daily / weekly credits, Piecemeal activities, programme participation, non activity earnings (eg Sickness, Unemployment etc) and no pay-policy exceptions (eg Refusal to work, Court attendance etc).


C-NOMIS RESTRICTED


FUNC3769 6.1.2.1 Amendment and Deletion of Future Dated Establishment Pay Profiles

For the existing C-NOMIS screen ‘Maintain Agency Pay Profile (OIMAGPAY)’ the following create, update and delete rules will apply to payment profiles.

1. When a new profile is created, or amended, the system will enforce the ‘From Date’ of the new or amended profile to be equal to or greater than today’s date, and, if other profiles exist for the Agency, the system will enforce the ‘From Date’ of the new or amended profile to be greater than the ‘From Date’ of the chronologically latest existing profile.

2. When a new profile is created, and other profiles exist, the system will enforce the ‘To Date’ of the chronologically latest existing profile to equal the new profile’s ‘From Date’ minus one day.

3. The system will allow a user to update all pay profile values contained within the ‘Detail’ frame of ‘Maintain Agency Pay Profile’ where the ‘From Date’ of the profile is greater than or equal to today’s date. If the ‘From Date’ of a profile is less than today’s date then the system must not allow the user to update the pay profile values.

4. The system will allow a user to update the ‘From Date’ of all profiles where that ‘From Date’ is greater than or equal to today’s date. The ‘From Date’ maybe updated according to the rules specified in point 1 above.

5. When the ‘From Date’ of a profile is updated, and an existing pay profile exists for the Agency that chronologically precedes the updated profile, the system will enforce the ‘To Date’ of the preceding profile to equal the updated profile’s ‘From Date’ minus one day.

6. The system will allow a user to delete all pay profiles where the ‘From Date’ of the profile is greater than or equal to today’s date. If the ‘From Date’ of a profile is less than today’s date then the system must not allow the user to delete the profile.

7. When a pay profile is deleted, and the deleted pay profile is chronologically the latest of all existing pay profiles for that Agency, the system will identify the profile that chronologically precedes the deleted profile and remove the ‘To Date’ of that identified profile.

When a pay profile is deleted, and the deleted pay profile is not chronologically the latest of all existing pay profiles for that Agency, the system will identify the profile chronologically preceding the deleted profile and change the ‘To Date’ of that identified profile to the ‘From Date’ minus one day of the profile that chronologically follows the deleted profile.

FUNC596 6.1.3 Manual Activity Earnings Update Manual Activity Earnings Update - create manual credit transactions for activity earnings.

FUNC597 6.1.4 Compensation Payments Compensation Payments - credit compensation payments to the prisoner's account, including comments field.

FUNC598 6.1.5 Bonus Payments Bonus Payments - credit bonus payments to the prisoner's account.

FUNC599 6.1.6 Canteen Refunds (Outsourced Canteen)

Canteen Refunds (Outsourced Canteen) - credit canteen spends to the prisoner's account where the prisoner has not received or has rejected the goods.

FUNC600 6.1.7 Canteen Refunds (HMPS Run Canteen)

Canteen Refunds (HMPS Run Canteen) - credit canteen spends to the prisoner's account where the prisoner has not received or has rejected the goods.

FUNC601 6.1.8 Discharge Payments Discharge Payments - record money given to prisoner at discharge.

FUNC602 6.1.9 Discharge Grant Discharge Grant - provide the facility to pay a discharge grant to a prisoner.


C-NOMIS RESTRICTED


FUNC603 6.1.10 Cheque Hold Cheque Hold - credit funds paid into a prisoner's account by cheque only once the funds are cleared.

FUNC604 6.1.11 Clearing of Beneficiaries Clearing of beneficiaries

FUNC605 6.1.12 Prisoner Budget Prisoner Budget

FUNC606 6.1.13 Prisoner Earnings Prisoner Earnings

FUNC607 6.1.14 Modify Discharge Balance Screen / Report

Discharge Balance Screen/Report

FUNC608 6.1.15 Global Payments Global payments

FUNC609 6.1.16 Transfer Savings Account on Migration from LIDS

Currently on migration of legacy data) an offender's savings account is not transferred as a separate account balance (it is added to the balance of the private cash account).

FUNC3116 6.1.17 Taxable Earnings/National Insurance Report

develop a report(s) that identifies and lists all those prisoners whose earnings have taken them above the Income Tax or National Insurance threshholds. The report(s) will include those prisoners who meet the criteria and have also been discharged from the prison.

FUNC3119 6.1.18 Move "Automated Offender Pay" forward from Release 1.2 to Release 1.1

The business has requested that automated offender pay be brought forward from release 1.2 to 1.1. The attached document specifies those detailed requirements for automated offender pay that expand on the existing high level requirement F1b1 as found in the project requirements catalogue.

FUNC6350 6.1.19 Record Monies Sender The system shall allow a user to record the full first name, full surname, full address and contact telephone number for senders of each instance of monies received by prisoners.

FUNC610 6.2 Manage Outgoings Manage Outgoings - record all prisoner debit transactions automatically.

FUNC611 6.2.1 Canteen Spends (Outsourced Canteen)

Canteen Spends (Outsourced Canteen) - electronically read and record canteen/shop spends activity and automatically debit the account balance.

FUNC612 6.2.2 Canteen Spends (HMPS Run Canteen)

Canteen Spends (HMPS Run Canteen) - electronically read and record canteen/shop spends activity and automatically debit the account balance.

FUNC613 6.2.3 External Money Transfers External Money Transfers - record money issued and its destination, including issued cheques/postal orders.

FUNC614 6.2.4 Prisoner Money Advances Prisoner Money Advances - record advances to the prisoner and associated reason.

FUNC615 6.2.5 Prisoner Advance Repayment Plan Prisoner Advance Repayment Plan - set up a repayment plan and payback frequency for prisoner money advance.

FUNC616 6.2.6 Prisoner Advance Repayment Prisoner Advance Repayment - record repayments made and deduct from advance balance.


C-NOMIS RESTRICTED


FUNC617 6.2.7 Paying Off Fines and Debts Paying Off Fines and Debts - record money paid by the prisoner towards reducing outstanding fines and debts.

FUNC618 6.2.8 Catalogue Spends Catalogue Spends - record prisoner ordered and disburse payment to catalogue service.

FUNC619 6.2.9 Scheduled Payments Scheduled Payments - set up, transact and record scheduled payments by prisoner or batch.

FUNC620 6.2.10 Pin-Phone Pin-Phone - record prisoner spends in purchasing pin-phone credit from the prisoner's spends account.

FUNC6351 6.2.11 Record Monies Recipient The system shall allow a user to record the full first name, full surname and full address for recipients of each instance of monies sent out by prisoners.

FUNC621 6.3 Multiple Prisoner Accounts Multiple Prisoner Accounts - manage several separate accounts for each prisoner.

FUNC622 6.3.1 Multiple Accounts Multiple Accounts - automatically set up and maintain four main separate prisoner accounts - Spends, Earnings, Private Cash and Advances, and allow creation of further account types.

FUNC623 6.3.2 Running Balance Running Balance - display/print out a running balance across all of the prisoner accounts. Provide detailed transaction history and produce a statement on request.

FUNC624 6.3.3 Money Transfers between Accounts Money Transfers between Accounts - record and maintain money transfers between the prisoner's accounts. Allow manual transfers between accounts or be able to set up a regular transfer between accounts (up to specified limits).

FUNC625 6.3.4 Account Ownership Account Ownership - transfer all prisoner information, including prisoner accounts, when a prisoner transfers between establishments.

FUNC626 6.3.4.1 Automatic Account Transfer Automatic Account Transfer - automatically transfer prisoner accounts (subject to business rules) when a prisoner transfers between establishments.

FUNC627 6.3.5 Comment at Header Level Comment at Header Level - provide a comment field at batch header level with option to overwrite for an individual transaction. Use the new comment for each individual payment entered on the screen but provide the ability to override the comment for an individual payment.

FUNC628 6.4 Prisoner Spend Limit Prisoner Spend Limit - monitor the prisoner's spend limit as dictated by his/her IEP level.

FUNC629 6.4.1 Prisoner Spend Limt Prisoner Spend Limit - prevent overspends from the prisoner's accounts as dictated by his/her IEP level and conviction status.

FUNC630 6.4.2 Monitor Maximum Spend Monitor Maximum Spend - identify occurrences of spending of more than 10 times the access to private cash limit.

FUNC631 6.5 Accounts Closure Accounts Closure - close accounts when a prisoner is discharged from custody.

FUNC632 6.5.1 Accounts Closure on Discharge Accounts Closure - close all accounts when a prisoner is discharged from custody and repay credit funds to prisoner. Prevent further updates to the account and provide offender with a form to sign confirming he has received the funds.


C-NOMIS RESTRICTED


FUNC633 6.5.1.1 Discharge Transactions The following transactions must be able to be applied on a single discharge screen, from which a discharge balance report can be produced. The transactions that need to be entered and applied include: - Temporary Absence Amount (can be entered if being discharged temporarily and will come off the private cash sub-account amount)- Subsistence Grant- Travel Grant- Discharge Grant and - Spending Sub-Account Balance- Private Cash Sub-Account Balance- Savings Sub-Account Balance- Un-cleared Funds- Available Private Cash Balance (i.e. Private Cash minus Uncleared Funds)- Advances (Obligations on TAG)- Credit Total (Spending Sub-Account Balance + Private Cash Sub-Account Balance + Savings Sub-Account Balance - Un-cleared Funds)- Debit Total (Advances)- Total Cash)- Cashier Total (Money prepared by the cashier)- Latest Total (see below for detail)- Difference (Cashier Total - Latest Total) In the case of a temporary discharge:Latest Total = Temporary Absence Amount + Subsistence Grant + Travel Grand + Discharge Grant)In the case of a final discharge:Latest Total = Total Cash + Subsistence Grant + Travel Grant + Discharge GrantIn the case of a discharge to court:Latest Total = the same as for final discharge but cashier will determine whether to give the prisoner money or not.In the case of a transfer:This screen would not need to be used in the case of an offender transferring to another establishment. All of the Offender's balances will be transferred automatically; the Offender will never take cash with them

FUNC4562 6.5.1.2 Discharge Balance Screen Modifications to the C-NOMIS Discharge Balance Screen (OTDDSBAL) to improve usability.

FUNC4563 6.5.1.3 Discharge Balance Report Modifications to the C-NOMIS Discharge Balance Report to improve usability.

FUNC4553 6.5.2 Read Only Amount to Be Disbursed The ‘Amount to Be Disbursed’ field must be read-only and display the same amount as displayed in the ‘Regular Sub Account Balance’ field.

FUNC634 6.6 Establishment Accounts Establishment Accounts - maintain establishment account information.

FUNC635 6.6.1 Establishment Accounts Management

Establishment Accounts Management - record and maintain establishment account structures and provide an interface between TAG and Phoenix.

FUNC636 6.6.2 Reconcile Prisoner Accounts Reconcile Prisoner Accounts - reconcile prisoner accounts with establishment accounts.


C-NOMIS RESTRICTED


FUNC4420 6.7 Transfer Funds Out Transaction Description

When a prisoner’s prison account balances are transferred out of an Establishment, the description of all financial transactions that are recorded to represent that transfer out will be as follows: ‘Transfer out to caseload’ + [CASELOAD] + [Transfer out description] Where [CASELOAD] is the code recorded in C-NOMIS to represent the caseload to which the prisoner is being transferred, for example, ‘ALI’ (representing the Albany Establishment caseload).Where [Transfer out description] is the description that a user enters if they are transferring funds manually out of C-NOMIS, if the funds transfer is automatic then this description will be blank.

FUNC4421 6.8 Transfer Funds In Transaction Description

When a prisoner’s prison account balances are transferred into an Establishment, the description of all financial transactions that are recorded to represent that transfer in will be as follows: ‘Transfer in from caseload’ + [CASELOAD] Where [CASELOAD] is the code recorded in C-NOMIS to represent the caseload from which the prisoner is being transferred, for example, ‘NWI’ (representing the Norwich Establishment caseload).

FUNC6352 6.9 Monies In and Out report The system shall report instances of prisoners receiving large quantities of cash from outside sources and subsequently sending cash outside. The report shall include the source of receipts and destination of sent monies. The system shall allow the definition of a 'large' quantity of cash to be defined by a user.

FUNC6353 6.10 Monies Sent to Other Prisoners Report

The system shall report instances of prisoners sending money to a large number of prisoners across multiple establishments or within the same establishment. The system shall allow the definition of a 'large' number of prisoners to be defined by a user.

FUNC637 7 Programme & Activity Management Programme & Activity Management

FUNC638 7.1 Activity Allocation Activity Allocation - allocate (manually or automatically) an activity or a set of activities to a prisoner.

FUNC639 7.1.1 OASys Sentence Plan OASys Sentence Plan - record the OASys sentence plan.

FUNC640 7.1.2 Manual Prisoner Selection Manual Prisoner Selection - manually select a prisoner for a full or part-time activity place.

FUNC641 7.1.3 Waiting Lists Waiting Lists - maintain waiting lists for activities. Capture the reason when an offender is rejected after being placed on a waitlist (such as offender withdrawn, security risk etc)

FUNC642 7.1.3.1 Assign Multiple Offenders to an Activity

Assign multiple offenders to an activity - Enable more that one offender on a waitlist to be assigned to an activity in a single action. The user should be able to select one or more offenders on the waitlist and then use a single action to assign those selected to the same activity.

FUNC643 7.1.3.2 Retrospective Set-Up of Projects & Allocations

Permit retrospective data entry


C-NOMIS RESTRICTED


FUNC644 7.1.4 Activity Places Availability Activity Places Availability - record, maintain and list employment, programmes and education places available both locally and across the estate.

FUNC645 7.1.5 Maintain Activity Definitions Maintain Activity Definitions - record and maintain details of activities.

FUNC646 7.1.6 Maintain Activity Type Exclusions Maintain Activity Type Exclusions - record and maintain the exclusions that may apply for certain activities and indicate inappropriate prisoner allocations.

FUNC647 7.1.7 Prisoner Refusal to Work Prisoner Refusal to Work - record and maintain if the prisoner has refused to participate in activities.

FUNC648 7.1.8 Specified Activities Detail Specified Activities - capture the following on the specific activities requirement (at time of sentencing): activity name, name of provider, location of activity, length of each session that the offender is to participate in, number of days (duration).

FUNC649 7.1.8.1 Offenders Assigned to a Programme Offenders Assigned to a Programme - provide a list of offenders assigned to a programme or activity for a specified date range.

FUNC650 7.1.9 Specified Activity ETE Specified Activity ETE - capture the education advancement achieved.

FUNC651 7.1.10 Specified Activity Levels Specified Activity Levels - capture levels of engagement and understanding for an offender at a session.

FUNC652 7.1.11 Behaviour at a Requirement Session Behaviour at a Requirement Session - capture behaviour of an offender at a session for any of the following requirements: supervision and unpaid work.

FUNC653 7.1.12 Behaviour at Attendance Centre Behaviour at an Attendance Centre - capture behaviour of an offender at a session an attendance centre.

FUNC654 7.1.13 Specified Activities Days Specified Activities Days - maintain a count of the number of days that an offender has completed against the total number of days that were ordered.

FUNC655 7.2 Amend Activities Amend Activities - record any changes to a prisoner's activity list or schedule.

FUNC656 7.2.1 Maintain Changes Amend Activities - record and maintain any changes to a prisoner's activity list or schedule.

FUNC657 7.2.2 Do not Require Offender at Activity Do not require offender at an activity

FUNC658 7.3 Activity Attendance Activity Attendance - record and update the attendance (and total time) of a prisoner at their employment/activity.

FUNC659 7.3.1 Manual Activity Attendance Recording

Manual Activity Attendance Recording - record the attendance and time spent by prisoners engaged in their activities.

FUNC660 7.3.2 Automatic Activity Attendance Recording

Automatic Activity Attendance Recording - perform the automatic recording of attendance and time spent by prisoners engaged in their activities.

FUNC661 7.3.3 Activity Interruptions Activity Interruptions - record activity interruptions for regime monitoring purposes. Record the interuption timing and the reason for the interruption.


C-NOMIS RESTRICTED


FUNC4337 7.3.4 Link Purposeful Activity to internal movements and activities to automate regime

Request for Post 1.0e release

Link Purposeful Activity to internal movements and activities to automate regime monitoring

Additional benefits can be accrued if all relevant regime data and internal movements control can be linked to attendance at activities and time out of cell. This will replace an onerous data collection exercise that is currently done manually in prisons and will release cashable savings.

FUNC662 7.4 Activity Performance Activity Performance - record attainment information on a prisoner's employment or activity performance.

FUNC663 7.4.1 Prisoner Induction Prisoner Induction - record the attendance and outcome of each stage of the Induction activity.

FUNC664 7.4.2 Education / Training / Activities Education/Training/Activities - record and maintain prisoner performance and behaviour at an activity and any attainments of education.

FUNC665 7.4.2.1 Attendance Pay Report During pilot it was anticipated that TAG pay module would be integrated with TAG Service Catalogue. Earnings pay could then be automatically calculated based on Offenders attendance. However this did not cater for additional piece work pay. A field was therefore added to the attendance screen to cater for this amount. It was later determined that the integration of the TAG pay module could not be achieved for Release 1.0. As a result it was agreed that the full pay amount could be captured on the attendance screen and this amount could then be reported out for posting to the Offender's account. During pilot Syscon developed a daily report linked to the Activity Attendance screen.

FUNC666 7.4.3 End Activity End Activity

FUNC667 7.5 Drug Testing Drug Testing - select candidates for mandatory drug testing and record the test results.

FUNC668 7.5.1 Random Drug Test List Random Drug Test List - generate a list of prisoners, randomly selected from the general prisoner population, to be drug tested.

FUNC669 7.5.2 Print Random Drug Test List Print Random Drug Test List - print the random drug test list (multiple times if necessary)

FUNC670 7.5.3 Drug Test Details (MDT & VDT) Drug Test Details (MDT & VDT) - record the reference details, confinement times, sample details (including barcode number from security seal), results of all drug tests and any actions taken based on the result. This information needs to be recorded on both the log and against an offender.

FUNC671 7.5.4 MDT Log MDT Log - record details of type, location and status of a sample for drug testing, any actions taken as a result of the outcome and adjudications results. This information needs to be recorded on both the log and against an offender.

FUNC672 7.5.5 Remove Middle Name Remove middle name from OIDRANDP

FUNC673 7.5.6 DTTO/DRR Appointment Schedule DTTO/DRR Appointment Schedule - schedule an appointment in offender diary when a drug test will take place. This may be during an existing appointment (with a staff member). Location may be Probation or Treatment Provider premises.


C-NOMIS RESTRICTED


FUNC674 7.5.7 DTTO/DRR Attendance DTTO/DRR Attendance - capture attendance details for offender attendance at a drug test, which should include the following:- date- time- location- outcome of test (positive, negative, no test)- action to be taken (LOV to be defined)Refusal to submit to test should result in a FTA/FTC.

FUNC675 7.5.8 DTTO/DRR Sample Type DTTO/DRR Sample Type - capture the type of sample(s) taken at a drug test:- Urine test- Oral fluid test- Gas Chromatography/Mass Spectrometry (GC/MS).

FUNC676 7.5.9 DTTO/DRR Test Type DTTO/DRR Test Type - capture, for each sample taken, the type of test to be performed and for which individual or categories of drugs (Amphetamines, Benzodiazepine, Cocaine, Methadone, Opiates, Morphine specific, Cannabinoids, Bruprenorphine (Subutex), Ecstacy).

FUNC677 7.5.10 DTTO/DRR Test Result DTTO/DRR Test Result - ability to record test results for each specific drug or category of drug tested.

FUNC678 7.5.11 DTTO/DRR Disclaimer DTTO/DRR Disclaimer - ability to capture that a sample has not been provided at a scheduled drug test because the offender has admitted to using drugs since their last test or since sentence. Ability to capture the drugs the offender has admitted taking. Ability to record that the offender has completed and signed a disclaimer form and to record the staff member who witnessed the offender signing the disclaimer form.

FUNC679 7.5.12 DTTO/DRR Ref Id DTTO/DRR Ref Id - capture a reference number for each sample taken at a test appointment. This will include barcode numbers for oral samples.

FUNC680 7.5.13 Delete Requirement Delete Requirement

FUNC681 7.5.14 DTTO/DRR Action DTTO/DRR Action - capture the action to be taken for a positive drug test, which may be one of:- no action- warning letter- removal from treatment programme- enforcement.

FUNC682 7.5.15 DTTO/DRR Allocation DTTO/DRR Allocation - allocate an offender to a Counselling Programme or to Structured Day Care (an activity) as part of a DRR order.

FUNC683 7.5.16 DRR SDC Attendance DRR SDC Attendance - capture attendance type, level of behaviour and free comments for offender attendance at a Structure Day Care activity.

FUNC684 7.5.17 DRR Assessment DRR Assessment - assess an offender and schedule a drug test appointment for the offender prior to that offender being placed on a DRR order.

FUNC685 7.5.18 Drug Test Appointment Case Note When an offender gives a sample for a drug test during any appointment, then an additional automatic case note for that appointment should be written after the results of the drug test are captured, so that a single automatic case note on the offender contact log includes both the appointment and the outcome of the drug test.


C-NOMIS RESTRICTED


FUNC686 7.5.19 DRR Bulk Attendance Report DRR bulk attendance and associated report

FUNC687 7.5.20 External Agencies External Agencies throughout the system

FUNC4338 7.5.21 Add frequent or suspicion MDT functionality

Request for post 1.0e Release

Add frequent or suspicion testing to MDT functionality so that there is one co-ordinated case management system for this area.

FUNC4535 7.5.22 Automatic Case Notes for Positive MDT

When a positive MDT result is recorded for a prisoner, the system must automatically record a case note for that prisoner containing the details of the MDT result.

FUNC688 7.6 OBP / SAP Participation Offending Behaviour (OBP)/Substance Abuse Programme (SAP) participation - record the participation of a prisoner engaged in an OBP or SAP.

FUNC689 7.6.1 Offender Behaviour Programmes (OBP)

Offending Behaviour Programmes (OBP) - record and maintain the participation and results/attainments information relating to prisoners allocated to an Offending Behaviour Programme.

FUNC690 7.6.2 Substance Abuse Programmes (SAP)

Substance Abuse Programmes (SAP) - record and maintain the referral to and consequent participation and results/attainments information relating to prisoners allocated to a Substance Abuse Programme.

FUNC691 7.6.3 Post Release Monitoring - View Post Release Monitoring - view the participation and results/attainments information relating to former prisoners allocated to an Offending Behaviours Programme or Substance Abuse Programme after their release from custody.

FUNC692 7.6.4 Anti-Bullying Strategy Participation Anti-Bullying Strategy Participation - record and maintain the prisoners that are engaged in the Anti- Bullying strategy programme.

FUNC693 7.6.5 Post Release Monitoring - Maintenance

Post Release Monitoring - record and maintain the participation and results/attainments information relating to former prisoners allocated to an Offending Behaviours Programme or Substance Abuse Programme after their release from custody.

FUNC694 7.7 Unpaid Work Unpaid Work (currently ECP)

FUNC695 7.7.1 Placement Details Placement Details - log placement details to enable the management of unpaid work placement.

FUNC696 7.7.1.1 Placement Quality Standard Placement Quality Standard - assess and record the Placement Quality Standard (PQS) offered by the unpaid work placement. Provide history of PQS reviews (enable PQS reviews to be listed in chronological order).

FUNC697 7.7.2 Supervisor & Tutor Details Supervisor & Tutor Details - capture the name of the Supervisor for each unpaid work session and capture the name of the Tutor who delivers a GSL component on that session.

FUNC698 7.7.3 Offender Allocation Offender Allocation - allocate an offender to a series of placements and/or site sessions. Provide placement availability and offender availability details from the offender diary.


C-NOMIS RESTRICTED


FUNC699 7.7.3.1 Offender Needs Information The system must provide manual capture of the following offender needs information: 1. Lifestyles and Associates Interpreted Score2. Emotional Wellbeing Interpreted Score3. Attitudes Interpreted Score4. Thinking & Behaviour Interpreted Score5. Education, Training and Employability Interpreted Score' These scores must each have a value of 0, 1 or 2

FUNC700 7.7.4 Attendance Recording Attendance Recording - record the attendance and absence (acceptable or unacceptable) of an offender at a placement/site session. Record the GSL component of attendance at an unpaid work placement, to include:- provider name- duration- comments.

FUNC701 7.7.4.1 Guided/Basic Skills Learning When recording unpaid work project attendance the system must provide the ability to record Guided Skills Learning and/or Basic Skills Learning components for which the attendance also counts towards. These may or may not be specified activities. The provider, team and/or officer delivering these must also be recorded for each component along with any comments

FUNC702 7.7.4.2 Unpaid Work Bulk Attendance Unpaid work permits bulk entry of attendance by project. It also allows entry by individual offender. What is also required is the functionality to permit bulk entry of attendance by offender within a chosen date range

FUNC703 7.7.5 End Requirement End Requirement - Manually record the following details when an offender ends any type of order requirement or licence condition: Date ended- Reason for ending- Free text commentThe user name of the user ending the requirement should also be captured

FUNC704 7.7.5.1 Licence with Missing Address Warning message for licence with missing address

FUNC705 7.7.5.2 Exclusion Detail Window Amendment

Amend exclusion detail window for licence

FUNC706 7.7.5.3 Supervision Detail Window Amendment

Amend supervision detail window for licence

FUNC707 7.7.5.4 Amend PPO Licence Condition Amend PPO licence condition

FUNC708 7.7.5.5 Unpaid Work Credits Unpaid Work Credits

FUNC709 7.7.6 Travel Costs Travel Costs - record travel costs and travel time for an offender against a placement allocation.

FUNC710 7.7.7 Assign Offender to Unpaid Work Placement

Assign an Offender to an Unpaid Work Placement - capture intended start and end times for the offender for each day they are scheduled to attend. These start and end times may not be the same as the scheduled start and end times for the placement.


C-NOMIS RESTRICTED


FUNC711 7.7.8 Penalising the Offender Penalising the Offender - capture the number of hours that an offender is to be penalised for unacceptable behaviour or unacceptable quality of work on an Unpaid Work placement.

FUNC712 7.8 Supervision by Non-NOMS Providers

Supervision by non-NOMS providers

FUNC713 7.8.1 Non-NOMS Provider Non-NOMS Provider - record details of non-NOMS providers.

FUNC714 7.9 Component Delivery & Performance Component Delivery and Performance

FUNC715 7.9.1 Attendance Details Attendance Details - record the offender's attendance (including start and end times) or failure to attend. This should be captured for the following order requirements: accredited programmes, unpaid work, specified activities and attendance centres.

FUNC716 7.9.2 End Requirement End Requirement – Record the following details when an offender ends any type of order requirement or prison activity or licence condition:- Date ended- Reason for ending- Free text comment- User nameFor all requirements/conditions apart from programme requirements, ending a requirement or activity must automatically clear from the offender diary any future scheduled appointments for that requirement.

When ending a programme requirement a check must be made for active programmes within that requirement. If there are active programmes then the user should be warned and prevented from terminating the parent programme requirement. Future scheduled appointments for a programme must be cleared before the parent requirement is ended.When applicable, ending a requirement or activity for an offender must increase the places available on that specific requirement by 1.

A requirement/activity may be ended manually due to normal or early completion.

A requirement/activity may be ended automatically as a result of:- Release of the offender from custody- Transfer of the offender to a different prison establishment or to a different probation area (in this case the requirement/activity might end in transferred from location and recommence in transferred to location – it would still have to be completed)

FUNC717 7.10 Service Catalogue Service Catalogue

FUNC718 7.10.1 Catalogue of Requirements Resources

Catalogue of Requirements Resources - record and maintain name, address and contact details for all requirement providers. For each provider, the following should be captured:- requirement types being offered- types of offender accepted (gender, age, offence)- maximum number of offenders per session (or in total)- area, region- disabled access.

FUNC719 7.10.1.1 Accredited Programmes & Interventions

Accredited Programmes & Interventions (Requirements) - provide the ability to search for programmes and other requirements by area, by title and by programme/placement name.


C-NOMIS RESTRICTED


FUNC720 7.10.1.2 Order Requirements Order Requirements - capture the following for each type of requirement:- number, frequency and length of sessions- maximum number of offenders per session- types of offenders accepted or excluded (gender, age, ethnicity, offence).

FUNC721 7.10.2 Brokerage Requirements Brokerage Requirements - assessment of brokerage requirements for specific interventions.

FUNC722 7.10.2.1 Programmes & Services Provided Programmes & Services Provided - capture a contract reference id, whether a service or programme is a spot purchase and monitor the use of call-off services and programmes (in terms of identifying a call-off service/programme and capturing numbers of places used).

FUNC723 7.10.3 Offender Waitlist Referral Offender Waitlist Referral - enable the offender to be added to the intervention service provider's waitlist.

FUNC724 7.10.3.1 Service Demand File Service Demand File - provide a facility to record and maintain on a 'service demand file' details of unsuccessful searches on the Service Catalogue where the required service is not available or is available but not in the required geographic area. The user making the unsuccessful search to indicate if the details are to be added to the file.

FUNC725 7.10.3.2 Offender Referral Offender Referral - provide the facility to automatically refer of an offender to a suggested programme. Manual override should be possible. Provide the facility to record the outcome of the referral and any further action, depending on the recommendations.

FUNC726 7.10.4 Accredited Programmes Accredited Programmes - capture the following for each programme:- who approved accreditation of the programme- structure of programme (modular, sequential, etc)- psychometric assessments associated with the programme- maximum number of tutors allowed to be involved in delivery of a course- number, frequency and length of sessions in a course- maximum number of offenders per course- number of catch-up sessions permitted and when.

FUNC727 7.10.5 Programme Scheduling Programme Scheduling - schedule programmes, courses, sessions and resources. There may be different rules for different courses.

FUNC728 7.10.5.1 Programme Scheduling Override Programme Scheduling Override - override the generated schedule for an accredited programme, capturing the authorising officer name and status.

FUNC729 7.10.6 Appointment for Participants in Activity

Make Appointments for Participants in Activity - allow a set of participants to be allocated to an activity, e.g. a group of offenders who will attend a delivery of a Think First programme, then automatically make appointments for each participant.

FUNC730 7.10.7 Session Assessment Session Assessment - assess and record the delivery of a session.

FUNC731 7.10.8 Pre & Post Programme Sessions Pre & Post Programme Sessions on Accredited Programmes - capture Type of Attendance, Level of Engagement, Level of Understanding and free format text for all Pre and Post Programme sessions on an Accredited Programme.

FUNC732 7.10.9 Catch-Up Sessions Catch-up Sessions - create a catch-up session on the programme schedule prior to the next scheduled session.

FUNC733 7.10.10 Catch-Up Session Count Catch-up Session Count - maintain a count of the catch-up sessions for an offender for a programme.


C-NOMIS RESTRICTED


FUNC734 7.10.11 Residency Residency - enable the specified addredd where the offender must reside to be captured with the Residency order requirement.

FUNC735 7.10.12 Service Providers Treatment Key Worker

Service Providers Treatment Key Worker - capture the name of the key worker who assumes responsibility for the offender (during treatment or otherwise) for the following requirements:- alcohol treatment- drug rehab requirement- mental health treatment- drug treatment- residency- curfew- attendance centre- specified activity.

FUNC736 7.10.13 Mental Health Treatment Practitioner

Mental Health Treatment Practioner - capture the name of the psychiatrist/practioner (who has proposed treatment and is willing to provide it) and any other additional comments against the mental health treatment requirement, at time of sentencing.

FUNC737 7.10.14 Tutor Records Tutor Records - capture and maintain tutor accreditation (registration) and a record of which programmes a tutor has been trained to deliver.

FUNC738 7.10.15 Video Assessment Video Assessment - hold the reference to an assessment of a videoed session of a programme.

FUNC739 7.10.15.1

Scoring The system must provide the ability to record a score in answer to several questions. The scores need to be added per block of questions and totalled/averaged overall. Reporting against these scores must be included in the solution. The business process is that the treatment manager, scores the questions while assessing the video performance (having the full form on screen). These scores need to be then logged in Tag. It is possible that this could be through the assessment process or through a dedicated screen. Syscon should investigate all possible solutions and indicate the effort for each. Requirement 2:This is not of such importance - tutors review their performance after each session . On occasions there may be 3 tutors involved. The scores need to be added per block of questions and totalled/averaged overall. Reporting against these scores must be included in the solution. Notes = Syscon to confirm that the staff requirements in IAPS are already met in Tag:- Tutors can be noted as registered (accredited) in staff details.- Registration is against a programme so some tutor staff will be registered for more than 1 program.- Counts of sessions delivered by Tutors must be possible- Entering dates of registration and de-registration must be possible - with a reason for de-registration- Attrition of staff (how many registered tutors left within a period by programme) must be possible (see above point re reasons for de registration

FUNC740 7.10.15.2

Sex Offender Questionnaire & HMP Assessments

Evaluation measures - sex offender questionnaire and remaining HMP assessments if/when OBPU come on board

FUNC741 7.10.16 Pilot Programmes Pilot Programmes - it must be possible to set up a pilot programme within a geographic Area and restrict access to the pilot programme.


C-NOMIS RESTRICTED


FUNC742 7.10.17 Accredited Programmes Waitlists Accredited Programmes Waitlists - provide the ability to maintain and sort a waiting list for each programme and for each module of a modular programme. For each offender on the waitlist, the following information should be available:- length of time waiting- time remaining on order- age of offender- offence- home location (town)- availability (ie evenings only)- gender and ethnicity

FUNC743 7.10.18 IAPS Data Extract IAPS Evalutaion measures data extract

FUNC744 7.10.19 View All Appointments Provide a View of All Appointments - provide a view of all appointments at a location for one day (useful for receptionists).

FUNC745 7.10.20 Pilot Programmes Pilot Programmes - provide the ability for specific areas to pilot programmes.

FUNC746 7.11 Rolling Programmes Rolling Programmes

FUNC747 7.11.1 Rolling Modular Programmes Rolling Modular Programmes - provide the ability to set up rolling modular programmes, in which an offender must participate in a 'package' of various programme components, in a pre-defined sequence.

FUNC748 7.11.2 Pre & Post Programme Work Pre- and Post-Programme Work - provide the ability for a package to start with pre-programme work (interviews, appointments) and end with similar post-programme work.

FUNC749 7.11.3 Capacity Capacity - restrict a group to a pre-defined number of offenders in a group at any one time.

FUNC750 7.11.4 Drop Out Drop Out - note the vacancy, if an offender drops out, and allow a replacement offender on a waiting list to start at the beginning of the next permitted module.

FUNC751 7.11.5 Pre Programme Appointments Pre-Programme Appointments - provide the ability to pre-define recurrent-schedule rules for pre-programme appointments, to be delivered by the Offender Manager.

FUNC752 7.11.6 Pre & Post Sessions for Multiple Offenders

Pre- and Post-Programme Sessions Administered To Multiple Offenders - provide the ability to pre-define scheduled dates and locations for this type of session.

FUNC753 7.11.7 Blocks for a Phase Blocks for a phase

FUNC754 7.11.7.1 Definition of Rolling Modules Definition of 'Rolling' Modules - provide the facility for an offender in a rolling modular programme to have to complete the rolling modules in order but be able to start at the beginning of any module.

FUNC755 7.11.7.2 Define Sessions Define Sessions - provide the ability to define, for each rolling module, a specific number of sessions required and a gap of a specific period of time between each module.

FUNC756 7.11.7.3 Schedule Dates/Time Schedule Dates/Time - provide the ability to schedule dates/times and locations for each session within a module.


C-NOMIS RESTRICTED


FUNC757 7.11.8 Offender Attendance Offender Attendance - provide a session register on which to record attendance of all offenders for each scheduled session at a single point of entry. Include offender, date, whether s(he) attended, any issues and a score for the level of understanding and level of engagement. This information is used to identify improvements (or not) throughout the programme or can be aggregated and inserted into the post programme report. A template for the post programme report should be populated automatically.

FUNC758 7.11.9 Allowable Offender Absences Allowable Offender Absences - provide the ability to pre-define a maximum number of allowable offender absences at a rolling modular programme session.

FUNC759 7.11.10 Non-Rolling Sessions in Rolling Modular Programme

Non-Rolling Sessions Within a Rolling Modular Programme - provide the ability to pre-define a maximum number of allowable offender absences at a rolling modular programme session.

FUNC760 7.11.11 Post Programme Appointments Post-Programme Appointments - provide the ability to pre-define necessary post-programme offender appointments, that must occur within a specific period of time from the end of a core programme.

FUNC761 7.11.12 Offender Restarts Offender Restarts - provide the ability to pre-define the maximum allowable number of offender restarts permitted in a rolling modular programme, after which the offender can be breached.

FUNC762 7.11.13 Open and Closed Sessions Open and Closed Sessions - provide the ability to indicate open and closed sessions on a course. An open session is defined as one which an offender can join (and thereby start the course) if there is space. A closed session is defined as one which an offender cannot join, even if there is space

FUNC763 7.11.14 Performance Reports Performance Reports - ensure that the data to generate performance reports is supported by TAG.

FUNC764 7.11.15 Tutor Responsibilities Tutor Responsibilities - capture hours of programme time delivered by each tutor in a year.

FUNC765 7.11.15.1

Tutors & OMs Delivering Programme Session

All Sessions (Pre Programme, Core Programme and Post Programme) on Accredited Programmes - capture the names of all tutors and offender managers who have participated in delivery of an Accredited Programme session. There may be more than one tutor involved in any single session.

FUNC766 7.11.16 Treatment Manager Supervision Treatment Manager Supervision - record if a session has been supervised by a treatment manager.

FUNC767 7.11.16.1

Video Monitoring Reviews Record video monitoring reviews against the relevant session

FUNC4331 7.12 Change to the Activities Functionality Design

The activities functionality has unnecessary steps and has poor ergonomic design. A redesign of this aspect of Prison NOMIS functionality to improve flow and reduce time taken on the application.

FUNC768 8 Prisoner Property Management Prisoner Property Management

FUNC769 8.1 Property Details Property Details - record details of all prisoner property.

FUNC770 8.1.1 Property Reference & Details Property Reference and Details - record and maintain details of all property, including serial number, bag seal number, date of receipt, receipt code / source of the property item quantity, colour, description


C-NOMIS RESTRICTED


FUNC771 8.1.2 Property Location Property Location - record the location of any stored property.

FUNC772 8.2 Prisoner Property Management Technology Interface

Prisoner Property Management Technology Interface - automate the documentation of property.

FUNC773 8.2.1 Labelling Prisoner Property Prisoner Property Management Technology Interface - provide a means of labelling all prisoner's property (collectively in bags or boxes) such that it can be read/identified electronically.

FUNC774 8.3 Property Management Property Management - manage and record the location and status of all prisoner property.

FUNC775 8.3.1 Request Change in Property Status Request for Change in Property Status - record the request from a prisoner to move property from one location to another.

FUNC776 8.3.2 Change in Property Status Change in Property Status - record the change in status and/or location of an item of property.

FUNC777 8.3.3 Property Disposals / Removals Property Disposals / Removals - record property items that have been disposed of or destroyed with the date of disposal and reason.

FUNC778 8.3.4 Property Changes Authorisation Property Changes Authorisation - record electronically the authorisation of all property changes/updates, to include prisoner, property and prison staff identifications.

FUNC779 8.3.5 Stored Property Return Stored Property Return - provide the ability to identify items in long terms storage and generate a list of these items.

FUNC780 8.3.6 Cell Clearance Cell Clearance - record details of property bagged during a cell clearance and the staff involved.

FUNC781 8.4 Prison Issue Clothing Prison Issue Clothing - record the issue of prison issue clothing for the prisoner.

FUNC782 8.4.1 Maintain Prison Issue for Prisoner Prison Issue Clothing - record and maintain the issue of prison issue clothing for the prisoner.

FUNC783 8.5 Valuable Valuable - record all valuable property.

FUNC784 8.5.1 Valuable Property Image Valuable Property Image - record an electronic image for items classified as valuable and link this to the property reference.

FUNC785 8.6 Property Confiscations Property Confiscations - record property items that are held because of a confiscation.

FUNC786 8.6.1 Temporary Confiscations Temporary Confiscations - record the items temporarily confiscated, including the date of confiscation, reason, proposed date of return to prisoner.

FUNC787 8.6.2 Permanent Confiscations Permanent Confiscations - record the items permanently confiscated, including the date of confiscation, reason and the disposal mechanism.

FUNC788 8.6.3 Confiscation & Destruction Orders Confiscation and Destruction Orders - record confiscation orders and destruction orders.

FUNC789 9 Prisoner Movements Prisoner Movements


C-NOMIS RESTRICTED


FUNC790 9.1 Prisoner Tracking Prisoner Tracking - record prisoner movements.

FUNC791 9.1.1 Prisoner Activity Movements Prisoner Activity Movements - record all prisoner movements between secure areas.

FUNC792 9.1.2 Prisoner Movement ID Card or Tagging

'Prisoner Movement ID Card or Tagging - utilize ID card or tagging (bracelet) to enable real-time recording of all prisoner movements between secure areas.

FUNC793 9.1.3 Area Movement Control Area Movement Control - indicate when a prisoner enters areas inappropriate for that prisoner, using the activity schedule and/or prisoner banning orders.

FUNC794 9.1.4 In Transit Code It has been agreed that for Release 1, the wings will note the departure time for a group of named offenders on paper and the workshops will note the arrival time of each named offender on paper. The workshops will enter the arrival time into NOMIS when time and resources allow. Introduction of an 'In Transit' code would allow offenders to be tracked between locations. This would require both wings and workshops to enter the time at which each individual named offender left or arrived at a location. It is recognised that this is not practical without some form of electronic monitoring, eg. swipe cards and portable readers

FUNC795 9.2 Roll Check Roll-Check - generate 'lock-in' roll-check lists and record the roll-check results.

FUNC796 9.2.1 Roll Check Lists Roll-Check - generate the roll-check lists, including prisoner cell location, and record the results of the roll-check processes.

FUNC797 9.2.2 Electronic Roll Board Electronic Roll Board - list the current location of prisoners identified at the last roll-check process.




FUNC801 9.3.3 Keep Beds Keep Beds

FUNC802 10 Offender Complaints Offender Complaints

FUNC803 10.1 Record Complaints Record Complaints - record complaints from offenders.

FUNC804 10.1.1 Complaint Log Complaint Log - record and maintain a complaints log, including unique reference number, category and complaint details.

FUNC805 10.2 Complaint Monitoring Complaint Monitoring - monitor the progress of complaints.

FUNC806 10.2.1 Complaint Assignment Complaint Assignment - assign responsibility for responding to the complaint to the required person(s) for action .

FUNC807 10.2.2 Complaint Progression Complaint Progression - record and maintain the progress of all complaints in terms of creation date, date of distribution to action group, action progress date and date of response issue.


C-NOMIS RESTRICTED


FUNC808 10.2.3 Overdue Complaint Responses Complaint Progression - compile a list of overdue complaint responses.

FUNC809 10.2.4 Complaints Ombudsman Referral Complaints Ombudsman Referral - record if a complaint has been referred to the Complaints Ombudsman.

FUNC810 10.3 Complaint Outcome Complaint Outcome - record the outcome of a complaint from an offender.

FUNC811 10.3.1 Record Complaint Outcome Complaint Outcome - record the outcome of the complaint.

FUNC812 10.3.2 Feedback to Offender Feedback to Offender - record the communication to the offender of the complaint outcome.

FUNC813 10.3.3 Complaint Appeals Lodged Complaint Appeals Lodged - record and maintain details of any appeals lodged by an offender against a complaint outcome.

FUNC814 11 Prisoner Requests Prisoner Requests

FUNC815 11.1 Record Requests Record Requests record requests from prisoners.

FUNC816 11.1.1 Request Log Request Log - record and maintain a request log, including unique reference number, type, date application made and additional details.

FUNC817 11.1.2 Request Progression Request Progression - record and maintain the progress of each request raised.

FUNC818 11.1.3 Overdue Request Actions Request Progression - compile a list of overdue request actions.

FUNC819 11.2 Request Outcomes Request Outcomes - record the outcome of a request from a prisoner.

FUNC820 11.2.1 Record Outcome of Request Request Outcome - record the outcome of the request.

FUNC821 11.2.2 Feedback to Prisoner Feedback to Prisoner - record the communication to the prisoner of the Request outcome.

FUNC822 12 Incidents & Observations Incidents & Observations

FUNC823 12.1 Incident Recording Incident Recording - record offender incidents.

FUNC824 12.1.1 Incident Details Incident Details - record and maintain all reportable incidents and associated details including all offenders involved and their roles in the incident through selection of an appropriate incident type code.

FUNC825 12.1.2 Additional Incident Details Additional Incident Details - record and maintain detail from additional officers, linked to one incident number.

FUNC826 12.1.3 Unique Incident Identifier Unique Incident Identifier - allocate a unique number to each incident raised.

FUNC827 12.1.4 Incident Status Incident Status - record and maintain incident status


C-NOMIS RESTRICTED


FUNC828 12.1.5 Amend Incident Reporting Design Amend Incident Reporting Design as follows: - Incident Reporting - enable enhanced user to set and update Incident Follow-up Date.Provide field validation as follows:o Field is optionalo Field is only maintainable by enhanced usero Field must be a valid dateo Date must be greater than today but less than or equal to today plus 1 monthNote: Incident Follow-up Date - date when open incident is due to be reviewed. Normally specified when additional information is requested from establishment or when other incident information is awaited. - Incident Enquiry - enable user to list open incidents where Incident Follow-up date is due or overdue

FUNC829 12.1.6 Incident Alerts to NPS Managers Incident Alerts to NPS Managers - alert appropriate managers to all serious offences.

FUNC830 12.1.7 Incident Type Specific Screen Configuration

Incident Type Specific Screen Configuration - record and display appropriate Incident Detail dependent upon the Incident Type.

FUNC831 12.1.8 Incident Follow-Up Action Incident Follow-Up Action - record and maintain additional details and actions where incidents previously recorded require follow up action.

FUNC832 12.1.9 Photographic Incidents Evidence Photographic Incidents Evidence - record prisoner or incident digital photographs with a free-format comment field.

FUNC833 12.1.10 Incidents Evidence Incidents Evidence - record the existence and location of any video footage within the incident record.

FUNC834 12.1.11 Incident Types Incident Types - maintain incident types and their associated information input requirements such that a user selecting a particular type is requested for all data relating to that type

FUNC835 12.1.12 Prisoner Details & Location Snapshot

Prisoner Details & Location Snapshot - record the location and details of all incident-related prisoners at the date and time of the recorded incident.

FUNC836 12.1.13 Notice Board Link Notice Board Link - provide the ability to display key or selected incidents information to selected managers at log on.

FUNC837 12.2 Observations Recording Observations Recording - record staff observations about individual offenders.

FUNC838 12.2.1 Roll Check Roll-Check - generate the roll-check lists, including prisoner cell location - to be delivered in Release 1.0

FUNC839 12.2.2 Offender History Offender History - record and maintain all events, special information and observations relevant to the daily events for an offender.

FUNC840 12.3 Incident Questionnaires Incident Questionaires - manage questionaires to record incident details.

FUNC841 12.3.1 Creation of Questionnaires Creation of Questionnaires - allow creation of a set of valid questions and answers, to attach to an Incident Type. Responses to a particular answer should point to the next valid question.

FUNC842 12.3.2 Completing a Questionnaire Completing a Questionnaire - automatically present the first valid question when an Incident Type is selected. From the response, present the next appropriate question, until the questionnaire is complete.


C-NOMIS RESTRICTED


FUNC843 12.3.3 Changing a Questionnaire Changing a Questionnaire - retain all previous completed questionnaires against the previous format if the questionnaire is changed for an Incident Type.

FUNC844 12.3.4 Incident Update Notification When any incident details are changed the system should automatically set the incident status to indicate that details have been updated. Incidents are raised by establishments and analysed by NOU.On the current IRS incident reporting system, when NOU require additional information, they send a message to the establishment who then respond or update the incident; which is re-transmitted back to NOU.NOMIS has been enhanced to provide similar functionality, in that NOU can request additional information (NOU set incident status to indicate information required) and the establishment update the incident (establishment change incident status to indicate information updated).

FUNC845 13 Adjudications Adjudications

FUNC846 13.1 Adjudication Preparation Recording Adjudication Preparation Recording - record adjudication charges and details.

FUNC847 13.1.1 Maintain Adjudication Charge Details

Adjudication Charge - record and maintain the adjudication charge details.

FUNC848 13.1.2 Adjudication Offence Details Adjudication Offence Details - record and maintain offence details and supporting evidence relating to the adjudication charge.

FUNC849 13.1.2.1 Record Wing Report Record Wing Report - provide the facility to record a Conduct report for an offender for inclusion at an Adjudication hearing.

FUNC850 13.1.2.2 Record Control & Restraint Details Record Control and Restraint details (for creation of C& R report).

FUNC851 13.1.3 Adjudications following Occurrences Adjudications following Occurrences - record and maintain occurrences associated to the adjudication.

FUNC852 13.1.4 Adjudication Hearing Date Adjudication Hearing Date - record and maintain an adjudication hearing date for each adjudication charge raised

FUNC853 13.1.5 Diary Adjudication Hearing Date Diary Adjudication Hearing Date - schedule adjudication date into the prisoner's diary.

FUNC854 13.1.6 Multiple Adjudication Prisoners Multiple Adjudication Prisoners - provide the facility whereby a charge may relate to one or more prisoners, each of whom may be subject to one or more charges. Charges may be heard at one or more adjudication hearings

FUNC855 13.1.7 Adjudication Offence Documents Adjudication Offence Documents - print the offence details in various formats, with all the previously input details pre-populated on the form.

FUNC856 13.1.8 Adjudication Documents Adjudication Documents - store Adjudication Documents once generated and printed.

FUNC857 13.1.9 Record Prisoner Told of Adjudication Record Prisoner Told of Adjudication - record the time that the prisoner was served with the adjudication documentation.

FUNC858 13.1.10 Impending Release Check Impending Release Check - indicate if an impending discharge from custody is scheduled when recording a new adjudication charge against a prisoner.


C-NOMIS RESTRICTED


FUNC859 13.1.11 Adjudication Offence History Adjudication Offence History - provide detail of prisoner offence history.

FUNC860 13.1.12 Version Controlled Charges Version Controlled Charges - provide a version controlled list of adjudication charge references and legal wording. The wording which is in effect at the time the charge is laid must be used even if the legal wording is subsequently changed.Release: Not for Release 1.0

FUNC3135 13.1.13 Validation of age field on Occurrence Details Recording screen

Currently it is possible to allocate an adult adjudication code to a YO and vice versa. Age validation needs to be added to the Occurrence Details Recording screen.

FUNC861 13.2 Adjudication Preparation Adjudication Preparation - record requests for witnesses etc at the adjudication.

FUNC862 13.2.1 Legal Advice Legal Advice - record if legal advice has been requested by the prisoner, whether it has been granted, the reason for refusal and contact details of the legal representative.

FUNC863 13.2.2 McKenzie Friends McKenzie Friends - record if a McKenzie Friend has been requested to attend the adjudication hearing.

FUNC864 13.2.3 Prisoner Adjudication Witness Prisoner Adjudication Witness - record and maintain witnesses and their statements of evidence.

FUNC865 13.2.4 Hearing Attendees Hearing Attendees - record the attendees at the adjudication hearing.

FUNC866 13.3 Adjudication Hearing Adjudication Hearing - record the adjudication hearing.

FUNC867 13.3.1 Record of Hearing Form Record of Hearing Form - print a Record of Hearing and Adjudication document with charge and incident details pre-populated.

FUNC868 13.3.2 Adjudication Medical Fitness Adjudication Medical Fitness - record the result of the medical fitness for cellular confinement assessment of the prisoner. The name of the examiner must also be recorded.

FUNC869 13.3.3 Adjudication Hearing Transcript Adjudication Hearing Transcript - record a textual transcript of the adjudication-hearing event.

FUNC870 13.3.4 Adjudication Audio Transcript Files Adjudication Audio Transcript Files - provide the capability to attach audio transcript files for adjudication-hearing proceedings.

FUNC871 13.3.5 Prisoner Conduct Report Prisoner Conduct Report - record if any conduct report information has been introduced to the Adjudication hearing.

FUNC872 13.3.6 Refusal to Attend Refusal To Attend - record when a prisoner refuses to attend the hearing.

FUNC873 13.4 Adjudication Outcome Adjudication Outcome - record the outcome of the adjudication.

FUNC874 13.4.1 Adjudication Findings Adjudication Findings - record a finalised Record of Hearing and Adjudication notification with adjudication results recorded thereon.

FUNC875 13.4.2 Adjudication Notification Adjudication Notification - notify persons of result of the adjudication eg Finance, Sentence Calculation etc.


C-NOMIS RESTRICTED


FUNC876 13.4.3 Prisoner Finance Update Prisoner Finance Update - record any changes to the prisoner's finances dictated by adjudication results, including Loss of earnings, Fines and Loss of Canteen.

FUNC4536 13.4.4 Automatic Case Notes for Adjudications

When an adjudication award is recorded for a prisoner, the system must automatically record a case note for that prisoner containing the details of the adjudication award.

FUNC4557 13.4.5 Restrict Applying Awards to Non Proven Charges

The system must only allow a user to record an adjudication award when a related charge has been recorded as proven against a prisoner.

FUNC877 13.5 Appeals Details Appeals Details - record details of appeals lodged following the adjudication.

FUNC878 13.5.1 Appeals Lodged Appeals Lodged - record details and outcome of any appeals lodged by a prisoner.

FUNC879 13.5.2 Overturned Adjudications Authorisation

Over-Turned Adjudications Authorisation - record all rescinded adjudication punishments previously recorded for all successful appeals.

FUNC880 13.5.3 Terminate Punishment Terminate Punishment - provide the ability to terminate an adjudication punishment if the prisoner is physically or mentally unfit to continue and record the reasons for doing so. This must be subject to manual approval before being applied.

FUNC881 13.6 Minor Report Minor Report - record minor offences for young offenders (at YOIs).

FUNC882 13.6.1 Minor Offences Minor Report - record and maintain minor offences alleged against the young offender.

FUNC883 13.6.2 Minor Report Resolution Details Minor Report Resolution Details - record the resolution details for all Minor Reports.

FUNC884 13.6.3 Minor Report Generation Minor Report Generation - produce a report for issue to the young offender detailing the minor offences committed.

FUNC885 14 Population & Accommodation Management

Population & Accommodation Management

FUNC886 14.1 Establishment & Approved Premises Information

Establishment and Approved Premises information - record information on all establishments within HMPS and all Approved Premises and those externally provided within NPS.

FUNC887 14.1.1 Establishment Basic Details Establishment Basic Details - record and maintain the location Id, address and contact details.

FUNC888 14.1.2 Establishment & Approved Premises Categories

Establishment and Approved Premises Categories - record and maintain the premises type, area, gender, disability access.

FUNC889 14.2 Unit & Cell Information Unit & Cell Information - record cell-specific information.

FUNC890 14.2.1 Unit & Cell Structure Unit and Cell Structure - record and maintain the components of an establishment as a hierarchy of units . For appropriate units, record and maintain further sub-divisions into dormitories or cells.


C-NOMIS RESTRICTED


FUNC891 14.2.2 Unit & Cell Classifications Unit and Cell Classifications - record and maintain the (multiple) 'classification of use' for units/cells at the appropriate level.

FUNC892 14.2.3 Certified Normal Accommodation Certified Normal Accommodation - record and maintain the Certified Normal Accommodation (CNA)s for all cells or units of residential accommodation.

FUNC893 14.2.4 Operational Capacity Operational Capacity - record and maintain the total Operational Capacity for the establishment or total bed spaces for NPS.

FUNC894 14.2.5 Unit/Cell Non-Availability Unit/Cell Non-Availability - record and maintain non-availability period start and end dates and reason. Indicate when end date reached.

FUNC895 14.2.5.1 Determine Bed Retention A new facility is required which allows establishments to determine locally which facilities are retained (including bed retention) when an offender leaves an establishment for court or other temporary absence. The decision on whether to retain or not should be based on the reason for the absence. An override should be available. For Release 1, the out of the box functionality will suffice and activities, visits etc will need to be re-entered manually; if the offender housing move is performed to an 'OUT' location, then the bed is released; if an internal move is performed, then the bed is retained.

FUNC896 14.2.5.2 Scan Psychometric Data Scan Psychometric Data - enable psychometric data to be scanned into NOMIS directly from the offender-completed paper form.

FUNC897 14.2.5.3 Link to File of Scanned Documents Provide the capability to link to a file which contains scanned documents that are either historical, or not generared via the system

FUNC898 14.2.5.4 Non Case Sensitive Searches Searches should not be case sensitive

FUNC899 14.2.6 Booking Information Booking Information - record provisional and accepted bookings. For approved premises, allow the user to book a provisional place, confirm the booking, and then confirm arrival of the offender. Record special intervention plan (not bailees) for period of residence.

FUNC900 14.2.7 Batch Internal Scheduled Movements

Offenders are scheduled for internal movement (eg, for the Doctor's call-up list) on the system. Currently, when the time comes for the offenders to be scheduled for an appointment, out of the box functionality requires staff to enter each offender's record individually. It would be preferable to be able to schedule all activity attendants to the activity location from one batch schedule screen. Add a new batch internal schedule screen to allow a number of offenders to be scheduled to one activity at one time. This change is essential for Release 1.

FUNC901 14.2.8 End of Custody Licence LIDS - End of Custody Licence (ECL) (as per proposal from Teresa Maude)

FUNC902 14.3 Building Details Building Details - record construction details and link to building plans.

FUNC903 14.3.1 Building / Construction Details Building / Construction details - record and maintain building / construction details ranging from general building details to detailed building and constructions data for individual cells, rooms and other building 'components'.

FUNC904 14.3.2 Building Plans Building plans - provide a mapping of accommodation at an individual establishment to CAD building plans maintained centrally

FUNC905 14.3.3 Changes to Accommodation Changes to Accommodation - maintain a history trail of changes made to establishment accommodation.

FUNC906 14.3.4 Works Access to Accommodation Details

Works Access to Accommodation Details - enable Works to have update access to Accommodation details (to maintain date of when works due only).

FUNC907 14.4 Offender Location Offender Location - record the offender's occupation of a cell.


C-NOMIS RESTRICTED


FUNC908 14.4.1 Location Location - record and maintain the cell/ dormitory assigned to the offender. In case of a dormitory, record and maintain the bed number.

FUNC909 14.4.2 Location Alerts Location Alerts - indicate if the prisoner is assigned to an inappropriate cell in respect of the prisoner's requirements and risk factors and the cell's classification attributes.

FUNC910 14.4.3 Location Assistance Location Assistance - automatically generate a list of available cells that can be viewed by cell type. For each available cell automatically indicate whether there is a conflict (see note 1). Note each type of conflict should be identified in its own right ie a separate flag for each type of conflict identified. Automatically display a pop-up message on selection of a cell where a conflict was identified reminding the user to check further the suitability of the assignment, and giving the option to continue with the assignment or not. Note 1:- Cell Sharing conflict - any offender being assigned and any offender already in the cell, or for whom the cell has been reserved, has a Cell Sharing Risk assessment rating of High (as defined in the Cell Sharing Risk Assessment).Where a cell with a cell sharing conflict is selected the system should automatically display a message to the user telling them which offender is causing the conflict, remind them to check further the suitability of the assignment, and give the option to continue with the assignment or not.- Capacity conflict - number of prisoners currently in the unit exceeds the unit's operational capacity.Where a cell with a capacity conflict is selected the system should automatically display a message to the user, reminding them to check further the suitability of the assignment, and give the option to continue with the assignment or not.- Non-association conflict (prisoner conflict) - any offender already in the cell, or for whom the cell has been reserved, has a non-association with the offender being assigned .Where a cell with a non-association conflict is selected the system should automatically display a message to the user telling them which offender is causing the conflict, remind them to check further the suitability of the assignment, and give the option to continue with the assignment or not.- Security conflict - the security category of the offender being assigned does not match with the security category of the cell.Where a cell with a security conflict is selected the system should automatically display a message to the user, reminding them to check further the suitability of the assignment, and give the option to continue with the assignment or not.

FUNC911 14.4.4 Reserve Bed for Existing Prisoner Need the ability to reserve a bed for an existing prisoner who is TEMPORARILY being located in another housing location. I.e. A long term prisoner has been sent to the segregation unit for 7 days CC and their existing housing location needs to be retained

FUNC912 14.4.4.1 Reserve Vacancy for Future Date For population management, need the ability to reserve a vacancy in a prison for a future date. I.e. a high profile prisoner is being sent to a new establishment at a future date. Therefore need to set the date, and reserve a space and therefore remove one from the overall prison capacity on this date to allow space for the new prisoner to be located. (This is not reserving an individual cell, just reserve a space)

FUNC913 14.5 Transfers Transfers - record all information relevant to transfer management.


FUNC915 14.5.2 Discharge Details Transfer - record the discharge reason, actual discharge date and time (which may be different from the planned diary time), target establishment code, stopover establishment (if applicable) and escort type (e.g. contractor, police, local etc.) The offender should be identified as 'in transit' until a 'received' code is generated when the offender is received into a new establishment

FUNC916 14.5.3 Transfer to Functional Unit Transfer to Functional Unit - record details of the application for a place in a particular functional unit and the result.

FUNC917 14.5.4 Auto Transfer Auto transfer from Court or other Temporary release


C-NOMIS RESTRICTED


FUNC918 14.5.4.1 Auto Transfer Change of Release Move original 1.2 requirement to 1.0e (Auto Transfer from Court or other Temporary Release)

FUNC919 14.6 Absence from Prison Absence from Prison - record all temporary absences.

FUNC920 14.6.1 ROTL Details ROTL - record and maintain the location address, reason and due return date for a ROTL offender.

FUNC921 14.6.2 Temporary Cellular Confinement Temporary Cellular Confinement - record and maintain which prisoners are detained in other temporary cellular confinement not under HMPS control, the location and the due return date.

FUNC922 14.6.3 Establishment Component Codes Establishment Component Codes

FUNC923 14.6.3.1 CR228 Release Change Moves CR00228 to 1.1 and hence 1.0e

FUNC924 14.6.4 Minimal Personal Details when held in Police Cells

Minimal Personal Details - record minimal personal details for a (new) prisoner temporarily held in Police Cells.

FUNC925 14.6.5 Court Appearance Discharge Court Appearance Discharge - record a prisoner released as a result of a court appearance.

FUNC926 14.6.6 Hospital Appointment Discharge Hospital Appointment Discharge - record a prisoner being discharged for a hospital appointment.

FUNC927 14.6.7 Mental Health Institution Mental Health - record and maintain the Mental Health Institution holding each Mental Health offender.

FUNC4340 14.6.8 Request for Bulk scheduling of ROTLS

POST 1.0e CR

Bulk scheduling of ROTLS

Currently ROTLs for outside work parties cannot be bulk scheduled on the system. This creates additional work for staff who have to perform this as a daily function.

FUNC928 14.7 Manage Offender in Approved Premises

Manage Offender in Approved Premises

FUNC929 14.7.1 Failure to Comply Failure to Comply - manage failures to comply.

FUNC930 14.7.2 Manage Periods of Residence Manage Approved Premises - manage periods of residence.

FUNC931 15 Discharge Discharge

FUNC932 15.1 Document Permanent Discharge Discharge - document an offender being discharged from an establishment permanently.

FUNC933 15.1.1 Record Discharge Record Discharge - record a offender being discharged including type of discharge, date of discharge, date of initial appointment, and prompt for associated activities. These activities include informing NPS of the impending release of the offender, requesting licence conditions from NPS and generating a document informing the offender of the initial appointment date.


C-NOMIS RESTRICTED


FUNC934 15.1.2 Listeners Release Indicator Listeners Release Indicator - automatically warn establishments of the imminent release of a prisoner who may be involved in counselling activities.

FUNC935 15.1.3 Check Release Date before Discharge

Check Release Date before Discharge - Ability to ensure that an offender is not released from custody before the release date for that offender. The only exception to this is where a release date falls on a bank holiday or non-working day (eg Saturday or Sunday). In such cases, the offender can be released from custody on the last working day before the bank holiday / non-working day. The discharge officer must be warned if they try to complete the discharge process for an offender before the relevant release date

FUNC936 15.2 Licence Production Licence Production - produce a release licence.

FUNC937 15.2.1 Licence Conditions Licence Conditions - include provision for licence conditions/sections & subsections of Acts and facility to add new conditions.

FUNC4548 15.2.2 Licence Termination Due to Error The system must provide the facility for a user to indicate the termination of a licence due to an error.

FUNC4549 15.2.3 Licence Condition Termination Due to Error

The system must provide the facility for a user to indicate the termination of a licence condition due to an error.

FUNC5943 15.2.4 Polygraph Licence Conditions

FUNC5944 15.2.4.1 Select Polygraph Licence Condition When producing a licence for an offender the user must be able to select a licence condition that requires the offender to attend for polygraph sessions. The text of the licence condition must be as follows:

‘To comply with any instruction given by your supervising officer requiring you to attend for a polygraph session, to participate in polygraph sessions and examinations as instructed by or under the authority of your supervising officer, and to comply with any instruction given to you during a polygraph session by the person conducting the polygraph session.’

FUNC5945 15.2.4.2 Polygraph Licence Condition Trial Area Only Warning

When a user produces a licence containing a polygraph condition, the system must warn the user that the condition only applies to offenders being released in one of nine probation areas using the following text: ‘This condition is only enforceable for those prisoners returning to the West Midlands, West Mercia, Warwickshire, Staffordshire, Lincolnshire, Leicestershire, Derbyshire, Nottinghamshire, and Northamptonshire Probation Areas. Do not use this condition if the prisoner will be living elsewhere in the country.’

As stated in PSI04/09, this condition is being trialled only in the above probation areas until 31st of March 2012; therefore, this warning must be removed at the end of the trial.

FUNC5946 15.2.4.3 Polygraph Licence Condition Sentence & Offence Warning

When a user produces a licence containing a polygraph condition, the system must warn the user that the condition only applies to offenders serving a sentence of 12 months or more and convicted of a relevant sexual offence.

FUNC5947 15.2.4.4 Polygraph Licence Condition MIS Availability

The polygraph licence condition must be available for reporting on within the MIS system.


C-NOMIS RESTRICTED


FUNC938 15.3 Lifer Discharge Lifer Discharge - record information about discharged lifers.

FUNC939 15.3.1 Life Licensee Life Licensee - record and maintain the address of lifer offenders released to the community on life license. The contact details of their supervisor must also be recorded.

FUNC940 15.4 Parole Parole - administer parole for all relevant offenders both estate wide and establishment level.

FUNC941 15.4.1 Parole Review Creation Parole Review Creation - allow regular batch estate wide creation of parole review for all relevant offenders. This is to be driven by parole eligibility date or subsequent review anniversary calculation. Create review types (e.g. deportation) according to appropriate offender details.

FUNC942 15.4.2 Action Creation Action Creation - automatically create all relevant actions (depending on type of review) and calculate target dates required to complete the whole parole review.

FUNC943 15.4.3 Action Allocation Action Allocation - automatically identify and allocate actions to the responsible user role's worksheet.

FUNC944 15.4.4 Parole Worksheet Maintenance Parole Worksheet Maintenance - automatically maintain a parole worksheet for each individual parole clerk. This will highlight in chronological order all outstanding parole related work for the whole establishment.

FUNC945 15.4.5 Parole Worksheet Review Change Parole Worksheet Maintenance - Allow for the ability to change the type of review mid-process.

FUNC946 15.4.6 Reallocation on Transfer Reallocation on Transfer - automatically reallocate all outstanding parole actions on a offender transfer. This will include system identification of new responsible user roles. Alert the Offender Manager for change in prison and personal officer

FUNC947 15.4.7 Actions on Transfer Actions on Transfer - create a warning prompt to the user when entering a transfer date for an offender who has started the parole process.

FUNC948 15.4.8 Maintain Core Review Details Maintain Core Review Details - record and maintain all core review details, e.g. parole review outcome, if pending or final outcome, and parole review outcome date, any subsequent PED and review date.

FUNC949 15.4.9 Parole Audit Parole Audit - record all work done, when and by whom for each individual review action. This will be automatically reflected in worksheets and parole review schedules.

FUNC950 15.4.10 Parole Opt-Out Maintenance Parole Opt-out Maintenance - maintain a record of parole opt out/in by the prisoner. Record when prisoner decides to opt out or back in to parole process by date.

FUNC951 15.4.11 Outstanding Actions Removal Outstanding Actions Removal - remove outstanding actions from relevant worksheets on opt-out and re-insert on opt-in.

FUNC952 15.4.12 Recalculation of Schedule Recalculation of Schedule - recalculate parole review schedule if the offender decides to opt back in.

FUNC953 15.4.13 Parole Panel Maintenance Parole Panel Maintenance - arrange record and maintain estate wide parole panels.

FUNC954 15.4.14 Parole Panel Recording Parole Panel Recording - record actual parole panel details, panel type (e.g. psychiatric), location, decisions, reason, date.

FUNC955 15.4.15 Allocation of Case to Panel Allocation of Case to Panel - provide a facility to allocate manually (estate wide) cases ready for panel to next available or specified panel.


C-NOMIS RESTRICTED


FUNC956 15.4.16 Parole Board Maintenance Parole Board Maintenance - maintain parole board details manually. Record any added or deleted cases or amendment of any of the board members.

FUNC957 15.4.17 PED Change PED Change - identify cases where the Parole Eligibility Date (PED) has been changed, due to sentence re-calculation.

FUNC958 15.4.18 PED Target Dates Override PED Change - allow action target dates to be manually overridden.

FUNC959 15.5 HDC Recalls HDC Recalls - administer Home Detention Curfew recalls estate wide and at establishment level for all relevant offenders.

FUNC960 15.5.1 HDC Recall Review HDC Recall Review - allow manual insertion of HDC recall reviews.

FUNC961 15.5.2 HDC Recall Review Schedule HDC Recall Review Schedule - automatically create HDC recall review schedule by action, target date and time.

FUNC962 15.5.3 HDC Core Details HDC Core Details - maintain core details of HDC recall review, e.g. recall reception date, breach conditions, appeal outcome.

FUNC963 15.5.4 HDC Recall Review Actions HDC Recall Review Actions - maintain HDC recall review individual actions and record date and time completed.

FUNC964 15.6 Early Removal Scheme Early Removal Scheme - administer an Early Removal Scheme (ERS) for all relevant offenders, both estate wide and at establishment level.

FUNC965 15.6.1 Parole Review Creation Parole Review Creation - allow regular, off line, batch, estate-wide creation of Early Removal Scheme reviews for all relevant offendParole. This is to be driven by Early Removal Scheme eligibility date and case type.

FUNC966 15.6.2 Action Creation Action Creation - automatically create all relevant actions (depending on type of review) and calculate target dates required to complete the whole Early Removal Scheme review.

FUNC967 15.6.3 Action Allocation Action Allocation - automatically identify and allocate actions to the responsible user's worksheet. This can be by individual or user role.

FUNC968 15.6.4 Actions on Transfer Actions on Transfer - create a warning prompt to the user when entering a transfer date for an inmate who has started the Early Removal Scheme process.

FUNC969 15.6.5 Maintain Core Review Details Maintain Core Review Details - record and maintain all core review details, e.g. Early Removal Scheme review outcome, if pending or final outcome, and Early Removal Scheme review outcome date, any subsequent ParoleED.

FUNC970 15.6.6 Early Removal Scheme Audit Early Removal Scheme Audit - record all work done, when and by whom for each individual review action. This will be automatically reflected in worksheets and Early Removal Scheme review schedules.

FUNC971 15.6.7 Mid Early Removal Scheme Transfer Warning

Mid Early Removal Scheme Transfer Warning - issue a warning to the Early Removal Scheme clerk in the establishment from which a mid review Early Removal Schemee has transferred.

FUNC972 15.7 HDC HDC - Record HDC Actions

FUNC973 15.7.1 HDC Task List HDC Task List - record and maintain an HDC task list showing the tasks to be performed and the target dates for completion.


C-NOMIS RESTRICTED


FUNC974 15.7.2 Task Outcome Recording Task Outcome Recording - record the outcome of tasks and dates of completion. The outcome can be recorded for a single task.

FUNC975 15.7.3 HDC 2nd Address Amend HDC screen to display 2nd address

FUNC976 15.7.4 Adjust Task Dates Adjust Task Dates - provide the facility for an establishment to adjust scheduled task due dates.

FUNC977 15.7.5 HDC Opt Out The PSO business rules restrict the number of times an Offender can opt out and back-in to the HDC process. LIDS enforces this restriction as it only allows one HDC application to be set up without Help desk intervention; NOMIS will allow multiple HDC applications to be created. Add a business rule to restrict the number of times that an Offender can opt out and back-in to the HDC process

FUNC978 15.7.6 Amend HDC Details after Approval Provide the ability to amend HDC address and Curfew Hours after HDC eligibility has been approved. Retain the original details so that can see what information was considered at the time eligibility was considered. Provide a field to indicate why the assessment details have been amended

FUNC979 15.7.7 Release Date Times Add fields for release date times

FUNC980 15.7.7.1 CR41 Release Change Moves CR0041 to release 1.1 and hence to 1.0e

FUNC981 15.7.8 Change Text Fields Change to text fields on HDC

FUNC982 15.7.9 HDC Suitability Assessment HDC Suitability Assessment - automatically create and record a suitability assessment for HDC 10 weeks prior to the HDC Eligibility Date, or upon sentence calculation if less than 10 weeks exist before the HDC Eligibility Date.

FUNC983 15.7.10 Release Diary Date Entry Release Diary Date Entry - automatically update sentence dates, upon completion of the suitability assessment, and create a release date diary entry with a prompt to select the tagging contractor, where appropriate.

FUNC984 15.7.11 Manual Eligibity Checks Manual Eligibility Checks - record the result of manual eligibility checks (pass or fail) and record reason(s) for failure.

FUNC985 15.7.11.1

Validation Validation when approving an HDC assessment

FUNC986 15.7.12 Record and Report Stages Record and report on all stages of HDC process

FUNC987 15.7.13 Shift Pattern Hours Record HDC curfew hours which cater for shift patterns

FUNC988 15.7.14 Update HDCAD Update HDCAD after completion of HDC suitability assessment

FUNC989 15.7.15 Amend HDC Address after Release Allow HMP to to change an offender's HDC address after release

FUNC990 15.7.16 Eligibility based on Main Offence HDC eligibility based on main offence

FUNC991 15.7.17 Multiple HDC CR Release Change Moves 204, 205, 206, 207 and 208 to Release 1.1 and hence 1.0e


C-NOMIS RESTRICTED


FUNC992 15.7.18 HDC Actual Release Date HDC Actual Release Date - calculate an HDC Actual Release Date only once approval for HDC has been given.

FUNC993 15.7.19 Offender Applied for HDC Offender Applied For HDC - add a field to indicate that the offender has applied for HDC.

FUNC994 15.7.20 HDC Statistics for RDS Capture HDC statistics to supply RDS

FUNC995 15.7.21 Auto Eligibility Checks based on Offence

Automatic HDC eligibility checks based on offence type

FUNC996 15.7.22 Bespoke Conditions for an Offender The licence code needs changing to show all bespoke conditions held for an offender. This change should be made to all licences, both button reports and IWPs

FUNC997 15.7.23 Indeterminate Public Protection Indeterminate Public protection

FUNC998 15.7.24 Manual Offender Merge Process and Rules

Manual Offender Merge Business process and merge rules

FUNC999 15.7.25 Mapping LIDS to C-NOMIS Country of Birth

Mapping LIDS-C-NOMIS Country of Birth (Related to defect 7198)

FUNC1000 15.7.26 HDC PSI New PSI on HDC

FUNC3364 15.7.26.1

Corrections of HDCED date/remand time and HDC ineligibility correction

Two rules apply in the calculation of HDC eligibility and the HDC Eligibility Date with regard to sentence adjustments (i.e. ADA/PADA, UAL and Remand Time): 1) Calculation of eligibility and the HDCED (reference CR00265) is to be based on the sentence handed down by the judge i.e. sentence length before adjustments are applied. 2) Adjustments are applied to the HDCED; the HDCED is not recalculated based on adjusted sentence length. Reference "Adjustment Types and Examples" written by [redacted].

FUNC2402 15.7.27 HDC opt in count validation Add a business rule to restrict the number of times that an Offender can opt out and back-in to the HDC process.(ie Defer this bit from Release 1.0) The PSO business rules restrict the number of times an Offender can opt out and back-in to the HDC process. LIDS enforces this restriction as it only allows one HDC application to be set up without Help desk intervention; NOMIS will allow multiple HDC applications to be created

FUNC2403 15.7.28 Amend HDC Address and Curfew Provide the ability to amend HDC address and Curfew Hours after HDC eligibility has been approved. Retain the original details so that can see what information was considered at the time eligibility was considered. Provide a field to indicate why the assessment details have been amended.


C-NOMIS RESTRICTED


FUNC2674 15.8 Discharge/Transfer Report It has become apparent that there may be a temporary issue with some parts of an offender's record being recorded electronically on c-NOMIS, for example currently in HMPS an offender's history sheet is a manual record but on c-NOMIS this is new functionality and 'Case Notes' will be electronic. Example - an offender is received into a local prison that uses the current legacy system LIDS and:1. A manual history sheet is opened and some entries made on it.2. The offender has some visits and a manual record is made on the visits sheet containing details of the visit and the visitor details both social and professional.

FUNC3118 15.9 Offender Supervisor/Personal Officer on Transfer

When a prisoner is transferred to another establishment, the current Offender Supervisor (label to be changed to Personal Officer under CR00262) is retained in the Header Block. This is not acceptable as it will suggest that an offender has already been allocated an offender supervisor, when in actual fact this is not the case. A new offender supervisor will be allocated on the prisoner's arrival in an establishment.

The parallel functionality within NPS is not a concern as any transfer between NPS areas as functionality exists to enable NPS to transfer offender manager responsibility between areas.

FUNC4344 15.10 Change to Movement Reference Data (UALs)

There is an issue in reporting in relation to the counting of offenders who are UAL (Unlawfully at Large) who are subsequently recaptured.Prisoners who are UAL have either:1. Escaped2. AbscondedOn recapture it is necessary to know by which method the prisoner was UAL in order to historically count the Escape/Abscond figures. At present on recapture the application only has the code ‘Recapture’ so it is not possible to know whether the prisoner has returned from an Escape or an Abscond. The issue could be resolved if the reference data was changed and the return code of ‘Recapture’ was replaced with 2 codes1. Recapture Escape2. Recapture AbscondThe application can easily be configured in order that the end user is only presented with the appropriate code on recapture.

FUNC10322

15.11 Discharge Address Reference Data Add the following reference data to the Offender Address Types in the P-NOMIS application.

Discharge - Bail/Probation HostelDischarge - NFADischarge - Discharge - Unknown Accommodation TypeDischarge - Transient/Short TermDischarge - Permanent HousingDischarge - Supported Housing Make the Address Type of ‘Discharge’ Inactive in the P-NOMIS application

FUNC1001 16 Licence Recall Licence Recall

FUNC1002 16.1 Licence Recall Details Licence Recall Details

FUNC1003 16.1.1 Licence Recalls Licence Recalls - administer licence recalls estate wide and at establishment level for all relevant offenders.

FUNC1004 16.1.2 Licence Recall Review Licence Recall Review - allow manual insertion of licence recall reviews.


C-NOMIS RESTRICTED


FUNC1005 16.1.3 Licence Recall Review Schedule Licence Recall Review Schedule - automatically create licence recall review schedule by action, target date and time.

FUNC1006 16.1.4 Licence Recall Core Details Licence Recall Core Details - maintain core details of licence recall review e.g. review date, review outcome,

FUNC1007 16.1.5 Licence Recall Review Actions Licence Recall Review Actions - maintain licence recall review individual actions and record date and time completed

FUNC1008 16.2 Offender Diary Offender Diary - maintain an offender diary.

FUNC1009 16.2.1 Offender Diary Facility Offender Diary - provide a diary facility for Offenders. This will allow staff members to see the availability of offenders and record external commitments when the offender is in custody.

FUNC1010 16.2.2 Offender Diary List Offender Diary List - generate a list to detail upcoming or due diary events.

FUNC1011 16.2.3 Amend Court Diary Screen Amend Court Diary Screen

FUNC1012 16.2.4 Event Conflict Event Conflict - provide a warning when conflicts arise within the offender diary.

FUNC1013 16.2.5 Next Appointment Prompt Next Appointment Prompt - provide a prompt to enter an appointment into the offender diary, when recording the outcome of an appointment, if the next appointment is not already scheduled.

FUNC1014 16.2.6 External Participants Availability External Participants Availability - allow partial diaries to be kept for external participants in appointments (e.g. drug testing clinic hours).

FUNC1015 16.2.6.1 External Participants Availability External Participants Availability - allow partial diaries to be kept for external participants in appointments (e.g. drug testing clinic hours).

FUNC1016 16.2.7 Repeated Meetings Repeated Meetings Scheduling - allow the user to set up a repeating sequence of meetings.

FUNC1017 16.2.8 Bulk Cancellation of Appointments Bulk Cancellation of Appointments - allow a user to make bulk cancellations of appointments, e.g.- all appointments for an offender,- all appointments for an offender for a specified period,- all appointments for an offender of a specified type.

FUNC1018 16.2.9 Probation Scheduler Update Rule Change Update Rule on Probation Scheduler - agreed with Business Change team 23/10/06

FUNC1019 16.3 Transfer Offender Transfer Offender

FUNC1020 16.3.1 Allocate Temporary Offender Manager

Offender Transfer - provide the ability to allocate a temporary offender manager to an offender if the offender is transferred between areas or regions, providing for immediate access to the offender's record in the new area during the transfer period. Permit staff from both areas to view and record details during the transfer period.

FUNC1021 16.3.2 Pre-Transfer Notification Checklist Pre-Transfer Notification Checklist - ability to maintain a checklist of activities to be completed prior to Offender transfer. Each item on the checklist to have a status, which can be populated from an agreed list of values (open, completed, N/A etc).

FUNC1022 16.4 Contact Log Contact Log - provide basic contact log viewing, simple chronological lists of contacts, ability to drill down from contact to full text, print contact details.


C-NOMIS RESTRICTED


FUNC1023 16.4.1 Simple Contact Recording Simple Contact Recording - allow a user to record a basic, generic, contact as a record of a past event. This would consist of a date and time the contact occured, the person the contact was with, a Contact Type and a free text field which could be used to record all other information that was required.

FUNC1024 16.4.1.1 Case Note Against Specific Order Case Note Against Specific Order - enter all contacts against a specific order, licence or requirement activity for offenders being managed and where appropriate against a specific activity or intervention, e.g. drug testing, curfew, accredited programme. For other cases, e.g. bailee, PSR report, the entry will be against the relevant activity only. Wherever possible, the system must set the default values for these e.g. if an Offender only has one active order or licence, or if the activity can be identified from the Contact Type. Where there are multiple current orders and activities, the user must be able to select the correct ones before starting to enter contacts. These would then remain the defaults while the user was able to enter a series of contacts. The user must also be able to select the correct order and activity while entering the contact details.

FUNC1025 16.4.2 Contact Log Reference Data Contact Log Reference Data - provide coded and textual reference data, views filtered by event type, activity, components, dates etc.

FUNC1026 16.4.3 Automatic Inserts into the Contact Log

Automatic Inserts into the Contact - automatically create entries in the contact log when specified events occur. e.g. when responsibility for an Offender is transferred to another office, an entry should be made in the contact log summarising details of the transfer. The automatic creation of contacts will be triggered by specified conditions in the data available to the contact log. The rules governing creation of contacts and the data to be recorded for a contact must be configurable to add or remove types of entries or adjust the rules for existing types of entries. If the facility to link contacts to supporting data or documents has been provided, then these links should also be generated automatically.

FUNC1027 16.4.4 My Offenders List My Offenders List - provide a 'My Offenders' facility which displays a list of all offenders relevant to the user (by role). Users must be able to select the offender and drill down to the required functionality.

FUNC1028 16.4.5 Record Group Contacts Record Group Contacts - provide a facility to allow users to record the outcome of group contacts in a single transaction. This should have a section to record general information, followed by a section listing each Offender with an appointment, with fields to enter the necessary data.

FUNC1029 16.4.6 External Contacts External Contacts - provide automated or semi-automatic capture of contact with external agencies or intervention providers (through loading data from structured files).

FUNC1030 16.4.7 View Linked Offender Data & Documents

View Linked Offender Data and Documents - allow a user to view documents and other data associated with a case note. The minimum requirement is for a user to be able to link from a case note entry recording the completion of a document through to the document itself.

FUNC1031 16.4.8 Contact Status Display Contact Status Display - display icons, or an alternative facility, showing contact status.

FUNC1032 16.4.9 Contact Details Search Contact Details Search - allow the user to search the contacts in the contact list by contact type (this may be a filtered list).

FUNC1033 16.4.10 Apply a Combination of Filters Apply a Combination of Filters - provide the facility to select multiple filters so that the contacts displayed are the result of the combined filter, e.g. all contacts of a specified type, for a selected intervention, within a defined date range. Enable filtering by source, contact type and sub-type or any combination of these.

FUNC1034 16.4.11 Filter by Team Filter by Team - provide the facility to filter the contact listing so that it only displays contacts with a member of a selected Team.

FUNC1035 16.4.12 Filter by Date Range Filter by Date Range - provide the facility to filter the contact listing so that it only displays contacts for a selected range of dates.


C-NOMIS RESTRICTED


FUNC1036 16.4.13 Outcome of Future Events Outcome of Future Events - prevent a user from entering an outcome for a future event except for certain reasons defined in reference data.

FUNC1037 16.4.14 Spell Check All Long Text Fields Spell Check all Long Text Fields - provide the facility to spellcheck when entering contact details or other data into the contact log. Spell checking must be applied to all long text fields, preferably as users type. This facility shall be switchable on/off by the user.

FUNC1038 16.4.15 Simple Chronological List of Contacts

Simple Chronological List of Contacts - allow the user to view a chronological listing of all contacts with an offender, starting with the most recent. Most contacts could be displayed one per line, but detailed analysis and design would be needed to confirm that this would be appropriate for all contacts, as this would be partially dependent on the interface design.Allow the user to vary the level of detail displayed in the contact listing, e.g.- standard, 1 line per contact- full, full contact details.

FUNC1039 16.4.16 Case Notes Enquiry Case Notes Enquiry - provide a facility for all authorised users to enquire on case notes.

FUNC1040 16.4.17 View Linked Offender Data & Assessments

View Linked Offender Data and Assessments - allow a user to view assessments and other data associated with a contact. The minimum requirement is for a user to be able to link from a contact log entry recording the completion of an assessment through to the assessment itself.

FUNC1041 16.4.18 Save User-Defined Filter Save User-defined Filter - save (optionally on user choice) the last filter selected by the user prior to log off.

FUNC1042 16.4.19 Date and Time on Case Note Date and Time on Case Note - associate a time (as well as a date) with all Case Notes.

FUNC1043 16.4.20 Manual Case Notes Manual Case Notes - provide the facility, based on user role, for the Contact Type to be automatically set to 'Manual' and the Subtype set to 'General' for all manual case note entries. This is relevant to all HMPS users except Seconded Probation Officers.

FUNC1044 16.4.21 Update of Manual Case Notes Update of Manual Case Notes - update of manual case notes can only be done by the user who entered the case note. This should be based on user role (ie. for HMPS users). This is not required for NPS users.

FUNC1045 16.4.22 No Default Dates or Times No Default Dates or Times - when a new event is scheduled, event date and time should not default to the system date and time. There should be no default and these fields should be blank.

FUNC1046 16.4.23 Case Notes Source Case Notes Source - case notes entries entered by HMPS users should have a source of the establishment in which the offender is residing and should say, eg, "Brixton" not the CJIT code. For NPS users, the location source is the probation area to which the offender Manager belongs. If there is no Offender Manager allocated to the offender, then the source location should be the current location of the court (the active location). If the offender is inactive, the source should be blank.

FUNC1047 16.4.24 Schedule Enquiry Tab Schedule Enquiry Tab - delete Schedule Enquiry tab.

FUNC1048 16.4.25 Appointments Linked to Sentence Appointment Linked to Sentence - record an appointment and the outcome and associate the appointment and outcome with one or more than one of the offender's sentence(s). The appointment may be recorded retrospectively in order to capture the offender's non-compliance.

FUNC1049 16.4.26 Appointment Linked to a Requirement

Appointment Linked to a Requirement - associate an appointment with an offender and the outcome of the appointment with a specific requirement within a sentence, or with the same requirement within more than one sentence.


C-NOMIS RESTRICTED


FUNC1050 16.4.27 Unacceptable Failure Count on Same Date

Failure Period - prompt the Offender Manager to confirm that the unacceptable failure count should be incremented again, in the case where the count of unacceptable failures to comply which fall on the same date (for that sentence/ requirement) has already been incremented.

FUNC1051 16.4.28 Confirm FTC is Unacceptable Confirm Unacceptable - provide a facility for the offender manager to confirm if a failure to comply is acceptable or unacceptable.

FUNC1052 16.4.29 Suspend Appointments Suspend Appointments - provide a facility for one or more future appointments to be marked as cancelled (suspended) and no longer counting for enforcement purposes.

FUNC1053 16.4.30 Reset Failure Counter Reset Counter - set the count of the number of failures to comply, both confirmed and unconfirmed, back to zero when the breach hearing gives the final sentence (community sentence) or on the decision that the offender is to be recalled (licence).

FUNC1054 16.4.31 Failure to Comply Failure to Comply - record and maintain details of an offender's failure to comply. A failure to comply includes failure to attend an appointment, or failure to behave.

FUNC4339 16.4.32 Request for IWP link to field length of case notes

Post 1.0e Release Request

Request for IWP link to field length of case notes.

Case note field length is limited to 4000 characters. For some OM reports, a facility to hyperlink to a Word report is required.

FUNC6354 16.4.33 Sorting by Date Provide the ability to sort both Case Notes and Probation Scheduler entries in either ascending or descending date order.

FUNC1055 16.5 Enforcement Enforcement

FUNC1056 16.5.1 Breach Court Appearance Result Breach Court Appearance Result - record the result of a breach court appearance.

FUNC1057 16.5.2 Generation of Breach Warning Letters

Generation of Warning Letters - link the tasks and alerts relating to enforcement and breach to the appropriate letters and documents and, on completion of the task, create the appropriate case note entries.

FUNC1058 16.5.3 Annual Enforcement Requirements Annual Enforcement Requirements - record and maintain an indicator of which types of appointment are subject to enforcement under national standards.

FUNC1059 16.5.4 Associate Breach Hearing with Original Sentence

Breach Hearing - associate a breach hearing with the original sentence being breached (and hence to the original charges for that sentence).

FUNC1060 16.5.5 Breach Hearing Outcomes Breach Hearing Outcomes - record the sentence outcomes of a breach hearing and associate with the requirement(s) of the original sentence and the sentence itself as appropriate.

FUNC1061 16.5.6 Breach Court List Breach Court List - record and maintain and provide a facility to query on details of the offenders appearing in the breach court sitting at any court.

FUNC1062 16.5.7 Breach Court Hearing Breach Court Hearing - record the details of the breach court hearing to be attended by the offender and add to the court list for the relevant breach court. Update the offender schedule.


C-NOMIS RESTRICTED


FUNC1063 16.5.8 Breach on Single Failure Breach on Single Failure - enable the offender manager to create a breach action letter (community sentence)) or initiate recall (licence) on a single unacceptable failure to comply overriding the automatic system rules. Create the case note entry that would have been created had the breach action letter been completed as part of workflow task.

FUNC1064 16.5.9 Probation Recall Report for Licence Breach

Probation Recall Report - produce the recall report on an offender who has breached the licence.

FUNC1065 16.5.10 Breach File Breach File - produce the breach file for each breached sentence, made up of:- The breach statement to court (IWP document)- Breach report - explanation of circumstances surrounding breach- Witness statements - document based on extract of reasons given for failure to comply- Most recent PSR for the sentence.

FUNC1066 16.5.11 Breach Summons or Warrant Breach Summons or Warrant - produce the summons or warrant for the offender in breach.

FUNC1067 16.6 MAPPA MAPPA

FUNC1068 16.6.1 Record & Maintain Offender Level MAPPA details - record the offender's MAPP level from LOV. Maintain a history of changes to the level.

FUNC1069 16.6.2 MAPPA Risk Management Plan MAPPA Risk Management Plan - record the MAPPA Risk Management Plan (text), plan review dates, MAPPA contacts in other agencies working with the offender.

FUNC1070 16.6.3 Child Protection Child Protection - alert (header block) that specific children are at risk from the offender. Record details of the LSCB (previously ACPC), registration including LSCB location, contact details, key worker details. The alert may be entered manually or triggered by the OASys assessment. An alert entered manually cannot be overwritten by OASys.

FUNC1071 16.6.4 Intervention Tier Intervention Tier - record and maintain the level at which an offender is assessed for intervention purposes (range 1-4). History of change to be captured at offender level.

FUNC1072 16.6.4.1 Capture Proposed Intervention Tier Provide the ability to capture proposed intervention tier for the offender with a court report.

FUNC1073 16.6.4.2 PSR Offence Identification PSR Offence Identification - identify sexual and violent offences in system maintenance and associate with maximum sentence length to help PSR authors identify appropriate range of proposals.

FUNC1074 16.7 End Supervision End Supervision

FUNC1075 16.7.1 Record Details End Supervision - record the details when an offender finishes a period of supervision.

FUNC1076 16.7.1.1 Termination Reason by Sentence Component Type

Termination Reason by Sentence Component Type - Enable termination reasons to be linked to specific booking component types, namely pre- and post-CJA Sentences, Requirements, Licences, Licence Conditions and Pre-CJA Additional Requirements. This will allow the user to be presented with a list of termination reasons that are relevant only to the component being ended

FUNC1077 16.7.1.2 Termination Reason by Sentence Type

Termination Reason by Sentence Type - Enable termination reasons to be linked to specific sentences. This will allow the user to be presented with a list of termination reasons that are relevant only to the sentence being ended


C-NOMIS RESTRICTED


FUNC1078 16.7.2 End Sentence Requirements Check End Sentence Requirements Check - ensure that all requirements relating to an order have been closed before the sentence is closed. If a requirement is still open then the user should be warned. The sentence cannot be closed until all requirements have been closed.

FUNC1079 16.7.3 End Sentence Close Requirements End Sentence Close Requirements - when a user wishes to close a sentence and is warned of open requirements the user should be given the option to view and close the requirements.

FUNC1080 16.7.4 End Sentence Appointments Check End Sentence Appointments Check - provide the ability to check if there are outstanding open appointments before closing a sentence. If appointments are still open the user should be warned.

FUNC1081 16.7.5 End Sentence Close Appointments End Sentence Close Appointments - when a user wishes to close a sentence and is warned of open appointments the user should be given the option to view and close outstanding appointments before closing the sentence. A sentence can be closed with outstanding open appointments. If this is the last sentence then it cannot be closed with outstanding open appointments.

FUNC1082 16.7.6 End Sentence Term Plan Check End Sentence Term Plan Check - ensure that the termination plan for a sentence has been completed before the sentence is closed. If the termination plan has not been completed then the user should be warned. The sentence cannot be closed until the termination plan for the sentence has been completed.

FUNC1083 16.7.7 End Sentence Close Term Plan End Sentence Close Term Plan - when a user wishes to close a sentence and is warned of a lack of a completed termination plan the user should be given the option view and complete the termination plan.

FUNC1084 16.7.8 Close Booking Sentence Check Close Booking Sentence Check - ensure that all sentences relating to the booking have been closed before the booking is closed. If there is an open sentence on the booking then the user should be warned. The booking cannot be closed until all sentences for the booking have been closed.

FUNC1085 16.7.9 Close Booking Close Sentence Close Booking Close Sentence - when a user wishes to close a booking and is warned of an open sentence on the booking the user should be given the option to view and close the open sentence.

FUNC1086 16.7.10 Close Booking Prompt Close Booking Prompt - the user should be prompted to close the booking when the last sentence for an offender has been closed.

FUNC1087 16.7.11 Close Booking Exceptions Close Booking Exceptions - a booking cannot be closed under any of the following conditions:- the offender is a lifer and the termination reason for the sentence is 'suspended'- there is outstanding breach action on the offender.

FUNC1088 16.7.12 Close Booking Exceptions Close Booking Exceptions - a booking cannot be closed under any of the following conditions:- the offender is a lifer and the termination reason for the sentence is 'suspended'- there is outstanding breach action on the offender- the Victim Liaison Unit has a need to update the offender record.

FUNC1089 16.7.13 Close Booking Task Check Close Booking Task Check - ensure that if there are active workflow tasks or workflow memos relating to the booking being closed then the user is warned. The user must be able to close the booking regardless of active workflow tasks or workflow memos

FUNC1090 16.7.14 Close Booking Close Task Close Booking Close Task - when a user wishes to close a booking and is warned of an active tasks or alerts on the booking the user should be given the option to view and mark the tasks and alerts as completed.

FUNC1091 16.7.15 Close Booking Team Check Close Booking Team Check - ensure that there are no active teams for the offender before the booking is closed. If there are any active teams then the user should be warned. The booking cannot be closed until all teams for the offender have been made inactive.


C-NOMIS RESTRICTED


FUNC1092 16.7.16 Close Booking Close Team Close Booking Close Team - when a user wishes to close a booking and is warned of any active teams for the offender the user should be given the option to view and inactivate the teams.

FUNC1093 16.7.17 Terminate HDC Address Terminate HDC address at end of booking

FUNC1094 16.8 Record Appointments Record Appointments

FUNC1095 16.8.1 Record and Amend Appointments Record and Amend Appointments - provide a facility to make, view, cancel and rearrange appointments for the offender.

FUNC1096 16.8.2 Enter Appointments in the Contact Log

Enter Appointments in the Contact Log - enter an appointment in the contact log from the day that the appointment occurs. When an appointment is recorded the user will be required to select or enter one of the available contact types and specify whether or not it is a National Standards contact (default to NS contact). The order or licence requirement to which the appointment relates must also be specified.

FUNC1097 16.8.3 Book Appointments for Others Book Appointments for Others - allow an authorised user to set up appointments in which they are not involved.

FUNC1098 16.8.4 Schedule Meetings before Identifying Participants

Schedule Meetings Before Identifying Participants - allow a user to set up single or repeating meetings before identifying the participants. Participants can then be added to the meetings later. This could be used to set up the sessions on a group work intervention, or for regular planned sessions.

FUNC1099 16.8.5 Exclude Evaluation Measures from Migration

Exclude evaluation emasures from migration

FUNC1100 16.8.6 Provide Tools to Assist Diarying Provide Tools to Assist Diarying - provide tools to automate routine tasks in the diary, e.g. recording standard travel times between home and appointment locations and including them when appointments are made.

FUNC1101 16.8.7 Record Repeating Patterns of Work Record Repeating Patterns of Work - provide tools to record offenders' repeating patterns of work or custody.

FUNC1102 16.8.8 HMPS Location for Case Note Case Notes screen and report - need to see HMP location at time of entering case note

FUNC1103 16.9 Workflow Workflow

FUNC1104 16.9.1 Manual Generation of Alerts Manual Generation of Alerts - provide a facility for a user to generate an alert about a contact log entry for an offender to a team or individual to do list.

FUNC1105 16.9.2 Alerts and Tasks Viewing Alerts and Tasks Viewing - provide the facility for authorised users to view a list of tasks and alerts allocated to a team or to an individual within the team.

FUNC1106 16.9.3 Workflow Staff Selection Workflow staff selection

FUNC1107 16.9.4 Rule Based Tasks & Alert Generation

Rule Based Tasks and Alert Generation - generate tasks and alerts relating to an offender in accordance with table driven rules related to time and/or specified conditions in the database. Certain parameters will be configurable by authorised users.


C-NOMIS RESTRICTED


FUNC1108 16.9.5 Allocate Tasks & Alerts to a Team Rule Based Task and Alert Allocation - provide the facility for the system to allocate tasks and alert to a team in accordance with table driven rules related to task/alert type, team, location, offender. Certain parameters will be configuarable by authorised users.

FUNC1109 16.9.5.1 Team Level Working Team Level Working - provide facility to complete work (tasks and alerts) at team mailbox level.

FUNC1110 16.9.6 Allocate Tasks Allocate Tasks - provide the facility for authorised team members to allocate tasks from the team list to an individual team member list or to another team list

FUNC1111 16.9.6.1 Filter Teams When a user assigns or transfers workflow tasks and alerts to another team the system must allow the user to select the 'assign to' team from a list filtered on an Area and/or Sub-Area selected by the user (the default selection must be the Area the user belongs to. 'I.e. on the Assign Incoming Work and Transfer Work Between Staff screens, when selecting the 'assign to' team the user must be able to first select an Area or Sub-Area, the system will then provide a list of teams only in that Area or Sub-Area from which the user can select'

FUNC1112 16.9.7 Allocate Individual Alerts Allocate Individual Alerts - provide the facility for a user with appropriate authority to select individual alerts from a team list and allocate to one or more other other users in the team or to another team list.

FUNC1113 16.9.8 Individual Reallocation of Alerts & Tasks

Individual Reallocation of Alerts and Tasks - provide the facility for a user with appropriate authority to select individual alerts or tasks from an individual list and reallocate to one or more other other users in the team.

FUNC1114 16.9.9 Bulk Reallocation of Alerts & Tasks Bulk Reallocation of Alerts and Tasks - provide the facility for a user, with appropriate authority, to make a bulk reallocation of alerts and tasks from one user to another or from one team to another team.

FUNC1115 16.9.10 Self Allocation Self Allocation - provide a facility for authorised team members to allocate a task from the team list to his or her self.

FUNC1116 16.9.11 List Tasks & Alerts List Tasks and Alerts - provide the facility for authorised users to view a list of tasks and alerts allocated to a team or to an individual within that team.

FUNC1117 16.9.12 Default List Sort Order Default List Sort Order - provide a default order of tasks and alerts on the list by creation date and then by due date.

FUNC1118 16.9.13 Sort Alerts Sort Alerts - provide a facility for a user to sort the alerts and tasks on the list by type and due date; work type, subtype and due date; name and NOMS number; due date or allocation date.

FUNC1119 16.9.14 Highlight Alerts & Tasks Highlight Alerts and Tasks - provide a facility to highlight alerts and tasks on the list that relate to dangerous offenders. A dangerous offender has a current OASys Risk of Harm level of High or very High.

FUNC1120 16.9.15 Remove Alerts from Own List Remove Alerts from Own List - provide the facility for a user to remove alerts from his/her own list.

FUNC1121 16.9.16 Remove Alerts from List Remove Alerts from List - provide the facility for an authorised user to remove alerts from others' list.

FUNC1122 16.9.17 Remove Task from List Remove Task from List - automatically remove a completed task from the list, or for a user to remove an open task from his/her own list.

FUNC1123 16.9.18 Identify Line Manager Line Manager - identify a member a team as the line manager of the team members.

FUNC1124 16.9.19 Copy to Backup Team Copy to Backup Team - automatically send a copy of a workflow alert or task to a backup team if a workflow trigger does not reach its destination. Provide a marker on the backup alert or task to enable the backup team to identify this task or alert as a copy.


C-NOMIS RESTRICTED


FUNC1125 16.9.19.1

Automatic Virtual Team Closure Automatic Virtual Team Closure - close Virtual Team automatically flag a member of the offender's virtual team as inactive on termination ( plus x days?) of the requirement for which that team member is responsible.

FUNC1126 16.9.19.2

Add Fields to My Offenders List My Offenders List Fields - add a primary owner flag and the offender's NOMS number to the My Offenders List.

FUNC1127 16.9.19.3

Default Historic Teams Default Historic Teams - set up default teams prior to migration of historic data.

FUNC1128 16.9.20 Countersignature Countersignature - enable certain tasks or alerts to be automatically generated but not automatically allocated to a team. Provide a facility to enable a user to manually allocate the task to the counter-signer by selecting from a list of possible mailboxes. Enable the user can designate one of the mailboxes on the list as the default mailbox.

FUNC1129 17 Physical Searching Physical Searching

FUNC1130 17.1 Searches Made Searches Made - record the occurrence of searches undertaken.

FUNC1131 17.1.1 Searching Targets Searching Targets - record the searching targets (at an establishment level) for each search type and progress against the targets.

FUNC1132 17.1.2 Search Procedures SPU interested in developing functionality to help record and manage search proceedures in prison, especially ethnicity of person being searched, or ethnicity of occupant of cell being serached

FUNC1133 17.1.2.1 Search Types Search Types - record the search type and category.

FUNC1134 17.1.2.2 Record Establishment Searches Record Establishment Searches - record establishment searches, cell fabric checks and visitor searches.

FUNC1135 17.1.3 Search Details Search Details - record the date and time of the search and the officers involved.

FUNC1136 17.2 Search Results Search Results - record the results of all searches.

FUNC1137 17.2.1 Record Search Results Search Results - record results of search, including if nil found.

FUNC1138 17.2.2 Search Planning Search Planning - generate a list of cells and areas randomly from the establishment for searching.

FUNC1139 17.2.3 Cell Search Certificate Cell Search Certificate - generate and print a cell search certificate.

FUNC1140 17.2.4 Items Found Items Found - record all illegal items found, their type, disposal details, and action identified.

FUNC1141 17.2.5 Record Cell Fabric Check Record Cell Fabric Check - record the results and actions of a cell fabric check.

FUNC1142 18 Reporting & Analysis Reporting and Analysis


C-NOMIS RESTRICTED


FUNC1143 18.1 Database History Database History - retain a record of offender history.

FUNC1144 18.1.1 Historical Data Historical Data - retain standard historical data to support the standard analysis and reports requirements.

FUNC1145 18.1.2 Transfer Planning History Transfer Planning History - record all removals and re-allocations to the transfer list with associated reason text.

FUNC1146 18.1.3 Activities History Activities History - maintain an historical record of all the offender's activities during all periods of custody.

FUNC1147 18.1.4 Team Structure & History Team Structure and History - record and maintain the history of allocation of a particular team or role (e.g. PSR writer, offender manager, supervision provider, intervention provider etc) to NOMS/NPS delivery staff (from a staff look-up table).

FUNC3097 18.1.5 MIS refresh date and time All MIS reports to display the date and time the MIS database was last refreshed.

FUNC3113 18.1.6 Change to MIS design to accommodate prisoner not allocated to a cell

The MIS data base is built on the assumption that a prisoner within a prison will always be allocated to a cell, this has been found not to be true for example a prisoner in reception who has just arrived from court and is awaiting a cell location.A change is required to the MIS structure so that the relationship between a prisoner and the prison that they are in is not dependant on them being allocated to a cell. In order to do this we need to change the structure of the MIS data base and the ETL which populates the MIS data base along with one universe and several reports.

FUNC3124 18.1.7 Put Latest Version of BR2 Reports Under Conf. Mgt

Obtain the latest version of the 23 BR2 reports from ALBANY staff. Build these reports into the next BOUK release to be delivered into cycle 3 of R1.0c testing. Testing will prove ONLY that the reports run to completion.UAT will be at liberty to test these reports. Defects found by UAT will be recorded in TD. The JDWG will make a decision on which have to be resolved, since any remedial work is out of scope for R1.0c.

FUNC3126 18.1.8 MIS TRAINING MATERIALS UPDATE

As the original MIS training materials were written in Feb 2006, and since both the MIS and C-NOMIS applications have further developed there was a need to review them to ensure they meet the training need. When carrying out the review it became very clear that large areas of the materials were no longer fit for purpose and major amendments would be required. Another major issue was that the current materials did not provide enough business relevance. This is essential in order for the end users to gain maximum benefit when returning to the workplace

FUNC1148 18.2 Standard Reports Standard Reports - provide a set of predetermined reports.

FUNC1149 18.2.1 Parameter Driven Reports Standard Reports - provide a set of predetermined parameter-driven reports that will be run on demand, and at scheduled points e.g. weekly, monthly), incorporating data at establishment, area and national levels.

FUNC1150 18.2.2 Simple Ad-Hoc Enquiry Reports Simple Ad-Hoc Enquiry Reports - provide the ability to create simple ad-hoc reports, based on selection of variables from a defined set of data variables.

FUNC1151 18.2.3 Complex Enquiry Reports Complex Enquiry Reports - provide the ability to produce ad hoc reports from the TAG database.

FUNC1152 18.2.4 Analysis Tool Analysis Tool - provide analysis reports based on user-defined data ranges.

FUNC1153 18.2.5 Graphical Report Format Graphical Report Format - produce reports on a diagrammatic or graphical basis.


C-NOMIS RESTRICTED


FUNC1154 18.2.6 Offender Record Access Requests Offender Record Access Requests (in accordance with the Data Protection Act) - record the requests for and produce a documented copy of selected offender information (at the request of the offender).

FUNC1155 18.2.7 Remand Time Report Remand Time Report - provide a facility for establishment staff to automatically print out something along the lines of the attached proforma, or at least the information on the first page detailing all remand relevant to each offence listed and any time spent serving a sentence within those remand periods.

FUNC1156 18.2.8 HMI Prisons Inspections Requests Standard requests for HMI Prisons Inspections - provide a population profile report for HMIP as a standard report.

FUNC1157 18.2.9 IQ Reports IQ Reports

FUNC1158 18.2.10 Reporting on Juveniles Reporting on Juveniles required by PSIMON - "Due to increasing demand from NOMS for a split data for those establishments with Juvenile and Non Juvenile sites, we are requesting for a 'Yes / No' object that would indicate whether an offender was/wasn't Juvenile. Therefore as part of this specification we are requesting for a change to the application"

FUNC1159 18.2.11 Reports on Use of Force Reports on Use of Force - produce reports on use of force in prisons

FUNC1160 18.2.12 Drug Treatment Attendance List Drug Treatment Attendance List

FUNC1161 18.2.13 Common Data File Extract Common data File extract

FUNC1162 18.2.14 Post R1.0 HMPS & NPS Reports Production of remaining post-R1.0 HMPS & NPS reports from 5260 reporting catalogues

FUNC1163 18.2.15 PSPlus Interface PSPlus Interface (extract)

FUNC1164 18.2.16 Met Police Data Extract Met Police data extract

FUNC1165 18.2.17 IRS Reporting Access Change IRS reporting access change

FUNC1166 18.2.18 Report Religion Changes Business Objects Universe/Report Religion Changes

FUNC3154 18.2.18.1

Business Objetcs Universe/Report Religion Changes 1.0c

Changes required to Business Objects MIS Universes/Reports to enable the reports to run correctly following a change of religion by an offender

FUNC1167 18.2.19 Religion Descriptions Religious descriotions

FUNC1168 18.2.20 Local Folders for Reporting Local folders for reporting

FUNC1169 18.2.21 LOV Change Reporting "List of Values" (LOV) Change


C-NOMIS RESTRICTED


FUNC1170 18.2.22 MIS Report to cover Training Issue 5 New MIS Report required to cover Training Issue 5

FUNC1171 18.2.23 Descope HMP Reports Descope HMp reports

FUNC1172 18.2.24 Reportable Incidents Distribution Report

Reportable Incidents Distribution Report

FUNC1173 18.2.25 F1032 Data Quality Report A report, which will be run at least once at the end of each month, is required on the live database that gives the prisoner's name, NOMIS Id and location (prison) where:

FUNC1174 18.2.26 Descope HMP Reports Descope * HMP reports

FUNC3048 18.2.27 Fix to defect 5988 - requested by Andy Turnbull on advice of Barry Underwood

In the BR2 report 'Financial Recociliation Report' the closing balance for 15/01/2007 did not match the opening balance for 16/01/2007.This was observed in the Live system by a user at Albany.

Incorrect Balances being displayed in reports - affects other reports as well

FUNC3146 18.2.28 LSR 1 for NOMIS 1.0b - 2nd May This release is to address 2 urgent defects in the CNOMIS application. The first is to Fix/reimplement the ""Canteen"" report which is one of 4 contingency reports that is used should NOMIS be unavailable. The Second is to fix a defect in the BULK attendance screen where the system is incorrectly reporting data on offender movements that occur within a given day.Full Description of Change:Schedule Early BackupRemove and Re Business Objects Canteen Report, and TestApply fix to Oracle View for Bulk Attendance Screen and Test

The Application of this LSR will not require any system outage, hence the request to implement during Mid evening as opposed to the service Window, however, the NOMIS users will benefit from the essential Changes instantly once implemented and verified.

FUNC1175 18.3 Additional Standard Reports Additional Standard Reports

FUNC1176 18.3.1 Audit Requirements Audit Requirements

FUNC1177 18.3.2 MIS physical delete MIS physical delete

FUNC1178 18.3.3 ECL Reporting Report to exclude ECL from MDT and A&O

FUNC1179 18.3.4 Descope NPS Reports Descope NPS reports

FUNC1180 18.3.5 Offender Virtual Team Offender Virtual team Screen

FUNC1181 18.3.6 Cell Location Date & Time Record date and time of cell location change


C-NOMIS RESTRICTED


FUNC1182 18.3.7 Button Report Naming The naming of Button reports needs modifying - an 8 character code means nothing to users

FUNC2701 18.3.8 Additional Reports in MIS A number of additional reports from C-NOMIS have been identified by HMP Albany, without which they are unable to go live.

FUNC3096 18.3.9 Local reporting Folder Re-name ‘Adhoc Reporting’ to ‘Local Reporting’ this deals with the misconception that locally created reports are one offs.There will be a folder for each prison establishment and probation area. This folder will contain functional sub folders,for example Activities, Finance etc for establishments and Reports, Unpaid Work etc for probation areas.The folders will contain only one version of a reportThese reports will be produced by the nominated “Power Users” in each establishment/area and on approval from the BICC that the report is fit for purpose and meets the reporting standards will be put into the appropriate local folder.

FUNC3099 18.3.10 Ghost Establishment reports Business Objects propose to put a universe level restriction in place which will filter out all information pertaining to offenders in the Ghost establishment as well as removing it from the list of selectable establishments in the appropriate prompts. This will only be done in the MIS system. Business Objects will also amend one specific OR report – View Accommodation Details – which aggregates without sectioning by establishment

FUNC3115 18.3.11 Activity Attendance Exception Report

This report will identify and list those prisoners that have been recorded in C-NOMIS as having attended more than one paid activity/programme at the same time. The time period may be the same or overlap.The report will return data for a date range specified by the user

FUNC3125 18.4 Increase number of ETL servers available to Wales Consortium from 1 to 3

[redacted] This change is to install into the South Wales Data Centre 2 additional ETL Servers so each probation area has its own dedicated ETL server.

FUNC1183 19 Common Functions Common Functions

FUNC1184 19.1 Electronic Templates Forms - provide electronic templates for forms production.

FUNC1185 19.1.1 Forms Creation Forms Creation - provide electronic template forms, pre-populated as far as possible, to capture a legal record of the offender management activities or events carried out during the offender's period of custody. Hard copy output may not have the same design as the screen. Templates must only be configurable by a national admimistrator

FUNC1186 19.1.1.1 Documents in Bulk Documents in Bulk - Provide the facility to generate many similar documents (e.g. appointment letters to be sent to all offenders on a group session).


C-NOMIS RESTRICTED


FUNC3012 19.1.1.2 Reverse ’91 licence changes Changes were made to the ’91 licences which have not yet been approved by Parliament and so these changes need removing.The initial changes affected 11 licences but only 10 are required to change under this CR (the 11th is an HDC licence and therefore an IWP document, and also not required until Release 1.1). The changes consist of:• three changes to wording• replacement of Sentence End Date with Licence Expiry Date in two places for each licence.The affected licences are:AC ACR for post-CJA inmatesAH ACR transferring to special hospitalAX ACR deportation licenceNP non-parole licenceNX non-parole deportation licencePA parole licence for post-CJA inmatesPX parole deportation licenceRP recalled extended sentence parole licenceRR returned extended sentence parole licenceRC recalled ACR and AUR licence

FUNC1187 19.1.2 Maintain Template Maintain Template - allow designated users to create and edit Word templates, assign bookmarks to the template, associate the generation of a document from a template with one or more screens, and assign user access rights to the template. Only national templates are allowed.

FUNC1188 19.1.3 Document Set Document Set - associate a set of documents together.

FUNC1189 19.1.4 Template Security Template Security - set up access rights for template update/ generation.

FUNC1190 19.1.5 Template Details Template details - hold details about the template including: template id, template descriptions, create date, creator user id, active/inactive indicator.

FUNC1191 19.1.6 Maintain Template Bookmarks Maintain Template Bookmarks - allow designated users to set up lists of bookmarks that can be assigned to templates.

FUNC1192 19.1.7 Print Template Print Template - provide a facility to print templates. Only users with access to the maintain template screen will be able to print blank tempates (i.e. administrators), general end users will not be able to do this.

FUNC1193 19.1.8 Document Generation Document Generation - allow authorised users to select a template from the list of templates associated with a screen and generate a document for an offender based on the selected template.

FUNC1194 19.1.9 Document Bookmarks & Text Document Bookmarks and Text - pre-populate the generated document with data from the database

FUNC1195 19.1.9.1 Auto Text Auto Text - when creating an IWP document enable a user to select auto text entries based on the selected template'

FUNC1196 19.1.10 Document Edit Document Edit - copy text from one document and paste into a new document.

FUNC1197 19.1.11 Document Status Document Status - allow authorised users to select a status for the document.


C-NOMIS RESTRICTED


FUNC1198 19.1.12 Document Details Document Details - hold details about the document including; document id, date and time created, date and time updated, author, status, comment.

FUNC1199 19.1.13 Delete Document Delete Document - allow for an authorised user to delete a document and any associated case note.

FUNC1200 19.1.14 Document View Document View - associate documents with an offender to be viewed via the screen(s) with which the document template is associated.

FUNC1201 19.1.15 Document Filter Document Filter - allow the user to filter the view of documents associated with an offender according to document type, date created, date updated.

FUNC1202 19.1.16 Document Auto Text Document Auto Text - provide a facility to select auto text for a document.

FUNC1203 19.1.17 Document E-mail Document E-mail - provide a facility to attach a document to an email (where there is an integrated email facility) to send to an external agency e.g. police.

FUNC1204 19.1.18 Document Storage Document Storage - the system must allow a user to manually save IWP documents to the database associated with an offender and a booking'

FUNC1205 19.1.19 Print Document Print Document - provide a facility to:- print documents- re-print a previously saved document without the need to regenerate the document- print photos and any data object e.g. photos, bar codes.

FUNC1206 19.1.19.1

User Friendly Online Documents Initially a majority of documents were to be produced using IWP functionality. Due to possible performance issues Syscon have requested that as many documents as possible be produced as OLDs. IWP documents can be launched from any Offender specific screen, unlike OLDs which currently must be launched from a single report generation screen where the user must enter report parameters. This change request is required to maintain some of the same functionality and prevent the user from having to open a new screen and re-enter data as report parameters.

FUNC1207 19.1.20 Document Text Document Text - provide a facility for authorised users to add or edit designated text within the document

FUNC1208 19.1.21 Address Search Address Search - allow the user to search for all people in the system associated with an address or partial address.

FUNC1209 19.1.22 External Document Link Electronic Documents - provide links with WP documents provided externally.

FUNC1210 19.2 Reference Data Reference Data - maintain reference data.

FUNC1211 19.2.1 Reference Data Maintenance Reference Data Maintenance - on selected screens, provide ability to search by location, region, all. Selected screens are:- staff- courts- providers- interventions.

FUNC3086 19.2.1.1 Offence Codes CT - OASys CR215 The CT (in OPOL) which holds offence codes must be updated to hold Offence Codes as released in January 2005


C-NOMIS RESTRICTED


FUNC3091 19.2.1.2 Addition of HMP Kennet Add reference data for HMP Kennet into the C-NOMIS reference data (Kennet has the LIDS code KTCM). If any further reference data is required, to be advised by Julie Hincks

FUNC1212 19.2.2 Bilateral Agreement Bilateral Agreement - provide an indicator for those countries for which a bilateral agreement exists.

FUNC2404 19.2.3 C-NOMIS Offence Code update The offence codes on C-NOMIS need to be updated to reflect the latest release from PNLD (Police National Legal Database).

Since the C-NOMIS offence codes were created - 360 offences have been withdrawn and 800 offences have become law

FUNC3017 19.2.4 OIDTRWJU (Transfer Within Jurisdiction) - Display Active Establishments ONLY

[redacted]

FUNC3060 19.2.5 Updating Finance Reference Data Updating Finance Reference Data

FUNC3070 19.2.6 PB494 – New bail code for detainees

Add a new bail code for detainees to enable the accurate recording of the current status of detainees. A new code of “BD” to be added to the movements code, which translates to Bailed Detainee

FUNC3081 19.2.7 Security Category Reference Data Addition of resolution of defect 3036 into Release 1.0cThis defect relates to Security Category reference data, it was originally a 1.1 defect, however since the implementation of additional establishments has been brought forward it should be fixed in 1.0c.The reference data will need to be provided by the Authority

FUNC3110 19.2.8 Interactive Load process for Team & Staff data

In general, NPS legacy systems maintain details of teams and officers (staff), but do not fully support the lower-level data required in C-NOMIS to record team members, roles and caseloads.

It has been identified that initial proposals to load team and staff details into C-NOMIS in advance of the load of an area's offender data, and for the area to build these lower level tables in the intervening period will not support the migration, which requires that all of this reference data is loaded in advance.

This change recommends an alternative approach, whereby the area will be supplied with a spreadsheet in advance of their migration, that they can augment as necessary, to load this data in full in advance of the offender data migration.

The spreadsheet will be pre-populated from the legacy system where possible and with system defaults where necessary, to ensure that offender data is not rejected in the migration because the area was unable to fully complete this task.

FUNC3122 19.2.9 FYI - QUANTUM- Change of Reference Data for creation of a Dummy/ Ghost Prison

The CR covers the change of Reference Data to accommodate the creation of a "Dummy/Ghost" prison within the application.The "Dummy Prison" will be used purely administrative purposes and will be used to manage incoming offenders who been discharged from their original site but have made a stop over (at a 2nd Prison) en route to the NOMIS Site. In such instances, there is a possibility that a duplicate record will be created for the incoming offender (1 from each site). Using the "Dummy/Ghost prison" potential duplicate incoming data will be vetted prior to being transferred to the NOMIS site.CR282/235 Ghost Establishments - National Reference Data Release RD_V10.2.0.1.53.34

FUNC1213 19.3 Data Searching Data Searching - allow searching and data matching.


C-NOMIS RESTRICTED


FUNC1214 19.3.1 Limited Data Record Search Limited Data Record Search - perform a fast search on a limited selection of known offender details.

FUNC1215 19.3.2 Data Matching Data Matching - return the closest data match if no exact match is found. Provide handling for mis-spellings, 'sounds like' or similar features.

FUNC1216 19.3.3 Distinguishing Marks Search Distinguishing Marks Search - provide the ability to search the system using prisoner's distinguishing marks or physical description characteristics criteria.

FUNC1217 19.3.4 Offender Registry Search Offender Registry Search - view status and selected offender details for any offender located in the NOMS, either current or historical, for selected users.

FUNC1218 19.3.5 Hot Page Hot Page - display a summary page of key offender details. The details displayed will change with user role.

FUNC1219 19.4 Post Code Facilities Post Code Facilities - provide facilities based on post-code.

FUNC1220 19.4.1 Address Entry Address Entry - at any point in the system where an address is captured the user must be able to enter partial details, the system must then find addresses in a standard PAF file that match the partial details. If only one address is found the PAF details returned are populated. If more than one address is found by the system then the user is presented with a list of addresses to select from. If no address is found in the PAF file or the user cannot find the address they require in the list then they must have the ability to manually record the address partially or in full (e.g. foreign or new addresses, addresses with insufficient information to identify a match with PAF)

FUNC1221 19.4.2 New Address Validation New Address Validation - validate only new addresses, not those being migrated from legacy systems.

FUNC1222 19.4.3 PAF Updates PAF Updates - when a PAF update is received and applied, the system must automatically update previously validated PAF addresses recorded in the system with any address changes in the new PAF file.

FUNC1223 19.4.4 Local Business Address Local Business Address - allow the input of the address of a business (e.g. the address of the the local police station for MAPPPA and Schedule One Offender purposes, the address of a probation office to appear on letters).

FUNC1224 19.4.5 Interface to Other CJOs Interface to other CJOs - allow formatted addresses to be shared with other CJOs.

FUNC1225 19.4.6 Additional Datasets Additional Datasets - associate postcodes with Police Forces, Local Government tiers to enable joint working on caseloads.

FUNC1226 19.4.7 Address Update Address Update - if an address in the system is updated by a user then it must attempt to re-validate against the PAF file without user knowledge. If more than one address is found by the system then the user is presented with a list of addresses to select from, if the address they require is not in the list then they must have the ability to manually record the address partially or in full. If no address is found in the PAF file then the updated address must be saved automatically.

FUNC1227 19.4.8 Address Format Address Format - addresses in the system must adhere to that specified in the NOMIS data standards document.

FUNC1228 19.4.9 Phone Number Field Length Reduce Phone Number field length on C-NOMIS to 20 characters

FUNC1229 19.5 Data Extract Data Extract - provide data extracts for analysis.

FUNC1230 19.5.1 Offender Data Extract Offender Data Extract - extract a selected range of offender record data and allow export to other analysis systems.


C-NOMIS RESTRICTED


FUNC1231 19.6 Document Management Document Management - provide technology to assist in document management.

FUNC1232 19.7 Maintain Staff Records Maintain Staff records

FUNC1233 19.7.1 Staff Details 3. The Effective Sentence End Date is missing (where the prisoner has a sentence)

FUNC1234 19.8 Audit Audit

FUNC1235 19.8.1 Author Audit View Author Audit View - provide basic audit information to a user (i.e case/offender details, user details, date, time, location and terminal ID) so that the identity of the author of any information can be displayed.

FUNC1236 19.8.2 Audit Requirements Audit - following initial analysis of requirements, provide ability to identify what is to be audited, allowing specification of which data items should be monitored, and which actions of create, update and delete are to be recorded.

FUNC1237 19.8.3 Access for Court Workers Access for Court Workers

FUNC1238 19.8.4 Role Based Access Role based Access


FUNC2993 19.8.6 Additional Audit and Accounting Reqs

Four identified new requirements need to be incorporated into the Audit and Accounting architecture as described in PD 1.2.2.6 – Audit and Accounting Requirements. These are:

(6.3.4) Archived NOMIS accounting and audit data must be available to the Authorised Requestor within 48 hours.

(6.3.22) Reveal untypical gaps in the accounting logs (e.g. no data for an individual user).

(6.3.28) Reveal every data download to media from NOMIS must be accounted for and logged against the User.

(6.3.29) Logs should be stored in a single central repository.

FUNC1240 19.9 Access Control Access Control

FUNC1241 19.9.1 Screen & Report Access Control Screen and Report Access Control - control access to the application screens and reports [redacted]

FUNC1242 19.9.2 Data Access Control Data Access Control - allow control of access to the application data [redacted]

FUNC1243 19.9.3 External Access External Access - provide for external commercial, voluntary sector and independent providers of services to access NOMIS. Provide for other CJS organisations to access NOMIS via the CJS Exchange programme.

FUNC1244 19.9.4 Data Protection Act Data Protection Act - provide compliance with the Data Protection Act (DPA). This means that all the personal data will have to be processed in line with the DPA and this will influence what information we collect, how long we retain it, who we share it with, etc.

FUNC1245 19.10 Archiving Archiving


C-NOMIS RESTRICTED


FUNC1246 19.10.1 Archive Facility Archive - provide a selective archive facility that will allow historical offender data to be stored and recovered.

FUNC1247 19.10.2 Historical Data Retention Historical Data - retain historical data for 6 years before purging. Some records are retained for longer e.g. offenders on life licence, Schedule 1 offenders.

FUNC1248 19.11 Data Migration Data Migration

FUNC1249 19.11.1 Legacy Data Migration Legacy Data Migration - facilitate the migration of data from legacy systems. This phase includes the cleansing, extraction, data transformation and eventual upload of data into the CTAG database.

FUNC1250 19.11.2 NPS Data Migration NPS Data Migration - migrate and transform data from NPS Areas [redacted]

FUNC2689 19.11.2.1

Change of scope for NPS Migrations Increase the scope of records selected for migration from legacy NPS systems to include:a) all data for high risk offenders (High OASys scores, Tier 3 or 4, MAPPA 2 or 3)b) all data for lifersc) 6 years of data/events for all other types of offender

FUNC2708 19.11.2.2

Provide means of searching and reporting on NPS archived data

This requirement is primarily aimed at NPS archived data but may also applied to HMPS archived data.There needs to be a mechanism that allows local office staff to search for an offender in the NPS Common Load Structure archive database (e.g. by name, date of birth, and any other identifier such as PNC number), and to report on such information, e.g.a) indicating when matching offender(s) were last known to the Probation Service, to which team/office, and the nature of that involvement.b) full details of information held on a particular offender (i.e. Like a Data Subject Access report)

FUNC3000 19.11.2.3

Support for the migration of Disability data for NPS

Probation Circular 34/2006 requires that Probation Areas monitor disability of offenders and employees from December 2006 onwards. The Common Load Structure does not currently support this. The Joint Load Structure supports Disability data but not data relating to disability provision for individuals. The ICMS and C-NOMIS applications support both Disability data and data relating to disability Provisions.

FUNC3014 19.11.2.4

Change to scope of NPS Data Migration

Change scope of Offenders and data selected for NPS data migration as follows:- High Risk Offenders - full migration of all case management data- Active/Recently Active Offenders - full migration for all orders active since 01/04/05 and summary details for earlier orders- Offenders Inactive since 01/04/05 - migrate summary details onlyThis means at least summary details are migrated for all Offenders within the 6 year data retention period for NPS areas.

FUNC3047 19.11.2.5

Provision for migrating Scottish PNC Numbers to C-NOMIS

Probation Areas, particularly those in the North of England, deal with offenders from Scotland. [redacted]allows recording of Scottish PNC numbers, which have a different format to England and Wales PNC numbers. In order to migrate these Scottish PNC numbers to C-NOMIS, we need an additional atribute in the Joint Load Structure.

FUNC3040 19.11.2.6

NPS Reconciliation Reports Following Business Reconciliation workshops and work carried out by Chris Tayler, a new requirement has been identified. This involves the production of reconciliation reports from C-NOMIS that will allow the NPS Areas to satisfy themselves that the correct data has been migrated to C-NOMIS and the correct fields have been populated.NPS reconciliation reports must be capable of being run against both Live and Trial C-NOMIS databases. They will include statistical reports that can be compared with similar reports generated from legacy systems.

FUNC2657 19.11.3 Change to Common Load Structure Various changes following reviews of the CLS and also changes implied by reviews of the Legal Case JLS


C-NOMIS RESTRICTED


FUNC2678 19.11.4 Option to migrate into NOMIS during Business As Usual (BAU)

This CR provides a discussion paper (see attached) that investigates the process, risks and mitigations associated with performing data migration loading of NOMIS during "business as usual" (BAU).

FUNC2990 19.11.5 Data Migration Loading during Business as Usual

Data Migration will run in dedicated access mode for early adopters who will need to be made aware of the resulting business impact.

Following migration of Early Adopters, it is proposed Data Migration loading will run against the live database alongside normal working (i.e. business as usual – BAU).

Please find the extended description in the description note attached. (Unfortunately the whole description of the CR was too long to fit it into this field)

FUNC3035 19.11.6 Change migrated movement and alert data in Case Notes

When Albany was migrated case notes were created in the system with a date & time equal to migration date & time rather than the date &time that the migrated event occurred e.g. if a transfer occurred in LIDS on 14/11/2006, the case note created when this movement was migrated shows a transfer date of 10/12/2006 (i.e. the date of migration). The correct information is available elsewhere in the system but when reading the case notes there is the potential for confusion.A change is required to delete existing case notes and recreate them to display their ‘date & time’ as the date & time that an event occurred rather than the creation date & time of the case note (although they maybe the same). The creation date & time will still be captured in separate existing creation date & time fields, it is expected that these recreated case notes will have a creation date & time equal to the date & time they are recreated (rather than the date & time they were originally created)The CFR covers not only the defects created in migration, but also in IEDT transfers. EDS ([redacted]) has agreed to hotfix this between R1.0b & R1.0c – several fixes will need to be applied to correct the errors caused by IEDT transfers as well as those from the original migratiohn.

FUNC3037 19.11.7 Show true dates in movements and alerts Case Notes

Currently when a case note is triggered and automatically generated by the system its ‘date’ & ‘time’ is recorded as the current system date & time. This has implications for migration and backdated entry into C-NOMIS.Currently when events are migrated into C-NOMIS system case notes are generated automatically with a ‘date’ & ‘time’ equal to the migration date & time rather than the actual date & time of the event. This has resulted in CR00222 having to be raised to correct the data issues in the live system.Similarly, if a user enters data into C-NOMIS ‘after the event’ and that entry triggers an automated case note, then the ‘date’ & ‘time’ of the case note will be the date & time at which it is entered rather than the date & time of the event.A change is required on the system to record a case note’s ‘date’ & ‘time’ as the date & time an event occurred (as previously captured and recorded elsewhere in the system) rather than the date & time of entry (although these will still continue to be captured in separate existing creation date & time fields).

FUNC3093 19.11.8 Additional Local Ref. Data transformation within Data Migration (Parkhurst only

For Albany the LIDS cell data mapped directly onto the c-NOMIS Local Reference Data without transformation.This has not proved to be the case for Parkhurst and may not be the case for other establishments.An additional mapping exercise of LIDS cells to c-NOMIS cells is required in order to provide the input to a new data migration transformation.This is a ‘need to have’ for Parkhurst as this impacts 2/3 of all cell mappings for that establishment. As an example, LIDS cell A-1-102 maps to c-NOMIS cell A-1-002. In contrast LIDS cell C-1-001 maps to c-NOMIS C-1-001which is in-line with set Albany migration ‘rules’.


C-NOMIS RESTRICTED


FUNC3120 19.11.9 FYI - QUANTUM - Implementation of data fix/ Migration of data on movement/ alert

This CR covers the implementation of a data fix for a defect identified in Vantive 1124132

"Migration of movement information creates a case note for every establishment. Migrated data is of no practical use as this information is available elsewhere and should not be migrated in future."

This CR will involve the execution of a script to change/correct migrated movement and alert data in case notes.

Prior to the running of the script a database backup will be taken.Post running validation will be conducted to confirm the correct execution and expected results.

Implementation process will be tested and Verified in NOMIS Pre Prod Environment

Backout plan - Review Progress at 03:30 and if necessary Flashback the database to pre LSR state using established processes

FUNC3121 19.11.10

Duplicate offenders Report (follow up CR from CR00010/ linked to 376 & 396)

C-NOMIS will on occasions contain duplicate records for the same offender, a report is required to list the offenders that have been identified by First Logic as potential merge candidates. The report should include the following data items for each offender record:NOMS NumberPrison NumberSurnameForename 1Forename 2GenderDate of BirthPNC NumberCRO NumberOther IdentifiersCase Identifiers (Magistrates Crt No. etc)Location (Prison Name)Active AlertsUAL Status (Unlawfully At Large)Personal Officer (Prison)Offender Manager (Name)Office (Name)Area (Name)The report will be sorted by;1. Area/Prison2. Office3. Offender Manager/Personal Officer

The report should indicate whether any of these data items relate to the offenders working name or are aliases.


C-NOMIS RESTRICTED


FUNC3140 19.11.11

Selective exclusion of Inactive offenders on HMPS migrations

The current scope of HMPS Data Migration includes offenders retained in LIDS but not currently at that establishment.This includes the following categories:K-Keep. These are offenders discharged from the establishment but where the establishment has chosen to retain the information.B-Bailed. These are bailed offenders.U-UAL. Unlawfully at Large. Absconders – may or may not have been re-captured.The issue surrounds data cleanse of these offenders. In many cases the retained data can be many years old and proves difficult to cleanse. Examples include:Offenders with status K who were released to court but never returned to that establishment. This combination is not valid for migration and causes movement history not to load.Errors in legal information that typically can only be corrected through re-keying in LIDS. These are difficult to cleanse as it requires up-to-date offence information.The requirement is to allow selective exclusion from migration of specific named LIDS offenders. The establishment would be presented a list of their K,B,U offenders and would select those that should be excluded from the migration process.

FUNC3153 19.11.12

Change/correct migrated movement and alert data in case notes

This CR is connected to CR00222"This CR covers the implementation of a fix for a defect identified in Vantive 1124132""Migration of movement information creates a case note for every establishment. Migrated data is of no practical use as this information is available elsewhere and should not be migrated in future."""This CR will change/correct migrated movement and alert data in case notes.

FUNC1251 19.12 Assistive Technology Assistive Technology

FUNC1252 19.12.1 Screen Change Screen Change - provide the facility for screen definitions to be capable of change to meet subsequently issued guidelines supporting accessibility. Screens should use prompts, labels, tool-tips and help text capable of compatibility with standard Assistive technology packages (e.g. Dragon Naturally Speaking and JAWS).

FUNC1253 19.12.2 Data Attributes Data Attributes - provide an ability to modify database field attributes by a central system administrator.


C-NOMIS RESTRICTED


FUNC4558 19.12.3 SAR JAWS Accessibility Issues This change request has been raised as a result of defect 11054. The description of the defect is stated below. This change, requests addressing the issues raised by the defect. As part of this, the business must identify and specify the accelerator keys they require to provide a more accessible application.

Defect Description:

‘Dragon Naturally Speaking can be used to navigate applications, enter, edit and format data / text.

While a user is able to navigate the NOMIS application via voice commands with Dragon, as the application currently stands, this is a very laborious task. The only way for a user to navigate the application (if they are reliant on voice commands) is to verbally replicate keystroke actions: e.g. "tab" to move to next field, "Press shift tab" to move to the previous field, "Press Control Page Down" to move to the next block, "Press Control Page Up" to move to the previous block etc.

This is an issue about how usable the application will be for a Dragon user, e.g. if a user wishes to move five fields in one direction they must state "Tab", "Tab", "Tab", "Tab", "Tab".

Testing of the application has been conducted with an AT consultant, who confirmed that the expectation of users would be to be able to navigate the application with more simple voice commands based on what they can see, e.g. 'Expand Legal Information' to expand that node in the menu pane, 'Next block' to move to next block, 'Click Save' to activate save button, 'Action' to expand the Action menu in the menu bar and so on.

While some generic scripting within Dragon may be possible to enable a user to 'Tab six times' for example, it has been identified that there would be a need for more accelerator keys for elements of the application, e.g. buttons to facilitate further scripting in Dragon to make the application more accessible/usable to Dragon users.

N.b although there is an option in Dragon to navigate via 'Mouse Grid', it was identified by the AT consultant that this is not an acceptable work around.’


C-NOMIS RESTRICTED


FUNC4559 19.12.4 SAR JAWS Accessibility Issues This change request has been raised as a result of analysis of defect 12346. The description of the defect is stated below. This change, requests addressing items 1, 5 and 7 (item 3 is covered by a separate CR, items 2 & 6 the business have decided not to pursue).

Defect Description:

‘SAR Full - Includes all offender data (please find example attached) The way that information is organised in the document makes it very difficult for a JAWS user to interpret. 1. Document contains a number of tables as a means of displaying information. When JAWS user reaches a table in a document they are informed. JAWS users would then use specific key strokes which provide the cell data and header information to support orientation and correct interpretation of table info. Some of the tables do not make sense when interpreted with JAWS because there may be numerous headings in columns. This means that the user is provided with not only the relevant cell data, but also other information from other parts of the table which are unrelated, e.g. Alias and Identifiers section of attached report (page 3) when using JAWS keystrokes. Sections of information are inconsistent in the way that information is structured in tables. 2. When JAWS user arrows down document there is repeat of some of the information in page headers (e.g. NOMS no. booking no. and offender name etc) 3. Some section titles are included as part of tables which are unrelated to the information that they correspond to, e.g. See alerts section of attached report (page 7). JAWS identifies the information under the 'Alert' title as being arranged in a table. The 'verifications - self harm 25/11/2008' is identified by JAWS as the last item at the end of the table. The information relating to this title is arranged in a seperate table structure. This means that the information is not logically structured for JAWS user and is difficult to interpret. 5. See Physical Characteristics section of attached doc (page 9). In the 'Height' section the information for feet and inches is provided in a table, but the information about centimetres is provided outside of the table and is not available to a JAWS user until much later in their navigation through the form. The information in the Physical Characteristics 'table' is not available to a JAWS user in a way which enables an understanding of the content. User first moves through a list of the 'characteristics' and the 'details' are available in a list afterwards, but a user would find it difficult to match up characteristic with detail. 6. See Physical Marks Images. Photo of offender is identified by JAWS as 'graphic …'. This could be labelled as image of offender? 7 IEP levels (page 11 of attached report) - information is visually displayed in a table, but keystroke navigation takes the user through the heading information, then in turn through each item in the table. It is difficult to relate the table content with the column/row headings. N.b There is a table in the Secondary Languages section which works as expected with JAWS (see page 14 of attached report).’

FUNC1254 19.13 On-Line Help On-line Help

FUNC1255 19.13.1 Accessible On-Line Help On-line Help - provide on-line help to assist all types of end-users that is directly accessible from the application and may be maintained by a system administrator. Help should include: How to use the application, Descriptions of the business process, Reference material, Links to external reference material.


C-NOMIS RESTRICTED


FUNC1256 19.13.2 Context-Sensitive Help Context-sensitive Help - provide help that is relevant to the current user screen and to selected fields.

FUNC2686 19.13.3 Online Help Using material produced by the OnDemand product

This Change Request is to implement the OnDemand Help System that provides online help facilities to the operational users of the NOMIS system from release 1.1 onwards.

FUNC1257 19.14 Ergonomics Ergonomics

FUNC1258 19.14.1 Multiple Simultaneous Transactions Multiple Simultaneous Transactions - while a user is engaged in a transaction on the application it should be possible for him to suspend his current work, conduct another transaction (e.g. an enquiry on a different offender), and then return to the original transaction at the point at which he left it, without losing any data already entered.

FUNC1259 19.14.1.1

Standard NOMIS Terminology All screen labels, reference data values and report items must use agreed and standard terminology as documented in the latest version of the NOMIS Terminology spreadsheet

FUNC1260 19.14.2 Consistent Selection Lists Provide consistency on all screens that provide a selection list (example the inconsistent select button on caseload/establishment search) for general navigation

FUNC1261 19.14.3 English Terminology English Terminology - the application must employ English terminology, language and spelling.

FUNC1262 19.14.4 Screen Navigation Screen Navigation - provide the facility to navigate between screens, records and fields with the minimum use of mouse clicks or key strokes e.g. having selected a record from a summary listing a user must be able to walk through the detail records without having to return to the summary listing.

FUNC1263 19.14.5 Configuration Changes Configuration Changes - provide for configuration of navigation to suit NOMS business roles.

FUNC1264 19.14.6 Health & Safety Health and Safety - comply with the UK Health & Safety and Disability Discrimination legislation.

FUNC1265 19.14.7 Ergonomic Enhancements Release Change

Move of ergonomic enhancements (PD 2.2.1.27) from R1.0 to R1.1

FUNC4555 19.14.8 Keystroke for First Field in Form The system must allow a user to move the focus of a C-NOMIS form directly to the first field on that form using a keystroke.

FUNC4556 19.14.9 Keystroke for Last Field in Form The system must allow a user to move the focus of a C-NOMIS form directly to the last field on that form using a keystroke.

FUNC1266 19.15 Miscellaneous Miscellaneous

FUNC1267 19.15.1 Euro Currency Euro Currency - provide support if, and when required, for transition from pound sterling to the euro currency as the currency unit for all financial transactions, including provision for a dual-running transition period.

FUNC1268 19.15.2 Non-Regeneration Non-regeneration - those system functions requiring the generation of a random list not capable of regeneration (e.g. where a random list of names for drug testing) shall utilise an approved randomisation element in their construction. The implementation of this randomisation element shall ensure that in the event of a system restore the functionality remains random. i.e. an exact repeat of user actions does not lead to the same results being experienced.


C-NOMIS RESTRICTED


FUNC2679 19.16 Password requirement The requirement is needed for the effective security of C-NOMIS. The Security standard for password management needs to be met in order for the system to be secure. This requirement is that where an initial password is set up for a user by an Administrator (i.e. an initial password or password reset), the user shall be forced to change this password on first logon. for NOMIS, but only following entry of their current password.

FUNC2684 19.16.1 RMC to enter C-NOMIS User Authorisation data

OIS Live Services has requested that the information relating to Authorisation of a C-NOMIS User is entered by the RMC service provided by EDS as a Quantum Help Desk facility.The service would be a "next working day" service measured from the date of submission of an Authorisation request by the Authority to EDS.

FUNC2698 19.16.2 Transparent Sign-On from C-NOMIS to NOMIS OR & MIS (

Users will have SSO enabled from within NOMIS to the BOE environments. Each user will have an identity in both BOE environments corresponding to their identity in TAG. Syscon will be undertake customisation work to enable this functionality within C-NOMIS by placing two menu items on screen to call the SSO functionality.The Java objects required to implement the required BOE functionality are provided as part of the “BoeTagIntegration” component produced by Business Objects, that will be deployed to the application servers hosting the NOMIS application (for further details refer to the document 5260 NOMIS SSO Design v.10.doc).

FUNC3013 19.16.3 CNOMIS MIS/OR PASSWORD MANAGEMENT

This change is required for the Albany Implementation 09/12/06The configuration of the MIS/OR system dictates that passwords resets be performed using the EDS Management LAN to the NCDS. The BICC would have to located at Meadowbank is they were to perform this task.OIS Live Services require the EDS C-NOMIS Helpdesk to perform password reset and group/roles changes.When the incident or request has been received by EDS the following will happen:1. The EDS Support Team will log the request and perform the identification and validation for the user.2. The EDS support staff will log onto the MIS/OR server via the management LAN and then reset the password or amend the group/role.3. EDS will contact the user and pass on the new password details4. EDS will close the case.

FUNC2690 19.17 C-NOMIS Business Process Model The Business Change and Data Modelling workstream recently carried out a "proof of concept" review on the current C-NOMIS business process model (BPM). Arising out of this, the workstreams jointly developed a proposal for a NOMS BPM (project doc ref 1.1.2.4.5) and submitted this as a business case to the C-NOMIS project board. The intention is for the C-NOMIS BPM project to replace all other NOMS BPM initiatives. The business case has been accepted by the project board and work on the BPM will be funded by OIS.

FUNC1269 20 Interfaces Interfaces

FUNC1270 20.1 Interfaces to Other Prison Service Systems

Interfaces to Other Prison Service Systems - provide interfaces to reduce data collection duplication.

FUNC1271 20.1.1 Accommodation & Occupancy Accommodation and Occupancy (A&O) - provide an interface to A&O. (This is a potential interface as the functionality may be in NOMIS). This interface is to send allocation and population data to A&O.

FUNC1272 20.1.2 PSIMOn PSIMOn - send key performance data to PSIMOn.

FUNC1273 20.1.3 Healthcare Healthcare - send prisoner details to the healthcare application, receive summary and specific healthcare details into NOMIS.

FUNC1274 20.1.4 Finance Finance - send and receive data on prisoner monies details to/from the Finance application ([redacted]).

FUNC1275 20.1.5 OASys OASys - send basic offender details to OASys and receive risk assessment summary information from OASys.


C-NOMIS RESTRICTED


FUNC1276 20.1.6 ProAct ProAct - provide a two way interface providing summary property information.

FUNC1277 20.1.7 Security Security - provide an interface to send prisoner details to security applications.

FUNC1278 20.1.8 Assisted Prison Visitor Scheme Assisted Prison Visitor Scheme - provide an interface to the APV system so that details of completed APV visits completed may be provided

FUNC1279 20.1.9 Pin Phones Pin-phones - interface to the BT pin-phone system

FUNC2405 20.1.10 Travel Restriction Order Information sharing systems between IPS and PS not working resulting in restricted offenders being able to travel abroad after release.

FUNC2662 20.1.11 Addition of NOMIS ID to the LIDS IEDT files and the SISI application New Requirement

This change is to allow LIDS to store and transfer the NOMIS ID, via IEDT files. It will also enable the NOMIS ID to be displayed to screen. It will also appear on Licences, where it is available. It will also pass the NOMIS ID to a redundant field on IIS.Once stored the NOMIS ID will be available for download to the security Information System

FUNC2676 20.1.12 Creation of IIS References on Syscon

IIS currently uses a set of references to amend records. These are not displayed and are originally created LIDS.The change is in two parts:-1) The references need migrating and storing on Tag.2) For new records, Tag will need to create references acceptable to IISThese references will need to be available to pass on the IIS and IEDT interfaces.The references that need creating/passing are:-P7 - Unique_add_numC1 - Case NumberC2 - Case NumberC2 - Offence NumberA2 - Charge_NumberA2 - Adj_ChargeA3 - Charge_NumberA3 - Punishment_NumberD5 - Unique_add_num

FUNC2680 20.1.13 Creation of IIS References on Syscon (Inactive)

IIS currently uses a set of references to amend records. These are not displayed and are originally created LIDS.The change is in two parts:-1) The references need migrating and storing on Tag.2) For new records, Tag will need to create references acceptable to IISThese references will need to be available to pass on the IIS and IEDT interfaces.

FUNC2681 20.1.14 Modifications to LIDS to allow Read-only Mode

After migration to NOMIS has been performed, the intention is to provide read-only access to LIDS for a specific period of time.

Current functionality allows LIDS to be set to read-only at establishment level.However, this has the following drawbacks:• A number of functions are not available• It is possible for the establishment to change LIDS from read-only back to update mode


C-NOMIS RESTRICTED


FUNC3074 20.1.15 Data Extract for RDS to overcome component code & predominant case issues in R1. (Inactive)

Build an interim solution to provide data on Offender’s Component Code and Predominant Case to RDS to supplement the existing F1032 extract and allow them to complete their analysis of the prison population at establishments that have been migrated onto C-NOMIS release 1.0c. It is anticipated that this solution will become redundant after the release of C-NOMIS 1.1.

Proposed Solution:

Business Objects will extract the required Offender data from C-NOMIS and will, based upon the derivation rules provided by Mark Rawlinson, build data structures within the MIS database to support the extraction of the required Component Code and Predominant Case information. Business Objects will then generate a simple report which can be manually extracted as a text file or spreadsheet containing:

Prisoner Number

Surname

Forename 1

Forename 2

Date of Birth

Component Code

LIDS Offence Code for the Predominant Case

Impact:

Business Objects estimate that this work will now take approximately 17 days of ETL development and 6 days of Report development and unit testing. This development is dependent on the provision of the data structures within C-NOMIS agreed to by [redacted] and on the provision of suitable data to test the solution

FUNC3080 20.1.16 IEDT Inbound performance enhancement

The addition of more establishments on CNOMIS for Rel 1.0c will result in an increase in the number of IEDT transfers to CNOMIS.Using the current method of processing transfer files sequentially, there will be delays in the Offender data reaching CNOMIS. Currently, it takes 18 minutes to process a single transfer. Using the current method of processing the transfers sequentially, it takes (18 x number of Offenders) minutes to complete the transfer process, so a batch of 5 transfers will result in the last Offender data taking 90 minutes to reach CNOMIS.

The greater the number of transfers in a batch, the longer the delay in data reaching NOMIS.

[redacted]

FUNC3094 20.1.17 Change the Index on IIS to ignore the Unique Address Number

Change the Index on IIS to ignore the Unique Address Number


C-NOMIS RESTRICTED


FUNC4418 20.1.18 Latest PNC, CRO When a PNC or CRO number for an offender record is supplied to IIS, OASys, or the A&O extract, C-NOMIS must provide the latest modified PNC or CRO associated with the working name of that offender record.

FUNC4419 20.1.19 Copy PNC, CRO to Alias When a new alias is created for an offender record in C-NOMIS, the system must record against that alias the latest modified PNC or CRO associated with the current working name of the offender record.

FUNC4537 20.1.20 OASys Message Trigger for merge of NOMIS IDs

This change is to trigger the existing "Reception" type OASys message when two NOMIS IDs are merged.

FUNC4550 20.1.21 IIS Notification of Licence Deletion If a user has indicated that a licence is terminated due to error then the system must notify IIS that the licence should be deleted.

FUNC4551 20.1.22 IIS Notification of Licence Condition Deletion

If a user has indicated that a licence condition is terminated due to error then the system must notify IIS that the licence condition should be deleted.

FUNC1280 20.2 External Agency / System Interface Capability

External Agency / System Interface Capability - provide interfaces to share information and documents with non-HMPS agencies.

FUNC1281 20.2.1 Cross Justice Agencies Cross Justice Agencies - provide an interface capability to CJIT Data Exchange Standards, with other justice agencies.

FUNC1282 20.2.2 Other External Agencies Other External Agencies - provide an interface capability to other external agencies and their systems via CJIT exchange and email (with or without secure email).

FUNC1283 20.2.3 Children Database Children Database - provide an interface capability to local Childrens' databases for information sharing.

FUNC1284 20.3 Other Providers Other Providers

FUNC1285 20.3.1 Other Providers not on GSI Networks

Other Providers not on GSI Networks - enable direct access to NOMIS (subject to appropriate access rights) by 3rd party non CJS interventions providers who are not on GSI networks.

FUNC1286 20.3.2 Data Interchange betweend IND Systems and C-NOMIS

Provide capability to extract information on immigration and foreign national offenders. Enable data interchange between IND systems and C-NOMIS

FUNC1287 20.3.3 E-OASys to C-NOMIS Additional query and response from e-OASys to C-NOMIS via data hub

FUNC1288 20.3.4 Risk Information from eOASys Update of C-NOMIS with Risk Information from eOASys

FUNC1289 20.3.5 Amend OASys Address Lines Amend Oasys address lines

FUNC1290 20.3.6 eOASys Searching eOASys local/national searching (further clarification on CR00065)

FUNC1291 20.3.7 Offender Home Address to OASys Identify correct offender home address to be passed to OASys

FUNC1292 20.3.8 Access to SOCA Access to SOCA


C-NOMIS RESTRICTED


FUNC1293 20.4 Pilot Sites Pilot sites

FUNC1294 21 Sentence Plan Sentence Plan

FUNC1295 21.1 Offender Assessment Offender Assessment

FUNC1296 21.1.1 OASys Sets Record details of one or more OASys sets

FUNC1297 21.1.2 OASys Sets Chronologically The OASys sets must be accessible in chronological order of review date

FUNC1298 21.1.3 User to Break from Assessment The user must be able to break off from the assessment at any time and come back to it

FUNC1299 21.1.4 Finished Set for Countersignature The system must provide facilities to route a finished set for countersignature

FUNC1300 21.1.5 Mark Set as Completed The user must be able to mark a set as completed thus locking that set

FUNC1301 21.1.6 Copy and Paste Text The user must be able to copy and paste text from previous assessments

FUNC1302 21.1.7 Base New Assessment on Most Recent

The user should be able to base a new assessment on the most recent assessment

FUNC1303 21.1.8 Data Automatically Transferred to RoH Assessment

The system must allow designated data from sections 1-13 to be automatically transferred to the RoH assessment in full

FUNC1304 21.1.9 Automatically Score Multiple Choice The system must provide a score automatically where answers are via multiple choice

FUNC1305 21.1.10 Include Weighted Scores The system must automatically calculate scores including weighted scores

FUNC1306 21.1.11 Calculate Summary Sheet The system must automatically calculate the summary sheet of all the scores

FUNC1307 21.1.12 Specialist Assessments Suggestion The system must suggest specialist assessments or interventions depending on answers and scoring

FUNC1308 21.1.13 Inheritance of Data The system must automatically inherit info from the most complete OASys 1-13 and ROH into the supervision plan ( and allow the user to reject of amend the inherited information)

FUNC1309 21.1.14 Link from PSR Assessment to PSR Document

The system must automatically provide a link from the PSR assessment to the PSR document

FUNC1310 21.1.15 Type of Assessment The user must be able to identify the set as an outline, initial, review (multiple) transfer or termination

FUNC1311 21.1.16 Review Alert The system must alert the offender manager to the need for reviews and set up the appointments as required


C-NOMIS RESTRICTED


FUNC1312 21.1.17 Non-Disclosure to Offender The system must allow for information not to be disclosed to the offender to be identified as such

FUNC1313 21.1.18 Switch to Non-Disclosed Data User must be able to to switch from any part of the assessment to the information not to be disclosed to the offender.

FUNC1314 21.1.19 Interface with ODEAT The system must interface with the ODEAT system in providing data for research on all assessments

FUNC1315 21.2 Single Sentence Plan Single Sentence Plan

FUNC1316 21.2.1 Going Straight Contract Going Straight Contract

FUNC1317 21.2.2 Single Sentence Plan Sentence Plan - NOMIS must hold a Single Sentence Plan for an offender. This is a description of future activities which, integrated together, are designed to meet all of the objectives for which an offender is under the jurisdiction of NOMS, within the timescales of that jurisdiction

FUNC1318 21.2.3 Legal Parameters Legal Parameters - the single sentence plan must set out the legal parameters defining its boundaries

FUNC1319 21.2.4 Specific Legal Requirements Specific Legal Requirements - where the legal parameters are defined by a sentence, any specific legal sentence requirements must be identifiable

FUNC1320 21.2.5 Objectives Objectives - the objectives to be met by the single sentence plan must be clear

FUNC1321 21.2.6 Multiple Objectives Multiple Objectives - objectives may be specified by a court, but may include other sentence objectives not specified by the court, and other objectives which are not sentence objectives, but Offender Management objectives

FUNC1322 21.2.7 Risks and Needs Risks and Needs - action must be specified to address the risks and needs presented by the offender

FUNC1323 21.2.8 Objectives Linked to Activities Objectives Linked to Activities - activity defined as forming part of the plan should be linked to the objectives

FUNC1324 21.2.9 Level of Offender Engagement Level of Offender Engagement - the plans should indicate the extent to which the offender has participated in and is aware of the planning process, accepts or is engaged with it

FUNC1325 21.2.10 Offender Disclosure Permission Offender Disclosure Permission - the plan, or a process associated with it, should obtain and record offender permission to managed disclosure, or specify any limits to this

FUNC1326 21.2.11 Coordination Arrangements Coordination Arrangements - arrangements by which the various elements of the plan will be co-ordinated should be specified, including who is responsible for doing what, by when and using which resources or methods

FUNC1327 21.2.12 Benchmark Progress Benchmark Progress - the plan should be “locked down” at a specified point in time so that progress can be monitored and evaluated against that locked down version

FUNC1328 21.2.13 Plan Amendment Plan Amendment - it should be possible to amend the plan in the light of progress, other changes, or new information and record when or why this has happened

FUNC1329 21.2.14 Plan Type Plan Type - a single sentence plan can one of three types; Initial, Review or Termination. It should be clear whether the plan is an initial one, or an updated one, evolved incrementally from an initial one


C-NOMIS RESTRICTED


FUNC1330 21.2.15 Link to Assessment Link to Assessment - the Sentence Plan must be an easily locatable, identifiable, integrated document, linked with the offender assessment but distinct and separate from it

FUNC1331 21.2.16 Printed Document Format Printed Document Format - the “look and feel” of the document may be different when viewed on screen than it looks in its printed form.

FUNC1332 21.2.17 Scaleable Format Scaleable Format - there should be a single, consistent, recognisable core to the plan, capable of being scaled-up from straightforward, single-activity plans into complex multiple-activity plans

FUNC1333 21.2.18 Compex Single Issue Plans Complex Single Issue Plans - more complex single issue plans (e.g. Individual Learning Plan for basic skills) should be associated with the main plan

FUNC1334 21.2.19 Agency Secure Database Agency Secure Database - the core plan should be held on an agency secure database

FUNC1335 21.2.20 SMART Process Thinking SMART Process Thinking - the layout of the plan should lead the planner through the SMART process, linking issue/objective to activity to outcome, defining responsibility and setting timescales

FUNC1336 21.2.21 Print Sentence Plan Print Sentence Plan - it should be possible to print a version of the plan in a format which is offender-friendly

FUNC1337 21.2.22 Offender Copy Provided Offender Copy Provided - the case record should record the fact that the offender has been provided with a copy/version of the plan

FUNC1338 21.2.23 Forward Plan to Providers Forward Plan to Providers - it should be possible to forward a version of the plan to providers and partners named in the plan as making a contribution to its implementation


FUNC1340 21.2.25 Control of the Plan Control of the Plan - control of the plan should reside with a named Offender Manager, amendable only by express permission to named others by the Offender Manager or by the Offender Manager's line management

FUNC1341 21.2.26 Review Progress Review Progress - the format should enable progress against the plan to be reviewed and recorded

FUNC1342 21.2.27 Revised Plan Revised Plan - enable a revised plan to be linked to the assessment and the review

FUNC1343 21.2.28 Review Schedule Review Schedule - a schedule of formal reviews should be incorporated into the host case management system

FUNC1344 21.2.29 Interim Reviews Interim Reviews - there should be a facility to conduct interim reviews and produce updated plans from them

FUNC1345 21.2.30 Link to Offender Assessment Link to Offender Assessment - the Sentence Plan should be clearly linked to the offender assessment and set into the context of the legal framework and the resources available

FUNC1346 21.2.31 Working Plan Working Plan - the working plan must remain in a dynamic relationship with the assessment, which itself will change with progress, new information and changing circumstances

FUNC1347 21.2.32 Review Reminder Review Reminder - the system should send an alert at a predetermined period to remind the OM to review the case assessment and amend the sentence plan if necessary


C-NOMIS RESTRICTED


FUNC1348 21.2.33 Offender Self Assessment Offender Self Assessment - there should be an element or version of the plan which enables the offender to make commitments which contribute to the plan

FUNC1349 22 Victims Victims

FUNC1350 22.1 Victim Screen Access Victim Screen Access - allow access to victim screens within NOMIS to be available only to victim contact staff, but victim staff should have read access to the offender screens that are linked to their victim cases - as in virtual team.

FUNC1351 22.2 Statutory Victim Contact Statutory Victim Contact - identify the offence type and sentence outcome that qualify for statutory victim contact.

FUNC1352 22.3 Alert for Potential Victim Case Alert for Potential Victim Case - alert the user that this is a potential victim case once a qualifying offence/sentence has been entered into NOMIS and provide a referral to the relevant victim contact unit.

FUNC1353 22.4 Victim Case Active or Inactive Victim Case Active or Inactive - provide a field in the offender record to indicate that this is a victim case, indicate if victim case active or closed.

FUNC1354 22.5 Victim Record Victim Record - create and maintain Victim Record.

FUNC1355 22.6 Link Victim to all Offenders Link Victim to all Offenders - link the victim record to all of the offenders who were involved in the index offences and vice versa.

FUNC1356 22.7 Victim Opt Out Victim Opt out - record if the victim has opted out of NPS contact following the initial discussion with the Police.

FUNC1357 22.8 Date of Initial Contact Date of Initial Contact - record the date that the initial contact is made by the NPS with the victim.

FUNC1358 22.9 Victim Case Note Victim Case Note - provide case notes/ contact log to record victim contact activity.

FUNC1359 22.10 Future Alert Date Future Alert Date - provide a task alert that can be manually set to a future date.

FUNC1360 22.11 Victim Officer Access Victim Officer Access - provide the victim officer with the same functionality re workflow as offender manager.

FUNC1361 22.12 Victim Documents Victim Documents - provide facility to create and store reports that are generated as the result of victim contact.

FUNC1362 22.13 Close & Reactivate Victim Cases Close and Reactivate Victim Cases - enable individual victim cases to be serially closed and/or reactivated until the offender sentence expiry date is reached.

FUNC1363 22.14 Victim MIS Victim MIS - produce a range of Management Information Reports.

FUNC1364 22.15 Victim Contact Details Victim Contact Details - record and maintain victim contact details, including date of contact with victim, result.

FUNC1365 22.16 Victim Requests for Non-Disclosure Victim Requests - record and track victim requests for non-disclosure (request, decision, appeal).

FUNC1366 22.17 Victim Contact 40 day Alert Initial VCLU Contact - provide an automatic alert to the NPS area VCLU who initiated the request for contact (n) days prior to the 40 day expiry date if the task has not been completed.


C-NOMIS RESTRICTED


FUNC1367 23 Approved Premises Approved Premises

FUNC1368 23.1 Approved Premises Information Approved Premises Information - hold and display approved premises information, displaying this by:Approved Premises code,Region,Area,address,telephone,fax,category (male/female/mixed),number of bedspaces,number of single rooms/shared rooms in main Approved Premisesnumber of rooms/shared rooms in clusters/self catering unitsprovision for disabled residentsrestrictions on offences not accepted,curfew arrangements,map and travel directions.

FUNC1369 23.2 Current Vacant Bed Spaces Current Vacant Bed Spaces - this should be automatically updated by the system.

FUNC1370 23.3 Temporary Bed Space Temporary Bed-space - record temporary bed-space.

FUNC1371 23.4 AP Rules AP Rules - hold rules for each Approved Premises which need to be printed for offender to sign.

FUNC1372 23.5 AP Standard Referral Form AP Standard Referral Form - hold standard referral form to be completed on line and electronically sent to the identiifed Approved Premises (sometimes more than one premises).

FUNC1373 23.6 Alert OM on AP Referral Alert OM on AP Referral - alert the relevent Approved premises of the referral when referral form completed by Offender Manager.

FUNC1374 23.7 Referral Outcome Alert Referral Outcome Alert - alert Offender Manager of outcome of referral.

FUNC1375 23.8 Referral Outcome Capture Referral Outcome Capture - ability to capture outcome of referral:*Accepted*Rejected - reasons:No vacanciesInsufficient informationRisk of harm too lowRisk to community too great to be managedRisk to staff too great to be managedRisk to residents too great to be managedRisk to self too great to be managedInadequate facilities for health needs.

FUNC1376 23.9 Arrival Date & Time Arrival Date and Time - record arrival date and time.


C-NOMIS RESTRICTED


FUNC1377 23.10 Reason for Residency Reason for Residency - record reason for residency.

FUNC1378 23.11 Bed Assignment Bed Assignment - assign a room or bed (shared rooms).

FUNC1379 23.12 AP Officer Assignment AP Officer Assignment - assign an Approved Premises officer to case.

FUNC1380 23.13 AP Contact Log AP Contact Log - record notes of contacts with Approved premises staff.

FUNC1381 23.14 AP Property AP Property - record and maintain details of property put in safe storage, including serial number, date of receipt, description. This needs to be printed for offender to sign.

FUNC1382 23.15 Dietary Needs Dietary Needs - record and maintain dietary needs.

FUNC1383 23.16 Medical Needs Medical Needs - record and maintain medical needs and details of medication requirements.

FUNC1384 23.17 Rent Payment Log Rent Payment Log - set up and maintain residents rent payment log.

FUNC1385 23.18 Resident's GP Resident's GP - record and maintain name and practice of resident's GP.

FUNC1386 23.19 AP Offender Details AP Offender Details - record offenders leaving and entering the Approved Premises, including description of clothes being worn.

FUNC1387 23.20 Approved Premises Curfew Approved Premises Curfew - record compliance with Approved Premises curfew of every resident at set time each evening.

FUNC1388 23.21 Individual Curfew Requirements Individual Curfew Requirements - record compliance with individual curfew requirements.

FUNC1389 23.22 Breach of Bail Breach of Bail - record breach of bail requirements.

FUNC1390 23.23 Alert on Enforcement Issue Alert on Enforcement Issue - alert offender manager of breach.

FUNC1391 23.24 Online Self Harm Monitoring Online Self Harm Monitoring - hold self harm monitoring form which needs to be completed on-line.

FUNC1392 23.25 Bedspace Loss Reason Bedspace Loss Reason - record the reason for a loss of bedspace.

FUNC1393 23.26 Monthly Occupancy Monthly Occupancy - record monthly occupancy as a percentage.

FUNC1394 23.27 AP Discharge Code AP Discharge Code - record the discharge code and reason, actual discharge date and time.

FUNC1395 23.28 Room Clearance Room Clearance - record details of property bagged after resident unplanned departure and the staff involved.

FUNC1396 23.29 Vacancy Lists by Hotel & Gender How many beds a hostel has and the gender of the referral. Vacancy lists for bail information officers by hostel and gender


C-NOMIS RESTRICTED


FUNC1397 24 Prioritising R1.1 Requirements Encompasses CR0022, CR0043, CR0044, CR0045

FUNC1398 25 Outstanding Design Changes Oustanding unresolved issues with Syscon - include reverting to previous design of OCDCCASE, error in rule for sequencing rolling modular programmes - OCMPHMOD, Area/Region and Blocks for a phase )

FUNC1399 26 Requirements Clarification Clarification of Functional requirements Catalogue

FUNC2989 27 Early Environment CR's

FUNC2654 27.1 Provision of NCDS Servers for support of MIS

Provision of NCDS Servers for support of MIS

FUNC2655 27.1.1 Provision of NCDS Servers for support of Operational Reports

Provision of NCDS Servers for support of Operational Reports

FUNC2661 27.1.2 Revised NCDS Infrastructure design, build, test & supp for MIS, Operational Rep

This CR is for the design, installation, commissioning, build, test, support and management of the above hardware. Two further CRs will be raised for the life-cycle development of MIS and OR using a Business Objects solution. These will cover the requirement definition, design, development, test, implementation, support and management of the solutions.

FUNC2669 27.1.3 MIS and Operational Reporting using Business Objects

This Change Request covers the introduction of MIS and Operational Reporting using the Business Objects tool suite to Release 1.0 and Release 1.1.The change includes the solution agreed between NOMS, EDS and Business Object and defined in the OR Technical Architecture and the MIS Technical Architecture

FUNC2672 27.1.4 Hire of Interim MIS V240 Server A short term hire of [redacted] is required to enable engineering work on the MIS servers to proceed with no loss of testing time.

FUNC2683 27.1.5 Provision of infrastructure for MIS / OR service

The MIS solution for R1.0 requires several items of hardware to be procured at the earliest opportunity if the delivery timeline is to be achieved

FUNC3025 27.1.6 MIS/OR Business Objects Support and Service Levels for Albany

Change the service window for MIS/OR to 06.00 to 24.00 Monday to Saturday and 09.00 to 24.00 Sunday and Public Holidays.

2. EDS to contract Business Objects to provide 2nd/3rd line support for all activities previously determined to be the responsibility of the BICC, and that the Authority wants the end-to-end support to be owned, provided and managed by/through EDS as the prime supplier.

3. Provide support for the Business Objects Application components within the service window specified in (1)

4. Support and “bug” fixes for reports developed and implemented in Release 1.0 with the normal and extended hours.

5. Maintenance of the National Reporting catalogue for R1.0 to ensure new and modified report are tested and assured before updating the catalogue.

6. Consultancy and Support for Albany users developing ad-hoc reports in R1.0.


C-NOMIS RESTRICTED


FUNC2659 27.1.7 Purchase Of MQ Series Licences For OASys Interface

Purchase [redacted] for installation on the NOMIS Data Hub. This is required for the development, test and production environments. We also need to train two development staff to install/configure/develop it.

FUNC2705 27.1.8 MIS/OR Budget July – September 2006

To provide commercial cover of £1,065,562, to cover Infrastructure and Time & Materials costs, incurred between July and September, in accordance with the already presented Price Model and approved PD’s, to enable work on the MIS/OR Project to be carried out whilst contract negotiations continue.

FUNC2997 27.1.9 MIS/OR Budget This CR is for the difference between the Price in the Proposal and the initial amount in CR00091.

Following submission by EDS of the “NOMIS OR and MIS Proposal”, version 2.1, dated 10th July 2006, the OR & MIS workstream work began under CR00091, which provided commercial cover of £1,065,562 intended to cover the period July to September 2006 to enable work on the OR & MIS Proposal to be carried out while contractual negotiations took place.

The overall financial impact of the OR/MIS work is summarized, below. The figures account for work already undertaken in FY 2005/06 and all kit purchased in that period, as well as all future work and kit until June 2012, when the contract tenure is due to end.

FUNC3073 27.1.10 Creation of a Training enviroment for MIS on the CHET.

Creation of a Training enviroment for MIS on the CHET.Requirement for it to be intergrated with the Training Database and share the same offender records.There also needs to be a process for configeration management to ensure that new MIS reports are headed as soon as they come out of testing and for the training database datasets to be updated accorodingly

FUNC2658 27.2 Assistive Technology Tools for Testing

To enable Syscon and the NOMS OIS AT Co-ordinator to test Assitive Technology compliance of the C-NOMIS application. The following software and equipment are required.

6 x Dragon Naturally Speaking - [redacted]6 x Zoomtext - [redacted]6 x JAWS Professional - [redacted]6 x TextHelp – [redacted]

2 x AT Gold Build Laptops from Steria

FUNC2677 27.2.1 Ergonomic Testing Laptop Provision of laptop for Loughborough University to conduct Ergonomic Assessments with users.

FUNC3007 27.2.2 PCs for User Acceptance Testing

This is a Change Request for Contracted Out Prisons, the workstream leader is [redacted]. This Change Rewquest has been submitted on behalf of [redacted].

8 PCs required for User Acceptance Testing

FUNC3103 27.2.3 12 PC's needed for UAT UAT currently occupy G10 (daily work, HMPS UAT) and G09 (NPS UAT, general use (training) for all on ground floor when not being used for UAT execution)

G09 requires 12 PC's to be fully functional. These PC's should be standard Grenadier House spec and should come with standard flat monitors.

FUNC3127 27.2.4 UAT - 2 x laptops required These are required to load the C-NOMIS application and provide transportable versions for UAT prep where we are required to visit externals. These are also requried for AT testing execution.


C-NOMIS RESTRICTED


FUNC3128 27.2.5 FYI only - UAT Team - 5 x ergonomic Keyboards and 5 x Ergonomic mice required

5 x ergonomic Keyboards and 5 x Ergonomic mice

Detail of this request can be found in the following email:

[redacted]

FUNC2656 27.3 Provision of Test Servers at Chertsey to support OASys Integration Testing

The project requires the purchase and installation of appropriate hardware into [redacted] to support integration testing of OASys & eOASys. Hardware needs to be ordered immediately to ensure timely delivery. Equipment to be purchased is:2 x [redacted] and associated preripherals

FUNC2667 27.3.1 Sun Cluster Installation for Integration Test Environment

- Sun are required to document and carry out the build of 5 Solaris servers, including Sun SAN and clustering.- Oracle are required to install clustered Oracle Servers and Oracle Dataguard.

FUNC2668 27.3.2 Development and Test Equipment rental continuation

Continuation of rental of equipment supporting the NOMIS development and test environments.

FUNC2697 27.3.3 Extend loan hardware for Functional Testing by 2 weeks

Extend loan of SUN server required in the Functional Test area by 2 weeks

FUNC2694 27.3.4 Expand storage capacity of the C-NOMIS integration test environment

The Storage available within the Integration Test environment is not sufficient to accommodate Operational Reporting and the Management Information System testing.The Integration environment uses a Sun StorageTek 3510 SAN, which currently supports 12x36GB disks, giving 432GB of RAW storage, which is configured as 2 partitions raided.To accommodate the additional storage requirements, a SAN expansion unit will need to be added to the current 3510 array. The recommendation is to add a minimum expansion unit of the following capacity;• 5x300GB disks providing 1.2TB approximate storage available.

FUNC2688 27.3.5 Additional Integration Testing Facilities

Additional Server Facilities required, for one month, to support enhanced integration testing.

FUNC3003 27.3.6 New Functional Test Environment For Meadowbank.

To provide additional Function Test Environment Capacity, required specifically (but not exclusively) to enable testing of R1.1 product to commence.

FUNC2996 27.3.7 Update to the Performance & Scalability Test Environment Application Server Tier

Currently the application servers in the Performance and Scalability test environment at Meadowbank do not reflect the type and memory size of the servers used in production.

The change is to exchange the current 4 Application Servers (v490 Sparc IV, 16G Ram) with 2 Application Servers (v490 Sparc IV+, 32G Ram) to be aligned with the current processors in the datacenter.


C-NOMIS RESTRICTED


FUNC2991 27.3.8 C-NOMIS Quantum co-existence testing server

To build an existing V240 server to be used for Co-existence testing for inclusion in the Quantum Model Office test environment.The proposed server will be used for co-existence testing of C-NOMIS, including BOE - MIS and OR related components, with the Quantum infrastructure service. It is not intended to be used to test any of NOMIS Data Hub or data migration related components, which will remain within the System Integration environment. The server will be zoned to provide a number of virtual machines equivalent to those used in the production environments and include various databases and file stores required for C-NOMIS, MIS & OR.This V240 server is capable of providing future C-NOMIS, MIS and OR co-existence testing needs and where necessary could potentially be utilised for demonstration purposes.

FUNC3008 27.3.9 NCDS Interconnect Amendment to allow Penetration testing of the Global Crossing

To modify the interconnect firewall implementation within the Global Crossing environment to allow independent penetration testing of the interconnect firewalls, as currently there is nowhere for penetration testers to attach test equipment within the Interconnect Area. This modification will add a temporary interface (subnet) to each of the 4 NOMIS/Quantum interconnect firewalls and a temporary change to the interconnect routers. See attachment for more details. (There is a lead time of 4-6 weeks for Global Crossing to procure and install the additional infrastructure).

FUNC3038 27.3.10 Production Oracle, Solaris and Application Upgrade

On 9th January the JDWG agreed that EDS would release Oracle Database Release [redacted] into production following a testing cycle and that this would impact the Release 1b plan. This was separated from Release 1b, as this contains a large number of application fixes across a number of areas.It is recommended that a maintenance release is prepared that upgrades Oracle and Solaris patch levels, along with a deploying a number of business priority and/or marginal risk application fixes. This work would be carried out independently of 1.0b and would be completed prior to 1.0b.COTS Upgrades• Upgrade Oracle from [redacted] to [redacted]Application FixesThe fixes outlined below would require changes only to minor database / application configuration parameters.1. Natcodes Reference Data update2. Redeployment of Ad-hoc reports to global access (rather than to user’s inbox) with fixes tested in UAT3. Amendment of xTAG JMS queue persistence durations (config) to support diagnostics

FUNC3039 27.3.11 NOMIS Technical Environments for R1.1

Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution, this CR provides the next priority orders to support the environments as described in the document titled “NOMIS Technical Environments High-Level Design’ version 0.8, which was provided under PD 7.2.3.21, and identifies the infrastructure equipment required for Release 1.1 and the strategy for provisioning the environments. This document has been approved by Technical Assurance.CR00183 provided an outline budgetary estimate for the environments in their entirety, but offers a staged approach to the implementation and provisioning of the environments so that the environments which are considered a priority can be dealt with in a timely manner. Spreadsheet “Tech Env HLD (Kit & Costs) v14” provides a list of equipment and estimated costs for the environments in their entirety.This CR specifically requests the provision of the Wide Area Network infrastructure required for the environments that are a priority to enable the timely development and testing of C-NOMIS Release 1.1

FUNC3041 27.3.12 Apply mandatory/urgent patches to Solaris operating system (CR006887

Apply mandatory/urgent patches to Solaris operating system on specified servers, spread over 4 days, with 2 days for contingency. Schedule currently is 26th: [redacted]. 27th: [redacted]. 28th: [redacted]. 29th: [redacted]. 30th/31st contingency. All [redacted] models to have IPGE interface changed to [redacted]


C-NOMIS RESTRICTED


FUNC3042 27.3.13 Test Automation Pilot To execute the pilot phases of the Release 1.1 Automation Regression & BVT Testing, leading to greater understanding of the processes, and the production of the Automation Deployment plans.The Automation pilot comprises: -• The production of a small number of Automated Test scripts with a Scheduling mechanism• Redefining the test scripts so that they are ready to be automated• Production of the NOMIS Regression Automation Deployment Plan document• Production of the NOMIS BVT Automation Deployment Plan document• Creation of scripts and technical assets for a proof of concept of the automated BVT

FUNC3049 27.3.14 NOMIS Patch Release 2 and Oracle 10.2.0.2 - 7-8/2 (Quantum CR006819)

his CR covers the implementation of number of NOMIS Patch Release 2 and Oracle [redacted] and a number of post [redacted] patches. The Patches are required in order to address a number of production issues that may cause intermittent but significant service impact.

Patch Release 2 comprisesThe fixes outlined below would require changes only to minor database / application configuration parameters.1. Natcodes Reference Data update2. Redeployment of Ad-hoc reports to global access (rather than to user’s inbox) with fixes tested in UAT3. Amendment of xTAG JMS queue persistence durations (config) to support diagnostics

The patches have been tested in the Meadowbank environment, and the implementation process WILL HAVE been tested in the Pre Prod env by the Live Services Team. Until the pre prod test against a representative environment, the timings are subject to change and review.

FUNC3059 27.3.15 NOMIS Technical Environments for R1.1 (Steria)

Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution, this CR identifies a number of additional technical environments needed by Steria to support the development and testing of key work packages for C-NOMIS: Data Migration, Infrastructure, Testing.

The document "C-NOMIS NPS INFRASTRUCTURE, TRAINING & MIGRATION ENVIRONMENTS" (see attached) describes the environments needed, the justification for them and their associated purchase costs.

Specifically, this CR requests financial approval for Steria to purchase the following categories of items to support its development and testing for C-NOMIS:a) Hardware (additional servers or upgrades)b) Softwarec) Supporting Infrastructure


C-NOMIS RESTRICTED


FUNC3068 27.3.16 NOMIS Technical envmnt for R1.1 – Steria and P&S envmnt enhancement

To support the introduction of Release 1.1 Steria testing requirements additional hardware will need to be provisioned. Steria have requested the following dedicated environments be made available as defined in the Steria document “C-NOMIS NPS Infrastructure, Training & Migration Environments” version 0.1 dated 19th January 2007;1. JLS transmission test environment2. Meadowbank test facility3. Meadowbank C-NOMIS release test4. OMNI release test.5. JLS transmission & load test environment6. JLS transmission test & trail load environmentCurrently, the environments available within the NOMIS solution can accommodate the requirements for two of the six required above. Specifically, the environments already in existence are;1. JLS transmission test environment2. Meadowbank test facility.These two environments are know as;1. The Data Migration trial environment2. The NMOE (NOMIS Model Office Environment)To support the introduction of the additional four environments that cannot be accommodated on the current hardware already in place due to resource constraints and concurrent testing processes, the following four environments will need provisioning;1. Meadowbank C-NOMIS release test2. OMNI release test3. JLS transmission & load test environment4. JLS transmission test & trail load environmentThe recommendation for introducing these environments is to re-purpose the P&S environment at Meadowbank and procure a new environment to be hosted within the Doxford data centre where economies of scale can be achieved in-line with the non-production environment strategy. All activity targeted for the following environments will be re-located to this new environments;1. PSTE – Performance testing (Small Scale)2. NFTE – Non functional testing3. Interaction profiling

FUNC3077 27.3.17 Test environment set up and environment support for Release 1.0c OASys and eOASy

EDS Testing – [redacted]SunGard Testing – [redacted]

Provision of a test environment and test environment support to enable SunGard to undertake regression testing of OASys and eOASys against C-NOMIS Release 1.0c.The set up is required on or just after 25/04/2007 to enable SunGard to begin regression testing after Cycle 1 of EDS’ Integration Testing has completed, currently planned for 20/04/2007

FUNC3083 27.3.18 Test environment set up and environment support for Release 1.1 OASys and eOASys

Provision of a test environment and test environment support to enable SunGard to undertake regression testing of OASys and eOASys against C-NOMIS Release 1.1.It is suggested that the set up is required on or just after Cycle 1 of EDS’ Integration Testing has completed, currently planned for 30/01/2008 to enable SunGard to begin regression testing.


C-NOMIS RESTRICTED


FUNC3104 27.3.19 eOASys release 4.2.1c - change of scope

eOASys support release 4.2.1c is defined and approved as C-NOMIS CR336.

The scope of this release has changed as follows:

Change ref 189 - removed from scope

Change refs NPD0094 and NPD0095 - added to scope. Details of these changes are attached.

FUNC3105 27.3.20 Change to Internet access method for Test Director

The Internet access method for Test Director needs to be changed from [redacted]

FUNC3106 27.3.21 eOASys support release 4.2.1d

eOASys support release 4.2.1d is scheduled for release on the weekend of 28th July 2007. This will contain problem fixes changes ref NPD0084, NPD0096, NPD0097. Details are included in the attached eOASys change requests.

FUNC3107 27.3.22 Remove eOASys interface HTTPS proof of concept

SunGard scope currently includes a proof of concept to determine whether eOASys (running on Lotus Notes) can communicate using HTTPS rather than HTTP.

EDS have confirmed that HTTPS will not be required for the eOASys interface, so this product can be removed.

FUNC3108 27.3.23 OASys: Oracle db partitioning The eOASys central Oracle database (which also provides the link between eOASys and HMPS OASys) needs to be partitioned to provide a tactical solution to a capacity problem with the current daily backup system.

This will use Oracle Partitioning to move historic messages into a separate tablespace, thus reducing the size of the daily backup.

The implementation date is not yet confirmed, but it is likely to be second half of July 2007

FUNC3111 27.3.24 EDS Man time to commission additional Test Environments

CR00250 did not include any EDS man time to commission these additional servers and as these servers are additional to the original Rel 1.1 Test environments procured as part of CR00185 no man-time was included in the Rel 1.1 Cost model.

FUNC3129 27.3.25 eOASys support release 4.2.1c

eOASys maintenance release 4.2.1c is scheduled for the weekend of 29/30 June. This will contain changes to eOASys only, and no impact on HMPS OASys or C-NOMIS is expected.

Changes are detailed in the attached eOASys change requests. These include some defect fixes (NPD0075, NPD0076 and NPD0083) and some minor functional changes (185, 189, 202 and 267).

FUNC3130 27.3.26 HMPS OASys incident release An incident release for HMPS OASys is planned for the end of June 2007. This contains a number of CRs and defects, described in the attached document.

The scope document has not been confirmed yet by the OASys client, so is subject to change.

FUNC3131 27.3.27 OASys release 4.2.3 CR raised for information only at this stage. OASys release 4.2.3 is planned for end November/early December 2007. The scope is not fully defined yet, but this release will include the OGRS 3 risk predictor algorithm as its main piece of new functionality.

This release applies to both HMPS OASys and NPS eOASys.


C-NOMIS RESTRICTED


FUNC3132 27.3.28 QUANTUM - FYI - Implementation of LSR 3 - 2 main elements

Implementation of LSR 3 - 2 main elements1) Data Corrections - This LSR Addresses a number of incidents that relate to errant or Incorrect data that has either been entered in error by the user, as a result of a failed batch IEP process or was loaded up as part of the original Take on of Albany. This Data is causing significat administrative issues at Albany.2) [redacted]

FUNC3142 27.3.29 Install CRAMS server on OASys test rig in Chertsey

A CRAMS server is required on the OASys secure pre-production rig in [redacted]. The server is available, but additional rack space and installation are required for this. See attached report and email for details of requirements and costs.

FUNC3148 27.3.30 UAT Team 8 x Graphics cards required

The UAT Team requires 8 x Graphics cards that allow one PC to operate a double screen. These will be placed into the Dell GX520 PC's in the UAT room (G10). These graphics cards are required to optimise the UAT team's Release 1.0C and 1.1 preparation activities.

Fraser Pope has discussed with [redacted] and these units will cost approx. £90 each for a total spend of £720. [redacted] has confirmed that this can be raised through petty cash.

FUNC3155 27.3.31 Doxford UAT Environment - NPS Connectivity from Grenadier House

EDS are preparing a UAT environment at Doxford for 1.0C UAT and 1.1 UAT.

For 1.1 UAT, a Steria-supplied solution is required to connect to this environment from Grenadier House in such a way as to simulate normal NPS connectivity.

The components of the solution should include:

- 14 WIDS (of specification(s) that represent NPS WIDS at the time of July 2008 go-live)- Citrix server(s)- OMNI or OMNI-like network- OMNI Perimeter security- Connected to EDS-supplied Interconnect or substuitute

FUNC3156 27.3.32 Agents to amend Team information (OASys CR234)

Update team in Assessor record agent. Make an agent available as an action button at the top of the Assessor view (and very probably following closely the format of the Update Roles button/agent at the top of the Assessor View.). The agent will act on selected records in the view. It will query the user to know which Team to assign to elected Assessors, and will then update the Team information in the selected Assessor records. Agent should be available only to Data Administrators.

Update Office in Assessor record agent. Exactly as per Update team in Assessor record agent, but for Office information.

Update Team in Offender Record agent. Make an agent available from the Actions / Administration menu, the action of which will be to update the Team information of selected Offenders, based on the Team information currently held against the Assessor record of the Assessor nominated as Supervising Officer of the Offender. (Where there is no Supervising Officer, the agent will not update the team information.) The agent will update Offender records only if they are owned in the Area. The agent will be available to Data Administrators only.


C-NOMIS RESTRICTED


FUNC3157 27.3.33 Expansion of Truncated field sizes in OASys

This Submission is for authorisation for EDS & SunGard to develop and implement the expansion of field sizes in the HMPS OASys application from 2000 character to a 4000 character limit. This work is to be carried out in accordance with the attached joint specification drawn up by the OASys Application Architect in conjunction with both EDS & SunGard. The Board has already approved this in principle and has previously authorised the production of the attached proposals (CCR 238) from the suppliers for the undertaking of this work.Timescale – urgent. Co-ordination required by EDS & SunGard. Potential candidate for 4.2 release, but may need to be delivered as independent release in advance of 4.2.

FUNC2663 27.4 MS Office Licences for NOMISNet Users in Testing and additional areas (

The EDS BoM included provision for MS Office licences. 45 additional machines have since been ordered and the licencing situation should be regularised

FUNC2664 27.4.1 Purchase VERITAS Backup Exec The backup of the HOPNC database that is used by the Data Quality team comes password protected. In order to be able to restore the backup we need VERITAS Backup Exec

FUNC2665 27.4.2 VERITAS Backup Exec VERITAS Backup Exec software is required on the HMPS Data Quality Server

FUNC2670 27.4.3 Move Licences to Rel 1.1 for Migration and Transitional Interfaces

Move delivery of migration and interface routines to transfer Licence Data between NOMIS and HMPS legacy from 1.0 to 1.1

FUNC2703 27.4.4 Renewal of Altova XML Spy Licences for EDS Data Migration & Interfaces Team

In July 2006, 15 one-year Altova XML Spy Professional Edition Licences were ordered. These licences expire on 18th August 2006. Hence a new set of 15 one-year licences are required.

FUNC2992 27.4.5 Additional TOAD Licences Required An audit of TOAD licences used by the Data Quality, Data Migration and Transitional Interfaces work-streams has indicated that TOAD software is being used on 23 machines. This is four greater than the current number of licences purchased from Quest Software (19 have been purchased to-date).

FUNC3067 27.4.6 CAST Software and Services One component of the approved Performance Management Architecture is Cost Criticality Analysis, which provides the detailed information required to review the cost implications of correcting poor performance in the C-NOMIS system . The CAST Software and services are required to provide this code analysis to conform to the agreed Performance Management Architecture.

CASTSoftware, the company, will provide an initial service to analyse the Oracle Forms and database code of the c_NOMIS application. Following that, EDS staff from the performance management workstream and from Syscon will have the ability to perform code analysis for a further 18months.

The output from CAST analysis toolset will also provide valuable information regarding the function points within the system, which will aid estimating.

The cost to meet this requirement is contained in the attached proposal from CAST Software.

FUNC3072 27.4.7 LoadRunner Maintenance The annual maintenance for the LoadRunner Licence is now due. The cost of the maintenance for 25000 is £64,422 + 10% EDS mark-up = £70864.20


C-NOMIS RESTRICTED


FUNC3112 27.4.8 Windows 2003 Server Licences for Doxford Test Environments

A number of Sun servers have been procured to provide Windows 2K or 2003 Server functionality to host the OASYS and EOASYS . It is necessary to purchase licences for theses servers. The servers were procured as part of CR00185 and CR00250. 16 Licences are required.

FUNC2685 27.5 Change name of Architecture Documents

. Data Centre Logical Architecture to NCDS Logical Architecture2. Data Centre Infrastructure Design to NCDS Infrastructure Design3. Service Management Architecture to IT Management Architecture

FUNC2692 27.6 Tactical Solution to implement Mirror View over Inter-site Links.

over the existing 1Gb Inter-site Link.The switches will be implemented between the existing Cisco MDS 9140 and the Cisco Catalyst 6513 and provide the mechanism to enable Mirror View to be implemented between the Clarion Storage devices located in each data centre.

FUNC2702 27.7 Remove NCDS NFS No Data Loss Requirement in Rel 1.0 from NFR179.7.4

In the design of the NCSD NFS clusters there is a requirement for no loss of data. The NFS SAN storage in Doxford should be mirrored to Washington such that in the event of a Disaster Recovery event triggering fail over to Washington no NFS San data is lost. The design did not foresee that MirrorView could not use the existing intersite link and would need its own dedicated link.

FUNC2699 27.8 Provision of NOMIS Application Support Environment

To provide an dedicated NOMIS logical environment for the provision of 2nd, 3rd and 4th line application support. Access is required from the support locations of St Helens and Sheffield and this environment should it should reflect the live environment in versions of released software.Reference data should be as per the live environment and all other data should be representative and valid to allow for the simulation, investigation and duplication of reported application incidents in the live environment.Where no current environment can support this change then a representative physical environment will be required to provide this function.Interface (or simulation to interfaces) will be required to fully support the NOMIS application.

FUNC2666 27.8.1 Move Systems from Washington to Doxford Data Centre

Washington Data Centre has experienced a serious power incident that may potentially impact the continued the delivery of certain business services to the NOMIS Project. As a result, this CR requests the move of the MIS and Data Migration systems, currently located at Washington Data Centre, to the Doxford Data Centre.Further detail of the change can be found in Technical Solution Note TSN022, a copy of which is attached.

FUNC2693 27.8.2 Meadowbank Server Room Air-Conditioning Upgrade

Provide additional cooling capability within Meadowbank Server Room for NOMIS MIS/OR equipment. Work to be carried out by McAlpine urgently.

FUNC2673 27.8.3 To amend data centre design, create build design and build the hardware procure

NOMS have procured some additional hardware (5 *T2000) required for the Data Migration solution .To implement the hardware the following documents will require change- Logical Technical ArchitectureNCDS Logical ArchitectureNCDS Logical Infrastructure High-level designData Migration ArchitectureThe following AE documents will need change or additionServer designFurther to the design creation implementation activities will be undertaken by the Infrastructure groups by the infrastructure group.


C-NOMIS RESTRICTED


FUNC2671 27.8.4 Implement a new Data Hub component to route messages

Two elements of the Interfacing solution are impacted by this change:• Creation of a new component in the Data Hub to provide a single connection point for xTAG and for routing of messages based upon their contento St Helens team resource impact • Upgrade of Oracle Application Server hosting xTAG (Interfacing) to [redacted]o Development environmento Integration Test Environmento Production Environment

FUNC2704 27.8.5 Tactical Solution for Data Hub Resilience in the NCDS (NFR179.5.5) for Rel. 1.0

The issue is that there are two T2000 servers available for Data Hub in the application layer as per the NCDS architecture. Current inbound and outbound capabilities require different levels of Oracle forcing these to be separated. For resilience we need four instances of data hub. Two inbound and two outbound.

FUNC2995 27.8.6 Renew rental on leased equipment Currently there are seven leased servers in various environments at Grenadier House and one at Meadowbank. The lease on these units expires on October 18 2006 (and was previously linked with various P&S hardware leased at the same time).

FUNC3002 27.8.7 Additional memory for Integration DB server

Additional memory is required for the Meadowbank Integration Database Servers. The two servers will be upgraded from 8gb to 16gb.

FUNC3018 27.8.8 NOMIS Technical Environments for R1.1

Additional technical environments are necessary for the continued development and Testing of C-NOMIS Release 1.1. The technical environments are described in the document titled “NOMIS Technical Environments High-Level Design’ version 0.5, which was provided under PD 7.2.3.21, and identifies the infrastructure equipment required for Release1.1 and the strategy for provisioning the environments. This document has been approved by Technical Assurance.This CR provides an outline budgetary estimate for the environments in their entirety, but offers a staged approach to the implementation and provisioning of the environments so that the environments which are considered a priority can be dealt with in a timely manner. Spreadsheet “Tech Env HLD (Kit & Costs) v05” provides a list of equipment and estimated costs for the environments in their entirety.This CR specifically requests the provision of environments that are a priority to enable the timely development of C-NOMIS Release 1.1. This CR does not include all of the environments highlighted within the document “NOMIS Technical Environments High-Level Design” version 0.5, but a subset, which includes environments for the following work streams:

FUNC3019 27.8.9 NOMIS Technical Environments for R1.1 (Part 2)

Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution, this CR provides the next priority environments as described in the document titled “NOMIS Technical Environments High-Level Design’ version 0.5, which was provided under PD 7.2.3.21, and identifies the infrastructure equipment required for Release 1.1 and the strategy for provisioning the environments. This document has been approved by Technical Assurance.CR00183 provided an outline budgetary estimate for the environments in their entirety, but offers a staged approach to the implementation and provisioning of the environments so that the environments which are considered a priority can be dealt with in a timely manner. Spreadsheet “Tech Env HLD (Kit & Costs) v06” provides a list of equipment and estimated costs for the environments in their entirety.This CR specifically requests the provision of environments that are a priority to enable the timely development of C-NOMIS Release 1.1. This CR does not include all of the environments highlighted within the document “NOMIS Technical Environments High-Level Design” version 0.5, but a subset, which includes environments for the following work streams:


C-NOMIS RESTRICTED



Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution, this CR provides the next priority environments as described in the document titled “NOMIS Technical Environments High-Level Design’ version 0.5, which was provided under PD 7.2.3.21, and identifies the infrastructure equipment required for Release 1.1 and the strategy for provisioning the environments. This document has been approved by Technical Assurance.CR00183 provided an outline budgetary estimate for the environments in their entirety, but offers a staged approach to the implementation and provisioning of the environments so that the environments which are considered a priority can be dealt with in a timely manner. Spreadsheet “Tech Env HLD (Kit & Costs) v07” provides a list of equipment and estimated costs for the environments in their entirety.This CR specifically requests the provision of environments that are a priority to enable the timely development of C-NOMIS Release 1.1. This CR does not include all of the environments highlighted within the document “NOMIS Technical Environments High-Level Design” version 0.5, but a subset, which includes environments for the following work streams:


Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution, this CR request the additional racking for Grenadier House to house the additiona1 servers requested on CR00183.


Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution.This CR provides the network connectivity (WAN) into the data centre to allow access from site locations to the Data Centre technical environments.The original estimate of £162k was based on a 10mbps service on a 10mbps bearer. Technical Assurance have suggested that the services ought to be a 20mpps service on a 100mbps bearer. The cost of the service has increased to £269k. The advantage of this solution is it will allow upgrades/downgrades in speed within the 100mbps range to be achieved within 48hours.


Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution.This CR provides the racking required by the Doxford Data Centre to house the Sun server that host the testing technical environments.This CR is Part 8 of the overall set of CR required for delivery of a full set of technical environments for Release 1.1


Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution.This CR provides the backup and recovery software required for the hardware that will be located within the Doxford Data Centre that will host the testing technical environments.This CR is Part 6 of the overall set of CR required for delivery of a full set of technical environments for Release 1.1

FUNC3028 27.8.15 NOMIS Technical Environments for R1.1 Part 7 - Hosting, Network design & imp

Following on from CR00183 which was an estimate of the costs associated with the additional environments required for Release 1.1 as described in the document titled “NOMIS Technical Environments High-Level Design’ version 0.8, which was provided under PD 7.2.3.21, and identifies the infrastructure equipment required for Release 1.1 and the strategy for provisioning the environments. This document has been approved by Technical Assurance.


C-NOMIS RESTRICTED


FUNC3030 27.8.16 NOMIS Technical Environments for R1.1 (Part 3a)

CR00185 incorrectly specified SUN Storage Hardware; specifically, 2 x 6140 Sun StorageTek SANs, within the EDS Doxford data centre.CR00185 has been amended to remove the SUN Storage H/W and this new CR covers the specific requirement of the EMC storage hardware. The change is in accordance with current C-NOMIS technical policy.The benefits of this change are the following;• EMC storage solutions are fully supported by EDS’ leveraged support groups.• EMC storage is deployed with the C-NOMIS production environment, therefore aligning the storage used within the testing environments provides a better match for NFR testing.• Configuration changes proposed for the production environment can be testing in their entirety within the Doxford testing environments.• The usage of EMC MirrorView matches that of the production environment, whereas the Sun Storage uses a different solution.• EMC storage is a comparable cost to the Sun StorageAn EMC quotation accompanies this CR for the Storage equipment required at the Doxford data centre.

FUNC3029 27.8.17 NOMIS Technical Environments for R1.1 Part 10

Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution, this CR provides the next priority orders to support the environments as described in the document titled “NOMIS Technical Environments High-Level Design’ version 0.8, which was provided under PD 7.2.3.21, and identifies the infrastructure equipment required for Release 1.1 and the strategy for provisioning the environments. This document has been approved by Technical Assurance.CR00183 provided an outline budgetary estimate for the environments in their entirety, but offers a staged approach to the implementation and provisioning of the environments so that the environments which are considered a priority can be dealt with in a timely manner. Spreadsheet “Tech Env HLD (Kit & Costs) v14” provides a list of equipment and estimated costs for the environments in their entirety.This CR specifically requests the provision of the Local Area Network infrastructure required for the environments that are a priority to enable the timely development and testing of C-NOMIS Release 1.1 scheduled to be hosted within the local C-NOMIS sites as follows;


Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS Release 1.1 solution.This CR provides the ongoing floor space and power costs for the Doxford Data Centre, as per the attached quotation.This CR is Part 11 of the overall set of CR required for delivery of a full set of technical environments for Release 1.1

FUNC3027 27.8.19 Nomis Technical Environments for R1.1

Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS release 1.1 solution.This CR is in addition to the 8 part set required for the delivery of a full set of technical environment for release 1.1

FUNC2709 27.9 HANDLING C-NOMIS BUSINESS SUPPORT REQUESTS FOR ALBANY

This change is required for the Albany Implementation.OIS Live Services require the EDS C-NOMIS Helpdesk to log Business Support incidents and requests, and pass them onto the OIS BUSG for resolution.Once the incident or request has been received by EDS the following will happen.

FUNC3032 27.9.1 Preventing Returning prisoners being received at Albany

When a prisoner returns to Albany a duplicate is created. There is no merge functionality as this is not required until 1.0cThe current workaround of deleting duplicate prisoners at Albany does not exist because no routine exists to delete prisoners. As a result it has been requested that the interfaces prevent returning offenders from being passed back to Albany and the site will update any missing transactions on the prisoner record.


C-NOMIS RESTRICTED


FUNC3090 27.9.2 Manual Duplicate Offenders Workaround

A summary of the problem is that Prisoners are discharged from a LIDS establishment to Albany. This creates an IEDT transfer which creates a TRN record in NOMIS. The Prisoner actually stops over at a LIDS site before arriving in Albany. At this stopover site, the prisoner is entered into LIDS and the following day, discharged to Albany. This creates a second IEDT transfer, which is created as a duplicate in NOMIS, with a different NOMIS ID. Although the stopover period here is considered as a single night, it could be any period from a single day to several months. In most instances this second record will only have a few details, and it is the initial record which is required to be retained. Where the “stopover” has lasted several months, it may be the second set of records which are most valid and hence required to be retained.

The scope of this change is to implement a pseudo establishment where duplicate offenders on NOMIS would be transferred. This would mean that the duplicates would disappear off Albany and be shown in a single location. It is envisaged that the establishment would identify the duplicate, but the actual transfer would be made by EDS support personnel.

This issue should not be confused with returning offenders, which will be resolved when release 1.0b is implemented. This addresses offenders that have a stopover at another establishment en route to a NOMIS

FUNC3138 27.9.3 LIDS/NOMIS Data Fix - Correct Problem with returning offenders on NOMIS

To correct a problem with returning offenders on NOMIS the records will be blocked at the interface level, this is achieved by checking whether the returning offender has a NOMIS ID. There are a number of inmates who have a Nomis id that have moved on to other establishments. The Nomis id was not sent for a number of Offenders (approx 65) with the IEDT records when the inmate was transferred (this has been corrected in release 1.ob) if these inmates return to a Nomis site they will not be caught by the fix as they have no Nomis id on their record.To ensure these inmates are covered by the new Nomis process it is necessary to have the Nomis id entered onto the appropriate LIDS record. This task can only be completed by the LIDS development team as it will entail adding the Nomis id directly on to the LIDS INMATE data file. A program will be run as part of the overnight processes which will search for the LIDS Prison number and if found add the Nomis id onto the record.There will be no impact to the sites whilst the process is running but the Nomis id will be visible on the F7 enquiry function, licences and nominal index cardThe Updates will be applied by the automated process during w/c 14th May on a site by site basis.

FUNC3147 27.9.4 Create Ghost establishment In order to overcome the duplicates created in C-NOMIS through "stopovers" Option 3.1 is proposed to create a "ghost establishment" to whiuch duplicates are transferred (since they cannot be deleted). This has already been tested and agreed

FUNC2682 27.10 Training Extend the contract of the Training developers from the current end of June 06 to end of September 06

FUNC2700 27.10.1 Replacement colour laser printer C522N Colour laser printer

FUNC2695 27.10.2 Purchase of an additional resource Resourcing required to meet reduced training material development window.Overtime on a T&M basis, for a fixed duration and budget, to develop materials

FUNC2994 27.10.3 TRAINING DEVELOPERS Extend the contract for the training developers from October 06 to February 07

FUNC3001 27.10.4 WINTELL VERSIONS OF TAG APPLICATION REQUIRED FOR C-NOMIS TRAINING

Wintell versions of the TAG application and produced for loading onto the training development environment & CHET,inclusive of reference data.Versions required are;Rel1.0,Rel 1.1,SR1,2,3&SR4&SR5

FUNC3009 27.10.5 Training for Local Support Staff Develop and deliver training for Local Support Staff. This is discussed in a paper by [redacted] (Reference 1) which is attached.


C-NOMIS RESTRICTED


FUNC3015 27.10.6 C-Nomis training database in Solaris Format, requirements for the CHET

C-Nomis training database in Solaris Format, requirements for the CHET and a Wintell format for mobile training suites

Requirements for v1.0 C-Nomis for 15th January 2007

R-MAN copy of database level 0 backup prior to personal data being enteredAny level 1's after the level 0 backup, upto the point where the personal data was added.Release notesInstall GuideAll SQL scripts and build script to executeCompiled copy of the oracle forms for the applicationApplication CD's

FUNC3034 27.10.7 Extend the contract for the training developers until 31st October 07

The current developers contract is due to expire 28th Feb 07 and we are obliged to give 1 months notice of our intention not to extend .Due to delays in the release of the 1.1 application from functional testing the developers have been unable to start NPS materials development as planned a task that will take approximatley 16 weeks to complete.The extension through to the 31st October 07 is due to having no firm date for the release of the 1.1 application from functional testing

FUNC3053 27.10.8 Sandpit System/ Set up of off-line version of C-NOMIS for Probation areas

For EDS to provide Steria with with a copy of the C-NOMIS release 1.1 application in Wintell version to support deployment of the sandpit system. [redacted] of release [redacted] in wintell version is required

FUNC3109 27.10.9 C-NOMIS Training Database Patch upgrade

To provide a R1.0c patch upgrade to the C-NOMIS Training Database’s in both a SOLARIS and WINTEL format. The details of which are listed below

1. Release Notes (including prerequisites and changes made to the environment) supplied 2 weeks before release date2. Step by step Install Guide3. All SQL scripts and build scripts to execute4. All configuration files that have changed or have been added and documentation of the changes required.5. Compiled copy of the TAG client (oracle forms, jar's and any client side files required by the TAG application) for the application on the Windows platform (WINTEL)6. Database export from a database with the release applied from a Windows platform.7. Application CD's8. Check list of all items to be delivered as part of release supplied 2 weeks before release date9. Onsite workshop day at Meadowbank, at least 5 days before scheduled release, Steria will send an Oracle DBA & Wintel engineer to oversee the build by EDS10. Telephone and email support by an EDS Oracle DBA on the day of install at Steria

FUNC2711 27.11 Upgrade xTAG In-bound service to Oracle Application Server v10.1.3

The xTAG In-bound service is currently implemented on Oracle Application Server (OAS) [redacted] and needs to be upgraded to OAS [redacted] to be consistent with the xTAG Out-bound service.xTAG In-bound is also used by the Data Migration service. Thus Data Migration will also need to roll forward to OAS [redacted] to avoid maintaining parallel instances of the same service for the Data Hub and Data Migration.

FUNC2998 27.12 Connect NOMIS Interconnect to the legacy 89 network

The solution for C-NOMIS IEDT-Out and IIS interfaces requires a connection between the NOMIS Interconnect and the legacy 89 network.


C-NOMIS RESTRICTED


FUNC2999 27.13 eOASys build effort for NPS eOASys-NOMIS Interface in 1.1

The proposal document and purchase order for the NOMIS-OASys interface workstream specifically excluded the build effort required from the eOASys project teams. It covered the activities of workstream management, analysis, and system testing by the OASys team.

In September 2007 the requirements for the eOASys interface (release 1.1) have been progressed, and as such the eOASys build and unit testing can be confirmed.

FUNC3004 27.14 Solution to implement Mirror View over Inter-site Links

This change supercedes CR00073. The original Change Description‘To implement Mirror View as architected it is necessary to provide Mirror View with its own dedicated inter-site link to enable the correct functionality to be deployed to ensure there is no loss of data on the NFS Platform.This change request calls for the provision of this link’is unchanged, however the cost has changed due to the following reason.. The 100MB link cannot support FCIP required for this inter-site link. We are required to have a 1GB link. The EDS cost is now one time implementation £45k (Original cost £15K) and ongoing monthly cost of £1K (Original cost £256). These costs are approximate and final cost is only known after implementation from 3rd party supplier.

FUNC3006 27.15 Windows Version of NOMS for Steria

EDS to provide Syscon with the following information to enable Syscon to compile a Windows version of the NOMIS application

1) Database Export2) All scripts needed to import the database export3) Instructions to run the scripts4) Release Notes describing the content of the release5) All application related libraries6) Instructions on configuring and installing the application server

FUNC3010 27.16 Additional NPS Legacy Systems The current NPS legacy systems within scope for NPS migration include all primary Case Management Systems (IAPS, ICMS, Delius, IOSS, CATO, etc) plus IAPS. In planning and mapping activites with Areas additional systems have been identified that would require additional time and effort to design, develop and test specialist extract scripts.

FUNC3011 27.17 Continued Rental of the Large Scale Performance Test Environment

Continued Rental of the Large Scale Test Environment to the 20th April 2007.

Equipment is rented from SUN and EMC.

FUNC3016 27.18 Increase in C-NOMIS client bandwidth requirements

The projected bandwidth requirements for the C-NOMIS client over OMNI drives OMNI capacity planning. Previous details for bandwidth requirements indicated 1.4 kbps outbound (client to server) and 3 kbps inbound (server to client). Existing OMNI network capacity was sufficient to accommodate these requirements. However, Steria understands the latest C-NOMIS client now requires upto 6 kbps outbound and 15 kbps inbound. This is approx. 5 times greater than earlier volumetric estimates and is likely to have significant impact on OMNI capacity

FUNC3031 27.19 EXTEND THE CNOMIS LOCKOUT TIME (

The CNOMIS user lockout interval need to be extended to be at least greater that the Quantum session lockout period. [redacted].

This is not release specific but requires a chnage to an Oracle parameter.

FUNC3044 27.20 C-NOMIS Data Scrambling technique

A method of scrambling C-NOMIS data is required for Release 1.0C testing, Release 1.1 testing and beyond. Specific requirements can be found in "Data Scrambling Requirements for Release 1.0C V0.1"


C-NOMIS RESTRICTED


FUNC3050 27.21 Project CR - Increase Scope of 1b to fix Production Issues

The Production Issue Review Board have recommended that two fixes are included in Release 1b:Defect 5881: Incorrect population details sent to IISDefect 5918: Offenders that have previously had temporary absences fail to transfer from NOMIS to LIDSIn addition the following issue has not been recommended for a release by the PIRB, but EDS believe it is critical to ensure the correct information is provided to users:Defect 5967: Hot Page shows incorrect Sentence Length

Technical Impact Assessments are provided with this CR, note that this is not yet fully completed for defect 5918 (the CR will be updated when it is).

FUNC3051 27.22 Project CR - Increase Scope of 1c to fix Production Issues

Addition of resolution of the following issues within Release 1.0c:

5887 - If an adjudication is amended and the offender has been convicted under a juvenile offence, but are now over 21, it classes it as a new adult transaction and creates a duplicate. It can possibly be fixed by passing the Adult/YP marker through to the interfaces. The current issue is seen to be low, there has been one instance to date, however the severity of this issue may increase when additional establishments are brought online.

Lifer data sent to A & O: A & O was receiving a zero sentence lengths for IPP Lifers, this meant that incorrect data was being reported. In order to workaround this the project is entering 99 year sentence lengths into NOMIS for impacted offenders in Albany. As additional establishments come online, this problem will be exacerbated. The extract process should be amended to use the lifer flag rather than rely on the sentence length.

FUNC3052 27.23 R1.0b UAT Additional Costs To build a clustered database environment for UAT. As it is a temporary environment, this will be done on repurposed hardware originally provided for R1.1. However, there are additional costs of £3850 for professional services and £4139.71 for Clustering Licenses. This CR is to approve these additional costs.

FUNC3054 27.24 Grenadier House Ground Floor Network Extension

Require a LAN design and implementation for 3 new Cisco Switches for the ground floor in Grenadier House. The cost items are:-3 * Cisco Catalyst C2960 Switches - £2,300 each9 * Gigabit Interfaces - £255 each

FUNC3055 27.25 Updating the ALT2 environment A Patch release to the ALT2 environment is required to enable further functional preview work. The last update was 28/11/06.

These patches need to be issued on a regular basis and the suggested period is at 8 week intervals unless notified to the contrary by any party.

FUNC3057 27.26 Compuware consultancy for Interaction Profiling

To bring in a team of Interaction Profilers to map interaction from the LoadRunner scripts. This is likely to be a 6 week exercise and will cost in the region of £100k + 10 % EDS mark-up = £110K


C-NOMIS RESTRICTED


FUNC3058 27.27 Changes to scope for 1.0b The following defects are not deliverable within the 1.0b time-box:5239 "The IncidentEstabCode is appearing incorrectly in the staging table"This cannot be fixed without storing extra information on NOMIS to mirror LIDS. There is very low occurrence in Albany. To store the extra information would require a CR, together with changes to both NOMIS and the interfaces, which is not within the 1.0b approach of low risk "quick win" defect fixes.5442 "'NFR 179.18.3.4 - Protective Marking - Business Objects reports"Discovered to require major alterations which are not deliverable within the 1.0b timeframe5482 "New reference data required to support Lifer Dates work around"Assessed by Julie Hincks as not required on the basis that the existing spreadsheets are working.5728 "Adhoc Reports: Save As causes 'Page Cannot be Displayed' Error"Not possible to deliver, because of an external dependency on a new version of the Business Objects toolset. There is currently no confirmed release date for this new version.


C-NOMIS RESTRICTED


FUNC3063 27.28 Release 1.0b change of scope since baseline Requirements Index

Since R1.0b Requirements Scope Index was baselined by JDWG on 18/01/07, a number of changes relating to defects have been raised by EDS. They are set out in CRs 00236, 00238, 00248, 00222 & 00223.

CR00236 concerns defect 5988 (raised by Live Services). EDS IA (20/02/07) indicates that there is no impact on R1.0b delivery date & report has been written by BICC.

CR00222 concerns vantive defect 1124132 (incorrect dates in case notes following migration). This defect was not included in the EDS defects List ver 1.3 which set out the defects for R1.0b. A CR 00222 was raised in January & EDS IA (20/02/07) indicates that this is fixed through a hotfix between R1.0b & R1.0c, including where post-migration inaccuracies are created by IEDT transfers.

CR00223 concerns vantive defect 1124132 (incorrect dates in case notes following migration). This defect was not included in the EDS defects List ver 1.3 which set out the defects for R1.0b. A CR 00223 was raised in January for a permanent fix to prevent the same defect arising in future migrations and where users enter data in C-NOMIS "after the event" . EDS IA (20/02/07) indicates that this can be fixed in R1.0c using some contingency and with no impact on the R1.0c date.

CR00238 This includes defects 5918 (which is in the baseline for fixing in R1.0b) and defects 5881 & 5967 raised by PIRB.

5881 - concerns incorrect population details sent to IIS. EDS IA (20/01/07) indicates that this will be hot-fixed in April (after R1.0b, but before R1.0c).5967 - concerns incorrect sentence length on Hot Page to be fixed in R1.0c.

CR00248 - EDS propose that 4 defects in the baseline for R1.0b are descoped from that release. Additionally, that defect 5719 is included in R1.0b. JDWG still to approve this CR.

5719 - this defect (A&O bulk extract discharge diary correction) was not required to be fixed by the Authority, but in fixing a releated required defect, it has been fixed in any case in R1.0b.5239 - Incidentestabcode incorrect in staging table. EDS propose removing from R1.0b. Authority view is that this must be included in R1.0c.

5442 - NFR 179.18.3.4 - protective marking on business Object reports - Authority content to leave the defect since it does not wish users to have the facility to change a "restricted" marking to a "confidential" or other marking.

5482 - New reference data for lifer workaround. Advised by [redacted] that existing workaround (for defect in IIS) is acceptable for R1.0c.

5728 - Save as error in Business Objects - dependency on new BOUK toolset. Workaround is currently acceptable and in fact improves report version control.

R1.0b Requirements Index ver 1.3 - section 2.9 - nb version update to "UAT Environmental Requirements Release 1.0b v1.0.xls" now "UAT Environmental Requirements release 1.0b with blue mods v0.3.xls". New documents also inserted "UAT 1.0b and 1.0c Test Environments Detail v0.2.doc" (provided to EDS).


C-NOMIS RESTRICTED


FUNC3064 27.29 Release 1.0c change of scope since baseline Requirements Index

Since R1.0c Requirements Scope Index (ver 1.3) was baselined by JDWG on 18/1/07, a number of changes relating to defects & requirements scope have been raised by EDS. Some of these relate to de-scopes in R1.0b which have consequential impacts on R1.0c and R1.1. These are set out in CRs 00245, 00223, 00238, 00239, 00248.

In addition, the baselined scope of R1.0c indicated that R1.0c was for limited deployment to HMP Camp Hill and HMPS Parkhurst. Following the decisions of the Programme Board on 15/2/07, R1.0c will be further deployed at a number of other prisons, subject to the constraints noted in the C-NOMIS R1.0c IT delivery Constraints Annex A ver 1.0 paper provided to the Programme Board.

CR00245 - EDS request that the requirements shown at subsections 2.2.8 & 2.2.3.2 of the R1.0c Requirements Index ver 1.3 are removed from scope. This CR was agreed at JDWG on 13.2.07.

CR00223 - This defect was not included in the EDS Defects List ver 1.3 which set out defects which would be fixed in R1.0b, R1.0c and R1.1. Required for R1.0c and following JDWG meetings on 16/2/07 & 20/2/07, EDS confirmed that the permanent fix to this defect available in R1.0c without impacting the agreed timescale for R1.0c.

CR00238 - 3 defects raised by the PIRB, only one of which is in the R1.0b requirements (5918). Defect 5881 (incorrect population details) will be hotfixed by EDS in April 2007 (not delivered as part of R1.0c). Defect 5967 (incorrect sentence lengths on hot page) will be fixed by EDS in R1.0c without impacting the agreed timescale for R1.0c.

CR00239 - increase scope of R1.0c to fix production issue 5887 - amendment of adjudication where offender was convicted as a YO but is now an adult & correction of lifer data sent to A&O.

CR00248 - Raised by EDS on 12/2/07. De-scopes 4 defects in the R1.0b scope and 1 defect not in R1.0b is added to R1.0b. Business ([redacted]) to formally confirm.

5239 - Incidentestabcode incorrect in staging table - proposed de-scope from R1.0b, must now be included in R1.0c.

R1.0c Requirements Index ver 1.3 - section 2.2.3 - clarification of risk predictor as follows:-

The Risk Predictor that uses the concept of an offence category. This is automatic in LIDS. Given the issues surrounding most serious offence and predominant case, a work around was devised and agreed. A spreadsheet of all the CJIT offences with their mapped catgories has been prepared for users to consult. Issues regarding this remains outstanding. (i) The mapping of the categories needs approval by the business. (ii) How to use the spreadsheet (incorporated in the application as an IWP document, loaded on the server as a look up document or printed out for manual use) is still to be determined.

R1.0c Requirements Index ver 1.3 - section 2.3.1 - Biometric Requirements Clarification.doc ver 1.1 updated to ver 1.4 (provided to EDS and updated following consultation with EDS)

R1.0c Requirements Index ver 1.3 - section 2.5 - "UAT Environment Requirements release 1.0c v1.0.xls" - updated to "UAT Environment Requirements Release 1.0c with blue mods v0.3.xls". (provided to EDS)

Also, new document inserted at 2.5 -"UAT 1.0b and 1.0c test Environments detail v0.2.doc (provided to EDS)

R1.0c Requirements Index ver 1.3 - section 2.6 - sub para 4 starting "For Req 2.6.2 - insert "nb these reports will require system test and UAT".

INFORMATION NOTE: The Section Below Will NOT Be Formally Impacted By EDS

R1.0c Requirements Index ver 1.3 - section 2.4.1 - the reports listed for R1.0c pertain to HMP camp Hill and Parkhurst. It is possible that as


C-NOMIS RESTRICTED


FUNC3075 27.30 Production Issues to be fixed in R1.0c

Description of Change Addition of resolution of the below defects within Release 1.0c. Note that the defects have come from multiple sources.

Incidental fix not done – defect deferred to 1.1HMPS Deferral – Deferred by HMPS to R1.0cPIRB – Required to resolve an issue being tracked through the PIRBInternal – Detected during development of 1.0c but present in production from 1.0a.

Defect Summary Source5772 EPG Bulk Extract - cosmetic issue Incidental fix6060 OASys - Offender Sentence Release Date not following order of precedence specified HMPS Deferral6107 Bulk Extracts - AOP extract is not working HMPS Deferral6133 Bulk Extracts - SiS is failing due to JDBC error reported HMPS Deferral6190 NOMIS Application issue: screen OUMASSMU does not display all Module_Privileges assigned to a user group for certain Roles. HMPS Deferral6191 OASYS Inter establishment movement Reception does not trigger details message HMPS Deferral6220 A & O Prisoner extract problem with Home Address Internal6230 Reports - MIS - Pre-UAT - Reception / Discharge List - 'Reception' Tab displaying all discharged prisoners. HMPS Deferral6238 P7’s are incorrectly being generated for changes of made to a) “non-IIS-significant” data and b) “IIS-significant” data which is being updated to the same PIRB6239 Changing an address when an Offender Contact is inactive but the address is active, will generate a P7 address PIRB6240 Changing an inactive address fires a P7 transaction where delete_flag = ‘Y' PIRB6241 If an Offender Contact with an inactive address is made inactive, a P7 is generated with a delete_flag = ‘Y’ PIRB6242 Changing the active address for an active contact generates a P7 for each of the Offenders including a P7 for a Offender where the contact is inactive for them PIRB6246 No truncation of Reception and Labour remarks in A&O Prisoner Bulk Extract Internal6243 No natcodes for Northern Irish and Scottish Courts Internal6030 Albany data missing from F1032 PIRB6050 Usability issue in C-NOMIS inflates F1032 Authorised Absences figure PIRB6261 Offender Supervisor contact not handled by IEDT Inbound DRB (awaiting deferral)


C-NOMIS RESTRICTED


FUNC3076 27.31 Increase scope of R1.0d to fix production issues

Description of Change Addition of resolution of the below defects within Release 1.0d. Note that the defects have come from multiple sources.

HMPS Deferral – Deferred by HMPS to R1.0dPIRB – Required to resolve an issue being tracked through the PIRBInternal – Detected during development of but present in production from 1.0a.

Defect Summary Source5911 Recurring Activity Schedules not being built. Internal6067 Schedule Enquiry - OIISCHED should not exclude schedules for offenders that are active in an agency caseload - but 'out' due to temp absence (for example) Internal6167 MB - User (RBACS4) has been assigned Role 900 and should only have Query access to the screen OMUVREST. However, user has Amend access. HMPS Deferral5937 Prison Roll Screen not showing correct details if offenders are in an internal location when it is deactivated PIRB6024 Error while creating a new ROLE PIRB5893 C-NOMIS cannot close Self Harm transactions on IIS PIRB6259 Inactive addresses are being sent to LIDS DRB (Awaits Deferral)

FUNC3078 27.32 Cancellation of CITO project and request for a Proposal to implement C-NOMIS

Request for a proposal for the replacement of the C-NOMIS Implementation on Transitional OMNI (CITO) project, with C-NOMIS Implementation on OMNI.

FUNC3079 27.33 Include TD 5943 in R1.0c Empty Movements transaction file generated during IEDT In transferAn Offender with 465 Movements was processed in IEDT In. An empty Movements transaction file was generated, which subsequently failed validation in xTAG.On further investigation, there is a limit imposed on the number of Movements that can be processed in the Data Integrator XML generation routines. This limit was imposed in the interests of performance for the Albany Data migration in order to ensure the Data Migration fits into the pre-defined window.This constraint needs to be revisited.

Note that this CR is retrospective. The defect has been included in r1.0c data Migration and IEDT-Inbound coding but was overlooked in the associated requirements documentation. The purpose of this CR is to formally document the r1.0c scope change. Dave Watson.


C-NOMIS RESTRICTED


FUNC3082 27.34 Increase Scope of 1c to fix Production Issues – Part 4

Addition of resolution of the following issues within Release 1.0c. All these issues have detected during development of Release 1.0c.These are all minor technical interface issues that do not have a user impact and have not been reported in production, however may now require technical support activities behind the scenes. These have all been reviewed by the 3rd Line Interfaces Support Team for this purpose.

6033 Incorrect Mapping for Natcode STAT table (SENT03 mapped to SENTCJ03)6295 Incorrect Mapping for Natcode STAT table (SENT03 mapped to SENTCJ03)5917 IIS: LD_NEWTX file not being archived6213 'Random' F2052 start dates being output on A&O Prisoner bulk extract6264 A&O Prisoner extract takes a 4 Estab comp code into a 2 char field in the output schema6266 Incorrect numeric1 (rank) on SEC90 status in NDH codetable6317 State Change Error Validation5780 IIS_A3_ARC table should have DURATION_PUN field as size NUMERIC(3)6318 M1 Transform Error6319 P7 Transform Error6320 The A2 Audit not updating correctly6350 Legacy offence codes missing from mappings

FUNC3089 27.35 NOMIS 1.0B 31/03-01/04 (QUANTUM CR - CR007124) FOR INFORMATION

Implementation of Nomis 1.0bThis CR covers the implementation of number of NOMIS 1.0b.

This release incorparates some 80+ defect fixes and requires changes or updates to be made to several of the core NCDS components.

The patches have been tested in the Meadowbank environment, and the implementation process HAVE been tested in the Pre Prod env by the Live Services Team. After the PRE Prod implementation the specific timeline and installation actvities will be provided.

FUNC3092 27.36 Fix / Additional Functionality required as part of Release 1.0c

A change is required to existing implementation of C-NOMIS for creation of occurrences on the Occurrence detail screen (OIDINCDE). The change is to restrict the search capability on the Occurrence detail screen (OIDINCDE) for standard users, so that:o Standard users - these users must have local search capability on Offenders on the Occurrence detail screen (OIDINCDE)o Enhanced users or specifically selected users - these users must have global search capability on Offenders on the Occurrence detail screen (OIDINCDE)

FUNC3100 27.37 Addendum to baseline requirements Index for R1.1

The scope of R1.1 was baselined by JDWG on 18/01/07. Since that time a number of changes have been requested and approved (with some outstanding JDWG approval). A detailed document entitled "C-NOMIS Addendum to Requirements Index for Release 1.1" version 1.3 (04/04/07) has been produced setting out the changes.

Apart from a number of CRs, there are other minor changes to some technical design documents produced by EDS/Syscon which have been approved by the project, and to transition to live services and services. The changes are set out in the document.

FUNC3123 27.38 Additional Defects to be fixed in Release 1.0d/ 1.1 (linked to CR00301/ R1.0c)

Provide resolution for the following defects in Release 1.0d./ R1.1:6278 – MIS Database update failure6303 – UAT – sit1b – Password screen (OUMAPASS) showing a truncation error6328 – OCDHEALT – Services Needed frame. Disparity between the column heading name

(PLEASE NOTE: This CR has been raised to request a formal impact from EDS against both R 1.0d and R1.1, CR00301 covers the IA against 1.0c which was rejected by EDS as not feasible)


C-NOMIS RESTRICTED


FUNC3137 27.39 Re-baseline Steria IT Delivery plan (v3.56)

Steria is submitting a revised plan/schedule for authority review and agreement to re-baseline

FUNC3144 27.40 Amendment to “Release 1c Quality Gate Deliverables v1 0”

Amend the agreed quality gate deliverables.

1. Move the following deliverables from gate 3 to gate 6:a. Accreditation Document Setb. Security Operating Procedures2. Remove Business Objects deliverables:a. “SSO Design” from gate 3b. “NOMIS 1.0c Report and Universe Unit Test Plan” from gate 4c. “NOMIS 1.0c Report and Universe Unit Test Exit Report” from gate 4d. Audit Unit Test Plane. Audit Unit Test Exit Reportf. Audit Link Test Plang. Audit Link Test Exit Report

FUNC3151 27.41 URGENT HOTFIX - Implement Defect #6499 in C-NOMIS (prior to R 1.0c)

#6499 on test director - Prison Activity you can schedule a inmate to have the same start and end date but you are unable to pull this information off - Select service pop up will not show the activity and this pop up is accessed from the bulk attendence screen OIDPATTE.

Code Change Required (details tbc by EDS)

FUNC3152 27.42 Additional Defects to be fixed in Release 1.0c

Provide resolution for the following defects in Release 1.0c:6278 – MIS Database update failure6303 – UAT – sit1b – Password screen (OUMAPASS) showing a truncation error6328 – OCDHEALT – Services Needed frame. Disparity between the column heading name

FUNC2710 27.43 Steria Proposal changes for OMNI This change provides the NOMIS team with a proposal and revised costed plan that describes Steria’s products and services to deliver its obligations to NOMIS within the OMNI contract and infrastructure.The change includes proposals for:a) A new product ID and Product Description (PD) for the NOMIS Build and Implementation phase - 6.3.3 Costed Build & Implementation Plan (OMNI)b) A revised proposal and implementation plan that takes into account Steria’s products and services to NOMIS following award of the OMNI contract.

FUNC3033 27.44 Sunguard e-OASys interface additional costs

This CR covers the additional costs incurred by Sunguard due to delays in the programme.Sungard have been contracted to provide the development of the interworking between C-NOMIS and the probation e-OASys professional service. They also provide support to the e-OASys system.

FUNC2696 27.45 Solution to implement Mirror View over Inter-site Links

To implement Mirror View as architected it is necessary to provide Mirror View with its own dedicated inter-site link to enable the correct functionality to be deployed to ensure there is no loss of data on the NFS Platform.

FUNC3158 28 CR's To Be Processed


C-NOMIS RESTRICTED


FUNC3159 28.1 Telephony Hardware required for application support

The purchase of additional telephony hardware to allow Application Support Groups to operate effectively.Qty Description4 Misco BT Converse 1200 4 Misco PLANTRONICS VISTA ADAPTER ONLY 4 Misco PLANTRONICS SUPRAPLUS H251 MONAURAL HEADSET1 Misco BT PARAGON 500 PLUS (answer m/c including phone) 8 Misco BELKIN SOHO 4 PORT PS/2 & USB KVM SWITCH 16 Misco BELKIN USB SOHO KVM CABLE KIT (WITH AUDIO) 1.8M16 Misco BELKIN PS/2 SOHO KVM CABLE KIT (WITH AUDIO) 1.8M 10 Misco Belkin USB to 2 x PS2 Device Adapter

Total cost: £1,367.37 plus 10% mark up = £1,504.11

FUNC3179 28.2 R1.0b UAT Additional Costs To build a clustered database environment for UAT. As it is a temporary environment, this will be done on repurposed hardware originally provided for R1.1. However, there are additional costs of £3850 for professional services and £4139.71 for Clustering Licenses. This CR is to approve these additional costs.

FUNC3182 28.3 Change title of PD for Biometrics Whilst we do not believe that this is a CR, nevertheless, the biometrics report should show the following options to enable the Authority to take a view on feasibility and affordability.

In order for the correct options to be deployed within C-NOMIS in the correct manner it is imperative that a fully detailed and costed options report be created. It should state the costings within any report and contain the following options as a minimum:1. Integration of single fingerprint readers (ANSI /NIST compliant for IDENT 1 and IND compatibility) for offender registration and addition of readers to the Quantum catalogue.2. Integration of ten print readers (ANSI /NIST compliant for IDENT 1 and IND compatibility) for visitor registration.3. Enhancement of the central system and infrastructure to support the stated offender volumetrics (ANSI /NIST compliant for IDENT 1 and IND compatibility)4. Enhancement of the central system and infrastructure to support the stated visitor volumetrics (ANSI /NIST compliant for IDENT 1 and IND compatibility)5. Transfer mechanism for Offender biometric information to be transferred to the Police to the correct standard (currently non interface for 1.1 but required as an interface at a later stage nominally 1.2)6. Live capture of Images of Offenders and/or Visitors to the approved standard.7. [redacted]8. Support for mobile devices to operate as visitor and offender validation units.9. An AFIS capability to the agreed requirements but with costings for different response times (for example only, 1 minute, 2 minute, 5 minute, 10 minute.)10. The complete package.

Option 9 needs to be a stand alone deliverable that can be added to the above configurations.


C-NOMIS RESTRICTED


FUNC3183 28.4 Expansion of Truncated field sizes in OASys (OASys CR 255)

This Submission is for authorisation for EDS & SunGard to develop and implement the expansion of field sizes in the HMPS OASys application from 2000 character to a 4000 character limit. This work is to be carried out in accordance with the attached joint specification drawn up by the OASys Application Architect in conjunction with both EDS & SunGard. The Board has already approved this in principle and has previously authorised the production of the attached proposals (CCR 238) from the suppliers for the undertaking of this work.Timescale – urgent. Co-ordination required by EDS & SunGard. Potential candidate for 4.2 release, but may need to be delivered as independent release in advance of 4.2.

FUNC3185 28.5 EDS Man time to commission additional Test Environments (CR00250

CR00250 did not include any EDS man time to commission these additional servers and as these servers are additional to the original Rel 1.1 Test environments procured as part of CR00185 no man-time was included in the Rel 1.1 Cost model.

FUNC3186 28.6 Align C-NOMIS Service Window for probation users to standard OMN

NFR 179.6.4.1 state that: "Except for periods of planned maintenance, the OMNI IS shall be available to NOMIS users 99.8% of the time during the 'Service Window' of 0600 to 2400 Monday to Saturday and 0900 to 2400 Sundays and Public Holidays measured over one calendar month. The OMNI IS shall be available to NOMIS users for not less than 75% of this availability outside of the 'Service Window'."

This CR is to align the Service Window to standard OMNI Support Hours of 08:00 to 18:00 Mondays to Fridays excluding public holidays.

FUNC3187 28.7 Duplicate Offenders Tracking Report (follow up CR from CR10/ lin

The report will list the those offenders that have been identified as potential merges by the 'Duplicate Offenders Report' and whose details have been passed to the relevant Prison/Probation Area. The records will be stored in a separate table in the MIS database or will be flagged as pending. The report is for tracking purposes and will be used by Live services to ensure that any potential merges have taken place within the agreed time frame. The report should include the following data items:Date of record flagged as pendingNOMS NumberSurnameForename 1Forename 2Date of BirthPNC NumberLocation (Prison Name)Offender Manager (Name)Office (Name)Area (name)The report will be sorted by:1. Date of record flagged as pending2. Area/Prison3. Office4. Offender Manager/Personal OfficerWhen a decison is made to merge/not merge the records the status of the record will change and the record will no longer appear on the report.


C-NOMIS RESTRICTED


FUNC3188 28.8 Standard of accommodation of discharge address fields required i

Raised on behalf of Philip Richardson

Currently when entering home address details into CNOMIS, an address type is selected from the following:

HomeApproved PremisesCurfew OrderDischargeReceptionHDC AddressRelease on Temporary LicenseResidency ConditionCare or Old Persons HomeHospitalOther

Currently LIDS and OASys have functionality that allows the entry of the standard of accommodation against the address given for discharge. The standards that are in use are as follows:

SettledUnsettledTemporaryNFA

FUNC3189 28.9 Change to Steria Product Breakdown Structure (PBS) for Data Migr

Agreement to, and implementation of, a redesigned product breakdown structure for the NPS data migration tool set development.

FUNC3190 28.10 Link Cases - clarification for work streams other than ALT

Link Cases was not a specific requirement in the catalogue but a supplementary design to the Sentences work package. Agreement has now been reached on how this functionality is to be achieved in Release 1.1 and this CR is to provide information and clarification to other work streams.

FUNC3191 28.11 Copying Alerts through all inactive bookings

In regard to Alerts, merge and migration rules have shown up one scenario where a merge change needs to be made (additon to the manual merge design). Current Tag functionality for creating a new booking takes all alerts (active or inactive) from the most recent booking and inserrts them into the new booking.

The change required is when merging more than 1 booking, that any alerts (active or inactive) must be merged/migrated into all later bookings. This will ensure that the most recent contains all alerts if/when a new bookign is created.

FUNC3192 28.12 eOASys support release 4.2.1e eOASys support release 4.2.1e is scheduled for the end of August 2007. This contains changes to the Access reporting system only, and will not impact C-NOMIS.

Details are contained in the attached change request, ref NPD099.


C-NOMIS RESTRICTED


FUNC3193 28.13 Change Ownershop of "Audit report of failed facial images" from

To change the delivery owner of the failed facial images report as documented in requirement A5.11 from Syscon delivery to Buisness Objects.

FUNC3194 28.14 Request for EDS/ Delivery of PB 063N End of Custody Licence RFC

Request from [redacted] to urgently commission EDS to deliver the requirements for changes detailed in section 1.1 and 1.5 of the attached requirements document for PB 063N End of Custody Licence. To aid EDS with this the Authority have prioritised the requirements:

• Priority 1 1.4 Completion of the new recall code work already commenced• Priority 2 1.9 Weekly temporary absence extracts to RDS• Priority 3 1.7 Menu driven report of those currently out on ECL to allow close down of ECL cases at ARD/CRD• Priority 4 1.8 Addition of the 2 temporary release licences (attached)• Priority 5 1.6 Menu driven report to identify those eligible for release on ECL• Priority 6 1.2 & 1.3 – It is understood that EDS have already implemented these requirements.

EDS are requested to urgently deliver the above requirements and provide an invoice upon completion.

Please contact [redacted] if you require any further information on this matter.

(PLEASE SEE ATTACHMENTS BELOW FOR MORE DETAILS)

FUNC3195 28.15 Q - Solaris Patch on all server in C-NOMIS environment & various

RC reference CR07906 - raised on behalf of [redacted]

The database backups must be rescheduled to start at 18:00, so that they are completed before the databases are shutdown.

At 19:00 The databases will be taken down in the following order. [redacted]

The application of the solaris patches and firmware will then be made. (order to be confirmed)

Post BST Changes, start the databases in the following order:[redacted]

Restart Hot Page, Xtag and CMS

Manually run first part of MIS batch - [redacted]Manually run second part of MIS batch - [redacted]

Manually run 5 cnomis batch processes

Enable 5 cnomis batch jobs in Enterprise Manager automatic schedule.


C-NOMIS RESTRICTED


FUNC3196 28.16 Q - End of BST/ Database backups must be rescheduled to start a

RC reference CR008004 - raised on behalf of [redacted]


Check that the 3 CNOMIS batch jobs that run before midnight have completed.

Disable 5 CNOMIS batch jobs that run after midnight from automatic schedule.

Disable [redacted] jobs using Business Object CMC.

The databases will be taken down in the following order. [redacted]


Restart Hot Page, Xtag and CMS




FUNC3197 28.17 Request for amended NPS Sandpit Solution

Please note: This request is raised on behalf of [redacted]. There is a revised Business requirement to deploy the sandpit on stand alone laptops instead of via the mobile training suites. [Reference CR00241]


C-NOMIS RESTRICTED


FUNC3198 28.18 Make Effective Sentence End Date mandatory in C-NOMIS

NOTE: This is a sister CR of 369 (Make Adult / Young Offender Flag mandatory in C-NOMIS ) and 370 (Make Main Inmate Status mandatory in C-NOMIS)

NOTE: This is NOT a "Defect Only" CR - Defect 6972 is relevant but does not wholly cover this issue.

NOTE: Teamtrack forces population of Scheduled Implementation Start and End Dates - these have been populated with defalt values

The following is an extract from the UAT-raised Training Issue 5:

"Training Issue 5, Defect 6972

The issue:

The F1032 is a summary population report, which breaks population down by Adult or Young Person, Sentence Length and Category of Offender.

The F1032 extract does not report on offenders where either the Adult / Young Offender not populated (Yes or No) OR where the Main Inmate Status is not populated OR Non-completion of Effective Sentence End Date for sentenced prisoners, excluding lifers.

The F1032 extract is used by the RDS Team to report on Estate population figures and it is therefore critical that the F1032 information is accurate. If the information was inaccurate this would lead to misreporting throughout the Prison Estate.

For a C-NOMIS Establishment, offenders who have been migrated from LIDS always have the Adult / Young Offender Flag data AND always have the Main Inmate Status entered. However, when entering a new offender into Reception in C-NOMIS, these fields are not mandatory and the system does NOT force the user to enter the Adult / Young Offender information (Yes or No) and does NOT force the user to populate the Main Inmate Status. ALSO, if an offender is sentenced the system does NOT force the user to enter an Effective Sentence End Date (this information is currently migrated from LIDS).

If reception (or equivalent) staff do not enter the Adult / Young Offender data AND populate the Main Inmate Status each time a NEW C-NOMIS reception event occurs (i.e New offender created), the F1032 extract will be incorrect and the result will be misreporting. Again, if an offender has a sentence the relevant member of staff must ensure that the Effective Sentence End Date is entered.

Training Implication:

Training should ensure that the C-NOMIS user realises that when creating a new offender record in Reception the Adult / Young Offender data must always be entered (Yes or No) and the Main Inmate Status must always be populated. If an offender has a sentence the relevant member of staff must ensure that the Effective Sentence End Date is entered."

FUNC3199 28.19 Spider / Conference Phones to be installed in ALL Grenadier Meet

The C-NOMIS Project has a constant requirement to conduct meetings in all Grenadier meeting rooms. Permanent spider phones should be set up in all meeting rooms - the cost is neglible and the benefit is substantial. The number of meeting rooms in the building is 8 (please confirm this figure). Therefore 8 permanent spider phones should be purchased and the exisiting 2 left for flexibility.



C-NOMIS RESTRICTED


FUNC3201 28.21 Q - Deployment of Nomis 1.0c into to Doxford NCDS

Deployment of Nomis 1.0c into to Doxford NCDS followed by Fire Break and Upgrade of DR SIte on 26th July.

Upgrade from C-Nomis 1.0b to 1.0c will require an outage of C-Nomis Services and Interfaces from 22:00 on the 24th to 06:00 on the 25th July. A fire break of appox 24 Hours to allow for full business acceptance of the release, after which the DR Site will be upgraded. During the interval between teh two deployments the DR environment will be in a "Frozen" state.

It is anticipated that this will occur from 10:00 AM on Thurs 26th July. It should also be stressed that all timings are approximate. A more accurate assesment will be available on completion of Implementation testing in Pre prod - to be complete on the 21st July.

FUNC3202 28.22 Q - Database backups to be rescheduled to start at 19:00


Disable all cnomis batch processes and run pre-midnight batch jobs

Bring down the front end apps

Shutdown TIBCOShutdown databases

The databases will be taken down in the following order. [redacted]

The application of the solaris patches and firmware will then be made. (order detailed on Time Line)


Start TIBCORestart Hot Page, Xtag and CMS





C-NOMIS RESTRICTED


FUNC3203 28.23 C-NOMIS Duplicate Offender Exception Table (link to CR00010, 375

Where a pair of records is determined by Live Services not to be a duplicate, a mechanism will be provided to mark the candidate pair of records as “not a duplicate”, and thereby exclude the rejected pair of records from any subsequent runs of the Duplicate Offender Report.

It is proposed that this rejection/exclusion mechanism is provided by means of an additional table created in the MIS database. The table will hold the NOMS ids of the two offenders who have proved not to be a match together with any other data items considered useful by Live Services, such as date of rejection, rejected by etc. This exceptions table will persist.

The exceptions table will be checked each time the Duplicate Offenders Report is run and, if a candidate pair of offender records exists in the table, that pair of records will be excluded from the report output.

A web page front end will be provided to enable users to insert pairs of records into the exceptions table.

A further extension of the proposal would be to introduce a mechanism whereby records can also be marked as “Pending Investigation”. For example, candidate pairs of records could be written to a Pendings table when they first appear on the Duplicate Offenders Report. These pairs could then be excluded from all subsequent report runs. This would ensure that only newly identified duplicates would appear on the report thus making it more manageable. The pending records could then be purged from the Pendings table when the duplicate issue has been resolved or once the pair of offenders have been rejected as “not a duplicate”.

FUNC3204 28.24 Q - Change weekend to implement Camphill & Parkhurst sites on 1.

Cross reference to CR00393

This is the currently planned change weekend to implement Camphill and Parkhurst sites on Rel 1.0 C of the C-NOMIS application. Various other CRs have been submitted to cover explicit actions (such as placing LIDS into Read only mode).This is a placeholder to identify this weekend as the planned migration. The decision to accept this application into production is subject to the Governance process described in the Justification Cell below and this process covers off the requirements of Operational supportability and acceptance, client business acceptance and project signoff that the application is good to go on this weekend.

These sites are to be migrated from LIDS to C-NOMIS. A pre-requisite is that the EDS Live Services change to deploy C-NOMIS Release 1.0C has been implemented succesfully.

FUNC3205 28.25 Changes to IAPS data mappings The external supplier of IAPS (i2n) to change IAPS data mapping document to clearly define the mappings for Accredited Programme Attendance and Phase Completion data in light of business requirement changes to the migration of IAPS phases to C-NOMIS phases.

FUNC3206 28.26 Q Break Fix restore of C-Nomis OR to 24th July/application of 1.

Emergency break Fix restore of C-Nomis OR to 24th July followed by application of 1.0c OR Components.


C-NOMIS RESTRICTED


FUNC3207 28.27 Q Break Fix restore of C-Nomis OR to 24th July/application of 1.

Emergency Quantum change.

Break Fix restore of C-Nomis OR to 24th July followed by application of 1.0c OR Components.

Operational Reporting is a Business Objects Component of C-Nomis. It has been determind that the Business objects Components in Live C-Nomis are corrupt and require to be re installed. It is proposed to regress, reinstall the OR components in Live from the Dec 06 Release and applying all subsequent changes This established process is used on a regular Basis to build test and dev environments.

This is a discrete component and this work can be conducted with no impact on the main C-Nomis App, or Indeed on MIS or any scheduled Process.

FUNC3208 28.28 Amend C-NOMIS scrambling parameter files and routines

As part of v1.0b, Steria developed C-NOMIS scrambling routines and an associated parameter file to scrambled offender data relating to a C-NOMIS database with v1.0b schema.

Following the impending implementation of v1.0c, an upgraded scrambling technique is required to prove the upgrade from v1.0c database to a v1.1 database.

In addition to this change, other changes have been requested following the use of the v1.0b scrambling routines. These include:•Use NOMIS to generate NOMIS IDs•Create a new scrambling technique to ensure unique swap values•Implement some performance enhancements as recommended by Live Services

FUNC3209 28.29 Q - Re run [redacted] Re run [redacted]. Modifying the day run parameter to allow it to run mid week.

As detailed in Vantive 1261994, a Scheduled payments batch run failed after processing approx 1000 or 1800 Offender records. To remedy this, the incorrect payment records have been suspended and the batch run needs to be re run to process the remaining 800 records. The process has been teste and proven in pre prod.

FUNC3210 28.30 Q - Amend Oracle database parameter [redacted]. Syn

Emergency Quantum Change.Amend the Oracle database parameter [redacted]. Syntax: [redacted].

[redacted].


C-NOMIS RESTRICTED


FUNC3211 28.31 Q - New licence provided as part of changes to LIDS

Raised on behalf of [redacted]

As part of the changes to LIDS to support the new ECL release scheme HMPS have requested a new licence be provided. This is a document that is printed from LIDS when an inmate is discharged.

The NOMIS project were been informed of the change in early June.

This is the third release we have issued for ECL,

1. Issued at the end of June2. Issued end of July3. Next change for the end of August.

This has been delivered this way to accommodate the policy groups in HMPS, they were still finalising the policy whilst we were developing. The first release issued the bare minimum that the estabs needed to release the inmates. Release 2 was to issue reports and release 3 is a licence.

HMPS have only finalised the details on the licence last week.

I can confirm that all the LIDS changes have been deployed successfully, (NOMIS delivery TBC), all my change request are independent of the NOMIS changes.

HMPS are currently requesting further changes for this ECL policy which will require further change request to be raised.

FUNC3212 28.32 Q - Amend all quantum user accounts

Amend all quantum user accounts [redacted]

[redacted]

FUNC3213 28.33 Allow search by NOMS number on the Establishment Search screen O

Bring functionality that allows search by NOMS number on the Establishment Search screen OIINAMES, from current release 1.1 code into release 1.0d (related to defect 5989).

Defect 5989 describes the inability to search for an offender by NOMS number on the Establishment Search screen (OIINAMES). This functionality is available in version SR7 (originally release 1.1 code base, assumed to now be 1.0e), and is required to be brought forward and included in functionality for release 1.0d or equivalent.

FUNC3214 28.34 Revised scope for R1.0e Following the decisions of the NOMS Board in August, an HMPS-only release of C-NOMIS was required. This is effectively R1.1, SR8 with the NPS functionality either masked or removed. It also includes CRs assigned to SR9 and other CRs required by HMPS BCST.

A revised Requirements Index for R1.0e, (ver 0.4) was provided to suppliers during August against which planning is proceeding.

FUNC3215 28.35 Property Box Number MIS Change the Prisoner demographics universe in the MIS database to include the data item ‘Property Box Number’


C-NOMIS RESTRICTED


FUNC3216 28.36 Q - All services on [redacted] to be rebooted


All the services on [redacted] need to be rebooted. This will be done as user oracle by running command [redacted], followed by [redacted]. This will take up to 30 mins to complete. Users who are logged onto this server will have their session terminated, and logging in again will take them to the other server. Users on the other server will be unaffected.

The Report Server on one of the application servers ([redacted]) has failed. This is having the effect of preventing users of C-NOMIS from being able to produce reports (this does not affect MIS and OR reports) when they connect to the application through this server. Users who are connecting through the other server are unconnected. It is totally arbitrary as to which server the user connects through.

FUNC3218 28.37 Q - Apply SQL script to create additional Prison activities with

Apply SQL script to create additional Prison activities with Reference data.

FUNC3219 28.38 Q - Implementation of LSR 7 Implementation of LSR 7-When nomis went live at Albany, the site had not completed all of their risk predictions etc. Whilst nomis 1.0 does have the capability to display risk predictor assesment results, and these were migrated on go live where available, it does not have the capability to actually "do" the predictions. Therefore this exercise is to load the balance of the risk prediction results into nomis that were not available at the time of the original migration.

Conduct Risk predictions manually (complete)Enter these onto a data load template (complete)Perform backup of environment.Run SQL to merge the data load template with the NOMIS dataValidate Process

FUNC3221 28.39 Change Format of the 'Print Activities Report'

The format of the Location tab in the Print Activities Report should be sectioned by wing and a page break by wing also inserted.

FUNC3222 28.40 Q - First Annual DR Test of C-Nomis First Annual DR Test of C-Nomis - Forced Fail Over from Primary Facilities at Doxford to Secondry Site at Washington, Followed by Failback to Doxford.

See TimeLine Tab for Full Details - Key Activities below1) C-Nomis Services to be Stopped at Primary Site/GSS Recofig'd2) OASys PULL from Nomis Disabled with OASys (Separate CR) (IOW Cluster Only)3) Secondary SIte (Washington) Promoted to Live4) Interfaces Reconfigured to Point to Dummy End Points - To Protect Live Legacy Systems5) Service Tested by Client6) Interfaces Tested by Client and EDS Personnel7) Signoff8) Nomis Services at Secondary SIte Stopped9) Nomis Services at Primary Site Started10) OASys Pull Capability Re Enabled for IOW Cluster11) Primary Site Accepted12) Secondary Site Synched with Primary site


C-NOMIS RESTRICTED


FUNC3223 28.41 Activity and appointments LIst The report will return a list of offenders and all the activities and appointments they have for the day. The report will be broken by wing and sectioned into A/M & P/M and within the section be ordered by Offender Surname. The report will return the following data items.NOMS NumberOffender SurnameOffender InitialsACCT StatusCell LocationAppointment/Activity detailsAppointment/Activity locationAppointment/Activity start time

FUNC3224 28.42 Updating of C-NOMIS Training Database Environments R1.0D

To enable Steria/EDS to provide a R1.0D update in both a Solaris and WINTEL format. This will then need to be applied to the C-NOMIS Training Database on the CHET and the following mobile training suites. Camp Hill, Parkhurst, Albany House, Grenadier House, and Newbold Revel.

Although the CHET update will be required to be in place by the 25/11/07. Having discussed the WINTEL version with John Shepherd I do understand that Syscon will not be able to provide a resource to facilitate this update until Jan 08, however approval will allow planning to take to allow as soonest


C-NOMIS RESTRICTED


FUNC3225 28.43 Case Note Report The purpose of the report is to list all the case note entries between two user specified dates in chronological order of a specified offender. The report is used for during an assessment of an offender for typically a review of the IEP (Inmate Earnings and Privilege Scheme) or ROTL (Release On temporary Licence) etc.The report should contain the following data items:1. NOMS Number2. Surname3. Given Name 14. Given Name 25. DOB6. Age7. Cell Location8. IEP Level9. Security Category10. Main Status11. Effective Sentence12. Personal Officer13. Date & Time of Case Note entry14. Establishment where entry was made15. Contact type16. Contact Sub Type17. Case note text18. Creation Date & Time19. Name of staff member who made the case note entry20. Date & Time of amendment to Case Note21. Name of user who made the amendment22. Amendment text

FUNC3226 28.44 Expansion of the Demographics universe

The addition of more objects to the MIS Demographics universe, to enhance the ad-hoc reporting capability for end users

FUNC3227 28.45 Expansion of the MIS Finance universe

The addition of more objects to the MIS Finance universe, to enhance the ad-hoc reporting capability for end users

FUNC3228 28.46 Expansion of the MIS Incidents universe

The addition of more objects to the MIS Incidents universe, to enhance the ad-hoc reporting capability for end users

FUNC3229 28.47 Expansion of the MIS Sentence universe

The addition of more objects to the MIS Sentence universe, to enhance the ad-hoc reporting capability for end users

FUNC3230 28.48 Expansion of the MIS Visits universe The addition of more objects to the MIS Visits universe, to enhance the ad-hoc reporting capability for end users

FUNC3231 28.49 Creation of an MIS Adjudications universe

The creation of an MIS Adjudications universe, to enhance the ad-hoc reporting capability for end users


C-NOMIS RESTRICTED


FUNC3232 28.50 Creation of an MIS Activities universe

The creation of an MIS Activities universe, to enhance the ad-hoc reporting capability for end users

FUNC3233 28.51 Q - Deploy C-Nomis 1.0d to Doxford NCDS followed by Fire Break a

Deployment of C-Nomis 1.0d into to Doxford NCDS followed by Fire Break and Upgrade of DR SIte on 3rd Dec.

Upgrade from C-Nomis 1.0c to 1.0d will require an outage of C-Nomis Services and Interfaces from 22:00 on the 1st Dec to 06:00 on the 2nd Dec A fire break of appox 24 Hours to allow for full business acceptance of the release, after which the DR Site will be upgraded. During the interval between the two deployments the DR environment will be in a "Frozen" state.It is anticipated that this will occur from 10:00 AM on Monday 3rd Dec. It should also be stressed that all timings are approximate. A more accurate assesment will be available on completion of Implementation testing in Pre prod - - to be completed following UAT.

FUNC3234 28.52 Q - Deployment of C-Nomis 1.0d to Doxford NCDS

Deployment of C-Nomis 1.0d into to Doxford NCDS followed by Fire Break and Upgrade of DR SIte on 10TH Dec.

This a CONTINGENCY CR ------The 1.0d Implementation is Scheduled for 1/2nd Dec. However, UAT has net yet been completed for this release.Should the need arise, it may be necessary to Reschedule the 1.0d implementation for the following week. _ This CR covers the contingemcy arrangements.

Upgrade from C-Nomis 1.0c to 1.0d will require an outage of C-Nomis Services and Interfaces from 22:00 on the 8TH Dec to 06:00 on the 9th Dec. A fire break of appox 24 Hours to allow for full business acceptance of the release, after which the DR Site will be upgraded. During the interval between the two deployments the DR environment will be in a "Frozen" state.It is anticipated that this will occur from 10:00 AM on Monday 10TH Dec. It should also be stressed that all timings are approximate. A more accurate assesment will be available on completion of Implementation testing in Pre prod - - to be completed following UAT.

FUNC3235 28.53 Q - Deployment of ECL release CR384 and 2 urgent Hot Fixes

Deployment of ECL release CR384 and 2 urgent Hot Fixes.

To Enable NOMIS to meet the requirements of the Governments ECL initiative a CR meeds to me implemented, this incorporates the following changesNational Reference Data RD_V10.2.0.1.53.48National Reference Data RD_V10.2.0.1.53.49IIS 1.12Business Objects Release [redacted]& [redacted]Install IWP Templates release IWPBM.2007.08.17.001

In addition, 2 urgent hot fixes will be deployed, they are the Visit order fix and a Modification to the Activities Report.


C-NOMIS RESTRICTED


FUNC3236 28.54 Q - Clariion san storage array at doxford requires a firmware co

Raised on behalf of David Beddard

The Clariion san storage array at doxford requires a firmware code upgrade.Current level is 065B/K and needs to be brought up to the lastest firmware version. Array will not be supported by EMC , void EMC/EDS service contract if upgrade doesn't take place. All servers attached to the SAN will need there applications stopped, so no I\O are going to and from the SAN. Servers application need to be stopped for a period of 2 hours :- [redacted] . HDS advised this is none disruptive change and should caused no problems. Once all application have been stopped, HDS engineer will shutdown the SAN and carry out the upgrade on SPA then test to make sure everything is fine, once this is completed he will upgrade the SPB and repeat the steps, each Storage processor will take around 1 our.

FUNC3237 28.55 Changes to Visits List report The following data items to added to the Visits ListV.O numberDetails of all visitors (current report only shows lead visitor)Child visitors to be flagged

FUNC3238 28.56 Additional “Court Considered Level of Seriousness” options

Raised on behalf of Michael Dutton.

Additional “Court Considered Level of Seriousness” options.

Changes required to the options available under Court considered level of seriousness to reflect ‘correct’ CJA03 language.Enables practitioners to record sentencer assessment of seriousness accurately.

Case Identification Screen – Court considered Level of SeriousnessAll existing fields in drop down box need removal and replacement with:• Not Stated• Too low for Community Sentence• Community Sentence Low• Community Sentence Medium• Community Sentence HighCustody Threshold


C-NOMIS RESTRICTED


FUNC3239 28.57 Change in Licence IWP details from PSI 48

As a result of the court rulings, the position generally for CJA91 prisoners serving 12 months or more is as follows:

• Any prisoner serving a sentence in respect of any offence committed before 30/9/98 may be recalled only until the ¾ point of their sentence (except for prisoners subject to Section 44 / Section 86, the release arrangements for which remain unaffected by this PSI). Such prisoners are entitled to unconditional release at the ¾ point of their sentence, and there is therefore no power to impose a licence in the final ¼ of the sentence. The “at risk” provisions continue to apply in the final quarter of the sentence.

•Any prisoner serving a sentence in respect of any offence committed on or after 30/9/98 but before 4/4/05 may be recalled until the ¾ point of their sentence. Whether or not the prisoner’s re-release from recall would be subject to licence supervision depends on the point in the sentence at which the prisoner is re-released.

Re-release licences

13. Where appropriate, establishments must ensure that the licences and notice attached to this instruction are used, when re-releasing from recall prisoners originally released under the CJA91, instead of those contained on LIDS or those contained in PSO6000. The correct licence (and accompanying explanatory note) in respect of the re-release of CJA03 prisoners remain available on LIDS. Establishments must continue to adjust the LED in line with any UAL time. Establishments must also ensure that, where appropriate, a Section 65 Notice of Supervision is issued.

The full PSI is attached for information - however it should be noted that this PSI came into effect on 23/11 - hence the request for a hot fix. it should also be noted that this CR only pertains to changes in 4 licences - the text and some bookmarks.

FUNC3240 28.58 Suppliers to ensure full clarity of data transfered from C-NOMIS

This CR requests that EDS, Syscon and the business fully evaluate the data being passed from C-NOMIS to IIS when live and duplicate records are amended during data cleansing.

The review should take into account any other interfaces transactions created by changes to offender data in C-NOMIS. and must ensure:

1. It identifies, recommends and specifies changes to C-NOMIS, IIS and any interfaces to ensure the integrity and accuracy of data passed from C-NOMIS to IIS.

2. It identifies and recommends changes to business processes until R1.0e and post R1.0e.

3. The modification will have to be in place and operational until all LIDS establishments (including COPS where transfers take place to a CNOMIS establishment) are replaced by C-NOMIS.

4. The merge functionality proposed for Release 1.0e and confirms that this does impact the IIS interface.

5. Confirmmation of delivery options and estimates of timescales.

FUNC3241 28.59 New version of 'Data Integrator' to be installed in the MIS envi

The resolution of a production problem requires the installation of a new version of 'Data Integrator' but only in the MIS environments.

There is a C-NOMIS NFR that states that only one version of any component should be in use. Therefore the Interface and Data Migration environments should also be upgraded to the new version.


C-NOMIS RESTRICTED


FUNC3242 28.60 Adjudication Awards - related to defect 1965

In screen OCUOICAW - Awards screen upon making two charges to run consecutive, in the award frame the adjudication refers to the adjudication number only and NOT the charge ID.

When the system displays an offender's adjudication award in the 'Award' block of the exsiting screen 'Offence In Custody Award - (OCUOICAW)', the system must display the 'Offence ID' of the award the displayed adjudication award is consecutive to, in place of the exsiting 'Adjudication' column.

FUNC3243 28.61 Comments on cancelled sessions - defect 5406

Recording comments of cancelled session not possible in same screen (OIDPACTI) as used to cancel the session.When a user cancels a prison activity attendance for a date greater than the date the user makes the cancellation, on either of the existing screens 'Prison Activities - (OIDPACTI)' or 'Prison Activity Attendance - (OIDPAATT)', the system shall allow the user to record a comment against the cancelled attendance.

FUNC3244 28.62 Business Objects password security Users of the Business Objects reporting tool who log in directly as opposed to using Single Sign On are given three opportunities to enter their password, three failures in succession will cause the account to lock. If the user enters two failures in succession and then waits 90 minutes the failure count reverts to zero and the user has another three chances. This is a requirement as defined in the NFR catalogue:This is linked to defect 7004 in Test Director179.18.1.4 Password Monitoring NOMIS shall prevent a user from accessing the system if they have entered an incorrect password three times in succession. In this event NOMIS shall send an alert to the Security User.

FUNC3245 28.63 Duplicate Reportable Incidents Amend MIS reports that report on incidents (including, but not limited to, Incidents by Establishment and Incident Type report) to filter out all incidents having the status of DUP [Duplicate (Raised in Error)]. The associated Vantive ticket is 1325226.


FUNC3247 28.65 Duplication in Licence IWP - related to defect 7798

This CR has arisen because of a change in release 1.1 to make the description of a Programme mandatory on the licence, should there be a programme condition ordered. The description of the programme is contained in a LOV and is reference data.However the mandatory programme decsription conflicts with a related need to permit the entry of an “Other” programme (i.e. one not already specified in C-NOMIS reference data).In either of these circumstances there is a free text box which can be entered. if a user selects the description of a programme from the LOV and enters text in the Other box, then the printed licence incorrectly displays as 2 conditions.This problem could be resolved through user training or preferably with a change in the sequel bookmark code to state "If programme description <> Other do not include comments."

FUNC3248 28.66 Refusal reason for HDC - related to defect 7865

Currently, if HDC is refused a user can save the record without entering a reason for refusal. The Refusal Reason has been present since the original design, but it has never been stated as mandatory when the HDC status is set to refused.


C-NOMIS RESTRICTED


FUNC3249 28.67 Amend interfaces to pass 99 years as the age of anyone over 100

The current C-NOMIS application allows peoples' ages to be over 100 years. The maximum on legacy applications is 99 years.The change is to transform any prisoners who are 100 years or over to 99 years on the interfaces.This will require changes to the interfaces to LIDS, IIS, OASys and Bulk extractsOther than interfaces, only testing will be impacted by this defect.

Defect no 6019 (EPG Monitor Transfer File (ldmpt) not produced due to offender having age >99 years, refers

FUNC3250 28.68 Replace Code with Description on screen OSIHRSUM – Defect 4090

When the system displays an Offender’s history of bookings on the existing screen ‘Offender History – (OSIHRSUM)’, the description of the reason for the Offender’s booking will be displayed in place of the reason’s code

FUNC3251 28.69 New OM Phase III forms for IPP and Lifers

6 new forms have been issued by Offender Management for use in HMPS. These need to be IWP templates. They are called LISP 1 to LISP 6. Not able to attach these electronically at the moment but I have paper copies to enable an impact

FUNC3252 28.70 C-NOMIS - ACCESSING LICENCE INFORMATION FOR INACTIVE OUT OFFENDE

This CR is a change to the live system to create a new caseload. The new caseload will be created using standard C-NOMIS front end screens. No testing is required. No changes to software or database are required either. Minor changes to training materials and user administration process will be required.

FUNC3253 28.71 Q - Release into live of a replacement Visits List Report

This CR Covers the Release into live of a replacement Visits List Report.The Client has identified this VERY HIGH priority report as being defective and a corrected version has been developed by Business Objects.

Ensure Archive contains Current Release of ReportUpdate Business Objects Universes - Using BOUK Update WizardUpdate Visits List Report - Using BOUK Update WizardConfirm Report Version Numbers are as designed


C-NOMIS RESTRICTED


FUNC3254 28.72 Migration, IEDT transfer and Oasys transfer of ACCT/F025 alerts

1. Currently on migration and IEDT transfer from LIDS to C-NOMIS any LIDS "Self Harm" alert is created on C-NOMIS as "Self Harm-Custody " alert. This is incorrect. Migration and inbound IEDT should be changed to create any LIDs "Self Harm" alert on C-NOMIS as "ACCT OPEN (HMPS) Alerts.

2. On migration and IEDT transfer from LIds to C-NOMIS all historical and current LIDs "Self Harm" alerts hsoudl be create don C-NOMIS according to the mapping rule above. If the alert is Active on LIDs then it shoudl be created as an alert with no expiry date on C-NOMIS and a creation date = the LIDS creation date. If the alert iis inactive on LIDS it shoudl be created as an alert with an expiry date equal to the expiry date on LIDS and a creation date = to the LIDS creation date.

3. Currently the Oasys quuestion "OASYS ROH_FA Section 8, R8.1.2 is being incorrectly populated by the c-NOMIS to Oasys interface. The Oasys question asks "Is there a current F2052SH - YES/NO". This is currently populated with Yes if C-NOMIS contains an active Self Harm Custody alert. This is incorrect, the question should only be populated with Yes if C-NOMIS contains and active ACCT OPEN (HMPS) alert for the offender

Additionally, the same question should be changed to NO if the ACCT OPEN (HMPS) alert becomes inactive on C-NOMIS for the offender. This currently does not occur even with the incorrect mapping of Self Harm

FUNC3255 28.73 Q - Change DB flag to prevent request messages being sent from O


This change is to prevent messaging from OASys to cNOMIS during the period of the cNOMIS Disaster Recovery test. All other OASys functionality will be available to users at these sites only messaging will be stopped for the period of the test.

Changing of a DB flag will prevent any cNOMIS request messages from being sent from OASys to cNOMIS. These messages will simply be stored up but not sent during this change. Once the DR test has been completed this flag will be reset and the stroed up messages will be picked up and sent to cNOMIS. There will be no loss of messages but they will not be sent during the DR test.

FUNC3256 28.74 Q - First Annual DR Test of C-Nomis First Annual DR Test of C-Nomis - Forced Fail Over from Primary Facilities at Doxford to Secondry Site at Washington, Followed by Failback to Doxford.

See TimeLine Tab for Full Details - Key Activities below1) C-Nomis Services to be Stopped at Primary Site/GSS Recofig'd2) OASys PULL from Nomis Disabled with OASys (Separate CR) (IOW Cluster Only)3) Secondary SIte (Washington) Promoted to Live4) Interfaces Reconfigured to Point to Dummy End Points - To Protect Live Legacy Systems5) Service Tested by Client6) Interfaces Tested by Client and EDS Personnel7) Signoff8) Nomis Services at Secondary SIte Stopped9) Nomis Services at Primary Site Started10) OASys Pull Capability Re Enabled for IOW Cluster11) Primary Site Accepted12) Secondary Site Synched with Primary site


C-NOMIS RESTRICTED


FUNC3257 28.75 Change of name from C-NOMIS to Prison Nomis

Due to recent changes within the scope of C-NOMIS the decision has been made to change the name from C-NOMIS to Prison Nomis.

FUNC3258 28.76 MIS Caseload Requirement Clarification

NFR 179.9.3.10 states that ' Whilst using an external reporting tool, the Authorised USer shall not be able to access NOMIS Information that they are not permitted to access within NOMIS.'

The change proposes that the NFR be re-worded:

The ad-hoc reporting database will allow full access to all Offender data for:

a) all offenders who are currently in the users Caseload;

b) all offenders who have been in the users caseload at any time in the last 6 calendar years (the RDS statistical calendar is the calendar year).

FUNC3259 28.77 MIS Universe Development To enhance the ad-hoc reporting capability for end users, the addition of more objects to the following universes in the MIS database :Demographics, Activities, Finance, Incidents, Sentence & Visits.The creation of the following further universes in the MIS database:Adjudications, Movements & EstablishmentsA list of the data items for objects in the MIS universe is contained in the document attached to this CRThis CR replaces previous CR's - CR429, CR430, CR431, CR432, CR433, CR434 & CR 435


C-NOMIS RESTRICTED


FUNC3260 28.78 Q - Sun Solaris patches to Database Severs in NCDS Live & Standy


To address the route cause of an issue that resulted in Two Service outages within The M-Nomis and C-Nomis environments it is intended to apply, as a matter of priority a number of Sun Solaris patches to the Database Severs in NCDS Live and Standy Environments.

The problem was highlighted when the loss of access to the application was reported during the working day and it transpired that the database cluster was hanging. Sun advise that the problem will be resolved by a patch which fixes the way their servers access database storage via fibre channel.

Fri PMBackup Rescheduled to start at 22:00Overnight Batch Processes suspended (to be run manually on completion of patching)

Saturday AMClosedown Nomis Databases, Services, Interfaces and MISApply Solaris patches [redacted] to the following 5 live servers at Doxford - ukdxnom001 [redacted].Start Nomis Databases, Services, Interfaces amd MISStart Deferred Batch ProcessesReset Scheduled Processes for future days

Sunday - Firebreak

Monday AMFollowing a fire break of two days, the System Disks on the named Servers will be re mirrored thereby applying the patches to the mirrored partition on each server

Monday PMPatches Applied to [redacted] (Standby site)

FUNC3261 28.79 Baseline Requirements Index for R1.0e

The Requirements Index for R1.0e ver 0.6d was last updated on 27/11/07, and forwarded to [redacted] for their approval. In January 2008 [redacted] indicated that this version would be the baseline, against which further changes would be impacted. HMPS wish to include some biometrics functionality within R1.0e, as well as a number of CRs which post-date the compilation of ver 0.6d of the Index.

This CR is to formally bring ver 0.6d within Change control. It should be noted that a further revision of the Index will be made during february 2008, to include additional functionality requested by HMPS, and a further CR will be raised at that point.

FUNC3262 28.80 Inclusion of Offender manager One of the implications of removing NPS functionality from C-NOMIS was the loss of the Offender manager field. This was expected to have been populated (and maintained) by NPS through the staff and agency location functionality.

OM and location of OM is required in C-NOMIS to poulate licences and button reports. it is also required by the DSS Project and this business benefit has already been doucmented.

{Please see attached paper for further detail and options


C-NOMIS RESTRICTED


FUNC3263 28.81 REVOKE CR00219 (Preventing Returning prisoners being received at

CR00219 was a change to prevent returning offenders creating a duplicate record for Albany for offenders attending the Hospital in Parkhurst.

Since the implementation of Parkhurst and Camphill the number of returning offenders has increased and IEDT records are being blocked. This has reduced the integrity of offender data, and increased the amount of manual effort required to resolve duplicate records.

This CR needs to be removed so the returning offender data is created in CNOMIS.

FUNC3264 28.82 De-scope two finance reports FIN0018 (All Accounts) Prisoner Account Statement, this report will return the details of all three accounts held by a single prisoner Spends, Private and Savings FIN0019 Prisoner Account Statement (Spend) this report will return the details of a single prisoners Spend account.Both these reports are superseded by FIN0017 Prisoner Account Statement, which allows the user to select one or more prisoners.All three reports are currently in the live environment, FIN0018 & FIN0019 which both have defects should be withdrawn and replaced with a new version of FIN0017.

FUNC3265 28.83 Changes to activity functionality as a result of Isle of White o

This is required before 1.0e due to difficulties experienced on the I.O.W.1. Allow one or more ‘slots’ (e.g. Morning, Afternoon, Evening and Night) to be recorded against each prison activity. Each slot will have a start time and end time and be associated with one or more days of a 7 day week.2. Allow an Offender’s schedule for a prison activity to be customised from the standard schedule for that activity.3. After an Offender has left an Establishment, allow the Establishment to de-allocate that Offender from activities they are still scheduled for within that Establishment.4. When maintaining a prison activity, allow the user to view all Offender’s currently allocated to that activity. The view includes at least allocation start date, allocation end date, Offender name, whether allocation is suspended and NOMS number, other fields maybe identified during design.5. Change screen OIDINTMV (Internal Movements) so that when a scheduled movement is for a Prison Activity, the ‘Schedule Reason’ column displays the prison ‘Activity Description’.6. Change screen OIDINTMV (Internal Movements) to add an additional column into the displayed results displaying the scheduled start time of the internal movement.7. If Toolbar Navigation is setup to call OIDPACTI (allocations screen) from OIDPAATT (bulk attendance screen), populate OIDPACTI with the Offender selected on OIDPAAT when navigation occurs.8. Allow a user to additionally filter by prison activity in the ‘Prison and Service’ frame of screen OIDPAWLI (bulk wait list).


C-NOMIS RESTRICTED


FUNC3266 28.84 PVO’s are incorrectly calculated as part of the batch process.

On the 1st of every calendar month, an Offender’s Privileged Visiting Order (PVO) balance should be credited according to their current IEP level. The amount credited for an IEP level is based on the value recorded against each level for the Establishment the Offender is currently located (as defined on the existing screen OIMOIEPS – Maintain IEP Levels).On the last day of every calendar month, an Offender’s PVO balance should be set to zero.Note: this process is distinct from the VO process where they are credited every 14 days and are not debited from the Offender’s VO balance.

Update from [redacted] 11th March 2008 - Explanation of the CR:Business requires PVO’s to be issued on the 1st day of each calendar month and expire on the last day of each calendar month.

• Currently in C-NOMIS they are issued every 14 days (as they are erroneously based on the issuing of the standard VO) and they do not expire. This is a defect against requirements.• The Design document (requirements) specified that they be issued every 28 days – this is an error in requirement – it should be issued on the 1st day of the month and expire on the last day of the month.

Hence C-NOMIS currently has a defect against the design requirements. However, if the defect is fixed this will leave PVOs issued every 28 days, and not from the 1st to the last day of each month. If this is not corrected it may be that a prisoner receives more than their entitlement of PVO’s.(Difference between say 2 per month and 2 per every 28 days)

Therefore whilst the defect must be remedied, the CR to modify the requirements (i.e. to change 28 days to 1st to last day of each month) is also required.

FUNC3268 28.85 Reports for Her Majesty's Inspectorate of Prisons

Her Majesty’s Inspectorate of Prisons requires a prison to submit a large quantity of data prior to and on the first day of an inspection, currently the prison being inspected is asked to supply this data. The data supplied is often incomplete and not delivered in a timely manner for the inspection, it is also a time consuming task for the prison to complete involving several members of staff. Prisons submit the data in different formats, with possible different understandings of what is required and the consequential data quality issues. With the C-NOMIS application this set of reports could be produced centrally and generated by HMIP before the inspection commenced, the reports would be timely, consistent, complete and the impact on the prison would be reduced.

Update from [redacted] 6th March 20083 Options (attached to CR ticket)A: - Move CR to IIS Replacement – benefits to prisons and Inspectorate delayed.B: - Develop the reports in BICC (with the exception of the 7 reports which will not have data in the R1.0e reporting tools) during the roll-out of R1.0e and before IIS replacement. This would bring forward the benefits for both Inspectorate and prisons.C: - Train HMIP data analysts in ad hoc reporting tools and enable them to develop the reports they require. Would require some input from BICC. This would bring forward the benefits for both Inspectorate and prisons.


C-NOMIS RESTRICTED


FUNC3269 28.86 Canteen Order Form OR version Create an OR version of the report 'FIN0035 Canteen Order Form' that currently exists in the MIS reporting environment, this report was created specifically for HMP Albany to fulfill the business need to supply each prisoner with an order form for the prison canteen, the form is populated with the prisoners details and the current available spend balance. the report was originally created as an Ad-Hoc report hence it exists in the MIS environment. It was recognised that this report was required nationally and it has been placed in the catalogue of MIS reports. The report is better suited to the Operational Reporting environment as it would always return the latest available spend balance of a prisoner it would also syncronise with the spend balances in 'FIN0035 Print Canteen Report'. which is a list of prisoners with their available spend balances that is used by the canteen staff.

FUNC3270 28.87 Change to ACT0005 Print Activities Report

Add a new tab to ACT0005 Print Activities Report, the new tab would use the same data and rules as the existing tabs, but would sort and break the report by activity.


C-NOMIS RESTRICTED


FUNC3271 28.88 Ending Schedules on leaving establishment - defect 1974

Defect 1974 ITT - In screen OIUSCINQ - Offender schedule conflict enquiry - when an offender has been transferred to another prison and in his new prison a new schedule is made a conflict is shown from his old establishment.

Requirement 1:When a user attempts to action the transfer of an Offender from one Establishment to another, and the Offender has outstanding scheduled internal appointments, the system must allow the user to cancel or not cancel the outstanding scheduled internal appointments before the transfer is actioned by the system.

Requirement 2:When a user attempts to action the transfer of an Offender from one Establishment to another, and the Offender has outstanding scheduled visit appointments, the system must allow the user to cancel or not cancel the outstanding scheduled visit appointments before the transfer is actioned by the system.

Requirement 3:When a user attempts to action the transfer of an Offender from one Establishment to another, and the Offender has outstanding scheduled adjudication appointments, the system must warn the user that the outstanding scheduled adjudication appointments exist. The system must allow the user to continue actioning the transfer after the warning, or cancel the transfer.Additional Comments:Note that in requirement 3 the system does not allow the user to cancel the adjudication appointments.

Requirement 4:When a user attempts to action the transfer of an Offender from one Establishment to another, and the Offender is scheduled for other transfers, the system must provide the user with the options to cancel or not cancel the other scheduled transfers before the transfer is actioned by the system.Requirement 5:When a user attempts to action the transfer of an Offender from one Establishment to another, and the Offender has outstanding scheduled programme appointments, the system must allow the user to cancel or suspend the outstanding scheduled programme appointments before the transfer is actioned by the system.Additional Comments:Note that in requirement 5 this is the same functionality as currently exists for prison activities.

Requirement 6:When a user attempts to action the transfer of an Offender from one Establishment to another, and the Offender is scheduled to attend court, the system must provide the user with the options to cancel or not cancel the scheduled court attendances before the transfer is actioned by the system.

Requirement 7:When a user attempts to action the transfer of an Offender from one Establishment to another, and the Offender is scheduled for any temporary absences, the system must provide the user with the options to cancel or not cancel the scheduled temporary absences before the transfer is actioned by the system.

Requirement 8:The system must allow an Establishment to cancel or update the following scheduled events only if they have been created by that Establishment, an Establishment must NOT be allowed to cancel or update these events if they have not created them:• internal appointments• scheduled visits• adjudication appointments• scheduled transfers• scheduled prison activities


C-NOMIS RESTRICTED


FUNC3272 28.89 Revised Biometrics functionality in R1.0e

CR to bring revised biometric functionality within the scope of R1.0e. The attached paper sets out the details of the required functionality, much of which already exists in the C-NOMIS application.

FUNC3275 28.90 Oasys PNC and Working Name - related to defect 5060

If a change is made to the working name of an offender then the PNCID associated with the new working name is not being passed to OASYS (PNCID associated with the old working name is passed instead).Issues are:-C-NOMIS permits >1 PNCC-NOMIS permits >1 PNC for aliasesWhich PNC to pull through to Oasys, IIS if >1 PNC?

Currently if a change is made to the working name of an offender then the PNCID associated with the new working name is not being passed to OASYS – the PNCID associated with the old working name is passed instead.

The OASys details message is created by dumping the contents of the NOMIS tables in an XML message. However, in the case of Offender_Identifiers, there is no way to derive what identifier belongs to what offender based on the contents of the XML complexType, which basically just lists the identifier_type and its value.

Possible solution is as follows:Copy over key attributes at the point of creation of an alias offender alias recordWhen the user creates an alias offender record, we need to ensure that any key attributes recorded against that offender's current working name are also copied over to this new alias record. At the point of creation of the alias record, the system should automatically copy over the attributes of gender, ethnicity, from the current working name to the alias record IF these attributes have not been filled out by the end user.Business needs to consider Ethnicity, Gender, Birth Place, Birth Country Code and CRO in addition to PNC

Clarification provided by [redacted] 26th March 2008:Oasys only permits 1 PNC NumberC-NOMIS permits more than 1C-NOMIS can also have different PNC numbers on alias records.

Issue 1When a user is entering details in Oasys and searching C-NOMIS for the right offender record to populate the record, which PNC number is presented to the user? Currently the PNC number attached to the working name is presented but there can still be more than 1. So the rule needs to be that the PNC with the latest user modified date is the one taken. This is a change to the interface.

Issue 2In the event of a new alias being created with no PNC entered against that alias a blank PNC will be pulled through. To prevent this possibility, a change is required to ensure that when a new alias is created, that unless the user adds a PNC Number, that the record is populated with the latest PNC associated with the working name. The suggestion is that not only PNC but other key identifiers (Gender, ethnicity, nationality and CRO) are treated similarly. This is a change to the application

Data migration code requires changing to reflect both the above issues.

In an attempt to reduce the number of PNC ID’s associated with an offender, rather than create a new alias record with the new PNC, users should be encouraged to ring Live Services and request the PNC is changed on the working name.


C-NOMIS RESTRICTED


FUNC3277 28.91 Provide a new extract from C-NOMIS to OFFLOC

Currently C-NOMIS provides certain extracts including the 5x5. The 5x5 is currently used to provide information to OFFLOC as there was insufficient time to create a new extract before Prison-NOMIS went live.

CR190 was lodged to bring the Prison-NOMIS extracts in line with the LIDS PB46 extract and provide a fuller set fo data to OFFLOC.

However, the DSS project now requires further data items form Prison-NOMIS to be added to the extract. These are Alias details, Offender Supervisor, Personal Officer, Case Administrator and NOMIS Number.

it was felt that a new CR should be raised to cover this requirement from DSS.

FUNC3278 28.92 Revisions of HelpText Revisions of C-NOMIS helptext as per report and recommendations from [redacted] 15/02/08

FUNC3279 28.93 USER MESSAGE TO BE DISPLAYED [redacted]

Raised on behalf of Security ([redacted])

The system will lock a user out [redacted] and display to the user that a password reset is required to regain access.

Additional comments from [redacted] (3rd April)This was agreed between [redacted] that this would go through as a CR as there would be no cost to the authority as this would speed up the process.

FUNC3281 28.94 MIS Universe Development To improve Ad-Hoc reporting capability, current available objects were prioritised to support pre-built reports.Expanding the number of objects extends the range of Ad-Hoc reporting. End users need to be able to report on as much of the system as possible to provide information for daily operational use, Senior Prison managers, Area Managers, Headquarters, Her Majesty’s Inspectorate of Prisons etc.LIDS provided wide ranging Ad-Hoc reporting across the system and it is the expectation of the business that C-NOMIS would provide the same as defined in the requirements catalogue – Reporting requirements R2a through to R2k.There is currently no reporting capability for Adjudications and Visits, a new universe will need to be created for each of these areas.There is limited reporting capability for Incidents and particularly Visits and changes will need to be made to these two universes. There are a small number of reports (5 Incident reports and 1 Visits report) associated with these universes that will require regression testing, this is acceptable given the benefits of the improved Ad-Hoc reporting capability.’

FUNC3291 28.95 HDC transfer and history reports Both the HDC History Report and the HDC section of the Transfer Report must be modified to bring them up-to-date with changes made to HDC functionality by Change Requests 119 (Amend HDC Address and Curfew), 208 (Record and report on all stages of the HDC process) and 265 (New PSI on HDC).Both reports are Oracle Button reports.See attached paper for further information


C-NOMIS RESTRICTED


FUNC3292 28.96 Change codes for descriptions on OIDSCMOV -

This CR results from defects 1036 & 1037. It has been agreed that these are not defects, but change requests.

Requirement:When the system displays offenders' scheduled court movements on the existing screen 'Schedule Court Movements - (OIDSCMOV)', the name of the court the offender will be moved to must be displayed in place of the court's code.Additional Comments:Currently the court 'Code' is displayed on OIDSCMOV. The purpose of the requirement is to replace this with the court's name which is held in the 'Location Description' field defined on screen 'Maintain Agency Locations - (OUMAGLOC)'

Requirement:When the system displays offenders' scheduled court movements on the existing screen 'Schedule Court Movements - (OIDSCMOV)', the description of the reason for the offenders' court movement must be displayed in place of the reason's code.Additional Comments:Currently the reason 'Code' is displayed on OIDSCMOV. The purpose of the requirement is to replace this with the reason's description.

FUNC3308 28.97 IIS interface for Video Links A change is required to allow the IIS interface to detect the direction of a movement and input the appropriate code for Video Links

FUNC3310 28.98 Addition of Offender Manager & Offender Supervisor data to C-NOM

Close CR00465, and move all reqs documentation for CR00465, including Syscon preferred option to this CR + add Offender Supervisor data (from LOV) to proposed new screen holding Offender manager data, and update hotpage.

FUNC3312 28.99 Auto Log off NFR 179.18.1.2 (version 0.5)

This CR exists to impact the design proposal from Syscon to meet NFR 179.18.1.2 (version 0.5) - Design document location on M: Drive is M:\cTag\Build\Release 1.0e\Workpackages\NFRs

FUNC3313 28.100 Sharing reports All Prison NOMIS users have an Inbox within the Business Objects Web Intelligence reporting tool that can receive copies of reports sent by other users, at present only a limited subset of users (report writers) have the rights to send reports to other users Business Objects Inboxes. The purpose of this CR is to enable all users to have the ability to send reports to the Business Objects Inbox of any other user.

FUNC3315 28.101 Global Search by LIDS Prisoner Number

Add the ability to search by LIDS Prison Number to the Global Search OSIOSEAR

FUNC3316 28.102 PNC number on transfer report PNC number is missing when inmates’ records are transferred from C-NOMIS to LIDS

FUNC3317 28.103 Remove Database Name from Login Screen

This is a totally unnecessary entry during login and users are complaining (see attachments for screen shot)


C-NOMIS RESTRICTED


FUNC3319 28.104 Biometrics Addendum to CR0475 This CR should be read as an addendum to CR0475 - it increases biometrics functionality. There are 3 additional items:-

1. 10 fingerprint images are recorded using an authority provided "slap" recorder instead of a single fingerprint reader. To include the ability to override part of the enrolment process of the bop bop bop. All of these fingerprint enrolments to be stored within Prison Nomis.

2 (a). Record, store and process (on verification) the fingerprint quality assessment score (NIST NFIQ Toolset).2 (b) Configure optimum verification threshold for the system based on a suitable FNMR which is acceptable to the business (this clarifies existing functuionality)

3.Facial images are recorded in accordance with the FIND implemetation of ISO19794-5 (ICAO compliance)

FUNC3320 28.105 ECL Defect (HMPS) *Change Requestor - [redacted]**Raised on behalf of - [redacted]*

Change the current functionality of ECL due to poor design. Currently this process takes too long for users to complete the process and fails to replace the paper system ECL procedures are currently based on. Effectively some of the actions are dead end processes

ECL functionality1. Dramatically simplified or whole process or2. Develop process on application that removes need for paper system

FUNC3321 28.106 ECL Defect - MS Excel (HMPS) *Change Requestor - [redacted]*Raised on behalf of [redacted]*

To enable users to copy live operational data and MIS operational data into excel to improve reporting capabilities

PLEASE NOTE: This CR is to request the ability to save reports into an excel spreadsheet and then manipulate it accordingly ifneeded. This is available to users now although I would suggest they are not aware of this. Clarification needed if this is something which can be fixed through Training.

FUNC3322 28.107 Hot Page (HMPS) *Change Requestor - [redacted]*Raised on behalf of [redacted]*

Add the following items to the Hot Page:• Latest CSRA Status• Offender Supervisor (this is linked to existing CR00263 and CR00465. The latter will shortly be superseded to cover the requirement to display the Personal Officer, Offender Supervisor and Offender Manager)• Main Offence (this field is currently not available in Prison-NOMIS and can be a manual data entry field which is then automatically copied to the Hot Page)


C-NOMIS RESTRICTED


FUNC3323 28.108 Additional items to CSRA Assessment (HMPS)

*Change Requestor - [redacted]**Raised on behalf of - [redacted]*

Add the following items to the CSRA Assessment:• Risk Minimisation Plan (Ref PSI 32/2005 dated 8th August 2005)

FUNC3324 28.109 Redesign the RBACS Matrix (HMPS)

*Change Requestor - [redacted]**Raised on behalf of - [redacted]*

Redesign the RBACS matrix in accordance with RBACS Review document v 0.4

FUNC3325 28.110 Switch on ID Card Functionality (HMPS)

Establishments would like the ID Card functionality switched on to aid their operations.

ID Cards can be printed out from system onto existing hardware.

FUNC3329 28.111 Replace Code with description on screen OIDSCMOV Defect 1037

When the system displays offenders' scheduled court movements on the exsiting screen 'Schedule Court Movements - (OIDSCMOV)', the code of the reason for the offenders' court movement is displayed rather than the description.

FUNC3330 28.112 HDC Approval Status Defect #2970 Currently the system allows a user to approve HDC in the Approval Status field on screen 'Home Detention Curfew - (OIDAHDCE)',The system shall allow the approval of Home Detention Curfew (HDC) for an offender to be only via a Governor's decision on the existing screen 'Governor - (OCUHGOVE)'.

FUNC3363 28.113 Amalgamation of Release of SR8/SR9/SR10 Help Text (EDS on behalf of Syscon)

Consolidation of delivery of SR8 / SR9 and SR10 Online Help and change of delivery date to 18/09/08

FUNC3181 28.114 Changes to NFR catalogue V2.1 Changes to NFR catalogue v 2.1.

This concerns the AT tool version changes - ref 179.13.1 to 179.13.19. The AT toolset is now specified as follows:-

Jaws version [redacted]Dragon Naturally Speaking version [redacted]Text Help Read and Write GOLD version [redacted]Zoom Text version [redacted]

FUNC3767 28.115 Immigration Hearing refernce data Reference data for identifying a type of court movements will include a type of - Immigration Hearing

FUNC3365 29 Potential Deletions


C-NOMIS RESTRICTED


FUNC3056 29.1 Purchase of 20 Dell Optiplex GX5 as part of the refurbishment of ground floor

The procurement of 20 Dell Optiplex GX520 desktops for the project to be used at Grenadier House

FUNC3180 29.2 AT Very Early UAT (VE UAT) Test Environment required

AT Very Early UAT (VE UAT) Test Environment required

On 15/2/2007 an AT workshop was held. The workshop concluded that Very Early UAT (VE UAT) should be conducted against the 1.1 Release in respect to AT compliance.

A Virtual Environment dedicated to AT testing must be set up. The environment will have the following properties:

- Dedicated to AT testing only- Capable of connection via VPN- Testers to connect from a variety of locations: Grenadier House, Various locations to be specified (AT users' workstations based in London, Manchester, Abell House (Trevor Roberts), other locations)- Total number of discrete users requring access is 20 (presumably this will have licensing implications)- The release to be implemented into this environment at any given time is the latest Syscon Release 1.1 in Syscon development- The testing intended for this environment is VE UAT whereby the AT tester will connect via VPN and functionally test the C-NOMIS Release in conjuntion with PC-based (local) AT tools - Dragon, JAWS, Zoomtext, Text Help- This is a temporary requirement only - required from 01/03/2007 to June 2007 [After June 2007 the Doxford-based UAT environment will be ready AND this environment will contain the Release 1.1 which has resulted from the first cycle of EDS System and Integration test. Moving forward the Doxford UAT environment will always be available and further AT UAT will be conducted in this environment only - these intended UAT cycles are conducted within the scope of "Pre UAT" during 2007 and 2008]- The expiration of the temorary requirement stated as "June 2007" is so stated based on the assumption that the (yet to be agreed) EDS Release 1.1 plan has the first cycle of EDS System/Integration test delivering to Pre-UAT in June 2007. Should this date change then the temporary environnment will be required until the first delivery date into Pre-UAT

FUNC3062 29.3 Revised Dates for Releases 1.0B, 1.0C, 1.0D and 1.1

At the ∑:NOMIS Programme Board on 15th February 2007, revised ‘ready to deploy’ dates from EDS were approved for the delivery of C-NOMIS to the requirements scope approved by the JDWG on 18th January.

The revised ‘ready to deploy’ dates are:

Release 1.0B - Albany Maintenance Release – 15th March 07Release 1.0C – Isle of Wight (Iow) cluster + additional sites selected by HMPS & COPS (restricted list) – 11th July 07Release 1.0D – Priority Defect Release (scope to be determined post R1.0C) - September 07Release 1.1 - Combined Prison & Probation delivery – 25th July 08*Release 1.2 - Delius replacement - TBA*Release 1.3 - IIS replacement - TBA

* At this stage, work is progressing to complete Release 1.2 requirements (due March 07) and 1.3 requirements (due April 07).At the ∑:NOMIS Programme Board on 15th February 2007, revised ‘ready to deploy’ dates from EDS were approved for the delivery of C-NOMIS to the requirements scope approved by the JDWG on 18th January.


C-NOMIS RESTRICTED


FUNC3150 29.4 eOASys support changes - release 4.2.1a

An eOASys support release is planned for 28th April, covering the following problem fix change requests:

NPD0047 - Countersigning commentsNPD0064 - problems in pull-through after abandoned assessmentsNPD0070 - Emergency risk flag changeNPD0071 - Risk flag amendmentsNPD0077 - Field not being rolled back correctly.

Details are provided in the attached change request documents.

FUNC3149 29.5 eOASys patch release 4.2.1.1 An emergency patch update to eOASys is scheduled for release on 23rd April 2007. This relates to the Lotus Notes front-end functionality only and does not affect the HMPS OASys system which currently interfaces to C-NOMIS.

FUNC3143 29.6 eOASys support release 4.2.1b changes to eOASys only, and no impact on OASys or C-NOMIS is expected.

Changes are detailed in the attached eOASys change requests, numbers NPD0049,NPD0050,NPD0051,NPD0057,NPD0058,NPD0066,NPD0073,NPD0078,NPD0079,NPD0089

FUNC3145 29.7 Implementing the mirroring of the NFS Clusters - NOMIS (Q_ CR007520)

This is the first phase in implementing the mirroring of the NFS Clusters LUNS in Doxford with the SAN in Washington. This Non Functional Requirement of no loss of data was postponed from Rel 1. 0 of C-NOMIS but is required for Release 1.0c.This change does not start any mirroring of data and no data is manipulated as a consequence of this change. This change is to gain approval to connect the two SANS in Doxford and Washington via an intersite fibre link. It is required to connect the fibre switches to the link at both ends and the two SANS will be merged, the switches will be zoned. NO LUNS WILL BE MIRRORED AT THIS POINT. I will submit 2 further requests for actual mirroring, 1 for PRE-PROD to prove mirroring and a subsequent change to implement in LIVE.NO NEW HARDWARE or SOFTWARE is being introduced. These components are already in place. We are only implementing the capability to MIRROR data between DOXFORD and WASHINGTON.

FUNC3141 29.8 OASys release 4.2.2 OASys version 4.2.2 is planned for release in mid-September 07. This will contain one major change, to support Offender Management (OM), however other minor changes may be added in due course.

The OM change is described in a requirements spec - not included here because of the size of the document, but this is available from change management or [redacted].

This change will affect both ends of the OASys system (i.e. HMPS OASys and NPS eOASys).

FUNC3220 29.9 Q - Implemement Data Fixes and minor system changes to address i

Implemement a number of Data Fix and minor system changes to address incidents resulting from issues with Web Submission and user/group administration.

LSR11 will address and supply fixes to incidents 1156918, 1278610, 1280148, 1153153, 1171448,1256952.

FUNC3217 29.10 Q - Syncronise Time on servers ukdxnom001 and ukdxnom002


Syncronise Time on servers [redacted] to the Network Router.a ) Stop NTP daemon b) Change ntp.conf to point to Gateway c) Start NTP Daemon.


C-NOMIS RESTRICTED


FUNC3286 29.11 Ending schedules on leaving establishment - Updated to new CR

Supersedes CR0474. Defect 1974 ITT - In screen OIUSCINQ - Offender schedule conflict enquiry - when an offender has been transferred to another prison and in his new prison a new schedule is made a conflict is shown from his old establishment.

Detailed analysis of existing CR00474 has resulted in a decision to pursue simpler more cost effective requirements. This CR supersedes CR00474, CR00474 should be withdrawn.

Requirement 1:Currently when a user attempts to schedule an event for an offender (e.g. transfer, court hearing, adjudication, temporary absence, visits etc), a schedule conflict warning is displayed (OIUSCINQ – Offender Schedule Conflict Inquiry). This warning currently displays the date, time, type and reason of the conflicting schedules. To aid the user in deciding if they need to ignore, or take action, for each conflict, a new column is required on OIUSCINQ to display the location at which the event is scheduled.

Requirement 2:To aid Establishments in investigating outstanding schedules when a Prisoner is scheduled for transfer, 2 reports are required, these reports provide the same information but have different ordering requirements:* It has not yet been decided if these reports should be developed by BOUK or Syscon, but presumed at this stage to be BOUK.Report 1:Displays each Prisoner scheduled for transfer (including reason for transfer), on a date specified by the user. For each Prisoner displayed, the report must indicate if there are any outstanding schedules on or after the date of transfer for each of the following schedule types:• Adjudications• Release of Temporary Licence• Court• Activities• Visits• Other Transfers• Internal Appointments

Report 2:Displays each schedule type as listed above. For each schedule type displayed, the report lists all Prisoners scheduled for transfer (including reason for transfer), on a date specified by the user, and, who have any outstanding schedules of that type on or after the specified date.

Requirement 3:Reference data values for ‘Transfer Reason’ need to be updated so that they indicate the likeliness that the Prisoner will return within a short space of time. This will aid the recipients of the reports produced above in determining whether to remove scheduled events for a Prisoner scheduled for transfer.

Detailed analysis of existing CR00474 has resulted in a decision to pursue simpler more cost effective requirements. This CR supersedes CR00474, CR00474 should be withdrawn.

FUNC3005 29.12 Request for additional resource for LIDS Data Migration support during Albany Dr

The full title of this CR is: Request for additional resource for LIDS Data Migration support during Albany Dress Rehearsal and Live Cutover

The need for an additional resource to provide LIDS support during the upcoming Albany Cutover and Dress Rehearsal has been identified.

FUNC10030

31 Merge


C-NOMIS RESTRICTED


FUNC4547 31.1 Offender Merge Licence Rules When two Offender records are merged, either automatically or manually initiated, any Licence records held against bookings on the Offender records must be merged by the system according to the following rules: a) Where there are Inactive Licences on both bookings regardless of whether the bookings are Open or Closed, the Legals, Licence and Licence Conditions from the From Offender, are not copied over to the To Offender. The To Offender retains its Legals, Licence and Licence Conditions. The Legals and Licence on the From booking are inactivated after the merge has taken place. b) Where the From booking is either Open or Closed with an Inactive Licence and the To booking is either Open or Closed with an Active Licence, the Legals and Licence and Licence Conditions from the From Offender are not copied over to the To Offender. The To Offender retains its Legals, Licence and Licence Conditions. The Legals and Licence on the From booking are inactivated after the merge has taken place. c) Where the From booking is either Open or Closed with an Active Licence and the To booking is either Open or Closed with an Inactive Licence, the Legals, Active Licence and Licence Conditions from the From Offender are copied over to the To Offender. The To Offender retains its existing Legals and Licence and Licence Conditions and the Legals and Licence on the From booking are inactivated after the merge has taken place. d) Where the From booking is either Open or Closed with an Active Licence and the To booking is either Open or Closed with an Active Licence and the Licences on both bookings have the same CJA (that is both Licences are 1991 or both Licences are 2003). In this case, if the Licence with the latest Licence Expiry Date (LED) or LED Override Date is on the To booking, the To booking Licence is kept Active and the Legals, Licence and Licence Conditions from the From Offender are copied over to the To booking and made Inactive. The Legals and Licence on the From booking are inactivated after the merge has taken place. e) Where the From booking is either Open or Closed with an Active Licence and the To booking is either Open or Closed with an Active Licence and the Licences on both bookings have the same CJA (that is both Licences are 1991, or both Licences are 2003). In this case, if the Licence with the latest LED or LED Override Date is on the From booking, the Legals, Licence and Licence Conditions from the From Offender are copied over to the To booking and the Licence kept Active and the To booking Licence is made Inactive. The Legals and Licence on the From booking are inactivated after the merge has taken place. f) Where the From booking is either Open or Closed with an Active Licence and the To booking is either Open or Closed with an Active Licence and the Licences on both bookings have different CJA’s (that is one Licence is 1991 and one Licence is 2003). In this case, the Legals, Licence and Licence Conditions from the From Offender are copied over to the To booking and kept Active and the To booking Licence is kept Active. The Legals and Licence on the From booking are inactivated after the merge has taken place. g) Where the From booking is either Open or Closed with a mix of Active and Inactive Licences and different CJA’s (that is 1991 and 2003) and the To booking is either Open or Closed and has a mix of Active and Inactive Licences and different CJA’s (that is 1991 and 2003), the Legals, Licences and Licence Conditions from the From Offender are copied over to the To booking and the To booking Licences are also kept.Each Active corresponding Licence for 1991 on the From and To bookings and each Active corresponding Licence for 2003 on the From and To bookings is compared on its LED/LED Override Date. The corresponding Licence with the latest LED/LED Override Date is kept Active on the To booking, whether this be the copied Licence from the From booking or the Licence on the To booking. The other copied Licences from the From booking are made Inactive on the To booking as are the other Licences that already exist on the To booking. The Legals and Licences on the From booking are inactivated after the merge has taken place.


C-NOMIS RESTRICTED


h) Where the From booking is either Open or Closed with an Active Licence and the To booking is either Open or Closed with an Active Licence and the Licences on both bookings have the same CJA (that is both Licences are 1991, or both Licences are 2003). In this case, if the LED or LED Override Date is the SAME on both Licences on both bookings, the Legals, Licence and Licence Conditions from the From Offender, are not copied over to the To Offender. The To Offender retains its Legals, Licence and Licence Conditions. The Legals and Licence on the From booking are inactivated after the merge has taken place.


2. NON-FUNCTIONAL REQUIREMENTSReq Id Hrchy Name Definition

NFR4657 1 Application Development

NFR4658 1.1 Development Environment Need to have a set of requirements to cover Development needs of Syscon, data migration team, operational report development team, MIS development team, etc.

NFR4659 2 Performance

NFR4660 2.1 Central System Provide a single, centralised offender information database.

NFR4661 2.2 Geographical Distribution Support users distributed across current Quantum.

NFR4662 2.3 Response Times Provide response time to user interactions of three seconds or less. Precise levels of service will be agreed in a Service Level Agreement (SLA).

NFR4663 2.4 MIS Performance MIS Performance- TBD

NFR4664 2.4.1 MIS Performance - ETL The combined performance of the MIS scheduled batch jobs (i.e. ETL, automated report creation, report routing, etc) shall not result in the loss of service to HMPS Establishments as defined for the NOMIS Service Window agreed in the NOMIS SLAs. This aspect of the solution must cope with the full peak volumes of records on the C-NOMIS database as determined from the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4665 2.4.2 MIS Performance - OR reports The NCDS shall provide a user response time of 20 seconds or less for the delivery NOMIS Operational Reports selected by a NOMIS user from any HMPS site that C-NOMIS is accessible from. This response time shall be achieved for at least 90% of the OR selections in a calendar month. This aspect of the solution must cope with the full peak volumes of records on the C-NOMIS database as determined from the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4666 2.4.3 MIS Performance - predefined MIS reports

The NCDS shall provide a user response time of 30 seconds or less for the delivery of pre-defined C-NOMIS MIS Reports selected by a C-NOMIS user from any HMPS site that C-NOMIS is accessible from.. This response time shall be achieved for at least 90% of the Pre-defined NOMIS MIS Report selections in a calendar month. This aspect of the solution must cope with the full peak volumes of records on the NOMIS database as determined from the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4667 2.5 Application Performance Responsiveness system-level NFRs for normal operation excluding disaster recovery scenarios and MIS.

NFR4668 2.5.1 Response Times - NCDS The NCDS shall provide a user response time of 3 seconds or less for a C-NOMIS user already logged on to C-NOMIS from any HMPS sites on Quantum that C-NOMIS is accessible from. This response time shall be achieved for at least 90% of transactions excluding exempt transactions. Note: this requirement effectively implies a response time within the NCDS boundary of 1 second or less.

NFR4669 2.5.1.1 Response Times - NCDS The NCDS shall provide a user response time of 3 seconds or less for a NOMIS user already logged on to NOMIS from an HMPS establishment or a NPS office. This response time shall be achieved for at least 90% of transactions excluding exempt transactions. Note: this requirement effectively implies a response time within the NCDS boundary of 1 second or less.


NFR4670 2.5.2 Log-on time Performance The NCDS shall provide a user response time of 5 seconds or less for the process of logging on a NOMIS user from an HMPS establishment, HQ sites or other locations Prison-NOMIS is accessed from (as defined in the Prison-NOMIS Statement of Volumetric requirements [5]). This response time shall be achieved for at least 90% of the log on attempts in a calendar month. Note: this requirement effectively implies a response time within the NCDS boundary of 3 seconds or less.

NFR4671 2.5.2.1 Log-on time Performance The NCDS shall provide a user response time of 5 seconds or less for the process of logging on a NOMIS user from an HMPS establishment or a NPS office. This response time shall be achieved for at least 90% of the log on attempts in a calendar month. Note: this requirement effectively implies a response time within the NCDS boundary of 3 seconds or less.

NFR4672 2.5.3 Response Times - Exempt Interactions for NCDS

For Interactions which clearly cannot achieve the required response times, such as for production of certain reports, the NCDS shall produce a response at the NCDS boundary within the required 1.00 seconds that advises the User that the submitted Interaction is being processed. A list of such Interactions (identified within the scope of P&S testing) that are exempt from the 1.00 seconds requirement will be agreed with the NCDS provider and the Authority, as part of P&S testing before go-live and a process will be defined to add Interactions to the Exempt list for use post-go-live. Further, a process is to be agreed between Suppliers and Authority of how to resolve the performance problem with the Exempt Interaction. Excluded is any work for resolution of agreed Exempt Interactions and any work post go-live to add Exempt Interactions.

NFR4673 2.5.4 Response Times - Exempt Interactions for Quantum

For Interactions which clearly cannot achieve the required response times, such as for production of certain reports, the NCDS shall produce a response at the NCDS boundary within the required 1.00 seconds that advises the User that the submitted Interaction is being processed. A list of such Interactions that are exempt from the 1.00 seconds requirement will be agreed with the Quantum provider and the Authority, as part of P&S testing before go-live and a process will be defined to add Interactions to the Exempt list for use post-go-live. Further, a process is to be agreed between Quantum provider and Authority of how to resolve the performance problem with the Exempt Interaction. Excluded is any work for resolution of agreed Exempt Interactions and any work post go-live to add Exempt Interactions.

NFR4674 2.5.5 Response Times - Exempt Interactions for OMNI

For Interactions which clearly cannot achieve the required response times, such as for production of certain reports, the NCDS shall produce a response at the NCDS boundary within the required 1.00 seconds that advises the User that the submitted Interaction is being processed. A list of such Interactions that are exempt from the 1.00 seconds requirement will be agreed with the OMNI provider.

NFR4675 3 Continuity

NFR4676 3.1 Continuity Provide support for a continuity of operation in the event that SLR cannot be met. Will be agreed through NOMIS Resiliency documents (Quantum + OMNI specification).

NFR4677 3.2 HMPS Contingency Facilities The Quantum IS shall enable a NOMIS Authorised User to print NOMIS data stored on a server in his/her HMPS establishment on a printer at the same location. Note: this requirement provides for the rare event of an Incident for which the NCDS is failed, Contingency Facilities must be provided by the affected IS providers to support management activities until the NCDS is restored.

NFR4678 3.3 Contingency Facilities The NCDS shall enable a system administrator to select any NOMIS data for automatic copying to a server or servers at an HMPS establishment or any other HMPS location to which Prison-NOMIS is provided. The NCDS shall enable a system administrator to specify the time interval at which this automatic copy will occur. At the times specified by the system administrator the NCDS shall copy the selected data to the specified HMPS. Note: this requirement provides for the rare event of an Incident for which the NCDS is failed, Contingency Facilities must be provided by the affected IS providers to support management activities until the NCDS is restored. This requirement is to allow future capability to schedule and deliver Prison-NOMIS data that may be needed for other business purposes.


NFR4679 3.3.1 Contingency Facilities The NCDS shall enable a system administrator to select any NOMIS data for automatic copying to a server or servers at an NPS area office. The NCDS shall enable a system administrator to specify the time interval at which this automatic copy will occur. At the times specified by the system administrator the NCDS shall copy the selected data to the specified NPS servers. Note: this requirement provides for the rare event of an Incident for which the NCDS is failed, Contingency Facilities must be provided by the affected IS providers to support management activities until the NCDS is restored. This requirement is to allow future capability to schedule and deliver

NFR4680 3.4 NCDS Continuity The NCDS shall not contain any single points of failure.

NFR4681 3.5 Data Communications Failure at HMPS site

In the event of a local telecommunications failure at an HMPS establishment, HQ sites or other locations Prison-NOMIS is accessed from (as defined in the Prison-NOMIS Statement of Volumetrics [5]) , Quantum shall enable data communications with the HMPS site via alternative means.

NFR4682 3.6 Data Communications Failure at NPS Area Offices

In the event of a local telecommunications failure at a NPS area office, OMNI shall enable data communications with the NPS area office via alternative means.

NFR4683 3.7 RAS Connection to NCDS The NCDS shall not prohibit HMPS users and NPS users to log-on to the NCDS via RAS enabled devices connected to their own respective IS. RAS is an IS service. No additional facility is provided at the NCDS to enable RAS users.

NFR4684 3.7.1 RAS Connection to NCDS The NCDS shall not prohibit HMPS users and NPS users to log-on to the NCDS via RAS enabled devices connected to their own respective IS. RAS is an IS service. No additional facility is provided at the NCDS to enable RAS users.

NFR4686 3.8 Use of OMNI WBTs OMNI shall enable any NPS user to have the capability to log-on to the NCDS using any OMNI WBT connected to the OMNI IS at the NPS user's local office.

NFR4685 3.9 Use of Quantum Desktop Units Quantum shall enable any HMPS user to have the capability to log-on to the NCDS using any Quantum desktop unit connected to the Quantum IS.

NFR4687 3.10 Business Continuity Business continuity NFRs

NFR4688 3.10.1 Corrective Action Where any corrective action is required that is considered, by the NCDS IS provider, likely to render the NCDS unavailable for a period exceeding 4.0 hours, the NCDS provider shall not undertake this action without prior authorisation from NOMS.

NFR4689 3.10.2 Disaster Recovery Exercises All facilities associated with Disaster Recovery for NCDS shall be exercised at least annually. Note: this is to ensure that the facilities operate correctly and that all relevant staff are suitably trained. The planning for all such exercises shall be agreed with NOMS. It is incumbent upon each service provider to work together and co-ordinate / develop joint plans for disaster recovery testing

NFR4690 3.11 MIS Use of Quantum Desktop Units Quantum shall enable any HMPS Authorised User to have the capability to log-on to MIS using any Quantum desktop unit connected to the Quantum IS.

NFR4691 3.12 MIS Use of OMNI WBTs OMNI shall enable any NPS Authorised User to have the capability to log-on to MIS using any OMNI WBT connected to the OMNI IS at the NPS Authorised User's local office.

NFR4692 4 Availability


NFR4693 4.1 Availability The system shall be designed for continuous operation of the application, 24x7.

NFR4694 4.2 MIS Availability The MIS system shall be designed for operation of the application for a minimum of 99.8% of the time during the 'Service Window' of 0600 to 2400 Monday to Saturday and 0900 to 2400 Sundays and Public Holidays, measured over one calendar month

NFR4695 4.3 NCDS Availability Availability NFRs covering the NCDS. For the purposes of the requirements in this section the NCDS is deemed available when any NOMIS user is able to log-on to the NCDS from a desktop unit via the NOMIS user's Infrastructure Services.

NFR4696 4.3.1 NCDS Availability During Service Window

The NCDS shall be available to NOMIS users for 99.95% of the time during the 'Service Window' of 0600 to 2400 Monday to Saturday and 0900 to 2400 Sundays and Public Holidays, measured over one calendar month. The NCDS shall be available to NOMIS users for not less than 75% of this availability outside of the 'Service Window'.

NFR4697 4.3.2 Restoration of Service The NCDS shall enable system administrators to restore availability to NOMIS users within 4.00 hours or less from the time the NCDS becoming unavailable.

NFR4698 4.4 OMNI Availability Availability NFRs covering the OMNI IS.For the purposes of the requirements in this section OMNI is deemed available when any NOMIS user is able to log onto a PC or Windows Based Terminal connected to the OMNI infrastructure. On logging in the Windows desktop will be displayed including a control to start up the NOMIS application.

NFR4699 4.4.1 OMNI Availability During Service Window

Except for periods of planned maintenance, the OMNI IS shall be available to NOMIS users 99.8% of the time during the 'Service Window' of 0600 to 2400 Monday to Saturday and 0900 to 2400 Sundays and Public Holidays measured over one calendar month. The OMNI IS shall be available to NOMIS users for not less than 75% of this availability outside of the 'Service Window'.

NFR4700 4.4.2 Restoration of OMNI Service The OMNI IS shall enable system administrators to restore availability to NOMIS users within 6.00 hours or less from time of the OMNI IS becoming unavailable.

NFR4701 4.5 Quantum Availability Availability NFRs covering the Quantum IS. For the purposes of the requirements in this section the Quantum IS is deemed available when any NOMIS user is able to log-onto the Quantum IS from a desktop unit connected to the Quantum IS. On logging in the Windows desktop will be displayed including a control to start up the NOMIS application.

NFR4702 4.5.1 Quantum Availability During Service Window

The Quantum IS shall be available to NOMIS users as per the defined service level for Quantum during the 'Service Window' of 0600 to 2400 Monday to Saturday and 0900 to 2400 Sundays and Public Holidays, measured over one calendar month. The Quantum IS shall be available to NOMIS users as per the defined service level for Quantum outside of the 'Service Window'.

NFR4703 4.5.2 Restoration of Quantum Service The Quantum IS shall enable system administrators to restore availability to NOMIS users within 4.00 hours or less from the time of the Quantum IS becoming unavailable.

NFR4704 4.6 MIS Availability Availability NFRs covering the NCDS.For the purposes of the requirements in this section the NCDS is deemed available for the MIS users when any MIS user is able to log-on to the NCDS from a desktop unit via the MIS user's Infrastructure Services.

NFR4705 4.6.1 MIS Availability During Service Window

The NCDS shall be available to MIS users for 99.8% of the time during the 'Service Window' of 0600 to 2400 Monday to Saturday and 0900 to 2400 Sundays and Public Holidays, measured over one calendar month. The NCDS shall be available to MIS users for not less than 75% of this availability outside of the 'Service Window'.


NFR4706 4.6.2 Restoration of MIS Service The NCDS shall enable system administrators to restore availability to MIS users within 24.00 hours or less from the time the NCDS becoming unavailable.

NFR4707 5 Disaster Recovery

NFR4708 5.1 Disaster Recovery Provide a facility so that in the event of the loss of main system functionality no data shall be lost as described in the Data Centre Logical Architecture.

NFR4709 5.2 Automatic Download of HMPS back up report

Each HMPS establishment shall have an establishment specific file containing a set of essential reports automatically downloaded to its local File and Print server up to twice per day at times to be agreed.

NFR4710 5.3 MIS disaster recovery Provide the facility so that the loss of MIS system functionality shall be such that no data shall be lost.

NFR4711 5.4 Workflow Triggers If, as the result of any system failure, a workflow batch job fails to run or fails to complete its run, NOMIS shall enable a system administrator to manually restart the batch job. Note: this requirement is intended to ensure that no workflow triggers are missed due to any system failure at the NCDS.

NFR4712 5.5 Committed data loss prevention NOMIS shall prevent any data that has been committed to the NOMIS database from being lost, even in the event of a disaster

NFR4713 5.6 Manual Re-Send of HMPS back up report

A facility to re-send and/or re-create the establishment specific file containing a set of essential reports redirected to the File and Print server of the establishment's 'buddy' prison shall be available.

NFR4714 5.7 Committed MIS data loss prevention NOMIS shall prevent any data that has been committed to the MIS database from being lost, even in the event of a disaster

NFR4715 5.8 Interaction integrity When a User submits a create/update/delete NOMIS interaction, NOMIS shall only send a success acknowledgement response to the User for the Interaction when all relevant data associated with the Interaction has been committed to the NCDS database

NFR4716 6 Scalability

NFR4717 6.1 Capacity Provide a system to support the number of concurrent users and peak hour transactions specified in the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4718 6.2 MIS Scalability - Design The MIS Solution shall be architected and designed to be both extensible and scalable to meet the enterprise demands for MIS capability by NOMIS and other departmental MIS Users. Such capability is likely to encompass integrated MIS capability of new systems with each other, such as OASys-R, IIS replacement, PCMS as per NOMIS programme scope.

NFR4719 6.2.1 MIS Scalability - Solution As a minimum, the MIS Solution shall be capable of expansion to double the number of NOMIS MIS Users and locations and for up to double the number of concurrently logged-on NOMIS MIS Users specified in the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4720 6.3 Capacity System NFRs Capacity System NFRs

NFR4721 6.3.1 Combined Concurrent Users The NCDS shall enable the number of combined HMPS and NPS concurrent users specified in the Prison-NOMIS Statement of Volumetric Requirements [5] to use the NOMIS application contemporaneously.


NFR4722 6.3.2 HMPS Concurrent Users Quantum shall enable the number of concurrent HMPS users specified in the Prison-NOMIS Statement of Volumentric Requirements [5] to use the NOMIS application contemporaneously.

NFR4723 6.3.3 NPS Area Concurrent Users OMNI shall enable the number of concurrent NPS users specified in the Statement of Volumentric Requirements [8] to use the NOMIS application contemporaneously

NFR4724 6.3.4 HMPS Concurrent Users Quantum shall enable the number of concurrent HMPS users specified in the Prison-NOMIS Statement of Volumetric Requirements [5] to use the Prison-NOMIS application contemporaneously during the peak hour.

NFR4725 6.3.5 NPS Concurrent Users OMNI shall consistently enable the number of concurrent NPS users specified in the Statement of Volumentric Requirements [8] to use the NOMIS application contemporaneously during the peak hour

NFR4726 6.3.6 NCDS Peak Hour Interactions The NCDS shall enable the number of interactions (including IWP interactions, reports and interface interactions) to be executed in an hour as specified in the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4727 6.3.7 HMPS Peak Hour Interactions Quantum shall enable the number of interactions (including IWP interactions, reports and interface interactions) to be executed in an hour as specified in the Prison-NOMIS Statement of Volumetric Requirements [5]

NFR4728 6.3.8 NPS Area Peak Hour Interactions OMNI shall enable the number of interactions (including IWP interactions, reports and interface interactions) to be executed in an hour specified in the Statement of Volumetric Requirements [8],

NFR4729 6.3.9 HMPS Peak Hour Interactions Quantum shall consistently enable the number of HMPS interactions (including IWP interactions, reports and interface interactions) to be executed in an hour as specified in the Prison-NOMIS Statement of Volumetric Requirements [5]

NFR4730 6.3.10 NPS Peak Hour Interactions OMNI shall consistently enable the number of NPS interactions (including IWP interactions, reports and interface interactions) to be executed in an hour specified in the Statement of Volumetric Requirements [8]

NFR4731 6.3.11 NOMIS Database Capacity The NCDS shall provide a NOMIS database capable of scaling to the size specified in the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4732 6.3.12 MIS Database Capacity The NCDS shall provide a MIS database capable of scaling to the size specified in the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4733 6.3.13 NOMIS Access by HMPS users NOMIS shall enable the total number of HMPS users specified in the Prison-NOMIS Statement of Volumetric Requirements [5] to access NOMIS

NFR4734 6.3.13.1 NOMIS Access by HMPS/NPS users NOMIS shall enable the total number of HMPS and NPS users specified in the Statement of Volumetric Requirements [8] to access NOMIS

NFR4735 6.3.14 HMPS Report Printing Quantum shall enable the printing of reports of the volume, size and frequency specified in the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4736 6.3.15 NOMIS Helpdesk The EDS Request Management Centre shall be able to handle the volume of NOMIS related calls from both HMPS and NPS users specified in the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4737 6.3.16 NOMIS Access by AT Users OMNI shall enable the total number of NPS AT users specified in the Statement of Volumetric Requirements [8] to access NOMIS


NFR4738 6.3.17 IWP Document Support OMNI shall enable the generation and printing of IWP documents of the volume, size and frequency specified in the Statement of Volumetric Requirements [8]

NFR4739 6.3.18 NPS Reports OMNI shall enable the printing of reports of the volume, size and frequency specified in the Statement of Volumetric Requirements [8].

NFR4740 6.3.19 Scalability of design The NCDS shall be capable of expansion to double the number of Users and locations and for up to double the number of concurrently logged-on Users specified in the Prison-NOMIS Statement of Volumetric Requirements [5].

NFR4741 7 Data Management

NFR4742 7.1 Data Migration Facilitate the migration of data from legacy systems. This phase includes the cleansing, extraction, data transformation and eventual upload of data into the TAG database. Note data cleansing is being performed by the business users of the legacy application

NFR4743 7.1.1 IIS Migrate and transform data from the HMPS IIS legacy system into NOMIS.

NFR4744 7.1.2 LIDS Migrate and transform data from the HMPS LIDS legacy system into NOMIS.

NFR4746 7.1.3 P2Lifers Migrate and transform data from the HMPS P2Lifers legacy system into NOMIS.

NFR4745 7.1.4 IRS Migrate and transform data from the HMPS IRS legacy system into NOMIS.

NFR4747 7.1.5 A&O Migrate and transform data from the HMPS Accommodation and Occupancy legacy systems into NOMIS.

NFR4748 7.1.6 Mother and Baby Migrate and transform data from the HMPS Mother and Baby legacy system into NOMIS.

NFR4749 7.1.7 Regmon Migrate and transform data from the HMPS Regmon legacy system into NOMIS.

NFR4750 7.1.8 Geebis Migrate and transform data from the HMPS Geebis legacy system into NOMIS.

NFR4751 7.1.9 HMPS Durham Applications Migrate and transform data from the HMPS Durham Applications into NOMIS.

NFR4752 7.1.10 Data Cleansing Provide tools, proposals to assist with data cleansing prior to migration.

NFR4753 7.1.11 NPS Data Migration Migrate and transform data from NPS areas

NFR4754 7.1.11.1 NPS Data Migration Migrate and transform data from NPS Areas as follows: PROBIS (Thames Valley) - FoxPro.

NFR4755 7.1.11.2 NPS Data Migration Migrate and transform data from NPS Areas as follows: DELIUS (Manchester) - Delphi.

NFR4756 7.1.11.2.1

NPS Data Migration Pathfinder is used by Gtr Manchester area as its equivalent of IAPS (Accredited Programmes data).


NFR4757 7.1.11.2.2

NPS Data Migration A Lotus Notes Programmes Booking system used by Cheshire as its equivalent of IAPS Accredited Programmes.

NFR4758 7.1.11.2.3

NPS Data Migration A Lotus Notes Database used by Dorset to hold data on Contacts as they do not use this CRAMS functionality.

NFR4759 7.1.11.2.4

NPS Data Migration West Midlands uses CATO as its Case Managerment System but has archived some Offender information into anther CATO system in order to improve performance. The archive database is a different structure to the Main CATO CMS.

NFR4760 7.1.11.2.5

NPS Data Migration An MS-Access Community Services system in Essex to hold data on CP Allocations, CP Attendances and CP Assessments because Essex do not use this CRAMS functionality.

NFR4761 7.1.11.3 NPS Data Migration Migrate and transform data from NPS Areas as follows: ICMS (Avon & Somerset, Devon & Cornwall, Kent, Norfolk, Suffolk, Cambridgeshire, Bedfordshire, East Sussex) - Visual Basic, SQL Server.

NFR4762 7.1.11.4 NPS Data Migration Migrate and transform data from NPS Areas as follows: CATO (West Midlands) - Lotus Notes.

NFR4763 7.1.11.5 NPS Data Migration Migrate and transform data from NPS Areas as follows: IOSS (West Mercia) - Axiant Powerhouse.

NFR4764 7.1.11.6 NPS Data Migration Migrate and transform data from NPS Areas as follows: CRAMS (31 other Areas) - Oracle.

NFR4765 7.1.11.7 NPS Data Migration Essex holds contact log information in MS Word format, which they rely heavily on instead of using CRAMS functionality. Will need to develop solution similar to other WPI docs which will require links to be migrated.

NFR4766 7.1.11.8 NPS Data Migration Migrate and transform data from NPS Areas as follows: IAPS (Merseyside) - Lotus Notes.

NFR4767 7.1.11.9 NPS Data Migration Include Disability Data in migration from NPS sources

NFR4768 7.1.11.10

NPS Data Migration Additional NPS data is to be migrated.

NFR4769 7.1.11.11

NPS Data Migration Scope Change scope of Offenders and data selected for NPS data migration as follows:- High Risk Offenders - full migration of all case management data- Active/Recently Active Offenders - full migration for all orders active since 01/04/05 and summary details for earlier orders- Offenders Inactive since 01/04/05 - migrate summary details onlyThis means at least summary details are migrated for all Offenders within the 6 year data retention period for NPS areas

NFR4770 7.1.12 Reference Data Maintenance Provide the facility to upload reference data on to the NCDS.

NFR4771 7.1.13 Data Migration Timescales The process of scheduled migration of data from HMPS establishments to the NCDS shall only take place between the times of Saturday 24:00 to 06:00 Sunday, which is within the batch window duration of Saturday 24:00 to 09:00 Sunday. Sufficient time must be allowed during this "migration window" to allow the back-out of any failed migration.


NFR4772 7.1.13.1 Data Migration Timescales - No Loss of Service

Data Migration is not to result in the loss of service to HMPS establishment, HQ sites or other locations Prison-NOMIS is accessed from (as defined in the Prison-NOMIS Statement of Volumetrics [5]) as defined for the Service Window agreed in the NOMIS SLAs

NFR4773 7.2 Data Protection Act The NOMIS system and its associated procedures must be compliant with the Data Protection Act (DPA). This is defined by the NOMIS DPA Policy Document.[7]

NFR4774 7.3 Data Policy Data Policy System Requirements. The requirements in this section are based on the requirements originally specified in the Data Policy [7]. It should be noted that the requirements covering data retention and archiving vary from those specified in the NOMIS SLR [2].

NFR4775 7.3.1 Automated Access Reports The System must be capable of producing automated reports that contain the information to allow the Prison-NOMIS Live Service ISMT to ensure that appropriate authorisation supports all Authorised User account changes; review alerts to failed access attempts (logons, attempting to access fields/objects that they are not permitted to access);· review of assignment of Authorised Users to roles;· amendments of the role group access rights etc.

NFR4776 7.3.2 Automated Authorisation Reports The system shall produce automated reports containing the information to allow the Prison-NOMIS Live Service ISMT to ensure that appropriate authorisation supports all Authorised User account changes

NFR4777 7.3.3 Automated Access Alert Reports The system shall produce automated reports containing the information to enable the Prison-NOMIS Live Service ISMT to review the audit/accounting log records of failed access attempts (logons, attempting to access fields/objects that they are not permitted to access);

NFR4778 7.3.4 Automated User Role Reports The system shall produce automated reports containing the information to allow the Prison-NOMIS Live Service ISMT to review of assignment of Authorised Users to roles

NFR4779 7.3.5 Automated Group Role Reports The system shall produce automated reports containing the information to allow the Prison-NOMIS Live Service ISMT to review amendments of the role group access rights etc

NFR4780 7.3.6 Protection of Auditable Fields The NOMIS Application contains numerous free form text fields. Where the Business Requirements dictate that data entered in to these fields is of auditable significance, the data entered in to these free form text fields shall be protected and the Authorised Users will only be able to add data to the data already entered (i.e. any data present cannot be over-written).

NFR4781 7.3.7 Automated Application of Global Changes

NOMIS shall support automated methods using scripts to apply global changes to the NOMIS database and common changes to a significant number of Offender and/or Victim records. These changes will be conducted under the NOMIS management control process. These updates must be auditable.

NFR4782 7.3.8 Control of Imported Data All imports of data from other systems shall be performed under NOMIS management control with proven methods to perform database roll-backs/recoveries if required. This should exclude reference data loads and agreed interface file/data loads which should be updates through standard procedures. However these updates need to be auditable and reversible.

NFR4783 7.3.9 Protection of NOMIS Data when using MIS

Whilst using an external reporting tool, the Authorised User shall not be able to access NOMIS Information that they are not permitted to access within NOMIS. The MIS reporting mechanism shall reflect the Role Based Access that Authorised Users hold


NFR4784 7.3.10 Authentication of Additional Tools Any additional tools or products that are used to access NOMIS Information shall adhere to the authentication mechanism that TAG has implemented Additional tools will need to be assessed for compliance at time of proposal.

NFR4785 7.3.11 Use of NOMIS Data by Additional Tools

Any application, infrastructure component or tool that is used against NOMIS shall at most only create temporary copies of NOMIS Information within NOMIS Itself. It shall only extract the NOMIS Information or create a view of it. Any temporary tables or files that are created as part of this process through application or infrastructure solution components shall be deleted once the process has finished. End user created files created outside the NOMIS are excluded from this process.

NFR4786 7.3.12 Classification Advice to Users Before an Authorised User successfully logs onto the NOMIS application, they shall be advised that they are accessing a RESTRICTED system and they must abide with the User Security Operating procedures that will be produced as part of the Accreditation of NOMIS

NFR4787 7.3.13 Implementation of Retention Policy The system shall use technical measures to implement the retention policy (as described in C-NOMIS Data Policy [6]) without requiring any Authorised User to manually delete records (except in exceptional circumstances authorised by the NOMIS Data Controller) Note: This NFR applies to all data i.e. C-NOMIS, MIS, Audit.

NFR4788 7.3.14 Retention of Lifer Data The system shall retain all data relating to Lifers for 99 years in its entirety where the 99 years is from the initial creation of the offender record

NFR4789 7.3.15 Retention of Offender Data The system shall retain all data relating to offenders other than Lifers for 10 years in its entirety from Sentence Expiry Date (SED)

NFR4790 7.3.16 Archive of Offender Data For all offenders other than Lifers, the system shall after 10 years from Sentence Expiry Date (SED)continue to retain the core Offender Data within the NOMIS application and the Offender Archive Data and Victim Archive Data will be archived to an appropriate media. The definition of the core Offender Data is given in the NOMIS Data Policy. This process will be performed using an automated method that will copy the records to the new location, verify the copy and if the copy was successful, delete the appropriate fields from the on-line database

NFR4791 7.3.17 Deletion of Offender Data For all offenders other than Lifers, the system shall after 99 years from Sentence Expiry Date (SED) delete all offender data as per the NOMIS Data Policy [6]

NFR4792 7.3.18 Retention Media The medium that will be used to store Offender Archive Data and Victim Archive Data shall either be capable of retaining the data (i.e. media Integrity) for the period of time as specified within the retention requirements or provisions shall be made to ensure that the data is copied to fresh media as and when necessary (in conformance with the manufacturers guidelines).

NFR4793 7.3.19 Archive Log A detailed archival log shall be produced that provides information relating to which Offender records have been archived and on what media (i.e. media identification) they have been archived to


NFR4794 7.3.20 Restoration of Offender Data When an Offender re-enters the Rehabilitation System, their archived records shall be restored from the backup media. The restore process shall restore the archived records into the on-line database against the Offenders Basic record information and any associated/linked offender data i.e. victim data. Once the archived record has been restored, the backed up record shall be deleted to ensure that it complies with the Data Protection Act's requirement for Personal Data Accuracy (4th Principle).

NFR4795 7.3.21 Performance of Restoration Process All restored records shall be restored into the NOMIS database within 24 hours of the request being made by a NOMIS user or being notified through electronic means such as the Police interface.

NFR4796 7.3.22 Removal of Data from Stand-Alone Systems

There are instances - mainly investigations - whereby there shall be a requirement to restore Offender data to a standalone system. The restore may relate to any number of Offender records. Controls shall be in place to restrict access to this standalone system and the data stored on it. Once the requirement to hold the NOMIS Information on the stand alone machine expires the information shall be cleared off the stand alone machine in accordance with the HMG guidelines pertaining to secure erasure of data and the detailed Code of Practise in this respect

NFR4797 7.3.23 Authorisation to Restore Archives System Administrators shall be the only people that are be capable of restoring the archived information

NFR4798 7.3.24 Protection of Offender Records There shall be no circumstances whereby an Authorised User can delete an Offender's record within NOMIS

NFR4799 7.3.25 Update of NOMIS Data Authorised Users shall not be capable of updating NOMIS Information without using the NOMIS Application

NFR4800 7.4 Archive Archive

NFR4801 7.4.1 Archive Facility Provide an archive facility that will allow historical non-core offender data to be stored and recovered as defined in the NOMIS Data Policy and NOMIS DPA Policy documents. Archiving is to be an automatic process which is time driven. Archived data will be restored based upon application driven event(s).

NFR4802 7.4.2 Archive With the exception of Lifers, NOMIS shall archive non-core Offender Data and associated non-offender data 10 years after the sentence expiry date of the Offender to which the data is associated.

NFR4803 7.4.3 Archive Restoration NOMIS shall enable a user to request the restore of offender records from the archive store to the NCDS within 24 hours of the request being made.

NFR4804 7.4.4 Retention Retain historical records for a period defined in the documents Data Policy[6] and DPA[7]

NFR4805 8 Interfaces

NFR4806 8.1 Non-System Interfaces Non-System Interfaces

NFR4807 8.1.1 Interface to Mobile Devices Allow integration of mobile devices such as Personal Digital Assistants (PDAs).

NFR4808 8.1.2 Application Support for Biometric Devices

Enable c-NOMIS application to capture biometric information from a digital camera through the Quantum desktop.


NFR4809 8.1.2.1 Biometric Interface [redacted]

NFR4810 8.1.3 Package Support Provide the capability to work with such versions of MS Office (Word, Excel & Outlook), JAWS, Dragon, TextHelp Read and Write, and Zoomtext as may from time to time be utilised by the organisation under Quantum.

NFR4811 8.1.4 Infrastructure Support for Biometric Devices

Quantum shall enable biometric information to be captured from peripherals using [redacted] as defined in the NOMIS Biometrics Requirements Clarification for R1.0e [12].

NFR4812 8.1.4.1 Infrastructure Support for Biometric Devices

Quantum shall enable the connectivity of a digital camera [redacted] with the capability to capture a JPEG images.

NFR4813 8.2 System to System Interfaces System to System Interfaces

NFR4814 8.2.1 External Interface Standards Support appropriate interface standards.

NFR4815 8.2.2 External Interface Capability External Interface Capability

NFR4816 8.2.2.1 OASys Interfaces Prison-NOMIS shall interface data with the legacy HMPS OASYS system, emulating the current LIDS / OASYS interface functionality.

NFR4817 8.2.2.2 OASys Interfaces Transfer data between HMPS OASys and NPS e-Oasys systems

NFR4818 8.2.2.3 Data Share System / OFFLOC Interface

The NOMIS application shall interface data with both the OFFLOC and Data Share System as per the Interface definition defined in [14]. This interface should be a single interface to meet the needs of both systems. Scheduling of the creation and interfacing of the data file should meet the needs of both systems.

NFR4819 8.2.3 Interface Standards Provide capability to support interfaces with external systems using data definitions mandated by the UK electronic Government Interoperability Framework, and the UK Criminal Justice IT (CJIT) organisation. These standards are applicable to all system Interfaces other than current legacy interfaces.

NFR4820 8.2.4 XML Data Exchange Provide capability to participate in data exchanges with external systems in a predefined manner and where preferred transports utilise XML.

NFR4821 8.2.5 Non-XML Data Exchange Provide the generic capability to interface with legacy systems, third-party systems and provision of transitional interfaces in non-XML format.

NFR4822 8.2.6 Transparency of Interfaces The interface process shall be automated and shall be transparent to the users

NFR4823 8.2.7 Transaction Logging NOMIS shall record the status of data imports in a system logfile which will contain details of all successful and unsuccessful transactions.


NFR4824 8.2.8 Integrity of Data Imports The NOMIS service provider shall ensure that all data has been correctly imported and applied and that both data and business integrity of the Application is maintained. Any exceptions shall be followed up in accordance with the Code of Connection that relates to the transfer

NFR4825 8.2.9 Encryption of Exported Data NOMIS shall encrypt any NOMIS Information that is sent outside of the GSI Community. Encryption products used must be compliant and/or approved under CESG HMG Infosec Standards 4: Communications Security and Cryptography (Part 1 - Management of Cryptographic Systems) for handling RESTRICTED data in non-RESTRICTED environments.

NFR4826 8.2.10 CoCo Compliance All NOMS Organisation (e.g. Contracted out Prisons, Third Party Providers) that wish to access NOMIS shall sign and comply at all times with the NOMIS CoCo

NFR4827 8.2.11 Audit of Connections The Prison-NOMIS Live Service ISMT shall retain the right to and will actively audit all connections to ensure that they are compliant with the CoCo

NFR4828 9 Infrastructure

NFR4829 9.1 Existing infrastructure Quantum must enable the NOMIS application to operate within the Quantum infrastructure.

NFR4830 9.1.1 Existing infrastructure Quantum and OMNI must enable the NOMIS application to operate within the Quantum and OMNI infrastructures respectively.

NFR4831 9.2 Infrastructure Compatibility NOMIS application to operate within the constraints imposed by the infrastructures.

NFR4832 9.3 Desktop Operate with the following minimum desktop specification:- resolution = 1024 x 768.

NFR4833 9.4 Infrastructure Security Operate within, and conform to the requirements of, an infrastructure accredited to handle UK Government RESTRICTED data. Accreditation standards are defined within CESG HMG Infosec Standards 2: Risk Management and Accreditation of Information Systems.

NFR4834 9.5 NOMIS Compatibility The NCDS shall enable a user to access the NOMIS application via the Quantum and OMNI infrastructures.

NFR4835 9.6 Quantum Compatibility Quantum shall enable an HMPS user to access the NOMIS application from a desktop unit in an HMPS establishment, HQ sites or other locations Prison-NOMIS is accessed from (as defined in the Priosn-NOMIS Statement of Volumetrics [5]) .

NFR4836 9.7 OMNI Compatibility OMNI shall enable a NPS user to access the NOMIS application from a WBT in a NPS area office.

NFR4837 9.8 Impact of MIS on NOMIS at the NCDS

During normal operation (ie periods when disaster recovery is not being used), the NCDS shall ensure that activity associated with the MIS at the NCDS has no impact on the performance and availability of the on-line NOMIS Service at the NCDS.

NFR4838 9.9 MIS Existing infrastructure Quantum must enable the MIS application to operate within the Quantum infrastructure.

NFR4839 9.9.1 MIS Existing infrastructure Quantum and OMNI must enable the MIS application to operate within the Quantum and OMNI infrastructures respectively.

NFR4840 9.10 MIS Infrastructure Compatibility The MIS application shall operate within the constraints imposed by the infrastructures.


NFR4841 9.11 MIS Desktop The MIS system shall operate with the following minimum desktop specification:- resolution = 1024 x 768.

NFR4842 9.12 MIS Infrastructure Security The MIS system shall operate within, and conform to the requirements of, an infrastructure accredited to handle UK Government RESTRICTED data.

NFR4843 9.13 MIS NCDS Compatibility The NCDS shall enable an Authorised User to access the MIS application via the Quantum and OMNI infrastructures.

NFR4844 9.14 MIS Quantum Compatibility Quantum shall enable an HMPS Authorised User to access the MIS application from a desktop unit in an HMPS establishment, HQ sites or other locations Prison-NOMIS is accessed from (as defined in the Priosn-NOMIS Statement of Volumetrics [5]) .

NFR4845 9.15 Copy to/from Removable Media Quantum shall enable a Quantum User who is authorised to copy files between NOMIS and any drive enabled on a Quantum PC or File Server that is accessible to an authorised Quantum User. This is to support local systems such as 4x4 and 5x5. The data to be copied should only be specific to that allowed under RBAC control, limited by CaseLoad and Role (i.e. limited to data within the establishment for that Role). This function must be auditable.

NFR4846 10 Accessibility

NFR4847 10.1 Change to Screen Definition Screen definitions should be capable of change to meet subsequently issued guidelines supporting accessibility. Screens should use prompts, labels, tool-tips, help text and to enable users to modify colour schemes, fonts and other formatting items as necessary.

NFR4848 10.2 Standard Windows AT services The system shall support all standard Windows AT services (such as changing colours and fonts) for Assistive support

NFR4849 10.3 Support Dragon Naturally Speaking The C-NOMIS Application shall support Dragon Naturally Speaking [redacted]

NFR4850 10.4 Support Zoomtext The C-NOMIS Application shall support Zoomtext [redacted]

NFR4851 10.5 Support JAWS v8 for Windows The C-NOMIS Application shall support JAWS [redacted]

NFR4852 10.6 Support TextHelp for Windows Applications

The C-NOMIS Application shall support TextHelp Read and Write Gold [redacted]

NFR4853 10.7 AT supported file outputs All file outputs from the C-NOMIS Application solution shall be in formats supported by Dragon Naturally Speaking [redacted], Zoomtext [redacted], JAWS [redacted] and TextHelp Read and Write Gold [redacted]

NFR4854 10.8 Support Web Content Accessibility Guidelines standard

The Applications SHOULD be compliant to the W3C Guidelines Priority 1 and MAY be compliant to Priority 2 guidelines as defined in the Web Content Accessibility Guidelines V2.0 (or higher)


NFR4855 10.9 Priority 1 W3C accessibility guidelines

The system should support all the Priority 1 checkpoints listed in the W3C LIST OF CHECKPOINTS FOR WEB CONTENT ACCESSIBILITY GUIDELINES V2.0 (or higher)

NFR4856 10.10 NOMIS Application compliance to W3C Web Content Accessibility Guidelines

The NOMIS Application shall be developed to be compliant to the W3C Web Content Accessibility Guidelines V2.0 (or latest version).

NFR4857 10.11 MIS Standard Windows AT services The MIS system shall support all standard Windows AT services (such as changing colours and fonts) for Assistive support

NFR4858 10.12 MIS Support Dragon Naturally Speaking v9

The MIS Application shall support Dragon Naturally Speaking [redacted]

NFR4859 10.13 MIS Support Zoomtext The MIS Application shall support Zoomtext [redacted]

NFR4860 10.14 MIS Support JAWS The MIS System shall support JAWS [redacted]

NFR4861 10.15 MIS Support TextHelp for Windows Applications

The MIS Application shall support TextHelp Read and Write [redacted]

NFR4862 10.16 MIS AT supported file outputs All file outputs from the MIS Application solution shall be in formats supported by Dragon Naturally Speaking [redacted], Zoomtext [redacted], JAWS [redacted]and TextHelp Read and Write Gold [redacted]

NFR4863 10.17 MIS Support Web Content Accessibility Guidelines standard

The MIS system shall support all the Priority 1 checkpoints and at least some of the priority 2 checkpoints defined in the existing ratified Web Content Accessibility Guidelines standard

NFR4864 10.18 Priority 1 W3C accessibility guidelines for MIS

The MIS system should support all the Priority 1 checkpoints listed in the W3C LIST OF CHECKPOINTS FOR WEB CONTENT ACCESSIBILITY GUIDELINES V2.0 (or higher)

NFR4865 10.19 MIS Application compliance to W3C Web Content Accessibility Guidelines

The NOMIS MIS Application should be developed to be compliant to the W3C Web Content Accessibility Guidelines V2.0 (or latest version).

NFR4866 11 Support & Maintenance

NFR4867 11.1 Client-side Deployment Allow deployment of any client-side NOMIS components via a software distribution package.

NFR4868 11.2 Support Provide on-line and telephone support as defined in the SLR.

NFR4869 11.3 Architecture Documentation Update Timeliness

The NCDS architecture documentation shall be maintained 1 month prior to any significant architecture change and approved by NOMS before the change is applied

NFR4870 11.4 MIS Client-side Deployment Allow deployment of any client-side MIS components via a software distribution package.


NFR4871 11.5 OMNI Urgent Updates OMNI shall provide a process for urgent updates to components of NOMIS installed on the OMNI infrastructure.

NFR4872 11.6 Quantum Urgent Updates Quantum shall provide a process for urgent updates to components of NOMIS installed on the Quantum infrastructure.

NFR4873 11.7 NCDS Urgent Updates The NCDS shall provide a process for urgent updates to components of NOMIS installed on the NCDS infrastructure.

NFR4874 11.8 OMNI Release Roll-back OMNI shall enable a System Administrator to restore the previous version of component of a new release installed on the OMNI infrastructure.

NFR4875 11.9 Quantum Release Roll-back Quantum shall enable a System Administrator to restore the previous version of component of a new release installed on the Quantum infrastructure.

NFR4876 11.10 NCDS Release Roll-back The NCDS shall enable a System Administrator to restore the previous version of a new release installed on the NCDS infrastructure.

NFR4878 11.11 Quantum Client-side Deployment Quantum shall enable only a System Administrator to deploy client-side NOMIS components on the Quantum infrastructure.

NFR4877 11.12 OMNI Client-side Deployment OMNI shall enable only a System Administrator to deploy client-side NOMIS components on the OMNI infrastructure.

NFR4879 11.13 OMNI Support OMNI shall provide on-line telephone support to NPS Users.

NFR4880 11.14 Quantum Support Quantum shall provide telephone support to HMPS Users.

NFR4881 11.15 NCDS Support The NCDS supplier shall provide on-line and telephone support to Business Users.

NFR4882 12 System Administration

NFR4883 12.1 System Administration Facilities System Administration Facilities

NFR4884 12.1.1 Monitor System Usage Provide system administration statistics as defined in the SLR (Capacity Measurement) as defined within CCN24-3

NFR4885 12.1.2 Monitoring Tools Provide monitoring tools to measure response times.

NFR4886 12.1.2.1 Monitoring Tools Provide monitoring tools to measure response times.

NFR4887 12.2 Help On-Line Help Facilities

NFR4888 12.2.1 On-line Help Enable application administrators to maintain Help Text.

NFR4889 12.2.1.1 On-line Help Implement the OnDemand Help System that provides online help facilities to the operational users of the NOMIS system from release 1.1 onwards.


NFR4890 12.2.2 Help Text Maintenance NOMIS shall enable an application administrator to edit the NOMIS application Help Text off-line such that the application need not be reinstalled to make the changes available to NOMIS users.

NFR4891 12.3 Service Providers Constraints related to services providers.

NFR4892 12.3.1 Service Provider Performance Monitoring

Provide aggregated management information on service provider performance (as defined within CCN24-2).

NFR4893 12.3.2 Service Management Reporting The NCDS provider shall include a table in NCDS Service Management Reports that shows the agreed Service Levels and the actual service levels as measured for the Service Measurement Period (SMP). The table shall present information as it applies to the NCDS. For the SMP covered by each report, the NCDS provider shall include NCDS statistics in the Service Management Report for the NCDS that include for the NCDS the information documented in section 14.3.1 of the NOMIS SLR v0.6

NFR4894 12.3.3 NCDS Maintenance Over-runs Where the time for planned maintenance is exceeded during a Service Window, any impact on delivery of the service shall be included in the service level measurements

NFR4895 12.3.4 NOMIS Service Unavailability When no Authorised Users are able gain access to the NCDS due to unavailability of the NCDS, the NCDS shall accrue Unavailability for 100% of the time that the failure situation persists. Desktop units associated with the NOMIS Service User community IS should not accrue downtime for this reason.

NFR4896 12.3.5 Service Management Report Timing Service Management Reports covering the NCDS shall be provided to NOMS by the NCDS provider for each Service Measurement Period (SMP) no later than 14 days after the end of the SMP. These reports shall be provided in electronic form and be capable of being printed by the NOMS recipient.

NFR4897 12.3.6 Quantum Service Management Reporting

In addition to the existing Quantum Service Management Reporting, the following statistics are expected to be provided by the respective IS providers under their reporting facilities so that, although provided, no NCDS-specific facility applies:a) Total calls to the relevant IS Help Desk that relate to NCDS;b) Average IS Help Desk response time to answer User calls;c) Performance measured at a User's desktop unit during the Service Window; this need only be provided where a Performance response time Incident has been reported to the Help Desk by a User and a response time measurement made..

NFR4898 12.3.7 OMNI Service Management Reporting

In addition to the existing OMNI Service Management Reporting, the following statistics are expected to be provided by the respective IS providers under their reporting facilities so that, although provided, no NCDS-specific facility applies:a) Total calls to the relevant IS Help Desk that relate to NCDS;b) Average IS Help Desk response time to answer User calls;c) Performance measured at a User's desktop unit during the Service Window; this need only be provided where a Performance response time Incident has been reported to the Help Desk by a User and a response time.

NFR4899 12.3.8 NCDS Performance measurement Provision shall be included for measurements of NCDS performance to be measured continuously within a N-minute window during each Hour with each N-minute measurement including:(a) The value of N;(b) Number of Interactions;(c) Number of responses at the NCDS within 1.00 seconds during the Hour;(d) Volume of data (bytes) received from Users;(e) Volume of data (bytes) sent back to Users, broken down by Client/Server for each server. Information is to be provided for each day of measurement.


NFR4900 12.3.9 Help Desk hours The NCDS Service provider shall provide a staffed NCDS Help Desk service for 24 hours every day

NFR4901 12.3.10 Incident categorisation Incidents reported to the NCDS Help Desk shall be categorised and resolved according to the table in the NOMIS SLR v1-1 section 11.3.1

NFR4902 12.3.11 Incident management documentation The NCDS provider shall provide documentation, preferably accessible on-line, which covers the subject of Incident management. Such documentation must include:(a) how Incidents are reported;(b) criteria for assigning Severity to an Incident;(c) how the duration of an Incident is measured including situations when the originator of the Incident cannot be contacted;(d) how Performance Incidents are dealt with;(e) escalation procedure;(f) how responsibility for an Incident is assigned (ie to the NCDS or to the relevant IS).

NFR4903 12.3.12 Ad-hoc service management reporting

Facilities shall be provided for Authorised Users to create ad-hoc reports that allow the NCDS statistics reported in the Service Management Report to be retrieved by those Users. The period (in hours) to be covered by each report will be as per parameters provided by the User

NFR4904 12.3.13 Ad-hoc specific incident report Facilities shall be provided for Authorised Users to request an Incident report that details the actions and consequences related to a single Incident

NFR4905 13 Release Management

NFR4906 13.1 Release Strategy Provide an acceptable strategy for future releases.

NFR4907 13.1.1 Urgent Updates Provide an acceptable strategy for urgent updates to NOMIS as defined in the SLR.

NFR4908 13.1.2 Release Roll-back Provide the ability to roll-back after the unsuccessful installation of a new release of NOMIS within a time period as defined by SLR.

NFR4909 13.2 Multiple Production Versions The system shall not support two or more versions in production simultaneously

NFR4910 13.3 ITIL Best Practice Release Management shall follow ITIL best practise procedures, including but not limited to Change Control Boards for NOMIS and Quantum and OMNI and Forward Schedules of Change

NFR4911 13.4 Release Scheduling The scheduling of releases shall be agreed by NOMS and HMPS in advance.

NFR4912 13.5 Software versions The system and its component sub-systems shall at all times be aligned in terms of software releases to ensure ease of maintainability and management e.g. xTag outbound server components nee to be at the same level of revision as xTAG in-bound and Data Migration.

NFR4913 13.6 Co-Ordination of Release Process A co-ordinated release process shall be implemented between the NCDS, OMNI and Quantum infrastructure providers and approved by NOMS

NFR4914 13.7 Release Process Agreement The release process shall be documented by the programme and formally agreed by the customer organisations and their IS suppliers


NFR4915 14 Configuration Management

NFR4916 14.1 Configuration Process All NOMIS Suppliers and the Systems Integrator shall supply approved (by the Authority) tools, processes and procedures for the configuration management of the NOMIS solution and the respective environments the application shall run in, which are to be jointly managed by the Authority and the Suppliers / Systems Integrator.

NFR4917 14.1.1 Configuration Process All NOMIS system integrators shall supply acceptable (to NOMS) tools, processes and procedures for the configuration management of the NOMIS application and the respective environments the application shall run in

NFR4918 14.2 Configuration Process Integration The configuration management tools, processes and procedures used by the Suppliers and Systems Integrator for the NOMIS solution must: - be integrated with each others tools, processes and procedures such that all configuration management functions are seamless, complete and accepted by the Authority - are to be jointly managed by the Supplier(s), Systems Integrator and the Authority during the development phases - are to be jointly managed by the Supplier(s), Systems Integrator and the Authority Live Services once the NOMIS Solution has been handed over to Live Services.

NFR4919 14.2.1 Configuration Process Integration 1. The configuration management tools, process and procedures used by the systems integrators must be integrated with each others tools, processes and procedures such that all configuration management functions are seamless, complete and accepted are to be approved by NOMS prior to the deployment and utilisation by any system integrator

NFR4920 15 Security

NFR4921 15.1 Authentication Authentication NFRs

NFR4922 15.1.1 Application Authorisation Authenticate all user attempts to launch the application or reporting facilities and refuse access to un-authorised users.

NFR4923 15.1.2 Auto Logoff Automatically log users off the screen following a period of inactivity requiring password input to reactivate. The inactivity period to be [redacted].

NFR4924 15.1.3 Provide Alerts Report to [redacted] failed attempts to access application as per security policy.

NFR4925 15.1.4 Password Monitoring NOMIS shall prevent a user from accessing the system if they have entered an incorrect password [redacted]. In this event NOMIS shall send an alert to [redacted].

NFR4926 15.1.5 RAS authentication Authorised Users accessing NOMIS via a remote access service shall be authenticated [redacted]

NFR4927 15.1.6 RAS authentication via Quantum Authorised Users accessing NOMIS via a Quantum remote access service shall be authenticated [redacted]

NFR4928 15.1.7 RAS authentication via OMNI Authorised Users accessing NOMIS via a OMNI remote access service shall be authenticated [redacted]


NFR4929 15.1.8 Remote user rights and auditing Remotely connected Authorised Users shall be given the same access rights and audited in the same fashion as Authorised Users of locally connected workstations

NFR4930 15.2 Access Control Access Control

NFR4931 15.2.1 Screen and Report Access Control Control access to the application screens and reports based on [redacted].

NFR4932 15.2.2 Single Sign-on The NOMIS application shall enable users signed on to the Quantum infrastructures to use the NOMIS application with their appropriate authorisation without an additional log on to the NOMIS application.

NFR4933 15.2.2.1 Transparent Sign-on Enable users to access any part of the Prison-NOMIS system without the need for repeated log-ins (specifically the Operational and MIS reporting sub-systems).

NFR4934 15.2.3 Access Maintenance Allow access rights to be changed, personnel to be removed and new personnel to be added to NOMIS by a suitably-authorised user subject to Security Policy through Application Screens only.

NFR4935 15.2.4 Data Access Control Allow control of access to the application data based on vertical (hierarchical) and multiple horizontal organisational arrangements, as well as functional needs as defined by the Security Role Model.

NFR4936 15.2.5 Authorised User Every individual Authorised User of NOMIS must have a unique identifier;

NFR4937 15.2.6 Offender Record Link to Location All Offender Records (other than offenders whose sentence has expired) must belong to a location, which in turn are linked to one or more Caseloads.

NFR4938 15.2.7 Simplicity of Operation The User Account Maintenance functions of Prison-NOMIS must be designed to allow maintenance of User Account functions in the shortest possible number of steps within each function. Basic tasks such as creating new Authorised User accounts, assigning Roles, creating new NOMIS Caseloads must be supported by screens and reports that allow [redacted] to carry out all functions for the largest establishment within the associated SLA for these business functions. Prison-NOMIS must support 'Template' Groups (as detailed within the Prison-NOMIS Role Based Access Control document [13]) so that when a new Authorised User account is being created and/or Roles are being applied, it is possible to base the Roles allocated to an individual on a pre-defined set.

NFR4939 15.2.8 Functions Assigned to Other Roles For operational reasons people may need to undertake functions which are assigned to other Roles - e.g. an NPS Enforcement Officer may need, on occasion, to undertake functions which a Court Worker normally undertakes. NOMIS must permit the granting of additional roles to Authorised users on a temporary basis, which is controllable by [redacted] This temporary access should be time controlled so that temporary access rights are revoked automatically by the system at the end of the temporary period.

NFR4940 15.2.9 Baseline Access Control NFRs The application must be compliant to the NOMIS Role Based Access Control Requirements

NFR4941 15.2.9.1 Ability to Perform Duties For the NOMIS Application Authorised Users must be capable of carrying out their authorised duties;

NFR4942 15.2.9.2 Access to Role Specific Data For the NOMIS Application Authorised Users must be able to view information that they need to see in order to perform their work;


NFR4943 15.2.9.3 Access to Data not Specific to Role For the NOMIS Application Authorised Users must not be capable of viewing NOMIS Information which they do not have a legitimate business need to know;

NFR4944 15.2.9.4 Write Access to Data Fields For the NOMIS Application Authorised Users must not be capable of writing to fields within NOMIS for which they do not have authorisation.

NFR4945 15.2.9.5 Sharing of NOMIS Information For the NOMIS Application the access control mechanism must be operationally practical and enable and facilitate sharing of NOMIS Information across NOMS Organisations in accordance the NOMIS Aims for Data Sharing;

NFR4946 15.2.9.6 Type of Access The NOMIS Application must control the type of access (view and/or update) that each type of role is allowed to carry out; such roles to be assigned to individual Authorised Users;

NFR4947 15.2.9.7 Segregation of Duties The NOMIS Application must be capable of enforcing constraints, such as segregation of duties, where there are business requirements for such separation of duties;

NFR4948 15.2.9.8 Management of Access Rights The NOMIS Application must be possible to grant and rescind access rights in a timely and efficient manner;

NFR4949 15.2.9.9 Role/Group Access Controls The access control mechanism must support the ability for Roles and Groups to be assigned to Authorised Users by [redacted];

NFR4950 15.2.9.10

Temporary Access Rights It must be possible to grant Authorised Users temporary or time limited access rights to perform duties whilst deputising for a colleague;

NFR4951 15.2.10 Audit of Access Rights

NFR4952 15.2.10.1

Audit of Access Rights - process [redacted] shall audit [redacted] that Authorised Users have accurate and up to date access permissions to NOMIS in accordance with Security / User Access Policy.

NFR4953 15.2.10.2

Audit of Access Rights - Application functions

The NOMIS application or System Integrator must provide a capability to enable the Business Management Group to carry out an audit of access rights and associated functions for ensuring security policy is being applied.

NFR4954 15.2.11 Authority to Grant Access Rights There must be internal processes in place to ensure that no Authorised User is assigned Roles and/or Caseloads without express Authority from [redacted].

NFR4955 15.2.12 Temporary Allocation of Role NOMIS must permit the granting of additional Roles to Authorised Users on a temporary basis. When these rights are granted [redacted] must set an end date beyond which these rights are no longer authorised.

NFR4956 15.2.13 Removal of Roles/Groups [redacted] revoked once they are no longer required.

NFR4957 15.2.14 Workflow Constraints The NOMIS application through workflows will ensure that no Officer verifies their own assessment even if they have supervisory rights.

NFR4958 15.2.15 Number of separate log ons Where possible, single log-on shall be provided with a maximum of two log-ons for any Quantum Users

NFR4959 15.2.16 Interconnect agreements Each IS provider will need to agree an Interconnect Agreement with NOMS to allow NCDS facilities to be available to Users of the IS


NFR4960 15.2.17 HMPS Interconnect agreement The HMPS shall agree an Interconnect Agreement with NOMS to allow NCDS facilities to be available to Users of Quantum

NFR4961 15.2.18 NPS Interconnect agreement The NPS shall agree an Interconnect Agreement with NOMS to allow NCDS facilities to be available to Users of OMNI

NFR4962 15.3 Protective Marking Protective Marking

NFR4963 15.3.1 System RESTRICTED The NOMIS application shall be accredited to store and process data up to the RESTRICTED classification under the HMG Protective Marking scheme.

NFR4964 15.3.2 Operations RESTRICTED The NOMIS application shall be accredited to store and process data up to the RESTRICTED classification under the HMG Protective Marking scheme.

NFR4965 15.3.3 OMNI/OMNI Restricted accreditation The OMNI Networks shall be accredited to handle RESTRICTED information before the NOMIS Application can be run on OMNI

NFR4966 15.3.4 Select protective marking level The Protective Marking associated with each report shall be defined as a parameter so that the Authorised User is able to choose from a range of pre-defined Protective Markings at the time the report is generated, but each report must have a default Protective Marking associated with it, so if no selection is made the report will still show the default marking.

NFR4967 15.3.5 Protective marking in MS Word The facility to export information to the word processing facility shall include the ability to create headers and footers in the word processing package showing the Protective Marking of the information being exported

NFR4968 15.3.6 Protective marking in ad-hoc reports Reports generated using the MIS ad-hoc reporting tool shall show the Protective Marking of the information contained on the report

NFR4969 15.3.7 Overall classification level NOMIS shall only be required to handle information with a Protective Marking of RESTRICTED or lower

NFR4970 15.4 Security Monitoring Security Monitoring

NFR4971 15.4.1 Audit failed log on attempts The system shall capture audit information for all failed attempts to log-on to NOMIS

NFR4972 15.4.2 Viewing flagged records The system shall produce an audit record whenever a [redacted] flagged record is viewed using identified screens

NFR4973 15.4.3 SR2 The system shall reveal in the audit logs a unique identification (ID), e.g. the ID of the individual or process performing a function [redacted] (SR2)

NFR4974 15.4.4 SR3 The system shall reveal in the audit logs the date and time of an event or function or series of related functions (SR3)

NFR4975 15.4.5 SR4 The system shall identify in the audit logs the physical or logical address (or both) where the function took place [redacted]. (SR4)

NFR4976 15.4.6 SR6 The system shall reveal in the audit logs the type of service being executed, [redacted]. (SR6)

NFR4977 15.4.7 SR7 The system shall identify in the audit logs the execution of privileged commands [redacted]. (SR7)


NFR4978 15.4.8 Reporting NOMIS security incidents All of the supporting organisations and third parties shall be contractually obliged to report any security incident that either directly relates to NOMIS or could impinge on the security of NOMIS to the NOMIS System Manager

NFR4979 15.4.9 Reporting OMNI NOMIS security incidents

Authorised Users in Probation Service shall inform the OMNI help desk of all security incidents

NFR4980 15.4.10 Reporting Quantum NOMIS security incidents

Authorised Users in HMPS shall inform the QUANTUM help desk of all security incidents

NFR4981 15.4.11 Reporting other NOMIS security incidents

Authorised Users in other organisations shall inform their local supporting organisation and escalate to the NOMIS Management Support Group all security incidents. Incidents reported by third parties shall be reported by the NOMIS System Manager in accordance with the procedures set out by UNIRAS

NFR4982 15.4.12 Responsibility of reporting incidents The reporting of incidents that came from within NPS or HMPS shall continue to be the responsibility of their supporting organisations

NFR4983 15.5 Boundary Protection Boundary Protection

NFR4984 15.5.1 NOMIS [redacted] boundary protection

NOMIS shall have boundary protection mechanisms [redacted].




The system shall have boundary protection mechanisms [redacted]




NOMIS shall have boundary protection mechanisms [redacted]

NFR4989 15.5.6 [redacted] Firewall configuration [redacted] firewall [redacted] shall be configured to enable the NOMIS application to operate

NFR4990 15.5.7 Protection of information in transit across unclassified networks

Any connections that are made over the Internet, or other public networks, from NOMIS to other systems shall have the information encrypted to [redacted] level

NFR4991 15.5.8 Protection of RAS information in transit

Any RAS connections are made over the Internet, or other public networks, shall have the information encrypted to [redacted] level

NFR4992 15.5.8.1 Protection of RAS information in transit

Any RAS connections are made over the Internet, or other public networks, shall have the information encrypted to [redacted] level


NFR4993 15.5.9 Control of exchange of information TBD

NFR4994 15.5.10 Control of exchange of information with other CJOs

Exchanging information between NOMIS and other Criminal Justice Organisations (excluding the NPS or HMPS) shall be governed by an Interchange Agreement

NFR4995 15.5.11 Control of exchange of information with large non-CJOs

Exchanging information between NOMIS and large non-CJOs shall be governed by an Interchange Agreement

NFR4996 15.5.12 Control of exchange of information with non-CJOs

Exchanging information between NOMIS and non-CJOs shall be governed by an Interchange Agreement and/or a Code of Connection

NFR4997 15.5.13 Exchanging information on media Exchange of information [redacted] shall be carried in accordance with the procedures set out in Control and Carriage of Protectively Marked Assets as defined by PSO9010

NFR4998 15.5.13.1

Exchanging information on media Exchange of information [redacted] shall be carried in accordance with the procedures set out in Control and Carriage of Protectively Marked Assets

NFR4999 15.6 Security Administration Security Administration

NFR5000 15.6.1 User Security Operating procedures Authorised Users shall abide with the User Security Operating procedures produced as part of the Accreditation of NOMIS

NFR5001 15.6.2 Password Policy The system shall enforce the password policies defined in the Security Architecture v1.0 section 8.3.2 and as required by the NOMIS Password Management Policy [9]

NFR5002 15.6.3 Authorised User Account Administration

The system shall [redacted] to create new accounts on NOMIS, define/update the roles these accounts can carry out and suspend/delete accounts when no longer required via application screens

NFR5003 15.6.4 NCDS Physical Security The NCDCs shall have physical security at the same level as enforced already by the Probation or Prison Services

NFR5004 15.6.5 NCDS temporary file deletion The infrastructure upon which NOMIS runs shall delete any temporary file [redacted] used by the NOMIS Application.

NFR5005 15.6.6 Quantum temporary file deletion Quantum shall delete any temporary file [redacted] used by the NOMIS Application

NFR5006 15.6.7 OMNI temporary file deletion OMNI shall delete any temporary file [redacted] used by the NOMIS Application


NFR5007 15.6.8 Database security documentation The following topics are to be documented (and approved/assured) as Database Security Implementation document deliverable, covering how Database Security (and its back-ups) is designed and implemented in the NOMIS Application.- Physical Security- Network Security- Operating System Security- Database File Security- Server Registry Security- Isolation of Services Security- Database Server Service Accounts Security- Authentication Security- Database Server Login Accounts Security- Permissions Security- Database Server Password Security- Database Server Role Security- Linked/Remote Server- DTS Security- Database Server Replication Security- Database Server Cross-Database Ownership Chaining- Auditing- Service Packs and Patch Security- Miscellaneous Security

NFR5008 15.6.9 ITIL planning The Business Continuity Planning and Contingency Plans shall be constructed on the basis of the advice contained in ITIL Service Support documentation

NFR5009 15.6.10 Password Reset Provide a facility to reset the NOMIS user passwords.

NFR5010 15.6.10.1

Password Reset Where an initial password is set up for a user by [redacted] (i.e. an initial password or password reset), the user shall be forced to change this password on first logon. for NOMIS, but only following entry of their current password

NFR5011 15.6.11 Access Rights Provide a facility to add, delete and change authorised NOMIS users and their access rights.

NFR5012 15.7 MIS Security MIS Security

NFR5013 15.7.1 MIS System RESTRICTED The MIS application shall be accredited to store and process data up to the RESTRICTED level, under the HMG Protective Marking scheme.

NFR5014 15.7.2 MIS Operations RESTRICTED The MIS application shall be accredited to store and process data up to the RESTRICTED level, under the HMG Protective Marking scheme.

NFR5015 15.7.3 MIS Password Policy The MIS system shall enforce the password policies defined in the Security Architecture v1.0 section 8.3.2

NFR5016 15.7.4 MIS Authorised User Account Administration

The system shall allow [redacted] to create new accounts on MIS, define/update the roles these accounts can carry out and suspend/delete accounts when no longer required via application screens


NFR5017 15.7.5 MIS [redacted] Firewall configuration The [redacted] firewall software [redacted] shall be configured to enable the MIS application to operate

NFR5018 15.7.6 Protection of MIS information in transit

Any connections that are made over the Internet, or other public networks, from MIS to other systems shall have the information encrypted as defined within CESG HMG Infosec Standards 4: Communications Security and Cryptography (Part 1 - Management of Cryptographic Systems) for handling RESTRICTED data in or across non-RESTRICTED environments.

NFR5019 15.7.7 Protective marking from MIS in MS Word

The facility to export information from MIS to the word processing facility shall not prevent the ability to create headers and footers in the word processing package showing the Protective Marking of the information being exported

NFR5020 15.7.8 MIS RAS authentication Authorised Users accessing MIS via a remote access service [redacted]. RAS is provided as per the Quantum IS.

NFR5021 15.7.9 MIS RAS authentication via Quantum Authorised Users accessing MIS via a Quantum remote access service [redacted]. RAS would be via the existing Quantum service

NFR5022 15.7.10 MIS RAS authentication via OMNI Authorised Users accessing MIS via a OMNI remote access service [redacted]. RAS would be via the existing OMNI service

NFR5023 15.7.11 Reporting MIS security incidents All of the supporting organisations and third parties shall be contractually obliged to report any security incident that either directly relates to MIS or could impinge on the security of MIS to the NOMIS System Manager

NFR5024 15.7.12 MIS Overall classification level MIS shall only be required to handle information that has been given a Protective Marking of RESTRICTED

NFR5025 15.7.13 MIS [redacted] There shall be procedures [redacted] MIS

NFR5026 15.7.14 MIS [redacted] There shall be procedures [redacted] MIS

NFR5027 15.7.15 MIS Web Portal access control Access Control to the Web portal shall be through an approved authentication mechanism

NFR5028 15.7.16 MIS Report approval An approval procedure shall be implemented to ensure that reports that are to be published on the web portal have been sanctioned prior to their release

NFR5029 15.7.17 MIS Access Maintenance Allow access rights to be changed and new personnel to be added to MIS [redacted] subject to Security Policy through Application Screens only.

NFR5030 15.7.18 MIS Authorised User Every individual Authorised User of MIS must have a unique identifier

NFR5031 15.7.19 MIS ease of management MIS must be designed to make its operation as simple as possible for the majority of activities to be carried out. Basic tasks such as creating new Authorised User accounts must be supported by screens and reports that make such actions simple to conduct

NFR5032 15.7.20 MIS RBAC The MIS Role Based Access Control mechanism must provide access control to the MIS Data in alignment with C-NOMIS RBAC

NFR5033 15.7.21 MIS Local Application Administration The MIS access control mechanism must support the ability for Roles and Groups to be assigned to Authorised Users by [redacted];


NFR5034 15.7.22 MIS temporary access rights It must be possible to grant MIS Authorised Users temporary or time limited access rights to perform duties whilst deputising for a colleague;

NFR5035 15.7.23 MIS role audit [redacted] shall regularly audit to ensure that Authorised Users have accurate and up to date access permissions to MIS in accordance with this Policy.

NFR5036 15.7.24 MIS roles/groups removal Procedures shall be implemented to ensure that MIS Roles and/or Groups have been removed when they are no longer required.

NFR5037 15.7.25 MIS Auto Logoff Automatically log Authorised Users off the MIS screen following a period of inactivity requiring password input to reactivate. The inactivity period [redacted].

NFR5038 15.7.26 Provide MIS Alerts Report to [redacted] to failed attempts to access the MIS application as per security policy.

NFR5039 16 Accounting & Auditing

NFR5040 16.1 MIS Auditing MIS Auditing

NFR5041 16.1.1 Audit failed MIS log on attempts The system shall audit all failed attempts to log-on to MIS

NFR5042 16.1.2 MIS Audit Authority Levels MIS shall log all system administrative activities with sufficient detail to identify the change that has been made and who made the change. MIS shall automatically generate an audit report.

NFR5043 16.1.3 MIS Audit Backup and Recovery MIS shall enable [redacted] to backup and restore audit data in equivalent manner to backup and restore of NOMIS data.

NFR5044 16.1.4 MIS Audit Archive MIS shall enable [redacted] to archive audit data when not held online and retain the data for up to six years or more.

NFR5045 16.1.5 MIS Audit Archive Recovery MIS shall enable [redacted] to recover archived audit data.

NFR5046 16.1.6 MIS Log On Auditing MIS shall audit log on to the application by an Authorised User

NFR5047 16.1.7 MIS Log Off Auditing MIS shall audit log off from the application by an Authorised User

NFR5048 16.1.8 MIS Abnormal Exit Auditing MIS shall audit abnormal Authorised User exit from the application due to terminal switched off or killed by administrator

NFR5049 16.1.9 MIS Timeout Auditing MIS shall audit Authorised User exit from the application due to timeout

NFR5050 16.1.10 MIS Override Prompt Auditing MIS shall audit when an Authorised User overrides a prompt

NFR5051 16.1.11 MIS Password Monitoring NOMIS shall prevent an Authorised User from accessing the system if they have entered an incorrect password [redacted]. In this event MIS shall send an alert to [redacted] Ad-Hoc users excluded from the scope of this NFR.


NFR5052 16.1.11.1

MIS Password Monitoring - [redacted] NOMIS shall prevent [redacted] from accessing the system if they have entered an incorrect password [redacted]. In this event MIS shall send an alert to [redacted].

NFR5053 16.1.12 MIS Time Stamp Correlation MIS shall enable time stamps in audit logs to be correlated with the different major components within the network

NFR5054 16.1.13 MIS Audit Retention MIS audit data shall be held online for 2 months and then on other archived media for 2 years.

NFR5055 16.1.14 MIS Update of Log Files MIS shall enable [redacted] to carry out administration tasks on any of the log files or audit tables that are produced by the MIS application following written authorisation of the Data Controller

NFR5056 16.1.15 MIS Access to Log Files MIS shall prevent [redacted] from deleting or amending the contents of the log files/audit tables

NFR5057 16.1.16 MIS Access Control of Log Files MIS shall enable read-only access of the Audit Log. [redacted]

NFR5058 16.1.17 MIS Retention of Log Files MIS shall retain system/audit logs on-line for a period of two months from the time that the log file is created.

NFR5059 16.1.18 MIS Archiving of Log Files Two months after the creation of a log file, MIS shall archive and store the log file for two years. MIS shall delete the log file after two years of retention. During this two year retention period MIS shall enable [redacted] to restore the log file.

NFR5060 16.1.19 MIS Automatic Audit Report Generation

MIS shall provide an automated process that produces reports that relate to [redacted]. These reports shall be produced [redacted]

NFR5061 16.1.20 MIS audit details The MIS system shall record a) The details of any query run on the MISb) The person who ran the query/reportc) The date and time the query/report was run. It is not necessary to record the details of the records accessed as a result of the query having been run

NFR5062 16.2 Application Auditing Application Auditing

NFR5063 16.2.1 Author Audit Review NOMIS shall enable [redacted] to view audit log files to determine the author of any audited information entered on the NOMIS application.

NFR5064 16.2.2 Auditable Events NOMIS shall enable [redacted] to specify the following events for auditing:- All log-ons- All log-offs- All updates of access rights- All print operations- All updates to the NOMIS data (insert, update and delete)- updates of all system and application logs


NFR5065 16.2.2.1 Auditable Events - session timeouts and System Admin functions

NOMIS shall enable [redacted] to specify the following events for auditing:- All application session timeouts- system administration functions/logging

NFR5066 16.2.3 Audit Data Reporting NOMIS shall enable audit data to be reported on [redacted] whether they are on-line or have been archived. The facility must be provided to pull all audit data together into an audit 'investigation tool'. This encompasses the NOMIS audit logs / Quantum audit logs / NCDS audit logs

NFR5067 16.2.4 Audit Log On / Log Off Record user log on and log off actions, including failed logon attempts and report where failed log-ons exceed a pre-defined parameterised limit.

NFR5068 16.2.5 Content of Audit Logs NOMIS shall log all events specified by [redacted]. For each event logged NOMIS shall log the data specified by [redacted] together with the status (success or failure) of each event.

NFR5069 16.2.6 Audit Backup and Recovery NOMIS shall enable [redacted] to backup and restore audit data in equivalent manner to backup and restore of NOMIS data.

NFR5070 16.2.7 Unathorised Access to [redacted] NOMIS shall generate an audit report and send it to [redacted] if an unauthorised user attempts to access the records of a [redacted].

NFR5071 16.2.8 Unathorised Access to [redacted] NOMIS shall generate an audit report and send it to [redacted] if an unauthorised user attempts to access the records of [redacted].

NFR5072 16.2.9 Audit Data Storage Hold audit data online for 2 years.

NFR5073 16.2.10 Audit of Data Exchanges Interface data to be persisted for auditing purposes.

NFR5074 16.2.11 Time Stamp Correlation All servers and other equipment that provide a timestamp for auditable events on the NCDS and Quantum shall be synchronised to a common time source (GSi)

NFR5075 16.2.11.1

Time Stamp Correlation All servers and other equipment that provide a timestamp for auditable events on the NCDS, Quantum and OMNI/OMNI shall be synchronised to a common time source (GSi)

NFR5076 16.2.12 Update of Audit and Log Files NOMIS shall enable only [redacted] to carry out administration tasks on the log files or audit tables that are produced by the NOMIS application following written authorisation of the Data Controller

NFR5077 16.2.13 Access to Log Files NOMIS shall prevent all users [redacted] from accessing Audit log files.

NFR5078 16.2.14 Storage of Audit and Log Information The mechanism/facilities that are used to store the audit and log information shall be secure and resilient

NFR5079 16.2.15 Access Control of Log Files NOMIS shall enable read-only access of the Audit Log.

NFR5080 16.2.16 Retention of Log Files NOMIS shall retain system/audit logs and for the avoidance of doubt NOMIS Solution Accounting data on-line for a period of two years from the time that the log file and Accounting data is created.


NFR5081 16.2.17 Archiving of Log Files Two months after the creation of a log file, NOMIS shall archive and store the log file for two years at which point NOMIS shall delete the log file. During this two year period NOMIS shall enable an Application Administrator to restore the log file.

NFR5082 16.2.18 Automatic Audit Report Generation NOMIS shall provide an automated process that produces reports that relate to [redacted]. These reports shall be produced on a periodic basis and on ad-hoc request

NFR5083 16.2.19 [redacted] NOMIS shall audit the time, date and user Id when [redacted].

NFR5084 16.2.20 Data to be Audited NOMIS shall enable [redacted] to specify the following data for auditing:User IDDate and time of eventType of eventApplications usedWorkstation ID.

NFR5085 16.2.21 Audit Data Provision - Quantum Quantum shall provide upon request, in electronic format, the accounting data related to a security incident that is being investigated in relation to a NOMIS security or investigation event. This data shall include the information associated with the Quantum user logon and log-off events.

NFR5086 16.2.22 Audit Data Provision - OMNI OMNI shall provide upon request, in electronic format, the audit data related to a security incident that is being investigated in relation to a NOMIS security or investigation event. This data shall include the information associated with the OMNI user logon and log-off events.

NFR5087 16.2.23 Audit Data Provision - NCDS NCDS shall provide upon request, in electronic format, the audit data related to a security incident that is being investigated in relation to a NOMIS security or investigation event. This data shall include the information associated with the NCDS user logon and log-off events.

NFR5088 16.2.24 Audit Data Provision - NOMIS NOMIS Application shall provide upon request, in electronic format, the audit data related to a security incident that is being investigated in relation to a NOMIS security or investigation event. This data shall include the information associated with the NOMIS user logon and log-off events.

NFR5089 16.2.25 Audit Data Provision - NOMIS MIS NOMIS MIS Application shall provide upon request, in electronic format, the audit data related to a security incident that is being investigated in relation to a NOMIS security or investigation event. This data shall include the information associated with the NOMIS MIS user logon and log-off events.

NFR5090 16.2.26 Audit Data Investigation A facility is to be provided whereby audit data from NOMIS Application, NOMIS MIS, Quantum and NCDS can be imported, collated and security/audit related incidents can be investigated and reported.

NFR5091 17 Training

NFR5092 17.1 Training Total Numbers The training system shall allow a total of 70 thousand staff to be trained as per the NOMIS Training Strategy and the NOMIS Implementation Plan

NFR5093 17.1.1 Training Total Numbers The Training System shall allow a total of 50,000 (fifty thousand) staff to be trained as per the Prison-NOMIS 1.0e Training Solution [10] and the Prison-NOMIS 1.0e National Training Plan [11]


NFR5094 17.2 Introduction Training Course The training shall include an Introduction and overview of the NOMIS system which all NOMIS Business Users will need to attend. This is a half day training course

NFR5095 17.3 MIS Training Course The training shall include a Management Information and Reporting course

NFR5096 17.4 Role Based Training Courses The training shall include Detailed role-based courses, each one of this set of courses will be focussed on a role or closely related set of roles such as Reception, Custody Office, Prisoners' Monies, Seconded or Court officer.

NFR5097 17.4.1 Role Based Training Courses Training shall include Detailed role-based courses, based on R1.0d training material which is updated to reflect the new functionality of R1.0e and to be HMPS specific. Each one of this set of courses will be focussed on a role, or closely related set of roles, such as Reception, Custody Office, Prisoners' Monies, etc.

NFR5098 17.5 Aftercare The training shall include Aftercare to provide Business Users with assistance in both the business process and purely IT aspects of NOMIS

NFR5099 17.6 Ongoing Training Programme The training shall include an ongoing training programme to train new Business Users and existing Business Users who change roles, and to provide refresher training and training in new system features

NFR5100 17.7 Local Support Training Training is required to ensure that Local Support Staff can carry out their Prison-NOMIS management responsibilities

NFR5101 17.7.1 Training Documentation The training shall include a set of process and system support documentation to support end Business Users.

NFR5102 17.8 Training Evaluation (end of course) An end of course testing of learners shall be provided to measure the achievement of course objectives

NFR5103 17.9 Training Evaluation (post go-live) There shall be an end of training measurement of the effectiveness of the training programme in giving Business Users the skills to meet business objectives

NFR5104 17.10 Training database refresh The Training Database(s) shall be refreshed at end of each day.

NFR5105 17.11 C-NOMIS Application Package Delivery for Training Material development

The R1.0e Prison-NOMIS Application code must be delivered as a Solaris installable package for Training material development purposes for each sub-release (SR8/9/10). The delivery package must include all material to successfully install the application without intervention from the Supplier. The Package must be delivered as indicated in the latest base-lined Prison-NOMIS Technical Delivery Schedule or when the package is delivered to the Prison-NOMIS ALT team, which ever is the sooner.

NFR5106 17.12 C-NOMIS Application Package Delivery for Training - CHET

The final R1.0e SR10 C-NOMIS Application code must be delivered as a Solaris installable package for Training purposes, encompassing each application sub release and environment patch enhancement. The delivery package must include all material to successfully install the application without intervention from the Supplier. The Package must be delivered as indicated in the latest base-lined Prison-NOMIS Technical Delivery Schedule or 13 weeks before the R1.0e go-live date, which ever is sooner.

NFR5107 17.13 C-NOMIS Application Code Delivery for Training - Mobile Suite

The final R1.0e SR10 C-NOMIS Application code must be delivered as a Wintel installable package for Training Delivery purposes, encompassing each sub-release and environment patch enhancement. The delivery package must include all material to successfully install the application without intervention from the Supplier. The Package must be delivered as indicated in the latest base-lined Prison-NOMIS Technical Delivery Schedule or 13 weeks before the R1.0e go-live date, which ever is sooner.


NFR5108 18 Testing

NFR5109 18.1 Testing environments NOMIS shall enable separate partitions to be created on the NCDS.

NFR5110 18.2 Test Provide necessary testing structure for both NOMIS Application and the reporting solution.

NFR5111 18.2.1 Test Strategy Provide an acceptable testing strategy.

NFR5112 18.2.2 Unit Test Provide an acceptable environment for unit testing.

NFR5113 18.2.3 Integration Test Provide an acceptable environment for integration testing.

NFR5114 18.2.4 System Test Provide an acceptable environment for system testing.

NFR5115 18.2.5 End to end Acceptance Test Provide an acceptable environment for end to end testing.

NFR5116 18.2.6 Load and Performance Test Provide an acceptable environment for load and performance testing.

NFR5117 18.2.7 User Acceptance Test Provide an acceptable environment for user acceptance testing.

NFR5118 18.2.8 Testing Tools Provide an acceptable set of tools to support and enable repeatable efficient testing, including load and performance testing.

NFR5119 18.2.9 Test Data Provide representative test data to exercise the functionality and performance of the application.

NFR5120 18.2.10 Test Environments Provide Test Environments to support the concurrent testing of Release 1.0e (and subsequent releases) in Grenadier House and such other sites as may be agreed between Authority and Suppliers

NFR5121 19 System Functions

NFR5122 19.1 Job Scheduling The NCDS shall have the capability to schedule operational application specific jobs (such as backups, system administration tasks, etc).

NFR5123 19.2 Output Distribution The NCDS shall have the capability to distribute the output from scheduled jobs (such as alerts, reports, etc) to a users workstation or local printer as appropriate to the scheduled operational application specific jobs (such as backups, system administration tasks, etc).