You are on page 1of 49

Legal Connect (Web Application)

Project Code
<Project code assigned by the Project Office>

Project Advisor
Mam Samreen Razzaq

Project Manager
Mam Humaira Ejaz

Project Team

BSITF17M028 Muhammad Shahid Team Leader


BSITF17M006 Maham Haider Group Member

Submission Date
March 2, 2021
Project Proposal

Project Proposal 4

Abstract 4

Background and Justification 5

Project Methodology 5

Project Scope 6
Software Requirement Specification

1. Introduction 7
1.1 Purpose 7
1.2 Scope 8
1.3 Definitions, Acronyms, and Abbreviations 8
1.4 Overview 10

2. Overall description 11
2.1 Product perspective 11
2.2 Product functions 11
2.3 User characteristics 12
2.4 Constraints 13
2.5 Assumptions and dependencies 13
2.6 Apportioning of Requirements........................................................................................... 14

3. Specific requirements 14
3.1 External interface Requirements 14
3.1.1 User interfaces 14
3.1.2 Hardware interfaces 17
A System having minimum specification: 17
3.1.3 Software interfaces 17
Software interfaces required in this project: 17
3.1.4 Communications interfaces 18
3.2 Functional requirements 18
3.2.1 User Class 1 - The User 18
3.2.2 User Class 2 - Lawyer 22
3.2.3 User Class 3 - Administrator 24
3.3 Performance requirements 29
3.3.1 Prominent search feature 29
3.3.2 Usage of the search feature 30
3.3.3 Response time 30
3.4 Design constraints 30
3.4.1 Hard drive space 30
3.3.2 Application memory usage 31
3.4 Software system attributes 31
3.4.1 Reliability 32
3.4.2 Availability 32
3.4.3 Security 33
3.4.4 Maintainability 35

4. Prioritization and Release Plan 36


4.1 Choice of prioritization method 36

Appendix I: Selection for Cost-Value Approach 36

Appendix II: Prioritization Result of 10 selected Requirements Using Cost-Value Approach 38


Appendix IV: Release Plan 39

Software Design Specification

1. Purpose 43

2. Design Considerations 43
2.1. Assumptions and Dependencies 43
2.2. Potential Risks and Threats 43

3. System Architecture 43
3.1. System Level Architecture 44
3.2. Components/Modules/Sub-System Level Architecture 46

4. Design Strategies 46
5. Detailed System Design 47

References 53

Project Proposal

Abstract

Many people lack the basic knowledge of the safety rights that the government provides them
because of the oppressive environment they grow up in. Other than that, businesses are
expanding in the world and there are many start-ups that are being launched every day. The
people initiating them have a good knowledge of what they are doing, however, they fail
because of lack of the basic knowledge of law and taxes.
Our Online Law Firm is a website that will provide the people with the basic knowledge of the
law and their responsibilities to the government. Its main purpose is to help them connect
online with professional lawyers and attorneys so that they can discuss their problems and find
reliable solutions.
This website will be great step towards solving many unsolved cases by providing people
lawyers with just a click. It helps people to get the credible legal help that they need. The main
aim of the website is helping people take good care of their families and their businesses.

Background and Justification

According to an article published by the Dawn Newspaper in 2018, there are approximately
1,896,886 cases pending with the judiciary. (Malik, 2018) These cases are due to lack of lawyers
and jurisdiction rights. There are many legal problems all over the country that people mostly
ignore due to lack of knowledge and resources. Even if people file their cases, they remain
pending and unsolved for generations due to lack of trustworthy legal help.
According to Transparency International’s 2017 Corruption Perception Index, Pakistan ranks at
117th most corrupt country out of 180 countries. (State, 4 August 2011) A recent survey of the
World Economic Forum highlights that the most problematic factor for doing business in
Pakistan is corruption (World Economic Forum (2017): The Global Competitiveness Report,
2017-18). Another problem is illegal interests that moneylenders charge or people who take
loans and don’t pay them back.
Minority and women rights are also some of the main issues that the public faces. Divorce and
dispute resolution are the issues where the rights of women are not fully protected and they face
unfair treatment due to lack of resources and knowledge.
There are some law firms that have official websites, but such websites only provide superficial
knowledge and no real solution. Our website will connect the many customers with specialized
lawyers according to their problem. We will make sure that all the lawyers signed up with us are
Pakistan Bar Council verified lawyers. With the help of Artificial Intelligence and
recommendation system integrated in our website, the customers will meet the lawyers
recommended by the website according to their problems.

Project Methodology

