ER-Flowchart-Use Cases-Use case template

ER - DIAGRAM

Drawing Entity Relationship diagram between the various entities of any Payroll

System.Example relationship between departments and employee, Leaves and

Employee, etc., Drawing the same will help to normalize and improve the Database

Design.

State-transition diagrams

State-transition diagrams (STD) show how the system behaves as a consequence of

some external event. For this purpose the STD represents the state of the system and

the transitions into different states when an external event happens. The structure of

the data items within these models may be described in more detail within the data

dictionary. Similarly, the models will contain a more detailed description of the key

processes taking place

FOR ADMIN:

FOR EMPLOYEE :

DATA DICTIONARY:

The Payroll Data Element Dictionary contains all the elements found in the U-M Data

Warehouse Payroll Tables, ordered alphabetically by element name. Here is a

description of the information that the dictionary provides for each element.

Physical Element Name: Name for the element you can use in SQL queries.

Logical Element Name:Descriptive name of the element.

Format Type:Type of value of the element (for example: character, number, or date).

Data Sets:The names of the data sets that contain the element.

Table Locations:The names of the tables in which the element is located.

Security Code:The level of security imposed on the element. Values are:

Public data: Data with no access restriction that may be released to the general public.

Private/Confidential data: Data available to University employees who need to access

these data to perform their official University duties. Unless otherwise noted, all

institutional data is designated as Private/Confidential.

Sensitive data: Data available only to University employees who have specific

authorization for access. Never release sensitive data in a manner that enables

identifying data element values with a specific person or persons.

Element Definition:Description of the element.

DATA FLOW DIAGRAM :

Level 0 for payroll ststem

Use Case Diagram

Payroll Processing System

Login

Add New Employee

Loan Details

Leave Details

Tax Details

Salary Slip

Bank Details

Salary Details

Update Profile

Change Password

View Earning

View Deduction

View Salary Slip

Use Cases

1 Login

1.1 Brief Description

This use case describes how a user logs into the Payroll Processing System.

1.2 Actors

The following actors interact and participate in this use case:AdministratorEmployee

1.3 Flow of Events 1.3.1 Basic Flow

This use case starts when the actors wishes to login to the Payroll Processing System.

1.The system requests that the actor enter his/her name and password.

2. The actor then enters his/her name and password.

3. The system validates the entered name and password and logs the actor into system

1.3.2 Alternative Flow

1.3.2.1 Invalid Username/Password

If in the Basic Flow, the actor enters an invalid name or password, the system displays an error message. The actor thus have option to either return to the beginning of the Basic Flow or cancel the login, at which the use case ends.

1.4 Special Requirements

None

1.5 Pre-Conditions

All users must have a user account (i.e., User ID, Password and Role) created for them in the system (through the administrator), prior to executing the use cases.

1.6 Post-Conditions

If the use case was successful, the actor is logged into the system. If not, the system state is unchanged.

If the user is Administrator, then he can Add details of a new employee, Edit the employee’s salary details, Loan Details, Leave Details, Tax Details, Salary Slip, Bank Details.

If the user is Employee, then he can Update Profile, Change The Password, View Earning, View Earnings, View Deductions, View Salary Slip.

2 Add New Employee


This uses Allows user to add the details of a new employee and thus register him into the Payroll Processing System.

1.2 Actors

The following actor(s) interact and participate in this use case:

Administrator

1.3Flow of Events

1.3.1 Basic Flow

This use case starts when the actor wishes to add a new employee in the Payroll Processing.

1. The System requests the actor to enter the Name, ID, Designation, and Date of Joining of the employee.

2. The actor enters the Name, ID, Designation, and Date of Joining of the employee.

3. The system verifies the Details entered by the actor and Stores it into system Database.


1.3.2.1 Invalid Name

There can be a situation that user can enter an invalid name like there can be numeric values in the name or any special character, this can be due to typing mistakes. Thus it is necessary to verify that the actor has entered the initials, First name, Last name of the New Employee.

1.3.2.2 Invalid ID

If in the Basic Flow, the actor enters the invalid ID of the New Employee, there may be cases like the ID already exists or the ID is not yet been issued by the company. Thus, the actors needs to make sure the ID is valid, he has two options either to recheck the ID or cancel the entry of adding the details of the New Employee.

1.3.2.3 Invalid Designation/ Date of Joining

In the Basic Flow, if the actor enters the invalid designation or the date of joining, the system asks him to recheck it and enter the right one. As they the basis on which the salary is assigned to the employee.

1.4 Special Requirements

None

Pre-Conditions

None

1.5 Post-Conditions

If the use case was successful, the account for the new employee is created, and the employee will now be able to receive salary every month.

3 Salary Details


This use case describes the salary of the employee and also allows the actor to update the salaries of the employees.

