Вы находитесь на странице: 1из 15

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

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.