Leave Application Management System

Software Requirements Specification

Version 1.0
  

Leave
Application
Management
Group Id: F1902694F6
System Supervisor Name: Dr. Nida Anwar
Software requirement
specification

1
 Revision History

Date (dd/mm/yyyy) Version Description Author

12/12/2019 1.0 Leave Application Management System BC120201717
MC180402458

2
 Acronyms & Description

Term Description

VU Virtual University of Pakistan

LAMS Leave Application Management System

SRS Software Requirement Specifications

Admin Administrator

Table of Contents

3
1. Purpose of Document:.........................................................................................................................5
2. Scope of the LAMS(Leave Application Management System)...........................................................6
2.1 Security........................................................................................................................................6
2.2 Efficient Operations.....................................................................................................................6
3. Functional and Non-Functional Requirements....................................................................................7
3.1 Functional Requirements.............................................................................................................7
3.1.1 Business Process.......................................................................................................................7
3.1.2 User (Employee) Access System................................................................................................8
3.1.3 User (Admin) Access System.......................................................................................................8
3.2 Non-Functional Requirements....................................................................................................9
3.2.1 Performance Requirements................................................................................................9
3.2.2 Safety Requirements...........................................................................................................9
3.2.3 Security Requirements.........................................................................................................9
3.2.4 Accessibility requirements.................................................................................................10
3.2.5 System requirements.........................................................................................................10
4. Use Case Diagram..............................................................................................................................11
4.1 Use Case Scenario......................................................................................................................12
5. Methodology.....................................................................................................................................21
5.1 Spiral Model...............................................................................................................................22
5.2 Prototyping Model.....................................................................................................................23
5.3 Waterfall Model.........................................................................................................................24
5.4 Adopted Methodology...................................................................................................................25
5.5 Reasons for adopting Methodology...........................................................................................27
6. Work Plan..............................................................................................................................................27
6.1 Team Structure................................................................................................................................28
6.2 Detailed Project Schedule................................................................................................................29
6.2.1 Gant chart..........................................................................................................................29

4
 1. Purpose of Document:
The purpose of software requirement specification is specify the requirements of the

project. So, the purpose of this document is to give the detailed view of Leave

Application Management System. All the requirements and functionality of LAMS is

briefly described in this SRS document.

From the IEEE standard:

The basic issues of SRS are the following:

a. Functionality. What is the main functionality of the system?

b. External interfaces. How the system interacts?

c. Performance. What are the Non-functional requirements of the system i.e.

security, speed, availability, response time etc. .

d. Attributes. What is the portability, correctness, maintainability, security, etc.

considerations?

e. Designing constraints.

5
 2. Scope of the LAMS (Leave Application Management System)
The people for which this system is designing:

 People don’t have much time to go through the tedious way of submitting
the leave application manually.
 Who want an efficient and easy way to submit their applications for leave.
Everyone in today’s world has a hectic routine, either in academic sector or corporate
sector. People don’t have much time to go through the tedious way of submitting the
leave application manually. Also, it is difficult to track leave application manually. So, it
will be much easier for them, if they apply online leave application from anywhere and to
keep record of their leaves at their own.
 This system mainly includes the following modules.

1. LAMS (Leave Application Management System)

2. Registration of user on interface
3. User can login and can fill the form
4. Approve the registration of user by admin
5. Applying leave module
6. Online attendance

User must register himself on interface, and fill the complete form. Admin will approve
the registration of users.
After successful applying of leave application, it will be available for Admin for
approval.
Admin will review about the leave and will be authorized to ‘Accept’ or ‘Reject’ the
leave.

2.1 Security
This system provides security to the users data. Sms alert or email notification system is also
used for the security purpose. The user can see concerned data only.

2.2 Efficient Operations

This system is very efficient because it has a proper and easy user graphical user interface and
the use can see all the status of his or her attendance. The employee can apply for a leave online
through this system. This is an efficient way to apply for leave because it saves a lot of time and
expanse.