System Development Life Cycle (SDLC) is the main model that is followed by application and
web development and this is the model we will follow for creating this website. The steps in the
SDLC are Requirements gathering and Analysis, Designing, Coding, Testing and Deployment.
Since the website created will be artificial intelligence, machine learning will take a lot of trial
and error for it to work properly. We will search for the requirements and after proper testing and
implementation, we will develop the website.
1. Requirements Gathering and Analysis: In this phase, we will look at several websites
and find the drawback and string points of each of them. We will discuss the main
purpose of our website. After getting in contact with several people, we will determine
what they want from our website that they couldn’t find in other websites.
2. Design: In this phase, we will finalize the design and functional requirements of the
website by first designing a low fidelity wireframe. After working on the low fidelity
prototype, we will create an evolutionary prototype that will the backbone of our main
website.
3. Coding: in this phase, we will begin the coding of the project. All the documentation will
be converted to source code. The front-end and back-end of the website will be created
side-by-side along with setting up of the database and server.
4. Testing: All through the coding phase, the testing will be done consecutively. After the
project is completed, the website will be tested continuously for any kinds of bugs or
crashes, and fixes would be made accordingly.
5. Deployment: In the final phase, a replica of the original environment will be created with
the clients and the lawyers and they will actively take part in the functioning of the
website. If the website is functioning well according to the customer’s satisfaction, it will
get the approval to go live.

Project Scope
The main aim of the website is connecting clients from all over Pakistan to the lawyers and
attorneys closest to their location. It will aid the clients if they want to choose a lawyer on their
own and will also recommend the most talented lawyers if they are unable to choose on their
own.
Users will be able to login and register into the website. They will enter their case problem and
with the help of the recommendation system, the related list of lawyers and attorneys will appear.
They can select the lawyer according to their choice and requirements such as location. A
scheduled time of meeting between the lawyer and the client will be selected by the admin. Real-
time chat system will help in connecting the both. After the meeting ends, a confirmation click
from both the client and lawyer will complete the transaction, and the number of completed case
will be uploaded on the dashboard.
The lawyers and clients both can view the details of the pending or completed case on their
profile. The lawyer can view his transaction and case history there. The admin will also be able
to check on the lawyer’s and client’s activity. The chat will be controlled and both parties will be
restricted from chatting privately until the admin allows.

Main working Environment


Sublime, Visual Studio
Languages/Frameworks
HTML, CSS3, JavaScript, Python, Laravel, Bootstrap
Database:
MySQL

Other Software Used


Gantter (Online Gantt Chart maker),

High Level Project Plan


In the high level project, the milestones, project deadlines, resources and the time allocated to
each activity will be allocated. This will be explained with the help of a Gantt Chart.
Software Requirements Specification

1. Introduction
This section gives a scope, description and overview of everything included in this SRS document.
Also, the purpose for this document is described and a list of abbreviations and definitions is provided.
1.1 Purpose

This document is meant to delineate the features of “Legal Connect” (LC), so as to serve as a guide to
the developers, and a software validation document for the prospective clients.

It will illustrate the purpose and complete declaration for the development of the system. It will also
explain system constraints, interface and interactions with other external applications. This document
is primarily intended to be proposed to a client for its approval and a reference for developing the
first version of the system for the development team.

1.2 Scope

The main aim of the website is connecting clients from all over Pakistan to the lawyers and attorneys
closest to their location. It will aid the clients if they want to choose a lawyer on their own and will
also recommend the most talented lawyers if they are unable to choose on their own.

Users will be able to login and register into the website. They will enter their case problem and with
the help of the recommendation system, the related list of lawyers and attorneys will appear. They
can select the lawyer according to their choice and requirements such as location, for which we will
use a location API. A scheduled time of meeting between the lawyer and the client will be selected by
the admin. Real-time chat system will help in connecting the both. After the meeting ends, a
confirmation click from both the client and lawyer will complete the transaction, and the number of
completed cases will be uploaded on the dashboard.

The lawyers and clients both can view the details of the pending or completed case on their profile.
The lawyer can view his transaction and case history there. The admin will also be able to check on
the lawyer’s and client’s activity. The chat will be controlled and both parties will be restricted from
chatting privately until the admin allows.

Definitions, Acronyms, and Abbreviations


Term Definition

LC Legal Connect (Name of the website)

Admin/Administrator System administrator who is given specific permission for managing and
controlling the system

User Someone who interacts with the web application

Lawyer Someone who provides his law services

Web-Portal A web application which present special facilities to user,

lawyer, admin

Stakeholder Any person who has interaction with the system who is not a developer.

DESC Description

RAT Rational

DEP Dependency

TAG A unique, persistent identifier contained in a PLanguage statement

GIST A short, simple description of the concept contained in a PLanguage


statement

SCALE The scale of measure used by the requirement contained in a PLanguage


statement

METER The process or device used to establish location on a SCALE contained in a


PLanguage statement
MUST The minimum level required to avoid failure contained in a PLanguage
statement

PLAN The level at which good success can be claimed contained in a


PLanguage statement

WISH A desirable level of achievement that may not be attainable through


available means contained in a PLanguage statement

1.4 Overview

This document includes three chapters and appendices. The first one provides an overview of the
system functionality and system interaction with other systems. This chapter also introduces different
types of stakeholders and their interaction with the system. Further, the chapter also mentions the
system constraints and assumptions about the application.

The second chapter provides the requirements specification in detailed terms and a description of the
different system interfaces. Different specification techniques are used in order to specify the
requirements more precisely for different audiences.

The third chapter deals with the prioritization of the requirements. It includes a motivation for the
chosen prioritization methods and discusses why other alternatives were not chosen.

