Chapter 3

ANALYSIS OF PROPOSED
SYSTEM
 “
● In this section the project team express the detail
work that are related to description of the current
system, its function, proposed system, functional
and non-functional requirements, security issue etc

2
 3.1 Functional requirement
● The functional requirement is functions or features that the system
must include to satisfy the system need and to be acceptable by the
user. and the some of the requires are
 The system allows generating ID card for Resident.
 The system support to a register resident information.
 The system should allow Record officer to search, insert, update.

3
3.2 non functional requirement
● Non-functional requirement is a requirement that
specifies criteria that can be to judge the operation of the
system rather than specific behaviors
 User interface and human factor
 An interface that is easy to use.
 The form should be user friendly.
 Interaction of users with system should be
through GUI.

4
Non functional . . .
● Security issue The system shall
provide high level of security by
blocking an authorized user to
view secured system page.
Performance consideration
During the time of accessing the system,
the response time will be range. Response
time of the Resident Record Management
System is faster than the existing system.
5
 Error handling

● We use java script validation, normally used to occur at the server, after the client
had entered all the necessary data and then pressed the Submit button. If the data
entered by a client was incorrect or was simply missing, the server would have to
send all the data back to the client and request that the form be resubmit with correct
information.

6
Error handling . . .
● Basic Validation First, the form must be checked make sure all the
mandatory fields are filled in. It would require just a loop through each
field in the form and check for data.
● Data Format Validation Secondly, the data that entered must be checked
for correct form and value. Your code must include appropriate logic to
test correctness of data.
● We also handle the error by using input exception validation i.e. this
validate the input and the display the error message.

7
 Quality issue
● Information in database should be accurate, updated, delete and retrieve.
■ Availability the system is available at any time when user wants to get
service. The system should be available 7*24 hr.
■ Robustness the system should be robust and adapt any kind of change
that occur in the system. RRMS should be able to operate under stress
or tolerate unpredictable or invalid input provided by its users.
■ The system Modification The system should be easily modifiable and
recoverable by system programmer, if some failure is happening
programmer can give modification this modification is depend on
failure.

8
Backup and recovery
● The proposed system should be holding a backup of the data by making
copies of data so that these additional copies may be used to restore the
original after a data loss due server failure. We can use an offline data
base server if current data base server crushes. When any failures occur,
we can fetch data from an offline server

9
 Resource issue
