Asset Monitoring System

Problem Statement:
 Asset Monitoring System acts as an interface between user and the asset manager/distributor
at the institute level.
 The main objective of the proposed system is to introduce computerized system in an institute
which can be used as a resource for private network, in order to fulfill the needs of the institute
in terms of physical assets.
 The system helps in creating and managing a data repository of the assets pertaining to the
hardware of IT resources in the organization.

Purpose of the system:

 Asset Monitoring System is a web-based application, which has two major components, a
repository for capturing and storing asset data pertaining to the installed hardware and software
of a computer and its associated peripherals, and second component which deals with updating
the repository and dealing with user requests.
 The second component uses the data captured and stored by the first component and also the
financial and commercial details of the data pertaining to the repository.
 The financial details include data about assets on purchase order, invoice and warranty and the
commercial details include data on suppliers, contacts and contracts, etc.

Problems in the existing system:

The problem definition of the system is to launch an online system for keeping an asset repository of
an institute.
The objective of the project is to set up an on-line enquiry system about the status of the availability of
the hardware resources along with the facility to request for new resources online and also to automate
the issuing procedure.

 Time Delay: It is inefficient to deal with voluminous data manually in the existing system where
records are stored in different files.
 Redundancy: As the branches are located in different locations, same files have to be stored
at all branches which increases data redundancy.
 Accuracy: Since same data is compiled at different branches the possibility of tabulating
incorrect data is high.

Solutions to be implemented in proposed system:

In the proposed system, we are computerizing the institute which is spread over a number of branches
at different locations and are connecting them through intranet (private network). This makes keeping
the asset repository up-to-date easier.

 Reliability: The system performs intended function with required precision; hence it is very
reliable.
 Feasibility: The system maintenance is very easy and modifications can be made in the existing
system in future. The system can interconnect to other branches within the institute under the
integrated network.
  Online Processing: The online processing of the system is kept simple following the existing
manual method without changes and suitable validation is provided for easy and correct access
of users.
 Security: Security measures are taken to avoid mishandling of database. Password restrictions
are provided to get access into the database. Only a user having valid username and password
will be granted access to the system.

Features of the system:

 Repository of the computers with management of the device’s connections.
 Repository of the network hardware with management of the connections to the devices (IP
addresses, MAC addresses, VLANs)
 Repository of printers with management of connections to the computers.
 Repository of the softwares with license and their expiration dates.
 Commercial and financial information management (purchase order, invoice, warranty,
extension and damping).
 History of the modifications on the elements of the repository.

Analyzing the system:

Graphical User Interfaces -

For the flexibility of the user, the interface has been developed keeping graphics in mind.
The GUI’s at the top level have been categorized as,
1. Administrative user interface
2. Operational or generic user interface

Administrative User Interface -

 The administrative user interface concentrates on the consistent information, that is practically,
part of the institutional activities and which needs proper authentication for the data collection.
 The interfaces help the administration with all the transactional states like data insertion deletion
and updating along with the extensive data search capabilities.

Operational or Generic User Interface -

 The operational or generic user interface helps the users of the system in transactions through
the existing data and required services.
 The operational user interface also helps the users in managing their own in a customized
manner as per the assisted flexibilities.

Modules to be implemented in the proposed system:

The system is differentiated in the following modules which are closely integrated with one another.
 1. Administrator:
 The activities that are carried out in this module are related to the maintenance of records such
as user database, asset database and approval or rejection of the asset requests for the entire
institute.
 It also contains facilities to generate reports and sending automated emails after a certain
procedure is complete.
 Only the administrator has the privileges to access and edit user and asset database.

Administrator capabilities:
 System log in/log out privilege
 Accessing/editing user database
 Accessing/editing asset database
 Approving/rejecting user request
 Implementing asset management policy
 Generating reports
 Sending automated emails after completion of a procedure

2. User:
The activities that are carried out in this module are related to browsing asset repository, searching
assets through specific attributes, submitting new asset/version upgrade/repair requests and tracking
the status of the request.

User capabilities:
 System log in/log out privilege
 Browsing asset repository
 Searching specific assets using various attributes
 Submitting new asset/version upgrade/repair requests
 Tracking the status of the request

3. Asset:
This module is used for automatically capturing repository data regarding installed hardware and
software.

Asset module consists of:

 Supplier details
 Asset details
o Type – Hardware/software
o Product specification
 Asset availability
 Financial details
o Purchase order
o Invoice
o Warranty
o Extension
o Damping
 Legal restrictions