The Appendices in the end of the document include the all results of the requirement prioritization
and a release plan based on them.
2. Overall description
This section will give an overview of the whole system. The system will be explained in its context to
show how the system interacts with other systems and introduce its basic functionality. It will also
describe what type of stakeholders will use the system and what functionality is available for each
type. At last, the constraints and assumptions for the system will be presented.

2.1 Product perspective

This product is aimed towards a person who doesn’t want to visit the courts as he might not have
time for that or might not be interested in visiting there and dealing with a lot of formalities &
lawyers. Online Law Firm will replace all traditional and outdated means of information and
communications.

This Web app will be a great step towards solving many unsolved cases by providing people lawyers
with just a click. It helps people to get the credible legal help that they need. The main aim of the
website is helping people take good care of their families and their businesses

An integrated database will ensure the storage and the retrieval of the user-related information and
the required lawyer data.

2.2 Product functions

User will take help in two different ways:

Search Query: User will enter his problem/case .The result will be based on the criteria that the user
input. A Content-based AI algorithm will be implemented in the search query like particular keywords
& lawyer’s previous experience regarding that particular type of case.

Hire Lawyer Manually: Users will navigate to the appointment section to hire a particular lawyer to
get legal advice. Users can also search lawyers by location, category & price range.

2.3 User characteristics


There are three types of users that interact with the system: users of the web application, lawyers and
administrators. Each of these three types of users has different use of the system as each of them has
their own requirements.

Admin: Admin is a person whose responsibility is to maintain the database that contains data of all
the lawyers, and users. Admin can add data into the database, can delete it and can update the
records.

Admin has some other responsibilities. They are:

● Managing lawyers, clients


● Controlling the activities of lawyers, meetings and expectations for the job done.
● Generating the reports of the lawyers, and
● Setting commissions

Clients:

Here the Client means the user who wants our service. If a user has signed up and made an account,
he would be given a profile where a record of his recent meetings with different lawyers/attorneys
will be given that will also include payment details and transaction history. After 6 meetings, he will
be given a 10% discount on the next meeting with whoever lawyer he chooses.

Lawyer/Attorney Sign Up:

Lawyer/Attorney sign up will be different from client’s sign up. In addition to his personal info, he will
give the following information.

1. University he graduated from


2. Picture
3. Scanned copy of degree
4. Area of expertise
5. Years of experience
6. Academic or other achievements
7. City of Residence

When a lawyer will be registered, admin will verify his account by examining his degree, Lawyers will
not be able to offer their service until admin will verify them .That information is then stored, and
accessed by the concerned users. Lawyers will have their own dashboard where they will manage
their meetings with clients, transaction history, revenue, profile update, chat system for discussion
with clients.

2.4 Constraints

Internet connection

● A full internet connection is required for this web application

Since the application fetches data from the database over the Internet, it is crucial that there is an
Internet connection for the application to function.

2.5 Assumptions and dependencies

User side assumptions and dependencies

● PC (Personal Computer).
● A web browser with support for cookies.
● Working Internet connection.

2.6 Apportioning of requirements


In the case that the project is delayed, there are some requirements that could be transferred to the
next version of the application. Those requirements are to be developed in the third release, see
Appendix IV.

3. Specific requirements
This section contains all of the functional and quality requirements of the system. It gives a detailed
description of the system and all its features.

3.1 External interface Requirements

This section provides a detailed description of all inputs into and outputs from the system. It also
gives a description of the hardware, software and communication interfaces and provides basic
prototypes of the user interface.

3.1.1 User interfaces

Home Page:

A first-time user should see the home page of a web application. In Fig 3.1, the homepage is visible
where the user will be able to navigate to any option he wants. Users can make appointments, take
legal advice by entering his problem in a text box.
Figure 3.1

Lawyers List:

In fig 3.2, the lawyer list page is visible where the user will select any lawyer he wants. To hire, users
will be able to search lawyers by category, price or location.

Figure 3.2

User & Lawyer Sign up:

To hire any lawyer user would have to register himself first. Lawyer will also register to offer his
services. Registration form is shown in Fig 3.3
Figure 3.3

Sign In Page:

When the user will be registered then he will be able to sign in to his account by providing his account
credentials Email, password. Lawyer will also register through this form but his role will be considered
as both user & lawyer. Sign in form is shown in fig 3.4

Figure 3.4
3.1.2 Hardware interfaces

A System having minimum specification:

● 2 GB RAM
● 40 GB Hard Disk
● Dual Core Processor
● Windows 7 or higher

3.1.3 Software interfaces

Software interfaces required in this project:

● Sublime text editor


● SQL database
● MVC framework
● Xaamp or live server

3.1.4 Communications interfaces

The communication between the clients, lawyers & admin, chat application will be integrated in it. So
that all persons communicate easily.

3.2 Functional requirements

This section includes the requirements that specify all the fundamental actions of the system.

3.2.1 User Class 1 - The User

3.2.1.1 Functional requirement 1.1

ID: FR1

TITLE: Home page – Web application

