ADDIS ABABA INSTITUTE OF

TECHNOLOGY
CENTER OF INFORMATION TECHNOLOGY AND
SCIENTIFIC COMPUTING
DEPARTMENT OF SOFTWARE ENGINEERING

Digital Court Management System

(Yeka Sub-city First instance court)

Team Members
Edossa Tadasa – ATR/4221/05
Muleta Alem – ATR/5086/05
Biftu Girma– ATR/2906/05

Advisor: Eyob Wondimkun

Feb 12,2017
 Addis Ababa Institute of Technology
Information Technology and Scientific Computing
Digital Court Management System

This Project documentation submitted in partial fulfillment of the requirements for the Degree of
Bachelor of Science in Software Engineering.

Project Advised by:

Eyob Wondimkun

Name and signature of Members of the examining board:

Name Title Signature Date

1. __________________ Advisor _____________ _____________

2. __________________ Chairperson _____________ _____________

3. __________________ Examiner _____________ _____________

4. __________________ Examiner _____________ _____________

5. __________________ Examiner _____________ _____________

January 2016

i
 Declaration of Originality

We declare that this project is our original work and has not been presented for a degree in any
other university.

Name Signature Date

1. Name of Student 1 __________________ __________________

2. Name of Student 2 __________________ __________________

3. Name of Student 3 __________________ __________________

4. Name of Student 4 __________________ __________________

This project documentation has been submitted for examination with my approval as university
advisor:

Advisoir Name _________________________

February 2017

ii
 ACKNOWLEDGEMENT

We have put our efforts in this projects, however, it would not have been possible without the
kind support and help of many individuals and organizations. We would like to extend our
sincere thanks to all of them.

We are highly indebted to Addis Ababa institute of Technology for their guidance and constant
supervision as well as for providing necessary information regarding the project and also for
their support in completing the project.

We would like to express our sincerest gratitude to our final project supervisor Mr. Eyob
Wondimkun for his guidance and valuable support throughout the course of this project work
and for helping us to coordinate our project especially in writing this proposal. Our thanks and
appreciations also go to people who have willingly helped us out with their abilities.

iii
 ABSTRACT

This project work intends to automate the existing Yeka sub city first instance court system and
to digitize court case management system. The essence was to produce durable courts and
lawyer’s interaction as well as scheduling court appointments, automatically and contextually
assigning judges, digitizing the case form.

This proposal is for the project named “Digital Court Management System” which is the final
project of our B.Sc. in Software Engineering. This project proposal is about the development
process of a Digital Court case Management System Exclusively for Yeka sub city first instance
court. This project has used object oriented techniques. All approaches taken and decisions made
are documented. The goal of this project is to minimize effort, time, and cost of all parties
involved in the process by assessing the current justice system such as interviewing lawyers,
prosecutors, Judges, and visiting the Federal First Instance Court of Addis Ababa (Yeka sub
city).

This project is web based integrated with an android (mobile) application. The website’s major
functionalities are for the courts while the lawyers and prosecutors will mainly use the android
(mobile) application.

iv
 Table of Contents
List of figures................................................................................................................................ix

List of Tables..................................................................................................................................x

ACRONYMS.................................................................................................................................xi

Chapter 1: INTRODUCTION......................................................................................................1

1.1 Background......................................................................................................................1

1.2 The Existing System............................................................................................................1

1.3 Statement of the Problem....................................................................................................3

1.4 Objective of the Project.......................................................................................................5

1.4.1 General Objective....................................................................................................5

1.4.2 Specific Objective.....................................................................................................5

1.5 Proposed System..................................................................................................................6

1.6 Feasibility Study...................................................................................................................7

1.6.1 Economic Feasibility.....................................................................................................7

1.6.1.1. Developmental cost..............................................................................................7

1.6.1.2. Operational Cost..................................................................................................7

1.6.2 Technical Feasibility.....................................................................................................7

1.6.3 Schedule Feasibility......................................................................................................8

1.7 Scope.....................................................................................................................................9

1.8 Methodology.........................................................................................................................9

There will be both server side and client side programming with industry standard
technologies to make the website more secure, interactive and user-friendly 1.9 Project
Management plan....................................................................................................................10

1.9.1. Time Management plan............................................................................................10

1.9.1. Time Management plan............................................................................................10

v
 1.9 .2 Quality Management Plan........................................................................................10

1.9 .3. Communication Management Plan.........................................................................12

Chapter 2: LITRATURE REVIEW..........................................................................................14

1.1 Introduction........................................................................................................................14

1.1 Purpose...............................................................................................................................14

1.2 Scope...................................................................................................................................14

2.2 Reviewed System.................................................................................................................16

2.3 Summary of the review........................................................................................................16

Chapter 3: Requirement Analysis..............................................................................................17

3.1 Introduction........................................................................................................................17

3.1 Purpose................................................................................................................................17

3.2 Scope...................................................................................................................................17

3.3 General Description...........................................................................................................19

3.4 Product Perspective...........................................................................................................19

Registration:.............................................................................................................................20

3.5 Product Functions..............................................................................................................20

3.6 User Characteristics..........................................................................................................20

3.7 General Constraints...........................................................................................................21

3.8 Assumptions and Dependencies........................................................................................22

3.9 External Interface Requirements.....................................................................................22

3.9.1 User Interfaces............................................................................................................22

3.9.2 Hardware Interfaces...................................................................................................22

3.9.3 Software Interfaces.....................................................................................................22

3.9.4 Communications Interfaces.......................................................................................23

3.1.4 Communications Interfaces.......................................................................................23

vi
3.10 Functional Requirements................................................................................................23

3.2.1 Registering to the system............................................................................................24

3.2.2 Communications.........................................................................................................24

3.2.3 Online opening case....................................................................................................24

3.2.4 Scheduling...................................................................................................................24

3.2.5 Automatic Assigning...................................................................................................25

3.2.6 Information.................................................................................................................25

3.3.1 Use Case #1..................................................................................................................26

3.3.2 Use Case #2..................................................................................................................26

3.3.3 Use Case #3..................................................................................................................27

3.3.4 Use Case #4..................................................................................................................28

3.3.5 Use Case #5..................................................................................................................28

3.3.6 Use Case #6..................................................................................................................29

3.12 Non-Functional Requirements.......................................................................................34

3.4.1 Performance................................................................................................................34

3.4.2 Reliability.....................................................................................................................34

3.4.3 Availability..................................................................................................................34

3.4.4 Security........................................................................................................................34

3.4.5 Maintainability............................................................................................................34

3.4.6 Portability....................................................................................................................34

3.4.7 Responsiveness............................................................................................................34

3.4.8 Synchronization:.........................................................................................................34

3.13 Inverse Requirements......................................................................................................34

3.14 Design Constraints...........................................................................................................35

3.15 Logical Database Requirements.....................................................................................35

vii
 3.16 Other Requirements........................................................................................................35

3.17 Change Management Process.........................................................................................36

Chapter 4: SYSTEM DESIGN...................................................................................................37

4.1 General Overview..............................................................................................................37

4.2 Development Methods & Contingencies..........................................................................37

4.3 System Architecture..........................................................................................................38

4.3.1 Subsystem decomposition..........................................................................................38

4.3.2 Hardware/software mapping.....................................................................................39

4.4 Object Model......................................................................................................................40

4.4.1 Class Diagram.............................................................................................................40

4.4.2 Sequence Diagram......................................................................................................41

Figure 15: Sequence Diagram-9............................................................................................49

4.5 Detailed Design...................................................................................................................50

Chapter 5: CONCLUSION AND RECOMMENDATION.....................................................74

6.1 Conclusion..........................................................................................................................74

6.2 Recommendation...............................................................................................................74

BIBLIOGRAPHY........................................................................................................................75

APPENDIX...................................................................................................................................76

Use Case Diagrams:.......................................................................................................................76

List of figures
viii
Figure 1:: Source: Judicial Reform in Ethiopia...............................................................................3
Figure 2: Figure 3:Time Management Plan Using Gantt chart.....................................................10
Figure 4 : overview of the system for mobile users.......................................................................37
Figure 5:UML Component Diagram.............................................................................................38
Figure 6: UML Deployment diagram............................................................................................39
Figure 7: Sequence Diagram-1......................................................................................................41
Figure 8: Sequence Diagram-2......................................................................................................42
Figure 9: Sequence Diagram-3......................................................................................................43
Figure 10: Sequence Diagram-4....................................................................................................44
Figure 11: Sequence Diagram-5....................................................................................................45
Figure 12: Sequence Diagram-6....................................................................................................46
Figure 13: Sequence Diagram-7....................................................................................................47
Figure 14: Sequence Diagram-8....................................................................................................48
Figure 15: Sequence Diagram-9....................................................................................................49
Figure 16: Use Case Diagram for Lawyer and Prosecutor............................................................76
Figure 17: Use Case Diagram for Client.......................................................................................77
Figure 18: Use Case Diagram for Admin......................................................................................78
Figure 19: Use Case Diagram for Judge........................................................................................79

List of Tables

ix
Table 1:User entity description......................................................................................................34
Table 2: Person class.....................................................................................................................50
Table 3: Attributes description for Person class............................................................................50
Table 4: Account class...................................................................................................................51
Table 5: Attributes description for Account class.........................................................................51
Table 6: Operation description for Account class.........................................................................51
Table 7: Schedule class..................................................................................................................52
Table 8: Attributes description for Schedule class........................................................................53
Table 9: Operation description for Schedule class........................................................................53
Table 10: Alarm class....................................................................................................................54
Table 11: Attributes description for Alarm class...........................................................................55
Table 12: Operation description for Alarm class...........................................................................55
Table 13: Judge class.....................................................................................................................56
Table 14: Attributes description for Judge Class...........................................................................56
Table 15 : Operation description for Judge Class.........................................................................57
Table 16: Lawyer/Prosecutor Class...............................................................................................58
Table 17: Attributes description for Lawyer/Prosecutor class......................................................59
Table 18: Operation description for Lawyer/Prosecutor class......................................................59
Table 19: Client class.....................................................................................................................61
Table 20: Attributes description for Client class...........................................................................61
Table 21: Operation description for Client class...........................................................................61
Table 22: Admin class...................................................................................................................62
Table 23: Attributes description for Admin class..........................................................................62
Table 24: Operation description for Adminclass...........................................................................63
Table 25: Case class.......................................................................................................................64
Table 26: Attributes description for Case class.............................................................................64
Table 27: Operation description for case class..............................................................................65
Table 28: Message class................................................................................................................66
Table 29: Attributes description for Message class.......................................................................66
Table 30: Operation description for Message class.......................................................................67
Table 31: Information....................................................................................................................67

x
Table 32: Attributes description for Information class..................................................................68
Table 33: Operation description for Information class..................................................................69
Table 34: Witness Class.................................................................................................................70
Table 35 : Attributes description for Witness class.......................................................................70
Table 36: Operation description for Witness class........................................................................71
Table 37 : Evidence class..............................................................................................................71
Table 38: Attributes description for Evidence class......................................................................72
Table 39: Operation description for Evidence class......................................................................72

xi
 ACRONYMS

FSCCD: Federal Supreme Court Cassation Division

