Annex B. Icmis Srs

Annex B
The Ethiopian Federal Courts’

Software Requirements Specification (SRS)
for the Development and Implementation of
Integrated Case Management Information System (iCMIS)
Date: November 1, 2021

RFP Number FETEH-2021-01
USAID Contract No. 72066319F00001
Page 1 of 144
Contents
List of Acronyms: ........................................................................................................................... 4

1. Executive Summary ................................................................................................................. 6
2. Introduction: ............................................................................................................................ 9
2. Case Management Data Groups and Data Elements: ............................................................ 10
2.1. Case Data Group: ........................................................................................................... 11
2.1.1. Definition: ............................................................................................................... 11
2.1.2. Classification: ......................................................................................................... 11
2.2. Person Data Group: ........................................................................................................ 12

2.2.1. Persons (Actors) in Civil Processes: ....................................................................... 12
2.2.2. Persons (Actors) in Criminal Processes: ................................................................. 14
2.3. Event Data Group: .......................................................................................................... 14

2.3.1. Events in Civil – Ordinary – First Instance Processes: ........................................... 15
2.3.2. Civil – Appeal Process Events: ............................................................................... 16
2.3.3. Criminal Process Events: ........................................................................................ 17
2.3.4. Cassation Process Events: ....................................................................................... 17
2.4. Financial Data Group: .................................................................................................... 18

3. Case Processing Events and Case Status: .............................................................................. 19
3.1. Definitions Used for Case Events and Status: ................................................................ 19
3.1.1. Case Events: ............................................................................................................ 19
3.1.2. Case Status: ............................................................................................................. 20
3.2. High Level View of the Court Case Flows: ................................................................... 22

4. The Major Internal and External Users of iCMIS ................................................................. 26
5. The Envisaged High Level Architecture of iCMIS: .............................................................. 28
6. Use Case Diagrams of Court Processes:................................................................................ 32
6.1. Civil Use Cases: ............................................................................................................. 32
6.1.1. First Instance – Ordinary Procedure: ...................................................................... 32
Page 2 of 144
6.1.2. First Instance – Summary Procedure: ..................................................................... 37
6.1.3. First Instance – Accelerated Procedure: ................................................................. 38
6.1.4. Appeal – Ordinary Procedure: ................................................................................ 40
6.2. Criminal Use Cases: ....................................................................................................... 61

6.3. System Administration Use Cases: ................................................................................ 77
6.3.1. Administration Functions: ...................................................................................... 77
6.3.2. Register User and Login Functions: ....................................................................... 79
7. Software Requirements Specification (SRS):........................................................................ 81

8. Key Performance Measures/Indicators:............................................................................... 126
8.1. Case Clearance Rate: .................................................................................................... 126
8.2. On-Time Case Processing: ........................................................................................... 127
8.3. Case Backlog: ............................................................................................................... 128
8.4. Trial Date Certainty:..................................................................................................... 129
8.5. Average Duration of Pre-Trial Custody ....................................................................... 129
8.6. Court User Satisfaction ................................................................................................ 130
8.7. Court Employee Engagement....................................................................................... 133
9. Technological Requirements ............................................................................................... 137
10. Warranty Services ............................................................................................................ 137
Annex 1: List of Reports in CCMS............................................................................................. 139
Page 3 of 144
List of Acronyms:
AFIS Administrative and Finance Information System

AFRS Administrative and Finance Reporting sub-system
API Application Programming Interface
BRD Business Requirements Document
CMIS Case Management Information System
CMRS Case Management and Reporting sub-system
CSV Comma Separated Value
DC Data Center
DCM Differentiated Case Management
DD-MM-YYYY Date-Month-Year
DR Disaster Recovery
eFLS Electronic Filing and Litigation sub-system
EOD End of Day
FFIC Federal First Instance Court
FHC Federal High Court
FSCE Federal Supreme Court of Ethiopia
HH:MM:SS Hour:Minutes:Seconds
HTTPS Hypertext Transfer Protocol Secure
iCMIS Integrated Case Management Information System
IFCE International Framework for Court Excellence
ISO/IEC International Organization for Standardization/International Electro-
technical Commission
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
MoA Memorandum of Appeal
NTP Network Time Protocol
Page 4 of 144
OLAP Online Analytical Processing
PDF Portable Document Format
PDF/A Portable Document Format Archive
R Read-only
RFP Request for Proposal
RM Records Management
RMIS Records Management Information System
RSA RSA (Rivest–Shamir–Adleman) is a public-key cryptosystem that is
widely used for secure data transmission
RTF Rich Text Format
RW Read and Write
SoC Statement of Claim
SoD Statement of Defense
SRS Software Requirements Specification
TLS Transport Layer Security
VPN Virtual Private Network
WAN Wide Area Network
XML Extensible Markup Language
Page 5 of 144
1. Executive Summary
This document, entitled “The Ethiopian Federal Courts’ Software Requirements Specification
(SRS) for the Development and Implementation of Integrated Case Management Information
System (iCMIS)” is produced through the consultancy support provided to the Federal Supreme
Court of Ethiopia (FSCE) from the USAID Feteh (Activity) in Ethiopia, hereinafter called
Feteh.
This SRS document, together with the following documents, produced through consultancy
support by Feteh:
1) The Ethiopian Federal Courts’ Business Requirements Document (BRD) for Integrated
Case Management Information System (iCMIS);
2) Request for Proposal (RFP) for Integrated Case Management Information System (iCMIS)
Application Software Development and Implementation to the Ethiopian Federal Courts,
shall constitute the necessary documents to hire a software development firm and guide the
design, development, and implementation of iCMIS.
A software requirements specification (SRS) is a document that describes what

the software will do and how it will be expected to perform. It also describes the functionality
and quality the product needs to fulfill its stakeholders (courts and their users) needs.
After analysis of the business requirements defined in the BRD, in this document we have
presented in detail the Software Requirements Specification (SRS) of iCMIS. The SRS
specifies the functional and non-functional requirements and also includes a set of use
cases that describe the processes involved and the user interactions that the software must
provide to get the services expected from iCMIS.
Page 6 of 144
This SRS document includes the following:
(1) Case Management Data Groups and Data Elements. The four basic groups of data
defined in detail under Section 2 include:
a) Case Data, i.e., data on statement of claim, statement of defense, evidence,
application, affidavit, case events, case history, statistics, etc.,
b) Person-Related Data, i.e., data on judges, parties, attorneys, witnesses, third-
parties, etc.,
c) Event Related Data, i.e., data on court calendars, adjournments, etc., and
d) Financial Data, i.e., data on fees, fines, security deposits, expenses, etc.
(2) Case Processing Events and Case Status, which includes definition of case processing
events and status, as well as high level view of court case flows for both civil and
criminal cases, based on the Civil and Criminal Procedures, respectively, presented
under Section 3.
(3) The major internal and external users of iCMIS are presented under section 4.
(4) The envisaged high-level architecture of iCMIS is presented under section 5.
(5) Use case diagrams of the court processes in civil and criminal procedures that describe
the processes involved and the user interactions that the software must provide to get
the services expected from iCMIS are presented under section 6.
(6) Section 7 presents the iCMIS Software Requirements Specification (SRS). The SRS
presents the functional and non-functional requirements and also includes a set
software features and qualities that the software must provide to get the services
expected from iCMIS.
(7) Section 8 presents details of the parameters and calculation formulas of the Key
Performance Measures/Indicators selected from among the indicators provided in the
International Framework for Court Excellence (IFCE) 1 that the software shall include.
The seven performance measures selected to be included in the software are: Case
Clearance Rate, On-Time Case Processing, Case Backlog, Trial Date Certainty,
1 International Consortium for Court Excellence (2020). Global Measures of Court Performance. Third Edition. Sydney, Australia:
Secretariat for the International Consortium for Court Excellence: http://www.courtexcellence.com
Page 7 of 144
Average Duration of Pre-Trial Custody, Court User Satisfaction, and Court Employee
Engagement.
(8) Section 9 requires the Software Development firms, to specify the technological
requirements (i.e., their selected technology for Software Development, Database
Management System, Operating System Software, Documents Creation and
Maintenance Software, and Network) for developing and implementing their proposed
iCMIS solution.
(9) Section 10 requires Software Development firms to include in their proposal provision
of two-years long post-implementation warranty services for the iCMIS software to be
implemented which will include both preventive and corrective maintenance services
so as to ensure uninterrupted service of the iCMIS software.
Overall, this Software Requirements Specification (SRS) document provides specification

of the functional and non-functional software requirements for the design, development,
and implementation of Integrated Case Management Information System (iCMIS)
software for the Federal Courts in a manner that would fully support all the judicial and
quasi-judicial processes in the courts with modern systems which will include, among
others:
(1) Electronic Filing (eFiling) and Electronic Litigation (eLitigation),
(2) Electronic Documents Generation, Access, Viewing, Delegation and Permissions,
(3) Judicial Workflow and Productivity Tools,
(4) Legal Research,
(5) Financial and Fee tracking,
(6) Calendars and Events management,
(7) Case Management,
(8) Reporting, and
(9) System Administration.
Page 8 of 144
2. Introduction:
This document, together with the following documents:

3) The Ethiopian Federal Courts’ Business Requirements Document (BRD) for Integrated
Case Management Information System (iCMIS);
4) Request for Proposal (RFP) for Integrated Case Management Information System (iCMIS)
Application Software Development and Implementation to the Ethiopian Federal Courts
fulfills the CMIS Requirements Definition and Specification deliverable of the fixed price
sub-contract #1 signed between Millennium DPI Partners and DigiFinance Trading and
Services PLC.
The three documents provide the business requirements, software specification, and the RFP
required for hiring a software developer company to develop, implement, and provide technical
support for a new case management system for the Ethiopian Federal Courts, entitled
“Integrated Case Management Information System (iCMIS)”.
The SRS presented in this document specifies the functional and non-functional requirements
and also includes a set of use cases that describe the processes involved and the user
interactions that the software must provide to get the services expected from iCMIS.
This SRS document covers the following topics:

1) Case management data groups and data Elements,
2) Case processing events and case status including high level view of the case flows,
3) Major internal and external users of the case management system,
4) The envisaged integrated case management information system (iCMIS),
5) Use case diagrams,
6) Software requirements specification (SRS),
7) Key performance measures/indicators,
8) Technological requirements, and
Page 9 of 144
9) Warranty services.
2. Case Management Data Groups and Data Elements:
The four basic groups of data maintained in courts are:

(1) case data, which includes data on statement of claim, statement of defense, evidence,
application, affidavit, case events, case history, statistics, etc.,
(2) person-related data, which includes data on judges, parties, attorneys, witnesses, third-
parties, etc.,
(3) event-related data, which includes data on court calendars, adjournments, etc., and
(4) financial data, which includes data on fees, fines, security deposits, expenses, etc.
Each of these court data groups relate to all of the other data groups in a “many-to-many”
relationship, as depicted in the below diagram.
Case Related Data

Event Related Data
Person Related
Financial Data
Data
Figure 1: Court Data Groups and their Relationships
Page 10 of 144
2.1. Case Data Group:
2.1.1. Definition:
A Case is a dispute between two parties that is adjudicated and decided in a court of law.
Based on the Ethiopian Civil and Criminal Procedure codes, a case data group is divided
into two major categories: Civil and Criminal.
A case is uniquely identified by Case Number. Other major identifiers for cases are names
and addresses of parties, case category, case type, court name, bench name, judge name,
etc.
Note: As per the Civil Procedure Code, Art. 214, case number is numbered in every year
according to the order in which the statements of claim are admitted. But the current
practice in the Ethiopian courts is that case numbers are given incrementally without
ending at the close of each year and starting afresh for each new-year.
2.1.2. Classification:
Based on the Civil Procedure Code, the Civil Case Category is classified into the
following Case Types:
(1) Family,
(2) Labor,
(3) Succession,
(4) Contract,
(5) Extra-contractual,
(6) Copyright and Neighboring Rights,
(7) Construction,
(8) Commercial,
(9) Bank and Insurance,
(10) Administrative Procedure,
(11) Miscellaneous Civil, and
Page 11 of 144
(12) Execution.
Based on the Criminal Code of Ethiopia, the Criminal Case Category is classified into
the following Case Types:
(1) Crimes against interests of the ‘State’,
(2) Crimes against interests of the ‘Community’,
(3) Crimes against interests of the ‘individual’, and
(4) Petty Offences.
2.2. Person Data Group:

The person data group includes:
• judge, parties on a case (i.e., plaintiff, defendant, third-party, etc.), advocate/attorney,
witness, participants, etc. for civil cases, and
• the judge, prosecutor, defendant, defense attorney, victim, witness, participants, etc. for
criminal cases.
2.2.1. Persons (Actors) in Civil Processes:
2.2.1.1.Civil – Ordinary – First Instance Processes:

