RAD Document For Fixed Asset Management System

ADDIS ABABA UNIVERSITY SCHOOL OF GRADUATE
STUDIES COLLEGE OF NATURAL SCIENCES

DEPARTMENT OF COMPUTER SCIENCE
Fixed Asset Management System

Requirement Analysis Document (RAD)
Submitted to:- Dida Midekso (Dr)
Prepared by
Name ID.No
Behailu Eshetu………………………………… GSE/1659/10
Kuma Bekele…………………………………….. GSE/6491/09
Taye Mohammed………………………………... GSE/8104/10
Tesfaye Kebede………………………………….. GSE/9183/10
DECEMBER 1, 2018
[COMPANY NAME]
[Company address]
Fixed Asset Management System Requirement Analysis Document
Table of Contents
Table of Contents……………………………………………………………………………………….………………………………………… i
List of Tables……………………………………………………………………………………………………………………………..………... ii
List of Figures……………………………………………………………………………………………………………………………………… iii
List of Acronyms and Abbreviations………………………………………………………….……………………………………... iv
1. Introduction ......................................................................................................................................... 1
1.1. Existing System ........................................................................................................................... 1
1.1.1. Data Flow Diagram of the Existing System ...................................................................... 2
1.1.2. Organization of the Existing System ................................................................................. 5
1.2. Purpose of the Project................................................................................................................. 6
1.3. Objective and Success Criteria of the Project .......................................................................... 7
1.3.1. General Objective ............................................................................................................... 7
1.3.2. Specific Objectives .............................................................................................................. 7
2. Proposed System ................................................................................................................................. 8
2.1. Overview ...................................................................................................................................... 8
2.2. Scope and Limitation of the System .......................................................................................... 9
2.2.1. Scope..................................................................................................................................... 9
2.2.2. Limitations ........................................................................................................................... 9
2.3. Functional Requirement ........................................................................................................... 10
2.4. Non-Functional Requirement .................................................................................................. 11
3. System Model .................................................................................................................................... 12
3.1. Use Case Diagram ..................................................................................................................... 12
3.1.1. Use Case Description ........................................................................................................ 13
3.2. Class Diagram ........................................................................................................................... 22
3.3. Sequence Diagram .................................................................................................................... 23
3.4. Activity Diagram ....................................................................................................................... 29
3.5. User Interface ............................................................................................................................ 36
References .................................................................................................................................................. 43
i
List of Tables:
Table 1: System Use case for "Login" ................................................................................................................... 13