FDRE: The Federal Democratic Republic of Ethiopia
PDRE: The People Democratic Republic of Ethiopia
ITSC: Information Technology and Scientific Computing
AAiT: Addis Ababa institute of Technology
CJP: Criminal Justice Policy of Ethiopia
API: Application programming interface
HPR: House of Peoples Representative
PHP: Personal Home Page
FSR: Feasibility Study Report
HF: House of Federation
MJ: Ministry of Justice
CCMS: Court Case Management System
UC: - Use case
UCD: - Use case Diagram
ER-diagram: - Entity relationship diagram
SRS: - Software Requirement Specification
DCMS: - Digital Court Management System
IEEE: - Institute of Electronic and Electrical Engineers
HACS: - High Angle Control Station
User: - Someone who interacts with the mobile phone application or website
Web portal:- web based application of the system or the system run on browser.
SDS: - Software Design Specification
IEEE: - Institute of Electronic and Electrical Engineers
User: - Someone who interacts with the mobile phone application or website
Web portal: - web based application of the system or the system run on browser.

xii
 Chapter 1: INTRODUCTION

1.1 Background
The court or Justice systems exist to provide a way to protect the rule of law. In order to
accomplish this goal, courts need to be (1) accessible; (2) fair; and (3) cost-effective.
Unfortunately, due to their reliance on old fashioned, non-technological processes, courts in
Ethiopia have seen little improvement on these three measures in recent decades. Manual
Processes which do not provide accurate, reliable and comprehensive data around the clock.

The Federal First Instance Court for example currently manages or audits approximately 530
cases each month (source: Yeka sub city Federal First Instance court).

Even the simplest negotiation points in the process require litigants to physically go to court, a
process that is time-consuming, opaque, and intimidating. Consequently, millions of people, who
have relatively minor issues that require negotiation with the judge or prosecutor are
inconvenienced.

What is required is a scalable, simple, interactive, web-based alternative to the one-on-one Court
making process. There are no other organizations involved in our project. Court System is a vital
aspect of every justice system.

1.2 The Existing System

In November 8, 2016 we have visited Yeka sub city Federal First Instance Court around
Shola area in Addis Ababa and collected some information about the existing system there. In
General, the existing system is manual (paper based) as the Judges, Lawyers, Prosecutors and
clients (Accuser and Accused) use it. But there are people hired there whose jobs are encoding
the paper based data. These people convert the paper document into a softcopy and store it using
a software “CCMS (Court Case Management System)” done by “Cyber Soft” in a server
which has a capacity of 2Terabytes. At the end of each month the ICT officer will send a copy of
the Data to the ICT Head office which is found at Lideta Federal Court via drop box or
physically.

Here, what we observed are the following:

1
  CCMS software users are only the Data Encoders and ICT officers.
 In addition the CCMS software doesn’t have mobile application.
 Also it cannot store digital files like: images, videos, sound and audios.
 The system is not networked.
 It only supports Windows operating system.

Below is the process of opening a case up to decision in the court:

 Firstly, cases are going to be reviewed at a First Instance Court.

 The client or the accuser gets a lawyer and fills the form that consists the detail of his/her
case: title, your description and written details. These forms are stored manually on a
paper.
 Before the case gets accepted it will be revised by the courts whether the case is for
Federal Court, Regional, or Religious court (Sharia).
 Next judges are selected and appointed to cases randomly.
 In the first appointment, the case will be viewed and judges must understand what the
case is. Here:
- There are three judges. The Main (Decision maker), and the remaining
two provide the necessary help for the Main Judge.
 If there are evidences to be considered from the accuser side or from the accused, an
appointment will be given for another day. As shown in the table below, 100 percent, or
76 of the sample disagreed that the Addis Ababa City Courts utilize IT equipment like
recording the arguments of litigant during trial hearing. In addition, 100 percent of them
agreed that the absence of such trail recording equipment cause fatigue for judges and
their decision be mistrusted by parties. Again, all the entire respondent believed that if
trials are to be recorded by hand writing, judges may not properly record important
arguments of the parties.

2
 Figure 1:: Source: Judicial Reform in Ethiopia

A Critical analysis on the Case of Addis Ababa City Government Courts (By Hailu
Tadesse Bellete)

 When the witness’ comes, these witnesses will testify what they have seen or
heard.
 The final decision will be passed based on the assessment of the entire case.
 The accused can appeal up to the Federal Supreme court if he/she disagrees with
the final decision of the current court.

1.3 Statement of the Problem

Each Court in Ethiopia serves a population of approximately 100,000. The courts work 10
months every year from September 11 to June 31 G.C or Meskerem 1 – Sene 30 E.C.

The project addresses problems like:

 Manual assigning of Judges

 Lack of Communication between staff clients, judges, lawyers, prosecutors and
courts: most of the time the appointment is postponed. Because of lack of
communication.

3
  Difficulty of retrieving stored information: The Data should be always available
and clear to judges as well as any privileged parties who need to access it. This
means Easy retrieval and modification of data.
 Risks of natural and manmade disasters
 Mismanagement of data: manual storage of files requires a physical space and
materials to be kept in places like a warehouse
 More time, energy and money consumption

The problem of ... The major problem is the lack of communication that exists
 Time problem between each person involved and lack of proper data storage. This
 Cost problem leads to more postponements consuming more time, costing more
 Effort problem money and energy.
 Efficiency problem
 Data retrieval problem

Affects ... Almost every person involved is affected.

And results in ... Hence creating a very inefficient and ineffective system.

Benefits of a solution ... Proposed solution for these problem is:

 This system can make the justice system of this country
very effective and will avoid issues like forgetting
appointments.
 A better way of gathering and storing data.
 Creating an effective way of communication.
 Efficient justice system.
 Save much needed time, energy and money.

4
1.4 Objective of the Project

1.4.1 General Objective

The project objective is to create a digital management system that significantly improves and
streamlines the Court System’s office workloads in the First Instance court (Yeka sub city),
resulting in time efficiencies for both the staff (Judges, prosecutors and Lawyers) and users (The
accuser and the accused). The software will also be user friendly so that both casual and
consistent users can easily obtain the information they need from the system.

1.4.2 Specific Objective

To achieve the general objective stated above, this proposed project is expected to address the
following specific objective:

 Improving information quality, enhanced access and superior data retrieval and reporting
capabilities.
 Improve workflow and avoid manual data storage.
 Creating an efficient way to retrieve old cases.
 Utilization of electronic document generation like case and evidence forms.
 Creating a system that will store and manage photos, different text formats, audio and
video recordings, data exchanges with the systems of other justice partners (i.e. jail,
courts, law enforcement); electronic case filing with the courts.
 Friendly user interfaces combined with intuitive layouts, user help documentation,
functionality and cost will drive the decision making process.
 Creating a better way to schedule and update appointments.
 Solve the issue of miscommunication.

5
1.5 Proposed System
We believe that our system will be an efficient and effective solution for the problems
that exist in the court (Yeka sub city) which are tedious for clients. What makes our proposed
solution reliable to solve the problems we mentioned earlier is that it addresses the major
problems while changing the entire manual system that we see in today’s courts to digital. This
system is applicable because the necessary infrastructure is already in place in most of the
required places. We got motivated to solve this problem knowing that it can make a difference in
the society we live in. Our system will make the justice and judiciary system transparent and
more efficient so that people benefit from the system by minimizing cost of transportation to
following up their appointment, saving time since the system is online.

The system enables communications between different courts, judges, lawyers and clients as well
as the both clients and lawyers and prosecutors can follow their case outside the court’s
compound.

Lawyers and prosecutors can also open cases without getting there physically into the courts,
knowing appointments, enable lawyers for scheduling meeting with judges and clients. The
client also benefits from this system since they follow their cases through the application once
they open their case through their lawyers and the system is faster than the manual one.

Lawyers and prosecutors based on the notifications they get can schedule their calendar, and can
send notification back to courts, judges, admin and client like dropping off cases.

The system also automatically and contextually assign judges in order to increase efficiency of
the court.

Moreover, our system manages cases in digital way by creating different kinds of form according
to the case and store all files in structured way so that it enables courts, lawyers and prosecutors
to easily find the stored data.

The system enables customers to get information about lawyers and prosecutors in case they
want to hire lawyers. Also get related information about the rule of law in Ethiopia.

6
1.6 Feasibility Study
1.6.1 Economic Feasibility
In performing Cost benefit analysis (CBA) it is important to identify cost and benefit factors. The
project will be possible by our developers and the resource we can get.

1.6.1.1. Developmental cost

The development costs that are incurred during the development of the system are fees of
transportation and equipment. The cost of transportation during requirement gathering from
different sources who have knowledge of the law. And also the cost of internet when there is no
connection in the campus compound. The equipment is computer either personal or desktop.
Finally the time spent by us, the developers.

1.6.1.2. Operational Cost

The operational costs that are incurred during the operation of the system are payments to a web
host, for a google play account and maintenance cost after the system is deployed. The expenses
required for the day to day running of the system is the cost of internet and server or storage.

1.6.2 Technical Feasibility

This system can run on almost all device. The minimum requirement for system to fully
applicable is:

1) Web based:

Hardware requirement:
Processor : Pentium Processor
Secondary Storage : 500GB HDD
ROM : 52X CD ROM Drive
Memory : 4 GB RAM
Network Adapter : Ethernet Adapter
Modem : 128kbps Voice Fax Data
Others : 17 Colour Monitor, Printer, Keyboard, Mouse.

Software requirement:
Platform : Windows
Operating System : Windows 7
Framework : PHP Laravel framework
Back-end tool : MYSQL

7
Scripting tool : PHP

2) Mobile application:

Hard ware requirement: smart phone with android based operating system.

Software requirement: android version above 4.0(KitKat).

1.6.3 Schedule Feasibility

The estimated duration of time the system will take to develop is 5 months, and it can be
completed in a given time period scheduled below. Since the project time table will be provided
by the department we will be following that schedule.

1.7 Scope
 We have desired to replace the current Case Management System to an
integrated, open architecture system that will provide improved
communication across each court.
 Since this project is based on the client-server & online-real time systems
architectures, the user will not feel any isolation at all and the users will be
able to get their hands-on this systems from anywhere.
 A court that has a Case Management System that provides easy access to
information and an intuitive end-user reporting system.
 A court that has a Case Management System that will reduce redundant data
entry, reduce paper flow, and streamline best practices.
 A court that has a Case Management System that will provide online filling
system.
 A court that has a Case Management System that will provide public access to
information.

8
1.8 Methodology
8.1 Data collection methodology:

As an input data for this project it would be better to know about the functioning of the existing
Court system, and its tedious parts for a better improvement and solutions for problems it has. To
this end the sources of this data are the Lawyers, judges, client and court’s staff in the current
structure so distributing questionnaires on how to solve a problem might be a data collection
mechanism. Besides proposing questionnaires for third parties, we have personally asked
different people involved in the justice process like lawyers and judges for the problems they
face. So, their experience in the current Court Management system would be a great input for the
project we are developing.

8.2 Description of datasets

The date collected to start up the system as well as all resources on the system will be in the form
of Digital Court Management System such as videos, audios, and text documents (PDFs and
Word Documents).

8.3 Implementation

For the development of this project we are going to use a Software Development Model called
“Waterfall Model”. Our main reasons to implement the project by using this model is that, there
is no need for a feedback from gathering requirements to testing it can be developed without
going back to the previous step. Another reason would be our experience in the Web and mobile
app development world so that its sequential manner of development would make our
development tasks easy-to-follow. The model also makes the testing experience easier to
accomplish.

