PAYROLL

SYSTEM

SOFTWARE REQUIREMENT SPECIFICATION:

TABLE OF CONTENTS:
1. INTRODUCTION
Purpose of the document
Scope of the document
Overview
2. GENERAL OVERVIEW
Product Functions
Similar system specifications
User problem specifications
User objectives
General objectives
3. FUNCTIONAL REQUIREMENTS
Description
Criticality
Technical issues
4. NON-FUNCTIONAL REQUIREMENTS
Security
Data encryption
Maximum Login attempts
Password Change
Transaction Record
Automatic user logout
Maintainability
Problem reduction
Automatic backups
Reliability
Availability

1.

System availability
Portability
INTRODUCTION:

Purpose of the document:

In general, purpose of the document is to describe its
purpose and its intended users. It also specifies all possible requirements
according to the user needs.
Scope of the document:
The scope of the document is to describe the developers
of the project of what the customer requires, additional requirements
which may prove existing, what are the requirements that are mandatory.
This also describes about the constraints that where placed upon the
requirements elicitation process such as schedules, cost or the
environment to develop the requirements.
Overview:
The document provides the overview of the final product
as a result of requirements elicitation process. So, the final product of
elicitation process is as follows:
Has the details regarding the employee.
Contains details about deduction, loans and
working hours.
Salary details.

2.

GENERAL OVERVIEW:

Product functions:
This describes the general functionality of the final
product. Here the functionality of the product is supposed to reduce the
pressure of the common end users who uses this software.
Similar system specification:
This describes the relation of this product with any
other product. It specifies if this product is intended to be stand-alone or
used as component of larger product. Here our product is a stand-alone
product.

 User characteristics:
This describes the feature of the user community
including the expected expertise with software system and the application
domain. Here, the user should have the basic knowledge of the payroll
system.
User problem statement:
This describes the essential problem confronted by
the user community.
User objectives:
This describes the set of objectives and requirements for
the system from the users perspective. Regarding the considered project
the user may wish to have a complete detail about the pay-slip.
General objectives:
This list the general constraints based upon the
design team, including speed requirements, industry protocols, hardware
platform and so forth.

3.

FUNCTIONAL REQUIREMENTS:

Functional requirements describe the possible effects of a software

system that is what a system must accomplish. Other kinds of
requirements such as interface, performance or reliability describe how
the system accomplishes the functional requirements.
Short imperative sentence stating highest ranked
functional requirements:
Description:
A full description of the requirement is needed.
Criticality:
Describe the essential to the overall requirement of
the system because, based on the requirements only
decision of the further processing of the project is decided.
Technical issues:
Describe any design or implementation issues
involved in satisfying these requirements.

4.

NON-FUNCTIONAL REQUIREMENTS:
Security:
System login:
For employee to login it requires the valid login
and password before granting further access.
Data encryption:
The payroll system encrypts all information before
writing it into the database.
Maximum login attempts:
This system allows the maximum of three consecutive
attempts.
Transaction recordings:
This system shall keep a record of all failure login
attempts with user login, terminal login and time.
Maintainability:
Problem reduction:
The major problem in the payroll system shall be
either resolve in two hours maintenance window.
Automatic backups:
The payroll system shall perform automatic
backups once per batch.
Reliability:
A simple measure of reliability is the sum of mean
time between failures (MTBF), mean time to failures
(MTTF) and mean time to return (MTTR).
Availability:
System availability:
It is the probability that the program is
operating according to the requirements at any point of
time and it is defined as

Availability=[MTTF /(MTTF+MTTR)]*100%
Portability:
The payroll system is provided to different users
provided they meet the specified requirements.

USE CASE DIAGRAM:

Definition:
A behavioral diagram that shows a set of use cases and actors and
their relationships is called a use case diagram. It address the static use
case view of a system and important in modeling the behavior of a system.
The major concepts involved in use case model are:
Actor: an actor represents anything that interact with the
system.
Use case: a use case is a sequence of action a system
perform that yields a result to the actor.
Relation: it defines the relationship between actor and a
user.
The actors involved in the use case diagram are:

Permanent employee
Contract employee
Trainee
Payroll admin
Project admin
Server
Bank

The use cases involved are:

Login
Employee database
Permanent employee database
Contractor database
Trainee database
Time card database

Salary calculation
Admin database
Payment dispatch
Sty fund dispatch

USE CASE DIAGRAM DESCRIPTION:

Login:
This function ensures that only authorized workers enters the work
place. An authorized worker is one who has account on the system.
Workers include permanent employee, contract employee and trainee.
The workers must give the valid user name and password.

Inputs: user name and password is a input given for the login.
Outputs: the output is successful or unsuccessful login.
Precondition: only authorized users can gain access.
Post condition: should not affect the employee database.
Basic flow: check the payment according to the designation and
working hours.

Employee Database:
This function allows seeing the list of all employees including their
personal details, designation, salary and working hours. They are uniquely
identified by their ssn number

Inputs: personal details of the employee with their ssn number.

Source: the login function is the source use.
Outputs: details of all employees are displayed.
Precondition: The user should be an employee of that work place
Basic flow: Workers must put entry of their daily working hours.

Time Card Database:

This function allows seeing all the employees working time for
every month which is used for calculating the salary for an employee.

Inputs: The daily working hours of the employees

Source: The employees SSN is the prime source to identify the
employee uniquely.
Outputs: The output is the total working hours of a month for a
particular employee.
Basic flow: The total working hours for a month is taken for salary
calculation every month.