Table 2: System Use case for "Register User"....................................................................................................... 13
Table 3: System Use case for "Manage User" ....................................................................................................... 14
Table 4: System Use case for "Register Asset" ..................................................................................................... 15
Table 5: System Use case for "Register Fixed Asset" ............................................................................................ 15
Table 6: System Use case for "Depreciate Fixed Asset" ........................................................................................ 16
Table 7: System Use case for "Transfer Fixed Asset" ............................................................................................ 16
Table 8: System Use case for "Return Fixed Asset" .............................................................................................. 17
Table 9: System Use case for "Get Pass" .............................................................................................................. 18
Table 10: System Use case for "Maintain Fixed Asset" ......................................................................................... 19
Table 11: System Use case for "Appreciate Fixed Asset" ...................................................................................... 19
Table 12: System Use case for "Dispose Fixed Asset" ........................................................................................... 20
Table 13: System Use case for "Generate Report" ............................................................................................... 21
Table 14: System Use case for "Log Activity" ....................................................................................................... 21
ii
List of Figures:
Figure 1: Data flow diagram for Process of Fixed Asset information registration, delivery, and tracking ............... 2
Figure 2: Data flow diagram for process of Fixed Asset maintenance .................................................................... 3
Figure 3: Data flow diagram for process of Fixed Asset write-off ........................................................................... 3
Figure 4: Data flow diagram for process of Fixed Asset transfer and movement .................................................... 4
Figure 5: Data flow diagram for process of Fixed Asset disposal ............................................................................ 5
Figure 6: Partial organizational structure of ZB ...................................................................................................... 6
Figure 7: Use case diagram for FAMS of ZB S.C .................................................................................................... 12
Figure 8: Class diagram for ZB FAMS .................................................................................................................... 22
Figure 9: Sequence diagram for "Login" ............................................................................................................... 23
Figure 10: Sequence diagram for "User Registration" .......................................................................................... 24
Figure 11: Sequence diagram for "Fixed Asset Information Registration" ............................................................ 25
Figure 12: Sequence diagram for "Fixed Asset Registration”................................................................................ 25
Figure 13: Sequence diagram for "Fixed Asset Transfer" ...................................................................................... 26
Figure 14: Sequence diagram for "Fixed Asset Maintenance" .............................................................................. 26
Figure 15: Sequence diagram for "Fixed Asset Return" ........................................................................................ 27
Figure 16: Sequence diagram for "Fixed Asset Disposal" ..................................................................................... 28
Figure 17: Activity diagram for "Login" ................................................................................................................ 29
Figure 18: Activity diagram for "User Registration" ............................................................................................. 30
Figure 19: Activity diagram for "Fixed Asset Information Registration" ............................................................... 31
Figure 20: Activity diagram for "Fixed Asset Registration" ................................................................................... 32
Figure 21: Activity diagram for "Fixed Asset Tracking" ......................................................................................... 33
Figure 22: Activity diagram for "Fixed Asset Maintenance" ................................................................................. 34
Figure 23: Activity diagram for "Fixed Asset Disposal" ......................................................................................... 35
Figure 24: User interface for "Login" .................................................................................................................... 36
Figure 25: User interface for "User Registration" ................................................................................................. 37
Figure 26: User interface for "User Account Management" - searching(filtering) accounts using different criteria
.................................................................................................................................................................... 37
Figure 27: User interface for "User Account Management"- taking appropriate measure with the selected
account ....................................................................................................................................................... 38
Figure 28: User interface for "Fixed Asset (Item) Information Registration" ........................................................ 38
Figure 29: User interface for "Fixed Asset Registration” ...................................................................................... 39
Figure 30: User interface for "Fixed Asset Transfer" ............................................................................................ 40
Figure 31: User interface for "Fixed Asset Disposal" ............................................................................................ 40
Figure 32: User interface for "Fixed Asset Return" ............................................................................................... 41
Figure 33: User interface for "Get Pass" ............................................................................................................... 41
Figure 34: User interface for "Fixed Asset Maintenance" ..................................................................................... 42
iii
List of Acronyms and Abbreviations
 FA – Fixed Asset
 FAMS – Fixed Asset Management System
 FAR – Fixed Asset Registration
 FART – Fixed Asset Return
 FATRA – Fixed Asset Tracking
 FR – Functional Requirement
 NFR – Non-Functional Requirement
 ZB – Zemen Bank
iv
1. Introduction
Requirement engineering deals with such activities as requirement elicitation, requirement
analysis, requirement specification, and requirement validation. The major tasks carried out in
requirement elicitation are: domain analysis, identifying stakeholders, gathering information,
refining the information collected, and requirement specification. The first four consecutive
listed activities are performed to come up with a well-articulated requirement specification
wherein system needs of a client is properly described and imparted to the system developers.
Likewise, so as to meet the system needs of the client (Zemen Bank S.C) and users’ expectation,
requirements are identified by taking vivid requirements of various actors or stakeholders into
consideration. Hence, system requirements are defined to the best level suffice to design the
system.
The Water-fall process model is applied as the system has simple and clear requirements. But, in
this project requirement determination involves the under major two phases:
 Problem identification and automated solution proposition;
 Requirement specification in line with the proposed solution;
Requirement analysis part of the project is divided into various distinct sections such as
introduction, objectives, purpose of the project, reviewing the existing system, describing the
proposed system, UML analysis of the components and user interactions within the domain of
the FAMS.
The document also includes system model which contains use case diagram, class diagram
sequence diagram, activity diagram, and user interface.
1.1. Existing System