9
There will be both server side and client side programming with industry standard technologies
to make the website more secure, interactive and user-friendly 1.9 Project Management plan
1.9.1. Time Management plan
1.9.1. Time Management plan

Complet Oct.27,16 Jan.1,17

ID Task Name Start Finish Duration
e Oct.27,16
Nov.1,16 Dec.1,16 Jan.1,17 Feb.1,17 Mar.1,17 Apr.1,17 May.1,17 Jun.1,17

1 Title Approval by Advisor Oct.27,16 Oct.30,16 0 w. 4 d. 100%

2 Proposal Nov.2,16 Nov.10,16 1 w. 2 d. 100%

3 Presentation Nov.19,16 Nov.19,16 0 w. 1 d. 100%

4 Requirement elicitation Nov.17,16 Nov.30,16 2 w. 0 d. 100%

5 Data collection Dec.1,16 Dec.17,16 2 w. 3 d. 100%

6 Design Dec.18,16 Jan.18,17 4 w. 4 d. 90%

7 Implementation Feb.18,17 Jun.18,17 17 w. 2 d. 96%

8 Testing Jun.18,17 Jun.25,17 1 w. 1 d. 94%

9 UMD Jun.25,17 Jun.30,17 0 w. 6 d. 97%

10 Finalizing Project Jul.1,17 Jul.7,17 1 w. 0 d. 100%

Figure 2: Figure 3:Time Management Plan Using Gantt chart

1.9 .2 Quality Management Plan

 It is easy for a court to lose control over the quality of its information

Some courts have effectively lost control of important data due to exclusive arrangements
that have been established with commercial information brokers that involve, for
example, external hosting of online filed documents without effective data repatriation
provisions or quality control checks.
 Risks to vulnerable people
Unlimited access to on-line court information may increase personal safety risks for
vulnerable people. This is particularly a concern in criminal and family law cases and in
cases involving juvenile justice. Personal information relating to witnesses, jurors,
victims of crime, troubled youths and children at risk will often need to be protected from
this access to minimise the potential for them to be exposed to harm. If this consideration
is not accommodated in systems that deliver court information on-line, the risks can be
greater than they were in the traditional paper based world due to the ease with which the
information can be accessed by anyone with Internet access.
10
  Access to disturbing material may cause distress or harm
Criminal Case Files often contain disturbing photo or video evidence that can cause
distress or even harm to those who become exposed to it whether inadvertently or
otherwise. It is easier for casual browsers who have no connection to such a case to either
accidentally or purposefully view such material where on-line access arrangements are
too liberally applied to information presented in court.

 It’s easier to leak sensitive court information and its impact is more
damaging
It is now much easier for a disgruntled ex-employee, participant in the justice system, or
member of the general public to publish such information instantaneously to millions of
people via the Internet, wiki-leaks style.

 Incorrect filling of the form cannot totally keep from mistakes

In the absence of clearly documented information management policies, designers
charged with the responsibility to design and implement new information systems will
sometimes make incorrect assumptions or may, at times, feel understandably compelled
to make important strategic business decisions themselves to fill a policy void.

Table 1: Communication Management Plan

Type of Method/ Tool Frequency/ Information Participants /

Communication Schedule Responsible

Internal Communication:

Project Meetings -Face to Face 5 times in a week Project status, Project team
problems,
risks, changed
requirements

weekly project -Face to Face Once a week Review status Advisor

status Meetings -Email of the project Project team
with the team. members

11
 Type of Method/ Tool Frequency/ Information Participants /
Communication Schedule Responsible

Technical Design -Face to Face Once a week Discuss and Advisor

Meetings develop Project team
technical members
design
solutions for
the project.

Final Project - Face to Face Once a month Wrap-up Advisor

Meeting - Conference Experiences Project team
Call members

External Communication and Reporting:

Project Report -Email Once a month Report the Advisor

-GitHub status of the Project team
project members
including
activities,
progress, costs
and issues.

SteCo Meetings -Conference Once a month Project

call Manager,
SteCo

Meeting Agenda
Meeting Agenda will be distributed 5 each week in advance of the meeting. The Agenda will be
identified with the presenter for each topic along with a time limit for that topic. The first item in
the agenda should be a review of action items from the previous meeting.

12
Meeting Agenda
Meeting minutes will be distributed within 2 business days following the meeting. Meeting
minutes will include the status of all items from the agenda along with new action items.

Action Items
Action Items are recorded in both the meeting agenda and minutes. Action items will include
both the action item along with the owner of the action item. Meetings will start with a review of
the status of all action items from previous meetings and end with a review of all new action
items resulting from the meeting. The review of the new action items will include identifying the
owner for each action item.

Meeting Advisor
The Advisor is good for distributing the meeting agenda, facilitating the meeting and distributing
the meeting ideas.

Note Taking
The Note Taking necessary for documenting the status of all meeting items, maintaining a
taking notes of anything else of importance during the meeting. The Note Taker will give a copy
of notes to other members.

Chapter 2: LITRATURE REVIEW

2.1 Introduction
This section describes the purpose, scope and an overview of the entire system.
2. 1.1 Scope
Digital Court Management System is the system which helps to make the current court system
automate Using Smart Phones and Computers, and simplify the current workload in the offices
since all work is done by these computers, create good communication system between staffs

13
Because the system enables users to communicate by sending message and Notifying the
updated information.
In-Scope:
Scope of this application is limited in a way that only the admin can register lawyers, prosecutors
and judges for this website and only lawyers and prosecutors can register their clients. Further,
the lawyer can maintain details of his client’s cases. Clients who are registered by the lawyer can
view their case details as entered and managed by the lawyer. Using this website, non-member
users can also find profiles of different lawyers and prosecutors registered with this website.
Out-of-Scope:
Registration of a lawyers, prosecutors and judges by themselves or registration of a client by
himself is out of scope of this system. Making payments to lawyers by the clients is also out of
scope of the system.

What our software product will do:

Enables communications between different courts, judges, lawyers as well as between both
clients and lawyers and prosecutors
 The system also automatically and contextually assign judges in order to increase
efficiency of the court so that it will save time and human resources for assigning the
judges.
 This site provides a flexible way for lawyers and clients to handle their cases in a well-
formatted way online through any part of the city. Also, new users can find lawyers
online according to their needs.
 Enables time improvement, information quality, enhanced data access and superior data
retrieval and reporting capabilities.

Lawyers and prosecutors will be able to:

 Open cases.
 Create schedule based on notification sent by the system. Such as an appointment.
 Register their clients.
 Send notification back to court, judges, admin and client.
 Updating information (time or schedule, place of meeting) regarding
specific case.
 Unscheduled communication with the client.
 When the case is closed.
 Follow their case outside the court’s compound.
 Communicate with their clients, courts, other and judges.
 Text Message or call
 Upload evidence and supporting materials (images, PDF, video, audio).

Admin will be able to

 Register lawyers, prosecutors and judges.
 Making updates.
 Notifying if there is change in time or schedule.
 Sending notification about the status of the case.
 Case approving.
 Get notifications regarding petition approving.

14
Judges will be able to:
 Send and receive notifications.
 Communicating with prosecutor, lawyer or admin.
 Send and receive update information regarding the case concerns the judge.

Clients will able to:

 Getting notification regarding their case by receiving notification.
 Getting information about the court, judges, lawyers, scenario of the court
 Communicate with their lawyers by sending message.

2.2 Reviewed System

In this document, we have explicitly articulated the requirement of DCMS in Detail. First
section deal with purpose, scope, objective of the project. Second part Provide General
Descriptions of the system, and overview of system in detail, the third section contain the main
part of this document’s external interface, functional, non-functional requirements along with its
use cases description and diagram. The last section contains change management process

2.3 Summary of the review

[This is optional since write this content if only the group members have done it so far]

15
Chapter 3: Requirement Analysis

3.1 Introduction
This section describes the purpose, scope and an overview of the entire system.

3.2 Scope
Digital Court Management System is the system which helps to make the current court system
automate Using Smart Phones and Computers, and simplify the current workload in the offices
since all work is done by these computers, create good communication system between staffs
Because the system enables users to communicate by sending message and Notifying the
updated information .

In-Scope:

Scope of this application is limited in a way that only the admin can register lawyers, prosecutors
and judges for this website and only lawyers and prosecutors can register their clients. Further,
the lawyer can maintain details of his client’s cases. Clients who are registered by the lawyer can
view their case details as entered and managed by the lawyer. Using this website, non-member
users can also find profiles of different lawyers and prosecutors registered with this website.

Out-of-Scope:

Registration of a lawyers, prosecutors and judges by themselves or registration of a client by

himself is out of scope of this system. Making payments to lawyers by the clients is also out of
scope of the system.

What our software product will do:

16
Enables communications between different courts, judges, lawyers as well as between both
clients and lawyers and prosecutors

 The system also automatically and contextually assign judges in order to increase
efficiency of the court so that it will save time and human resources for assigning the
judges.
 This site provides a flexible way for lawyers and clients to handle their cases in a well-
formatted way online through any part of the city. Also, new users can find lawyers
online according to their needs.
 Enables time improvement, information quality, enhanced data access and superior data
retrieval and reporting capabilities.

Lawyers and prosecutors will be able to:

 Open cases.
 Create schedule based on notification sent by the system. Such as an appointment.
 Register their clients.
 Send notification back to court, judges, admin and client.
 Updating information (time or schedule, place of meeting) regarding
specific case.
 Unscheduled communication with the client.
 When the case is closed.
 Follow their case outside the court’s compound.
 Communicate with their clients, courts, other and judges.
 Text Message or call
 Upload evidence and supporting materials (images, PDF, video, audio).

Admin will be able to

 Register lawyers, prosecutors and judges.

 Making updates.
 Notifying if there is change in time or schedule.
 Sending notification about the status of the case.
 Case approving.
 Get notifications regarding petition approving.

Judges will be able to:

 Send and receive notifications.

 Communicating with prosecutor, lawyer or admin.
 Send and receive update information regarding the case concerns the judge.

17
Clients will able to:

 Getting notification regarding their case by receiving notification.

 Getting information about the court, judges, lawyers, scenario of the court
 Communicate with their lawyers by sending message.

3.3 General Description

This section describes the product perspective, product function, user characteristics, general
constraint and the assumptions and dependencies of the system.

3.4 Product Perspective

The DCMS system is a new and self-contained product intended to provide a mechanism for
giving automated system and efficient way to solve current manual system and old fashion. The
product is a web based system that implement client-server model.

The following are among of main features that are included in this product:

Communication: The system will enable the communication between staff (lawyers,
prosecutors, judges and admin) as well as between lawyers and their clients.
Opening case: lawyers and prosecutors can open the new case online.
Scheduling: The system automatically create schedule and Lawyers can make schedule from the
notification for their case and to communicate with clients.
Automatic Assigning: the system can automatically assign judges based on the content of the
cases.
Information: users can see detail information about the court and even lawyers, Prosecutors,
judges and work flow of the court, so that the users can select any available lawyer they want.
Registration: admin can register the lawyers, prosecutors and judges as well as lawyers can
register their clients.

3.5 Product Functions