DESC: When a user opens the website it will go to the homepage where all navigation, drop-down
menus & search bar will appear in the header part. There will be a section of login & register also

RAT: In order for a user to visit a web application.

DEP:

3.2.1.2 Functional requirement 1.2

ID: FR2

TITLE: User registration – Web application


DESC: Users should be able to register through the web application. The user must provide user-
name, password and email address.

RAT: In order for a user to register on the web application.

DEP:

3.2.1.3 Functional Requirement 1.3

ID: FR3

TITLE: User log-in – Web application

DESC: Given that a user has registered, then the user should be able to log in to the web application.
The log-in information will be stored in the database.

RAT: In order for a user to log-in on the web application.

DEP: FR2

3.2.1.4 Functional requirement 1.4

ID: FR4

TITLE: Web application - Search

DESC: The user should be able to search for lawyers according to several search options.

The search options are Category, Location, and Price. There should also be a free- text search option.

RAT: In order for a user to search for a lawyer.

DEP:

3.2.1.5 Functional requirement 1.5

ID: FR5

TITLE: Web application - Search by category type

DESC: A user should be able to select a category type in a given list as input. The query will show the
lawyers of that particular category.

RAT: In order for a user to search by category type.

DEP:

3.2.1.6 Functional requirement 1.6


ID: FR6

TITLE: Web application - Search by price

DESC: A user should be able to select a lawyer by price as input. The query will show the results
according to per hour charges of the lawyer.

RAT: In order for a user to search by price

DEP:

3.2.1.7 Functional requirement 1.7


ID: FR7

TITLE: Web application - Search by specific location

DESC: A user should be able to select a specific location. This query should display lawyers belonging
to that particular area/location.

RAT: In order for a user to search by location.

3.2.1.8 Functional requirement 1.8

ID: FR8

TITLE: Web application - No match found

DESC: If no match is found the user should be informed but kept on the search page in order to get
the possibility to conduct a new search right away.

RAT: In order for users to conduct a new search if no match is found.

DEP:

3.2.1.9 Functional requirement 1.9

ID: FR9

TITLE: Web application - Free-text search

DESC: A user should be able to conduct a search by entering his problem then the system should
automatically refer him to a lawyer, expert in that field, based on previous reviews.

RAT: In order for a user to search through the free-text search.

DEP:

3.2.1.10 Functional requirement 1.10


ID: FR10

TITLE: Web application – Appointment

DESC: User will make an appointment only if he is a registered user.

RAT: In order for a user to make an appointment.

DEP: FR2, FR3

3.2.1.11 Functional requirement 1.11

ID: FR11

TITLE: Web application – User Profile

DESC: User should be able to manage all his information, cases, and transaction history, chat system
for discussion with lawyer, edit his profile etc.

DEP: FR2, FR3

3.2.1.12 Functional requirement 1.12

ID: FR12

TITLE: Web application – Leave Reviews & rate

DESC: Users should be able to give reviews & ratings in all his appointments.

DEP: FR2, FR3

3.2.2 User Class 2 - Lawyer

3.2.2.1 Functional requirement 2.1

ID: FR13

Feature: Create an account

In order to create an account, lawyers should have to register on the web-portal.


Scenario: Required information for registration

When the Lawyer registers on the web-portal by providing his

1. Name
2. Email
3. Password
4. University he graduated from
5. Picture,
6. Scanned copy of degree,
7. Area of expertise,
8. Years of experience
9. Academic or other achievements
10. City of Residence

Then the Lawyer should be able to apply for verification.

Scenario: Confirmed registration

Admin will verify his account & within 24 hours lawyer will get a confirmation email after that he will
be able to offer his services

3.2.2.2 Functional requirement 2.2

ID: FR14

Feature: Lawyer log-in

In order to use the system, Lawyer should be logged in to the web-portal

Scenario: Successful log-in

After successful log-in, the lawyer will be redirected to his profile/Dashboard where he will be able to
respond to all queries of his clients.

DEP: FR13

3.2.2.3 Functional requirement 2.3

ID: FR15

Feature: Lawyer Dashboard

In order to manage information, lawyers should be logged in to the web-portal.

Manage cases
Lawyer should be able to manage all his active cases, case description, track records, download CSV,
pending & completed cases.

Change availability status:

Lawyer should be able change his availability status.

Meetings and Appointments

Lawyers should be able to view records of scheduled meetings and appointments.

Transaction management

Lawyer should be able to view all his transactions, current account balance, and make withdrawal
requests.

Chat Box

Chat box to discuss case details with his clients.

Edit Profile

Lawyer should be able to edit his profile, manage password etc.

DEP: FR14

3.2.3 User Class 3 - Administrator

3.2.3.1 Functional requirement 3.1

ID: FR16

Feature: Administrator Login

To administer the system, the administrator should be logged in to the web-portal.

Scenario: Successful Login

Given the administrator wants to log in, when the administrator logs in with an administrator account
then the administrator should be logged in as an administrator.

3.2.3.2 Functional requirement 3.2


ID: FR17

Feature: Verify Lawyers