Key persons (actors) in civil – ordinary – first instance processes:
1. Plaintiff:
a. Self-represented
b. Represented by advocate
2. Defendant:
a. Self-represented
3. Registrar,
4. Cashier,
5. Judge,
6. Person in possession of document/evidence, if any
7. Witness, if any
8. Interpreter, if any
Page 12 of 144
9. Clerk,
2.2.1.2.Civil – Ordinary – Appeal Processes:

Key persons (actors) in civil – ordinary – appeal processes:
1. Appellant:
a. Self-represented
2. Respondent:
a. Self-represented
3. Registrar,
4. Cashier,
5. Judge,
6. Person in possession of document/evidence, if any
7. Witness, if any
8. Interpreter, if any
9. Arbitrator,
10. Clerk.
2.2.1.3.Civil – Ordinary – Execution Processes:

Key persons (actors) in civil – execution processes:
1. Decree holder,
2. Judgment Debtor,
3. Registrar,
4. Judge of the court which executes the decree,
5. Judge of the court which passed the decree,
6. Execution officer,
7. Finance,
8. Property Administration,
9. Registry,
Page 13 of 144
10. Another person appointed to execute a decree,
11. Auctioneer,
12. Broker,
13. Expert,
14. Prison officer,
15. Person in possession of the property to be attached,
16. Objector,
17. Claimant,
18. Third party,
19. Purchaser
20. Dispossessed Person,
2.2.2. Persons (Actors) in Criminal Processes:

Key persons (actors) in criminal processes:
1. Police,
2. Public Prosecutor,
3. Accused Person or his/her Family,
4. Guarantor,
5. Witness,
6. Public Defender,
7. Private Prosecutor,
8. Private Complainant,
9. Prison Officer.
2.3. Event Data Group:

The event data group consists of data that contain information on past and future events
in a case, including:
• filings, hearing, trial, judgment, disposition, post-trial, other scheduled events, for civil
cases, and
• filings, hearing, plea, judgment, sentence, disposition, post-sentence, and other
scheduled events, for criminal cases.
Page 14 of 144
2.3.1. Events in Civil – Ordinary – First Instance Processes:
Key procedural events in Civil – Ordinary – First Instance process are:
1. Filing statement of claim (SoC),
2. Examining technical sufficiency of the SoC,
3. Payment of court fee,
4. Opening file,
5. Examining legal sufficiency of the SoC,
6. Examining pauper application, if any, and passing decision
7. Exchanging statement of claim (SoC), statement of defense (SoD), and evidences
between parties,
8. Examining preliminary objection, if any, and passing decision,
9. Framing of issues,
10. Hearing of the suit,
11. Examination of evidences and witnesses,
12. Stay, if any
13. Amendment of pleading, if any
14. Discontinuance, if any
15. Opposition, if any
16. Intervention, addition, or substitution, if any
17. Consolidation of suits, if any
18. Removal of judge, if any
19. Judgment,
20. Review of Judgments, if any
21. Execution
22. Closing the file.
Page 15 of 144
2.3.2. Civil – Appeal Process Events:
Key procedural events in Civil – Ordinary – Appeal process are:
1. Filing appeal,
2. Checking and passing decision on completeness and timeliness of the appeal,
3. Collecting court fee, if no pauper application filed
4. Opening the appeal case file,
5. Examining the legal sufficiency of the appeal,
6. Examining and passing decision on application to sue as pauper,
7. Receiving additional evidences, if any,
8. Hearing the appellant only and passing decision on whether to continue to hearing the
case,
9. Exchanging the appeal, reply, counter-reply (if any), cross objection (if any), reply on
the cross objection (if any), counter reply on the reply to the cross objection (if any)
10. Hearing the appeal, reply, counter-reply (if any), cross objection (if any), reply on the
cross objection (if any), counter reply on the reply to the cross objection (if any)
11. Examination of evidences,
12. Stay, if any
13. Amendment of pleading, if any
14. Discontinuance, if any
15. Opposition, if any
16. Intervention, addition, or substitution, if any
17. Consolidation of suits, if any
18. Removal of judge, if any
19. Judgment, Decision, and Order
20. Execution,
Page 16 of 144
2.3.3. Criminal Process Events:
Key procedural events in court related Criminal case processes are:
1. Search warrant, if any
2. Arrest warrant, if any
3. Getting court order to obtain evidence, if any
4. Recoding the accused statement by the court, if any
5. Remand,
6. Stay, Sequestration, or Confiscation of property,
7. Case filing,
8. Verify technical sufficiency,
9. Verify legal sufficiency,
10. Preliminary Inquiry, if any
11. Withdrawal, if any
12. Charge,
13. Pre-Trial (exchanging of Charge, Objection, Response, Counter- Response, etc.)
14. Hearing,
15. Decision on Objection,
16. Plea,
17. Examination of Evidence,
18. Acquittal, if any
19. Judgment,
20. Sentence,
21. Appeal.
2.3.4. Cassation Process Events:

1. Filing cassation application,
2. Verifying technical sufficiency,
3. Collecting court fee, for civil cases
4. Opening case file,
5. Scheduling hearing date for applicant,
Page 17 of 144
6. Hearing and Examination of Admissibility of the Cassation Application,
7. Determining the existence of Issue of Law,
8. Sending summon and cassation application to respondent,
9. Getting respondents reply,
10. Hearing and Examination of the Issue of Law,
11. Decision,
2.4. Financial Data Group:

The financial data group in civil and/or criminal cases consists of a single, all-inclusive
data type, the financial data type, which contains information on financial activities in a
case such as:
• payments, financial obligations, and accounting activities including single payments
(e.g., fees, fines, etc.) and installment payments (e.g., based on some judgments and
decisions),
• payment schedules/plans and payment collection methods,
• payment satisfaction (e.g. certificates of satisfaction of judgment),
• general ledger accounting,
• trust fund accounting, and
• fund’s relation to case, party, disposition, and other activities.
Page 18 of 144
3. Case Processing Events and Case Status:
3.1.Definitions Used for Case Events and Status:
3.1.1. Case Events:
3.1.1.1.Filing event:
A filing event occurs when an action is brought before the court as the result of a pleading,
petition, application, complaint or any other recordable action sufficient to begin a case.
The initiation of a case by whatever means is referred to as a filing event. In criminal
cases, the definition would include an arrest or summons or other action charging an
individual with a crime, as well as the filing of any other document or action recorded with
the court authorized to initiate a case.
Where the filling fulfills the requirements of the applicable procedure law, it results in
opening of case file.
An open case is a case that has one or more issues outstanding that require active resolution
by the court.
3.1.1.2.Disposition event:
A disposition event occurs when a case is closed for court activity as a result of judicial
decision, order, or other recordable action that provides resolution, by the court, on the
issues raised by and subsequent to the filing event.
A closed case is case that has had all issues raised by and subsequent to the filing event
resolved and no further action of the court is required.
3.1.1.3.Reopen event:
A reopen event occurs when a motion, pleading or other recordable action occurs on a case
that requires additional court activity after a disposition event has closed the case for court
activity. Note that a reopen event involves at least one action and that additional post-
judgment actions may occur before the case is reclosed.
Page 19 of 144
A reopened case is a case that has one or more post-judgment actions outstanding that
require active resolution by the court.
3.1.1.4.Reclosure event:
A reclosure event occurs when the last (or only) post-judgment action has been resolved
by judicial decision, order or other recordable action, thereby completing court proceedings
on the issues raised by and since the reopen event occurred.
A reclosed case is a reopened case that has had all post-judgment actions resolved and no
further action of the court is required.
3.1.2. Case Status:

3.1.2.1.Active:
A case is considered in an active status when the court is engaged in activity directly related
to the resolution of the specific matters and issues associated with the case. This status
applies to open cases in the period between the filing and disposition events.
3.1.2.2.Inactive (or suspended):

A case is considered in an inactive or suspended status when court activity on that case is
suspended pending resolution of an issue external to the court or that does not directly
involve the court in resolving that issue; for example, awaiting the results of an appeal or
the disposition of a related case. A case placed in an inactive status is not closed and does
not need to be reopened when the case returns to active status, regardless of the length of
time involved. This status applies on open cases in the period between a filing and
disposition event.
3.1.2.3.Closed:
A case is considered to be closed, or disposed, (that is, in a closed status) for court activity
on the date of the judicial decision, order or other recordable action that provides resolution
to the last (or all) of the matters brought before the court as a consequence of the filing
event that initiated the case. The court, then, has no further action to take on the case. This
status identifies a previously open case that has been resolved by the courts and applies to
the period between the disposition event and the first reopen event.
Page 20 of 144
3.1.2.4.Reopened Active:
A case will be considered to be in a reopened status (either active or inactive), from the
date that the first post-judgment motion/pleading is filed or other action occurs that reopens
a case for court activity (i.e. the reopen event) until the date of the last judicial
decision/order resolving all overlapping court proceedings (i.e. the reopen closure event).
Each period in which a case is reported as in a reopened status may involve one or more
overlapping post-judgment actions. A case is considered to be in a reopened active status
when one or more post-judgment actions are pending and the court is actively engaged in
their resolution. This status identifies a reopened case and applies to the period between
the initiating reopen event and the final reclosure event as described.
3.1.2.5.Reopened Inactive:
A case is considered to be in a reopened inactive status if the activity on all outstanding

post-judgment actions is held in suspense pending resolution of some issue external to the
court or that does not directly involve the court in resolving that issue. In this circumstance,
the court is not actively working to resolve the matter(s). This status identifies a reopened
case and applies to the period between the initiating reopen event and the final reclosure
event as described.
3.1.2.6.Reclosed:
A case that has had one or more post-judgment actions will be considered reclosed, or re-
disposed, (that is, in a reclosed status) for court activity on the date of the judicial decision,
order or other recordable action that provides resolution to the last (or all) of the matters
brought before the court since the reopen event occurred. The court, then, has no further
action to take on the case. This status identifies a previously reopened case with additional
matters that has been resolved by the courts and applies to the period between the reclosure
event and the next reopen event.
Page 21 of 144
3.2.High Level View of the Court Case Flows:
Page 22 of 144
Page 23 of 144
Page 24 of 144
Page 25 of 144
4. The Major Internal and External Users of iCMIS
R = Read Only
RW = Read & Write
Figure 5: External Users of the Courts’ System
Page 26 of 144
Figure 6: Internal Users of the Courts’ System
Figure 7: Very High Level INTRANET connectivity needs for iCMIS
Page 27 of 144
Figure 8: Very High Level INTERNET and VPN connectivity needs for iCMIS
5. The Envisaged High Level Architecture of iCMIS:
The overall information system of the courts would contain three major systems:
(1) Integrated Case Management Information System (iCMIS),
(2) Records Management Information System (RMIS), and
(3) Administrative and Finance Information System (AFIS).
iCMIS would consist of two major sub-systems:

(1) Electronic Filing and Litigation sub-system (eFLS), which would serve as the front-
end (front-office) system of iCMIS, specifically to be used for court filing and litigation
processes, and
(2) Case Management and Reporting sub-system (CMRS), which would serve as the back-
end (back-office) system of iCMIS, specifically to be used for case management and
report generation functions.
Page 28 of 144
AFIS is expected to serve four major groups of functions in the court organization, i.e.
(1) Budget, Disbursement, and Accounting,
(2) Human Resources Management,
(3) Procurement Management, and
(4) Property and Maintenance Administration.
Based on this, AFIS is expected to have two major sub-systems:
(1) Admin. & Finance Information sub-system (AFIS), which would be the front-end
system and
(2) Admin. & Finance Reporting sub-system (AFRS), which would serve as the back-end
system.
RMIS would serve both iCMIS and AFIS, as their respective records management system and
records repository. iCMIS need integration with AFIS due to case data group’s relation with
the person data group, whose internal actors (like Judge, Registrar, Assistant Judge, Bench
Clerk, etc.) detail data is maintained and managed in the Human Resources Management
system. On the other hand the case data group is related to finance data group due to the court
fees, security deposits, fines, execution related deposits, etc. that court receive and maintain in
their accounts. Property, which is also closely related to finance, is also related to the case data
group, due to case related property to be attached by the courts. Due to this there is a need to
integrate iCMIS with the Accounts part of the courts Budget, Disbursement, and Accounts sub-
system and the Property Management sub-system part of AFIS.
The following diagram provides overall view of the envisaged court systems to be put into
place.
Page 29 of 144
Figure 9: Overall Architecture of the Envisaged Court Systems (iCMIS, RMIS, and AFIS)
The Integrated Case Management Information System (iCMIS) would be the core system
within the court systems, as it would support the court’s core business, i.e., providing judicial
services and its corresponding case flow management efforts.
iCMIS shall be developed and implemented in a way that it can comprehensively support the
entire court business, i.e., it shall be designed and developed not only to support case-
processing transactions for individual cases but also to support operational controls,
management controls, and strategic planning. On the other hand, the iCMIS shall be developed
and implemented taking into consideration existing situations on which the system is expected
to operate.
Page 30 of 144
As the telecom VPN and internet services in Ethiopia face frequent interruption and
degradation of performance, it would be difficult to run iCMIS from central system only for
all courts spread in locations covering wide area. This is due to the fact that interruption and/or
slow performance in the system would highly likely result in degradation and/or stoppage of
services in the Courts, as the courts will depend on the central system not only for the software
but also for the data of the active files they would be working on.
To take care of the above constraining problem the system shall be designed having two
systems, Central System and Local System, which would be synchronized to each other twice
a day. The Central System is envisaged to be an all inclusive system (having both front-end
and back-end services) that is deployed in the Federal Courts' Data Centers which can be
accessible from both Internet and VPN, while the Local System is a cut down version of this
central system, that would be deployed locally in each area court with system and data for
active files of the specific area court at a given point of time. Under this arrangement, each
area court’s front office operations would use the Local system and avoid any risk of
interruption and/or performance downgrade on the VPN or Internet. On the other hand the data
in the area court’s Local System will be kept in sync with the Central system through
replication to be done twice a day, i.e., at noon and close of business day.
Figure 9 above, shows the Central System and Local System and their integration and
replication.
The three systems, i.e., iCMIS, AFIS, and RMIS would have tight integration with each other.
To this end, the envisaged iCMIS is expected to have API (Application Programming
Interface) to get linked with AFIS and RMIS.
Page 31 of 144
iCMIS
API API
RMIS API AFIS
Figure 10: Integration among iCMIS, RMIS, and AFIS
Figure 10 above, shows a high level schematic view of the required integration among the three
systems. Here it shall be noted that the scope of this project is limited to the development and
implementation of iCMIS and the development of its APIs for the internal integration with
RMIS and AFIS and external integration with the systems of the Attorney General Office
(the Public Prosecutor), Police, and Prisons Administration. The required API’s are
expected to be developed with the development of the iCMIS but the integration would be
done when the other systems are developed and become ready for integration.
In the following section, a more detailed view of the envisaged iCMIS to be developed is
presented through Use Case diagrams that are prepared for each major sub-system of the
envisaged iCMIS, based on the requirements defined in the Business Requirements Document
(BRD), which are in turn defined based on the Civil Procedure Code and Criminal Procedure
Code of Ethiopia.
6. Use Case Diagrams of Court Processes:
6.1.Civil Use Cases:
6.1.1. First Instance – Ordinary Procedure:
6.1.1.1. The following use case diagram specifies the envisaged software functional requirements
for the processes mainly described in the Civil Procedure Code Book IV: Ordinary
Page 32 of 144
Proceedings in First Instance - Chapter 1: Institution and Frame of Suit, (Art. 213 – 240),
which cover General Provisions and provisions on filing of Statement of Claim (SoC)
and Statement of Defense (SoD).
Page 33 of 144
for the processes mainly described in the Civil Procedure Code Book IV: Chapter 2: Trial
of Suit, which covers Articles 241 – 273, which cover Procedures at First Hearing and
Procedures for Hearing and Examination of Witnesses up to judgment.
Page 34 of 144
for processes on Execution of Payment of Money Decrees Passed in Ethiopia which are
described in the Civil Procedure Code Articles 394, 403, 405, 153, 186, 381, 384, and
386.
Page 35 of 144
Page 36 of 144
6.1.2. First Instance – Summary Procedure:
The following use case diagram specifies the envisaged software functional requirements
for Summary Procedure which are described in the Civil Procedure Code – Book IV:
Special Procedures – Chapter 1: Summary Procedure, which cover Articles 284 – 292.
Page 37 of 144
6.1.3. First Instance – Accelerated Procedure:
Page 38 of 144
The following use case diagram specifies the envisaged software functional requirements
for Summary Procedure which are described in the Civil Procedure Code – Book IV:
Special Procedures – Chapter 2: Accelerated Procedure (Art. 300-314).
Page 39 of 144
6.1.4. Appeal – Ordinary Procedure:
for the processes mainly described in the Civil Procedure Code Book V: Appeal,
Opposition, and Revision - Chapter 1 – Paragraph 1: Appeal from Judgment (Art. 320 –
331), which cover General Provisions for appeal. Though the articles under paragraph 1
are mainly applicable, other applicable articles in other parts of the civil procedure code
are also used.
Page 40 of 144
for the processes mainly described in the Civil Procedure Code Book V: Appeal,
Opposition, and Revision - Chapter 1: Appeal from Judgment – Paragraph 3 – Admission
and Hearing of Appeal (Art. 320 – 331), entitled for appeal. Though the articles under
Page 41 of 144
paragraph 3 are mainly applicable, other applicable articles in other parts of the civil
procedure code are also used.
Page 42 of 144
for the processes mainly described in the Civil Procedure Articles 91. Other related
provisions used are Articles 251, 329, and 330.
Page 43 of 144
for the processes mainly described in the Civil Procedure Articles 74.
Page 44 of 144
for the processes mainly described in the Civil Procedure Articles 11.
Page 45 of 144
for the processes mainly described in the Civil Procedure Articles 208 - 210.
Page 46 of 144
Page 47 of 144
for the processes mainly described in the Civil Procedure Article 41. Article 42 is also
considered.
Page 48 of 144
for the processes mainly described in the Civil Procedure Article 43.
Page 49 of 144
for the processes mainly described in the Civil Procedure Articles 332 - 335. Other
articles of the civil procedure code related to stay are also used.
Page 50 of 144
Page 51 of 144
Page 52 of 144
Page 53 of 144
Page 54 of 144
Page 55 of 144
for the processes mainly described in the Civil Procedure Articles 463 and 464.
Page 56 of 144
Page 57 of 144
Page 58 of 144
for the processes mainly described in the Federal Courts Proclamation No. 25/1996 and
applicable provisions of the Civil Procedure Code.
Page 59 of 144
Page 60 of 144
6.2.Criminal Use Cases:
6.2.1. The following use case diagram specifies the envisaged software functional requirements
for the court related processes on search warrant mainly described in the Criminal
Procedure Code (Draft) – Chapter 2 – Part 3.
Page 61 of 144
for the court related processes on arrest warrant mainly described in the Criminal Procedure
Code (Draft) – Chapter 2 – Part 6.
Page 62 of 144
for the court related processes on “court order to obtained evidence” mainly described in
the Criminal Procedure Code (Draft) – Chapter 2 – Part 2.
Page 63 of 144
for the court related processes on “Request to Record the Accused Statement by the Court”
mainly described in the Criminal Procedure Code (Draft) – Chapter 2 – Part 6 Art. 122.
Page 64 of 144
Page 65 of 144
for the court related processes on “Remand” mainly described in the Criminal Procedure
Code (Draft) – Chapter 2 – Part 6 Art. 119.
Page 66 of 144
for the court related processes on “Stay, Sequestration, or Confiscation of Property” mainly
described in the Criminal Procedure Code (Draft) – Chapter 2 – Part 6 Art. 119.
Page 67 of 144
for the court related processes on “Preliminary Inquiry” mainly described in the Criminal
Procedure Code (Draft) – Chapter 5 - Art. 119.
Page 68 of 144
for the court related processes on “Charge and Pre-Trial” mainly described in the Criminal
Page 69 of 144
Procedure Code (Draft) – Book 5, Chapter 1 – Section 2.
Page 70 of 144
for the court related processes on “Hearing, Evidence, Judgment, and Sentence” mainly
described in the Criminal Procedure Code (Draft) – Book 5, Chapters 4, 4, and 5 (Art. 252
Page 71 of 144
– 311).
Page 72 of 144
for the court related processes on “Appeal” mainly described in the Criminal Procedure
Code (Draft) – Book 7, Chapters 2 (Art. 336 – 353).
Page 73 of 144
Page 74 of 144
for the court related processes on “Cassation” mainly described in the Criminal Procedure
Code (Draft) – Book 7, Chapters 3 (Art. 354 – 364).
Page 75 of 144
Page 76 of 144
6.3.System Administration Use Cases:
ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice

for information security controls, recommends the separation of the systems administrator
role from the day to day user role and having a user with two accounts if they perform
different jobs on the same platform. Hence, separation of administrative interfaces from
common functions provided to users shall be mandated in the iCMIS application software.
In the following top level use case diagram and its subset use case diagrams which describe
functions by two actors, i.e. the iCMIS Administrator and Help Desk staff.
6.3.1. Administration Functions:
Page 77 of 144
Page 78 of 144
6.3.2. Register User and Login Functions:
Each user in iCMIS shall be registered user and logins shall be mandated either through
the courts VPN or through Internet, as depicted in the following use case diagrams.
Page 79 of 144
Page 80 of 144
7. Software Requirements Specification (SRS):
In this section the Software Requirements Specification (SRS) which describes the features of
the iCMIS software to be developed. The SRS is modeled after the business requirements
definition which is presented in a predecessor separate document entitled “The Ethiopian
Federal Courts’ Business Requirements Document (BRD) for Integrated Case Management
Information System (iCMIS)”. The SRS presented in this section specifies the
functional and non-functional requirements and also includes a set software features and
qualities that the software must provide to get the services expected from iCMIS.
Instruction:
(1) In the “Response” column, please enter “C” to indicate that the software developer will
comply to this specific requirement item, and “NC” to indicate that the software developer
will not comply to this specific requirement item.
(2) Please provide additional description to your response (if any), in the “Description of
Response” column.
Page 81 of 144
(“ C” or
Response
“ NC” )
Description
Feature ID Required Feature of the iCMIS Software
of Response
1. BASIC FUNCTIONS AND FEATURES

1.1. General
1.1.1 iCMIS (Integrated Case Management Information
System) shall provide its services in two major service
categories, namely, Electronic Filing and Litigation
Service (eFLS) and Case Management and Reporting
Service (CMRS). The eFLS shall focus on providing
front-end (front-office) operations to court users,
while the CMRS focuses on back-end (back-office)
services.
1.1.2 iCMIS shall enable the courts to automate cases
progress in courts which would involve tasks such as
the collection of case information at case initiation, the
scheduling of hearing, and the issuing of case
management orders that govern case progress to trial
or disposition, including the use of non-trial means.
1.1.3 iCMIS shall enable active judicial case management in
courts through automating the court processes that are
defined in the Federal Courts’ Integrated Case
Management System Business Requirements
Document (BRD) and providing all the needed courts
productivity and reporting tools.
1.1.4 iCMIS shall enable continuous control over court
processes in a manner that progress to each scheduled
control point or event triggers application of the next
scheduled control point.
Page 82 of 144
(“ C” or
Response
“ NC” )
Description
of Response
1.1.5 iCMIS shall enable the courts to implement

Differentiated Case Management (DCM), by
channeling processes of civil cases in courts, in three
tracks (i.e., (1) Ordinary, (2) Summary, (3)
Accelerated procedures) based on the subject matter of
the case.
1.1.6 iCMIS shall enable the courts to enter and maintain
overall and intermediate time standards for each of
milestone events in the progress of cases in courts (as
classified by DCM), from filing through disposition
and completion of all post-disposition court works.
1.1.7 iCMIS shall also enable courts to monitor cases
progress against the time standard and generate
relevant reports to the judges, registrars, and the courts
leadership.
1.1.8 As part of the overall case flow management in the
courts, iCMIS shall enable judges to execute proper
trial management practices that involve (1) activities
of preparation for trial, (2) scheduling to start trials on
time, (3) continuous monitoring and maintenance of
trial momentum, and (4) establishment and
enforcement of time limits.
Page 83 of 144
(“ C” or
Response
“ NC” )
Description
of Response
1.1.9 iCMIS shall enable the courts to exercise appropriate

case flow management practices in judgment
execution which may include:
a) monitoring court cases in their post disposition
status,
b) exercising court control over the pace of their post
disposition events,
c) managing the link of post disposition case to other
“cases”
d) determining when all court works would be done.
1.1.10 iCMIS shall enable both random and non-random
assignment methods for assigning cases to judges.
1.1.11 iCMIS shall provide the following selected key
performance measure reports to the courts: (1) Case
Clearance Rate, (2) On-Time Case Processing, (3)
Case Backlog, (4) Trial Date Certainty, (5) Average
Duration of Pre-Trial Custody, (6) Court User
Satisfaction, and (7) Court Employee Engagement, as
specified in a specification document submitted
together with this document.
1.1.12 iCMIS shall provide the capability to provide various
list reports, as specified in a specification document
submitted together with this document.
1.2. User Interface
Page 84 of 144
(“ C” or
Response
“ NC” )
Description
of Response
1.2.1 iCMIS must use tabbed browsing interface in order to