6
 3. Functional and Non-Functional Requirements

Functional requirements provide all main functions of the product, the products framework to

empower developers to finish their work expressed in the client prerequisites. The functional

requirements must be fulfill.

Non-Functional requirements are the requirements provide the functions of the system which are

not main functions but necessary for the systems effectiveness. The attributes which are defined

in the functional requirements are reliability, security, usability, speed, maintainability etc.

3.1 Functional Requirements

3.1.1 Business Process

LAMS perform the following activities:

1. User must register himself on interface, and fill the complete form.
2. Admin keep the record of employee and maintain the daily record of employee
attendance.
3. User must be able to get login.
4. Customer can login through his/her cell phone or computer to login.
5. After successful applying of leave application, it will be available for Admin for
approval.
6. Admin will review about the leave and will be authorized to ‘Accept’ or ‘Reject’
the leave.
7. After the “Approval” or “Rejection” of leaves, SMS Alert/ Email Notification
must be sent to the concerned employee.

7
3.1.2 User (Employee) Access System

 There should be a complete registration process through which any employee registered
on LAMS.
 After this the employee will login to interface.
 Employee can see all the status of leave application.
 Only registered employee can apply for leave online.
 Applying leave module can have the following tabs like:
o Total number of available leaves.
o Reason of leave
o Apply date
o Address
o Leave deduction module
o Total cost to be deducted of leaves.
o Leaves can be either casual, earned, without pay or medical.
 Employee can also mark the attendance online.
 The user must be able to logout to release the interface.

3.1.3 User (Admin) Access System

 Admin will approve the registration of the user.

 After applying for the leave, it will be available to the admin for approval.

 Admin can accept or reject the leave after review.

 All records and history of leaves must be saved into database by admin.

 Admin keep all record of the employees.

 Admin will be able to maintain daily attendance of the employee

8
3.2 Non-Functional Requirements

The non-functional requirements are related to system infrastructure. Specifically it is defined in

six categories i.e. performance, availability, maintainability, portability, security and ecology
(system environment). Different systems have different purposes, standards and effects on
society. These requirements are related to maintaining continuous system service availability,
system performance and system’s future expansion related requirements, operations of system
and service maintenance, migration of the system, safety of the system and securing the
information, and system installation environment.

Other non-functional requirements of LAMS are:

3.2.1 Performance Requirements

The performance of LAMS is very good. If any user performs any related activity the interface

will take less than a second to update this activity.

e.g. if admin approve the request to registration of an employee the acknowledgement message

will receive within a second.

3.2.2 Safety Requirements

 All records and history of leave is saved in the database by admin.

 The backup of all data is updated twice on daily basis
 If the system has any failure accidently the system will recover all data.

3.2.3 Security Requirements

 Only registered user can login and access only data that is related to himself/herself.
 System must check the identity before login.
 The system will not be access by any unauthorized person.

9
  The system is prevented from different security breaches e.g. DOS or DDOS.

3.2.4 Accessibility requirements

 The user can access the system through internet.

3.2.5 System requirements

3.2.5.1 Server

 Processor At least Core i3(1st Gen) (Core i7 2nd Gen or higher recommended)
 Operating System any that is compatible with .Net framework
 RAM At least 1GB RAM
(4GB or max is recommended)
 C# .NET
 ASP with .Net framework 4.5 + SQL server 2014
 The minimum Disk Space available at hosting server is 1000Mb. Recommended is
Unlimited.
 The optimal Band Width requirement of hosting server is 1GHz. Recommended is
Unlimited.

10
 4. Use Case Diagram

Registration

Login

Logout Admin
Employee

Leave Request

History

Attendance

Response

Review

11
4.1 Use Case Scenario
USE CASE SCENARIO

Use Case Title Registration

Actor Admin, Employees

Use Case ID UC-01

Priority 1

Description The employee fills the registration form to get registered on system.