In order to allow a lawyer to offer services, the administrator should be able to verify the lawyers.
Scenario: Verify lawyer

Given the administrator is logged in, when the administrator verifies a lawyer, then the lawyer should
be able to offer services and the lawyer should be notified by a confirmation email.

Scenario: Reject Lawyer

Given the administrator is logged in, when the administrator rejects a lawyer, then the lawyer should
not be able to log in & should be notified by a rejection email.

3.2.3.3 Functional requirement 3.3

ID: FR18

Feature: Manage Category

In order to have a list of categories, the administrator should be able to manage the categories of law,
like Civil laws & Criminal laws.

Scenario: Add a new category

Given the administrator is logged in, when the administrator creates a new category type, then the
new category type should be added to the list of law main categories.

Scenario: Editing an existing category type

Given the administrator is logged in, when the administrator edits existing category type, then that
category type will be updated to the list of law main categories.

Scenario: Delete a category type

Given the administrator is logged in, admin will be able to delete/deactivate specific categories.

3.2.3.4 Functional requirement 3.4

ID: FR19

Feature: Manage lawyers

The Administrator should be able to manage the Lawyers.

Scenario: View all registered lawyers

Admin should be able to view all registered lawyers & their registered cases.

Scenario: Edit an existing lawyer’s information


Given the administrator is logged in, when the administrator edits an existing lawyer, then the lawyer
profile information should be updated.

Scenario: Delete/Deactivate a Lawyer

Given the administrator is logged in, admin will be able to delete/deactivate specific lawyers.

Scenario: Secret Login to his profile

Admin will be able to login in to any lawyer profile to view his activities.

Scenario: Illegal Activities

Clients and lawyers are not allowed to share phone no or email addresses with each other in a chat
box before a deal is made otherwise notification will be sent to admin and admin will take action
against it.

3.2.3.6 Functional requirement 3.6

ID: FR20

Feature: Manage Subcategory

The Administrator should be able to manage the subcategory.

Scenario: Add a Subcategory

Given the administrator is logged in, Admin will be able to add to subcategories of main categories.

Scenario: Edit an Subcategory

Given the administrator is logged in, when the administrator edits an existing subcategory, then the
information should be updated.

Scenario: Delete/Deactivate Subcategory

Given the administrator is logged in, Admin will be able to delete/deactivate specific subcategory.

3.2.3.7 Functional requirement 3.7

ID: FR21

Feature: Manage Home Page Sliders

The Administrator should be able to manage home page sliders.

Scenario: Add a slider


Given the administrator is logged in, Admin should be able to add a slider whether it would be image
or video.

Scenario: Edit an slider

Given the administrator is logged in, when the administrator edits an existing slider, then the
information should be updated.

Scenario: Delete/Deactivate slider

Given the administrator is logged in, Admin will be able to delete/deactivate specific sliders.

3.2.3.9 Functional requirement 3.9

ID: FR22

Feature: Updation of policies

Administrator should be able to manage pages like privacy policy, terms & use, About us.

3.2.3.10 Functional requirement 3.10

ID: FR23

Feature: Manage clients

In order to keep track of the users/clients, the administrator should be able to manage the
users/clients.

Scenario: View user’s record

Admin should be able to view all users previous track record/cases pending and completed.

Scenario: Edit an existing user’s information

Given the administrator is logged in, when the administrator edits an existing then the user
information should be updated.

Scenario: Delete/Inactivate an existing user

When the administrator deletes an existing user, then the user should be deleted.

3.2.3.11 Functional requirement 3.11


ID: FR24

Feature: Manage Transactions

Commission (10-15% depending upon level of lawyer) taken by the admin after every client and
lawyer meeting.

Transaction record between client and lawyer.

Discount given to registered lawyer.

Scenario: User Transactions

Admin should be able to view all transaction history of clients, payment methods, time etc.

Scenario: Lawyer’s Transaction

Admin should be able to view the lawyer's transaction history, accept or reject withdrawal requests
from the lawyer.

3.2.3.12 Functional requirement 3.12

ID: FR25

Feature: Meetings and Appointments

Admin should be able to check completed and pending meetings and appointments.

3.3 Performance requirements

The requirements in this section provide a detailed specification of the user interaction with the web
application and measurements placed on the system performance.

3.3.1 Prominent search feature

ID: QR1

TITLE: Prominent search feature

DESC: The search feature should be prominent and easy to find for the user. RAT: In order for a user
to find the search feature easily.

DEP: none

3.3.2 Usage of the search feature


ID: QR2

TITLE: Usage of the search feature

DESC: The different search options should be evident, simple and easy to understand.

RAT: In order for a user to perform a search easily.

DEP: none

3.3.3 Response time

ID: QR3

TAG: Response Time

GIST: The fastness of the search SCALE: The response time of a search

METER: Measurements obtained from 1000 searches during testing. MUST: No more than 2 seconds
100% of the time.

WISH: No more than 1 second 100% of the time.

3.4 Design constraints

This section includes the design constraints on the web application caused by the hardware.

3.4.1 Hard drive space

ID: QR4