The fixed asset management of Zemen Bank S.C has been manual wherein each activity related
to managing fixed asset is handled using simple spreadsheet to keep record of asset information
regardless of their type (fixed or non-fixed asset).
1
The business process starts from registering the asset with support division under facilities
department after being purchased by procurement division. Support or logistic and property
management division reports all assets purchased on arrival to finance department to maintain
list of inventory of fixed asset. Then finance department keeps record of the fixed asset on fixed
asset register. Upon request by department/s or branch/s, the fixed asset shall be delivered after it
has been tagged for easy tracking of the fixed asset. Finally, the fixed asset will be delivered to
the department or branch which has requested for its possession.
Following the delivery of the fixed asset to its destination (department or branch), other such
activities as transferring the fixed asset, calculating depreciation, maintenance, calculating
appreciation, and tracking where the asset exists come next. Handling these tasks involves
keeping proper recording, which is currently carried out manually using a form designed for the
purpose.
The existing workflow is described with diagrams from figure 1 through Figure 5.
1.1.1. Data Flow Diagram of the Existing System
i. Process of Fixed Asset information registration, delivery, and tracking
Figure 1: Data flow diagram for Process of Fixed Asset information registration, delivery, and tracking
2
ii. Process of Fixed Asset maintenance
Figure 2: Data flow diagram for process of Fixed Asset maintenance
iii. Process of Fixed Asset write-off
Figure 3: Data flow diagram for process of Fixed Asset write-off
3
iv. Process of Fixed Asset transfer and movement
Figure 4: Data flow diagram for process of Fixed Asset transfer and movement
4
v. Process of Fixed Asset Disposal
Figure 5: Data flow diagram for process of Fixed Asset disposal
1.1.2. Organization of the Existing System
At Zemen bank, the Director-Facility Management Department executes tasks related to fixed
asset management. This department is responsible for managing new fixed asset registration,
asset transfer, disposing assets, maintaining fixed asset, tracking asset at employees’ hand etc.
The following figure shows the partial organizational structure of the bank involving the
department under which management of fixed asset is carried out.
5
Figure 6: Partial organizational structure of ZB
1.2. Purpose of the Project

The very purpose of this project is to fulfil the partial academic requirement of the course called
Software Development and Project Management. To this end, we have opted to evaluate the
existing manual system which Zemen Bank has been using for more than a decade in managing
fixed asset; propose a better automated solution that can give a relief to the work unit handling
fixed asset management.
While fulfilling the academic requirement is one thing, the system to be developed shall be
utilized by Zemen Bank S.C as it is in a real need to solve the problem facing when handling
fixed asset management manually. Firsthand information has been collected, policy and
procedure manuals pertaining to fixed asset handling have been reviewed and the business
process has been properly observed. It is very likely that developing the system shall be
considered to be a significant contribution to the facility department of ZB.
6
1.3. Objective and Success Criteria of the Project

The quintessence of this project is to develop a fixed asset management system for Zemen Bank
S.C that shall provide the work unit with relieved workflow in line with the business requirement
of the company.
So as to realize the project, objectives are divided into two: general and specific objectives.
1.3.1. General Objective
The major objective of this project is to design and implement a FAMS for Zemen Bank S.C,
based on the business requirements collected from the work unit that this project is destined for.
1.3.2. Specific Objectives
So as to achieve the general objective, it is essential to describe ways that help realize the general
objective.
 Understanding the business process. This helps to comprehend the overall activities
performed in the facilities department of ZB, one of the activities of which is managing
the fixed asset of the bank. In this respect, policy and procedure of the bank shall be
reviewed, observation how employees in the work unit accomplish their tasks shall be
carried out;
 Understanding the problem. Problem identification is the very essential task as it leads
to proposing a candidate solution that can be achieved out of automating the workflow;
 Requirement specification. After twigging the business process, requirement is
specified in such a way that all system needs of the client are properly articulated so that
both the client and the developers understand the business requirement;
 Designing the system. In this specific objective of the general objective, using UML and
Use cases, system designing is performed, which is considered to be the major input to
the implementation;
 Implementing the system. This specific objective is considered to be the major one in