Use case diagram:

Use case specification:

1. System log in/log out capabilities

a. Brief description: Allows log in/log out privileges to the verified user.
b. Actors:
i. Administrator
ii. User
 c. Pre conditions: Unauthenticated session
d. Basic flow:
i. The user selects the Login button from the home page.
ii. The system displays login page.
iii. The user provides username, password and a string from displayed image
(CAPTCHA).
iv. The user selects Submit button.
v. The system fetches user permission and displays home page with menus
corresponding to user permissions (admin/user).
e. Alternate flows:
i. The system, if the provided information is incomplete or erroneous, displays an
error message to the user:
1. The user selects the Return button; and
2. The system displays the Login page with blank fields.
f. Exception flows:
i. The user cancels the login by selecting the Cancel button from the Login page:
1. The system displays the home page, and
2. The system does not store any updated information.
ii. A database error is encountered:
1. The system displays an error message.
iii. Invalid username, password and/or string (CAPTCHA):
1. The system displays an error message.
g. Post conditions:
i. Authenticated session

2. Access/edit user database

a. Brief description: Administrator can add/update user entries in the database.

b. Actors:
i. Administrator
c. Pre conditions: Administrator’s authenticated session
d. Basic flow:
i. Administrator selects the Users tab.
ii. The system displays the Users page.
iii. The administrator selects add user/edit user button.
iv. The system displays following fields:
1. Un-editable fields:
a. Username
b. Role
2. Editable fields:
a. Password
b. Name
c. Email ID
v. The administrator adds/updates the above fields as applicable.
vi. The administrator selects the Submit button.
vii. The system displays a message with the administrator provided information and
requesting the administrator to confirm the submission:
1. The admin selects the Confirm button, or
 2. The admin selects the Return button.
a. The system displays the Users page with current information.
viii. The system updates the User database entry with the applicable changes.
e. Alternate flows:
i. The system, if any of the above fields are incomplete, displays a message
indicating the missing information and request the admin to provide it:
ii. The user selects the Return button; and
iii. The system displays the Users page with current information.
f. Post conditions:
i. A new user entry is added to the database, or
ii. An existing entry is updated.

3. Access/edit asset database

a. Brief description: Administrator can add/update asset entries in the database.

b. Actors:
i. Administrator
c. Pre conditions: Administrator’s authenticated session
d. Basic flow:
i. Administrator selects the Assets tab.
ii. The system displays the Assets page.
iii. The administrator selects add user/edit asset button.
iv. The system displays following fields:
1. Un-editable fields:
a. Asset_id
b. Name
c. Type
2. Editable fields:
a. Status
b. Version
v. The administrator adds/updates the above fields as applicable.
vi. The administrator selects the Submit button.
vii. The system displays a message with the administrator provided information and
requesting the administrator to confirm the submission:
1. ssThe admin selects the Confirm button, or
2. The admin selects the Return button.
a. The system displays the Assets page with current information.
viii. The system updates the Asset database entry with the applicable changes.
e. Alternate flows:
i. The system, if any of the above fields are incomplete, displays a message
indicating the missing information and request the admin to provide it:
1. The user selects the Return button; and
2. The system displays the Assets page with current information.
f. Post conditions:
i. A new user entry is added to the database, or
ii. An existing entry is updated.

4. Approving/rejecting asset requests

 a. Brief description: Administrator analyses the requests and approves/rejects them.
b. Actors:
i. Administrator
c. Pre conditions: Administrator’s authenticated session
d. Basic flow:
i. The administrator selects Requests tab.
ii. Then he/she selects approve requests button.
iii. If the specific requested asset:
1. Is in working condition.
2. Is available for use at the time.
iv. The administrator sets the status of the request to Approved.
v. The request database entry is updated with status change.
vi. Automated email is sent to the user regarding the status change.
e. Alternate flows:
i. Upon getting the request, if the specific asset requested asset:
1. Is not in a working condition, or
2. Is not available for use at the time.
ii. The system does not store any updated information.
iii. Automated email is sent to the user regarding the status change.
f. Post conditions:
i. The system displays the Request details page with updated information.
ii. The closed request is stored in the database.
iii. Email is sent to the user regarding status change of the request.

5. Implementing asset management policy