This system will consist of two parts: one mobile application and one web portal. The mobile
application will be used to create communication channel between all the users (Judges,
prosecutor, plaintiff and defendant, Lawyers) in a standard format. While the Web portal will be
used to manage the system and data in the office.
The Mobile Application The mobile application will need to create communication with the
other phones on clients having the same Application to interchange information like schedule or
appointment, detail information of specific case, payment information etc.

18
 Database

Web Service

Mobile Application Web Portal

3.6 User Characteristics

The admin must have a hands-on knowledge of how a computer system works as he has to
manage the entire website. The admin can either be a programmer or somebody trained to
execute the job that the administrator does which is mentioned below in the use case scenarios.
The person using the website as a lawyer, prosecutor, judge or client must be able to operate a
computer and an android system. Each of them will be given an account by the admin except the
client who is given an account by the lawyer he/she hires or a prosecutor who is assigned to
them.

3.7 General Constraints

Compatibility – Software should run compatibly (i.e. under the same operating system, database
and networking capabilities) with the other subsystems it works together with. – It must allow an
Administrator to enroll new users and give them access into the system.

1. Reliability and Availability

In order to make the System more reliable and available at all the time, it needs an
electric power of a normal delivery (220V) and there should be an Electric power
Generator incase if electric power is not there or is off. So any failure results in only a
few minutes of downtime.

2. Storage
The System requires 2 storage Devices of capacity of a minimum of 1 Terabyte size. One
will be used by the system at any time and the other is used for backup, in case one fails
the other can replace.

3. Skilled Man Power

19
 The System requires a skilled man power that can maintain the server in case of failure
and so that the system can return to its function with a short period of time.

4. Internet
This System completely functions in the presence of internet. So a 3mb/s is required to
make the system more speedy for the Web side (Data retrieval, Access of Data) and make
the communication system more fast where there is not much of mobile network for the
Mobile Side.

5. Memory:
To run the Website, A Computers must have an 8 GB RAM with 700GB HDD and for
mobile application, the phones must have an Android Operating System with minimum
of 1GB RAM and a free space of 100MB. As to the website since it uses the default
browsers on the computers any memory requirement will depend on it.

6. Language requirements: software is multilingual, including the following languages:

English, and Amharic. So anyone that accesses the system should be able to understand
both English and Amharic languages.

3.8 Assumptions and Dependencies

Full working of DCMS is dependent on the availability of Internet connection. The details of the
client’s cases are as entered by the lawyer and gets updated only when the lawyer updates it. It is
assumed that all the case-transaction related contents posted by the lawyers is true, however, the
software is a stand-alone website managed by the admin and registered lawyers. No part of the
website is dependent on or is concerned with the websites of any court. Only the lawyers or
prosecutors shall be responsible for the contents they have posted. It is also assumed that all the
lawyers who want to register with this website contact the admin and provide the proof of their
identity, all outside the scope of the software. It is also assumed that payment is done explicitly.

3.9 External Interface Requirements

This section describes different external interface requirements of the system:
One way to search lawyers can be by selecting a type and getting list of all the lawyers available
in that type. Court-type can also be mentioned with this. Other way is where photographs along
with the names of all the available Lawyers should appear while any user searches for lawyers.
Appendix shows the intended user screen.

3.9.1 User Interfaces

3.1.1.1 User Interfaces for mobile application
All visitors, clients (Defendant and Plaintiffs) and staff cannot get any information unless they
get registered by admin and get account.
The correspondent users can get notification regarding their case.
Besides they can also create send Data to each other

20
3.1.1.2 User Interfaces for website
The first visitors, clients, judges, prosecutors or lawyers visit the website will see only the home
page, lawyer’s information and browse the content by category.
The system will not allow people to login to the system without registering by the admin (staff)
and without getting account from their lawyers (clients), and participate in anything rather than
viewing some allowed information such as lawyers detail information (visitors).

3.9.2 Hardware Interfaces

Wireless Ethernet Card for internet connectivity or wireless internet connectivity.

3.9.3 Software Interfaces

Web Browser such as latest Internet Explorer 8.0 or later, Google chrome, Mozilla Firefox or
any browser to communicate with the system.
The system uses ‘MySQL’ interface to create communication of web Portal and mobile
application with database.
So We are going to use web service for the communication between the Mobile App or the Web
Portal and the Database.

3.9.4 Communications Interfaces

3.1.4 Communications Interfaces

For web based platform is a website which is directly accessible by any browser of any device, it
will be accessed using the standard HTTPS for client-server communication on port 8080. For
mobile app users must get the software (android) and install it.

3.10 Functional Requirements

This section describes different functional requirements of the system in terms of the
Functions/features the system should provide.
1. Login for Admin (by Admin)
2. Registration of Lawyer, Judge and Prosecutor (by Admin)
3. Update details of Lawyer, Judge and Prosecutor (by Admin)
4. Delete Lawyer, Judge and Prosecutor (by Admin)
5. Login for Lawyer, Judge and Prosecutor (by Lawyer, Judge and Prosecutor)
6. Registration of Clients (by Lawyer or Prosecutor)
7. Update details of Clients (by Lawyer or Prosecutor)
8. Delete Client (by Lawyer or Prosecutor)
9. Add details of Clients (by Lawyer or prosecutor)
10. Update case details (by Lawyer or prosecutor)
11. Delete Cases (by Admin)

21
 12. Login for Client (by Client).
13. View Case Details concerning the client (by Client)
14. Visiting of Website (by Any New User)
15. Finding Lawyers (by a Visitor)
16. Notify schedule (by system)
17. Create schedule (by Lawyer or prosecutor)
18. Send schedule (by Lawyer or prosecutor)
19. Send message communication (by Lawyer/prosecutor/client)
20. Call communication(by Lawyer/prosecutor/client)

After being logged in, an admin in this project can enter the details of the lawyers or prosecutors
or judges that register with the website, can update details of lawyers/prosecutors/judges or
delete the account of lawyers/prosecutors/judges. Only after a lawyer/prosecutor/judge is
registered by the admin, he/she can further carry out tasks with their respective clients. When a
lawyer/prosecutor/judge wants to register for the first time, they gets an id and password from
the admin which they can use to login in to the system.
After being logged in, a lawyer/prosecutor can register their clients, update client’s details, delete
a client’s account and can store all the case details of his clients in the database. Also the cases
that have been terminated unexpectedly (due to withdrawal, death, etc.), or those that have been
won by a lawyer/prosecutor are stored in the database which he can use as a reference for future
cases. A lawyer/prosecutor can also update the case details of their clients and can also delete
some cases if desired.

After being logged in, a client can see his/her case details and all the transactions carried out
during the judicial process. She/he can also find out new lawyers through this website.
New visitors can also visit this site and find lawyers online by viewing the details of the lawyers
available in the website and selecting the one best suited for them. They can do this by simply
entering their valid name and e-mail ids (i.e. by registering themselves). The services provided
by the system are free of charge. By default, a list of all the lawyers/prosecutors registered with
the website appears. Out of these listed, specific lawyers/prosecutors can be searched based on
their detail.

3.10.1 Registering to the system

3.10.1.1 Introduction: This sub-section specifies the registration part of the system for getting
account.
3.10.1.2 Inputs: The system will require the lawyers, prosecutors and judges’ information such
as: name, age, phone number, email, photo, city, profession, and year of experience, role
(lawyer, prosecutor and judge)
3.10.1.3 Processing: The system will register the specified user in a database by admin
3.10.1.4 Outputs: User account (user name and password)
3.10.1.5 Error Handling: authentication and filtering
The system will register the specified user in a database.

22
3.10.2 Communications
3.10.2.1 Introduction: This sub-section of the system will enables the communication between
staff (lawyers, prosecutors, judges and admin) as well as between lawyers and their clients.
3.10.2.2 Inputs: The system will contain information such as: title, date, description and type.
3.10.2.3 Processing: The system will send notification for specified staff.
3.10.2.4 Outputs: message through notification.
3.10.2.5 Error Handling: notifying whether it was sent or not.
References Figure 1
3.10.3 Online opening case
3.10.3.1 Introduction: lawyers and prosecutors can open the new case online.
3.10.3.2 Inputs: The system will request information such as: id, title, date, type, description,
witness, date
3.10.3.3 Processing: The system will save the case to the online database.
3.10.3.4 Outputs: creating new case file and ordering based on date.
3.10.3.5 Error Handling: authentication
References Figure 1
3.10.4 Scheduling
3.10.4.1 Introduction: to communicate with clients.
3.10.4.2 Inputs: The system will take information such as: title, description, date, owner of case.
3.10.4.3 Processing: The system automatically create schedule and Lawyers can make schedule
from the notification for their case and
3.10.4.4 Outputs: Notifications
3.10.4.5 Error Handling:
References Figure 1
3.10.5 Automatic Assigning
3.10.5.1 Introduction: This is the part of the system which assign judges based on the content of
the cases automatically.
3.10.5.2 Inputs: The system will take information from the case upload by lawyer based on type
of case.
3.10.5.3 Processing: The system can automatically assign judges based on the content of the
cases.
3.10.5.4 Outputs: avoid delaying of appointment
3.10.5.5 Error Handling:

3.10.6 Information
3.10.6.1 Introduction: This subsection of the system enables users to see detail information for
the lawyer of their need.
3.10.6.2 Inputs: The visitors will text in the search for the information they want to get or by
choosing option
3.10.6.3 Processing: The system search for the type of lawyers based on the information
provided.
3.10.6.4 Outputs: Court, Lawyers, prosecutors, judges and other detail information.
3.10.6.5 Error Handling:
References Figure 2

23
Principal Actors:

The website has 6 principal actors:

1. Admin: IT professional
2. Lawyer: a person who knows about law and work in his/her own.
3. Prosecutor: a person who has a profession in law and work in government organization
(court).
4. Judge: a person who has profession in law and has skill on court by giving final decision on
case
5. Client: it will be either Defendant or Plaintiff.
6. Visitor: a person who wants to visit the system.
Use cases
1. Login
2. Registration
3. Add client
4. Opening case
5. Confirming and closing the case
6. Remove client.
7. Delete Actors.
8. Update Actors
9. Information of Prosecutor or Lawyer
10. Information of Court workflow
11. Information of Constitution
12. Call Communication
13. Message Communication
14. Creating Schedule
15. Notify Schedule
16. Send Schedule
17. Delete Schedule

3.11.1 Use Case #1

Use case name: - Login
Primary actor: - Admin, Client, Lawyers, Prosecutor and Judges
Summary: - All the primary actors Login in to the system.
Pre-condition: - All the primary actors must be registered except the admin who gets an account
from the developer.
Post-condition: - All the primary actors can access their account.
Trigger: - Choosing to login ()

Main success scenario

24
1. Select login.
2. System will display login dialog.
3. User will fill password and username.
4. The system will authenticate the users.
5. Login confirmation
6. The system will display the primary actor’s home page.
7. UC-1 performed

Extension
3a. The User fills wrong username and/or password
3a1.System displays failure message and prompt the user to enter the correct username and/or
password

Alternative Path
5a. Click forgot account link.
5a1. User enters email.
5a2. Password reset link will be emailed to the user.
3.11.2 Use Case #2
Use case name: -Registration
Primary actor: - Lawyers, Prosecutor and judges
Summary: - The admin will register Lawyers, Prosecutor and judges in to the system.
Pre-condition: - First the admin must get an account from the system and log in.
Post-condition: - They will have a user account in the system.
Trigger: - Choosing to register ()

