$PROJECT{C-NOMIS}
1. Functional Requirements 2
2. Non-Functional Requirements 157
Functional Requirements
|Req 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 |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 |
| | |C-NOMIS |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 |
|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. |
|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 |Release 1.1 needs to deliver the Risk Predictor |
| | |FACTOR SCORES |LIDS 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. |
|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. |
|FUNC3139 |2.4.6 |Implementation of LSR for Risk |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(For loadbalance risk predictor |predictor assesment results, and these were migrated on go live where available, it does not have the capability to actually ""do"" the predictions. |
| | |results) |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. |
|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. |
|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 |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 |
| | |Requirement |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. |
|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 |
|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 |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 |
| | |post-release |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. |
|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 ID |
| | | |For 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 |
|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 |2 results with different offence indicators |
| | |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. |
|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. |
|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 |When a user records two results against an offence on the existing screen ‘Court Cases – OCDCCASE’, the system must only allow the following combinations |
| | |Combinations |of result types: |
| | | |Final/Final |
| | | |Partial/Partial |
| | | |Interim/Interim |
| | | |Final/Partial |
|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). |
|FUNC4554 |3.6.11 |Extended Sentences Imposed on or After |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 |
| | |14/07/08 |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 |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 |
| | |Release Date |date. |
|FUNC5951 |3.6.12.3 |Approved Transfer To Community Date on |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|
| | |Release Schedule |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 |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. |
| | |Licence Start Date | |
|FUNC5953 |3.6.12.5 |Approved Transfer To Community Date on Hot|When an Approved Transfer to Community Date has been recorded, the system must display this as the release date on the existing ‘Hot Page’. |
| | |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. |
|FUNC500 |3.7 |[redacted] |[redacted] |
|FUNC501 |3.7.1 |[redacted] |[redacted] |
|FUNC502 |3.7.2 |[redacted] |[redacted] |
|FUNC503 |3.7.3 |[redacted] |[redacted] |
|FUNC504 |3.7.4 |[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' |
|FUNC509 |3.8.4 |[redacted] |[redacted] |
|FUNC510 |3.8.5 |[redacted] |[redacted] |
|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. |
|FUNC513 |3.8.8 |[redacted] |[redacted] |
|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. |
|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 |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 |
| | |reference |LIDS users to perform this merge |
|FUNC3276 |3.11 |Criminal Justice & Immigration Act 2008 | |
|FUNC10022 |3.11.1 |CJIA 2008 Sentence Calculation Rules – |For Offender records that meet the selection criteria defined below, and when calculating an Offender’s sentence key dates the system must: |
| | |Release of Long Term Prisoners |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. |
|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. |
|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. |
|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 |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 |
| | |document |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 following Authority agreement on reduced scope of biometrics for 1.1, 1.2 & 1.3 |
| | |version change from 1.5 to 1.6 | |
|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. |
|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 |Distinguishing Marks Photographs on Documents - provide the ability to print photographs of distinguishing marks on selected documents and reports. |
| | |Documents | |
|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 |Provide [redacted] |
| | |Quantum Sanctuary | |
|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. |
|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. |
|FUNC566 |5.1.19 |[redacted] |[redacted] |
|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. |
|FUNC568 |5.1.21 |[redacted] |[redacted] |
|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. |
|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. |
|FUNC582 |5.3.8 |[redacted] |[redacted] |
|FUNC583 |5.3.9 |[redacted] |[redacted] |
|FUNC584 |5.3.10 |[redacted] |[redacted] |
|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 |
|FUNC588 |5.4.2 |[redacted] |[redacted] |
|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). |
|FUNC3769 |6.1.2.1 |Amendment and Deletion of Future Dated |For the existing C-NOMIS screen ‘Maintain Agency Pay Profile (OIMAGPAY)’ the following create, update and delete rules will apply to payment profiles. |
| | |Establishment Pay Profiles |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. |
| | | |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. |
| | | |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. |
| | | |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. |
| | | |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. |
| | | |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. |
| | | |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. |
|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|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 |
| | |LIDS |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|The business has requested that automated offender pay be brought forward from release 1.2 to 1.1. The attached document specifies those detailed |
| | |Release 1.2 to Release 1.1 |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. |
|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. |
|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 Grant |
| | | |In 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. |
|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 & |Permit retrospective data entry |
| | |Allocations | |
|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. |
|FUNC4337 |7.3.4 |Link Purposeful Activity to internal |Request for Post 1.0e release |
| | |movements and activities to automate | |
| | |regime |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. |
|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. |
| | | | |
|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 |Request for post 1.0e Release |
| | |functionality | |
| | | |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. |
|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 Score |
| | | |2. Emotional Wellbeing Interpreted Score |
| | | |3. Attitudes Interpreted Score |
| | | |4. Thinking & Behaviour Interpreted Score |
| | | |5. 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 comment |
| | | |The 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. |
|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 name |
| | | |For 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. |
|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. |
|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 |Evaluation measures - sex offender questionnaire and remaining HMP assessments if/when OBPU come on board |
| | |Assessments | |
|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. |
|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. |
|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 |Non-Rolling Sessions Within a Rolling Modular Programme - provide the ability to pre-define a maximum number of allowable offender absences at a rolling |
| | |Programme |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 |The activities functionality has unnecessary steps and has poor ergonomic design. A redesign of this aspect of Prison NOMIS functionality to improve flow |
| | |Design |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 |
|FUNC771 |8.1.2 |Property Location |Property Location - record the location of any stored property. |
|FUNC772 |8.2 |Prisoner Property Management Technology |Prisoner Property Management Technology Interface - automate the documentation of property. |
| | |Interface | |
|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 |
|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. |
|FUNC798 |9.3 |[redacted] |[redacted] |
|FUNC799 |9.3.1 |[redacted] |[redacted] |
|FUNC800 |9.3.2 |[redacted] |[redacted] |
|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. |
|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 |
|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 optional |
| | | |o Field is only maintainable by enhanced user |
| | | |o Field must be a valid date |
| | | |o Date must be greater than today but less than or equal to today plus 1 month |
| | | |Note: 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 |Incident Type Specific Screen Configuration - record and display appropriate Incident Detail dependent upon the Incident Type. |
| | |Configuration | |
|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. |
|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. |
|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. |
|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 |The system must only allow a user to record an adjudication award when a related charge has been recorded as proven against a prisoner. |
| | |Charges | |
|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 |Establishment and Approved Premises information - record information on all establishments within HMPS and all Approved Premises and those externally |
| | |Information |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 |Establishment and Approved Premises Categories - record and maintain the premises type, area, gender, disability access. |
| | |Categories | |
|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. |
|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. |
|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. |
|FUNC914 |14.5.1 |[redacted] |[redacted] |
|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 |
|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 |Minimal Personal Details - record minimal personal details for a (new) prisoner temporarily held in Police Cells. |
| | |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. |
|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 |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 |
| | |Only Warning |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 & |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 |
| | |Offence Warning |sentence of 12 months or more and convicted of a relevant sexual offence. |
|FUNC5947 |15.2.4.4 |Polygraph Licence Condition MIS |The polygraph licence condition must be available for reporting on within the MIS system. |
| | |Availability | |
|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. |
|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. |
|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 |
|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 |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 |
| | |HDC ineligibility correction |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. |
|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 |When a prisoner is transferred to another establishment, the current Offender Supervisor (label to be changed to Personal Officer under CR00262) is |
| | |Transfer |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. Escaped |
| | | |2. Absconded |
| | | |On 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 codes |
| | | |1. Recapture Escape |
| | | |2. Recapture Abscond |
| | | |The 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 Hostel |
| | | |Discharge - NFA |
| | | |Discharge - Discharge - Unknown Accommodation Type |
| | | |Discharge - Transient/Short Term |
| | | |Discharge - Permanent Housing |
| | | |Discharge - 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. |
|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. |
|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. |
|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. |
|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 |Post 1.0e Release Request |
| | |case notes | |
| | | |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 |Breach Hearing - associate a breach hearing with the original sentence being breached (and hence to the original charges for that sentence). |
| | |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. |
|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 |Termination Reason by Sentence Component Type - Enable termination reasons to be linked to specific booking component types, namely pre- and post-CJA |
| | |Type |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 |
|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. |
|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 |Schedule Meetings Before Identifying Participants - allow a user to set up single or repeating meetings before identifying the participants. 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. |
|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. |
|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 |
|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 |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 |
| | |prisoner not allocated to a cell |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. |
|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 required to Business Objects MIS Universes/Reports to enable the reports to run correctly following a change of religion by an offender |
| | |Changes 1.0c | |
| | | | |
|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 |
|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 Backup |
| | | |Remove and Re Business Objects Canteen Report, and Test |
| | | |Apply 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 |
|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 report |
| | | |These 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 |[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. |
| | |to Wales Consortium from 1 to 3 | |
|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). |
|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 inmates |
| | | |AH ACR transferring to special hospital |
| | | |AX ACR deportation licence |
| | | |NP non-parole licence |
| | | |NX non-parole deportation licence |
| | | |PA parole licence for post-CJA inmates |
| | | |PX parole deportation licence |
| | | |RP recalled extended sentence parole licence |
| | | |RR returned extended sentence parole licence |
| | | |RC 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. |
|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 |
|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) - |[redacted] |
| | |Display Active Establishments ONLY | |
|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.0c |
| | | |This 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 |The CR covers the change of Reference Data to accommodate the creation of a "Dummy/Ghost" prison within the application. |
| | |for creation of a Dummy/ Ghost Prison |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. |
|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. |
|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 |
|FUNC1239 |19.8.5 |[redacted] |[redacted] |
|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 |
|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 lifers |
| | | |c) 6 years of data/events for all other types of offender |
|FUNC2708 |19.11.2.2 |Provide means of searching and reporting |This requirement is primarily aimed at NPS archived data but may also applied to HMPS archived data. |
| | |on NPS 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 |Probation Circular 34/2006 requires that Probation Areas monitor disability of offenders and employees from December 2006 onwards. The Common Load |
| | |data for NPS |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 only |
| | | |This 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 |Probation Areas, particularly those in the North of England, deal with offenders from Scotland. [redacted]allows recording of Scottish PNC numbers, which |
| | |Numbers to C-NOMIS |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 |
| | | | |
| | | | |
|FUNC2678 |19.11.4 |Option to migrate into NOMIS during |This CR provides a discussion paper (see attached) that investigates the process, risks and mitigations associated with performing data migration loading |
| | |Business As Usual (BAU) |of NOMIS during "business as usual" (BAU). |
|FUNC2990 |19.11.5 |Data Migration Loading during Business as |Data Migration will run in dedicated access mode for early adopters who will need to be made aware of the resulting business impact. |
| | |Usual | |
| | | |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|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 |
| | |Case Notes |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 |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|
| | |Case Notes |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’. |
| | | | |
|FUNC3120 |19.11.9 |FYI - QUANTUM - Implementation of data |This CR covers the implementation of a data fix for a defect identified in Vantive 1124132 |
| | |fix/ Migration of data on movement/ alert | |
| | | |"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 |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 |
| | |from CR00010/ linked to 376 & 396) |Logic as potential merge candidates. The report should include the following data items for each offender record: |
| | | |NOMS Number |
| | | |Prison Number |
| | | |Surname |
| | | |Forename 1 |
| | | |Forename 2 |
| | | |Gender |
| | | |Date of Birth |
| | | |PNC Number |
| | | |CRO Number |
| | | |Other Identifiers |
| | | |Case Identifiers (Magistrates Crt No. etc) |
| | | |Location (Prison Name) |
| | | |Active Alerts |
| | | |UAL Status (Unlawfully At Large) |
| | | |Personal Officer (Prison) |
| | | |Offender Manager (Name) |
| | | |Office (Name) |
| | | |Area (Name) |
| | | |The report will be sorted by; |
| | | |1. Area/Prison |
| | | |2. Office |
| | | |3. Offender Manager/Personal Officer |
| | | | |
| | | |The report should indicate whether any of these data items relate to the offenders working name or are aliases. |
|FUNC3140 |19.11.11 |Selective exclusion of Inactive offenders |The current scope of HMPS Data Migration includes offenders retained in LIDS but not currently at that establishment. |
| | |on HMPS migrations |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|This CR is connected to CR00222 |
| | |data in case notes |"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. |
|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.’|
|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. |
|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|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|
| | |OnDemand product |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. |
|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 |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 |
| | |data |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 |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 |
| | |OR & MIS ( |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. |
|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 |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 |
| | |files and the SISI application New |appear on Licences, where it is available. It will also pass the NOMIS ID to a redundant field on IIS. |
| | |Requirement |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 IIS |
| | | |These references will need to be available to pass on the IIS and IEDT interfaces. |
| | | |The references that need creating/passing are:- |
| | | |P7 - Unique_add_num |
| | | |C1 - Case Number |
| | | |C2 - Case Number |
| | | |C2 - Offence Number |
| | | |A2 - Charge_Number |
| | | |A2 - Adj_Charge |
| | | |A3 - Charge_Number |
| | | |A3 - Punishment_Number |
| | | |D5 - Unique_add_num |
|FUNC2680 |20.1.13 |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. |
| | |(Inactive) |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 IIS |
| | | |These 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 |After migration to NOMIS has been performed, the intention is to provide read-only access to LIDS for a specific period of time. |
| | |Mode | |
| | | |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 |
|FUNC3074 |20.1.15 |Data Extract for RDS to overcome component|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 |
| | |code & predominant case issues in R1. |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 |
| | |(Inactive) |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 |Change the Index on IIS to ignore the Unique Address Number |
| | |Unique Address Number | |
| | | | |
|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 |This change is to trigger the existing "Reception" type OASys message when two NOMIS IDs are merged. |
| | |IDs | |
|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 |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. |
| | |Deletion | |
|FUNC1280 |20.2 |External Agency / System Interface |External Agency / System Interface Capability - provide interfaces to share information and documents with non-HMPS agencies. |
| | |Capability | |
|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 |Provide capability to extract information on immigration and foreign national offenders. Enable data interchange between IND systems and C-NOMIS |
| | |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 |
|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 |The system must allow designated data from sections 1-13 to be automatically transferred to the RoH assessment in full |
| | |Assessment | |
|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 |
|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 |
|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 |
|FUNC1339 |21.2.24 |[redacted] |[redacted] |
|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 |
|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. |
|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 Premises |
| | | |number of rooms/shared rooms in clusters/self catering units |
| | | |provision for disabled residents |
| | | |restrictions 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 vacancies |
| | | |Insufficient information |
| | | |Risk of harm too low |
| | | |Risk to community too great to be managed |
| | | |Risk to staff too great to be managed |
| | | |Risk to residents too great to be managed |
| | | |Risk to self too great to be managed |
| | | |Inadequate facilities for health needs. |
|FUNC1376 |23.9 |Arrival Date & Time |Arrival Date and Time - record arrival date and time. |
|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 |
|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 |Provision of NCDS Servers for support of MIS |
| | |MIS | |
|FUNC2655 |27.1.1 |Provision of NCDS Servers for support of |Provision of NCDS Servers for support of Operational Reports |
| | |Operational Reports | |
|FUNC2661 |27.1.2 |Revised NCDS Infrastructure design, build,|This CR is for the design, installation, commissioning, build, test, support and management of the above hardware. |
| | |test & supp for MIS, Operational Rep |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 |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. |
| | |Business Objects |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 |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 |
| | |service | |
|FUNC3025 |27.1.6 |MIS/OR Business Objects Support and |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. |
| | |Service Levels for Albany | |
| | | |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. |
|FUNC2659 |27.1.7 |Purchase Of MQ Series Licences For OASys |Purchase [redacted] for installation on the NOMIS Data Hub. This is required for the development, test and production environments. We also need to train |
| | |Interface |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. |
|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 |The project requires the purchase and installation of appropriate hardware into [redacted] to support integration testing of OASys & eOASys. Hardware needs|
| | |support OASys Integration Testing |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 |The Storage available within the Integration Test environment is not sufficient to accommodate Operational Reporting and the Management Information System |
| | |integration test environment |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 |To provide additional Function Test Environment Capacity, required specifically (but not exclusively) to enable testing of R1.1 product to commence. |
| | |Meadowbank. | |
|FUNC2996 |27.3.7 |Update to the Performance & Scalability |Currently the application servers in the Performance and Scalability test environment at Meadowbank do not reflect the type and memory size of the servers |
| | |Test Environment Application Server Tier |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. |
|FUNC2991 |27.3.8 |C-NOMIS Quantum co-existence testing |To build an existing V240 server to be used for Co-existence testing for inclusion in the Quantum Model Office test environment. |
| | |server |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 |To modify the interconnect firewall implementation within the Global Crossing environment to allow independent penetration testing of the interconnect |
| | |Penetration testing of the Global Crossing|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|On 9th January the JDWG agreed that EDS would release Oracle Database Release [redacted] into production following a testing cycle and that this would |
| | |Upgrade |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 Fixes |
| | | |The fixes outlined below would require changes only to minor database / application configuration parameters. |
| | | |1. Natcodes Reference Data update |
| | | |2. Redeployment of Ad-hoc reports to global access (rather than to user’s inbox) with fixes tested in UAT |
| | | |3. 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 |Apply mandatory/urgent patches to Solaris operating system on specified servers, spread over 4 days, with 2 days for contingency. Schedule currently is |
| | |operating system (CR006887 |26th: [redacted]. 27th: [redacted]. 28th: [redacted]. 29th: [redacted]. 30th/31st contingency. All [redacted] models to have IPGE interface changed|
| | | |to [redacted] |
|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 comprises |
| | | |The fixes outlined below would require changes only to minor database / application configuration parameters. |
| | | |1. Natcodes Reference Data update |
| | | |2. Redeployment of Ad-hoc reports to global access (rather than to user’s inbox) with fixes tested in UAT |
| | | |3. 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 |Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS |
| | |(Steria) |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) Software |
| | | |c) Supporting Infrastructure |
|FUNC3068 |27.3.16 |NOMIS Technical envmnt for R1.1 – Steria |To support the introduction of Release 1.1 Steria testing requirements additional hardware will need to be provisioned. Steria have requested the |
| | |and P&S envmnt enhancement |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 environment |
| | | |2. Meadowbank test facility |
| | | |3. Meadowbank C-NOMIS release test |
| | | |4. OMNI release test. |
| | | |5. JLS transmission & load test environment |
| | | |6. JLS transmission test & trail load environment |
| | | |Currently, 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 environment |
| | | |2. Meadowbank test facility. |
| | | |These two environments are know as; |
| | | |1. The Data Migration trial environment |
| | | |2. 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 test |
| | | |2. OMNI release test |
| | | |3. JLS transmission & load test environment |
| | | |4. JLS transmission test & trail load environment |
| | | |The 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 testing |
| | | |3. Interaction profiling |
|FUNC3077 |27.3.17 |Test environment set up and environment |EDS Testing – [redacted] |
| | |support for Release 1.0c OASys and eOASy |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 |Provision of a test environment and test environment support to enable SunGard to undertake regression testing of OASys and eOASys against C-NOMIS Release |
| | |support for Release 1.1 OASys and eOASys |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. |
|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 |The Internet access method for Test Director needs to be changed from [redacted] |
| | |Director | |
|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 |SunGard scope currently includes a proof of concept to determine whether eOASys (running on Lotus Notes) can communicate using HTTPS rather than HTTP. |
| | |concept | |
| | | |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|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 |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. |
|FUNC3132 |27.3.28 |QUANTUM - FYI - Implementation of LSR 3 - |Implementation of LSR 3 - 2 main elements |
| | |2 main elements |1) 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 |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 |
| | |Chertsey |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|EDS are preparing a UAT environment at Doxford for 1.0C UAT and 1.1 UAT. |
| | |from Grenadier House | |
| | | |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 |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 |
| | |CR234) |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. |
|FUNC3157 |27.3.33 |Expansion of Truncated field sizes in |This Submission is for authorisation for EDS & SunGard to develop and implement the expansion of field sizes in the HMPS OASys application from 2000 |
| | |OASys |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 |The EDS BoM included provision for MS Office licences. 45 additional machines have since been ordered and the licencing situation should be regularised |
| | |Testing and additional areas ( | |
|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|Move delivery of migration and interface routines to transfer Licence Data between NOMIS and HMPS legacy from 1.0 to 1.1 |
| | |Transitional Interfaces | |
|FUNC2703 |27.4.4 |Renewal of Altova XML Spy Licences for EDS|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 |
| | |Data Migration & Interfaces Team |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 |
|FUNC3112 |27.4.8 |Windows 2003 Server Licences for Doxford |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 |
| | |Test Environments |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 Architecture |
| | | |2. Data Centre Infrastructure Design to NCDS Infrastructure Design |
| | | |3. Service Management Architecture to IT Management Architecture |
|FUNC2692 |27.6 |Tactical Solution to implement Mirror View|over the existing 1Gb Inter-site Link. |
| | |over Inter-site Links. |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 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 |
| | |in Rel 1.0 from NFR179.7.4 |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 |To provide an dedicated NOMIS logical environment for the provision of 2nd, 3rd and 4th line application support. |
| | |Environment |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 |Provide additional cooling capability within Meadowbank Server Room for NOMIS MIS/OR equipment. Work to be carried out by McAlpine urgently. |
| | |Upgrade | |
|FUNC2673 |27.8.3 |To amend data centre design, create build |NOMS have procured some additional hardware (5 *T2000) required for the Data Migration solution . |
| | |design and build the hardware procure |To implement the hardware the following documents will require change- |
| | | |Logical Technical Architecture |
| | | |NCDS Logical Architecture |
| | | |NCDS Logical Infrastructure High-level design |
| | | |Data Migration Architecture |
| | | |The following AE documents will need change or addition |
| | | |Server design |
| | | |Further to the design creation implementation activities will be undertaken by the Infrastructure groups by the infrastructure group. |
|FUNC2671 |27.8.4 |Implement a new Data Hub component to |Two elements of the Interfacing solution are impacted by this change: |
| | |route messages |• 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 content |
| | | |o St Helens team resource impact |
| | | |• Upgrade of Oracle Application Server hosting xTAG (Interfacing) to [redacted] |
| | | |o Development environment |
| | | |o Integration Test Environment |
| | | |o Production Environment |
|FUNC2704 |27.8.5 |Tactical Solution for Data Hub Resilience |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 |
| | |in the NCDS (NFR179.5.5) for Rel. 1.0 |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 |Additional memory is required for the Meadowbank Integration Database Servers. The two servers will be upgraded from 8gb to 16gb. |
| | |server | |
|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 |Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS |
| | |(Part 2) |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: |
|FUNC3020 |27.8.10 |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 |
| | |(Part 3) |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: |
|FUNC3021 |27.8.11 |NOMIS Technical Environments for R1.1 | |
| | |(Part 4) |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. |
| | | | |
|FUNC3022 |27.8.12 |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 |
| | |(Part 5) |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. |
|FUNC3023 |27.8.13 |NOMIS Technical Environments for R1.1 | |
| | |(Part 8) |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 |
| | | | |
|FUNC3024 |27.8.14 |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 |
| | |(Part 6) |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|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 |
| | |7 - Hosting, Network design & imp |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. |
|FUNC3030 |27.8.16 |NOMIS Technical Environments for R1.1 |CR00185 incorrectly specified SUN Storage Hardware; specifically, 2 x 6140 Sun StorageTek SANs, within the EDS Doxford data centre. |
| | |(Part 3a) |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 Storage |
| | | |An 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|Following on from CR00183, which highlighted the need for additional environments to support the ongoing development, testing and support of the C-NOMIS |
| | |10 |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; |
|FUNC3026 |27.8.18 |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 |
| | |(Part 11) |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|This change is required for the Albany Implementation.OIS Live Services require the EDS C-NOMIS Helpdesk to log Business Support incidents and requests, |
| | |FOR ALBANY |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 |When a prisoner returns to Albany a duplicate is created. There is no merge functionality as this is not required until 1.0c |
| | |received at Albany |The 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. |
|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|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 offenders on NOMIS |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|
| | | |card |
| | | |The 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 |Wintell versions of the TAG application and produced for loading onto the training development environment & CHET,inclusive of reference data.Versions |
| | |REQUIRED FOR C-NOMIS TRAINING |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. |
|FUNC3015 |27.10.6 |C-Nomis training database in Solaris |C-Nomis training database in Solaris Format, requirements for the CHET and a Wintell format for mobile training suites |
| | |Format, requirements for the CHET | |
| | | |Requirements for v1.0 C-Nomis for 15th January 2007 |
| | | | |
| | | |R-MAN copy of database level 0 backup prior to personal data being entered |
| | | |Any level 1's after the level 0 backup, upto the point where the personal data was added. |
| | | |Release notes |
| | | |Install Guide |
| | | |All SQL scripts and build script to execute |
| | | |Compiled copy of the oracle forms for the application |
| | | |Application CD's |
|FUNC3034 |27.10.7 |Extend the contract for the training |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 |
| | |developers until 31st October 07 |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|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. |
| | |of C-NOMIS for Probation areas |[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 date |
| | | |2. Step by step Install Guide |
| | | |3. All SQL scripts and build scripts to execute |
| | | |4. 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's |
| | | |8. Check list of all items to be delivered as part of release supplied 2 weeks before release date |
| | | |9. 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 |
| | | |EDS |
| | | |10. 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 |The xTAG In-bound service is currently implemented on Oracle Application Server (OAS) [redacted] and needs to be upgraded to OAS [redacted] to be |
| | |Application Server v10.1.3 |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 |The solution for C-NOMIS IEDT-Out and IIS interfaces requires a connection between the NOMIS Interconnect and the legacy 89 network. |
| | |89 network | |
|FUNC2999 |27.13 |eOASys build effort for NPS eOASys-NOMIS |The proposal document and purchase order for the NOMIS-OASys interface workstream specifically excluded the build effort required from the eOASys project |
| | |Interface in 1.1 |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 |This change supercedes CR00073. The original Change Description |
| | |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. |
| | | |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 Export |
| | | |2) All scripts needed to import the database export |
| | | |3) Instructions to run the scripts |
| | | |4) Release Notes describing the content of the release |
| | | |5) All application related libraries |
| | | |6) 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 |Continued Rental of the Large Scale Test Environment to the 20th April 2007. |
| | |Performance Test Environment | |
| | | |Equipment is rented from SUN and EMC. |
|FUNC3016 |27.18 |Increase in C-NOMIS client bandwidth |The projected bandwidth requirements for the C-NOMIS client over OMNI drives OMNI capacity planning. Previous details for bandwidth requirements indicated|
| | |requirements |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" |
|FUNC3050 |27.21 |Project CR - Increase Scope of 1b to fix |The Production Issue Review Board have recommended that two fixes are included in Release 1b: |
| | |Production Issues |Defect 5881: Incorrect population details sent to IIS |
| | | |Defect 5918: Offenders that have previously had temporary absences fail to transfer from NOMIS to LIDS |
| | | |In 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 |Addition of resolution of the following issues within Release 1.0c: |
| | |Production Issues | |
| | | |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 |Require a LAN design and implementation for 3 new Cisco Switches for the ground floor in Grenadier House. The cost items are:- |
| | |Extension |3 * Cisco Catalyst C2960 Switches - £2,300 each |
| | | |9 * 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 |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 |
| | |Profiling |region of £100k + 10 % EDS mark-up = £110K |
|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 timeframe |
| | | |5482 "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. |
|FUNC3063 |27.28 |Release 1.0b change of scope since |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 |
| | |baseline Requirements Index |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). |
|FUNC3064 |27.29 |Release 1.0c change of scope since |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 |
| | |baseline Requirements Index |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 more |
| | | |prisons are included ion the deployment of R1.0c (following the Programme Board decision on 15/2/07) that some additional reports from the 5260 NOMIS |
| | | |Report categorisation 1.11.xls may be required. This can not be determined until the business has decided which additional prisons will be brought onto |
| | | |R1.0c. |
|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.1 |
| | | |HMPS Deferral – Deferred by HMPS to R1.0c |
| | | |PIRB – Required to resolve an issue being tracked through the PIRB |
| | | |Internal – Detected during development of 1.0c but present in production from 1.0a. |
| | | | |
| | | |Defect Summary Source |
| | | |5772 EPG Bulk Extract - cosmetic issue Incidental fix |
| | | |6060 OASys - Offender Sentence Release Date not following order of precedence specified HMPS Deferral |
| | | |6107 Bulk Extracts - AOP extract is not working HMPS Deferral |
| | | |6133 Bulk Extracts - SiS is failing due to JDBC error reported HMPS Deferral |
| | | |6190 NOMIS Application issue: screen OUMASSMU does not display all Module_Privileges assigned to a user group for certain Roles. HMPS Deferral |
| | | |6191 OASYS Inter establishment movement Reception does not trigger details message HMPS Deferral |
| | | |6220 A & O Prisoner extract problem with Home Address Internal |
| | | |6230 Reports - MIS - Pre-UAT - Reception / Discharge List - 'Reception' Tab displaying all discharged prisoners. HMPS Deferral |
| | | |6238 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 PIRB |
| | | |6239 Changing an address when an Offender Contact is inactive but the address is active, will generate a P7 address PIRB |
| | | |6240 Changing an inactive address fires a P7 transaction where delete_flag = ‘Y' PIRB |
| | | |6241 If an Offender Contact with an inactive address is made inactive, a P7 is generated with a delete_flag = ‘Y’ PIRB |
| | | |6242 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 PIRB |
| | | |6246 No truncation of Reception and Labour remarks in A&O Prisoner Bulk Extract Internal |
| | | |6243 No natcodes for Northern Irish and Scottish Courts Internal |
| | | |6030 Albany data missing from F1032 PIRB |
| | | |6050 Usability issue in C-NOMIS inflates F1032 Authorised Absences figure PIRB |
| | | |6261 Offender Supervisor contact not handled by IEDT Inbound DRB (awaiting deferral) |
|FUNC3076 |27.31 |Increase scope of R1.0d to fix production |Description of Change Addition of resolution of the below defects within Release 1.0d. Note that the defects have come from multiple sources. |
| | |issues | |
| | | |HMPS Deferral – Deferred by HMPS to R1.0d |
| | | |PIRB – Required to resolve an issue being tracked through the PIRB |
| | | |Internal – Detected during development of but present in production from 1.0a. |
| | | | |
| | | |Defect Summary Source |
| | | |5911 Recurring Activity Schedules not being built. Internal |
| | | |6067 Schedule Enquiry - OIISCHED should not exclude schedules for offenders that are active in an agency caseload - but 'out' due to temp absence (for |
| | | |example) Internal |
| | | |6167 MB - User (RBACS4) has been assigned Role 900 and should only have Query access to the screen OMUVREST. However, user has Amend access. HMPS Deferral |
| | | |5937 Prison Roll Screen not showing correct details if offenders are in an internal location when it is deactivated PIRB |
| | | |6024 Error while creating a new ROLE PIRB |
| | | |5893 C-NOMIS cannot close Self Harm transactions on IIS PIRB |
| | | |6259 Inactive addresses are being sent to LIDS DRB (Awaits Deferral) |
|FUNC3078 |27.32 |Cancellation of CITO project and request |Request for a proposal for the replacement of the C-NOMIS Implementation on Transitional OMNI (CITO) project, with C-NOMIS Implementation on OMNI. |
| | |for a Proposal to implement C-NOMIS | |
|FUNC3079 |27.33 |Include TD 5943 in R1.0c |Empty Movements transaction file generated during IEDT In transfer |
| | | |An 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. |
|FUNC3082 |27.34 |Increase Scope of 1c to fix Production |Addition of resolution of the following issues within Release 1.0c. All these issues have detected during development of Release 1.0c. |
| | |Issues – Part 4 |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 archived |
| | | |6213 'Random' F2052 start dates being output on A&O Prisoner bulk extract |
| | | |6264 A&O Prisoner extract takes a 4 Estab comp code into a 2 char field in the output schema |
| | | |6266 Incorrect numeric1 (rank) on SEC90 status in NDH codetable |
| | | |6317 State Change Error Validation |
| | | |5780 IIS_A3_ARC table should have DURATION_PUN field as size NUMERIC(3) |
| | | |6318 M1 Transform Error |
| | | |6319 P7 Transform Error |
| | | |6320 The A2 Audit not updating correctly |
| | | |6350 Legacy offence codes missing from mappings |
|FUNC3089 |27.35 |NOMIS 1.0B 31/03-01/04 (QUANTUM CR - |Implementation of Nomis 1.0b |
| | |CR007124) FOR INFORMATION |This 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|A change is required to existing implementation of C-NOMIS for creation of occurrences on the Occurrence detail screen (OIDINCDE). The change is to |
| | |part of Release 1.0c |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 |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 |
| | |for R1.1 |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 |Provide resolution for the following defects in Release 1.0d./ R1.1: |
| | |1.0d/ 1.1 (linked to CR00301/ R1.0c) |6278 – MIS Database update failure |
| | | |6303 – UAT – sit1b – Password screen (OUMAPASS) showing a truncation error |
| | | |6328 – 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) |
|FUNC3137 |27.39 |Re-baseline Steria IT Delivery plan |Steria is submitting a revised plan/schedule for authority review and agreement to re-baseline |
| | |(v3.56) | |
|FUNC3144 |27.40 |Amendment to “Release 1c Quality Gate |Amend the agreed quality gate deliverables. |
| | |Deliverables v1 0” | |
| | | |1. Move the following deliverables from gate 3 to gate 6: |
| | | |a. Accreditation Document Set |
| | | |b. Security Operating Procedures |
| | | |2. Remove Business Objects deliverables: |
| | | |a. “SSO Design” from gate 3 |
| | | |b. “NOMIS 1.0c Report and Universe Unit Test Plan” from gate 4 |
| | | |c. “NOMIS 1.0c Report and Universe Unit Test Exit Report” from gate 4 |
| | | |d. Audit Unit Test Plan |
| | | |e. Audit Unit Test Exit Report |
| | | |f. Audit Link Test Plan |
| | | |g. Audit Link Test Exit Report |
|FUNC3151 |27.41 |URGENT HOTFIX - Implement Defect #6499 in |#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 - |
| | |C-NOMIS (prior to R 1.0c) |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 |Provide resolution for the following defects in Release 1.0c: |
| | |1.0c |6278 – MIS Database update failure |
| | | |6303 – UAT – sit1b – Password screen (OUMAPASS) showing a truncation error |
| | | |6328 – 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 |This CR covers the additional costs incurred by Sunguard due to delays in the programme. |
| | |costs |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 |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 |
| | |Inter-site Links |to be deployed to ensure there is no loss of data on the NFS Platform. |
|FUNC3158 |28 |CR's To Be Processed | |
|FUNC3159 |28.1 |Telephony Hardware required for |The purchase of additional telephony hardware to allow Application Support Groups to operate effectively. |
| | |application support |Qty Description |
| | | |4 Misco BT Converse 1200 |
| | | |4 Misco PLANTRONICS VISTA ADAPTER ONLY |
| | | |4 Misco PLANTRONICS SUPRAPLUS H251 MONAURAL HEADSET |
| | | |1 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.8M |
| | | |16 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. |
| | | | |
|FUNC3183 |28.4 |Expansion of Truncated field sizes in |This Submission is for authorisation for EDS & SunGard to develop and implement the expansion of field sizes in the HMPS OASys application from 2000 |
| | |OASys (OASys CR 255) |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|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 (CR00250 |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|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 |
| | |users to standard OMN |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 |The report will list the those offenders that have been identified as potential merges by the 'Duplicate Offenders Report' and whose details have been |
| | |(follow up CR from CR10/ lin |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 pending |
| | | |NOMS Number |
| | | |Surname |
| | | |Forename 1 |
| | | |Forename 2 |
| | | |Date of Birth |
| | | |PNC Number |
| | | |Location (Prison Name) |
| | | |Offender Manager (Name) |
| | | |Office (Name) |
| | | |Area (name) |
| | | |The report will be sorted by: |
| | | |1. Date of record flagged as pending |
| | | |2. Area/Prison |
| | | |3. Office |
| | | |4. Offender Manager/Personal Officer |
| | | |When 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. |
| | | | |
|FUNC3188 |28.8 |Standard of accommodation of discharge |Raised on behalf of Philip Richardson |
| | |address fields required i | |
| | | |Currently when entering home address details into CNOMIS, an address type is selected from the following: |
| | | | |
| | | |Home |
| | | |Approved Premises |
| | | |Curfew Order |
| | | |Discharge |
| | | |Reception |
| | | |HDC Address |
| | | |Release on Temporary License |
| | | |Residency Condition |
| | | |Care or Old Persons Home |
| | | |Hospital |
| | | |Other |
| | | | |
| | | |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: |
| | | | |
| | | |Settled |
| | | |Unsettled |
| | | |Temporary |
| | | |NFA |
| | | | |
|FUNC3189 |28.9 |Change to Steria Product Breakdown |Agreement to, and implementation of, a redesigned product breakdown structure for the NPS data migration tool set development. |
| | |Structure (PBS) for Data Migr | |
|FUNC3190 |28.10 |Link Cases - clarification for work |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 |
| | |streams other than ALT |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 |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). |
| | |bookings |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. |
| | | | |
|FUNC3193 |28.13 |Change Ownershop of "Audit report of |To change the delivery owner of the failed facial images report as documented in requirement A5.11 from Syscon delivery to Buisness Objects. |
| | |failed facial images" from | |
|FUNC3194 |28.14 |Request for EDS/ Delivery of PB 063N End |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 |
| | |of Custody Licence RFC |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|RC reference CR07906 - raised on behalf of [redacted] |
| | |environment & various | |
| | | |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. |
| | | | |
|FUNC3196 |28.16 |Q - End of BST/ Database backups must be |RC reference CR008004 - raised on behalf of [redacted] |
| | |rescheduled to start a | |
| | | |The database backups must be rescheduled to start at 22:00, so that they are completed before the databases are shutdown. |
| | | | |
| | | |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] |
| | | | |
| | | |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. |
| | | | |
|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] |
| | | | |
|FUNC3198 |28.18 |Make Effective Sentence End Date mandatory|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) |
| | |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|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 |
| | |in ALL Grenadier Meet |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. |
| | | | |
|FUNC3200 |28.20 |[redacted] |[redacted] |
|FUNC3201 |28.21 |Q - Deployment of Nomis 1.0c into to |Deployment of Nomis 1.0c into to Doxford NCDS followed by Fire Break and Upgrade of DR SIte on 26th July. |
| | |Doxford NCDS | |
| | | |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 |The database backups must be rescheduled to start at 17:00, so that they are completed before the databases are shutdown. |
| | |start at 19:00 | |
| | | |Disable all cnomis batch processes and run pre-midnight batch jobs |
| | | | |
| | | |Bring down the front end apps |
| | | | |
| | | |Shutdown TIBCO |
| | | |Shutdown 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) |
| | | | |
| | | |Post BST Changes, start the databases in the following order: |
| | | |[redacted] |
| | | | |
| | | |Start TIBCO |
| | | |Restart Hot Page, Xtag and CMS |
| | | | |
| | | | |
| | | |Manually run first part of MIS batch - [redacted] |
| | | |Manually run second part of MIS batch - [redacted] |
| | | | |
| | | |Manually run 8 cnomis batch processes |
| | | | |
| | | |Enable 8 cnomis batch jobs in Enterprise Manager automatic schedule. |
| | | | |
|FUNC3203 |28.23 |C-NOMIS Duplicate Offender Exception Table|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 |
| | |(link to CR00010, 375 |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 &|Cross reference to CR00393 |
| | |Parkhurst sites on 1. | |
| | | |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 |Emergency break Fix restore of C-Nomis OR to 24th July followed by application of 1.0c OR Components. |
| | |July/application of 1. | |
|FUNC3207 |28.27 |Q Break Fix restore of C-Nomis OR to 24th |Emergency Quantum change. |
| | |July/application of 1. | |
| | | |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 |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 |
| | |and routines |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 |Emergency Quantum Change. |
| | |[redacted]. Syn |Amend the Oracle database parameter [redacted]. Syntax: [redacted]. |
| | | | |
| | | |[redacted]. |
| | | | |
|FUNC3211 |28.31 |Q - New licence provided as part of |Raised on behalf of [redacted] |
| | |changes to LIDS | |
| | | |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 June |
| | | |2. Issued end of July |
| | | |3. 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 |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|
| | |Establishment Search screen O |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’ |
| | | | |
|FUNC3216 |28.36 |Q - All services on [redacted] to be |Raised on behalf of [redacted] |
| | |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 |Apply SQL script to create additional Prison activities with Reference data. |
| | |Prison activities with | |
|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 data |
| | | |Validate Process |
| | | | |
|FUNC3221 |28.39 |Change Format of the 'Print Activities |The format of the Location tab in the Print Activities Report should be sectioned by wing and a page break by wing also inserted. |
| | |Report' | |
|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 below |
| | | |1) C-Nomis Services to be Stopped at Primary Site/GSS Recofig'd |
| | | |2) OASys PULL from Nomis Disabled with OASys (Separate CR) (IOW Cluster Only) |
| | | |3) Secondary SIte (Washington) Promoted to Live |
| | | |4) Interfaces Reconfigured to Point to Dummy End Points - To Protect Live Legacy Systems |
| | | |5) Service Tested by Client |
| | | |6) Interfaces Tested by Client and EDS Personnel |
| | | |7) Signoff |
| | | |8) Nomis Services at Secondary SIte Stopped |
| | | |9) Nomis Services at Primary Site Started |
| | | |10) OASys Pull Capability Re Enabled for IOW Cluster |
| | | |11) Primary Site Accepted |
| | | |12) Secondary Site Synched with Primary site |
| | | | |
|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 Number |
| | | |Offender Surname |
| | | |Offender Initials |
| | | |ACCT Status |
| | | |Cell Location |
| | | |Appointment/Activity details |
| | | |Appointment/Activity location |
| | | |Appointment/Activity start time |
| | | | |
|FUNC3224 |28.42 |Updating of C-NOMIS Training Database |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 |
| | |Environments R1.0D |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 |
| | | | |
|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 Number |
| | | |2. Surname |
| | | |3. Given Name 1 |
| | | |4. Given Name 2 |
| | | |5. DOB |
| | | |6. Age |
| | | |7. Cell Location |
| | | |8. IEP Level |
| | | |9. Security Category |
| | | |10. Main Status |
| | | |11. Effective Sentence |
| | | |12. Personal Officer |
| | | |13. Date & Time of Case Note entry |
| | | |14. Establishment where entry was made |
| | | |15. Contact type |
| | | |16. Contact Sub Type |
| | | |17. Case note text |
| | | |18. Creation Date & Time |
| | | |19. Name of staff member who made the case note entry |
| | | |20. Date & Time of amendment to Case Note |
| | | |21. Name of user who made the amendment |
| | | |22. 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 |
| | | | |
|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 |Deployment of C-Nomis 1.0d into to Doxford NCDS followed by Fire Break and Upgrade of DR SIte on 3rd Dec. |
| | |followed by Fire Break a | |
| | | |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 |Deployment of C-Nomis 1.0d into to Doxford NCDS followed by Fire Break and Upgrade of DR SIte on 10TH Dec. |
| | |NCDS | |
| | | |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 |Deployment of ECL release CR384 and 2 urgent Hot Fixes. |
| | |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 changes |
| | | |National Reference Data RD_V10.2.0.1.53.48 |
| | | |National Reference Data RD_V10.2.0.1.53.49 |
| | | |IIS 1.12 |
| | | |Business 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. |
| | | | |
|FUNC3236 |28.54 |Q - Clariion san storage array at doxford |Raised on behalf of David Beddard |
| | |requires a firmware co | |
| | | |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 List |
| | | |V.O number |
| | | |Details of all visitors (current report only shows lead visitor) |
| | | |Child visitors to be flagged |
| | | | |
|FUNC3238 |28.56 |Additional “Court Considered Level of |Raised on behalf of Michael Dutton. |
| | |Seriousness” options | |
| | | |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 Seriousness |
| | | |All 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 High |
| | | |Custody Threshold |
| | | | |
|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 |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 |
| | |transfered from C-NOMIS |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 |The resolution of a production problem requires the installation of a new version of 'Data Integrator' but only in the MIS environments. |
| | |installed in the MIS envi | |
| | | |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. |
| | | | |
|FUNC3242 |28.60 |Adjudication Awards - related to defect |In screen OCUOICAW - Awards screen upon making two charges to run consecutive, in the award frame the adjudication refers to the adjudication number only |
| | |1965 |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 |Recording comments of cancelled session not possible in same screen (OIDPACTI) as used to cancel the session. |
| | |5406 |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 Director |
| | | |179.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. |
| | | | |
|FUNC3246 |28.64 |[redacted] |[redacted] |
|FUNC3247 |28.65 |Duplication in Licence IWP - related to |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 |
| | |defect 7798 |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|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 |
| | |7865 |design, but it has never been stated as mandatory when the HDC status is set to refused. |
| | | | |
|FUNC3249 |28.67 |Amend interfaces to pass 99 years as the |The current C-NOMIS application allows peoples' ages to be over 100 years. The maximum on legacy applications is 99 years. |
| | |age of anyone over 100 |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 extracts |
| | | |Other 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 |When the system displays an Offender’s history of bookings on the existing screen ‘Offender History – (OSIHRSUM)’, the description of the reason for the |
| | |OSIHRSUM – Defect 4090 |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 |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 |
| | |FOR INACTIVE OUT OFFENDE |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 |This CR Covers the Release into live of a replacement Visits List Report. |
| | |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 Report |
| | | |Update Business Objects Universes - Using BOUK Update Wizard |
| | | |Update Visits List Report - Using BOUK Update Wizard |
| | | |Confirm Report Version Numbers are as designed |
| | | | |
|FUNC3254 |28.72 |Migration, IEDT transfer and Oasys |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 |
| | |transfer of ACCT/F025 alerts |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 |Raised on behalf of [redacted] |
| | |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 below |
| | | |1) C-Nomis Services to be Stopped at Primary Site/GSS Recofig'd |
| | | |2) OASys PULL from Nomis Disabled with OASys (Separate CR) (IOW Cluster Only) |
| | | |3) Secondary SIte (Washington) Promoted to Live |
| | | |4) Interfaces Reconfigured to Point to Dummy End Points - To Protect Live Legacy Systems |
| | | |5) Service Tested by Client |
| | | |6) Interfaces Tested by Client and EDS Personnel |
| | | |7) Signoff |
| | | |8) Nomis Services at Secondary SIte Stopped |
| | | |9) Nomis Services at Primary Site Started |
| | | |10) OASys Pull Capability Re Enabled for IOW Cluster |
| | | |11) Primary Site Accepted |
| | | |12) Secondary Site Synched with Primary site |
| | | | |
|FUNC3257 |28.75 |Change of name from C-NOMIS to Prison |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. |
| | |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 & Establishments |
| | | |A list of the data items for objects in the MIS universe is contained in the document attached to this CR |
| | | |This CR replaces previous CR's - CR429, CR430, CR431, CR432, CR433, CR434 & CR 435 |
| | | | |
|FUNC3260 |28.78 |Q - Sun Solaris patches to Database Severs|Raised on behalf of [redacted] |
| | |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 PM |
| | | |Backup Rescheduled to start at 22:00 |
| | | |Overnight Batch Processes suspended (to be run manually on completion of patching) |
| | | | |
| | | |Saturday AM |
| | | |Closedown Nomis Databases, Services, Interfaces and MIS |
| | | |Apply Solaris patches [redacted] to the following 5 live servers at Doxford - ukdxnom001 [redacted]. |
| | | |Start Nomis Databases, Services, Interfaces amd MIS |
| | | |Start Deferred Batch Processes |
| | | |Reset Scheduled Processes for future days |
| | | | |
| | | |Sunday - Firebreak |
| | | | |
| | | |Monday AM |
| | | |Following 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 PM |
| | | |Patches 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 |
| | | | |
|FUNC3263 |28.81 |REVOKE CR00219 (Preventing Returning |CR00219 was a change to prevent returning offenders creating a duplicate record for Albany for offenders attending the Hospital in Parkhurst. |
| | |prisoners being received at | |
| | | |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 |This is required before 1.0e due to difficulties experienced on the I.O.W. |
| | |result of Isle of White o |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). |
| | | | |
|FUNC3266 |28.84 |PVO’s are incorrectly calculated as part |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 |
| | |of the batch process. |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 |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 |
| | |Prisons |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 2008 |
| | | |3 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. |
| | | | |
|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. |
| | | | |
|FUNC3271 |28.88 |Ending Schedules on leaving establishment |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|
| | |- defect 1974 |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 |
| | | |• scheduled programme appointments |
| | | |• scheduled court attendances |
| | | |• scheduled temporary absences |
| | | | |
|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 |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 |
| | |defect 5060 |with the old working name is passed instead). |
| | | |Issues are:- |
| | | |C-NOMIS permits >1 PNC |
| | | |C-NOMIS permits >1 PNC for aliases |
| | | |Which 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 record |
| | | |When 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 Number |
| | | |C-NOMIS permits more than 1 |
| | | |C-NOMIS can also have different PNC numbers on alias records. |
| | | | |
| | | |Issue 1 |
| | | |When 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 2 |
| | | |In 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. |
| | | | |
|FUNC3277 |28.91 |Provide a new extract from C-NOMIS to |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|
| | |OFFLOC |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 |
| | | | |
|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 |Close CR00465, and move all reqs documentation for CR00465, including Syscon preferred option to this CR + add Offender Supervisor data (from LOV) to |
| | |Supervisor data to C-NOM |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) |
| | | | |
|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 functionality |
| | | |1. Dramatically simplified or whole process or |
| | | |2. 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) |
| | | | |
|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 |When the system displays offenders' scheduled court movements on the exsiting screen 'Schedule Court Movements - (OIDSCMOV)', the code of the reason for |
| | |OIDSCMOV Defect 1037 |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 |Consolidation of delivery of SR8 / SR9 and SR10 Online Help and change of delivery date to 18/09/08 |
| | |Help Text (EDS on behalf of Syscon) | |
|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 | |
|FUNC3056 |29.1 |Purchase of 20 Dell Optiplex GX5 as part |The procurement of 20 Dell Optiplex GX520 desktops for the project to be used at Grenadier House |
| | |of the refurbishment of ground floor | |
|FUNC3180 |29.2 |AT Very Early UAT (VE UAT) Test |AT Very Early UAT (VE UAT) Test Environment required |
| | |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, |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 |
| | |1.0D and 1.1 |requirements scope approved by the JDWG on 18th January. |
| | | | |
| | | |The revised ‘ready to deploy’ dates are: |
| | | | |
| | | |Release 1.0B - Albany Maintenance Release – 15th March 07 |
| | | |Release 1.0C – Isle of Wight (Iow) cluster + additional sites selected by HMPS & COPS (restricted list) – 11th July 07 |
| | | |Release 1.0D – Priority Defect Release (scope to be determined post R1.0C) - September 07 |
| | | |Release 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. |
|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 comments |
| | | |NPD0064 - problems in pull-through after abandoned assessments |
| | | |NPD0070 - Emergency risk flag change |
| | | |NPD0071 - Risk flag amendments |
| | | |NPD0077 - 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 |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|
| | |Clusters - NOMIS (Q_ CR007520) |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 |Implemement a number of Data Fix and minor system changes to address incidents resulting from issues with Web Submission and user/group administration. |
| | |system changes to address i | |
| | | |LSR11 will address and supply fixes to incidents 1156918, 1278610, 1280148, 1153153, 1171448,1256952. |
| | | | |
|FUNC3217 |29.10 |Q - Syncronise Time on servers ukdxnom001 |Raised on behalf of [redacted] |
| | |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. |
| | | | |
|FUNC3286 |29.11 |Ending schedules on leaving establishment |Supersedes CR0474. Defect 1974 ITT - In screen OIUSCINQ - Offender schedule conflict enquiry - when an offender has been transferred to another prison and|
| | |- Updated to new CR |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 |The full title of this CR is: Request for additional resource for LIDS Data Migration support during Albany Dress Rehearsal and Live Cutover |
| | |Data Migration support during Albany Dr | |
| | | |The need for an additional resource to provide LIDS support during the upcoming Albany Cutover and Dress Rehearsal has been identified. |
|FUNC10030 |31 |Merge | |
|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. |
| | | | |
| | | |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.|
Non-Functional Requirements
|Req 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 |For Interactions which clearly cannot achieve the required response times, such as for production of certain reports, the NCDS shall |
| | |NCDS |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 |For Interactions which clearly cannot achieve the required response times, such as for production of certain reports, the NCDS shall |
| | |Quantum |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 |For Interactions which clearly cannot achieve the required response times, such as for production of certain reports, the NCDS shall |
| | |OMNI |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 |In the event of a local telecommunications failure at a NPS area office, OMNI shall enable data communications with the NPS area office |
| | |Offices |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 only |
| | | |This 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 |Data Migration is not to result in the loss of service to HMPS establishment, HQ sites or other locations Prison-NOMIS is accessed from |
| | |Service |(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 |Quantum shall enable biometric information to be captured from peripherals using [redacted] as defined in the NOMIS Biometrics |
| | |Devices |Requirements Clarification for R1.0e [12]. |
|NFR4812 |8.1.4.1 |Infrastructure Support for Biometric |Quantum shall enable the connectivity of a digital camera [redacted] with the capability to capture a JPEG images. |
| | |Devices | |
|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 |The Applications SHOULD be compliant to the W3C Guidelines Priority 1 and MAY be compliant to Priority 2 guidelines as defined in the Web |
| | |Guidelines standard |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 |The NOMIS Application shall be developed to be compliant to the W3C Web Content Accessibility Guidelines V2.0 (or latest version). |
| | |Content Accessibility Guidelines | |
|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 |The MIS Application shall support TextHelp Read and Write [redacted] |
| | |Applications | |
|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 |The MIS system shall support all the Priority 1 checkpoints and at least some of the priority 2 checkpoints defined in the existing |
| | |Guidelines standard |ratified Web Content Accessibility Guidelines standard |
|NFR4864 |10.18 |Priority 1 W3C accessibility guidelines |The MIS system should support all the Priority 1 checkpoints listed in the W3C LIST OF CHECKPOINTS FOR WEB CONTENT ACCESSIBILITY |
| | |for MIS |GUIDELINES V2.0 (or higher) |
|NFR4865 |10.19 |MIS Application compliance to W3C Web |The NOMIS MIS Application should be developed to be compliant to the W3C Web Content Accessibility Guidelines V2.0 (or latest version). |
| | |Content Accessibility Guidelines | |
|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 |The NCDS architecture documentation shall be maintained 1 month prior to any significant architecture change and approved by NOMS before |
| | |Timeliness |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 |The NOMIS application or System Integrator must provide a capability to enable the Business Management Group to carry out an audit of |
| | |functions |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]. |
|NFR4985 |15.5.2 |NOMIS [redacted] boundary protection |NOMIS shall have boundary protection mechanisms [redacted]. |
|NFR4986 |15.5.3 |NOMIS [redacted] boundary protection |The system shall have boundary protection mechanisms [redacted] |
|NFR4987 |15.5.4 |NOMIS [redacted] boundary protection |NOMIS shall have boundary protection mechanisms [redacted]. |
|NFR4988 |15.5.5 |NOMIS [redacted] boundary protection |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 |Any connections that are made over the Internet, or other public networks, from NOMIS to other systems shall have the information |
| | |across unclassified networks |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 |Exchanging information between NOMIS and other Criminal Justice Organisations (excluding the NPS or HMPS) shall be governed by an |
| | |other CJOs |Interchange Agreement |
|NFR4995 |15.5.11 |Control of exchange of information with |Exchanging information between NOMIS and large non-CJOs shall be governed by an Interchange Agreement |
| | |large non-CJOs | |
|NFR4996 |15.5.12 |Control of exchange of information with |Exchanging information between NOMIS and non-CJOs shall be governed by an Interchange Agreement and/or a Code of Connection |
| | |non-CJOs | |
|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 MIS |
| | | |b) The person who ran the query/report |
| | | |c) 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 |NOMIS shall enable [redacted] to specify the following events for auditing: |
| | |System Admin functions |- 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 ID |
| | | |Date and time of event |
| | | |Type of event |
| | | |Applications used |
| | | |Workstation 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 |The R1.0e Prison-NOMIS Application code must be delivered as a Solaris installable package for Training material development purposes for |
| | |Training Material development |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 |The final R1.0e SR10 C-NOMIS Application code must be delivered as a Solaris installable package for Training purposes, encompassing each |
| | |Training - CHET |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 |The final R1.0e SR10 C-NOMIS Application code must be delivered as a Wintel installable package for Training Delivery purposes, |
| | |Training - Mobile Suite |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). |
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- c reactive protein level 30
- c reactive protein level chart
- does emergen c work
- is emergen c good for you
- c c international group
- project in project management definition
- c string to c string
- project goal and project requirement
- project and project management
- project specialist vs project manager
- project manager vs project coordinator
- c and c construction services