that the final software product is put into deployment, achieving the general objective.
However, such successive tasks as testing and debugging shall also be performed to
ensure a quality software is delivered to the client;
7
2. Proposed System
2.1. Overview
The FAMS takes four major departments into consideration: the facilities, the HR, and finance
department. Procurement of asset is performed in the facilities department and in the same
department carried out management of the fixed asset. However, the information related to cost
of fixed asset is also kept at finance department for accounting purpose. Hence, finance
department will have access to the system. Information as to which employee is using the fixed
asset is what the system is expected to perform; since, information related to employee is
obtained from the HR system, the FAMS shall have access to the HR system.
Each information pertaining to FA is stored in a central database so that data storage and
retrieval will be easier. The proposed software solution shall be able to avoid the major problems
encountered as using manual process. All anomalies related to data management in respect of FA
shall be eliminated as a result of introduction of this automated software solution.
Asset movement must also be properly recorded. FA transfer is initiated as a result of delivery to
the requested destination, from department to department, for maintenance, and disposal. In all
of these activities, there is information updating which shall be easier in this proposed software
solution, as opposed to the manual approach the bank has been using.
Naturally, fixed asset reduces its value due to wear and tear. The other reason an asset loses its
value is as a result of providing services for a longer period of time. For either of the two
reasons, the book value of an asset must be determined and kept a record of. So as to determine
the book value, it is essential to properly calculate the depreciation of an asset, and the calculated
depreciation value is deducted from the historical cost of the FA to arrive at the book value of the
asset. Such computation has been manually performed using excel spread sheet and its result is
maintained in the same file, and this has been causing difficulty in keeping a precise and
persistent information in respect of the FA. Unlike the manual approach, the proposed system
shall be able to calculate depreciation and store correct book value of the asset persistently,
relieving the work unit from calculating depreciation value of a large number of FAs with varied
nature.
8
As opposed to depreciation, there is also appreciation in FA value as a result of maintenance

service executed on a given FA. The increase in value by the FA shall also be properly recorded
in the system. This task is often forgotten in the case of manual approach, ending up wrong value
being reflected on the balance sheet of the bank. The proposed automated software solution shall
have the capacity to alleviate the problem being observed in the manual approach in this regard.
Tracking where exactly the FA is one of the major functionality the proposed system is going to
provide. In the case of manual approach, this task has been the major headache demanding
significant effort as it requires to review various documents which might not be properly kept,
resulting in difficulty of exactly locating the fixed asset.
To sum up, the proposed automated software solution is strongly believed to solve the problem
frequently encountered in the manual approach of managing fixed asset.
2.2. Scope and Limitation of the System

2.2.1. Scope
The proposed solution shall be able to manage the fixed asset of Zemen Bank S.C. Fixed asset
management that the system is going to handle involves: registering the fixed asset information
as it is purchased; registering the fixed asset after delivery to the specific work unit in the name
of the department or branch; handling the fixed asset transfer activity within departments or
branches; keeping track of the returning process; handling the maintenance activity when the
fixed asset is believed to need repair; calculating depreciation; handling fixed asset disposal
when the fixed asset is considered to be no more useful; and the last but not the least is report
generation when required. Hence, managing non-fixed asset is out of the scope of this software
solution.
2.2.2. Limitations
The software solution proposed by this project has the under listed limitations:
 The system will not be handling information related to procurement process;
 Notification functionality has not been defined in the system. Any user of the system will
not be notified each time a new fixed asset information is inserted in the system;
 The system will not totally eliminate the paper work being currently carried out;
9
2.3. Functional Requirement