allow for multiple cases, names, calendars, and
dashboards to be accessed.
1.2.2 iCMIS must support Google Chrome, Microsoft Edge,
and Mozilla Firefox.
1.2.3 iCMIS must be fully accessible and usable via the web
by any authorized user with authorized access without
the purchase of additional thin-client software.
1.2.4 All screen displays, fields, coded values and system
views and user rights in iCMIS must be entirely
configurable by the application administrators in the
court in a way that provide each application user their
own view of the case management application based
on their roles and the roles group they belong to in the
courts. Such views and user rights shall be controlled
through the user’s login.
1.2.5 iCMIS must provide Court definable “dashboard”
functionality for each user group to display key
reports, searches and displays providing the user a
view of their cases, calendar, and reports.
1.2.6 iCMIS must provide global, web-style searching
which ranks, sorts and lists search results to quickly
locate case records, sorted by case number and
litigants’ name. Each search result must be
hyperlinked for quick access to case record details.
Page 85 of 144
(“ C” or
Response
“ NC” )
Description
of Response
1.2.7 For summary reports, iCMIS shall provide drill down

functionality to display the details of the summary by
clicking on the summary result.
1.2.8 For list reports, iCMIS shall provide hyperlink
functionality to open up case record(s) by clicking on
a hyperlinked case number or litigant name.
1.2.9 iCMIS shall provide automated, scheduled email
reporting to Presidents, Judges, and Registrars, on
selected reports.
1.2.10 In addition to tabular summary and list reports, iCMIS
shall provide reports with graphs using vertical bar
charts, horizontal bar charts, pie charts, line charts, and
scatter plot.
1.2.11 iCMIS shall provide the ability to print all report
contents on paper or PDF and export to Excel, XML,
and CSV formats.
1.2.12 iCMIS must include the ability to electronically route
cases, work tasks and notify system users of those
routed items. Users can navigate directly to routed
cases and work tasks via hyperlink.
1.3. Search
1.3.1 iCMIS must provide for the easy retrieval of
information by using on-screen, web style searching
where any relevant case/matter information is ranked,
sorted, and hyperlinked for access.
Page 86 of 144
(“ C” or
Response
“ NC” )
Description
of Response
1.3.2 iCMIS must provide the ability to search for records

using almost any data or combination of data
contained within the case record(s).
1.3.3 iCMIS must provide the ability to search on parts of
names, addresses, and other data elements and export
all search results.
1.3.4 iCMIS must provide the ability to search on any
combination of applicable fields (e.g., case
type/category, status, adjournment date, judge, bench,
etc.) fields and export all search results to PDF, Excel,
XML, or CSV formats.
1.3.5 iCMIS must provide for easy retrieval of information
by using on-screen searching.
1.3.6 iCMIS must be capable of restricting searches
performed by system users, or groups based on user
roles and rights defined by the Application
Administrator.
1.3.7 iCMIS must provide the ability to search on ranges of
information in applicable fields, such as range of
dates, range of continuances, range of adjournment
dates, etc.
1.4. Security
1.4.1 iCMIS must support a three tier deployment, i.e., it
must be developed such that it can be split into three
separate tiers of Web, App and Database.
Page 87 of 144
(“ C” or
Response
“ NC” )
Description
of Response
1.4.2 iCMIS must have integration with LDAP with TLS for
authentication. It must support LDAP (Lightweight
Directory Access Protocol) with TLS (Transport
Layer Security) for centralized authentication and web
access control of both application users and
administrators.
1.4.3 iCMIS Audit Logs shall output to Syslog. The system
must provide comprehensive auditing & logging that
gives iCMIS administrators a granular view of what
data is being edited, viewed, deleted and added by
system users. The system must have the ability to
generate audit logs and forward those logs to a central
log server.
1.4.4 iCMIS must have support for the network time
protocol (NTP).
1.4.5 iCMIS must support encryption on storage. The
system must have native support for file or database
level encryption on storage. The encryption must be of
an appropriate strength (at least 128bit) and standards
based (non proprietary).
1.4.6 iCMIS must natively support encryption on
transmission. In the very least, support shall be in
place for server to user communication, web
administration, and web services (HTTPS over Soap).
1.4.7 iCMIS must have support for security key control and
key management. Keys shall be kept in split
Page 88 of 144
(“ C” or
Response
“ NC” )
Description
of Response
knowledge method or dynamically created to promote

secure storage.
1.4.8 iCMIS must support role based policies for
administration. Administration of iCMIS shall support
different users with different roles, and support for
security, admin, and auditor roles.
1.5. Scalability
1.5.1 iCMIS must be scalable, i.e., it must be able to handle
an increase in workload without performance
degradation, with its ability to quickly enlarge, so as to
accommodate more users, more processes, more
transactions, and additional nodes and services as the
business requirements change and as the system
evolves to meet the future needs of the courts business.
1.5.2 iCMIS must have multi-tier (N-tier) architecture to
enable scalability. The application must be engineered
to have multi-tier (also called N-tier architecture) in
that the processing, data management, and
presentation functions shall be physically and
logically separated.
1.6. Performance
1.6.1 iCMIS must be able to provide 5 (five) seconds or less
page load time for web applications on computers or
mobile devices connected to the system using the
courts LAN (Local Area Network) and/or WAN
(Wide Area Network) and 10 (ten) seconds or less on
Page 89 of 144
(“ C” or
Response
“ NC” )
Description
of Response
computers or mobile devices connected to the system

through the internet.
1.6.2 iCMIS must be designed using responsive website
design so that the website (and its pages) can adapt and
deliver the best experience to users, whether they’re
on their desktop, laptop, tablet, or smart-phone.
1.7. High Availability
1.7.1 Except the period (about 2 months, every year) when
the courts will be partially closed based on their annual
calendar, iCMIS must be fully available and provide
24 x 7 services, throughout the year.
1.7.2 iCMIS must be able to be deployed and run on two
clustered servers each at the primary and disaster
recovery data center (DC) sites. The application must
be able to run in parallel on the two clustered servers
in the primary DC site either in Active-Active mode
(with load balancer enabled) or Active-Passive mode
(with failover enabled). In case where the entire
primary DC site goes down, the application shall be
able to switch to the disaster recovery (DR) site and
continue providing services.
1.8. Interoperability
1.8.1 iCMIS must provide Private APIs (Application
Programming Interface) for future integration with
additional systems or applications of the courts (like
HR, Finance, etc. applications) and building new
Page 90 of 144
(“ C” or
Response
“ NC” )
Description
of Response
systems or customer-facing apps for the courts

leveraging on the iCMIS. In this case iCMIS will be
the Publisher API while the additional/new systems
will be subscribers.
1.8.2 iCMIS must provide Partner APIs (Application
Programming Interface) for interfacing with other
criminal justice institutions, i.e., the Attorney General
Office/Public Prosecutor, Police, and Prisons. In case
of using Partner APIs, iCMIS shall remain to be the
API publisher, while the partner institutions systems
will be subscribers.
1.9. Modularity
1.9.1 At the highest level, iCMIS must have front-end
(front-office) system on which the day-to-day service
to court users is provided which is separate from the
back-end (back-office) system on which the back-
office operations are to be done. In addition iCMIS
shall be divided into central and local system, as
described below.
1.9.2 Due to the slow and frequently interrupted internet and
VPN connection in Ethiopia, the iCMIS system shall
be designed having two deployments, i.e., (1) central
deployment in the Primary and DR datacenters for all
cases files (i.e., for both active, inactive, opened, re-
opened, closed, or re-closed), (2) local deployment in
the Local servers located in each area court for active
Page 91 of 144
(“ C” or
Response
“ NC” )
Description
of Response
only case files (i.e., opened or re-opened and currently

undergoing service in the courts )with local
application and database for currently active files only.
The central system will have both the front-end and
back-end systems of iCMIS, while the local system
will have only the front-end systems of iCMIS. iCMIS
users working from inside each area court will provide
their day-to-day customer facing services to court
users using the iCMIS – Local, accessing the system
through their LAN. To access the back-end systems
for certain back office services, such as case
management, reporting, etc. they will access Central
System through the VPN. As the back-office services
aren’t client facing like the front-end services, even if
interruption occurs on the VPN, the courts service will
not be interrupted. There must be two-way replication
between the Local and Central systems two times a
day, i.e., at Noon and Close of business day. External
users accessing the iCMIS system with Read, Write or
Both rights, shall access iCMIS through the Central
system.
1.9.3 iCMIS must have Civil and Criminal cases sub-
systems, so that system deployment for each area court
can be tailored based on the availability of benches for
Civil, Criminal, or Both.
Page 92 of 144
(“ C” or
Response
“ NC” )
Description
of Response
1.9.4 The entire system shall be designed modular and with