● Server: Minimum hard ware requirements for Apache server are:
■ - CPU: 32 bit or 64 bit Cores: single (single core 3Hz or higher dual
■ - Core 2GHz or higher is recommended.
■ - Display resolution: 1360X768(or higher).
● Client:
■ - Browser
■ - CPU: 32 or 64 bit
■ - RAM: 2GB or higher
● Editor
■ - Notepad++ or notepad
■ Adobe Photoshop (for editing an image)

10
 Documentation

● Internal documentation: Internal documentation is the program source code

when the system is implement. We will add some sample codes there in the
implementation phases.
● User Documentation: User documentation is to help the user of the system as a
reference
● External Documentation: External documentation contains the scenarios: use-
case models the conceptual models (class, CRC, component, and deployment),
and interaction diagrams (activity. Sequence) and user interface documentation

11
 3.3 system model
Use case model :- actors and their model
Use case model . . RMS

Register
prepare Population
clearance
<<Include>> <<Include>>

prepare ID count Population

Chairm
an
Generate
Report
<<Include>>
<<Include>>
Logout

<<Include>> <<Extend>>
<<Include>>

<<Include>>
<<Include>>

<<Include>> Record office

View comment
Include
<<Include>>

<<Include>>
Include
Set appointment <<Include>>

Vital
Registr <<Include>>
ar Login
<<Include>> <<Include>>

<<Extend>> <<Include>> Include

<<Extend>> View Notification
<<Extend>>
Include
Include
Include
Include
Include
<<Include>> <<Include>>
Include
Include
Include
Include
Include
Send Request
Resident
Add Employee <<Include>>

Admini
<<Include>>
strator Give comment

Manage user

<<Include>> <<Include>>
View
appointment
manage
account

<<Extend>>
<<Extend>>
<<Extend>>
Create
Deactivate
Activate
Use case description or
documentation
In this part of the project we described the use cases that are
identified in the use case identification and tabular or table format.
Conceptual class diagram
Class diagram of our project can show the classes and the
relationships among classes that remain constant over the time
Conceptual class diagram
Record office
Vital Registrar

Username
Username
Password
Password
phonenumber
Has Register Phonenumber
Account ID:
Resident House ID
count()
OwnerID
Username Login() Login()
Housenumber
KebleID Password
Keble
Housenumbe ID
Fname Register() Marriage Generate
Lname count() Full_name
Age create()
Type_marriage Certificate
Sex
Birth Job
Job ID:int
child_name marriage_date
Placeof birth Fname:varchar
weight Adress
Date of birth Manage Lname:varchar
Send() Nationality
Natinalites parent_name age:int
Request dateof_birth Prepare()
PrepareDate:date
ID Admin adress view_certificate()
Pourpose of natinaolity Prepare()
Register() Association
Request Uesrname view_certificate()
SendRequest() Email
ViewNews() Password prepare()
Report Divorce
send() AdminID
view() Report_ID Full_name
1 View() Typeof_mairrage
Content
View() job
View() Login() numberof_child
Generate()
adress
Generate() view_divorce()
Comment prepare()
News
Chairman
CommentID * Id card
Content News_ID
content Clearance ID
SentDate Username
postDate Password prepare Fname
owner_ID Lname
Give() Chairman_ID
Fname age
View() phonenumber
post() Lname preparedate
view() perparedate
Prepare()
perpare() Login()
1

Post()
*
Sequence diagram
A diagram shows, for a particular scenario of a use case, the events that external actors
generate their order, and possible inter-system events. A sequence diagram should be for
the main success scenario of the use case, and frequent or complex alternative scenarios.
A system sequence diagram should specify and show the following:
• External actors
• Messages (methods) invoked by these actors
• Return values (if any) associated with previous messages
• Indication of any loops or iteration area
Conceptual diagram for login
Conceptual diagram for create account
Creat account Database
Home page Admin Account
account page <<server>>
<<UI>> <<controler>>
<<UI>>
Admin

1.Display() 2:Login to
admin page
3.Display UI

4:click create
account

5:Display the
form

6:fill the form

7.submit
8:validate

9:try again

10:Reload
11:send

12:Response
Sequence diagram for registration

Register Home page Record Register Register Database

population office <UI> <<controler>> <<server>>
<<UI>>
Record
ofice

1.Display() 2:Login to
R.office

3.Display UI

4:point register click

population link

6:fill the
form
7:submit
8:valida te

9:try again
10:Reload
11:send

12:Re sponse
Sequence diagram for clearance

Clearance
Chairman Chairman Clearance Database
Homepage <<Controler>
<<UI>> <<UI>> <<form>> <<server>>
>

prepare Clearance 1.open()

2.Login to the
page
3.Display

4.point prepare and

clik clearance card
butt on

8.validate

12.Response
Sequence diagram for certificate

generate Home page Vital certfiicate Database

Certificate registrar <<controler>> <<server>>
<UI>
Vital <<UI>>
registra
r

1.Display() 2:Login to pa ge
3.Display UI

4:point pre pare

click Certifica te
link
5:Display the
form

7:submit
8:validate

9:try again

10:Re loa d
11:se nd

12:Response
13:print
Activity diagram
• Activity diagram describes the flow of control in a system. It
consists of activities and links. The flow can be sequential,
concurrent or branched. Activity diagrams are used to visualize the
flow of controls in a system. This is prepared to have an idea of
how the system will work when executed.
Activity diagram for login

Login

Click Login link

display login form Re enter

fill username and

password

Click on login

correct Incorect
Validate

User page
displayed
24
Activity diagram for create account

Dissplay home page

Create accunt

Click create account

Incorect
Fill the criteria

Click the button

Correct validate

Account is sucessfuly
created

25
Activity diagram for register population

Dissplay recored
Register office window
population

point on Register
and click population
link

display the form

Incorect
Fill the form

Click Register
button

Correct
validate

sucessfully registered
26
Activity diagram for prepare birth certificate

Display vital
Prepare birth Registration page
certificate

click birth register

Display birth
certificate form

Invalid
Fill the form

Click save button

Association
Valid
check

Generate Birth
crtificate sucessfuly 27
Activity diagram for post news

Dissplay chairman
Post News window

Click Post News

Incorect
Fill the form

Click Post button

Correct
validate

News posted
sucessfully

28