Software Requirements Specification

for

Academic Payroll System

Version 0.1

Prepared by: Himanshu Kumar, Georgia Kitt & Monish Mohan

21/04/2009

Copyright 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document. This document has been modified for use in courses at AUT, February 2009.

Software Requirements Specification for <Project>

Page ii

Table of Contents
1. Introduction................................................................................................................................1
1.1 Purpose ............................................................................................................................................... 1.2 Intended Audience and Reading Suggestions..................................................................................... 1.3 Project Scope....................................................................................................................................... 1.4 References........................................................................................................................................... 2.1 Product Perspective............................................................................................................................. 2.2 Product Features.................................................................................................................................. 2.3 User Classes and Characteristics........................................................................................................ 2.4 Operating Environment....................................................................................................................... 2.5 Design and Implementation Constraints............................................................................................. 2.6 User Documentation........................................................................................................................... 2.7 Assumptions and Dependencies......................................................................................................... 1 1 2 3 3 4 5 5 5 5 5

2. Overall Description....................................................................................................................3

3. System Features......................................................................................................................... 6
.................................................................................................................................................................. 6 3.1 Modify Payment Method ................................................................................................................... 7

4. External Interface Requirements ......................................................................................... 8 5. Other Nonfunctional Requirements.........................................................................................8 6. Other Requirements.................................................................................................................. 8

6.1 Appendix A: Glossary......................................................................................................................... 8

Revision History
Name Maciaszek, Leszek A., Requirements Analysis and System Design Date 19/04/0 9 Reason For Changes Documentation and System Features Version 3rd Edition

Software Requirements Specification for <Project>

Page 1

1.
1.1

Introduction
Purpose

The scope of the project is computerizing a new Academic Payroll (AP) system for a university. It describes a single subsystem of the AP System for full-time and casual academics to use.

1.2

Intended Audience and Reading Suggestions

The intended audience that the document is intended for is developers to implement the system, project managers who design the system, users such as the full-time and casual employees who use the system and anyone with interest to the system.

1.2.1

Business Requirements
1. Business categorizes employees into Full Time and Casual (Contractual). 2. Personnel Department maintains employees information. 3. The Academic payroll system maintains employees, manages leaves, and sick leaves. 4. Academic Kiosk (Web access) allows employees to maintain their information. 5. Academics are to be paid on Wednesday every fortnight. 6. Full time academics are paid on a flat salary and casual academics are paid on hourly rate. 7. Contracts Management System maintains the contract information. 8. Standard tax rates are deducted from full time academics. 9. Casual academics are given the choice of either to pay or not pay the tax. 10. The academics are either paid by mail (Cheques) or directly deposited into bank account.

Software Requirements Specification for <Project>

Page 2

1.3

Project Scope

The software being developed is an Academic Payroll (AP) System for a university. Its main purpose is to pay salaries to the Full-time and Casual Academics which are currently being employed at the university. Academic Payroll System has also links with other departments. AP System has full access Personnel Department and Contract Management which it has access to all the personal and contract information for all of its employees. The Academic Payroll System enables university to achieve its business goal of payment to Full-time and Casual Academics.

Software Requirements Specification for <Project>

Page 3

1.4

References

Not applicable to assignment.

2.
2.1

Overall Description
Product Perspective

The product being developed is new for the university to achieve its Payroll System to pay salaries to the Full-time and Casual Academics.

Personnel Management

AP System

Full-Time Academic Casual Academic

Contract Management

Software Requirements Specification for <Project>

Page 4

2.2

Product Features
Business processes Maintain Employee Information Manage leave Make payments(fortnight) Add Employee Delete employee Manage annual leave & sick leave days Paid Fortnightly Mail (bank cheque) (postal address) Direct deposit (bank ac.) Automatic (every second wednesday) Hourly rate Request receiving payments View payments details Fortnight payments Total salaries Year to date tax Leave balances Personal information Update (Web Based Access) Flat salary Contract information Stores basic contract information(Hourly rate) Verification (Total Hours) May elect to have no tax deductions(university) Fortnight payments No leave entitlement Notification by email or mail Participants Full time academics Casual academics Accountants

Information Employee Personnel information

Windows-based desktop interface FULL TIME ACADEMICS

Web developers

Casual Contract information

Software Requirements Specification for <Project>

Page 5

2.3

User Classes and Characteristics

User Classes categories end users of the new system in terms of their industry and IT skills, capabilities and characteristics.

Type of users can be Direct (Employees maintaining the AP System) or Indirect (Full-time academics accessing the system through Academic Kiosk). Frequency of use is both applicable to direct and Indirect users. Employees in Personnel Department will be interacting with the AP System more frequently. Subset of product functions allows both direct and indirect users to use same functions with privileges and access. Technical expertise refers to the direct users which will have full access to AP System plus maintaining the AP System for the indirect user. Security or privilege levels are very both important as indirect users will have high security and less privilege in the AP System compared to direct users which will have full access to all the information of the AP System. Educational level or experience is less important to satisfy as it does not affect the AP System or the users in any way.