reusable components.
1.10. Usability
1.10.1 iCMIS must be easy to learn for both new and
experienced computer users.
1.10.2 iCMIS must be efficient for the frequent user, i.e., it
shall take very short time for executing ordinary tasks.
1.10.3 iCMIS must be easy to remember, how its different
functions work, for the casual user.
1.10.4 iCMIS must be easy to understand what the system
does, for the casual user.
1.11. Flexibility
1.11.1 iCMIS must support multiple local languages. To this
end for every English term used for look-up and
transactional data to be used in the system and the
menu and other user interface items, the system shall
support translation into multiple local languages.
1.11.2 iCMIS must support the following Unicode
characters, based on the Unicode 13.0 Character
Code Charts (Code Charts (unicode.org):
1. Latin
2. Ethiopic
Based on the language selected at login, the
appropriate character sets shall be used for user
interface elements, meta data, lookup data (master data
and reference data), and transactional data.
Page 93 of 144
(“ C” or
Response
“ NC” )
Description
of Response
1.11.3 iCMIS must be designed to be flexible to

accommodate future changes or upgrades based on
user requirements.
2. ELECTRONIC FILING AND LITIGATION SYSTEM (eFLS)
2.1. Electronic Filing (eFiling)
2.1.1 iCMIS shall include an electronic filing and litigation
system (eFLS) web portal.
2.1.2 eFLS shall have full integration with the Case
Management and Reporting System (CMRS) of
iCMIS, Electronic Records Management System, and
Finance System of the Federal Courts.
2.1.3 iCMIS’s eFLS portal shall have full integration with
the digital certificate, encryption, and time stamp
services of the certificate provider of the courts.
2.1.4 iCMIS’s eFLS portal shall have functionality for
recording by parties and/or their advocates, payment
transaction reference number, purpose and amount for
payments that are made to the courts and also attach
evidences of such payments issued by the payer bank.
2.1.5 iCMIS’s eFLS web portal shall have functionality for
registering licensed advocates as Registered Users of
the system and periodically renewing this registration,
so that they can be able to electronically file their case
and participate in the litigation process through eFLS.
2.1.6 iCMIS’s eFLS web portal shall have a functionality
for registering and periodically renewing this
Page 94 of 144
(“ C” or
Response
“ NC” )
Description
of Response
registration for partners or employees of Registered

Users so that they can be enrolled as authorized user(s)
of the eFLS
2.1.7 iCMIS’s eFLS web portal shall enable parties and/or
their advocates to electronically file any pleading,
petition, application, request, annex, or any other
documents on order of the court for conducting
litigation process.
2.1.8 iCMIS’s eFLS portal shall be able to send to the filer,
automatic electronic confirmation of the filing made,
which will be used as a proof of service of a document
that has been served to the courts through eFLS.
2.1.9 iCMIS’s eFLS portal shall enable the Registrar for
sending notification of acceptance or rejection of the
document to the authorized user through his/her page
on eFLS.
2.1.10 iCMIS’s eFLS web portal shall enable courts to serve
notice, order, judgment, or other document, by
electronic means.
2.1.11 iCMIS’s eFLS web portal shall support eFiling
scanned documents prepared in text-searchable
PDF/A format that is compatible with the latest
version of Adobe Reader.
2.1.12 iCMIS’s eFLS web portal must record the exact date
and time of each document lodgment by any
party/advocates as well as the exact date and time of
Page 95 of 144
(“ C” or
Response
“ NC” )
Description
of Response
issuance of any document issued by the courts, in the

format DD-MM-YYYY for the date and in 12 hours
format using HH:MM:SS followed by AM or PM for
time. The system shall convert such date and time to
Ethiopian date and time formats and store the same in
iCMIS databases and also display to users.
2.1.13 iCMIS-eFLS shall enable any filer shall be able to get
any eFLS generated automatic notification and/or any
notification, response, or document issued from the
Registrar or Judge, in its case file page under his/her
eFLS page.
2.1.14 iCMIS-eFLS shall be able to check the size of each
document to be submitted through eFLS against the
maximum size of documents allowed, before the
document upload process starts. If the document size
is above the maximum allowed, iCMIS-eFLS shall not
upload the document and return a message to the filer
to reduce the size at most to the maximum allowed.
2.1.15 Before uploading any file, iCMIS-eFLS shall require
the filer to confirm that the document doesn’t contain
any material that is under seal (i.e., to be kept
confidential by court order), including documents filed
under seal in lower courts.
2.1.16 Before uploading any affidavit, iCMIS-eFLS shall
require the filer to confirm the following:
Page 96 of 144
(“ C” or
Response
“ NC” )
Description
of Response
• The affidavit is sworn-in in the usual way in which

the deponent signs the original paper affidavit,
• The affidavit being uploaded is a true and
complete electronic image of the original paper
affidavit created.
2.1.17 iCMIS-eFLS will be used as proof for delivery of
document from filers to the court and vice versa. For
this reason, iCMIS-eFLS shall keep all meta data that
will describe the document submitted, including date
and time stamps.
2.1.18 iCMIS-eFLS shall be integrated with the courts’
antivirus software so that each document being filed
through eFLS can be scanned and confirmed it is free
from any virus and malware before it is uploaded into
the court systems.
2.1.19 iCMIS-eFLS shall keep log of all efiling transactions,
whether they are successfully filed or failed to file. In
case of failure to file, the system shall record the
reason for the failure.
2.2. Electronic Documents
2.2.1. Document Generation
2.2.1.1 iCMIS must include a utility that provides for
automatic document and form generation using data
contained in iCMIS.
2.2.1.2 iCMIS must allow fillable PDF forms to be created
from within the application.
Page 97 of 144
(“ C” or
Response
“ NC” )
Description
of Response
2.2.1.3 iCMIS must allow filled PDF forms to be

automatically linked to a case file for future reference.
2.2.1.4 iCMIS shall support the capability to issue and
electronically sign court orders, decisions, judgments,
and sentences.
2.2.1.5 iCMIS shall support the capability to obtain electronic
signatures on documents from litigants, through
signature pads or other electronic signature capture
tools.
2.2.1.6 iCMIS must allow for the digitally signing of
automatically created documents.
2.2.1.7 iCMIS must include integrated electronic document
management functionality including: (1) Integrated
document scanning, (2) Document routing, (3)
Document indexing, (4) Document searching, (5)
Ability to perform redaction and other editing
functions authorized by the judge in charge of the case.
2.2.1.8 iCMIS must provide for the Application
Administrators to have the ability to create additional
form and report templates that can be utilized by
system users.
2.2.1.9 iCMIS must allow for documents and forms to be
automatically generated based on event and rules
configured in the system.
Page 98 of 144
(“ C” or
Response
“ NC” )
Description
of Response
2.2.1.10 iCMIS must be able to generate identifier labels for

manual case files, including the potential use of bar
codes, QR codes, and RFID codes.
2.2.1.11 iCMIS must maintain location information for hard
copy files (e.g., storage facility location, row and shelf
identifier, person in custody of the file, etc.).
2.2.1.12 iCMIS shall provide the capability to prepare standard
forms, reports, and letters with data retrieval from the
case management system.
2.2.1.13 iCMIS shall provide security and audit trail
capabilities to ensure that the digital signature is
applied by the right person and that the timing and
intention is logged as part of the case data if the
signature is ever challenged.
2.2.1.14 iCMIS shall provide the capability to quickly make
permanent changes to a document, including applying
check-marks, official stamps, and keying new data
onto the document during the electronic signing
process. Where it is necessary and authorized by
judge, it shall support redacting information and
strike-through on the document. iCMIS shall support
all changes made during such processes to be logged
in the permanent audit trail of the document and
versions of the document before the change is kept as
part of the record.
Page 99 of 144
(“ C” or
Response
“ NC” )
Description
of Response
2.2.1.15 iCMIS shall support fully-featured word processor to

draft notes, letters, orders, decisions, judgments, and
sentences.
2.2.1.16 iCMIS shall support the capability to search other
authored documents and use them as a reference to
create a new one.
2.2.1.17 iCMIS shall support the capability to create documents
by merging a template with data already stored in other
databases (case management system, records
management system, etc.). Document creation shall
have the ability to be performed automatically, in
batches, or as a single document.
2.2.1.18 Document notes in iCMIS shall be an overlay on the
document and not be permanently burned into the
document, except in the case of a permanent redaction
(e.g. to hide highly secret information). iCMIS shall
provide the capability for users to be able to quickly
view the original document without annotations, and
print with or without annotations.
2.2.1.19 iCMIS shall provide the capability for document notes
to automatically capture the date, time, and author of
the notes.
to be editable by authorized users, with all interaction
tracked for auditing purposes.
Page 100 of 144

(“ C” or
Response
“ NC” )
Description
of Response

to allow different security levels so that certain notes
may be made more secure than others.
to be automatically applied by the system in
circumstances, like stamping a document as
“received” or putting a timestamp when changing a
document.
2.2.1.23 iCMIS shall provide the capability for document
redactions as a special type of document note that
allow for the creation of a version of the document
with the redaction made permanent (Example: for
documents containing highly confidential
information).
2.2.2. Document Access and Viewing
2.2.2.1 iCMIS judicial tools which are aimed at providing
judges with access to electronic documents shall
include the capability:
(1) to search/filter documents by document title,
content, and annotations,
(2) for multiple presentation options: index-based
view as well as thumbnail view of documents,
(3) to annotate documents, highlight and create
individual notes by the judge working on the case,
(4) to create standardized list view of documents for
review by case type, category or class code,
Page 101 of 144

(“ C” or
Response
“ NC” )
Description
of Response
(5) to access all electronic documents including

transcripts and exhibits,
(6) to a complete versioning display allowing users to
view all changes made to the document, and
(7) to determine the correct or most current version of
a document.
2.2.2.2 All files, documents, and other files that are stored in
the “electronic” case file folders must be able to be
searched via a web-based document, file searching
method.
2.2.2.3 iCMIS shall provide the capability for users to be able
to see all document notes in a concise fashion, with the
ability to sort by date and author.
2.2.2.4 Document notes shall be searchable by authorized
users. The searching capabilities must respect security
restrictions.
2.2.3. Delegation and Permissions
2.2.3.1 iCMIS shall provide Judges the ability to set
delegation and permissions to others to work on their
active cases, through the iCMIS application.
2.2.3.2 iCMIS audit report shall accompany the electronic
signing application to provide judges with information
on delegated signature for all electronically signed
documents. Digitally certifying these documents will
ensure all documents stored in the document
Page 102 of 144

(“ C” or
Response
“ NC” )
Description
of Response
management system are genuine and authentic court

documents.
2.3. Benches/Judges Work

2.3.1. Judicial Workflow and Productivity Tools
2.3.1.1 iCMIS shall enable judicial workflow, wherein the
workflow can be set up in a manner that approved or
signed matters can be passed along to appropriate
individuals (e.g., registrar, bench clerk, parties,
advocates, etc.) after they are completed by the judge.
2.3.1.2 iCMIS workflow process shall provide a mechanism
to assign a case or document to the proper person
either manually or automatically (based on business
rules), track where the file is currently assigned, who
is working on what aspect of the case file or document,
and what is the next step.
2.3.1.3 iCMIS shall enable judges, registrars, and staff to
manage a case from filing to disposition using
workflow queues. iCMIS judicial workflow tools shall
provide each judge, registrar, and staff with ready
access to work that is in a queue where action is
required.
2.3.1.4 iCMIS judicial workflow shall provide judges with a
simple view of work in queue and a minimal number
of queues to monitor, so that performance of such tasks
Page 103 of 144

(“ C” or
Response
“ NC” )
Description
of Response
would be simplified to as few steps, touches, or clicks

as possible.
2.3.1.5 iCMIS shall provide the ability for a judge to manage
matters taken for further deliberation, which may
mean placing a matter in a pending status for a pre-
determined period of time, while keeping the matter
alive in the system so that it is not forgotten.
2.3.1.6 iCMIS workflow tools shall be configurable (as
opposed to requiring software development) to
implement workflow process changes, from time to
time.
2.3.1.7 iCMIS shall use workflow rules to manage the
progress of tasks from one step to the next. For
example, a new case shall only be presented to a judge
after completing technical sufficiency verification by
the registrar).
2.3.1.8 iCMIS shall present to judges a queue containing all
documents that are waiting for review or signature.
2.3.1.9 iCMIS shall provide the ability to retrieve, complete
and enter electronic documents by judges.
2.3.1.10 iCMIS shall provide Judges with the ability to submit
documents back to other queues for review.
2.3.1.11 iCMIS shall provide to judges task lists for managing
their activities and decisions points.
2.3.1.12 For judges who will need or want to work off-site,
iCMIS shall be capable of providing them with tools
Page 104 of 144

(“ C” or
Response
“ NC” )
Description
of Response
that allow the appropriate remote access to their case

file, related cases, and court information, with
properly encryption and security embedded in the
system, to protect against any fraudulent use.
2.3.1.13 iCMIS shall provide the ability of direct
communication among judges to share information or
content, including text documents, photos, audio,
video, and other complex data.
2.3.1.14 iCMIS shall provide access to information and alerts
for activities and decision points that occur between
formal judicial actions.
2.3.1.15 iCMIS shall offer Judges the ability to link elements in
the database (build query) and get their custom reports,
or perform searches and generate list view of certain
cases, or summary view of certain types of cases of a
certain age, etc.
2.3.1.16 iCMIS shall enable judges who will need or want to
work off-site to be provided with tools that allow the
following:
(1) Ability to read, approve, sign, and electronically
transmit a document remotely.
(2) Security and Audit trail to protect the integrity of
the event.
(3) Ability to communicate directly to police,
prosecutor, or defense counsel, and to directly
Page 105 of 144

(“ C” or
Response
“ NC” )
Description
of Response
share information or content, including photos,

videos and other complex data types.
2.3.1.17 iCMIS shall provide to judges, live, secure, and
reliable audio-video access to jails and litigants
coming from remote places, with a view to support
conducting remote proceedings.
2.3.1.18 iCMIS shall provide document packet creation tools
(pack and go file management feature) that will auto
generate the required documents in a case file.
2.3.1.19 iCMIS shall allow the Judge and the registrar to
electronically sign documents in the packet.
2.3.1.20 iCMIS shall enable all judicial notes whether taken
during hearings and trials or while working from
office, or anywhere to be linked to the case and
available from the dashboard or the judge’s screen.
2.3.1.21 iCMIS shall enable case file notes to be easy to view
and in most cases to be the first thing that is displayed
when the electronic case file is opened.
2.3.1.22 iCMIS shall provide capability for case file notes that
allow a free-form text box with a large capacity of
characters (16K or more). Ability for rich text in the
text box is a desired feature to support some basic
word processing constructs (such as color,
highlighting, underlining, bullets, etc.).
2.3.1.23 iCMIS shall provide capability for case file notes to be
searchable.
Page 106 of 144

(“ C” or
Response
“ NC” )
Description
of Response
2.3.1.24 iCMIS shall provide capability for case file notes to

automatically capture the date, time, and author.
2.3.1.25 iCMIS shall provide capability for case file notes to be
only editable by the original author.
2.3.1.26 iCMIS shall enable all interactions on case file notes
to be tracked for auditing purposes.
2.3.1.27 iCMIS shall enable varying security levels to case file
notes so that certain notes are more secure than others.
2.3.1.28 iCMIS shall enable users to see all case file notes in a
concise fashion, with the ability to sort by date and
author.
2.3.1.29 In iCMIS, the private notes a judge taken any note-
taking program during a hearing or trial shall be
accessible directly from the judge’s screen for the case
with the contents private and accessible only by the
judge or his/her delegate(s).
2.3.1.30 iCMIS shall enable case file notes to be searchable by
authorized users only, with the right security
restrictions.
2.3.1.31 iCMIS must provide Rich Text Formatted (RTF)
entry for case notes.
2.3.1.32 iCMIS must provide system username and date
stamping for case notes.
2.3.1.33 To improve user efficiency, iCMIS document
management system shall be able to automatically
Page 107 of 144

(“ C” or
Response
“ NC” )
Description
of Response
apply certain case file notes based on case information

that is present in the documents.
2.3.1.34 iCMIS shall provide capability for rapid text dialog,

such as instant messaging, among judges and judicial
and non-judicial court staff. The text dialog shall be
enhanced with the ability to support hypertext links
that reference documents and other case information.
2.3.1.35 iCMIS shall provide multi-media communication
using IP based audio-video technology for judges and
judicial staff. Such tools shall be able to support a text
dialog in parallel for presenting exhibits.
2.3.1.36 iCMIS communication capabilities shall be tightly
integrated with the courts' workflow.
2.3.1.37 iCMIS shall provide tools that allow customer-
friendly collaboration with parties and the public in the
modern electronic technology supported court. For
example, these tools shall allow the public and parties
to see schedules, check-in for a case, pay fees and
fines, etc.
2.3.1.38 iCMIS communication safety and security shall be
compliant with international best practices and
regulations in Ethiopia.
2.3.2. Legal Research
2.3.2.1 iCMIS shall provide judges with access to
knowledgebase of past judgments, decisions
(including cassation decisions), sentences, orders,
Page 108 of 144
(“ C” or
Response
“ NC” )
Description
of Response
opinions, laws, regulations, and legal research