TAG: HardDriveSpace

GIST: Hard drive space.

SCALE: The application’s need for hard drive space.

METER: MB.

MUST: No more than 200 MB.

PLAN: No more than 150 MB.

WISH: No more than 100 MB.

MB: DEFINED: Megabyte


3.3.2 Application memory usage

ID: QR5

TAG: ApplicationMemoryUsage

GIST: The amount of Operate System memory occupied by the application. SCALE: MB.

METER: Observations done from the performance log during testing MUST: No more than 200 MB.

PLAN: No more than 160 MB WISH: No more than 100 MB.

Operate System: DEFINED: The Operate System which the application is running on.

MB: DEFINED: Megabyte.

3.4 Software system attributes

The requirements in this section specify the required reliability, availability, security and
maintainability of the software system.

3.4.1 Reliability

ID: QR6

TAG: SystemReliability

GIST: The reliability of the system.

SCALE: The reliability that the system gives the right result on a search.

METER: Measurements obtained from 1000 searches during testing.

MUST: More than 98% of the searches.

PLAN: More than 99% of the searches.

WISH: 100% of the searches.

3.4.2 Availability

ID: QR7

TAG: SystemAvailability

GIST: The availability of the system when it is used.

SCALE: The average system availability (not considering network failing).


METER: Measurements obtained from 1000 hours of usage during testing.

MUST: More than 98% of the time.

PLAN: More than 99% of the time.

WISH: 100% of the time.

ID: QR8

TITLE: Internet Connection

DESC: The application should be connected to the Internet.

RAT: In order for the application to communicate with the database.

DEP: none

3.4.3 Security

ID: QR9

TAG: CommunicationSecurity

GIST: Security of the communication between the system and server.

SCALE: The messages should be encrypted for log-in communications, so others cannot get user-name
and password from those messages.

METER: Attempts to get user-name and password through obtained messages on 1000 log-in sessions
during testing.

MUST: 100% of the Communication Messages in the communication of a log-in session should be
encrypted.

Communication Messages: Defined: Every exchange of information between client and server.

ID: QR10

TAG: LawyerLoginAccountSecurity

GIST: Security of accounts.


SCALE: If a lawyer tries to log in to the web portal with a non-existing account then the lawyer should
not be logged in. The lawyer should be notified about log-in failure.

METER: 1000 attempts to log-in with a non-existing user account during testing.

MUST: 100% of the time.

ID: QR11

TAG: AdminLoginAccountSecurity GIST: Security of accounts.

SCALE: If an admin tries to log in to the web portal with a non-existing account then the admin should
not be logged in. The admin should be notified about log-in failure.

METER: 1000 attempts to log-in with a non-existing user account during testing.

MUST: 100% of the time.

ID: QR12

TAG: LawyerOwnerAccountSecurity

GIST: Security of lawyers accounts.

SCALE: A lawyer and IP address should not be able to log-in for a certain time period after three times
of failed log-in attempts.

METER: 1000 attempts to log-in during the lock period after the user account has been locked
because of failed log-in attempts of three times.

MUST: The locking period should be half an hour, and during that period the log-in function is
disabled.

ID: QR14

TAG:AdminAccountSecurity

GIST: Security of admin accounts.

SCALE: An admin and IP address should not be able to log-in to the web portal for a certain time
period after three times of failed log-in attempts.
METER: 1000 attempts to log-in during the lock period after the user account has been locked
because of failed log-in attempts of three times.

MUST: The locking period should be half an hour, and during that period the log-in function is
disabled.

ID: QR15

TAG: UserCreateAccountSecurity

GIST: The security of creating accounts for users of the system.

SCALE: If a user wants to create an account and the desired username is occupied, the user should be
asked to choose a different user name.

METER: Measurements obtained on 1000 hours of usage during testing. MUST: 100% of the time.

3.4.4 Maintainability

ID: QR16

TITLE: Application extensibility

DESC: The application should be easy to extend. The code should be written in a way that it favors
implementation of new functions.

RAT: In order for future functions to be implemented easily to the application.

DEP: none

ID: QR17

TITLE: Application testability

DESC: Test environments should be built for the application to allow testing of the applications'
different functions.

RAT: In order to test the application.

DEP: none
4. Prioritization and Release Plan
In order to get a view of how to divide the requirements into different releases and what
requirements should be included in which release, a prioritization of the requirements is needed. This
section discusses the choice of prioritization methods and gives a suggestion of how the release plan
for these requirements could look like.

4.1 Choice of prioritization method

When prioritizing the requirements the ten most important ones were picked out first. This was done
with a simple “1 to 10” ranking method, with one being “not important” and ten “very important”.
Based on the elicitation meetings, and the perceived ideas of what was important to the different
stakeholders, a number was set for each requirement. The numbers were then summed up for each
requirement and the ten with the highest score were chosen to be prioritized with the cost value
approach. The results, which are pink-marked, can be seen in Appendix I and as shown, it turned out
to be five functional requirements and five quality requirements. These requirements were then
prioritized according to the cost value approach and the results can be viewed under Appendix II