Main success scenario

1. Select register option.
2. Fill out the required information.
3. Cancel or confirm the registration.
4. System will display a registered successfully message in Home page.
5. The system will send an email confirmation.
6. UC-2 performed

Extension
4a. admin doesn’t fill all information requested by the system
4a1.System displays failure message and prompt admin to fill all information correctly

Alternative Path
5a. Admin wants to cancel registration before completing the operation.
5a1.Admin selects the cancel option, and goes back to Home page.

3.11.3 Use Case #3

Use case name: -Add client
Primary actor: - Client

25
Summary: - The Lawyer or prosecutor will register Client in to the system and Lawyer or
prosecutor Log in.
Pre-condition: - First the Lawyer or prosecutor must get an account from the Admin.
Post-condition: - They will have a user account in the system.
Trigger: - Choosing to register client

Main success scenario

1. Select add client option.
2. Fill out the required information.
3. Cancel or confirm the registration.
4. System will display a registered successfully message in Home page.
5. The system will send an email confirmation.
6. UC-3 performed

Extension
4a. Lawyer or prosecutor doesn’t fill all information requested by the system
4a1.System displays failure message and prompt Lawyer or prosecutor to fill all information
correctly

Alternative Path
5a. Lawyer or prosecutor wants to cancel registration before completing the operation.
5a1. Lawyer or prosecutor selects the cancel option, and goes back to Home page.

3.11.4 Use Case #4

Use case name: - Opening a new Case
Primary actor: - Lawyers, Prosecutor
Summary: - The lawyer or prosecutor will fill a form and submit
Pre-condition: - Clients must be assigned a lawyer or prosecutor.
Post-condition: - The case will be reviewed by the System and get the first Appointment.
Trigger: - Click new case Button.

Main success scenario

1. Clicking login by lawyer or prosecutor
2. Fill password and user name
3. The system displays prosecutor or lawyer page
4. Select new case option
5. Fill information required by the system
6. Select case type
7. Cancel or Submit form
8. The system will be automatically assign judges
9. UC-4 performed
Extension
2a. Lawyer or prosecutor fill wrong User name and password
2a1. System displays authentication failed message and prompt prosecutor or lawyer to fill it
again
5a. Lawyer or prosecutor doesn’t fill all information requested by the system

26
 5a1. System displays failure message and prompt admin to fill all information correctly
Alternative Path
7a. Lawyer or prosecutor wants to cancel opening case before completing the operation
7a1. Lawyer or prosecutor selects a cancel option, and back to Lawyer or prosecutor page.

3.11.5 Use Case #5

Use case name: - Confirming and closing the case.
Primary actor: - Judge
Summary: After the final decision the Judge will close the case.
Pre-condition: -The final decision must be known and Judge will login.
Post-condition: - The defendant can appeal.
Trigger: - Close button clicked.
Main success scenario
1. Select “close” option
2. Cancel or confirm.
3. Send notification
4. UC-9 performed

Alternative Path
2a. “Cancel” button clicked
2a1. The system back to the judge’s home page
2b. “Confirm” button clicked
2b1. “Case Successfully closed” dialog box is shown

3.11.6 Use Case #6

Use case name: - Remove client.
Primary actor: - Prosecutor, client
Summary: Prosecutor can delete client after the case is closed.
Pre-condition: -
 The Prosecutor/Lawyer should login
 Client should have an account to be deleted.
 The case needs to be closed.
Post-condition: - The client will be deleted by Prosecutor or Lawyer.
Trigger: - Delete client button clicked.
Main success scenario
1. Select “Delete / Remove client” option.
2. Cancel or Confirm deletion.
3. The System deletes the intended client and Send Notification to the Admin that the client
is deleted.
4. “Successfully Deleted” message dialog box appears.
5. UC – 6 performed.
3.11.7 Use Case #7
Use case name: - Delete Actors.
Primary actor: - Judge, Prosecutor, Lawyer.
Summary: Admin can delete Judge, Prosecutor, and Lawyer that are unable to function no
longer: incase died, left the Office.

27
Pre-condition: -
 Admin logs in
 Judges, Prosecutors and Lawyers should have an account to be deleted.
Post-condition: - The Judges, Prosecutors and Lawyers will be deleted by Admin.
Trigger: - Delete Judges, Prosecutors or Lawyers button clicked.
Main success scenario
1. Select “Delete / Remove Judges, Prosecutors or Lawyers” option.
2. Cancel or Confirm deletion.
3. The System deletes the intended Judges, Prosecutors and Lawyers and Send Notification.
4. “Successfully Deleted” message dialog box appears.
5. UC – 7 performed.

3.11.8 Use Case #8

Use case name: - Update Actors
Primary actor: - Judge, Prosecutor, Lawyer
Summary: Admin can update information of Judges, Prosecutors, and Lawyers on their profile.
Pre-condition: -
 Admin logs in
 Judges, Prosecutors and Lawyers should have an account to be updated.
Post-condition: - The Judges, Prosecutors and Lawyers will be updated by Admin.
Trigger: - Update Judges, Prosecutors or Lawyers button clicked.
Main success scenario
1. Select “Update Judges, Prosecutors or Lawyers” option.
2. Cancel or Confirm Update.
3. The System updates the intended Judges, Prosecutors and Lawyers and Send Notification
to the updated actor.
4. “Successfully Updated” message dialog box appears.
5. UC – 8 performed.

3.11.9 Use Case #9

Use case name: - Information of Prosecutor or Lawyer
Primary actor: - Prosecutor, Lawyer
Summary: The system shows updated information of Prosecutors, and Lawyers and posts on the
website to make it visible to the clients.
Pre-condition: -
 Prosecutors and Lawyers login.

Post-condition: - Prosecutors and Lawyers can post their profile information on the website.
Trigger: - “Edit profile Prosecutor/Lawyer” button clicked.
Main success scenario
1. Select “Edit profile Prosecutor/Lawyer” option.
2. Cancel or Confirm Post.
3. The System posts the intended information of Prosecutors and Lawyers and Send
Notification to the respective actor.
4. “Successfully posted” message dialog box appears.
5. UC – 9 performed.

28
3.11.10 Use Case #10
Use case name: - Information of Court workflow
Primary actor: - Admin
Summary: The system shows updated information of Court workflow and posts on the website to
make it visible to the clients.
Pre-condition: -
 Admin logs in.
Post-condition: - Admin can post information of court workflow on the website and Users can
read and understand.
Trigger: - “Post Court Information” button clicked.
Main success scenario
1. Select “Post Information of the Court” option.
2. Cancel or Confirm Post.
3. The System posts the intended information of Court. It will be visible on the website.
4. “Successfully posted” message dialog box appears.
5. UC – 10 performed.

3.11.11 Use Case #11

Use case name: - Information of Constitution
Primary actor: - Admin
Summary: The system Posts updated information of constitution to make it visible to the clients.
Pre-condition: -
 Admin logs in.
Post-condition: - Admin can post information of constitution on the website and Users can read
and understand.
Trigger: - “Post Constitution” button clicked.
Main success scenario
1. Select “Post Constitution” option.
2. Cancel or Confirm Post.
3. The System posts the information constitution. It will be visible on the website.
4. “Successfully posted” message dialog box appears.
5. UC – 11 performed.

3.11.12 Use Case #12

Use case name: - Call Communication
Primary actor: - Clients (plaintiff and defendant), Lawyers, and Prosecutor and judges
Summary: -
 The Prosecutors can Call to the client
 The client can make a call to the prosecutor/Lawyers
 The Prosecutors can Call to the Judge
 The Judges can Call to the Prosecutor
Pre-condition: -
 The actors need to get the Mobile Application and an account from
Admin.

29
  Actors log in
Post-condition: - They can communicate and exchange information to each other.
Trigger: - Make a call button clicked

Main success scenario

1. Select “Call” option
2. Chooses the recipient from the contact
3. Cancel or Make a Call.
4. Call made or failed
5. UC -12 performed

3.11.13 Use Case #13

Use case name: - Message Communication
Primary actor: - Clients (plaintiff and defendant), Lawyers, Prosecutor and judges
Summary: -
 The clients (plaintiff and defendant) can send message as well as upload files (image,
video, pdf, and doc) which are evidence and can be added to the case.
 The Prosecutors or Lawyers can send message to the Judges.

Pre-condition: - First all the actors need to get an account from Admin and login.
Post-condition: - They can send message and exchange information to each other.
Trigger: - Sending Message

Main success scenario

1. Select “Message” option
2. Chose the format “text” or “upload files”
3. Chooses the recipient
4. Cancel or send message
5. Message sent or failed
6. UC -13 performed

3.11.14 Use Case #14

Use case name: - Creating Schedule
Primary actor: - Prosecutor, Lawyer, Judge
Summary: - After the case is reviewed, The Judges can make an appointment for additional day
and the prosecutor can notify the clients.
Pre-condition: -
 Case must be opened.
 Actors will log in
Post-condition: - Notification of schedule to the actors and clients.
Trigger: - create schedule

Main success scenario

30
 1. Lawyer or Prosecutor select create schedule option to communicate with client regarding
their case.
2. Choose level for creating schedule (directly from notification or by filling form)
3. Fill information required by the system
4. Create schedule
5. “Successfully created” message dialog
6. UC-14 performed

3.11.15 Use Case #15

Use case name: - Notify Schedule
Primary actor: - Prosecutor, Lawyer, Judge
Summary: - The created schedule can be updated and Notification will be sent to all actors.
Pre-condition: -
 Actors will log in
 Schedule should be created
 The mobile should have an alarm
Post-condition: - All actors will be notified.
Trigger: - Reminding schedule

Main success scenario

1. Lawyer or Prosecutor select “Remind schedule” option to create reminder for the
schedule.
2. Fill information required by the system
3. The system will display “reminder set”.
4. UC-15 performed

3.11.16 Use Case #16

Use case name: - Send Schedule
Primary actor: - Prosecutor, Lawyer, Judge
Summary: - The created schedule can be sent inform of Notification to all actors.
Pre-condition: - Actors will log in and schedule should be created
Post-condition: - Deletion of schedule will be done.
Trigger: - Deletion of schedule

Main success scenario

1. Lawyer or Prosecutor select “Send schedule” option to send the created schedule
regarding their case.
2. Fill information required by the system
3. Update schedule and create Alarm
4. “Successfully Sent” message dialog
5. UC-16 performed

3.1.17 Use Case #17

Use case name: - Delete Schedule
Primary actor: - Clients (plaintiff and defendant), Lawyers, Prosecutor and judges
Summary: - The clients (plaintiff and defendant) can delete schedule if not needed or the
schedule time is removed.

31
Pre-condition: - First login and the schedule should be created.
Post-condition: - They can send message and exchange information to each other.
Trigger: - Sending Message

Main success scenario

1. Select “delete schedule” option
2. Cancel or Confirm.
3. “Schedule Deleted” dialog box shown.
4. UC -17 performed

3.12 Non-Functional Requirements