The functional requirement refers to what tasks the proposed automated FAMS is supposed to
accomplish. So as to identify the functional requirements, it is a must to understand how the
currently in use manual system works and observe the problems most of the time being
encountered so that proposing an automated solution with major functionality included will be
easier. To this end, methodologies followed to realize the functional requirement must be clearly
identified.
Observing the business process with respect to managing the fixed asset of the bank; reviewing
policies and procedures pertaining to fixed asset management; and interviewing the employees
working in the facilities department are the methodologies followed to identify the functional
requirements. The functional requirements are listed hereunder.
Req.ID Description
FR1: The system shall allow a legitimate user to login
FR2: The system shall allow user registration;
FR3: The system shall allow user management;
FR4: The system shall allow asset(regardless of its type) registration just after
procurement process ends;
FR5: The system shall allow fixed asset registration with its custodian information
attached;
FR6: The system shall be capable of calculating depreciation on fixed asset;
FR7: The system shall be able to keep record of fixed asset upon transfer;
FR8: The system shall be able to update its record just after the fixed asset is returned;
FR9: The system shall be able to display Get Pass information to an Officer or Security;
FR10: The system shall be able to update its record in relation to fixed asset maintenance;
FR11: The system shall be able to update the increased value of a fixed asset after
maintenance service is carried out;
FR12: The system shall be able to update its fixed asset information resulting from change
in value with respect to disposal of fixed asset;
FR13: The system shall be able to generate report;
10
FR14: The system shall keep activity log information that will enable system auditing
easier;
2.4. Non-Functional Requirement
Req.ID Description
NFR1: The system shall be of user friendly interface to help users get easily acquainted with
the system
NFR2: The system shall inforce access control to prevent unauthorized user from getting
access into the system and/or to prevent a user from accessing a role for which he/she
is not entitled;
NFR3: The system shall keep all passwords encrypted;
NFR4: The system shall be accessible only to legitimate users based on a role granted by the
admin;
NFR5: The system shall be able to handle exceptions when error occurs;
NFR6: The system shall be scalable to business expansion and new development;
NFR7: The system shall be platform independent as the code shall be written using Java,
which is one of the platform independent programing languages;
11
3. System Model
3.1. Use Case Diagram
Figure 7: Use case diagram for FAMS of ZB S.C
12
3.1.1. Use Case Description

Table 1: System Use case for "Login"
Use Case ID : SUC-001

Use Case Name : Login
Actor : Admin, officer, Security
In this system use case, the Admin, the Officer or the Security shall be
Description :
able login using username and password
Trigger : When the user has to login to the system
The user must be employee of ZB and should be registered on user table
Precondition :
first
1. Actor first created on database
Normal Flow : 2. Actor enter user name and password and click on login button
3. The system displays the home pages of the system
Post Condition: Actor successfully logged in
2.1. If the actor enters wrong user name and password, the system
Alternative Flow: displays a notification message that the user inserted wrong input and
resets the fields.
Table 2: System Use case for "Register User"

Use Case Name : Register User
Actor : Admin
Description : This system use case, it is built for register system user
Trigger : When the employee required access privilege to the system
Precondition : The user must be employee of ZB
1. Admin login to the system
2. The system displays admin home page
Normal Flow : 3. Admin select create user link
4. The system displays user registration form
5. Admin enter input information and click create button
13
6. The system notify successfully created message

Post Condition : User successfully created
Alternative Flow : 5.1. If the admin entered wrong information, then the system notify
and the page is unchanged.
Table 3: System Use case for "Manage User"

Use Case Name : Manage User
Actor : Admin
In this system use case, the Manage user is built to manage user that
Description has different roles on the system. In addition to this, updating, and
viewing of users
Trigger : When the user have to access the system
The user must be employee of ZB and should be registered on User
Precondition :
table first.
1. Admin user first created on database
2. Admin user enter user name and password and click on login
button
3. The system displays the home pages of the system
4. The user clicks on the link of manage user link from the top menu
Normal Flow :
5. The system displays the manage user page.
6. The user selects user to be manage
7. The system displays user information
8. The user should select information to be updated and click button
9. The system return successfully message
Post Condition : User information successfully changed
2.1.If the user enters wrong user name and password, return the
reminder message that the user entered wrong password and user
Alternative Flows :
name and the login page unchanged.
14
Table 4: System Use case for "Register Asset"