materials
2.3.2.2 iCMIS shall provide judges with access to the full case
file including recordings/transcripts
2.4. Financial and Fee Tracking
2.4.1 iCMIS must include an integrated financial module
for records, tracking and managing court defined
fees, fines, witness/commission expenses, security
deposits, and any other collections (payments into)
the courts. A third party product will not be
accepted.
2.4.2 The integrated financial module must utilize the same
name and addresses database used by iCMIS.
2.4.3 The financial module integrated in iCMIS must have
the capability that provides for the collection and
allocation of payments paid by court involved parties.
2.4.4 The financial module integrated in iCMIS must have
the capability to print official receipts for payees,
each receipt having a unique reference number.
2.4.5 iCMIS shall have the capability for any entry,
change/update, or deletion of data in the financial
module to be used only by specific authorized users in
the courts. Except these authorized users, iCMIS shall
be able to restrict all other users of the application
software including administrators, to have only view
access on to such financial data.
Page 109 of 144

(“ C” or
Response
“ NC” )
Description
of Response
2.4.6 iCMIS shall have the capability to always keep audit

logs of such operations in the financial module.
2.4.7 iCMIS must have the capability or a module that
provides for court defined installment payment report
generation and printing. Report must include the
following information: (1) Payee Name, (2) Payee
Address, (3) Case Number, (4) Total Amount to be
Paid, (5) Total Amount Paid to Date, (6) Total Amount
Remaining, (7) Set Amount of Payment, (8) The Last
Payment Date, (9) The Last Payment Amount
2.4.8 iCMIS must be able to compute/calculate and enter
court fees, fines, witness/commission expenses,
security deposits, and any other collections (payments
into) the courts.
2.4.9 iCMIS must allow printing of receipts based on
reference number of payment into the bank account of
the concerned court or online notification of
confirmation of such collection by banks or other
institutions delegated by the court.
2.4.10 iCMIS must associate payment with proper case and
party when funds are collected.
2.4.11 iCMIS must allow for full, partial, and installment
payments by various methods.
2.4.12 iCMIS must allow multiple types of payments in
single transaction.
Page 110 of 144

(“ C” or
Response
“ NC” )
Description
of Response
2.4.13 iCMIS must compute totals, list transactions, and

balance for each cashier and payment type (e.g., court
fee, fine. Security deposit, etc.).
2.4.14 iCMIS must permit transactions that arrive after end-
of-business day close-out to be entered as transaction
for next day.
2.4.15 iCMIS must generate and print (including ability to
reprint) receipts for any collection received by the
court.
2.4.16 iCMIS must establish, maintain, and track multiple
bank accounts used by the courts for collection of
court fees and other types of collections.
2.4.17 iCMIS must be able to print system-wide daily cash
receipts journal.
2.4.18 iCMIS must be able to produce detailed and summary
lists of financial transactions (e.g., voided transactions
listed by type or chronologically) for specific accounts
over specific periods (e.g., daily, monthly, for life of
case).
2.4.19 iCMIS must allow flexible, user-defined and
maintained account structure that permits funds to be
distributed to the appropriate payer based on court
order.
2.4.20 iCMIS must compute and produce costs and fees
based on the occurrence of specific court events.
Page 111 of 144

(“ C” or
Response
“ NC” )
Description
of Response
2.4.21 iCMIS must be able to produce detailed and summary

lists of financial transactions (e.g. court fees, fines,
deposits, monetary judgments, installment payments,
payments due, voided transactions, etc.) for specific
cases and parties over specific periods (e.g., daily,
monthly, for life of case).
2.4.22 iCMIS must be able produce documents such as
payment notices.
2.4.23 iCMIS must be able to create payment schedules,
collect payments, apply payments collected to
scheduled amount due (e.g., amount in judgment) and
produce reports on overdue amounts (e.g., for
previously waived fees).
2.4.24 iCMIS must be able to identify (i.e., input or compute)
and record payment delinquencies, generate alerts
when scheduled payments are not made (e.g., for
unpaid assessments now due), and take or prompt user
to take appropriate action (e.g., notify appropriate
court and judge).
2.4.25 iCMIS must allow for specific periods: produce
separate reports showing restitution received and
moneys disbursed (by victim) for each case or
offender.
3. CASE MANAGEMENT AND REPORTING SYSTEM (CMRS)
3.1. Calendars and Events
Page 112 of 144

(“ C” or
Response
“ NC” )
Description
of Response
3.1.1 iCMIS shall support both individual and master

calendars of courts.
3.1.2 iCMIS shall provide feature of variety of calendar
views displayed in many different formats, by day,
week, and month.
3.1.3 iCMIS shall offer graphical representations capability
for looking at many calendar days simultaneously, as
well as viewing for each specific date in the calendar:
what cases will be heard, the judges, the court room,
time, parties attending, and reason for the calendar
item.
3.1.4 To assist the Judge in scheduling activities, iCMIS
shall indicate the number of cases queued up for the
morning and afternoon time block of each working
day, the already given schedules for each business day,
and status of court room occupancy by time range for
each business day. The system shall offer color-coding
capability to indicate over-scheduled dates and
courtroom occupancy information.
3.1.5 iCMIS shall provide to graphical view of all court and
non-court schedule events
3.1.6 iCMIS shall provide graphical view for a day, week,
and month views
3.1.7 iCMIS shall provide the ability to display the length of
time allocated for a scheduled event
Page 113 of 144

(“ C” or
Response
“ NC” )
Description
of Response
3.1.8 iCMIS shall provide the ability to display gaps in

hours where no scheduled events occur
3.1.9 iCMIS shall provide the ability to display overlap or
conflicts between two scheduled events
3.1.10 iCMIS shall provide the ability to export calendar data
in different formats for personal calendars or mobile
devices (example: iCalendar Feed)
3.1.11 iCMIS shall provide the ability to access judge’s
comprehensive calendar, particularly if he or she
presides in multiple jurisdictions, to ensure no
conflicts exist when scheduling future hearings in
other locations.
3.1.12 iCMIS shall provide the ability for judges to see their
personal calendar overlaid onto their work calendar.
3.1.13 iCMIS shall provide judges and concerned court staff
the ability of access to case information and electronic
documents from calendar event
3.1.14 iCMIS shall provide judges with the ability to
schedule for any future events.
3.1.15 iCMIS shall provide case management tools that allow
calendars to be reorganized in the courtroom for the
purpose of fluid courtroom management without
changing the original calendar.
3.1.16 iCMIS shall provide workflow tools that allow many
scheduled items to be managed by a central
“dispatcher”, in a manner that allows the judge and
Page 114 of 144

(“ C” or
Response
“ NC” )
Description
of Response
judicial staff to see the schedule and to rearrange tasks

or events.
3.1.17 iCMIS shall provide graphical view that displays the

total number of cases scheduled cases vs. the total
number of scheduled and available court hours.
3.1.18 iCMIS shall provide configurable list view that
provides key data fields by case type to allow
processing of case from calendar when possible.
3.1.19 iCMIS shall provide access to additional case
information and electronic documents from calendar
event.
3.1.20 iCMIS shall provide the ability to display modified
calendars and calendar status information.
3.1.21 iCMIS must provide the ability to initiate schedule of
future tasks on individual or group events based on
occurrence of prior tasks or events (e.g., schedule
appearances after admission event of a case occur)
based on court defined business rules.
3.1.22 iCMIS must permit users to designate cases with
special scheduling needs.
3.1.23 iCMIS must produce schedules for individuals, events,
tasks, and dates upon user request (e.g., judge’s
schedule by date). These schedules must be printable,
exportable to Excel, Word, PDF, and must be web-
accessible.
Page 115 of 144

(“ C” or
Response
“ NC” )
Description
of Response
3.1.24 iCMIS must allow for the publishing and display of

calendar information via a publicly accessible web
site.
3.1.25 iCMIS must allow calendars to be created individually
or by batch according to various criteria including
date, judge, or courtroom.
3.1.26 iCMIS must have the ability to distribute calendars
electronically to concerned judges, registrars, court
managers, judicial support staff, advocates, and
parties.
3.2. Case Management
3.2.1 iCMIS shall provide each judge with ready access to
case management information relative to time
standards and benchmarks.
3.2.2 iCMIS shall provide the ability to toggle between view
of entire list of cases by judge and only cases not yet
heard or resolved.
3.2.3 iCMIS case management alert & reporting tools shall
include, among others:
1) Graphical view of age of pending case status with
drill down to specific case management
information and case documents;
2) Real-time access to case management information
relative to benchmarks and time standards;
3) Ticklers/reminder and alert systems for judges to
manage processing of their assigned cases from
Page 116 of 144

(“ C” or
Response
“ NC” )
Description
of Response
filing to final disposition and completion of all

post-disposition (execution) actions.
4) Ability to monitor and report compliance with case
management time standards;
5) Access to alerts for cases out of compliance with
time standards;
6) Ability to monitor cases with no future scheduled
court activities
3.2.4 iCMIS must accommodate single name/party record
entry in a fully relational table. For example, a
name/party is entered only once and can then be linked
with information anywhere else in the application.
iCMIS must require that all name/party records be
entered in the same table.
3.2.5 iCMIS must include court-definable and interactive
register of actions, and/or case record keeping
functionality. This must allow for hyper-linking to
other case participants and related cases.
3.2.6 iCMIS must be able to track an unlimited number of
addresses, phone numbers and e-mails for any
name/party.
3.2.7 iCMIS must provide the capability to Open, Close,
Reopen, and Reclose case files and keep all required
records of such events on a case.
Page 117 of 144

(“ C” or
Response
“ NC” )
Description
of Response
3.2.8 iCMIS must provide the ability to automatically close

a case based on business rules in accordance with
court's rules or procedures.
3.2.9 iCMIS must provide the ability for the closure of a
case to auto-create court defined documents, record
entries, events, system reports, and notifications.
3.2.10 iCMIS must provide the ability to record reason for
case closure.
3.2.11 iCMIS must provide ability to generate record entries,
events and document production based on specified
case record and/or case events.
3.2.12 iCMIS must provide ability to automatically generate
record entries through case initiation process.
3.2.13 iCMIS must allow for the sealing and expunging of
cases, based on the concerned bench's/judge’s
decision and order. The use of this feature shall be
restricted to only a person having the authority to do
so.
3.2.14 iCMIS must provide the ability to automatically
generate notices and letters as an event is scheduled
or rescheduled.
3.2.15 iCMIS must provide the ability to enter comments on
an event.
3.2.16 iCMIS must provide the ability for reopening
previously closed cases retaining previous case
closure and current reopening information.
Page 118 of 144
(“ C” or
Response
“ NC” )
Description
of Response
3.2.17 iCMIS must provide the ability for reclosing

previously re-opened cases retaining previous case
opening, closure, and re-opening events as well as the
current reclosure information.
3.2.18 iCMIS must allow users to view all involvements to a
name/party on one screen, i.e., a name/party inquiry
identifies at a minimum all aliases and all cases related
to the name/party and the person's relationship to each
case.
3.2.19 iCMIS must allow users to view all involvements to a
case on one screen.
3.2.20 iCMIS must be able to store an unlimited number of
aliases.
3.2.21 iCMIS must be able to link cases to other cases.
3.2.22 iCMIS must be able to allow the linking of court
defined numbers to specific court cases. These
numbers must be completely searchable to find cases.
To force data entry and for proper document
formatting, number entry must be masked based on
court defined standards.
3.2.23 iCMIS must allow users to view all cases linked to a
name/party, and from this view allow users to go
directly to a chosen case.
3.2.24 The central name/party capability must allow for
searching on any name/party in the system or any other
court defined case involvement and allow users to
Page 119 of 144

(“ C” or
Response
“ NC” )
Description
of Response
view all cases linked to a name/party. From this view

system shall allow users to go directly to a chosen
case.
3.2.25 iCMIS may allow users to enter an unlimited number
of name/party-specific relationships, such as, brother,
sister, business associate, employer, etc.
3.2.26 For each name/party and case record, iCMIS must
provide comments and notes fields and include a rich
text editor.
3.2.27 iCMIS must allow for chronological entry of case and
name/party notes by date, time, and author coding
capability.
3.2.28 iCMIS must allow for an unlimited number of court
defined visual alert prompts for users, based on key
name/party and case information.
3.2.29 iCMIS must be designed in a manner to accommodate
unified case category and case type creation by the
Registrar.
3.2.30 iCMIS must be able to categorize a case with multiple
court case types.
3.2.31 iCMIS must allow users to conduct searches for case
records using many combinations of search criteria.
3.2.32 iCMIS must provide the ability to track event
information including, but not limited to, type,
location, date and time, and event notes.
Page 120 of 144

(“ C” or
Response
“ NC” )
Description
of Response
3.2.33 iCMIS must allow for a judge to have a viewable and