2.4

Operating Environment

Not applicable to assignment.

2.5

Design and Implementation Constraints

If the server for the web-based access is not running properly, full-time academics would not be able to access the interface for viewing their payment details, leave balances and personal information. If the server is down, the full-time academics would not be able to update their personal details and payment method. Academic Kiosk would not be able to query the system about the full-time academics payment details. Also, making sure that the payment is made securely to the Full-time academics bank account.

2.6

User Documentation

Not applicable to assignment.

2.7

Assumptions and Dependencies

No Assumptions have been made during this project.

Software Requirements Specification for <Project>

Page 6

3.

System Features

Contract Management

Academic Payroll System

Caasual Academics Submit Time Cards

Peronnel Department

Academmic Kiosk

Maintain Personal Information

<<extend>> Verification of Total Hours Against Contract <<extend>> <<extend>> Check Leave Balances

Salary Payment <<extend>> Payment Notification <<extend>> <<extend>>

Full-Time Academics

Modify Payment Method

Payment By Mail(Bank Cheques) E-mail Mail

Payment By Direct Deposit

Tax Deduction

<<include>>

The Use case diagram above gives an overview of the complete Academic Payroll system. The Casual academics submit timecards at the start at which it will be checked by the Contract Department who verify the total hours worked against the hours agreed on the contract. The time cards then will be passed on to the Personal Department, which processes the cards and make salary payments to the academics via the chosen payment method. The tax value can be deducted upon the choice of the academic. In addition, the casual academics have the choice of receiving payment notifications by either mail or email. The full time academics are paid a flat salary and therefore will be paid directly via the Personal Department to the academics with tax being deducted. The Full time academics have the option to view, edit personal details and payment method via the Academic Kiosk.

Software Requirements Specification for <Project>

Page 7

3.1

Modify Payment Method

3.1.1 Description and Priority

A full time academic change its payment method through Academic Kiosk whereas Casual Academic has to notify Personnel Department to change their payment method.

3.1.2 Functional Requirements Use Case Name: Scenario (if applicable): Triggering Event (if applicable): Brief Description: Actors: Related Use Cases: Preconditions: Postconditions:
Modify Payment Method A full time academic wants to change his payment method through Academic Kiosk. A Full time academic wants to change payment method. If a Full Time academic wants to change his/her payment method, they can access the Web-based interface(Academic Kiosk). Full Time Academics, Academic Payroll System

A Full Time Academic needs to exist in the system and have a User ID and Password. Also, Academic Kiosk needs to be in a good working condition. Payment method successfully modified.

Basic Flow: Line Actor Action

1. Full Time Academic wants to change his/her Payment Method. Academic accesses the Web based Interface. User enters his/her User ID and Password.

System Response

2. 3. 4. 5. 6. 7. 8.

User accesses the Payment Method webpage. The academic then locates the modify payment method option. The academic changes his/her Payment Method. Academic logs out of system.

The AP system asks the user to log in using his/her User ID and Password. System verifies the user login details with the existing details in the database. System loads the Home Page upon login by default. System displays the Payment Method webpage.

System updates his/her Payment Method. System logs out user.

Alternate Flow (AF1) If at line 3, this happens: Line Actor Action

3a If user enters invalid login details

System Response
Invalid login message displayed and prompts to re- enter details. It also prompts user to disable Caps Lock. Payment method page displays error message: Page cannot be displayed.

5a

The user refreshes the payment method page.

Software Requirements Specification for <Project>

Page 8

4.

External Interface Requirements

Not applicable to assignment.

5.

Other Nonfunctional Requirements

Not applicable to assignment.

6.
6.1

Other Requirements
Appendix A: Glossary
manages leave, and makes payments.

Personnel Department - The departments responsible for maintaining employees information, Contract The agreement drawn up between the employer and the employee to confirm payment
terms, royalty, respective responsibilities etc

Entitlements An entitlement is a particular type of authorization Contractual Relating to or be part of a binding legal agreement. Academic Kiosk Provides web based access to full-time academics to view their payment details,
leave balances, and personal information. Web-based access - Information and/or an application made available via the World Wide Web. Windows-based desktop - Desktop that runs Windows based operations system. Timecards - Records the dates and hours worked for a particular contract number. Contracts Management System that maintains contract information. Database - A Computer Database is a structured collection of records or data that is stored in a computer system Query A query is the primary means of viewing, changing, and analyzing data. Bank Cheque - A cheque is a negotiable instrument instructing a financial institution to pay a specific amount of a specific currency from a specific demand account held in the maker/depositor's name with that institution. Both the maker and payee may be natural persons or legal entities

Appendix B: Analysis Models

Not applicable to assignment.

Appendix C: Issues List

Not applicable to assignment.