3.12.1 Performance
90% of the responses should be within 2 sec, except for downloading the entire case history for
which more time is acceptable.
3.12.2 Reliability
Data must not become corrupted in case of system crash or power failure.
3.12.3 Availability
The system will work 24/7 as much as internet connection is available and server is not down
3.12.4 Security
Data containing information regarding client’s case should be secured against malicious
deformations. Security for the HACS includes authentication, access control, data integrity, and
data privacy. Authentication of the user is done by an identifier and a password.
3.12.5 Maintainability
The system should be having high maintainability in terms of correctness, adding new
functionalities and should be highly adaptive.
3.12.6 Portability
Our software can run on many devices like computer windows and for mobile android operating
system.

3.12.7 Responsiveness
The Web system is responsive to different kind of devices (Computer, Tablet, and Mobile
Devices) to make it portable.
The Mobile App is suitable for Android platform of all versions for as to make it operational
across different android versions (lower versions).

32
3.12.8 Synchronization:
The system is able to sync the data from the mobile application with the data from the website
into the database using an API that uses a JSON format. This way user account data across
different devices will be the same.

3.13 Inverse Requirements

The system has to fulfill all functional and non-functional requirements that are explicitly
articulated above. But there are some actions that the system will not deal with. Some of these
are:
 The system will not allow country cross check.
The system does not allow users to register themselves.

3.14 Design Constraints

The major design constraint is creating a communication mechanism for the clients and their
respective lawyers and prosecutors since they cannot by themselves register in to the system.

3.15 Logical Database Requirements

Logical database required for the system to store user personal information, opened case data,
uploaded material and other general information will stored in large storage database server.
The logical data required for our project is User, Material and Group project.

User
Data item Type Description
Full Name String User’s name
User Name String For login into the system
Password varchar For login into the system
Specialization area String On which area she/he did
most
Email varchar User’s email address
Phone Number Int User’s phone number
Role String The role of the user(Lawyer,
Prosecutor or Judge)
Age Int Age of the user’s
Address varchar Where the user lives
Nationality String Where the user came from
Gender Char sex

Table 2:User entity description

User entity description

33
Material – Contains attributes
Title - Title of the material and String type.
Specialization - On which area the users where doing and String type.
Content - On which area the users where doing and Blob type.

Group project – Contains attributes

Project Title - Title of the group project and String type.
Date - Date of submission and Date type.
Project Data - The project material and Blob type.

3.16 Other Requirements

Training-related Requirements

The following users will be trained.

 Prosecutors or Lawyers:
Will be trained on how to open a new case by filing the minimum requirement required to
open the case by the system. This is useful to show eliminate incorrect filling of forms
and cases.
 Clients
The plaintiffs and the defendant may be older peoples or they may be peoples who
doesn’t have much interaction with mobile phone from rural are so special training is
required on how to communicate with their prosecutor or lawyer. In order to send a data
or upload files.
 Judges
If Judges may have not been used the system before, he/she is required to know the
details of the software in order to reduce time wastage, self-confidence and even data
loose.
 Admin
The Admin can be Naive person or programmer which has never used the system before.
So in any case they both need to be informed and have a detail knowledge about the
system in depth. Because the Admin can do functions beyond other users, Detail
knowledge for Admin is must.

Packaging Requirements
The system functions online. This is not a desktop application (.exe). So we are going to put it in
a folder and deploy on the local server with IP Address. But for mobile application its (.apk) and
the user can install it on a smart phone.

Legal Requirements
Copyright laws and license agreements are claimed under the ownership of AAIT-ITSC.

Packaging Requirements

How the system is packed (folder with code or in exe format or……) if there is any file for the purpose of help
(README file) and Any If the is makefile for recompilation

34
Legal Requirements

Copyright laws and license agreements

3.17 Change Management Process

Since we are using a water fall model, we will add new detailed information and more
specifications for further requirements that we find in the next versions of this product.

35
 Chapter 4: SYSTEM DESIGN

4.1 General Overview

The following diagram briefly describe how tasks will be accomplished using the system

Figure 4 : overview of the system for mobile users

4.2 Development Methods & Contingencies

The development method used for the DCMS is the methodology that can bring some new
changes. This project has used the Unified Software Development Process and Object Oriented
techniques The concepts such as, data encapsulation, communication through interfaces and code
re-use through polymorphism shall be considered in order to keep the system efficiency and
consistency along with Unified Modeling Language. All the approaches taken, decisions made
are documented.

Contingency plans are required to address exceptional situations when there is something that
might possibly happen in the future, usually causing problems or making further arrangements
necessary. In order to solve such kind of problems, we planned to change the methodology we
used. When it needs change, our system can be improved based the required information and
methodologies.

36
4.3 System Architecture
4.3.1 Subsystem decomposition
UML Component Diagram

Retrieved from
Uses
DCMS Resource Database
Store

DCMS

Lawyer / Plaintiff /
Judge Naive Client
Prosecutor Defendant

Resources

Resources for Resources for

Resource for Information for
Lawyer / Plaintiff /
Judges Naive Client
Prosecutor Defendant

Figure 5:UML Component Diagram

37
 4.3.2 Hardware/software mapping

Client
Client
Mobile
Web Applicatio
Browser n

JSON Https
JSON Https

Web
Service

Wamp/Xa
mpp
Server

Figure 6: UML Deployment diagram

38
4.4 Object Model
4.4.1 Class Diagram

Evidence <<Interface>>
Witness
UserPage
-evidenceType
-date -submissionDate +openCase();
-time +updateCase();
-submissionTime
-reason +removeCase();
-sourceName
-placeOfEvent +confirmCase();
-testimony +createEvidence(); +closeCase();
+updateEvidence(); +recievenotification(); Aggregation
+addWitness(); *0..** +deleteEvedince(); relation ship
+removeWitness(); 0..* +submitEvidence();
+updateWitness();
Name +resetEvidence();

*
0..* Manages
*

provides
Schedule

Person Account -date

-time
-userName -title
-fullName
-password -scheduleType
-address 1 1 Alarm
-accountType -description
-age get
-nationality +createAccount(); -reason -alarmID
Describes the +editAccount(); -alarm
-phoneNumber -alarmType
generalisation +deactivateAccount();
-email -alarmDate
relationships +login(); +createSchedule():
-gender -alarmTime
-photo +logout(); +notifySchedule(): -alarmTitle
+sendSchedule():
+updateSchedule(): +createAlarm
+startAlarm():
0..* * +removeSchedule(): +changeAlarm():
0..* * +stopAlarm():
+deleteAlarm():

manages
*

1 1 1
Interface1 1
Lawyer/Prosecutor Admin
Judge Client
0..* * 1 * -experience
-chilot clientType -levelOfEducation
-assignedCourt -experience
manage
* +createAccount():
-experience -levelOfEducation 1 0..*1 +searchLawyer():
-levelOfducation -certificate +editAccount():
+recieveNotification():
-qualification -qualification +activateAccount():
+editAccount():
+deactivateAccount():
+closeCase(): +deactivateAccount():
+dispatchMessage():
+Notify(): * * 1
* +recieveMessage():
+removeCase(): +openCase(): +recieveNotification():
+editAccount(): +updateCase(): 1 +login();
+removeAccount(): +editAccount(): +logout();
+recieveNotification(): +removeAccount():
recieveNotification(): see
* see *
* * *
1 *
*
1
1
1..*
Information
Case
1 0..1
-caseNumber 0..* -name
0..* 0..*
-dateOfCase -date
Message -title
1 -typeOfCase
-titleOfCase -description
1 -name
1 -reason -infoType
-tiltle
-opposeReason -phone
manages 1..* -description
-witness -date +findLawyer():
-caseKey +addDocument():
-lawyerName +isInvalidDocument():
+dispatch():
-plaintiffName +findDocument():
+recieve():
-defendentName +findConstitution():
+notify():
+seeCWorkflow():
0..* +visitLatestNews():
+open():
1 +updateInfo():
+close():
+update():
+confirm():
+remove():
+notify():
+addWitness();
+removeWitness();
+updateWitness();
+createEvidence();
+submitEvidence();

see

39
 4.4.2 Sequence Diagram

Opening case

opencase opencase prosecutorpage newcase newcase cases

<<Boundary>> <<Controller>> <<Boundary>> <<Boundary>> <<Controller>> <<EntityDB>>
User
click()

login()

<<create>>

check

<<create>>

<<create>>

<<click>>

selectoption()

fillform()

confirmation

submit()

store()

displaysuccessfu
l
displaysuccessfu
l
displaysuccessf
ul

Figure 7: Sequence Diagram-1

40
 Create Case

createSchedule ScheduleController ScheduleDB NotifySchedule

<<Boundary>> <<Controller>> <<EntityDb>> <<Boundary>>
user
click()

fillchedulef
orm
submit()
check

store()

<<create>>
<<create>>

displaySchedule

displayScheduleNotification

Figure 8: Sequence Diagram-2

41
 Close Case

case closecase cases

<<Boundary>> <<controller>> <<EntityDB>>

User
click()

login()

authenticate
selectOptio
n()
confirmation
selectoptio
n()
<<create>>
check

<<create>>

update()

sendUpdate()
confirm

displaysuccessful

Figure 9: Sequence Diagram-3

42
 Delete Schedule

deleteSchedule ScheduleController NotifySchedule ScheduleDB

<<Boundary>> <<Controller>> <<Boundary>> <<EntityDB>>
user click()

confirmation
chooseOpti
on()
<<create>>

<<create>>
store()

update()

displaySuccessful()
displaySuccessful()

displayNotification()

Figure 10: Sequence Diagram-4

43
 Delete User

deleteusers() deleteusers() deleted() users

<<Boundary>> <<Controller>> <<Boundary>> <<EntityDB>>
User
click()
selectoptio
n()

confirmation
selectoptio
n()
<<create>>

<<create>>
update()

sendUpdate()
sendUpdate()

Figure 11: Sequence Diagram-5

44
 Login

login login userpage

<<Boundary>> <<controller>> <<Boundary>>

User
click()

fillform()
<<create>>
check

success
loginsuccessful
()
<<create>>

display

Figure 12: Sequence Diagram-6

45
 Message
Communication

ComposeMessage MessageController Messagesent

<<Boundary>> <<Controller>> <<EntityDB>>

User click()
choosefor
mat()
<<create>>

selectOption
displayOption

composem
essage()
fillreceipt()

confirmation
selectoptio
n()
selectoptio
n()
check

<<store>>

displaysuccessful()
displaysuccessful()
displaysuccessful()

Figure 13: Sequence Diagram-7

46
 Send schedule

SendSchedule ScheduleController NotifySchedule sentSchelueDB

<<Boundary>> <<Controller>> <<Boundary>> <<Entity>>
User
click()

fillform()

confirmation

chooseOpti
on
<<create>>
check

<<create>>
store()

schedulesent
schedulesent

displaySchedulesent()

displaySchedulesent()

alt
[validInput]

store()

return

Acknowledge

[IsNotValid]

return exception
display error dialog

Figure 14: Sequence Diagram-8

47
 Signup

Signup Database Controller userDB

<<Boundary>> <<Controller>> <<Entity>>

User
click()

fill form
<<create>>
return to signup
UI
Check

displaySignupUI
submit
store()

alt [ValidInput]

Store();
return
Acknowledge

IsNotValid

return exception
display Error dialog

Figure 15: Sequence Diagram-9

48
4.5 Detailed Design
Table 3: Person class

Users
-fullName:String
-phoneNumber:Integer
-address:String
-email:String
-age:Integer
-nationality:String
-gender:Char
-photo:BLOB

Table 4: Attributes description for Person class