Pre-Conditions User has internet connection.

System in working position

Task Sequence Exceptions

1) User click on registration button.  An exception can occur if any of

2) A form will open. necessary information will not
3) User fills the form. provide by the user.
4) User gives all other necessary information
for registration.  If password of both text boxes
5) System checks that the information is valid will not match.
or not.
6) Valid information is forward to the admin.  If information is not valid.
7) The admin will approve or reject the
request.

Post Conditions The user will register successfully.

The data will save in database.

12
Assumptions If any problem will occur during registration then the system will send an
appropriate message to the user.

Concurrency After registration the system will give option to the new user to open account.
And Response

Modify History
Author MC180402458,BC120201717

13
 USE CASE SCENARIO
Use Case Title Login
Actor Employee
Use Case ID UC-02
Priority 1
Description The employee will login after registration.

Pre-Conditions The employee must be registered.

Task Sequence Exceptions
1) Firstly the registered user clicks on login
button.  If user is not registered then the
2) The user gives the user name and password. system will show the message that
3) If both are true the user will login into the user does not exist.
system.  If the user name or password is
4) The interface will appear on the screen of wrong then the system will show an
user. appropriate message to the user.
Post Conditions The user will login into the system successfully.
Assumptions

Concurrency System shall response quickly on all actions.

And Response
Modify History
Author MC180402458,BC120201717

14
 USE CASE SCENARIO
Use Case Title Logout
Actor Employee
Use Case ID UC-03
Priority 1
Description This use case allows the employee to logout from the system.

Pre-Conditions User must be login into the system.

Task Sequence Exceptions
1) The use case starts when the employee click
on logout button.  The employee may click on the
2) The system will confirm from user about button other than logout button
request.
3) After this the employee will logout from the
system.

Post Conditions The employee will successfully logout from the system.
Assumptions After logout the user will get release from interface.

Concurrency The system shall response quickly.

And Response
Modify History
Author MC180402458,BC120201717

USE CASE SCENARIO

Use Case Title Leave request
Actor Admin, employee

15
Use Case ID UC-04
Priority 1
Description This use case provides facility to employee to request for leave, and admin to
accept or reject the leave.

Pre-Conditions System is in working position.

User must be login.
User must has available leaves.
Task Sequence Exceptions
1. Firstly the employee fills the application
form.  If the employee does not have the
2. Click on request button. available leaves then an
3. The request is forward to the admin. appropriate message send to the
4. The admin accept or reject the request. user.
5. Sms alert will received to the user about
accepting or rejecting the request.

Post Conditions Leave request sends from the user side and receive the alert.
Assumptions

Concurrency The system shall response quickly.

And Response
Modify History
Author MC180402458,BC120201717

USE CASE SCENARIO

Use Case Title History

16
Actor Admin, Employee
Use Case ID UC-05
Priority 1
Description This use case provides facility to the admin to maintain all history about
every user and employee to see all related information.

Pre-Conditions System should be in working position.

Task Sequence Exceptions
1. Firstly any change will occur in the system  If user is not login then he or she
e.g. a request is sent to the admin. cannot see the attendance.
2. The admin generate response.
3. Save all record in database by admin
4. The user get login to the system.
5. User can see his attendance history in his
profile.

Post Conditions User can see his attendance.

All record is saved and show on the interface.
Assumptions

Concurrency The system response quickly.

And Response
Modify History
Author MC180402458,BC120201717

USE CASE SCENARIO

Use Case Title Response

17
Actor Admin, Employee
Use Case ID UC-06
Priority 2
Description In this use case the admin will be able to respond on any request.

Pre-Conditions A request is generated from employee side.

Task Sequence Exceptions
1. Firstly the employee will send request to the  An illegal request is generated from
admin for any purpose e.g. registration user side.
request or leave application request.
2. The request is received by admin.
3. The admin will respond according to request
and rules.

Post Conditions The response is generated successfully.

Assumptions

Concurrency The system response quickly.