1.2 Actors


Administrator

1.3 Flow of Events

1.3.1 Basic Flow

This use case starts when the actor gives the request to view the Salary Details of the employee(s) or to update the Salary Details of any employee.

The actor can view or update the ID, designation, basic Salary, PF, Daily Allowance, HRA of a Particular employee.


1.3.2.1 Invalid Value is given

The Basic Flow says that the user can either view or update the details of the Salary of the employee, but if the actor entered an invalid value of the detail while updating it, at that point the system displays an error message stating the value(s) are invalid. The actor can choose to either leave the details unchanged or enters the valid new values of the respective detail(s).

1.4 Special Requirement

None

1.5 Pre-Conditions

For the actor to view the details of an employee it is required that these details must be already present into the database and only then a user can view then or edit it.

1.6 Post-Condition

If the use case was successful, there would be two possible states of the system:

1. If the actor has just viewed the details of the employee then there would be no change in the system state.

2. If the actor has done any edition, then the system state will be changed, i.e. the details will be changed in the database.

If the use case is not successful then also the system state will be unchanged.

4 Loan Details


This use case provides particular employee’s loan details.

1.2 Actors


Administrator

1.3 Flow of Events

1.3.1 Basic Flow

This use case starts when the actor gives the request to view the Loan Details of the employee(s) or to update the Loan Details of any employee.

The actor can view or update the ID, Loan Number, EMI, Repaid Amount, Balance amount of a particular employee.


1.3.2.1 Invalid Value is given

If the actors wants to update the loan details and provides some invalid values to the system, then the system generates an error messages stating the invalid details of the given invalid value(s).

If the actor is able to provide the correct details then the respective loan detail is updates else it remains unchanged.


None

1.5 Pre-Conditions

For the actor to view the loan details of an employee it is required that the employee must have taken some type of loan from the company and only then a user can view or edit it.

1.6 Post-Condition

If the use case was successful, there would be two possible states of the system:

3. If the actor has just viewed the loan details of the employee, then there would be no change in the system state.

4. If the actor has done any edition, then the system state will be changed, i.e. the details of the respective loan will be changed in the database.

If the use case is not successful then also the system state will be unchanged.

5 Leave Details


This use case allows the actor to view, edit or enter the details of the leaves taken by the employee.

1.2 Actors


Administrator

1.3 Flow of Events

1.3.1 Basic Flow

This use case starts when the actor wishes to either view or enter the leave details of the employee.

1. The actor can view the Leave Details of the employee so that according the salary of that employee can be adjusted. This must be preferred to be done in the end of the month, while crediting the salaries.

2. During the month when an employee takes a leave, it should immediately added into the database to keep the track of attendance of the employees.


There would be no alternative flow possible.


None

1.5 Pre-Conditions

None

1.6 Post-Conditions

If the employee has taken any leave it must be taken into consideration, as it may affect the employee’s salary. If he has any pending leave then there’ll be no deduction in the employee’s salary else all the leaves other than medical leaves must be deducted from the salary of the employee.

6 Tax Details


This use case allows the Actor to view and update the tax details of an employee.

1.2 Actors


Administrator

1.3 Flow of Events

1.3.1 Basic Flow

This use case starts when the actor requests for the taxation details of an employee.

1. The System asks for the name or ID of a particular employee, so that the details of the respective employee can be fetched from the database.

2. The actor provides either the name or the ID of the employee or both.3. The system then displays the respective employee’s details.4. Now the Actor have an option to edit the details (that’s optional).


The taxable limit may differ in among the employees, i.e. male employee’s may have some and female may have something else, thus the actor must keep in mind that wrong limit must not be provided.

Different savings would be done by different employees. Hence, the actor must carefully enter these details else the system will generate error messages regarding the incorrect values or entries.


None

1.5 Pre-Conditions

For calculating the details of the tax payable by the employee it is required to have the information regarding the investment made by each employee.

1.6 Post-Conditions

If the use case was successful, the tax of each employee is calculated, and thus deducted from the respective employee’s salary.

This case must not be unsuccessful because Tax is compulsory to each employee.

7 Salary Slip


This use case allows the Actor to view and generate the Salary Slip of all employees.

1.2 Actors


Administrator

1.3 Flow of Events

1.3.1 Basic Flow

This use case starts when the Actor gives the request either to view the Salary slip or to generate the Salary Slip.

1. The System gives the option of viewing and creating the Salary Slip.2. If the Actor chooses to view the Salary slip, the name and ID of the

respective employee is asked.3. The Actor enters the name and the ID of the employee.4. The System validates and displays the Salary slip of that particular

employee.5. If the Actor chooses to generate the salary slip of the employee then the ID,