Appendix I: Selection for Cost-Value Approach


Table 2 – Select of ten most important requirements

Requirement ID Ali Ahmad Asad Farhan Sean Total

FR1 9 10 10 10 9 48

FR2 8 6 7 6 8 35

FR3 6 7 7 9 8 37

FR4 6 5 6 7 6 30

FR5 6 9 5 7 6 33

FR6 6 5 9 9 4 33

FR7 7 8 9 6 7 37

FR8 10 7 8 8 6 39

FR9 6 8 8 9 7 38

FR10 9 9 10 10 10 48
FR11 3 4 6 5 5 23

FR12 3 6 6 7 4 23

FR13 4 6 7 7 7 31

FR14 4 4 6 6 6 26

FR15 9 10 10 9 9 47

FR16 8 9 9 10 10 46

FR17 9 9 9 9 9 45

FR18 6 6 7 4 4 27

FR19 5 4 5 4 7 25

FR20 5 7 5 6 6 29

FR21 5 4 6 5 4 24

FR22 6 8 6 8 7 35

FR23 8 7 5 5 6 31

FR24 5 5 10 5 5 30

FR25 3 5 4 3 4 19

QR1 8 7 7 7 6 35

QR2 6 6 7 5 7 31

QR3 6 8 6 5 7 32

QR4 6 8 6 7 7 45

QR5 6 6 5 4 5 35

QR6 6 6 5 4 7 28

QR7 9 8 9 9 9 44

QR8 9 10 8 9 8 44
QR9 10 9 9 8 7 43

QR10 6 9 7 8 7 37

QR11 9 9 9 8 7 42

QR12 9 9 8 6 8 40

QR13 7 5 7 4 5 28

QR14 8 5 9 5 5 32

QR15 9 9 7 8 9 42

QR16 8 5 9 5 5 32

Appendix II: Prioritization Result of 10 selected Requirements Using


Cost-Value Approach
Table 3 – 10 most important requirements

Requirement ID Title Requirement Type

FR1 Web Application- Home Page Function

FR10 Web Application - Appointment Function

FR15 Web Application - Lawyer dashboard Function

FR16 Admin Log-In Function

FR17 Administrator Verifies Lawyer Function

QR7 System Availability Quality

QR8 Internet Connection Quality

QR9 Communication Security Quality

AR11 Admin Login Account Security Quality

QR15 Application Extensibility Quality


Appendix IV: Release Plan

RE Dependencies Description Motivation Release Duration


FR1 - This has the menu bar, 1 3
Homepage - Web navigation, drop-down
application selection and navigation along
with the user’s profile details.

FR2 - User Registration This is an important step to 1 2


take to make a profile and
really get connected with the
website.

FR3 FR2 User Login - Web After registration, the user logs 1 2
Application in for details and connecting
with the lawyers

FR4 - Search - Web Search for lawyers according to 2 3


Application name, location and price.

FR5 - Search By Search for the Lawyer 2 3


Category - Web according to the categories
Application given

FR6 - Search By Price - Search Lawyers by the Price 3 4


Web Application Range affordable for users.

FR7 - Search By Locate the lawyers according to 2 1


Location - Web which cities they are operating
Application in so that the users can meet
them easily.

FR8 - No Match Found If a user types something and 1 2


- Web no match is found then the
Application user should be informed

FR9 - Free-Text Search User should be able to find 1 2


- Web related information from
Application lawyers according to the
problems he enters.

FR10 FR2, FR3 Appointment - Users can make appointments 2 1


Web Application with a lawyer only if they are
registered.

FR11 FR2, FR3 User Profile - 2 1


Web Application Users can manage their
information, cases, transaction
history, chat system, editing
profile, etc.

FR12 FR2, FR3 Leave Reviews Users should be able to give 1 2


and Rate - Web reviews and ratings to the
Application lawyers he meets with.

FR13 - Create an Lawyers and Customers should 2 1


Account be able to make their account
by getting their personal
information verified.

FR14 - Lawyer Login Lawyers should be able to login 1 2


their accounts and view
notifications and requests on
their dashboard.

FR15 FR14 Lawyer Lawyers can manage cases, set 1 2


Dashboard meetings and appointments,
manage transactions, chata
and edit profiles.

FR16 - Administrator Administrator should be able 1 2


Login to manage all the accounts on
the website

FR17 FR16 Verify Lawyers The Administrator should be 2 1


able to verify lawyers or reject
lawyers.

FR18 FR16 Manage The Administrator should be 1 2


Categories able to add, edit or delete
categories.

FR19 FR16 Manage Lawyers The Administrator should be 1 2


able to view, edit, delete and
login into lawyers’ accounts.

FR20 FR16 Manage The administrator is able to 1 2


Subcategories add, edit and delete
subcategories of main
categories.

FR21 FR16 Manage Home The administrator is able to 1 1


Page Sliders add, delete or edit sliders as
images or videos.

FR22 FR16 Updation of The administrator can manade, 1 1