And Response
Modify History
Author MC180402458,BC120201717

USE CASE SCENARIO

Use Case Title Review
Actor Admin

18
Use Case ID UC-07
Priority 1
Description In this use case the admin will able to review everything.

Pre-Conditions System should be in working position.

Task Sequence Exceptions
1. If the user sends a request the request is  Nothing to review.
forwarded to the admin.
2. The admin review the request by clicking on
review button.
3. The admin review history to maintain it.

Post Conditions Admin reviews wanted thing.

Assumptions

Concurrency The system shall response quickly.

And Response
Modify History
Author MC180402458,BC120201717

USE CASE SCENARIO

Use Case Title Attendance
Actor Employee
Use Case ID UC-08
Priority 1

19
Description The user can mark attendance online.

Pre-Conditions User is registered.

User is loin into the system.
Task Sequence Exceptions
1. Firstly the employee login into the system.  The user may mark absent instead
2. Then open attendance page. of present.
3. Mark attendance.

Post Conditions The employee mark attendance successfully.

Assumptions

Concurrency The system shall response quickly.

And Response
Modify History
Author MC180402458,BC120201717

20
 1. Methodology

 Spiral Methodology

 Prototyping Methodology

 Waterfall Methodology

Combine Diagram of these methodologies

21
 1.1 Spiral Model

Spiral means iteration. This model includes many iterations. The project is divided into many

subprojects and each subproject is develop in an iteration. This model is very flexible. The

change in initial requirements is possible because the project is completed in different phases.

Every next phase include new functions of the system.

Diagram of Spiral Model

22
 1.2 Prototyping Model

Prototype means sample. In this method or model a sample is given to the customer. This is a

simple design of the system to gather exact requirements. Sometimes customer do not know

exactly what he wanted or needed, this model help to get requirements which the user cannot

explain.

There are 2 types of prototyping model:

 Through away prototype

This is a sample of system in the form of picture. This is only use to show the design of

system to the customer. This type of prototype is not used in development purpose.

 Incremental prototype

This is not in the form of picture. This prototype is develop in simple HTML and CSS

and also use in development of the system.

Diagram of Prototyping

23
 1.3 Waterfall Model

Waterfall model is a sequential model. Every phase is completed on its own turn. If one

phase is not completed next phase cannot started. If any change is required in the system

every phase must perform again properly. It takes more time to complete the project. It is

used in projects which have fixed requirements.

Diagram of Waterfall Model

24
 1.4 Adopted Methodology
I have been studied all models. My system can develop by using every model but the most

suitable model is VU Model. And our university also guides us to must use VU Model. This is

why I choose this model to develop the system.

The VU Model included the following phases:

1. System Requirement Specification (SRS)

2. Design phase.

3. Test phase

4. Development

5. Final Report

6. Presentation and viva

25
Diagram of project Model

SRS

Design phase

Test Phase

Development

Final Report

Presentation & viva

26
 1.5 Reasons for adopting Methodology

I choose VU model to my project development. There are some reasons to choose this

model. The reasons are as follows:

1. The main reason of selecting this model is that the VIRTUAL UNIVERSITY OF

PAKISTAN guide us to must use VU Model for project development.

2. This model is most suitable for this project.

3. VU Model is the combination of Waterfall and Spiral methodologies. One feature of

waterfall methodology is the sequence of steps that we take in our methodology and one

feature of spiral methodology is to go previous steps. This feature also we include in our

methodology.

6. Work Plan
The project development work is planned in very good manners. The way of development of my

project is reliable. I have managed suitable time for each phase. Each phase is completed within

time easily.

Plan consists of following stages.

1. Team structure
2. Detailed project schedule

27
6.1 Team Structure

The project Leave Application Management System consists of two members one Supervisor

and one Developer.

Supervisor

Developer Developer

28
6.2 Detailed Project Schedule

The detailed of project of schedule are as under.

6.2.1 Gant Chart

29