interactive calendar for upcoming associated events.
3.2.34 iCMIS must provide the ability to manually assign and
reassign cases to individual or groups of judges.
3.2.35 iCMIS must allow for each name/party to have a
viewable calendar for any upcoming associated
events.
3.2.36 iCMIS shall have the ability to display courtroom or
court division wide based calendars.
3.2.37 iCMIS must allow for the generation of user or court
defined calendars to be sorted on location, judges,
courtroom, and time.
3.3. Reports
3.3.1 iCMIS must provide integrated reporting functionality
within the case management system.
3.3.2 iCMIS must provide “dashboard” functionality for all
users based on their roles, controlled through login.
3.3.3 iCMIS must support query builder capability for users
to build their custom reports by selecting fields and
aggregation options.
3.3.4 iCMIS must include a report writer to create custom
views for list reports and summary (statistical) reports.
3.3.5 iCMIS must provide the ability to format reports
either in Portrait and Landscape formats.
Page 121 of 144

(“ C” or
Response
“ NC” )
Description
of Response
3.3.6 iCMIS must include a collection of commonly used

standard reports (60 standard reports to be defined
based on the existing >120 reports in CCMS).
3.3.7 iCMIS must allow the general user to easily generate,
print on paper, export (to PDF, Excel, Word, XML,
or CSV), and/or send the reports.
3.3.8 iCMIS must allow for the placement of reports in user-
defined locations within the system to allow for easier
execution of reports (e.g. calendar related reports run
from the calendar screen/tab/page, etc.)
3.3.9 iCMIS must provide specific and user definable
“dashboard” functionality for users and functional
groups (e.g., Judge, Registrar, President, etc.). For
judges, this functionality must display key reports and
searches and provide them with a view of their cases,
calendar and reports.
3.3.10 iCMIS must allow for judges and judicial staff to
subscribe to key reports for automated email delivery
(for example, the next business Day's Court List of the
judge to be sent to the judges’ email at 4:00 PM).
3.3.11 iCMIS must support generation of list, summary, and
OLAP (Online Analytical Processing) reports, both
using queries pre-built in the application and user-
defined queries through the use of the query builder
functionality.
3.4. Software License and Support
Page 122 of 144

(“ C” or
Response
“ NC” )
Description
of Response
3.4.1 The software license, including design, source code,

name, and brand must be fully owned by the Federal
Supreme Court.
3.4.2 The developer of iCMIS must provide annually
renewable support and maintenance contracts that
include software support and regular software releases
and updates.
3.4.3
The developer of iCMIS must maintain a customer
accessible section of its web site and call center
services that allows for enhancement/bug submission,
message board/forum access, online access to support
representatives and the sharing of documents and
reports with other software application customers.
3.5. Training
3.5.1 The developer of iCMIS must provide a practice
database, independent of the actual database, for
training purposes.
3.5.2 The developer of iCMIS must develop training
manuals for the application administrators, trainers,
and users.
3.4.3 The developer of iCMIS must provide training of
trainers (ToT) to the courts using detailed training
plans and manuals.
3.4.3 The developer of iCMIS must provide periodic onsite
training to application administrators and trainers.
Page 123 of 144
(“ C” or
Response
“ NC” )
Description
of Response
4. ADMINISTRATION FUNCTIONAL REQUIREMENTS

4.1 iCMIS shall enable its Administrator to create
different user groups and corresponding access
privileges or options.
4.2 iCMIS shall enable its Administrator to update or
delete user groups or their privileges.
4.3 iCMIS shall enable its Administrator to create, update
and delete users and corresponding access privileges.
4.4 iCMIS shall enable its Administrator to find, lock, and
unlock users.
4.5 iCMIS shall enable its Administrator to see how many
user sessions are created, including some statistics
about sessions, to find some specific session and see
status of that session, and to cancel (delete) some
session(s), where needed.
4.6 iCMIS shall enable its Administrator to view iCMIS
status of logs and find log records.
5. LOGIN FUNCTIONAL REQUIREMENTS
5.1 iCMIS shall have login functionality for registered
users to access the system from within the federal
courts’ VPN or through internet.
5.2 Login shall be possible either from the federal courts’
central system or local systems or both using username
and password credentials in the federal courts’ VPN.
Page 124 of 144

(“ C” or
Response
“ NC” )
Description
of Response
5.3 Login shall allow access to the federal courts’ central

system through internet using username, password, in
conjunction with One-Time-Password (RSA software
token).
5.4 When login is successful the login module shall direct
the user to the iCMIS home page.
5.5 When login is not-successful the login module shall
display access deny message, with the right cause for
the denial.
Page 125 of 144

8. Key Performance Measures/Indicators:
The following selected Key Performance Measures based on the International Framework
for Court Excellence (IFCE) 2 shall be designed and developed as report.
8.1. Case Clearance Rate:

Definition: the number of outgoing cases (i.e., resolved, disposed, or closed) as a
proportion of the number of incoming cases (i.e., filed or opened) expressed as a
percentage.
Case Clearance Rate is an indicator of whether or not a court or court system is keeping
up with the demands for judicial services in terms of its incoming and outgoing caseload -
the number of outgoing cases represented as a percentage of the number of incoming cases.
If a court is “clearing” (i.e., resolving or disposing) fewer cases than are filed a serious
backlog of cases, is inevitable.
The purpose of this performance indicator is to help courts and judges to:
• understand whether they complete as many cases as are filed/opened, and
• identify similarities and differences between the case clearance rates for different types
of cases at different periods of time.
Formula for Calculation of Case Clearance Rate

% Clearance = ((A + B + C) / (D + E)) x 100
A = Number of cases closed
B = Number of dispositions of reopened cases
C = Number of cases placed in suspended status
D = Number of cases opened
E = Number of cases reopened
All shall be counted for a common given time period (e.g., a year, a quarter, a month)
2 International Consortium for Court Excellence (2020). Global Measures of Court Performance. Third Edition. Sydney, Australia:
Secretariat for the International Consortium for Court Excellence: http://www.courtexcellence.com
Page 126 of 144
8.2.On-Time Case Processing:
Definition: The percentage of cases disposed or otherwise resolved (closed) within

established time reference points (i.e., time standard) by case type in a specified time period
(e.g., month, quarter or year).
On-Time Case Processing provides information about the length of time it takes to process
cases. By resolving cases within established time frames, a court increases trust and
confidence in the judicial process.
On-Time Case Processing is an indicator of the certainty, predictability, timeliness and

efficiency of case processing. “Timeliness reflects a balance between the time required to
properly obtain, present, and weigh the evidence, law and arguments, and unreasonable
delay due to inefficient processes and insufficient resources.” 3
On-Time Case Processing, especially when used in conjunction with measures such as:
Case Clearance Rate, Case Backlog, and Trial Date Certainty, it would become a handy
management tool for courts to assess and manage their timeliness and efficiency.
Formula for the Calculation of On-Time Case Processing:
% On-Time Case Processing = ((A + B)/C) x 100
A = Cases closed within the reporting period that do not exceed the time standard (e.g. 180 days)
B = Cases suspended within the reporting period that do not exceed the time standard
C = All cases closed or suspended within the reporting period
3
International Consortium for Court Excellence. International Framework for Court Excellence, 3rd Edition, May
2020
Page 127 of 144
8.3.Case Backlog:
Definition: Case Backlog is the proportion of cases in a court’s inventory of pending

unresolved cases that have exceeded established timeframes or time standards. The measure is
expressed in terms of the percentage of all the pending cases that are considered to be a backlog
– that is, the proportion of cases that exceed the on-time case processing time reference points,
benchmarks, and established time standards, or, simply, the proportion of pending cases that
already have taken too long.
All cases opened but not yet resolved or otherwise disposed make up a court’s active pending
caseload. A complete, accurate, and current inventory of active pending cases, as well as the
number, types, and “ages” of the cases in the inventory, provide performance data for a
quantitative assessment of a court’s efficiency and timeliness. The terms “current inventory”
and “backlog” are used here to distinguish two parts of a court’s total active pending caseload.
“Current inventory” refers to all active pending cases, including recent “fresh” cases that are
not yet “old,” i.e., not yet beyond established time standard. “Backlog” refers to the proportion
of the current inventory of active pending cases that have “aged” beyond the time standards.
Required data elements to calculate Backlog include:

• the number of cases in the inventory of active pending cases by major case type, level of
court, court location, and other variables,
• the number of elapsed days each case in the inventory has been pending since it was
registered, filed, opened or reopened, and
• identification of established time standards (in days) for on-time case processing of major
case types.
Formula for the Calculation of Case Backlog:
Case Backlog = A/B x 100

Page 128 of 144
A = Total Number of Cases in Backlog

B = Total Number of Cases in the Current Inventory of Pending Cases
8.4.Trial Date Certainty:
Definition: The certainty with which important case processing events occur when scheduled,
expressed as a proportion of trials that are held when first scheduled.
Trial Date Certainty measures a court’s success in holding important case processing events
on the dates they are scheduled to be held, and provides a tool to evaluate the effectiveness and
efficiency of various case management processes such as court calendar management and
continuance policies and practices.
Formula for the Calculation of Trial Date Certainty
% Cases with no more than prescribed (P) trial settings = (A/B) x 100
P = Number of prescribed or target trial settings (e.g., 2)

A = Number of cases with no more than the prescribed or target settings
B = Total number of closed trial cases
8.5.Average Duration of Pre-Trial Custody
Page 129 of 144

Definition: The average elapsed time, criminal defendants who have not been convicted of
crime are detained awaiting trial.
The requirements for calculation of Pre-Trial Custody include:

• the identification and definition of the criminal case types involving pre-trial detention,
• the operational definitions of the two case processing milestones, i.e., (1) date of custody,
and (2) the first date the trial begins, and
• the number of elapsed days between those two milestones.
Formula for Calculation of Duration of Pre-Trial Custody
Average Duration of Pre-Trial Custody = (A – B) / C
A = Date of custody
B = The first date the trial begins
C = Total number of pre-trial criminal defendants
8.6.Court User Satisfaction
Definition: The percent of court users who believe that the court provides procedural
justice, i.e., accessible, fair, accurate, timely, knowledgeable, and courteous judicial
services.
The Court User Satisfaction measure allows courts to continuously receive and evaluate
feedback about how litigants and other court users were treated when they use the courts,
and whether the courts’ processes of making decisions seem fair to them. This measure
provides an effective tool to survey court users about their experiences. It allows for
Page 130 of 144

analysis by court location, division, type of user, and across different types and levels of
courts and tribunals.
The methodology of this measure addresses five key questions:
(a) Who is surveyed?

• Randomly selected actual users of the court on a “typical” day, at the end of every
quarter. The general public (i.e., individuals who do not use the court) are not
surveyed.
(b) About what?
• Agreement with 10 simple statements (anonymously), that deals with accessibility,
convenience, and treatment by the courts (fairness, equality, and courtesy).
(c) When?
• At the end of every quarter, on a continuous and regular basis.
(d) By whom? How?
• Court staff using a simple questionnaire.
(e) Where?
• All courts, possibly beginning with pilot courts before it is implemented in all
courts.
Sample Survey Questions:
Instruction: Please put “X” mark along your selected response.
Disagree (2)
Disagree (1)
No Opinion
Applicable
Agree (5)
Agree (4)
Strongly
Strongly
Not
S/N Survey Question

(3)
1 Getting to the courthouse was easy.
2 Finding where I needed to go in the

courthouse was easy and convenient.
3 I felt safe in the courthouse.
Page 131 of 144

4 I had no difficulty getting the
information I needed when I came to
the courthouse.
5 Court personnel treated me with
courtesy and respect.
6 The judge hearing my case listened to
me and was courteous, respectful and
fair.
7 I understand the instructions of the
court and what I need to do next.
8 The case or other business I had with
the court was handled in a timely and in
an efficient manner.
9 I was treated equally. My gender,
economic status, age, or ethnicity made
no difference in how I was treated by
the court.
10 Overall, I think the court performs
effectively.
Page 132 of 144

The following (i.e., A to H) shall be calculated for each of the 10 questions.
A = Total Count of “Strongly Agree” multiplied by 5
B = Total Count of “Agree” multiplied by 4
C = Total Count of “No Opinion” multiplied by 3
D = Total Count of “Disagree” multiplied by 2
E = Total Count of “Strongly Disagree” multiplied by 1
F = Total Count of “Not Applicable” multiplied by 0
G = Total Count of Responses multiplied by 5
H = ((A + B + C + D + E + F) / G) x 100
As shown in the following formula, the overall Court User Satisfaction rate would be
Summation of “H” scores for the 10 questions divided by 10.
Overall Court User Satisfaction Score = (H1 + H2 + H3 + H4 + H5 + H6 + H7 + H8 + H9 +

H10) / 10
Possible Score meaning (score from 100):

85 – 100 = Excellent
70 – 84.99 = Good
60 – 69.99 = Average
50 – 59.99 = Poor
< 50 = Failure
8.7.Court Employee Engagement
Definition: The percent of the employees of a court who, as measured by a court-wide