policies add, edit or delete pages e.g.
privacy Policy, Terms and Use,
About Us, etc.
FR23 FR16 Manage Clients The administrator can manage 1 2
the user’s information, profile,
cases, appointments, meetings
and deactivate his account if he
wants.

FR24 FR16 Manage The administrator is able to 1 2


Transactions manage transactions and
discounts of both the users and
lawyers.

FR25 FR16 Meetings and The administrator can manage 1 1


Appointments and watch over the meetings
and appointments between the
lawyers and clients.

QR1 - Prominent The search bar should be easy 1 2


Search feature to find and work on.

QR2 - Usage of Search The different search options 1 2


Feature should be simple, clear and
easy to understand.

QR3 - Response Time The time taken for the query to 1 2


show results through the
search bar.

QR4 - Hard Drive Space The application’s need for hard 1 2


drive space. Almost 200 MB.

QR5 - Application The amount of operating 1 2


Memory Usage system memory required by
the application. Almost 200MB.

QR6 - System The reliability that the system 1 2


Reliability will give correct information
after a search.

QR7 - System The availability of the system 1 2


Availability when it is used.

QR8 - Internet The website needs to be 1 2


Connection connected to the internet.

QR9 - Communication Security of the communication 1 2


Security between the system and the
server

QR10 - Lawyer Login If a lawyer is not able to login 1 2


Account Security the web portal because of the
non-existence of the account,
he should be notified.
QR11 - Admin Login If an admin is not able to login 1 2
Account the website because of the
non-existence of his account,
he should be notified.

QR12 - Lawyer Owner A lawyer and IP address should 2 1


Account Security not be able to login for some
time after three login failures.

QR13 - Security of An admin and IP address 2 1


Admin should not be able to login for
some time after three login
failures.

QR14 - Security of Users If a user uses an already 1 2


while Creating registered username or email,
Accounts he should be asked to change
it.

QR15 - Application The website should be flexible 1 2


Extendibility and should allow more
features to be added.

QR16 - Application Test environment should be 1 2


Testability provided to test the websites’
functions.

Software Design Specification


1. Purpose
The main purpose of this section is to give a pictorial version of the project. These diagrams will
cover all the key aspects and main modules of the project while considering the abstraction
aspect of the diagram. This documentation is done to facilitate the Project Manager and Faculty
of the Department of CS and IT, University of Sargodha. The design methodology adopted for
this project is System Development Life Cycle (SDLC).
2. Design Considerations
There are many issues and setbacks that need to be addressed before delving into the design
document. This section deals with such issues beforehand and makes sure that appropriate
groundwork is set to create an effective design document.
2.1. Assumptions and Dependencies
The website effectively works on laptops and PCs with an active Internet connection and GUI.
The web browser from where the website will be accessed should have its cookies enabled. The
web browser should also be connected with a server that is supported by Java, GUI and Http.
This will enable all the users (Admin, Client, Lawyers) to access the website with ease.
2.2. Potential Risks and Threats
The website has a potential risk of failure due to several reasons such as a heavy load on server,
connection issues and unexpected surge of traffic. In such cases, the website is most likely to
crash and not respond to the use’s requests in expected time. For this, we can overhaul the
hosting services and make sure that the design of the website is suitable for larger audiences.

3. System Architecture
This section should provide a high-level overview of how the functionality and responsibilities
of the system are partitioned and then assigned to subsystems or components. The main
purpose is to gain a general understanding of how the system is decomposed, and how the
individual parts work together to provide the desired functionality.
3.1. System Level Architecture
The architecture should decompose the system at a top level in a way that provides a
foundation for more detailed design work. The architecture discusses relationships and roles of
system elements (subsystems, components, modules, etc.), but does not provide internal
details.
Package Diagram
Component Diagram
3.2. Components/Modules/Sub-System Level Architecture
The website will extract data from databases that will hold data for all the users involved
(Admin, Lawyers, Clients), whenever any of the users access their accounts. A user interface will
be available which will navigate to different sections of the website. A Content-based AI
algorithm will enable the clients to search lawyers according to their requirements. Other than
this, a chat box will be available for the clients and lawyers to communicate under the
supervision of admin.

4. Design Strategies
This sections describes the design strategies or decisions that impact the overall organization of
the system and its high-level structures. This information should provide the reader with
insights into the key abstractions and mechanisms used in the system architecture
5. Detailed System Design
This section deals with the details design of the proposed system with respect to Unified
Modeling Language to elaborate the working and features of the system i.e. Activity Diagram,
Control Flow Diagram, Sequence Diagram and Use case Diagram etc.
Activity Diagram
Activity Diagram of Admin
Activity Diagram of Lawyer
Activity Diagram of Client
Use Case Diagram
Data Flow Diagram

Sequence Diagram
Class Diagram
References
Malik, A. (2018, January 21). Over 1.8 million cases pending in Pakistan’s courts.
State, U. D. (4 August 2011). Pakistan:Country Reports on Human Rights Practices. Bureau of
Democracy, Human Rights, and Labour , 12-24.
World Economic Forum (2017): The Global Competitiveness Report. (2017-18). Retrieved from
http://www3.weforum.org/docs/GCR2017-

You might also like