Code Change Request (CCR)
Before submitting the CCR:
We strongly recommend you to read the ‘Guide to Completing the CCR Template’ section at the end of this document before filing this document.
Please ensure all sections are completed for each requirement as failure to do that may lead in the requirement to be rejected.
After Submitting the CCR:
We aim to review all CCRs within 28 working days from the submission of the completed change request form and advise you of the feasibility of the change. Change feasibility will be decided based on the information submitted to us in this template, however, in case of complex requirements where further in-depth analysis is needed, we may ask for further information.
Feasibility Assessment / Next Steps:
Where a more thorough analysis is required to assess the feasibility of the change and consequently requires a significant investment of time and resources from us, there may be a Feasibility Assessment charge. In which case, we will advise you accordingly and seek your confirmation whether you require us to proceed with evaluating the request on a chargeable basis.
The Feasibility Assessment, where required, will be charged as per the Consultancy rates as per our standard Rate Card. Please refer to your subscription agreement for the Rate Card or contact the Support Desk for a copy.
Once the feasibility has been established and development costs agreed (where appropriate), we will advise you within 28 days from the point we receive your instruction to proceed, the target Version / Build your request can be included in.
Code Change Request Form
Guide to Completing the Code Change Request (CCR) Template
Section
Description
Priority
(Mandatory)
Priority of this Change Request needs to be stated as:
Critical, the requirement is necessary to support critical business transactions.
Major, the requirement is necessary to speed up business transactions and directly affects the customer service levels.
Moderate, the lack of this feature does not prevent the business from operating however user performance is being affected.
Visible, the requirement has only a visible or cosmetic impact on the System but that defect does not affect business operational performance.
Invisible, the impact of the requirement is invisible to the user and defect does not affect business operational performance
Change Category
(Mandatory)
Please state which of the category(ies) below best describes the nature of your requirement:
- Cosmetic – For requirements which only constitute a cosmetic or superficial changes to the presentation or layout of on-screen information.
- Functionality – For requirements which affect existing functionality or requires development of new features in the system.
- Legal Compliance – For requirements which are needed for compliance with legal or industry regulations. Please state which requirement / regulation it’s required by.
- Process Optimisation – For requirements which improve the system speed or efficiency.
- Security/Access Rights – For requirements which improve the data security internally.
- Exploratory / R&D – For non-business critical requirements which are part of research & development activity for implementation or a future project.
Usage Frequency
(Mandatory)
How often would this change will affect the system usage? E.g. Daily, Bi-weekly, Weekly, Monthly, Quarterly, Annually
Business Case
(Mandatory)
Only fill this section in case of Enhancements, not required for Bugs.
We have added the following questions to help you define the best case for this change. Please feel free to add additional information as required.
- Is this change going to generate additional revenue? Yes / No If, yes – Please state approximately how much revenue generation can be directly / indirectly attributed to this change over a month / year?
- Is this change going to reduce manpower required or improve efficiency within the business? If yes, how many man hours can be saved on average over the period of day/month/year?
- How many or what percentage of users to benefit from this change?
- Is this change required to gain advantage or keep up with your competitors? If yes, please share details as appropriate.
Detailed Specification
(Mandatory)
Please describe the requirement in as much detail as possible. Failure to express the requirement clearly may result in the request being declined.
New/Existing Screen, Form, Report Design
(Mandatory, if existing screen(s) requirement modification or new screens are required)
Please describe any changes required to existing screen(s) with the help of wire-frame, mock ups and/or screen-grabs / print outs of the existing screen and marking the changes required. In case of a new page/form or report is asked, please supply dummy report(s) in a suitable format (e.g. CSV, PDF, Excel) to illustrate the requirement.
Any exceptions to be made aware of?
Please state if there are any parts of the system or processes that should not specifically be affected.
Pre/Post Development Data Update Required?
Please state if any updates to the existing records will be needed to before of after the requirement has been developed.
Test Cases / Testing Requirements
Please give as much detail for the test cases / requirements for validating this change. This essentially will determine the scope of what needs to be tested and delivered.
Incomplete / missing test cases may result in the improper working of the system which may requires further development to fix any bugs arising out of the change which may be treated as separate development requests.