Basic Salary, Designation, Net Pay of the employee is asked and on the basis of all the already stored information the salary slip of that respective employee is generated and Saved into the system.


If Actor entered wrong ID or name of the employee the Salary slip will not be generated.


None

1.5 Pre-Conditions

All the details regarding Taxation, Leaves taken by the employees must be already available to generate the Salary Slip.

1.6 Post-Conditions

The Salary Slip is generated and saved into the database and thus can be viewed by the respective employee.

8 Bank Details


This allows the employee’s Salary to be created in to the particular employee’s Bank account.

1.2 Actors


Administrator

1.3 Flow of Events

1.3.1 Basic Flow

If the Account Number given by the employee is valid and working the Salary then can be credited into that particular account.


If the account number is incorrect the system generates an error and the Salary is not credited in the account of that very employee.


None

1.5 Pre-Conditions

The Account information of the employee is required for depositing the Salary of that employee.

1.6 Post-Conditions

If the use case is successful the Salary is credited into the Account of the respective employee.

9 Update Profile


This use case allows the Actor to update the respective profile.

1.2 Actors


Employee

1.3 Flow of Events

1.3.1 Basic Flow

This use case starts when the Actor gives the request to update the Profile. In this use case the Actor can update ID, Name, Designation, Email-id, Mobile Number, Address, Key Skills, and Qualification.

1. The Actor gives the request to update the profile.2. The System then gives the available information and lets the Actor update

the profile.3. The Actor then provides the new updated information.4. The System then validates and saves the changes made.5. Then again the System shows the updated information.


1.3.2.1 Invalid updated values

There may be a case that the new values provided by the system may be invalid in context and hence it is the job of the System to check for such information.


None

1.5 Pre-Conditions

The profile of the employee must already be available and the Actor can only change the information, that’s already available to the system.

1.6 Post-Conditions

If the use case is successful the request to update the profile given by the particular employee is fulfilled and the information is now updated.

10 Change Password


This use case allows the Actor to Update the passwords of respective Actor.

1.2 Actors


Employee

1.3 Flow of Events

1.3.1 Basic Flow

This use case starts when the Actor gives the request to change the password of the account/profile.

1. The Actor chooses to change the password of the profile(i.e. Account)2. The System then requests for the current password.3. The Actor provides the current password and the System validates it.4. If the Password matches with the existing current password then the system

requests the Actor for new password.5. The Actor provides a new password.6. The System then accepts that new password and changes it to new provided

password.


1.3.2.1 Invalid Current Password

If the Actor is not able to provide current password then the System will not allow the Actor to change the password of the profile or account. And the end of this case the Current password will remain unchanged.


None

1.5 Pre-Conditions

There must be already existing profile, then only the Actor will have the option to change the password of the profile.

1.6 Post-Conditions

This use case is successful when the Actor is able to provide the Current password to the system before changing the password.

11 View Earnings


This use Case allows the Actor to give the request to the System to View his earnings.

1.2 Actors


Employee

1.3 Flow of Events

1.3.1 Basic Flow

1. This use starts when the Actor gives the request to view his Earnings, this is achieved by just choosing the option of View Earning in the System.


None


None

1.5 Pre-Conditions

The earnings should be pre-calculated into the System, then only the Actor can view his earnings.

1.6 Post-Conditions

None

12 View Deductions


This use allows the Actor to view his deduction.

1.2 Actors


Employee

1.3 Flow of Events

1.3.1 Basic Flow

This use starts when the Actor gives the Request to view his Deductions.

1. The actor needs to provide the Specific month and the year to the system 2. Once the Specific month and year is provided the System Fetches

information for that particular month of that particular year and displays his total deductions.


1.3.2.1 Invalid Date

The use is unsuccessful when the user provides the invalid date or the deduction for that very month and year is not available.


None

1.5 Pre-Conditions

The information regarding Deductions should already be available into the system.

1.6 Post-Conditions

This use case is successful if the Actor is able to View his deductions.

13 View Salary Slip


This use allows the Actor to view his Salary Slip.

1.2 Actors


Employee

1.3 Flow of Events

1.3.1 Basic Flow

This use starts when the Actor gives the Request to view his Salary Slip

1. The actor needs to provide the Specific month and the year to the system 2. Once the Specific month and year is provided the System Fetches

information for that particular month of that particular year and displays his Salary Slip


1.3.2.1 Invalid Date

The use is unsuccessful when the user provides the invalid date or the Salary slip for that very month and year is not available.


None

1.5 Pre-Conditions

The Salary slip of that month and year should already be available into the system.

1.6 Post-Conditions

This use case is successful if the Actor is able to View his Salary Slip.

ER-Flowchart-Use Cases-Use case template

Documents

Transcript of ER-Flowchart-Use Cases-Use case template