Salary Calculation:
This function provides the salary details for each employee and also
takes care of the dispatching of the salary to the concerned.
Inputs: The employee SSN number, basic, deductions, working
hours are given as input.
Source: The admin database provides all the necessary details.
Outputs: The salary for each employee will be dispatched.
Pre condition: The employee must provide the correct SSN
number.
Post condition: The net pay will be calculated.
Basic flow: The salary will be dispatched.

CLASS DIAGRAM:
Definition:
Class diagram is also known as static structure diagram. It is a
collection of static modeling elements such as classes and their
relationships. Class diagrams also show the attributes and operations of
the various classes and the constraints that apply to the way objects are
connected.
The various terminologies used in the class diagram are as follows:
Aggregate Relationship:
The aggregate relationship shows a whole and part of
relationship between two classes. The classes at the client end of the
aggregate relationship are sometimes called the aggregate class.
Association Relationship:
An association provides a pathway for communication. The
types of association are:
Uni-directional
Bi-directional
Dependency:
A dependency is a relationship between two model elements in
which a change to one model element will affect the other model element.
Generalization:

A generalized relationship between classes shows that the

subclass shares the structure or behavior defined in one or more super
class.

Class Notation:
The UML notation for class is a rectangle divided into 3 parts
Class Name
Attributes
Operations
Interface:
An interface is a variation of a class. An interface shares the
same features as a class. In other words, it contains attributes and
methods. The only difference is that the methods are only declared in the
interface and will be implemented by the class implementing the
interface.

STATE CHART DIAGRAM:

Definition:
State diagrams are used to help the developers to understand better
any complex/unusual functionalities or business flows of specialized areas
of the system. In short, state diagrams depict the dynamic behavior of the
entire system, or a sub-system, or even a single object in a system. This is
done with the help of behavioral elements.
Behavioral Elements of state diagram are:
Initial state: This shows the starting point or first activity of the flow
denoted by a solid circle. This is also called as a pseudo state where the
state has no variable describing it further and has no activities.
State: It represents the state of the object at an instant of time. In a state
diagram, there will be multiple of such symbols, one for each state of the
object. It is denoted by rounded rectangle with compartments.
Transition: It is a solid line with arrow head indicating the transition of
object from one state to another. Transitions of state that occur after the
completion of some event or action is called guard condition. This guard
condition or event is depicted by square brackets around the description
of the event or action.
History States: A flow may be such that the object goes into a waiting
state and on occurrence of certain event it goes back to the state it was last
active. This is shown by the history state which is denoted by letter H
enclosed in a circle. This is also a pseudo state.

Event and Action: A trigger that causes a transition to occur is called a

event or action. Every transition need not occur due to the occurrence of
an event or action directly related to the state that transitioned from one
state to another. An event/action is written above the transition that
causes it.
Final State: The end of the state diagram is denoted by bulls eye called
final state. A final state is also a pseudo state.

ACTIVITY DIAGRAM:
Definition:
An activity diagram is typically used for modeling the sequence of
activities in a process. It provides a way to model the workflow of a
business process. An activity diagram is basically a special case of a state
machine where most states are activities.
Using Activity Diagrams:
Activity diagram can model many different types of workflows. For
example, a company could use activity diagrams to model the flow for an
payment dispatch.
Understanding Workflows:
Each activity represents the performance of a group of actions in a
workflow. Once the activity is complete, the flow of control moves to the
next activity or state through a transition. If an outgoing transition is not
clearly triggered by an event, then it is triggered by the completion of the
contained actions inside the activity. A unique activity diagram feature is a
swimlane that defines who or what is responsible for carrying out the
activity or state. It is also possible to place objects on activity diagrams.
The workflow stops when a transition reaches an end state.
Activity diagrams cannot reside within the component view it is mostly
attached in use case or logical view.

SEQUENCE DIAGRAM:
Definition:
A sequence diagram is a graphical view of a scenario that shows
object interaction in a time based sequence as what happens first and
what happens next. Sequence diagram establish the roles of objects and
help provide essential information to determine class responsibilities and
interfaces. This type of diagram is best used during early analysis phases
in design because they are simple and easy to comprehend. Sequence
diagrams are normally associated with use cases.
Sequence diagrams are closely related collaboration diagrams and both
are alternate representations of an interaction. There are two main
differences between sequence and collaboration diagram that is sequence
diagram shows time-based object interaction while collaboration shows
how associate with each other object.
A sequence diagram has two dimensions they are:
Vertical placement representing time
Horizontal placement representing objects
Tools of sequence diagram:
The following tools located on a sequence diagram toolbox enable
you to model sequence diagram:
Object

Message icon
Focus of control
Message to self
Note
Note anchor
Swimlane

COLLABORATION DIAGRAM:
Definition:
Collaboration diagrams and sequence diagrams are alternate
representations of an interaction. A collaboration diagram is an
interaction diagram that shows the order of messages that implement an
operation or a transaction.
Using Collaboration Diagram:
Collaboration diagrams show objects, their links and their messages.
They can also contain simple class instances and class utility instances.
Each collaboration diagram provides a view of interactions or structural
relationships that occur between objects and object-like entities in the
current model.
Creating Collaboration Diagram:
The create collaboration diagram command creates a collaboration
diagram from information contained in the sequence diagram. The Goto
sequence diagram and Goto collaboration diagram commands traverse
between an interactions two representations.
Collaboration diagram contain icons representing objects. You can create
one or more collaboration diagrams to depict interactions for each logical
package in your model. Such collaboration diagrams are themselves
contained by the logical package enclosing the objects they depict. An

object specification enables you to display and modify the properties and
relationships of an object.
The associated diagrams or specifications are automatically updated.
Design show the semantics of mechanism in the logical view and
Analysis indicate the semantics of primary and secondary interactions.
Thus the collaboration diagrams are used as the primary vehicle to
describe interactions that express your decisions about the behavior of the
system.