Software Requirements Specification (SRS)
for
Integrated Enterprise
The
document in this file is an annotated outline for specifying software requirements,
adapted from the IEEE Guide to Software Requirements Specifications (Std
830-1993).
Software Requirements Specification
for
Integrated Enterprise
Version
1.0 approved
Edited by
Mehedi Zaman
Date :
(5th February 2015 )
This Page Is Intentionally Left Blank
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions,
Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. The Overall
Description
2.1 Product
Perspective
2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communications Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements
2.2 Product Functions
2.3 User
Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
2.6 Apportioning of Requirements
3. Specific
Requirements 15
3.
Specific Requirements 15
3.1.
Functional Requirements 15
3.2.
Hardware Interfaces 36
3.3.
Software Interfaces 36
3.4.
Communication Interfaces 37
3.5
Performance Requirements 37
3.6
Design Constraints 37
3.7
Software System Attributes 37
Security 37
Maintainability 37
Portability 37
3.8
Logical Database Requirements 37
3.9
Other Requirements 37
1.Introduction
ERP is one of the most widely implemented business software systems in a wide variety of industries and organizations. ERP is the acronym of Enterprise Resource Planning. ERP is just not only a software. ERP definition refers to both; ERP software and business strategies that implement ERP systems.
Our (Integrated Enterprise Resource Planning ) IERP implementation utilizes Human Resource Management System , Payroll System , Finance System and other integrated applications to improve the performance of any organizations for
1) Resource Planning
2) Management Control
3) Operational Control.
Our IERP software consists of multiple component that integrate activities across functional departments - from production planning, parts purchasing, inventory control and product distribution to order tracking. Our IERP software systems include application modules to support common business activities like finance, accounting and human resources. These components interact together to achieve a common goal - streamline and improve organizations' business processes.
1.1 Purpose
Intended Audience :
- Software Developer
- Software Tester
- Software Analyzer
Integrated
Enterprise Resource Planning (IERP) software can be described as a complete
business software solution. It is aimed at the integration of all business
processes and sub-processes into a single unified system. This system is
formulated and implemented in an organization to effectively and efficiently
achieve the business goals of the organization. The
purpose of this is to develop a IERP system which will provide following
benefits to the organization in it is implemented :
1. All
processes and sub-processes are linked and unified into a single system.
2. There
are enhancements in the field of productivity, efficiency and achievement of
business objectives.
3. ERP
tends to considerably reduce the response time by effectively transferring
crucial information.
4. ERP
helps in streamlining the numerous functions performed by the organization as a
whole.
5. It
helps the management to make vital decisions with unparalleled accuracy and
in-depth study.
1.2
Scope
1.2.1.
Following
Software product are need to produced :
1.2.1.1.
Integrated Enterprise
1.2.1.1.1. Manufacturing
System
1.2.1.1.2. Supply
chain management System
1.2.1.1.3. Financials
System
1.2.1.1.4. Projects
System
1.2.1.1.5. Human
resources System
1.2.1.1.6. Customer
relationship management System
1.2.1.1.7. Data
warehouse System
1.2.1.1.8. Access
control System
1.2.1.1.9. Customization System
1.2.2. Ob jectives :
1.2.2.1.
The IERP Software will have following goals :
1.2.2.1.1.
Manufacturing
Engineering,
bills of material, scheduling, capacity, workflow management, quality control,
cost management, manufacturing process, manufacturing projects, manufacturing
flow
1.2.2.1.2.
Supply chain management
Order to
cash, inventory, order entry, purchasing, product configurator, supply chain
planning, supplier scheduling, inspection of goods, claim processing,
commission calculation
1.2.2.1.3.
Financials
General
ledger, cash management, accounts payable, accounts receivable, fixed assets
1.2.2.1.4.
Projects
Costing, billing,
time and expense, activity management
1.2.2.1.5.
Human resources
Human
resources, payroll, training, time and attendance, rostering, benefits
1.2.2.1.6.
Customer relationship management
Sales and
marketing, commissions, service, customer contact and call center support
1.2.2.1.7.
Data warehouse
Data warehouse and various self-service
interfaces for customers, suppliers, and employees
1.2.2.1.8. Access control
User privilege as per authority levels for
process execution
1.2.2.1.9. Customization
To meet the extension, addition, change in
process flow
1.3. Definitions,
Acronyms, and Abbreviations.
1.3.1. IERP : Integrated Enterprise
1.3.2. ERP : Enterprise
1.3.3. SRS : Software Requirement
Specification
1.4 References
For Information Regarding the Enterprise
1.4.1. Related Books
1.4.1.1.
Pankaj Sharma. Enterprise New Delhi
1.4.1.2.
Hanson, J.J. "Successful ERP Implementations Go Far Beyond Software."
San
Diego 5
July 2004 ).
1.4.1.3.
Olinger , Charles. "The Issues Behind ERP Acceptance and
Implementation." APICS: The
Performance Advantage
1.4.1.4.
Millman, Gregory J. "What Did You Get from ERP and What Can You Get?"
Financial Executive (May 2004).
1.4.2. Related
Websites :
1.4.2.1. http://www.developer.com
1.4.2.2. http://www.erpandmore.com
1.4.2.3. http://www.isnare.com
1.4.2.4. http://sysoptima.com
1.4.2.7. http://java.sun.com/reference/docs/
1.4.2.8. http://www.python.org/doc/
1.4.2.9. http://dev.mysql.com/doc/
1.5 Overview
The next
sections will provide the detailed study of the Integrated Enterprise resource Planning (IERP) software.
Section 2 is
intended to be used by the End User/Customers. The intended audience for the
section 2 will be End Users.
Section 3 is
intended to be used by the System Developers / System Analyst . The intended
audience for the section 3 will be person’s involved in the development of the
IERP software.
2.The Overall Description
The IERP
project is replacing the Financial and Human Resources/Pay systems with an
integrated software suite from any organization. The IERP applications offer functionality in many
areas, including Human Resources/Payroll, Financial, Budget and Materials
Management Services. The overall goal of the IERP project is to implement an
administrative software system that improves services to Organization Employees,
provides access to timely and accurate decision-making data, and helps make the
organization more technologically
competitive and efficient.
A system integrating IERP and HR/Pay applications will greatly benefit the organization. By eliminating the need to enter information in multiple systems, these powerful and user-friendly financial administration tools will boost productivity and improve access to information.
The IERP Human Resources system will provide organization a valuable tool, which it currently lacks, for collecting and managing vital employee data. Through various modules, the system can store and manage data on all personnel, from support staff to managers, and even track employee tenure. It can also maintain job descriptions and classifications, job families, benefits, and salary structure.
The project will benefit the organization by improving access to information, integrating with the financial system, decentralizing data entry and reporting, minimizing duplication and, above all, lowering the risks stemming .
2.1 Product
Perspective
The proposed
system shall be developed using client/server architecture and be compatible
with each and every operating system. The front end of the system will be
developed using Java , PHP and backend will be developed using Mysql Server.
 |
