Payroll
Payroll
Payroll
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:
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.
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
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.
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.
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:
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.