a. Brief description: Administrator can change the protocols based on which assets are
purchased, distributed, and made available.
b. Actors:
i. Administrator
c. Pre conditions: Administrator’s authenticated session
d. Basic flow:
i. The administrator selects Edit policy tab.
ii. The system displays Policy page.
iii. The administrator changes the protocol as he/she sees fit.
iv. The database is updated with applicable changes.
e. Post conditions: The updated policy is then implemented while dealing with asset
monitoring.

6. Sending email notifications after completing a process

a. Brief description: After a particular request is approved/rejected, automated email is

sent to the user who submitted the request.
b. Actors:
i. Administrator
c. Pre conditions: Administrator’s authenticated session
d. Basic flow:
 i. When the status flag in the asset request changes, a pre-programmed email is
generated by the system and sent to the user who submitted the request.
e. Post conditions: An email is sent to the user regarding the change in the request status.

7. Generating reports

a. Brief description: Administrator generates a report detailing current asset availability,

need and other statistics.
b. Actors:
i. Administrator
c. Pre conditions: Administrator’s authenticated session
d. Basic flow:
i. Administrator selects Reports tab.
ii. The system displays Reports page.
iii. Admin selects generate report button.
iv. A document containing all the current asset repository information is generated.
e. Post conditions: A detailed report is generated.

8. Browsing asset repository

a. Brief description: User can go through the entire repository to check the specifications
and availability of the assets.
b. Actors:
i. User
c. Pre conditions: User’s authenticated session
d. Basic flow:
i. The user selects Asset tab.
ii. The system displays asset page.
iii. The user selects Repository tab under Asset tab.
iv. Now the entire repository is displayed for the user to browse through.

9. Searching specific assets using various attributes

a. Brief description: The user can search for a particular asset using various attributes
(asset_id, type, etc.).
b. Actors:
i. User
c. Pre conditions: User’s authenticated session
d. Basic flow:
i. The User selects Search tab under Asset tab.
ii. The system displays Search page.
iii. The user can specify the attributes (any number of them):
1. Type
2. Asset_id
3. Name
iv. The user selects Search button.
v. The query is transferred to the database.
vi. The result set is now displayed by the system.
 e. Post conditions: The asset with specified attributes is displayed.

10. Submitting new asset/version upgrade/repair request

a. Brief description: The user can submit request for new assets, for upgrading existing
asset or for repairing of some asset.
b. Actors:
i. User
c. Pre conditions: User’s authenticated session
d. Basic flow:
i. The user selects the Submit request button under the Requests tab.
ii. The system displays the Submit request page.
iii. The user provides the following information:
1. Type of request – (new asset/upgrade/repair)
2. Type of asset
3. Asset_id
iv. The user selects the Submit button.
v. The system:
1. Assigns the request a unique identification number (Request_id).
2. Sets the request status to pending.
3. Adds the request to the database including Request_id, asset_id, type,
description, status and username.
vi. Displays a message to the user with the request ID:
1. The user selects the Return button.
e. Exception flows:
i. The user cancels the request by selecting the Cancel button from the Submit
general request page:
1. The system displays the original system page.
2. The system does not store any information associated with the cancelled
request.
ii. A database error is encountered:
1. The system displays an error message.
f. Sub flows:
i.
g. Post conditions:
i. The system displays the system page from which the Requests tab was accessed.
ii. The new request is stored in the database,
h. Special requirements:

11. Tracking the status of the request

a. Brief description: The user can check whether the request submitted by him/her is
approved or not.
b. Actors:
i. User
c. Pre conditions: User’s authenticated session
d. Basic flow:
i. The user selects the Search request button under the Requests tab.
 ii. The system displays the Search request page.
iii. The user provides the following (all optional) search attributes:
1. Request_id
2. Type
3. Description string
iv. The user selects the Search button.
v. The system builds the query based on the selected parameters and issues it to the
database.
vi. The system displays the Search results page with the list of requests returned by
the query with:
1. Request_id
2. Type
3. Status
e. Exception flows:
i. The user cancels the search by selecting the Return button from the Search
request page:
1. The system displays the original system page.
ii. The user triggers a new search by selecting the New search button from the
Search results page:
1. The system displays the Search request page with all search information
fields cleared.
iii. The user clears all search information fields by selecting the Clear search
parameters button from the Search request page:
1. The system displays the Search request page with all search information
fields cleared.
iv. The query does not return any result:
1. The system displays a “No results found” message.
v. A database error is encountered:
1. The system displays an error message.
f. Post conditions: User will get to know the status of the submitted request
(approved/rejected).
g. Special requirements:
i. There has to be at least one request application submission.