Attribute Type Visibility Invariant

Name: String Private Name <> NULL and must contain first, middle and last name
and shouldn’t contain special characters and integers.
PhoneNumber Integer Private PhoneNumber <> NULL must be 10 digits and must start by
+251/09
Address String Private Address <>NULL and it must be between 12 to 20 characters

Email String Private Email <> NULL

 Must contain @
 Must contain. (dot)
 Position of @ >1
 Position of (dot)>position of @ + 2
 Position of (dot)+3<= total length of email address and
the total character of the Email is at least 5 characters
Age Integer Private Age<>NULL must be 2 digits
Nationality String Private Nationality<>NULL and it must be between 5 to 20 characters
Gender Char Private Gender<>NULL it must be one character either M or F
Photo BLOB Private Photo<>NULL and not greater than 300MB.it can be all
formats.

Table 5: Account class

49
 Admin
-userName: String
-password:String
-accountType:String

+createAccount();
+editAccount();
+deactivateAccount();
+login();
+logout();

Table 6: Attributes description for Account class

Attribute Type Visibility Invariant

UserName: String Private UserName <> NULL and it may or may not has special
characters and integers. Must be greater than or equal 6
characters
Password String Private Password <> NULL must be greater than 10 digits and must
have capital letter, number and small characters.
AccountType String Private AccountType <>NULL and must have to select proper type of
account

Table 7: Operation description for Account class

Operation Visibility Return Argument Pre-Condition Post Condition

type
createAccount() Public void Person The user personal The user personal
information information
shouldn’t exist should exist
editAccount() Public void password The user The user
information information
50
 shouldn’t exist should exist
deactivateAccount() Public void Password Both the user’s User’s
information information
shouldn’t exist should exist
login() Public void Username User can’t able to User must be in
password use the system and the system
not in the system
logout() Public void - The user must be in User is out of the
the system. system

Table 8: Schedule class

Schedule
-date: Date
-title: String
-scheduleType:String
-description: String
-reason:String

+create():
+send():
+remove():
+update():
+createAlarm
+startAlarm():
+changeAlarm():
+stopAlarm():
+deleteAlarm():

Table 9: Attributes description for Schedule class

Attribute Type Visibility Invariant

51
 Date Date Private Date <> NULL and should contain start and end date.

Title String Private Title <> NULL. It must have appropriate name not exceeding
15 characters.
ScheduleType String Private ScheduleType <>NULL and must have to select proper type
of account
Description String Private Description<>NULL and must have character 10 to 255

Reason String Private Reason<> NULL and must have character 5 to 25

Table 10: Operation description for Schedule class

Operation Visibility Return Argument Pre-Condition Post Condition

type
create() Public Void title The schedule title The schedule title
and description and description
shouldn’t exist in should exist in the
the database database
send() Public Void - The schedule should The sender must
be created in the get delivered
database message
notification
remove() Public Void Title The schedule should The schedule
Date be created in the shouldn’t be exist
database in the database.
update() Public Void Title The schedule should The schedule
Date be created in the should be updated
database in the database
createAlarm() Public Void - The schedule should The alarm should

52
 be created in the be created in
database and the database
alarm with the title
and date shouldn’t
be exist
startAlarm() Public Void - The alarm should be The alarm should
created in database be start
changeAlarm() Public Void Date The alarm should be The alarm should
created in database be changed in
database
stopAlarm() Public Void Date The alarm should be The should be
start either snoozed or
canceled
deleteAlarm() Public Void Date The alarm should be The alarm
exist in the database shouldn’t be exist
in the database

Table 11: Alarm class

Alarm
-alarmID: Integer
-alarmType: String
-alarmDate: Date
-alarmTitle: String

+create();
+start();
+stop();
+change();
+delete();

Table 12: Attributes description for Alarm class

53
 Attribute Type Visibility Invariant
AlarmID String Private AlarmID <> NULL and it must be provided by the system

AlarmDate Date Private AlarmDate <> NULL It must have appropriate date and time

AlarmType String Private AlarmType <>NULL and must have to select proper type of
alarm available
Title String Private Title<>NULL it must be between 5 to 25 character

Table 13: Operation description for Alarm class

Operation Visibility Return Argument Pre-Condition Post Condition

type
create() Public void - The alarm shouldn’t The alarm should
be exist in the be exist in the
database database
start() Public void AlarmID The alarm should be The alarm should
exist in the database start
stop() Public void - The alarm should be The alarm should
exist in the database be snoozed or
cancled
change() Public void AlarmDate The alarm should be The updated
exist in the database alarm should be
exist in the
database
delete() Public void - The alarm should be The alarm
exist in the database shouldn’t be exist
in the database

54
Table 14: Judge class

Judge
-chilot: String
-assignedCourt: String
-experience: Integer
-levelOfducation:String
-qualification:String

+closeCase():
+updateCase():
+removeCase():
+createSchedule():
+sendSchedule():
+notifySchedule():
+updateSchedule():
+removeSchedule():
+editAccount():
+deactivateAccount():
+recieveNotification():
+login():
+logout():

Table 15: Attributes description for Judge Class

Attribute Type Visibility Invariant

Chilot String Private Chilot <> NULL and must have characters between 5 to 25
long
AssignedCourt String Private AssignedCourt <> NULL selected from the option

Experience Integer Private Experience <>NULL and must have to select proper type of
account
LevelOfEducation String Private LevelOfEducation<>NULL and it will be choosen from the
option provided
Qualification String Private Qualification<>NULL and it will be choosen from the option

55
 provided

Table 16 : Operation description for Judge Class

Operation Visibility Return Argument Pre-Condition Post Condition

type
closeCase() Public void CaseNumber Case with the Case should be
number should be not accessedany
exist in the more from the
database. database.
updateCase() Public void CaseNumber Case with the Case should be
number should be updated and exist
exist in the in the data base
database.
removeCase() Public void CaseNumber Case with the Case shouldn’t be
number should be exist in the data
exist in the base
database.
CreateSchedule() Public void Date The schedule The schedule
Title created by the judge created by the
shouldn’t exist judge should
exist
sendSchedule() Public void Date The schedule Notification will
Title created by the judge be sent to user of
should exist the system
notifySchedule() Public void Date The schedule The users will get
Title created by the judge notified
should exist
updateSchedule() Public void Date The schedule The schedule
created by the judge updated by the

56
 Title should exist judge should
exist
removeSchedule() Public Void Date The schedule The schedule
Title created by the judge created by the
should exist judge shouldn’t
exist
recieveNotification() Public void - The schedule The Judge will
created by the judge receive and see
should exist notification
editAccount() Public Void password The Judge The Judge
information information
shouldn’t exist should exist
deactivateAccount() Public Void Password Both the Judge’s Judge’s
information information
shouldn’t exist should exist
login() Public void Username Judge can’t able to Judge must be in
password use the system and the system
not in the system
logout() Public void - The judge must be Judge is out of the
in the system. system

Table 17: Lawyer/Prosecutor Class

Lawyer/Prosecutor
-experience: Integer
-levelOfEducation:String
-certificate:String
-qualification:String

+openCase():
+updateCase():
+createSchedule():

57
 +sendSchedule():
+notifySchedule():
+updateSchedule():
+removeSchedule():
+editAccount():
+deactivateAccount():
recieveNotification():
+login():
+logout():

Table 18: Attributes description for Lawyer/Prosecutor class

Attribute Type Visibility Invariant

Experience Integer Private Experience <>NULL and must have to select proper type of
account
LevelOfEducation String Private LevelOfEducation<>NULL and it will be choosen from the
option provided
Qualification String Private Qualification<>NULL and it will be choosen from the option
provided
Certificate String Private Certificate <> NULL must be filled with appropriate character

Table 19: Operation description for Lawyer/Prosecutor class

Operation Visibility Return Argument Pre-Condition Post Condition

type
openCase() Public void - Case with the Case with the
number shouldn’t number should be
be exist in the exist in the
database. database.
updateCase() Public void CaseNumber Case with the Case should be
number should be updated and exist
exist in the in the data base
database.

58
CreateSchedule() Public void Date The schedule The schedule
Title created by the created by the
Lawyer shouldn’t Lawyers should
exist exist
sendSchedule() Public void Date The schedule Notification will
Title created by the be sent to user of
Lawyer should the system
exist
notifySchedule() Public void Date The schedule The users will get
Title created by the notified
Lawyer should exist
updateSchedule() Public void Date The schedule The schedule
Title created by the updated by the
Lawyer should exist Lawyer should
exist
removeSchedule() Public Void Date The schedule The schedule
Title created by the created by the
Lawyer should exist Lawyer shouldn’t
exist
recieveNotification() Public void - The schedule The Lawyer will
created by the receive and see
Lawyer should exist notification
editAccount() Public Void password The Lawyer The Lawyer
information information
shouldn’t exist should exist
deactivateAccount() Public Void Password Both the user’s Lawyer’s
information information
shouldn’t exist should exist
login() Public void Username Lawyer can’t able to Lawyer must be
password use the system and in the system
not in the system

59
 logout() Public void - The Lawyer must be Lawyer is out of
in the system. the system

Table 20: Client class

Client
clientType : String

+searchLawyer():
+recieveNotification():
+editAccount():
+deactivateAccount():
+login():
+logout():

Table 21: Attributes description for Client class

Attribute Type Visibility Invariant

ClientType String Private ClientType <> NULL. it can be either Defendant or plaintiff
based on the option provided

Table 22: Operation description for Client class

Operation Visibility Return Argument Pre-Condition Post Condition

type
searchLawyer() Public void Name The user personal The user personal
Phone information information
qualification shouldn’t exist should exist
recieveNotification() Public void - The client should The client should
get account from able to receive
his/her lawyer communication
editAccount() Public void password The client The client
information should information
exist should be updated
60
 in the database
deactivateAccount() Public void Password The client’s client’s
information should information
exist in database shouldn’t exist
database
login() Public void Username Client can’t able to Client must be in
password use the system and the system
not in the system allowed for
him/her
Logout() Public void - The user must be in User is out of the
the system. system allowed
for him/her

Table 23: Admin class

Admin
-experience : Integer
-levelOfEducation : String
+createAccount():
+editAccount():
+activateAccount():
+deactivateAccount():
+dispatchMessage():
+recieveMessage():
+recieveNotification():
+login();
+logout();

Table 24: Attributes description for Admin class

Attribute Type Visibility Invariant

Experience Integer Private Experience <>NULL and must have to select proper type of
account

61
 LevelOfEducation String Private LevelOfEducation<>NULL and it will be choosen from the
option provided

Table 25: Operation description for Adminclass

Operation Visibility Return Argument Pre-Condition Post Condition

type
createAccount() Public Void Person The user personal The user personal
information information
shouldn’t exist should exist
dispatchMessage() Public Void - The users must get The user will able
into the system to send message
and communicate
with other users
recieveMessage() Public Void - The users must get The user’s will be
into the system and able to read the
the message should message.
be sent.
editAccount() Public Void password The user’s The user’s
information information
shouldn’t exist should exist
deactivateAccount() Public Void Password Both the user’s users‘s
information information
shouldn’t exist should exist
recieveNotification() Public void - There should be The admin will
some new receive and see
information notification
login() Public void Username admin can’t able to admin must be in
password use the system and the system
not in the system
logout() Public void - The admin must be admin is out of

