Supporting the effective legal remedies to human rights violations
in Serbia
Business Requirements
This document is the property of the Council of Europe. It's a part of a consultation launched by the Directorate General of Human Rights and Rule of Law The supplier will treat this document as strictly confidential. It may not be reproduced or communicated without the author's prior agreement. The content of this document will be disclosed to potential business partners in good faith by the supplier. No part of this document may, in itself, constitute a commitment of the Council of Europe or its staff.
|
Drafted by |
Version |
Date |
Status |
|
Name |
x.x |
xx/xx/2012 |
Draft / Validated |
|
Distribution list |
|||
|
Entity |
Name |
Role |
Purpose of distribution |
|
Amendment tracking |
|||
|
Version |
Author |
Reasons |
Date |
1 Introduction........................................................................................... 5
1.1 Purpose of the document.......................................................................... 5
1.2 Reference Documents.............................................................................. 5
1.3 Lexicon / Glossary................................................................................... 5
2 Executive summary................................................................................... 6
3 Background Information......................................................................... 6
3.1 Project scope and Objectives..................................................................... 6
3.2 Out of Scope.......................................................................................... 6
3.3 Presentation of the relevant directorates / departments................................. 6
3.4 Business processes.................................................................................. 6
3.4.1 Existing (AS IS) processes...................................................................................... 6
3.4.2 Future (TO BE) processes....................................................................................... 6
3.5 Identified stakeholders, users, roles & responsibilities..................................... 7
3.6 Interaction with other systems................................................................... 7
3.7 Replacement of existing / older systems...................................................... 7
3.8 Production rollout considerations................................................................ 7
3.9 Method of requirements capture used......................................................... 8
4 Business Requirements............................................................................ 8
4.1 Detailed business requirements.................................................................. 8
4.2 Interface requirements............................................................................ 9
4.3 User profiles.......................................................................................... 9
5 Technical Requirements........................................................................... 9
5.1 Operational environment Standards............................................................ 9
5.2 Hardware and infrastructure requirements................................................... 9
5.3 Access modes and security requirements..................................................... 9
5.4 Operational Security............................................................................... 10
5.5 Business Continuity plan (Disaster recovery)............................................... 10
5.6 Backup and Archiving............................................................................. 10
5.7 Service level: availability, performance and support..................................... 10
5.8 System Documentation........................................................................... 10
6 Critical considerations......................................................................... 11
6.1 Assumptions......................................................................................... 11
6.2 Constraints........................................................................................... 11
6.3 Risks................................................................................................... 11
7 Data Requirements................................................................................ 12
7.1 Data inputs........................................................................................... 12
7.2 Data outputs and reporting requirements................................................... 12
7.3 Data migration...................................................................................... 12
8 User Documentation and Training Requirements..................................... 12
9 Regulatory requirements....................................................................... 13
9.1 Privacy Requirements............................................................................. 13
9.2 Audit Requirements................................................................................ 13
9.3 Legislation............................................................................................ 13
10 Critical Success Factors (CSF) and measurements................................... 13
11 Sign Off Agreement................................................................................ 13
This document presents the detailed business requirements for the System Name system that will be delivered by the Strengthening the effective legal remedies to human rights violations in Serbia project.
List all documents describing the application and provide their hyperlink, for example, Business Requirements, User guide, etc. In connection with the various developments in the solution's "history", it may be helpful to provide a link to the detailed "delta" specifications drawn up for each project.
|
Name/Description |
Link to the document |
List all the specific terms and abbreviations used in the document.
|
Term |
Definition |
|
SLA |
Service Level Agreement |
Provide a brief overview of the project (one page only). What is its purpose? What is the problem it is seeking to address? What was the cause of this problem occurring?
The Council of Europe is currently implementing, until 23 May 2022, the Action “Strengthening the effective legal remedies to human rights violations in Serbia”, within the co-operation framework co-funded by the European Union and the Council of Europe known as the “Horizontal Facility for the Western Balkans and Turkey 2019-2022”. In that context, it is looking for a Provider for the provision of consultancy services of supporting project team in conducting tender procedure for the update of the website of the Constitutional Court of the Republic of Serbia and of the State Attorney’s Office-Agency Department before the European Court of Human Rights, most notably by preparing business requirements and detailed technical specification.
Explicitly identify anything, which is considered out of the scope of this project.
Include background of teams / functions impacted by the project.
In this section you describe the business processes and how your application will be used in this context.
In most cases you will need two sections – one describing the existing business process using existing systems (AS IS) and the other describing the future business process using the system you are developing (TO BE). This happens any time the business process will change once your system is introduced. When this is the case, the purpose of describing the existing business process is to have a basis of reference to explain the new business process.
If the business process won’t change when your application is introduced you should be able to describe it in a single section. However, in this case be sure you understand and communicate to others what value your application brings to the customers. This question should be answered in the Objectives section.
This section should be detailed enough to allow the Functional Specifications to be created. The use of diagrams, flowcharts and other similar items is encouraged.
The existing (AS IS) processes are those which the business undertakes before any changes are made. In most cases the majority of variation within any system arises from the process rather than the individuals. As a result, understanding of the process is critical to obtain sustained improvement.
The future (TO BE) processes are those which the business wishes to undertake and will identify where any changes to Policy, procedure, process and systems might be required. It is important to understand what these are.
In this section you describe who the users and stakeholders are and how the system fits into what they do. It is important to identify these up front otherwise requirements may be missed as you will not speak to the necessary people.
You need to list all users for your system in terms of user roles. Typically each individual performs multiple roles in the course of his work since his job involves meeting multiple business objectives. A user role is related to meeting a specific business objective. When gathering requirements it is most useful to consider roles since you will want to focus only on those business objectives that are relevant to your application.
For each role you need to list the tasks that involve the use of your system (directly or indirectly). You also need to describe the relationships among the tasks for each individual user role and the hand-offs from one role to another. This is usually represented as a workflow diagram.
Consider time in describing tasks and their relationships – different sets of tasks may be performed at different times (daily, monthly, etc.) and several workflow diagrams may be needed.
Once you have written the Objectives, Business Process, and the User Roles and Responsibilities sections, give them to the business expert to read. If you agree on what’s written you are well on your way to understand what actually needs to be done!
Insert, if appropriate, the RACI table.
In this section you describe how your application relates to other existing systems.
If your application is a sub-system of a larger system, this section should have two sub-sections. In one you describe the interactions between your sub-system and other sub-systems within the larger system. In the other you describe the interactions between your application and other systems outside of that larger system. These other systems may include legacy and non-legacy systems.
At the very least you should include a diagram showing the interfaces between your system and others. It should show the relationships between systems and what information is passed between them. It is best to add a verbal description of how your application fits in with everything else in terms of application responsibilities.
If your application replaces any existing or older systems, in this section you describe the special actions that will be required for switching production from the existing / old to the new system.
This may be quite involved and need a lot of technical detail. You may want to include a very short summary section in the requirements document and write a separate replacement requirements document.
In this section you describe the strategy for production rollout.
In addition, either this section, or an appendix in the requirements document, or a separate document should include the discussion of populating the system data for rollout and the discussion of the expected data and transaction volume.
Explanation of what methods were employed in order to complete the Business Requirements Document. This is useful for new project members joining or historical reasons.
This part of the requirements document states in a detailed and precise manner what the application will do. Requirements need to be explicit and clear, if any ambiguity exists then this needs to be resolved.
Specify each identified business requirement separately and ensure appropriate security requirements are included. This must track back to a Requirements Traceability Matrix to ensure no missing requirements.
|
BR1 – Business Requirement ‘Name’ § Description - A simple description for this requirement § Priority § Scope - A more detailed outline of the requirement. The stakeholders (Business, Project Lead, CIO, PMO) should share the same understanding of the scope. E.g. The tool should allow for the automatic archiving of documents after a defined period of time. § Benefits - Simple description of the business and strategic benefits of achieving this requirement. E.g. Improved searching § Need - Nice to have, Must have § Test Approach and Acceptance Criteria - How would the user expect to see that this has been achieved? E.g. Demonstration, Tested in line with existing standards etc. § Business rules - Business rules relating to this requirement may exist - Describe any business rules which relate to this requirement |
|
BR1 – Business Requirement XXX § Description § Priority § Scope § Benefits § Need § Test Approach and Acceptance Criteria § Business Rules |
|
BR2 – Business Requirement XXX § Description § Priority § Scope § Benefits § Need § Test Approach and Acceptance Criteria § Business Rules |
Define the accessibility / usability standards to be achieved, may be a referral to another document / standard which already exists.
Usability is the ease of use and learnability of a human-made object. Usability describes the extent to which the product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.
Accessibility describes the degree to which a product, device, service, or environment is available to as many people as possible. Accessibility is often used to focus on people with disabilities or special needs and their right of access to entities, often through use of assistive technology.
Specification of who has authorised access to the product (both functionality and data), and under what circumstances that access is granted, and to what parts of the product access is allowed.
List here the different user profiles.
Mention exceptions if there are any.
Are there any specific Hardware / Infrastructure changes that will be required?
If needed, describe the methods by which users will access the system; may be a referral to another document that already exists.
- E.g.: Intranet
- E.g.: Internet
- E.g.: remotely: Intranet Anywhere
Specification of who has authorised access to the Hardware, Media and Administration controls for the system being implemented. Mention exceptions if there are any.
Define what requirements or changes to existing practise will be needed to ensure the ongoing ability of the organisation to regain access to the data, hardware and software necessary to resume critical business operations after a Natural disaster or Man-made disaster. Establish if changes will be required to the current Business Continuity plan.
Define what requirements or changes to existing practise will be needed to ensure the ongoing backup and archiving of the system data.
Ensure any availability, performance and support requirements for this system are documented here. Examples of these might include:
Define the level of documentation required. It is expected that documentation for all aspects of the system should be thorough and complete.
Documentation should cover:
Ensure any assumptions made are documented here. Examples of assumptions might include:
§Assumptions about the technological environment in which the product will operate. These assumptions should highlight areas of expected compatibility.
Ensure any constraints identified are documented here. Examples of constraints might include:
The purpose of risk identification and assessment is to enable avoidance or mitigation and it is essential that unacceptable risks are mitigated by senior management prior to project commencement. Beyond this, risks and threats should be continually evaluated throughout the life of the work. List here the risks identified during the business requirements phase. For each risk, indicate its probability, impact and possible mitigation measures.
Probability reflects how likely a risk is to materialise and Impact indicates the magnitude of exposure represented by the risk (from 1=Low to 4=High). Overall rating reflects the combination of probability and impact. By definition, unacceptable risks are almost certain to occur and will severely impact, if not prevent, completion of the initiative.
|
Category |
RISK |
Impact |
Probability |
Overall |
Proximity |
Current Mitigation |
Assigned to |
|
What type of risk this is? |
RISK TITLE in capitals followed by the risk description (Risk is a specific situation in the future which is undesirable, can be avoided or mitigated and is measurable) |
Severity of the risk occurring (from 1=Low to 4=High) |
Likelihood of the risk occurring (from 1=Low to 4=High) |
Overall rating reflects the combination of Probability and Impact |
When is the risk likely to occur (in X months) |
Specific measures in place to counter the risk |
The person appointed to keep an eye on the risk |
What type of data is to be recorded in the system and which business areas would record it. Further analysis to understand detail on these will be undertaken as appropriate.
What data is required to be output from the system in the form of reports and which business areas would receive them.
Reporting requirements are key to understanding the data that a system will need to hold. All too often reporting needs are left until the last minute but they need to be defined at the very beginning. What reports will be required? Who will need to see them? Further analysis to understand detail on these will be undertaken as appropriate.
Data migration is the transferring of Data between Computer storage types, Formats, or Computer systems. Data migration is usually performed programmatically to achieve an automated migration, freeing up human resources from tedious tasks – however, it requires significant analysis to ensure that this is achieved successfully. It is required when organisations or individuals change computer systems or upgrade to new systems.
Any need or requirement for Data Migration must be identified here so that further detailed analysis can be undertaken as appropriate.
List the user documentation that will be supplied as part of the system and describe the training that will be available.
For each document consider:
Specification of what the product has to do to ensure the privacy of individuals that it stores information about taking into account confidentiality, integrity and availability requirements. The product must also ensure that relevant Council of Europe standards and national law about privacy of an individual’s data are observed e.g. data protection rules.
Specification of what the product has to do (usually retain records) to permit the required audit checks.
Highlight any legal, compliance or governance issues that could impact this project i.e. Financial services legislation, data protection rules, freedom of information etc.
This chapter will be excluded from a Call for Tender document
Critical Success Factor (CSF) is a Business term for an element which is necessary for an organisation or project to achieve its mission. Please provide the criteria / factors that must be met in order for the project to be successful.
How will we know if the CSF has been met? For each criteria/factor identified you must provide a SMART measurement against it. Get the CSF validated by the business so as to be used as acceptance criteria.
This chapter will be excluded from a Call for Tender document
Before any further work can be undertaken in relation to the requirements outlined in this document, the relevant Business and staff MUST sign off below as having reviewed and agreed this document as appropriate.
This is to certify that:
§ The requirements outlined in this document reflect the needs of the business as at the date of signing.
§ It is understood that any change to these requirements at a future date will have a likely impact on cost and timescales.
All relevant E-Mails relating to the sign off must be attached.
|
Name |
Role |
Date |
Signature |
End of Document