Use Case Name : Register Asset
Actor : Officer
This system use case is used to add, delete, or update fixed asset when
Description :
the asset delivered from vender.
Trigger : When new fixed asset is delivered to store
Precondition : The new fixed asset is bought by ZB first
1. Officer login in to the system
2. The system displays the home page
3. Officer select FA info registration link
Normal Flow :
4. The system displays the FA info registration form
5. Officer enter information and click registration button
6. The system notifies new FA is successfully registered
Post Condition : Fixed asset is registered successfully
5.1. If the officer entered wrong information, the system notify that
Alternative Flow : the user entered wrong information and the form does not
change
Table 5: System Use case for "Register Fixed Asset"

Use Case Name : Register Fixed Asset
Actor : Officer
This system use case is used to add, delete, or update fixed asset
Description :
information that are found on employees hand
Trigger : When employee received fixed asset from store
Precondition : Fixed asset have to be registered and stored in storage first.
Normal Flow : 2. The system displays home page
3. Officer select FAR link
15
4. The system displays fixed asset registration form

5. User enter the information and click on save button
6. The system notify the asset record successfully registered
Post Condition : New fixed asset record created successfully
5.1. If the officer entered wrong information, the system notify
Alternative Flow : that the user entered wrong information and the form does not
change
Table 6: System Use case for "Depreciate Fixed Asset"

Use Case Name : Depreciate Fixed Asset
Actor Officer
This system use case, built to display the depreciation information of
Description :
fixed asset
Trigger : Fixed asset depreciation information is valuable
Precondition: Fixed asset is in use or in store
3. Officer select depreciation link
Normal Flow :
4. The system displays depreciation form
5. Officer select to see depreciation information
6. The system display the required information
Post Condition : The Officer successfully see selected depreciation information
Table 7: System Use case for "Transfer Fixed Asset"

Use Case Name : Transfer Fixed Asset
Actor : Officer
This system use case, the officer transferred fixed asset from one
Description :
employee to another either between two different departments or the
16
same departments
Trigger : When employee wants to transfer fixed asset to another employee
There must be two employees one transfer and the other received fixed
Precondition :
asset
3. Officer select FATF link
4. The system displays FATF form
Normal Flow :
5. Officer enter input information and click on transfer register
button
6. The system notify successfully transferred information is
registered
Post Condition : Fixed Asset Transferred registration successfully completed
5.1. If the officer entered wrong information, the system notify that the
Alternative Flow :
user entered wrong information and the page does not change
Table 8: System Use case for "Return Fixed Asset"

Use Case Name Return Fixed Asset
Actor : Officer
Description : This system use case, the employee return the fixed asset to the store
Trigger : When the employee wants to return the fixed asset to store
The employee leave the company, change the department, or wants to
Precondition :
receive new fixed asset because of the asset fail.
2. The system displays home page
3. Officer select FART link
Normal Flow :
4. The system displays FART form
5. User enter input information and click on register button
6. The system notify Fixed asset return registration successfully
17
completed
7. Officer click on print transfer information
8. The system enable print function and respond properly
Post Condition : The fixed asset returned successfully to the store
5.1.If officer entered wrong information, the system notify that the
officer entered wrong information and page does not change
Alternative Flow :
1.1. If the system does not print the form, the system should notify
the problem
Table 9: System Use case for "Get Pass"

Use case Name : Get Pass
Actor : Officer, Security
This system use case, the get-pass is built automate the get-pass
Description :
process
When the user wants to get out the fixed asset from office for
Trigger :
maintenance purpose or to another office location
Precondition : User have to receive fixed asset from store
2. The system displays home page
3. Officer select getpass link
4. The system displays getpass form
5. Officer enter input information and click register button
6. The system notifies successful registration massage and put to
Normal Flow :
the waiting list
7. Security login in to the system
9. Security select getpass link
10. The system displays the getpass form
11. Security view the waiting information and click the confirm
18
button
12. The system notify success message
Post Condition : User successfully get out the fixed asset
5.1.If the user entered wrong information, the system notifies and
Alternative Flow :
the page unchanged
Table 10: System Use case for "Maintain Fixed Asset"