|||
 |
|||
2.1.1 System Interfaces
None
2.1.2 Interfaces
The IERP will have following user-friendly
and menu driven interfaces :
2.1.2.1. Login
To allow the entry of only authorized
users through valid login Id and password.
2.1.2.2. Manufacturing
To maintain Engineering, bills of
material, scheduling, capacity, workflow management, quality control, cost
management, manufacturing process,
manufacturing projects, manufacturing flow
2.1.2.3. Supply Chain Management
To maintain Order to cash, inventory,
order entry, purchasing, product configurator, supply chain planning, supplier
scheduling, inspection of goods, claim processing, commission calculation
2.1.2.4. Financials
To maintain General ledger, cash
management, accounts payable, accounts receivable, fixed assets
2.1.2.5. Projects
To maintain Costing, billing, time and
expense, activity management
2.1.2.6. Human Resources
To maintain Human resources, payroll,
training, time and attendance, rostering, benefits
2.1.2.7. Data Warehouse
To maintain Data warehouse and various
self-service interfaces for customers, suppliers, and employees
2.1.2.8. Access Control
To maintain User privilege as per
authority levels for process execution
2.1.2.9. Customization
To maintain the extension, addition,
change in process flow
The software should generate following
viewable and printable reports :
a) Manufacturing
b) Supply chain
management
c) Financials
d) Projects
e) Human
resources
f) Customer
relationship management
g) Data warehouse
h) Access control
i) Customization
2.1.3
Hardware Interfaces
a) Screen
resolution of at least 640 x 480 or above.
b)
Support for
Printer (Dot Matrix, Deskjet, Laserjet)
c)
Computer
systems will be in the networked environment as it is a multi-user system.
2.1.4. Software Interfaces
2.1.4.1.
MySQL Server
Developed by MySQL AB
Initial release May 23, 1995
Stable release 5.1.32
Preview release 6.0.9
Written in C,
C++
OS Cross-platform
Available in English
Type RDBMS
License GNU General Public License
2.1.4.2.Java
2.0
Paradigm Object-oriented,
structured
Appeared in 1995
Designed by Sun
Microsystems
Latest release Java
Standard Edition 6 (1.6.12)
Typing discipline Static,
strong, safe
Major implementations Numerous
OS Cross-platform
License GNU
General Public License
2.1.4.3.Netbeans
Developed by Sun
Microsystems
Latest release 6.5
Written in Java
OS Multi-platform
Available in Multilingual
Type Java
IDE
License CDDL
or GPL2
2.1.4.4.PHP
Usual file extensions .php
Paradigm imperative,
object-oriented
Appeared in 1995
(1995)
Designed by Rasmus
Lerdorf
Developer The
PHP Group
Latest release 5.2.9
Latest unstable release 5.3.0
Beta 1, and 6.0-dev[1]
Typing discipline Dynamic,
weak
Major implementations Roadsend
PHP, Phalanger
Influenced by C,
Perl, Java, C++
Influenced Php4delphi
OS Cross-platform
License PHP
License
2.1.5 Communications Interfaces
None
2.1.6 Memory Constraints
2.1.6.1. At least 512
MB RAM and 500 MB space of hard disk will be required to run the software on
Client Side.
2.6.1.2. At least 3096
MB RAM and 20 GB space of hard disk will be required to run the software on
Server Side.
2.1.7 Operations
None
2.1.8
Site Adaptation Requirements
The terminal
at client site will have to support the hardware and software interfaces
specified in the section 2.1.3 and 2.1.4 respectively.
2.2 Product Functions
Use Case
|
Description
|
Login
|
Login
|
Change password
|
|
Manufacturing System
|
Add , Delete , View , Analyze bills of material
purchased
|
Add , Delete , View , Analyze schedule of the
next purchase of the material
|
|
Add , Delete , View , Analyze Workflow Management
|
|
Add , Delete , View , Analyze quality control
reports
|
|
Add , Delete , View , Analyze cost management
|
|
Supply Chain Management
|
Add , Delete , View , Analyze order to cash
|
Add , Delete , View , Analyze inventory
|
|
Add , Delete , View , Analyze order entry
|
|
Add , Delete , View , Analyze purchasing
|
|
Add , Delete , View , Analyze product
configurator
|
|
Add , Delete , View , Analyze supply chain
planning
|
|
Add , Delete , View , Analyze supplier scheduling
|
|
Add , Delete , View , Analyze inspection of goods
|
|
Add , Delete , View , Analyze commission
calculation
|
|
Financials
|
Add , Delete , View ,
Analyze General Ledger
|
Add , Delete , View ,
Analyze Cash Management
|
|
Add , Delete , View ,
Analyze Accounts Payable
|
|
Add , Delete , View ,
Analyze Accounts Receivable
|
|
Add , Delete , View ,
Analyze Fixed Assets
|
|
Projects
|
Add , Delete , View ,
Analyze Costing
|
Add , Delete , View ,
Analyze Billing
|
|
Add , Delete , View ,
Analyze Time and Expense
|
|
Add , Delete , View ,
Analyze Activity Management
|
|
Human Resources
|
Add , Delete , View ,
Analyze Payroll
|
Add , Delete , View ,
Analyze Training
|
|
Add , Delete , View ,
Analyze Time
|
|
Add , Delete , View ,
Analyze Attendance
|
|
Add , Delete , View ,
Analyze Rostering
|
|
Add , Delete , View ,
Analyze Benefits
|
|
Data Warehouse
|
Self-Service interfaces
for customers ,suppliers and employees
|
2.3 User Characteristics
2.3.1.
Qualification
At least
matriculation and comfortable with English.
2.3.2.
Experience
Should be well
versed/informed about the working of the organization in various domains.
2.3.3.
Technical Experience
Elementary
knowledge of computers
2.4 Constraints
2.4.1.
There will only be one administrator.
2.4.2.
The delete operation is
available only to the administrator. To reduce the complexity of the system, there is
no check on delete operation. Hence, administrator should be very careful
before deletion of any record and he/she will be responsible for data
consistency.
2.5
Assumptions and Dependencies
2.5.1.
The login Id and password must
be created by system administrator and communicated to the concerned user confidentially to avoid
unauthorized access to the system.
2.6 Apportioning of Requirements.
2.6.1. Version
1.0
2.6.1.1.
Financials
System
2.6.1.2.
Human
Resources System
2.6.1.3.
Payroll
System
2.6.2. Version
1.1
2.6.2.1.
Supply
chain management
2.6.3. Version 1.3
2.6.3.1.
Projects
2.6.3.2.
Manufacturing
2.6.3.3.
Customer relationship management
2.6.3.4.
Data warehouse
2.6.3.5.
Access control
2.6.3.6.
Customization
3. Specific Requirements
This section contains the software
requirements in detail along with the various screens to be developed.
3.1. Functional Requirements
3.1.1 Use Case Description
The
following user-interfaces sequence and use case will serve as the building
block of the software
3.1.1.1.
financial System
3.1.1.1.1 Introduction
This
use case describes how a user logs into the financial maintenance system.
3.1.1.1.2 Actors
DR
3.1.1.1.3 Pre Conditions
None
3.1.1.1.4 Post Conditions
If the use case is successful, the actor is
Logged into the system. If not, the system state is unchanged.
3.1.1.1.5 Basic Flow
This use case starts when the actor wishes to
login to the financial maintenance system.
(i)System requests that the actor
enter his/her name and password.
(ii)The actor enters his/her name
& password.
(iii)System validates name &
password, and if finds correct allow the actor to
logs into the system.
3.1.1.1.6 Alternate Flows
3.1.1. 1.6.1 Invalid name & password
If
in the basic flow, the actor enters an invalid name and/or password, the
system displays an error message. The actor can choose to either return
to
the
beginning of the basic flow or cancel the login, at that point, the use case
ends.
3.1.1.1.7 Special Requirements:
None
3.1.1.1.8 Use case Relationships:
None
3.1.1.2. View/Display
3.1.1.2.1 Introduction
This use case
allows the DR to view the result.
3.1.1.2.2 Actors
Administrator/DR
3.1.1.2.3 Pre Conditions
None
3.1.1.2.4 Post Conditions
If use case is
successful, the corresponding information is displayed by the system.
Otherwise, state
is unchanged.
3.1.1.2.5 Basic Flow
Use case begins
when DR/Administrator wish to view the loan amount.
3.1.1.2.6 Alternative Flow
3.1.1.2.6.1 Record not found
Error
message should be displayed.
3.1.1.2.7 Special Requirements
None
3.1.1.2.8 Use Case relationships
None
3.1.1.3. Maintenance of loans
3.1.1.3.1 Introduction
This use case allows the administrator to
maintain Information related to loans. This includes adding, changing and
deleting loan information from the system.
3.1.1.3.2 Actors
Administrator/DR
3.1.1.3.3 Pre-Conditions
The administrator
must be logged on to the system before the use case begins.
3.1.1.3.4 Post-Conditions
If the use case was successful, the loan
information is added, updated, or deleted from the system. Otherwise, the
system state is unchanged.
3.1.1.3.5
Basic Flow
This use case starts
when the Administrator wishes to add, change, and/or delete loan
information from
the system.
(i) The system requests that the Administrator
specify the function he/she would
like to perform (either Add loan to the Account, Update or Delete a loan from
the Account).
(ii)Once the Administrator provides
the requested information, one of the sub-
flows is executed
a)If the Administrator selected “Add a loan to
the Account”, the Add a loan to
the
Account sub
flow is executed.
b)If the Administrator selected
“Update a loan”, the Update a loan sub-flow is executed.
c)If the Administrator selected
“Delete a loan”, the Delete a loan sub-flow is
executed.
3.1.1.3.5.1 Add a loan
1. The system requests that the Administrator
enters the loan information. This includes:
(a) User Name to
which the loan is sanctioned or taken from
(b) User ID-should be
unique for each user account
(c) Password
(d) Role
2. Once the Administrator provides the
requested information, the loan information is added.
3.1.1.3.5.2 Update a loan
1. The system requests that the Administrator
enters the User ID.
2. The Administrator enters the User ID. The
system retrieves and displays the user account information.
3. The Administrator makes the desired changes
to the user account information. This includes any of the information specified
in the Add a loan
Account sub-flow.
4. Once the Administrator updates the necessary
information, the system updates the user account record with the updated
information.
3.1.1.3.5.3 Delete a loan
1. The system requests that the Administrator
enters the User ID.
2. The Administrator enters the User ID. The
system retrieves and displays the user account information.
3. The system prompts the Administrator to
confirm the deletion of the loan from the user account.
4. The Administrator confirms the deletion.
5. The system deletes the loan from user
account record.
3.1.1.3.6 Alternative Flows
3.1.1.3.6.1 User Not Found
If in the Update loan from user account or Delete a loan
from User Account sub-flows, a user account with the specified
User ID does not exist, the system displays an error Message. The Administrator
can then enter a different User ID or cancel the operation, at which point the
use case ends.
3.1.1.3.6.2 Update Cancelled
If in the Update a loan from User Account sub-flow, the Administrator decides not to update the loan from user
account information, the update is cancelled and the Basic Flow is re-started at the beginning.
3.1.1.3.6.3 Delete Cancelled
If in the Delete a loan from User Account sub-flow, the Administrator decides not to delete the loan from user account Information, the
delete is cancelled and the Basic Flow is re-started at the beginning.
3.1.1.3.2
Special Requirements
None
3.1.1.3.2 Use
case relationships
None
3.1.1.4. Assets
3.1.1.4.1 Introduction
This use case allows the administrator to
maintain Information related to assets of an organization .This includes
adding, changing and deleting assets information from the system.
3.1.1.4.2 Actors
Administrator
3.1.1.4.3 Pre-Conditions
The administrator
must be logged on to the system before the use case begins.
3.1.1.4.4 Post-Conditions
If the use case was successful, the asset’s
information Is added, updated, or deleted from the system. Otherwise, the
System state is unchanged.
3.1.1.4.5 Basic Flow
This use case starts when the Administrator
wishes to add or delete assets information from the system.
(i) The system requests that the Administrator
specify the Function he/she would like to perform (either Add or Delete a asset
from the Account)
(ii) Once the Administrator provides the
requested information, One of the sub-flows is executed :
a) If the Administrator selected “Add a asset
to the Account”, the Add a asset to
the Account sub flow is executed.
b) If the Administrator selected “Delete a
asset from the account”, the Delete asset sub-flow is executed.
3.1.1. 4.5.1 Add asset
1. The system requests that the Administrator
enters the asset Information. This includes:
(a) Place where asset
exists
(b) Form of the asset
2. Once the Administrator provides the
requested information, the Asset
information is added.
3.1.1.4.5.2 Delete asset
1. The system requests that the Administrator
enters the place and form of the asset.
2. The Administrator enters the same. The
system retrieves and displays the account information.
3. The system prompts the Administrator to
confirm the deletion of the asset from the account.
4. The Administrator confirms the deletion.
5. The system deletes the asset from account
record.
3.1.1.4.6 Alternative Flows
3.1.1. 4.6.1 Not Found
If in the Delete asset sub-flows,
asset with the specified information does not exist, the system displays an
error Message. The Administrator can then enter a different asset or cancel the
operation, at which point the use case ends.
3.1.1.4.6.2. Delete
Cancelled
If in the Delete asset sub-flow,
the Administrator decides not to delete asset from account Information, the
delete is cancelled and the Basic Flow is re-started at the beginning.
3.1.1.4.7
Special Requirements
None
3.1.1.4.8 Use
case relationships
None
3.1.1.2.
Login Form
This
will be the first form, which will be displayed. It will allow user to access
the different forms based on his/her role.
Various fields available on this form will be
a) Login Id
Alphanumeric of length 11 characters and only digits
from 0 to 9 are allowed. Alphabets, special characters and blank spaces are not
allowed.
b) Password
Alphanumeric of length in the range of 4 to 15
characters. Blank spaces are not allowed. However, special characters are
allowed.
3.1.1.3 Change Password
The change password form facilitates the user to
change the password. Various fields available on this form will be
a)
Login Id
Alphanumeric
of length of 11 characters and only digits from 0 to 9 are allowed. Special
characters and blank spaces are not allowed.
b)
Old Password
Alphanumeric
of length in the range of 4 characters to 15 characters. Blank spaces are not
allowed. However, special characters are allowed.
c)
New Password
Alphanumeric
of length in the range of 4 characters to 15 characters. Blank spaces are not
allowed. However, special characters are allowed.
d)
Confirm Password
Alphanumeric
of length in the range of 4 characters to 15 characters. Blank spaces are not
allowed. However, special characters are allowed. The content of this field
must match with the contents of new password field.
3.1.1.4 Payroll
1. Login
1.1 Introduction
This use case describes how a
user logs into the payroll maintenance system.
1.2 Actors
(i) DEO , Employees
1.3 Pre Conditions
None
1.4 Post Conditions
If the use case is successful, the actor is Logged into the system.
If not, the system state is unchanged.
1.5 Basic Flow
This use case starts when the actor wishes to login to the payroll
maintenance system.
(i) System requests that the actor enter his/her name and password.
(ii) The actor enters his/her name & password.
(iii) System validates name & password, and if finds correct allow
the actor to logs into the system.
1.6 Alternate Flows
1.6.1 Invalid name & password
If in the basic flow, the actor enters an invalid name and/or
password, the system displays an error message. The actor can choose to either
return to the beginning of the basic flow or cancel the login, at that point,
the use case ends.
1.6 Special Requirements:
None
1.7 Use case Relationships:
None
2. View/Display
2.1 Introduction
This use case allows the DR/employee to view the salary
2.2 Actors
Administrator/DR and employee
2.3 Pre Conditions
None
2.4 Post Conditions
If use case is successful, the corresponding information is displayed
by the system. Otherwise, state is unchanged.
2.5 Basic Flow
Use case begins when DR/Administrator wish to view the salary,
wages, incentives, deductions.
2.6 Alternative Flow
5.6.1
Record not found
Error message should be displayed.
2.7 Special Requirements
None
2.8 Use Case relationships
None
3.
Maintenance of salary and wages
3.1 Introduction
This use case allows the administrator to maintain Information
related to salary, wages
from the system.
3.2 Actors
Administrator/DR
3.3 Pre-Conditions
The administrator must be logged on to the system before the use
case begins.
3.4 Post-Conditions
If the use case was successful the salary, wages information is
added, updated, or deleted from the system. Otherwise, the system state is
unchanged.
3.5 Basic Flow
This use case starts when the Administrator wishes to add, change,
and/or delete the information from the system.
(i)
The system requests that the Administrator
specify the function he/she would like to perform (either Add, update,
delete the salary, wages from the Account).
(ii) Once the Administrator provides the requested information, one
of the sub-flows is executed
- If
the Administrator selected “Add”, the Add
salary to the Account sub flow is
executed.
- If
the Administrator selected “Update”, the Update
salary, wages sub-flow is executed.
- If
the Administrator selected “Delete”, the Delete
salary, wages sub-flow is executed.
3.5.1 Add
1. The system requests that the Administrator enters the salary,
wages information. This includes:
(a)
User Name
(b)
User ID-should be unique for each user account
(c)
Password
(d)
Role
3.5. 2. Once the Administrator provides the requested
information, the salary information is added.
3.5.2 Update
1. The system requests that the Administrator enters the User ID.
2. The Administrator enters the User ID. The system retrieves and displays
the user account information.
3. The Administrator makes the desired changes to the user account
information. This includes any of the information specified in the Add sub-flow.
4. Once the Administrator updates the necessary information, the system
updates the user account record with the updated information.
3.5.3 Delete
1. The system requests that the Administrator enters the User ID.
2. The Administrator enters the User ID. The system retrieves and
displays the user account information.
3. The system prompts the Administrator to confirm the deletion of
the salary from the user account.
4. The Administrator confirms the deletion.
5. The system deletes the salary from user account record.
3.6 Alternative Flows
3.6.1 User Not Found
If in the Update salary from user account or Delete salary from User Account sub-flows, a user account with the specified User ID does not exist,
the system displays an error message. The Administrator can then enter a
different User ID or cancel the operation, at which point the use case ends.
3.6.2 Update Cancelled
If in the Update salary from User Account sub-flow, the Administrator decides not to update salary from user
account information, the update is cancelled and the Basic Flow is re-started at
the beginning.
3.6.3 Delete Cancelled
If in the Delete salary from User Account sub-flow, the Administrator decides not to delete the salary from
user account Information, the delete is cancelled and the Basic Flow is re-started at
the beginning.
3.6 Special Requirements
None
3.7 Use case relationships
None
4. Deductions
4.1 Introduction
This use case allows the administrator to maintain Information
related to deduction in the salary from the system.
4.2 Actors
Administrator/DR
4.3 Pre-Conditions
The administrator must be logged on to the system before the use
case begins.
4.4 Post-Conditions
If the use case was successful the deduction can be done. Otherwise, the system state is unchanged.
4.5 Basic Flow
This use case starts when the Administrator wishes to deduct the
salary from the employee account from the system.
(i) The system requests that the Administrator specify the amount
that he/she wishes to deduct according to rules specified within the
organization
(ii) Once the Administrator provides the requested information, deduct
sub-flow is executed
4.5.1 Deduct
1. The system requests that the Administrator enters the User ID.
2. The Administrator enters the User ID. The system retrieves and
displays the user account information.
3. The system prompts the Administrator to confirm the deduction
from the salary from the user account.
4. The Administrator confirms the deletion.
5. The system deducts the salary from user account record.
4.6 Alternative Flows
4.6.1 User Not Found
In case specified user is not found then the error message get printed
“USER NOT FOUND”
4.6.2 Deduction Cancelled
If in the Deduction salary sub-flow, the Administrator decides not to deduct the salary from
user account, the deduction is cancelled and the Basic
Flow is re-started at the beginning.
4.7 Special Requirements
None
4.8 Use case relationships
None
5.
Incentives
5.1 Introduction
This use case allows the administrator to maintain Information
related to incentives
from the system.
5.2 Actors
Administrator/DR
5.3 Pre-Conditions
The administrator must be logged on to the system before the use
case begins.
5.4 Post-Conditions
If the use case was successful the incentives can be added. Otherwise, the system state is unchanged.
5.5 Basic Flow
This use case starts when the Administrator wishes to add
incentives to the employee account
according to his/her performance
(i) The system requests that the Administrator specify the amount
that he/she wishes to add according to rules specified within the organization
(ii) Once the Administrator provides the requested information, add
sub-flow is executed
5.5.1 Add
1. The system requests that the Administrator enters the User ID.
2. The Administrator enters the User ID. The system retrieves and
displays the user account information.
3. The system prompts the Administrator to confirm the addition of
incentives in the salary to the user account.
4. The Administrator confirms the addition.
5. The system adds incentives to
the salary in the user account record.
5.6 Alternative Flows
5.6.1 User Not Found
In case specified user is not found then the error message gets
printed “USER NOT FOUND”
5.6.2 Addition Cancelled
If in the Add sub-flow,
the Administrator decides not to add incentives to the salary in user account,
the addition is cancelled and the Basic
Flow is re-started at the beginning.
5.7 Special Requirements
None
5.8 Use case relationships
None
3.1.1.5 Human
Resource
1.
Login
1.1
Introduction
This
use case describes how a user logs into the human resources maintenance system
1.2
Actors
DR
1.3
Pre Conditions
None
1.4
Post Conditions
If
the use case is successful, the actor is Logged into the system. If not, the
system state is unchanged.
1.5
Basic Flow
This
use case starts when the actor wishes to login to the human resources
maintenance system.
(i)
System requests that the actor enter his/her name and password.
(ii)
The actor enters his/her name & password.
(iii)
System validates name & password, and if finds correct allow the actor to logs
into the system.
1.6
Alternate Flows
1.6.1
Invalid name & password
If
in the basic flow, the actor enters an invalid name and/or password, the system
displays an error message. The actor can choose to either return to the
beginning of the basic flow or cancel the login, at that point, the use case
ends.
1.8 Special
Requirements
None
1.9 Use case
Relationships
None
2.
View/Display
2.1
Introduction
This
use case allows the DR to view the information related to human resources of
the organization
2.2
Actors
Administrator/DR/customer
2.3
Pre Conditions
None
2.4
Post Conditions
If
use case is successful, the corresponding information is displayed by the
system. Otherwise, state is unchanged.
2.5
Basic Flow
Use
case begins when DR/Administrator/customer wish to view the information related
to human resources of the organization.
2.6
Alternative Flow
2.6.1
Record not found
Error
message should be displayed.
2.7
Special Requirements
None
2.8
Use Case relationships
None
3.
Maintenance of Departmental information
3.1
Introduction
This
use case allows the administrator to maintain Information related to human
resources of the organization. This includes adding, changing and deleting the
information related to human resources of the organization from the system .
3.2 Actors
Administrator/DR
3.3 Pre-Conditions
The
administrator must be logged on to the system before the use case begins.
3.4 Post-Conditions
If
the use case was successful, the human resources information is added, updated,
or deleted from the system. Otherwise, the system state is unchanged.
3.5 Basic Flow
This
use case starts when the Administrator wishes to add, change, and/or delete
human resources information from the system.
(i)
The system requests that the Administrator specify the function he/she would
like to perform (either Add, Update or Delete an employee from a particular
department account).
(ii)
Once the Administrator provides the requested information, one of the sub-flows
is executed
I. If the
Administrator selected “Add an employee”, the Add an employee to the Account
sub flow is executed.
II. If the
Administrator selected “Update”, the Update sub-flow is executed.
III. If the
Administrator selected “Delete”, the Delete sub-flow is executed.
3.5.1
Add an employee
1.
The system requests that the Administrator enters the employee information.
This includes:
(a)
Employee name
(b)
Role/designation of the employee
(c)
unique employee-id should be generated on adding the employee
2.
Once the Administrator provides the requested information, the employee is
added to the corresponding department.
3.5.2
Update
1.
The system requests that the Administrator enters the employee ID.
2.
The Administrator enters the employee ID. The system retrieves and displays the
employee account information.
3.
The Administrator makes the desired changes to the employee account
information. This includes any of the information specified in the Add an
employee sub-flow.
4.
Once the Administrator updates the necessary information, the system updates the
employee account record with the updated information.
3.5.3
Delete
1.
The system requests that the Administrator enters the employee ID.
2.
The Administrator enters the employee ID. The system retrieves and displays the
employee departmental information.
3.
The system prompts the Administrator to confirm the deletion of the employee
account.
4.
The Administrator confirms the deletion.
5.
The system deletes the employee from that particular department.
3.6
Alternative Flows
3.6.1
Employee Not Found
If
in the Update or Delete an employee sub-flows, a employee account with the
specified
employee
ID does not exist, the system displays an error message . The Administrator can
then enter a different employee ID or cancel the operation, at which point the
use case ends.
3.6.2
Update Cancelled
If
in the Update sub-flow, the Administrator
decides not to update the department of the employee. The update is cancelled
and the Basic Flow is re-started at the beginning.
3.6.3
Delete Cancelled
If
in the Delete sub-flow, the Administrator decides not to delete an employee,
the delete is cancelled and the Basic Flow is re-started at the beginning.
3.7
Special Requirements
None
3.8
Use case relationships
None
4.
Employee information
4.1
Introduction
This
use case allows the administrator to maintain Information related to an
employee of an organization .This includes mentioning of the designation and
mode of service that is being rendered by the organization of an employee
4.2
Actors
Administrator/DR/employee
4.3
Pre-Conditions
The
administrator must be logged on to the system before the use case begins.
4.4
Post-Conditions
If
the use case was successful, the employee information is mentioned in terms of
his designation and mode of service whether permanent or temporary from the
system. Otherwise, the system state is unchanged.
3.5
Basic Flow
This
use case starts when the Administrator wishes to add, change, and/or delete
employee information from the system.
(i)
The system requests that the Administrator specify the function he/she would
like to perform (either Add, Update or Delete an employee).
(ii)
Once the Administrator provides the requested information, one of the sub-flows
is executed
I. If the
Administrator selected “Add an employee”, the Add an employee to the Account
sub flow is executed.
II. If the
Administrator selected “Update”, the Update sub-flow is executed.
III. If the
Administrator selected “Delete”, the Delete sub-flow is executed.
3.5.1
Add an employee
1.
The system requests that the Administrator enters the employee information.
This includes:
(a)
Employee name
(b)
Role/designation of the employee
(c)
unique employee-id should be generated on adding the employee
(d)
mode of his/her job
2.
Once the Administrator provides the requested information, the employee is
added to the corresponding department.
3.5.2
Update
1.
The system requests that the Administrator enters the employee ID.
2.
The Administrator enters the employee ID. The system retrieves and displays the
employee account information.
3.
The Administrator makes the desired changes to the employee account
information. This includes any of the information specified in the Add an
employee sub-flow.
4.
Once the Administrator updates the necessary information, the system updates
the employee account record with the updated information.
3.5.3
Delete
1.
The system requests that the Administrator enters the employee ID.
2.
The Administrator enters the employee ID. The system retrieves and displays the
employee departmental information.
3.
The system prompts the Administrator to confirm the deletion of the employee
account.
4.
The Administrator confirms the deletion.
5.
The system deletes the employee from that particular department.
4.6
Alternative Flows
4.6.1
Employee Not Found
If
in Delete an employee sub-flows, a employee account with the specified employee
ID does not exist, the system displays an error message . The Administrator can
then enter a different employee ID or cancel the operation, at which point the
use case ends.
4.6.2
Delete Cancelled
If
in the Delete sub-flow, the Administrator decides not to delete an employee,
the delete is cancelled and the Basic Flow is re-started at the beginning.
4.7
Special Requirements
None
4.8
Use case relationships
None
3.2.Hardware
Interfaces
As stated in
Section 2.1.3
3.3. Software Interfaces
As stated in
Section 2.1.4
3.4.Communication Interfaces
None
3.5
Performance Requirements
(a)
Should run on 500 MHz, 512 MB RAM machine.
(b)
Responses should be within 2 seconds.
3.6
Design Constraints
None
3.7
Software System Attributes
Security
The
application will be password protected. Users will have to enter correct login
Id, and password to access the application.
Maintainability
The
application will be designed in a maintainable manner. It will be easy to
incorporate new requirements in the individual modules.
Portability
The
application will be easily portable on any Client System/Platform that has JVM
installed.
3.8
Logical Database Requirements
Cannot
be revealed as the application is a business integration Application in which
security relies mainly on the database and it’s connectivity with the remotely
running application no the client.
3.9
Other Requirements
None
No comments :
Post a Comment