survey, are passionate about their job, committed to the mission of the court and, as a result,
put discretionary effort into their work.
There is a difference between employee engagement and employee satisfaction. The latter
reflects how happy employees are, but not necessarily their level of motivation,
Page 133 of 144
involvement, or emotional commitment to their work. Disengaged employees can be quite
satisfied but not motivated and dedicated to their work. Employee engagement comes from
a feeling of accomplishment, meaning, and achievement.
The methodology of this measure addresses five key questions:
(f) Who is surveyed?

• All non-judicial court staff on a “typical” day, at the end of every quarter.
(g) About what?
• Agreement with 20-item self-administered anonymous questionnaire focused on
the strength of the court's workforce and the quality of the relationships of its
employees.
(h) When?
• Twice a year (at the end of the 1st quarter and the end of the 3rd quarter), on a
continuous and regular basis.
(i) By whom? How?
• Administered by human resources administration using a simple questionnaire.
(j) Where?
• All courts, possibly beginning with pilot courts before it is implemented in all
courts.
Sample Survey Questions:
Instruction: Please put “X” mark along your selected response.

Disagree (2)
Disagree (1)
No Opinion
Applicable
Agree (5)
Agree (4)
Strongly
Strongly
S/N Survey Question

Not
(3)
1 I am kept informed about matters that

affect me.
Page 134 of 144

Disagree (2)
Disagree (1)
No Opinion
Applicable
Agree (5)
Agree (4)
Strongly
Strongly
S/N Survey Question
Not
(3)
2 I understand what is expected of me.
3 I have the resources (materials,

equipment, supplies, etc.) necessary to
do my job well.
4 I am able to do my best every day.
5 Communication within my
division/department/unit is good.
6 In the last few months year, I was at
least once recognized and praised for
doing a good job by my supervisor.
7 Someone at work cares about me as a
person.
8 I have opportunities to express my
opinion about how things are done in
my division.
9 Courts are respected in the community.
10 My co-workers work well together.
11 I am encouraged to try new ways of

doing things.
12 I understand the relationship between
the work I do and the mission and goals
of the Courts.
Page 135 of 144

Disagree (2)
Disagree (1)
No Opinion
Applicable
Agree (5)
Agree (4)
Strongly
Strongly
S/N Survey Question
Not
(3)
13 My working conditions and
environment enable me to do my job
well.
14 I feel valued by my supervisor based on
my knowledge and contributions to my
department, unit or division.
15 I feel free to speak my mind.
16 In the last month, someone at work has

talked to me about my performance.
17 I enjoy coming to work.
18 My co-workers care about the

efficiency and quality of the services we
provide.
19 I am treated with respect.
20 I am proud that I work in the Courts.
The following (i.e., A to H) shall be calculated for each of the 20 questions.

A = Total Count of “Strongly Agree” multiplied by 5
B = Total Count of “Agree” multiplied by 4
C = Total Count of “No Opinion” multiplied by 3
D = Total Count of “Disagree” multiplied by 2
E = Total Count of “Strongly Disagree” multiplied by 1
F = Total Count of “Not Applicable” multiplied by 0
G = Total Count of Responses multiplied by 5
H = ((A + B + C + D + E + F) / G) x 100
Page 136 of 144
As shown in the following formula, the overall Court User Satisfaction rate would be
Summation of “H” scores for the 20 questions divided by 20.
Overall Employee Engagement Score = (H1 + H2 + H3 + H4 + H5 + H6 + H7 + H8 + H9 + H10+

H11 + H12 + H13 + H14 + H15 + H16 + H17 + H18 + H19 + H20) / 20
Possible Score meaning (score from 100):

85 – 100 = Excellent
70 – 84.99 = Good
60 – 69.99 = Average
50 – 59.99 = Poor
< 50 = Failure
9. Technological Requirements
Software developers who submit their proposal for the development of iCMIS as per the
Software Requirements Specification provided under section 6 above and other functional and
non-functional requirements and required software features provided in this document as well
as the BRD (i.e., The Ethiopian Federal Courts’ Business Requirements Document (BRD) for
Integrated Case Management Information System (iCMIS)) shall present in detail the
information technology requirements (or all supported technological platforms) for their
proposed iCMIS solution, including but not necessarily limited to the following:
1) Software Development Technology;

2) Database Management System (DBMS);
3) Operating System Software;
4) Documents Creation and Maintenance Software Technology;
5) Network Technology.
10. Warranty Services
Page 137 of 144

The selected software developer will be required to provide two-years long post-
implementation warranty services for the implemented iCMIS software which will include
both preventive and corrective maintenance services so as to ensure uninterrupted service of
the iCMIS software. The warranty service will include corrective maintenance to resolve
existing problems that occurred on the system as well as preventive maintenance to guard
against any potential problem or treat on the software. Such service may include provision of
software patches, updates, and/or upgrades.
Page 138 of 144

Annex 1: List of Reports in CCMS
Number
S/N Report Title of
Reports
1 Court Schedules Report Category: 11
 List of Cases Scheduled on a Given Day (i.e., Court List
or Docket)
 Scheduled Cases List by Reason
 Past Scheduled Cases List
 Case files with no schedule
 Schedule Cases List by Reason
 Case files having no future date schedule
 Schedule Analysis
 Number of Scheduled Cases by Reason
 Number of Scheduled Cases by Schedule Status
 Cancelled Schedules
 Number of Schedules by Date
2 Filings Report Category: 8
 List of filed Cases
 Cases under Process
 Summary of filed Cases Classified by Year
 Summary of filed Cases Classified by Quarter
 Summary of filed Cases Classified by Month
 Statistics on filings
 10 Case Categories with biggest number of filings
 Forecast of filings
3 Pending Cases Report Category: 14
Page 139 of 144
Number
S/N Report Title of
Reports
 List of Pending Cases
 List of Delayed Cases
 List of Cases which are Pending for many years
 List of Re-Opened Pending Cases
 List of Suspended Pending Cases
 Summary of Delayed Pending Cases
 Summary of Pending Cases by Year
 Summary of Pending Cases by Quarter
 Summary of Pending Cases by Month
 Pending Cases Statistics
 10 case categories having the Big Number of Pending
Cases
 Summary of Pending Cases classified by their Age
 Summary of Pending Cases Transferred from Year to
Year
 Summary of Pending Cases
4 Disposed Cases Report Category: 12
 List of Disposed Cases
 List of Cases filed for Appeal or Cassation
 Summary of Cases filed for Appeal or Cassation
 Summary of Disposed Cases by Year
 Summary of Disposed Cases by Quarter
 Summary of Disposed Cases by Month
 Statistics on Disposed Cases
 10 Case Categories on with Big Number of Cases
Disposed
Page 140 of 144

Number
S/N Report Title of
Reports
 Summary of Disposed Cases classified by Age
 List of Cases Disposed in a Month
 Analysis of Disposed Cases
 List of Disposed Cases classified by Type of their
Disposal
5 Lower Courts Report Category: 7
 List of cases brought from lower Courts
 Statistics on comparison of the new judgments against old
ones
 Statistics on comparison of the new judgments against old
ones classified by lower Court
 Summary of cases brought from lower Courts
 Summary of cases brought from lower Courts by case
category
 List of cases transferred to another Court
 List of cases transferred from another Court
6 Statistics Report Category: 14
 Cash collected
 Cases Summary
 Statistics of cases
 Statistics of cases by date and case category
 Summary statistics
 Statistics
 Clearance and Congestion
 Comparison by year
 New, Disposed, and Active Cases statistics
Page 141 of 144

Number
S/N Report Title of
Reports
 Statistics of cases transferred between Courts
 List of related and connected cases
 Lower Courts statistics
 Statistics on children leaving with their mother or father
 Statistical comparison by year
7 Miscellaneous Reports Category: 13
 Judgment execution
 Summary of litigation amount
 Summary of Court fee
 Analysis of Penalty
 Summary by winner and loser
 List of case categories
 List of committed crimes
 Court session opening and closing times
 Case file’s movement history
 Annual average comparison
 Summary of penalty/detention analysis
 Win-Lose Summary List
 Files transferred between Courts
8 Plaintiff & Defendant Report Category: 14
 Plaintiffs' Summary Statistics
 Defendants' Summary Statistics
 Plaintiff Information
 Defendant Information
 Statistics by Plaintiff or Defendant Category
 List of cases by Plaintiff or Defendant Category
Page 142 of 144

Number
S/N Report Title of
Reports
 List of cases having Defendant prisoner
 List of cases having Plaintiff prisoner
 List of cases having Defendant penalty
 List of cases having Plaintiff penalty
 Criminal Plaintiffs by nationality and age
 Criminal Defendants by nationality and age
 Statistics of parties with and without legal support
 Number of victim juveniles classified by defendant name
9 Judges and Lawyers Report Category: 8
 Schedules by Judges
 Case categories by Judges
 List of Presidents and Judges
 List of Presidents and Judges by Age
 List of Presidents and Judges by Year of Experience
 Cases by Lawyers
 Fee collected by Lawyers
 Judges that prepared judgments
10 System Audit Report Category: 4
 Files audit history
 Audit statistics
 Data Encoders' time record
 Court’s Audit record
11 Juvenile Related Reports Category: 8
 Statistics
 Clearance and Congestion
 Yearly Comparison
Page 143 of 144

Number
S/N Report Title of
Reports
 Crime Victim Juveniles
 Plaintiff Juveniles
 Defendant Juveniles
 Witness Juveniles
 Third-Party Juveniles
12 Adoption Related Reports Category: 7
 Reasons for Rejecting Adoption
 Adopted Children categorized by Region and Ethnic
group
 Adopted Child Families
 List of adopted children: name and gender
 List of adopted children: name and age
 Adoptive family and adopted child
 Adopted child and parent(s) before adoption
Page 144 of 144

Annex B. Icmis Srs

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Annex B. Icmis Srs

Uploaded by

Copyright:

Available Formats

Annex B

The Ethiopian Federal Courts’

Date: November 1, 2021

List of Acronyms: ........................................................................................................................... 4

2.1.2. Classification: ......................................................................................................... 11

2.2. Person Data Group: ........................................................................................................ 12

2.2.2. Persons (Actors) in Criminal Processes: ................................................................. 14

2.3. Event Data Group: .......................................................................................................... 14

2.3.2. Civil – Appeal Process Events: ............................................................................... 16

2.3.3. Criminal Process Events: ........................................................................................ 17

2.3.4. Cassation Process Events: ....................................................................................... 17

2.4. Financial Data Group: .................................................................................................... 18

3.1.2. Case Status: ............................................................................................................. 20

3.2. High Level View of the Court Case Flows: ................................................................... 22

6.1.3. First Instance – Accelerated Procedure: ................................................................. 38

6.1.4. Appeal – Ordinary Procedure: ................................................................................ 40

6.2. Criminal Use Cases: ....................................................................................................... 61

6.3.2. Register User and Login Functions: ....................................................................... 79

7. Software Requirements Specification (SRS):........................................................................ 81

AFIS Administrative and Finance Information System

A software requirements specification (SRS) is a document that describes what

Overall, this Software Requirements Specification (SRS) document provides specification

This document, together with the following documents:

This SRS document covers the following topics:

2. Case Management Data Groups and Data Elements:

The four basic groups of data maintained in courts are:

Case Related Data

Figure 1: Court Data Groups and their Relationships

2.2. Person Data Group:

2.2.1. Persons (Actors) in Civil Processes:

2.2.1.1.Civil – Ordinary – First Instance Processes:

2.2.1.2.Civil – Ordinary – Appeal Processes:

2.2.1.3.Civil – Ordinary – Execution Processes:

2.2.2. Persons (Actors) in Criminal Processes:

2.3. Event Data Group:

2.3.4. Cassation Process Events:

2.4. Financial Data Group:

3.1.2. Case Status:

3.1.2.2.Inactive (or suspended):

A case is considered to be in a reopened inactive status if the activity on all outstanding

Figure 5: External Users of the Courts’ System

Figure 7: Very High Level INTRANET connectivity needs for iCMIS

5. The Envisaged High Level Architecture of iCMIS:

iCMIS would consist of two major sub-systems:

RMIS API AFIS

Figure 10: Integration among iCMIS, RMIS, and AFIS

ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice

6.3.1. Administration Functions:

1. BASIC FUNCTIONS AND FEATURES

1.1.5 iCMIS shall enable the courts to implement

1.1.9 iCMIS shall enable the courts to exercise appropriate

1.2.1 iCMIS must use tabbed browsing interface in order to

1.2.7 For summary reports, iCMIS shall provide drill down

1.3.2 iCMIS must provide the ability to search for records

knowledge method or dynamically created to promote

computers or mobile devices connected to the system

systems or customer-facing apps for the courts

only case files (i.e., opened or re-opened and currently

1.9.4 The entire system shall be designed modular and with

1.11.3 iCMIS must be designed to be flexible to

registration for partners or employees of Registered

issuance of any document issued by the courts, in the

• The affidavit is sworn-in in the usual way in which