62
 in the system. the system

Table 26: Case class

Case
- caseNumber:Integer
+ dateOfCase:Date
+ typeOfCase:String
- titleOfCase: String
- reason:String
-opposeReason: String
- caseKey: Varchar
- lawyerName : String
-plaintiffName : String
-defendentName : String

+open():
+close():
+update():
+confirm():
+remove():
+notify():

Table 27: Attributes description for Case class

Attribute Type Visibility Invariant

caseNumber Integer private CaseNumber <> Not NULL and must contain greater
than 6 digit.
dateOfCase Date Public DateOfCase <> Not NULL must be a date type of
format 2017/01/13
typeOfCase String Public typeOfCase<> Not NULL and it must be between
provided with option and selected.
63
 titleOfCase String Private titleOfCase<> Not NULL.it contains up to 20
characters.

reason String Private Reason<> Not NULL it contains up to 255

characters.

opposeReason String Private OpposeReason Not NULL it contains up to 255

characters.
caseKey String Private CaseKey <> Not NULL it must contains randomly
generated 8 characters. It mus have Capital letter,
lowercase, number, some special character.
lawyerName String Private LawyerName <> Not NULL it contains up to 25
characters.
plaintiffName String Private Plaintiff <> Not NULL it contains up to 25
characters.
defendentName String Private DefendantName<> Not NULL it contains up to 25
characters.

Table 28: Operation description for case class

Operation Visibility Return Argument Pre-Condition Post Condition

type
open() Public void - The case should be The case will be
not created first. opened with new
case key and case
number.
close() Public void caseKey and The case should The case will be
caseNumber opened. closed.
update() Public void caseKey and The case should be The case will be
caseNumber created and must be updated.

64
 open first.
confirm() Public void -

remove() Public void caseKey and The case should be The case will be
caseNumber created and must be removed.
open first.
notify() Public void Person The case should be User will be
deleted or closed. notified of about
Users must have an the case.
account

Table 29: Message class

Message
-name: string
-tiltle: string
-description : string
-date : date

+dispatch():
+recieve():
+notify():

Table 30: Attributes description for Message class

Attribute Type Visibility Invariant

name String Public Name <> Not NULL and must contain first, middle and last
name and shouldn’t contain special characters and integers.
title String Public Title <> Not NULL and must contain short Description and
shouldn’t contain special characters and integers.

65
 description String Public Description <>Not NULL and may contain brief Description
and special characters and integers.
date Date Public Date <> Not NULL must be a date type of format 2017/01/13

Table 31: Operation description for Message class

Operation Visibility Return Argument Pre-Condition Post Condition

type
dispatch() Public void name The message should Text message
phoneNumber be created. will be sent to
the recipient.
receive() Public void name The message should The message
phoneNumber be composed. should be
delivered
notify() Public void name The message should Users will be
phoneNumber be sent. notified.

Table 32: Information

User
-name : String
-date : date
-title : String
-description
-infoType : String
-phoneNumber : Integer

+findLawyer()
+addDocument()

66
 +isInvalidDocument()
+findDocument()
+findConstitution()
+seeCWorkflow()
+visitLatestNews()
+updateInfo()

Table 33: Attributes description for Information class

Attribute Type Visibility Invariant

name String Private Name <> NULL and must contain first, middle and last name
and shouldn’t contain special characters and integers.
date Date Private Date <> NULL must be correct format of date
(DD/MM/YYYY) OR MM, DD YYYY
title String Private Title <>NULL and it must be between 12 to 20 characters

description String Private Description <> NULL and it must be more than 20 characters

infoType String Private InfoType <> NULL and it must be between 12 to 20 characters

phoneNumber Integer Private PhoneNumber <> NULL must be 10 digits and must start by
+251/09

Table 34: Operation description for Information class

67
 findLawyer() Visibility Return Argument Pre-Condition Post Condition
type
findLawyer() Public void . The Lawyers’ User can see
information must be Available
filled first information of
Lawyers
addDocument() Public void The case must Document must
always be be added to the
Information
isInvalidDocument() Public void - There must be a The document
document must be stored
findDocument() Public void - There must be a User will get the
document stores appropriate
document
findConstitution() Public void - There must be a Constitution
constitution information will
information to be be available
added
seeCWorkflow() Public void - Court work flow must User can see the
be added or posted work flow of
first Court
visitLatestNews() Public void - Latest News must be User can see latest
added first News
updateInfo() Public void - There must be User will see
information to be updated
updated information

Table 35: Witness Class

68
 Admin
-date : Date
-time : Date
-reason : String
-placeOfEvent : String
-testimony : String
+addWitness();
+removeWitness();
+updateWitness();

Table 36 : Attributes description for Witness class

Attribute Type Visibility Invariant

date Date Private Date <> NULL and it must be filled with the
appropriate type of date.
time Date Private Time <> NULL must be it must be filled with the
appropriate type of time.
reason String Private Reason<>NULL. It is text

placeOfEvent String Private PlaceOfEvent<>NULL. It is string that contains character

from 1 to 50.

testimony String Private Testimony<>NULL. It is string text.

Table 37: Operation description for Witness class

69
 Operation Visibility Return Argument Pre-Condition Post
type Condition
addWitness() Public void Person The user personal The user
information personal
shouldn’t exist information
should
exist
removeWitness() Public void Name The user The user
Address information information
phone shouldn’t exist should
exist
updateWitness(); Public void Name User’s information Updated
Address should exist User’s
phone information
should
exist

Table 38 : Evidence class

Admin
-evidenceType: BLOB
-submissionDate: Date
-submissionTime: Date
-sourceName: String

+createEvidence();
+updateEvidence();
+deleteEvedince();
+submitEvidence();
+resetEvidence();

Table 39: Attributes description for Evidence class

70
 Attribute Type Visibility Invariant
-evidenceType BLOB Private evidenceType <> NOT NULL Must be greater than or
equal 2 characters
submissionDate Date Private submissionDate <> NOT NULL must be greater than 10
characters
and may have capital letter, number and small characters.
submissionTime Date Private submissionTime <> NOT NULL and must have to select
proper type of time
sourceName String Private sourceName <> NULL and may contain special characters and
must be gerater than 5 characters.

Table 40: Operation description for Evidence class

Operation Visibility Return Argument Pre-Condition Post Condition

type
createEvidence() Public void - The case should be The Evidence will
opened. be added.
updateEvidence() Public void password There should be Evidence should
evidence created. be updated.
deleteEvedince() Public Void password There should be The corresponding
evidence created evidence should
be deleted.
submitEvidence() Public void - User must fill the The evidence will
evidence form be added and
stored.
resetEvidence() Public void - The evidence form The evidence
should exist form will be
reseted.

71
 Chapter 5: CONCLUSION AND RECOMMENDATION

6.1 Conclusion
This project work intends to automate the existing Yeka sub city first instance court system and
to digitize court case management system.
The aim of this document is to specify complete description of the Digital Court Management
System objective and requirement for the reader (audience). The Goal of this project is to
develop a software that can manage the court system and interactions with society to minimize
efforts of time, cost, and Materials. The other objective is to implement a new software program
that significantly improves and streamlines the Court System’s office workloads in Ethiopia,
resulting in time efficiencies for both the staff (Judges, prosecutors and Lawyers) and users (The
Defendant and Plaintiff).

Now a day, court cases are out merging everywhere. A lot of people need to contact their
lawyers regularly or find appropriate lawyers for their cases. The other goal of the project is to
provide a flexible way to the people to fulfill their requirements.
Therefore, intended reader groups for this software requirement specification are customers,
suppliers and users.

This project is web based integrated with an android (mobile) application. The website’s major
functionalities are for the courts while the lawyers and prosecutors will mainly use the android
(mobile) application.

6.2 Recommendation
Create a favorable work condition in the organization more than current condition such as:
internet connection 24/7.
 Build up a good team in organization.
 Arrange proper training for improving performance
 Reduce workload of students and employees by using stress management
 Make the project applicable by finding the customer.

72
 BIBLIOGRAPHY
[1] Ethiopian Law of civil Judgement, “blog-posts”,
http://www.abyssinialaw.com/blog-posts/itesm/1499-executions-of-civil-judgement-and-the-need-to-
reform-the-enforcement-system-in-ethiopia, visited on 16/10/2016.
[2] Ethiopian FSC, “homepage”, http://www.fsc.gov.et/Documents/Index1, visited on 18/10/2016.
[3] Ethiopian Chilot, “module page”, https://chilot.files.wordpress.com/2011/07/module-on-caseflow-
management.pdf , visited on 26/10/2016.
[4] Campus Virtual, “homepage”, https://ssi.campusvirtualsp.org/jamaica/?page_id=327, visited on
1/11/2016.
[5] Tutorials point “UML Home Page” http://www.tutorialspoint.com/uml/index.html visited at
December 28, 2016.
[6] Ethiopian Law of civil Judgement, “blog-posts”,
http://www.abyssinialaw.com/blog-posts/itesm/1499-executions-of-civil-judgement-and-the-need-to-
reform-the-enforcement-system-in-ethiopia, visited on December 28, 2017.
[7] Court Case Management for Ceylinco Insurance PLC done by London Metropolitan University
accessed at January 12, 2017.
[8] Ethiopian FSC, “homepage”, http://www.fsc.gov.et/Documents/Index1, visited on January 15, 2017.
[9] Ethiopian Chilot, “module page”, https://chilot.files.wordpress.com/2011/07/module-on-caseflow-
management.pdf , visited on January 15, 2017.

73
APPENDIX
Use Case Diagrams:

74
 Digital Court Management System

Open case

Update case <<include>>

Detail

Create schedule <<include>>

Update schedule <<include>>

<<include>>
Delete schedule

<<include>>
Send Schedule
<<include>>

Notify schedule
<<include>> <<include>>
Login Register
Add <<include>>
client
Lawyer/
<<include>> Admin
Prosecu
tor Update client
detail
<<include>>

delete client
<<include>>

Message
Communication <<include>>

Call
<<Extend>>
communication

Court flow <<Extend>>

information

<<Extend>>
Lawyer/Prosecutor
information

Constittution
information

Figure 16: Use Case Diagram for Lawyer and Prosecutor

75
 DIgital Court Management System

Notification

<<include>>

communication
<<include>>

Lawyer
Lawyer Information <<Extend>>

<<Extend
Login Registration
<<Extend>>
Court flow
Client Information

<<Extend>>

Constitution
Information Prosecu
tor

Figure 17: Use Case Diagram for Client

Digital Court Management System

Registration

<<Include>>
Update Case Detail

<<Include>>
Delete case
detail
<<Include>>

Message <<Include>>
Communication <<Include>> Login Register

<<Include>> Develop
Admin Call Communication er

<<Include>>

Lawyer/Prosecutor
information
<<Include>>

<<Include>>
Court flow
information

<<Include>>

Constitution
information

delete account

76
 Figure 18: Use Case Diagram for Admin

Digital Court Management System

Create
schedule

<<include>>
Update
schedule
<<include>>

Send
schedule <<include>>

Delete <<include>>
schedule
<<include>>
Login Register
<<include>>
Notify Schedule
Judge Admin

Include
Court flow <<include>>
information

Constittution
<<include>>
information

Lawyer/Prosecutor
information <<include>>

Close case

Figure 19: Use Case Diagram for Judge

77