Use Case Name : Maintain Fixed Asset
Actor Officer
This system use case, the maintenance is built to store the
Description :
maintenance information of fixed asset
Trigger : When the fixed asset need maintenance and maintained
Precondition : Fixed asset has a problem to maintain
3. Officer select the link of maintenance
4. The system displays maintenance form
Normal Flow :
5. Officer enter the input information and click on register
button
6. The system notify maintenance information is successfully
registered
Post Condition : Fixed asset maintenance information is successfully registered
5.1. If officer entered wrong information, system notify and the
Alternative Flow :
page does not change.
Table 11: System Use case for "Appreciate Fixed Asset"

Use Case Name : Appreciate Fixed Asset
Actor Officer
Description : This system use case, built to increase the book value of the asset
19
Precondition : The system increate the book value after maintenance

3. Officer select appreciation link
Normal Flow :
4. The system displays the appreciation form
5. Officer enter input information and click register button
6. The system notify success message
The appreciation registration is successfully registered and book value
Post Condition :
is increase
If officer entered wrong information, system notify and page is
Alternative Flow :
unchanged
Table 12: System Use case for "Dispose Fixed Asset"

Use Case Name : Dispose Fixed Asset
Actor : Officer
This system use case, the dispose is built to show the fixed asset
Description :
disposed information
Trigger : When disposal fixed asset is reported to dispose
Precondition : Fixed asset is initiated to dispose
3. Officer select dispose link
Normal Flow : 4. The system displays dispose form
5. Officer entered input information and click on register button
6. Disposed information is successfully registered and notification
is return
Post Condition : Dispose fixed asset registration is successfully registered
5.1. If officer entered wrong input, the system notify incorrect input
Alternative Flow :
has been entered and the page does not change
20
Table 13: System Use case for "Generate Report"

Use Case Name : Generate Report
Actor : Officer
Description : This system use case, built to generate report of different activities
Trigger : When the officer need to print report
Precondition : The required report information must be found in the system
3. Officer select generate report link
Normal Flow : 4. The system displays generate report form
5. Officer select types of report to print
6. The system displays the report information
7. Officer print the report
Post Condition : The report successfully generated
7.1.If the system does not print the form, the system should notify
Alternative Flow :
the problem
Table 14: System Use case for "Log Activity"

Use Case Name : Log Activity
Actor : Admin
This system use case is used to maintain the user information of the user
Description :
who access the system.
Trigger : When the activity log information is asked by third party.
Precondition : Users should access the system.
2. Admin login in to the system
3. System display admin home page of the system
Normal Flow :
4. Admin select manage user link
5. The system displays manage user form
21
6. Admin select activity log link

7. The system displays user activity information
8. Admin print the information using print button and have
successfully retrieve activity log information.
Post Condition : Activity log information is successfully retrieved
3.2. Class Diagram
Figure 8: Class diagram for ZB FAMS
22
3.3. Sequence Diagram
Figure 9: Sequence diagram for "Login"
23
Figure 10: Sequence diagram for "User Registration"
24
Figure 11: Sequence diagram for "Fixed Asset Information Registration"
Figure 12: Sequence diagram for "Fixed Asset Registration”
25
Figure 13: Sequence diagram for "Fixed Asset Transfer"
Figure 14: Sequence diagram for "Fixed Asset Maintenance"
26
Figure 15: Sequence diagram for "Fixed Asset Return"
27
Figure 16: Sequence diagram for "Fixed Asset Disposal"
28
3.4. Activity Diagram
Figure 17: Activity diagram for "Login"
29
Figure 18: Activity diagram for "User Registration"
30
Figure 19: Activity diagram for "Fixed Asset Information Registration"
31
Figure 20: Activity diagram for "Fixed Asset Registration"
32
Figure 21: Activity diagram for "Fixed Asset Tracking"
33
Figure 22: Activity diagram for "Fixed Asset Maintenance"
34
Figure 23: Activity diagram for "Fixed Asset Disposal"
35
3.5. User Interface
Figure 24: User interface for "Login"
36
Figure 25: User interface for "User Registration"
Figure 26: User interface for "User Account Management" - searching(filtering) accounts using different criteria
37
Figure 27: User interface for "User Account Management"- taking appropriate measure with the selected
account
Figure 28: User interface for “Asset (Item) Information Registration"
38
Figure 29: User interface for "Fixed Asset Registration”
39
Figure 30: User interface for "Fixed Asset Transfer"
Figure 31: User interface for "Fixed Asset Disposal"
40
Figure 32: User interface for "Fixed Asset Return"
Figure 33: User interface for "Get Pass"
41
Figure 34: User interface for "Fixed Asset Maintenance"
42
References
[1] Alan Dennis, Barbara Haley Wixom and David Tegarden, Systems Analysis and Design
with UML Version 2.0
[2] Bernd Bruegge & Allen H. Dutoit, Object-Oriented Software Engineering Using UML,
Patterns, and Java™ Third Edition
[3] Robert K. Wysocki, Effective Software Project Management, Wiley.
[4] Zemen Bank S.C, Fixed Asset Management Policy and Procedure
[5] Zemen Bank S.C, Procurement Policy and Procedure Manual
43

RAD Document For Fixed Asset Management System

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RAD Document For Fixed Asset Management System

Uploaded by

Copyright:

Available Formats

ADDIS ABABA UNIVERSITY SCHOOL OF GRADUATE

STUDIES COLLEGE OF NATURAL SCIENCES

Fixed Asset Management System

Submitted to:- Dida Midekso (Dr)

Behailu Eshetu………………………………… GSE/1659/10

Kuma Bekele…………………………………….. GSE/6491/09

Taye Mohammed………………………………... GSE/8104/10

Tesfaye Kebede………………………………….. GSE/9183/10

List of Figures……………………………………………………………………………………………………………………………………… iii

List of Acronyms and Abbreviations………………………………………………………….……………………………………... iv

Table 1: System Use case for "Login" ................................................................................................................... 13

List of Acronyms and Abbreviations

1.1. Existing System

ii. Process of Fixed Asset maintenance

Figure 2: Data flow diagram for process of Fixed Asset maintenance

iii. Process of Fixed Asset write-off

Figure 3: Data flow diagram for process of Fixed Asset write-off

iv. Process of Fixed Asset transfer and movement

v. Process of Fixed Asset Disposal

Figure 5: Data flow diagram for process of Fixed Asset disposal

1.1.2. Organization of the Existing System

Figure 6: Partial organizational structure of ZB

1.2. Purpose of the Project

1.3. Objective and Success Criteria of the Project

As opposed to depreciation, there is also appreciation in FA value as a result of maintenance

2.2. Scope and Limitation of the System

2.3. Functional Requirement

2.4. Non-Functional Requirement

Figure 7: Use case diagram for FAMS of ZB S.C

3.1.1. Use Case Description

Use Case ID : SUC-001

Table 2: System Use case for "Register User"

Use Case ID : SUC-002

6. The system notify successfully created message

Table 3: System Use case for "Manage User"

Use Case ID : SUC-003

Table 4: System Use case for "Register Asset"

Use Case ID : SUC-004

Table 5: System Use case for "Register Fixed Asset"

Use Case ID : SUC-005

4. The system displays fixed asset registration form

Table 6: System Use case for "Depreciate Fixed Asset"

Use Case ID : SUC-006

Table 7: System Use case for "Transfer Fixed Asset"

Use Case ID : SUC-007

Table 8: System Use case for "Return Fixed Asset"

Use Case ID : SUC-008

Table 9: System Use case for "Get Pass"

Use Case ID : SUC-009

Table 10: System Use case for "Maintain Fixed Asset"

Use Case ID : SUC-010

Table 11: System Use case for "Appreciate Fixed Asset"

Use Case ID : SUC-011

Precondition : The system increate the book value after maintenance

Table 12: System Use case for "Dispose Fixed Asset"

Use Case ID : SUC-012

Table 13: System Use case for "Generate Report"

Use Case ID : SUC-013

Table 14: System Use case for "Log Activity"

Use Case ID : SUC-014

6. Admin select activity log link

Figure 8: Class diagram for ZB FAMS