UCSC Electronic Lab Management System

University of colombo school of computing | 28/04/2015
Software Requirements Specifications Document
Information System for Electronic Laboratory at

UCSC
Software Requirements Specification (SRS)
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)
SRS of Group 24
Page 1 of 69
03/25/15
SCS2102/ IS2002
(Group 24)
Group Members
Name
Registration Index
Number
E-mail address
Mobile
Phone
R.W.M.N.H.Wanigasekera
2013/CS/126
13001264
nalinda2hemanga@gmail.com
0722456670
H.M.G.C. Herath
2013/IS/019
13020196
gayan.c.herath@gmail.com
0714841652
D.H.U. Perera
2013/CS/090
13000901
hisharaperera@gmail.com
0710474949
S.S.H. Subasinghe
2013/CS/116
13001167
heshansubasinghe@gmail.com
0713639264
K.A.D.D.D. Nanayakkara
2013/IS/032
13020323
kadddn92@gmail.com
0773566288
T.H.D.L.B. Thirimanne
2013/CS/121
13001213
lbhanuka@gmail.com
0711886227
Software Requirements Specification (SRS)

Report
Supervisor :
Mr.H.E.M.H.B.Ekanayake
Project Advisors :
Mr. Asanka Sayakkara,
Miss. J.H.K.Thiyumini
Version: 1.0Date: (28/04/2015)
SRS of Group 24
Page 2 of 69
03/25/15
Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 Hardware Interfaces
2.1.3 Software Interfaces
2.1.4 Memory Constraints
2.1.5 Operations
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 Inputs and Outputs
3.2 Functions (Functional Requirements)
3.2.1 System Login sub system use case
3.3 Performance Requirements
3.4 Design Constraints
3.4.1 Standards Compliance
3.5 Software System Attributes
3.5.1 Reliability
3.5.2 Availability
3.5.3 Security
3.5.4 Maintainability
3.5.5 Portability
4.
Supporting Information
SRS of Group 24
Page 3 of 69
03/25/15
1. Introduction
Our project is focus on Electronic lab of University of Colombo School of Computing.
Previous year this electronics lab was combined with WASN lab and it was difficult to do
the operational and administrative processes. Therefore this year onwards those two labs
will be separated and operated under different administrations. In the present the lab
which handles the electronic and embedded practical classes is called as Electronic
Laboratory. And also from this year some of tutorial classes are going to be held at this
lab.
Currently the operations of the lab are done manually. Now we are considering to replace
that with a web based information system for Electronics laboratory according to the
processes run on there.
There will be only a public interface for guest users. And there will be a more specified
interfaces for the other users of the system. The main purpose of this public interface is to
post achievements, projects and researches. Other interfaces will be given according to
their role and responsibility.
There will be a list of electronic equipments under related categories and sub categories
which are at Electronic lab. Proposed system is designed to track those equipments using
issuing and returning process.
This proposed system manages the scheduling activities of lab practical classes and
tutorial classes. Such scheduling activities are view schedule, reserve the free time slots
for lab practical and tutorial classes.
1.1 Purpose
The purpose of this System Requirement Specification document is to present the
requirement description of the web based information system to be developed during the
analysis stage of the project.
This web based information system is designed to Electronic Laboratory at University of
Colombo School of Computing to manage the processes of the laboratory such as
tracking electronic equipment when issuing and returning them, increase the publicity of
the lab, scheduling the tutorial classes and lab practical.
The purpose of this document is to describe the functionalities of the web based
information system that the system is expected to do and not to do. It will describe
functional and non-functional requirements of the system. Basically this document will
act as an agreement between the client and the developer. And also it is intended for
designers, and testers of system. The use of this document will be to see whether user
requirements are met in the process. After creating the SRS the implementations will be
done.
SRS of Group 24
Page 4 of 69
03/25/15
1.2 Scope
Through our project we design a web based information system for electronic laboratory
at UCSC.
In previous year this lab had two parts but now they were separated as electronic lab and
WASN lab. In this project we consider only the electronic laboratory.
This project is aimed only at the functionalities among the electronic laboratory
environment. There is no interaction between Virtual Learning Environment of UCSC
and our system. This system has various types of users such as admin (lab admin, system
admin), teaching assistant (non-related teaching assistant, related teaching assistant),
lecturer (related lecturer, non-related lecture), student (graduate, under graduate), lab
assistant, and collaborator. These users will have different access levels and each user
have relevant interface to interact with the system.
The main goal of this project is to manage and control the processes of the Electronics
laboratory at UCSC.
Objectives:
Increase publicity and connectivity among the users.

Online forum will allow to share knowledge among users.
Scheduling the laboratory practical and tutorial classes.
Handling Inventory by maintaining a database of Electronics Equipment
Track Electronic equipment by using issuing and returning details of the items.
Benefits:
There will be no paperwork to do when issuing and returning the equipments, so the
process will be faster
User friendly.
Being a web application, It can be accessed from anywhere at anytime.
Booking of the electronic laboratory will be an easy task
Anyone can make donations to the lab via the website, and the donation process is very easy. So it
will encourage more users to make donations
SRS of Group 24
Page 5 of 69
03/25/15
1.3 Definitions, Acronyms, and Abbreviations
SRS
Software Requirements Specifications
UCSC
University of Colombo School of Computing
WASN
Wireless Ad-Hoc and Sensor Network
HTML
Hypertext markup language
PHP
Hypertext Preprocessor
UML
Unified Modelling language
CSS
Cascading Style Sheet
SCoRe
Sustainable Computing Research
QR code
Quick response code
Definitions :
System: System refers to the proposed Web based information system for the Electronic
Laboratory in UCSC
Server: The term server refers to the server software and the Server machine
User: Who are use the System
Database: Which is keeping tracks of Members and Equipments
Wish list : A list of items that wish to be purchased in future
payment Gateway: an e-commerce application service provider service that authorizes
credit card payments
barcode : An optical machine-readable representation of data relating to the object to
which it is attached
1.4 References
WHITTEN Jeffrey and BENTLEY Lonnie, (2005), Systems Analysis and Design
Methods 7th Edition, New York: McGraw Hill.
SOMMERVILLE Ian, Software engineering, 9th Edition. Massachusetts: Pearson,
Sams Teach Yourself UML in 24 Hours, 3rd Edition
LankaTronics - Sri Lanka's Best Electronic Component Store CATEGORIES [Online]
Available from: http://www.lankatronics.com
SRS of Group 24
Page 6 of 69
03/25/15
1.5 Overview
Rest of the document describes as follows,
Chapter 2 contains an overall description of web based information system for the
Electronic Laboratory at UCSC and how will be the interfaces are designed. And also
focuses on the product functions, system interfaces and hardware interfaces.
Chapter 3 focuses on the developer related information. Specific requirements of inputs,
outputs, functional, performance requirements, design constraints and software system
attributes such as reliability, availability, security, maintainability, portability.
Chapter 4 describes the ways that makes to use the Software Requirements Specifications
easily.
2. The Overall Description

The web based information system is designed to assist the processes of the electronic
laboratory such as tracking hardware equipments, scheduling practical and tutorial
classes and increasing publicity. A bar code system will be used to track the equipments
and the relevant users will able to reserve the laboratory through the website. The
achievements will be posted in the public interface of the website. The system facilitate
the guest users to donate money to the electronic laboratory through the UCSC payment
gateway.
2.1 Product Perspective

Our project is almost independent from other related systems of the UCSC such as virtual
learning environment and library system. Since the system is a self-contained system
with its own website, there will not be a requirement to integrate with an external system,
but there will be a connection to the UCSC payment gateway to handle the donation
payments.
There are no direct similarities to our system, but there are some systems available which
have the same functionalities as our system. SCoRe laboratory of the UCSC uses a
inventory handling system. A QR code is attached to each and every equipment and track
them using a mobile phone application.
2.1.1 System Interfaces
Our system is going to handle the donations from the guest users, so that the UCSC
payment gateway will be used as a system interface for our system to manage the credit
card payments.
SRS of Group 24
Page 7 of 69
03/25/15
2.1.2 Hardware Interfaces

Hardware interfaces are required to direct the hardware by connecting the hardware and
software components. A barcode scanner is used as a hardware device to interact with the
system. Every equipment in the laboratory has a barcode label pasted on it. In the
issuing/returning process the barcode scanner is used to scan the relevant barcode of the
equipment, and thereby the system gets the details of the particular equipment.
The keyboard wedge output is used to interface the barcode reader to the computer. The
barcode readers with keyboard wedge output plug directly into the keyboard port on the
computer and they also provide a pigtail connector so that we can plug in the keyboard at
the same time. When we scan a barcode with the keyboard wedge barcode reader, the
data goes into the computer just as if it were typed in on the keyboard. This makes it
extremely easy to interface the barcode reader to any application that is written to accept
keyboard data.
RS232 or serial interface is another method to interface the barcode reader to the
computer. Here we need a program called a "Software Wedge" to take the data from the
barcode reader. It is little more complex compared to the keyboard wedge output method.
So we use the keyboard wedge output method as it is extremely simple.
2.1.3 Software Interfaces
HTML
HTML version 5 will be used to develop user interfaces.
CSS
CSS version 3 will be used to add styles to user interfaces.
PHP
PHP version 5.5 will be used for back end programming.
SQL
MySQL version 5.6.17 will be used for database design. 5.55.6.176.
So the system is to be written using PHP version 5.5 and the database builder is MySQL.
Web page builder is HTML5 and the front end designer is CSS3. Since all these software
are freeware, they can be easily downloaded from the Internet.
2.1.4 Memory Constraints
This system entirely runs on the servers of UCSC, therefore the users of the system who
connect to it via the Internet have no need of specific memory requirements on their PCs.
SRS of Group 24
Page 8 of 69
03/25/15

Their PCs are only need to be able to run Internet Explorer 7 or above, Google Chrome or
Firefox. However to run these web browsers their PCs must have minimum requirements
of 512MB of RAM and 350MB disk space.
2.1.5 Operations
Currently back up is planned weekly and it is send to the cloud storage once in every
three months the quantity of each electronic equipment is checked.
In addition to that there is already a method to store backup in UCSC servers.
2.2 Product Functions

1.
2.
3.
4.
5.
When designing this system we have to focus in these main functionalities.

Tracking lab equipments by issuing and borrowing process.
Schedule practical and tutorial classes.
Increasing the publicity of the lab.
Handling Inventory
Share knowledge and experiences of past students
These main functions will be supported by many other functions. The following table will
provide a brief description on them.
Function
Description
User registration.
Users will be registered by the system admin

under their UCSC index number.
User log-in
Users can log-in by typing their user name

and password. Their log-in interfaces will be
differ according to the account type.
Manage inventory
Add/Remove equipment, Edit equipment

details, and maintain wish-list.
Track equipments
Issue equipments/ Return equipments
Request lab slot
Particular users can request a lab slot and the

requests can be accepted or denied by the lab
assistant.
View equipments
Particular users can view equipments and their

details.
Manage news and researchers.
Particular users can update/edit news features

on the web site.
Donate
Guest users can donate money
SRS of Group 24
Page 9 of 69
03/25/15
2.3 User Characteristics
User
Educational Level
Experience
Technical Expertise
Administrator
Lab
Admin
System
Admin
High
High
(have
experience
with
virtual
Learning
Environment
of
UCSC)
Medium (Have a
good
knowledge
about computers as
well as information
systems but not about
this system.)
Medium (Graduates
Underg and Undergraduates)
raduate
Graduat
e
High
(have
experience
with
virtual
Learning
Environment
of
UCSC)
Medium (Have a
good
knowledge
about computers as
well as information
this system.)
High
High
(have
experience
with
virtual
Learning
Environment
of
UCSC)
High (Have a good

knowledge
about
computers as well as
information systems
but not about this
system.)
Teaching
Assistant(TA)
Related
TA
Nonrelated TA
High
High
(have
experience
with
virtual
Learning
Environment
of
UCSC)
Medium (Have a
good
knowledge
about computers as
well as information
this system.)
Temporary User
Medium
(undergraduates)
High
(have
experience
with
virtual
Learning
Environment
of
UCSC)
High (Have a good

knowledge
about
computers as well as
information systems
but not about this
system.)
Collaborator
Can be vary
Can be vary
Can be vary
Guest
Can be vary
Can be vary
Can be vary
Student
Lecturer
Related
Lecturer
Nonrelated
Lecturer
SRS of Group 24
Page 10 of 69
03/25/15

Primary users of this system will be members of UCSC like students, academic staff and
past students (graduates). So they all are well familiar with using web based information
systems because of the Virtual Learning Environment of UCSC. And of course every
one of them have a good knowledge about using computers and the Internet.
The outsiders (guests) are only be able to visit the web page. So they have to be able to
use the Internet. There they can see news and achievements of the electronic lab. And
they can also make donations.
2.4 Constraints
The Internet connection is a constraint for the users of the system. Since the system
communicates with the users over the Internet, it is crucial that there is an Internet
connection between users and the system.
The security level of the system and its database should be high enough so that outsiders
cannot make any changes to the system over the Internet and make it malfunction.
Web site will only appear in English and Login e-mail and password is used for the
identification of users.
2.5 Assumptions and Dependencies

The invitation e-mails would be sent in English. It can be assumed that e-mail users
have no issue in reading the mail.
The assumption is that our current academic year is representative of the previous, with
regard to length. This assumption has been maintained in preparing the project schedule
According to our feasibility study our projects total implementation cost is 38,000Rs.
(30,000 for the Lab computer and 8,000 for the barcode system) We assume that UCSC
will provide us with a lab computer and we can bear the cost for implementation of
barcode system.
SRS of Group 24
Page 11 of 69
03/25/15
3. Specific Requirements
3.1 Inputs and Outputs
I.
User Registration
Name of
Item
Description of purpose
Source of
input or
destinatio
n of
output
Valid range,
accuracy
and/or
tolerance
Name of
the user
To identify the users

name and thereby other
users can recognize the
users who are in the
system.
To identify the users who
post on the forum
Keyboard
(Laptop/D
esktop
Computer)
This will include None

only initials of
the name and
surname.
Maximum 30
characters,
characters only
None
Text
E-mail
When the new users sign

up to the system.
All the users have to use
the e-mail address every
time they log in to the
system.
Keyboard
(Laptop/D
esktop
Computer)
A valid e-mail
address.
Users cannot
sign in or sign
up without an email address.
None
User
name
Text
(E-mail
address
format)
Access
level
To identify the privileges

given by the system
Mouse
(Laptop/D
esktop
Computer)
Can select only

the access level
given in the
system.
None
None
Check
box
Course
To identify courses of the

students
Mouse
(Laptop/D
esktop
Computer)
Can select only

the courses
given.
None
None
Drop
down
list
Keyboard
(Laptop/D
esktop
Computer)
Can insert
alphanumeric
letters. 30
characters
maximum
length.
None
None
Text
Address 01 Not required. No of the

address or street of
address or city.
To give more users' info
SRS of Group 24
Page 12 of 69
Units of Relation Data

measure ships to formats
other
inputs/o
utputs
03/25/15

Address 02 Not required. Name of
street or city.
Keyboard
(Laptop/D
esktop
Computer)
Can insert
None
alphanumeric
letters. 30
characters
maximum length.
None
Text
Address 03 Not required. Name of

city.
Keyboard
(Laptop/D
esktop
Computer)
Can insert
alphanumeric
letters. 30
characters
maximum
length.
None
None
Text
Telephone
Number
Keyboard
(Laptop/D
esktop
Computer)
Can insert
numbers and
plus symbol.
None
None
Number
s
II.
Not required. To give

more contact info.
Equipment Registration
Name of
Item
Description of
purpose
Source of input
or destination of
output
Valid range,
accuracy
and/or
tolerance
Units of
measure
Relationshi Data
ps to other formats
inputs/outp
uts
ID
To identify the
equipment
uniquely
Keyboard
(Laptop/Desktop
Computer)
Alphanumeric
characters
None
Name
Text
Name
To identify the
equipment
Keyboard
(Laptop/Desktop
Computer)
Maximum 30
characters,
Characters only
None
None
Text
Category
To categorize
equipment.
To identify
equipment
easily
Mouse
(Laptop/Desktop
Computer)
Maximum 30
characters,
Characters only
None
None
Drop
down
list
Sub
Category
To categorize
equipments in
detail (If
available only)
Mouse
(Laptop/Desktop
Computer)
Maximum 30
characters,
Characters only
None
Category
Drop
down
list
SRS of Group 24
Page 13 of 69
03/25/15

Supplier
name
To identify the
supplier
Keyboard(Laptop/ Maximum 30
Desktop)
characters,
Characters only
None
None
Text
Supplier
Address
To identify the
supplier address Desktop)
characters,
Characters only
None
Supplier
Name
Text
Supplier
Email
address
As a contact
detail
Desktop)
Characters.
None
Supplier
Name
Text
(Email
address
format)
Supplier
Telephone
number
As a contact
detail
Keyboard
(Laptop/Desktop)
Maximum
None
character length
is 10
Supplier
Name
Number
s
III.
Scheduling Details
Name of
Item
Description of
purpose
Source of
input or
destination
of output
Valid range,
accuracy
and/or
tolerance
Units of
measure
Relations Data formats

hips to
other
inputs/ou
tputs
Schedule
type
To identify
whether it is
tutorial or lab
practicals
Keyboard
(Laptop/Des
ktop)
Should be
tutorial or
practical
None
None
Radio Buttons
Date
To reserve the lab. Mouse

(Laptop/Des
ktop)
Should be date None

on the calendar.
None
None.
According to
Calender
Time
Duration
To reserve the
time slot
Keyboard
(Laptop/Des
ktop)
Should be
between 08:00
to 18:00.
24Hours
None
Input format
should be
xx:xx-yy:yy
Subject
Code
To identify the
subject
Keyboard(L
aptop/Deskt
op)
None
None
None
Text
Eg: IS2002
Subject
Name
To identify the
subject
Keyboard
(Laptop/Des
Maximum 30
characters only
None
Subject
Code
Text
SRS of Group 24
Page 14 of 69
03/25/15

ktop)
Teaching
Assistant
name
To identify the
Keyboard(L
Teaching assistant aptop/Deskt
op)
Maximum 25
characters only
None
None
Text
Description
Reason to reserve
the lab (Not
Required)
Maximum 50
characters only
None
None
Text
Keyboard(L
aptop/Deskt
op)
3.2 Functions (Functional Requirements)

3.2.1 System Login sub system use case
Use case diagram 1
SRS of Group 24
Page 15 of 69
03/25/15

3.2.1.1 System log in use case narrative
Use case name:
System log in
Use case ID:
010
Priority:
High
Source:
Use case Diagram 1
Primary
actor:
Other
actors:
SYSTEM ANALYSIS
business Admin, Teaching assistant, Lecturer, Student ,Lab assistant

Temporary user, Collaborator
participating None
Other
interested System admin - Interested in who logs into the system in
stakeholders:
order to know how the students are dealing with the lab
Description:
This use case describes how to log in to the system. For this purpose
User should provide E-mail and the password which was given to
the user by System Admin.
Preconditions
Internet connection is available

System Home-page displays on the actors web browser.
Trigger
Typical
Event
This use case is initiated when a user want to log on to the system
Course
of Actor action
User enters user name and the Verify the user name and the
password to the system
password. User get access to
the site
Users web browser displays the appropriate page according to their
authority level. If the user name or password is incorrect display an error
message.
Post conditions
Implementation
Constraints
Specifications :
System response
None
and
3.2.1.1.1 Reset forgot password use case narrative

Use case name:
SRS of Group 24
Reset forgot password
Page 16 of 69
SYSTEM ANALYSIS
03/25/15

Use case ID:
011
Priority:
Low
Source:
Use case diagram 1
Primary
business actor:
Admin, Teaching assistant, Lecturer, Student ,Lab assistant

Other
participating
actors:
none
Other
interested
stakeholders:
None
Description:
This use case facilitate user to reset the forgot password

using a link that is sent to their email.
Preconditions
Internet connection available

User must be registered to the system
Trigger
When forgot the password on the login page
Typical Course
of Event
Actor action
System response
user click on the reset

password link
send an e- mail to the

corresponding
user
with an activation link
go to e-mails and click on

the link
provide
a
User
interface to reset the
login password
Post conditions
A message is displayed that the password has changed.
Implementation
Constraints and
Specifications :
none
3.2.1.1.2 Record log details use case narrative

Use case name:
Record Log details
Use case ID:
012
Priority:
High
SRS of Group 24
Page 17 of 69
SYSTEM ANALYSIS
03/25/15

Source:
Use case diagram 1
Primary
business actor:
Admin,Teaching assistant, Lecturer, Student, Lab

Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
System automatically record about the login details of each

and every users.
Preconditions
Internet Connections available

User is registered
Trigger
User log in to the system
Typical Course
of Event
Actor action
System response
user enter password and

username and successfully
log in to the system
Record the
login
details accordingly
Post conditions
None
Implementation
Constraints and
Specifications :
None
assistant,
3.2.1.2 View log details use case narrative

Use case name:
View log details
Use case ID:
011
Priority:
Low
Source:
Use case diagram 1
Primary
business actor:
System Admin
SRS of Group 24
Page 18 of 69
SYSTEM ANALYSIS
03/25/15

Other
participating
actors:
none
Other
interested
stakeholders:
None
Description:
This use case facilitate the user to view the login details of
each user
Preconditions

Logged in as system admin
Trigger
When system admins wants to check the log in details
Typical Course
of Event
Actor action
System response
System admin view the log

in details
Displays
the
log
details of the users
Post conditions
None
Implementation
Constraints and
Specifications :
None
3.2.2. Collaboration Sub system Use case
SRS of Group 24
Page 19 of 69
03/25/15
Use case Diagram 2
3.2.2.1 Join forum use case narrative

Use case name:
Join Forum
Use case ID:
0800
SRS of Group 24
SYSTEM ANALYSIS
Page 20 of 69
03/25/15

Priority:
Medium
Source:
Use case Diagram 2
Primary
business actor:
Teaching Assistant, Temporary User, Collaborator, Student,

Lecturer.
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
Above actors can access the forum by using this use case.
this use case provide various option to the actors to deal
with the forum.
Preconditions
Internet connection is available.

Logged in as one of above Users.
Trigger
User wants to interact with other users.
Typical Course
of Event
Actor action
System response
User request to join forum
View
join
forum
options - Add Post,
Edit Post, Delete Post,
and Comment on a
Post.
Post conditions
View join forum options to the User
Implementation
Constraints and
Specifications :
None
3.2.2.1.1 Add post use case narrative
Use case name:
Add Post
Use case ID:
081
Priority:
Medium
Source:
Use case Diagram 2
SRS of Group 24
SYSTEM ANALYSIS
Page 21 of 69
03/25/15

Primary
business actor:

Lecturer.
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
User can add posts to forum. They can share ideas and ask
questions.
Preconditions

Requested to Join Forum.
Trigger
User wants to add a post to the forum.
Typical Course
of Event
Actor action
System response
Request to add a post.
View a text box to

write the post.
Write the post on the text

box and submit.
Add new post to the

forum.
Post conditions
System returns to join forum.
Implementation
Constraints and
Specifications :
None
3.2.2.1.2 Edit post use case narrative
Use case name:
Edit Post
Use case ID:
082
Priority:
Medium
Source:
Use case Diagram 2
Primary
business actor:

Lecturer.
SRS of Group 24
SYSTEM ANALYSIS
Page 22 of 69
03/25/15

Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
Users can edit post that previously added to the forum by

themselves.
Preconditions

Trigger
User wants to edit his/her previous post
Typical Course
of Event
Actor action
System response
Select the post and request

to edit.
View the post in a

Editable text box.
Edit the post and submit.
Update database.
Post conditions
Implementation
Constraints and
Specifications :
None
3.2.2.1.3 Remove post use case narrative

Use case name:
Remove Post
Use case ID:
083
Priority:
Low
Source:
Use case Diagram 2
Primary
business actor:

Lecturer.
Other
participating
actors:
None
Other
None
SRS of Group 24
Page 23 of 69
SYSTEM ANALYSIS
03/25/15

interested
stakeholders:
Description:
Above users can delete posts that previously added to the

forum by themselves.
Preconditions

Trigger
User wants to delete a post.
Typical Course
of Event
Actor action
System response
Select the post and request

to delete.
Delete post from the

forum and update
database.
Post conditions
Implementation
Constraints and
Specifications :
None
3.2.2.1.4 Comment on a post use case narrative
Use case name:
Comment on a Post
Use case ID:
084
Priority:
Medium
Source:
Use case Diagram 2
Primary
business actor:

Lecturer.
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
Users can comment on the posts that are previously added to
SRS of Group 24
Page 24 of 69
SYSTEM ANALYSIS
03/25/15

the forum by themselves or others.
Preconditions

Trigger
User open a comment on a post.
Typical Course
of Event
Actor action
System response
Select a post and request to

comment.
View a text box to

write the comment.
Write the comment on the

text box and submit.
Attach the comment under

the original post.
Post conditions
Implementation
Constraints and
Specifications :
None
3.2.2.2 View Equipment (restricted) use case narrative

Use case name:
View equipment (restricted)
SYSTEM ANALYSIS
Use case ID:
031
Priority:
High
Source:
Use case Diagram 2
Primary
business actor:

Non-Related Lecturer.
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
Above users can view the list of equipment in the lab with
access to limited details.
Preconditions

Logged in as above user.
SRS of Group 24
Page 25 of 69
03/25/15

Trigger
Click on the View Equipment tab.
Typical Course
of Event
Actor action
System response
From the list of equipment,

Select one.
View limited details of

the
selected
equipment.
Search by equipment ID
Display the limited list

of equipment details.
Post conditions
None.
Implementation
Constraints and
Specifications :
None.
3.2.2.3 Manage News use case narrative

Use case name:
Manage News
Use case ID:
110
Priority:
Medium
Source:
Use case Diagram 2
Primary
business actor:
Lab Admin
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
Lab Admin can use this use case to update the system home
page with latest news and achievements of the lab.add past
and on going research details and project details to the
public interface
Preconditions

Logged in as Lab Admin.
Trigger
Lab Admin manages news and achievements.
SRS of Group 24
Page 26 of 69
SYSTEM ANALYSIS
03/25/15

Typical Course
of Event
Actor action
System response
Request to manage news.
Facilitate admin to
manage news in the
system home page and
other public pages
Post conditions
None
Implementation
Constraints and
Specifications :
None
3.2.2.4 Make Donation use case narrative

Use case name:
Make Donation.
Use case ID:
120
Priority:
Low
Source:
Use case diagram 2
Primary
business actor:
Guest
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
Anyone who is interested about a research or a project at

electronic lab can make donations to the Lab via the UCSC
payment gateway.
Preconditions
Internet Connection available

UCSC payment gateway is up and running
Trigger
When a guest wants to donate money to a research or to a

project
Typical Course
of Event
Actor action
System response
Guest decide to donate

money and go into the
connect the user with

the UCSC payment
SRS of Group 24
Page 27 of 69
SYSTEM ANALYSIS
03/25/15

relevant page
gateway to carry out

the further payment
procedures
Post conditions
Confirmation about the donation and appreciation letter will

be sent
Implementation
Constraints and
Specifications :
None
3.2.3 Inventory Handling sub system use case
SRS of Group 24
Page 28 of 69
03/25/15
Use case Diagram 3
3.2.3.1 Maintain inventory use case narrative

Use case name:
Maintain inventory
Use case ID:
020
SRS of Group 24
Page 29 of 69
SYSTEM ANALYSIS
03/25/15

Priority:
High
Source:
Use case Diagram 3
Primary
business actor:
Lab admin
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
This will allow Lab admin to add, remove equipments and to edit
equipment details. Lab admin will also can create a wish list of
equipments and add or remove entries from that list. Simply Lab
admin can manage inventory database with this use case.
Preconditions

Logged in as Lab admin.
Trigger
Typical
Event
This use case is initiated when the Lab admin click on the manage
inventory tab.
Course
of Actor action
System response
Click on the Manage Inventory View Manage Inventory tab

tab
which has options to Add,
Remove, Edit inventory.
Post conditions
View Manage Inventory tab
Implementation
Constraints
Specifications :
None
and
3.2.3.1.1 Add equipment use case narrative

Use case name:
Add Equipment
Use case ID:
021
SRS of Group 24
Page 30 of 69
SYSTEM ANALYSIS
03/25/15

Priority:
High
Source:
Use case Diagram 3
Primary
business actor:
Lab Admin
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
This use case uses by the Lab Admin to add new equipment
to the database by submitting valid details of the new
equipment.
Preconditions

System views the Maintain Equipment tab.
A new equipment with a barcode.
Trigger
when adding a new equipment lab admin clicks on Add

Equipment
Typical Course
of Event
Actor action
System response
Submit valid details of the

new equipment and scan its
barcode. Then click Add
Generate an Inventory
ID for the new
equipment and add it
to database.
Post conditions
A message is displayed that the equipment is added

successfully.
System returns to Manage inventory tab.
Implementation
Constraints and
Specifications :
None
3.2.3.1.2 Delete equipment use case narrative
SRS of Group 24
Page 31 of 69
03/25/15

Use case name:
Delete Equipment
SYSTEM ANALYSIS
Use case ID:
022
Priority:
Low
Source:
Use case Diagram 3
Primary
business actor:
Lab Admin
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
With this use case, any equipment and its details can be
removed from the database.
Preconditions

An Equipment that is no longer in the lab.
Trigger
Lab admin wants to remove an equipment from the system,

So he/she clicks on Delete Equipment
Typical Course
of Event
Actor action
System response
Click on Delete Equipment
View a list of
equipments
in
database
all
the
Select equipment and click Delete All details of selected

equipment removed from the
database.
Post conditions
A message is displayed that the equipment is deleted

successfully.
System returns to list of all equipments.
Implementation
Constraints and
Specifications :
None
SRS of Group 24
Page 32 of 69
03/25/15

3.2.3.1.3 Update Equipment use case narrative
Use case name:
Update Equipment
Use case ID:
023
Priority:
Medium
Source:
Use case Diagram 3
Primary
actor:
business
SYSTEM ANALYSIS
Lab Admin
Other participating
actors:
None
Other
interested
stakeholders:
None
Description:
Lab Admin can modify the details of any equipment in the

database with this Use case.
Preconditions

Trigger
Typical
Event
Lab admin wants to alter equipment details and he/she clicks

on Update Equipment.
Course
of
Actor action
System response
Click on Update Equipment
View
a
list
of
all
equipments in the database
Select any equipment and

click Update
View an editable form

of equipment details.
Update details and click

Save
Check the validity and

update the database
with new details.
Post conditions
A message is displayed that the equipment is updated

successfully.
System returns to list of all equipments.
Implementation
Constraints
and
Specifications :
None
SRS of Group 24
Page 33 of 69
03/25/15

3.2.3.2 View equipment (non restricted) use case narrative
Use case name:
View equipment
restricted
non
SYSTEM ANALYSIS
Use case ID:
030
Priority:
High
Source:
Use case Diagram 3
Primary
business actor:
Lab Admin, Related Lecturer, Lab Assistant.
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
Above users can view the list of equipment in the lab with
access to full details.
Preconditions

Logged in as Lab admin, Related Lecturer or Lab assistant.
Trigger
Typical
Event
Click on the View Equipment tab.

Course
of Actor action
Post conditions
Implementation
Constraints
Specifications :
System response
From the list of equipment, Select View full details

one.
selected equipment.
of the
Search by equipment ID
list
Display the full

equipment details.
None.
None.
and
3.2.3.3. Manage Wish list use case narrative
SRS of Group 24
Page 34 of 69
03/25/15
of

Use case name:
Manage wish list
Use case ID:
040
Priority:
Medium
Source:
Use case Diagram 3
Primary
business actor:
Lab Admin
Other
participating
actors:
Related Lecturer
Other
interested
stakeholders:
None
Description:
This use case can maintain the wish list by giving options to
view the list and Add/Remove items from it.
Preconditions
SYSTEM ANALYSIS
Logged in as Lab admin or Related Lecturer.
Trigger
Lab admin or Related Lecturer want to manage wish list, so they

click on Wish List
Typical Course
of Event
Actor action
System response
Lab admin or Related

Lecturer click on Wish List
View Wish List tab

which has options to
Add/Remove
items
from it
Post conditions
None
Implementation
Constraints and
Specifications :
None
3.2.3.3.1 Add wish list Entry use case narrative

Use case name:
Add Wish list Entry
Use case ID:
041
SRS of Group 24
Page 35 of 69
SYSTEM ANALYSIS
03/25/15

Priority:
Medium
Source:
Use case Diagram 3
Primary
business actor:
Lab Admin
Other
participating
actors:
Related Lecturer
Other
interested
stakeholders:
None
Description:
By this Use case Lab Admin and Related Lecturers can add
new equipments to the wish list.
Preconditions

System displays the Wish List tab
Trigger
Lab admin or Related Lecturer wants to add a new wish list item.
Typical Course
of Event
Actor action
System response
Actor click on the New
View a form to submit details

of the new equipment.
Entry
Submit details and click

Add to List
Check for validity of the

details and add equipment to
the Wish List.
Post conditions
A message is displayed that the wish list item is added

successfully
System will return to the Wish List tab
Implementation
Constraints and
Specifications :
None
3.2.3.3.2 Remove wish list entry use case narrative

Use case name:
Remove Wish List Entry
Use case ID:
042
SRS of Group 24
Page 36 of 69
SYSTEM ANALYSIS
03/25/15

Priority:
Medium
Source:
Use case Diagram 3
Primary
business actor:
Lab Admin
Other
participating
actors:
Related Lecturer
Other
interested
stakeholders:
None
Description:
This Use case uses to delete equipments from the Wish List.
Preconditions

System displays the Wish List tab
Trigger
Lab admin or Related Lecturer wants to delete a wish list item.
Typical Course
of Event
Actor action
System response
Select an equipment from

the Wish List and click
Delete Entry
Selected equipment will be

removed from the Wish List.
Database will be updated.
Post conditions
System will return to the Wish List tab
Implementation
Constraints and
Specifications :
None
3.2.3.3.3 View Wish List narrative

Use case name:
View Wish List
Use case ID:
043
Priority:
Medium
Source:
Use case Diagram 3
Primary
business actor:
Lab Admin
SRS of Group 24
Page 37 of 69
SYSTEM ANALYSIS
03/25/15

Other
participating
actors:
Related Lecturer
Other
interested
stakeholders:
None
Description:
Lab admin and Related Lecturer can view the Wish List.
Preconditions

Trigger
Lab admin or Related Lecturer want to view wish list, so they

click on Wish List
Typical Course
of Event
Actor action
System response
Actor click on Wish List
View list of equipments of the

Wish List.
Post conditions
None
Implementation
Constraints and
Specifications :
None
3.2.3.4 Issue Equipment use case narrative

Use case name:
Issue Equipment
Use case ID:
050
Priority:
High
Source:
Use case Diagram 3
Primary
business actor:
Lab Assistant
Other
participating
actors:
None
Other
interested
stakeholders:
Undergraduate
Related Assistant
Related Lecturer
SRS of Group 24
Page 38 of 69
SYSTEM ANALYSIS
03/25/15

Temporary User
Description:
Lab Assistant can issue items to the Undergraduates, Related

Assistants, Temporary Users and Related Lecturers. All the
equipments that are issued will record in the system.
Preconditions

Logged in as Lab Assistant.
Borrower of the equipment with his ID.
Trigger
a one of above users asks to borrow an equipment.
Typical Course
of Event
Actor action
System response
Click on Issue equipment
View
Issue
Equipment tab.
Input
identification
Identify the borrower and

check whether he can
borrow equipments.
borrower
Scan equipments barcode.

Click Issue.
Post conditions
Identify
the
equipment.
Check
whether it can be
Borrowed. Then mark
it as borrowed. Update
database.
A message is displayed that an equipment is issued

successfully
System returns to Issue Equipment tab.
Implementation
Constraints and
Specifications :
None
3.2.3.4.1 Check status and Conditions use case narrative

Use case name:
SRS of Group 24
Check status and Conditions
Page 39 of 69
SYSTEM ANALYSIS
03/25/15

Use case ID:
051
Priority:
Medium
Source:
Use case Diagram 3
Primary
business actor:
Lab Assistant
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
When Issuing an equipment Lab Assistant can check it for

any damages. Or the borrower may inform that there are
some damages in the equipment they are borrowing. So this
use case will be used to update the system about the
condition of the equipment.
Preconditions

System displays the Issue Equipment tab.
Trigger
when issuing an equipment
Typical Course
of Event
Actor action
System response
scan the barcode of the

equipment to get the
condition details
Output the status and

the condition of the
equipment scanned.
Choose
whether
equipment is in
condition to issue.
Records the condition

and the status.
the
good
Post conditions
System returns to Issue Equipment tab.
Implementation
Constraints and
Specifications :
None
3.2.3.5 Return equipment use case narrative
SRS of Group 24
Page 40 of 69
03/25/15

Use case name:
Return Equipment
Use case ID:
060
Priority:
High
Source:
Use case Diagram 3
Primary
business actor:
Lab Assistant
Other
participating
actors:
None
Other
interested
stakeholders:
Undergraduate
Related Assistant
Related Lecturer
Description:
This Use case will be used when a member is returning the

borrowed equipment. Lab assistant is responsible for
checking whether the equipment returned is in good
condition and record it in to the system
Preconditions
SYSTEM ANALYSIS

Borrower of the equipment with his ID and the equipment.
Trigger
Lab Assistant click on the Return Equipment
Typical Course
of Event
Actor action
System response
click on the Return Equipment
View the Return Equipment

tab
Scan borrowers ID barcode
Identify the borrower.
Scan equipments barcode.

Click Return
Identify the equipment, Mark it

as returned. Update database.
Post conditions
System returns to Return Equipment tab.
Implementation
Constraints and
Specifications :
None
3.2.3.5.1 Report condition use case narrative
SRS of Group 24
Page 41 of 69
03/25/15

Use case name:
Report Condition
Use case ID:
061
Priority:
Medium
Source:
Use case Diagram 3
Primary
business actor:
Lab Assistant
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
Lab Assistant can report and update the condition of the item
when they returned.
Preconditions
SYSTEM ANALYSIS

Borrower of the equipment with his ID and the equipment.
Trigger
When the user returns the equipment
Typical Course
of Event
Actor action
System response
Check the condition of the

equipment and record the
details
save the record for

future references
Post conditions
A message is displayed that the equipment is successfully

returned.
Implementation
Constraints and
Specifications :
None
3.2.3.6 Generate reports use case narrative
Use case name:
Generate Reports
Use case ID:
070
SRS of Group 24
Page 42 of 69
SYSTEM ANALYSIS
03/25/15

Priority:
Medium
Source:
Use case Diagram 3
Primary
business actor:
Lab Admin
Related Lecturer
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
Lab Admin and Related Lecturer can generate various kinds

of reports about the lab.
Preconditions

Logged in as Lab Admin or Related Lecturer.
Trigger
When clicked on the generate report lab.
Typical Course
of Event
Actor action
System response
User select desired options

of equipments and click on
generate report
display the list of

equipments with the
specified attributes
Post conditions
Gives the print option to the user
Implementation
Constraints and
Specifications :
None
3.2.4 Scheduling Sub system
SRS of Group 24
Page 43 of 69
03/25/15
Use case Diagram 4
3.2.4.1 Maintain fixed schedule use case narrative

Use case name:
Maintain fixed schedule
Use case ID:
1100
Priority:
High
Source:
use case diagram 4
Primary
business actor:
Lab Admin
Other
none
SRS of Group 24
Page 44 of 69
SYSTEM ANALYSIS
03/25/15

participating
actors:
Other
interested
stakeholders:
Undergraduates
Description:
This use case is used to add new fixed schedules, remove

existing schedules and update the current schedules of the
electronic laboratory. Fixed schedules are used in the
electronic practical classes.
Preconditions

Logged in as Lab Admin
Trigger
User decides to maintain the fixed schedule, usually a

beginning of a new calendar year.
Typical Course
of Event
Actor action
System response
Receive the fixed schedule

and the lab admin makes the
changes
Give suitable facilities

to maintain the fixed
schedule through an
interactive table
Post conditions
none
Implementation
Constraints and
Specifications :
none
3.2.4.1.1 Add fixed schedule use case narrative

Use case name:
Add Fixed schedule
Use case ID:
1101
Priority:
High
Source:
Use case Diagram 4
Primary
business actor:
Lab Admin
Other
participating
actors:
none
SRS of Group 24
Page 45 of 69
SYSTEM ANALYSIS
03/25/15

Other
interested
stakeholders:
Undergraduate
Description:
The lab admin can add new fixed schedules in to the

interactive schedule table
Preconditions
Internet Connections Available

logged in as the lab Admin
Trigger
When the new schedules for the new calendar year is

received for the electronic practicals
Typical Course
of Event
Actor action
System response
Receive the new schedule

and add that to the table
Provide
necessary
facilities to add a fixed
schedule
Post conditions
A message will be displayed that a new schedule was added.
Implementation
Constraints and
Specifications :
none
3.2.4.1.2 Remove fixed schedule use case narrative

Use case name:
Remove fixed schedule
Use case ID:
1102
Priority:
Medium
Source:
Use case diagram 4
Primary
business actor:
Lab Admin
Other
participating
actors:
none
Other
interested
none
SRS of Group 24
Page 46 of 69
SYSTEM ANALYSIS
03/25/15

stakeholders:
Description:
Remove the complete fixed schedule from the schedule.
Preconditions

Logged in as the Lab admin
Trigger
when required to change the schedule at the end of a

calendar year
Typical Course
of Event
Actor action
System response
Lab admin deletes the fixed

schedule
Ask for confirmation

on delete.
Completely remove
the fixed schedule
information from the
system
Post conditions
none
Implementation
Constraints and
Specifications :
Existing fixed schedule must be there
3.2.4.1.3 Update fixed schedule use case narrative

Use case name:
Update fixed schedule
Use case ID:
1103
Priority:
Low
Source:
use case diagram
Primary
business actor:
Lab Admin
Other
participating
actors:
none
Other
interested
stakeholders:
none
Description:
Update the fixed schedule on changes to the schedule.
SRS of Group 24
Page 47 of 69
SYSTEM ANALYSIS
03/25/15

Preconditions
Internet Connection is available

Logged in as Lab admin
Trigger
When there is a change on the fixed schedule
Typical Course
of Event
Actor action
System response
Lab admin updated the

fixed schedule

Update the schedule
and
corresponding
database tables
Post conditions
none
Implementation
Constraints and
Specifications :
There must be a existing fixed scedule
3.2.4.2. Maintain dynamic schedule use case narrative

Use case name:
Maintain
Schedule
Use case ID:
1200
Priority:
High
Source:
Use case Diagram 4
Primary
business actor:
Lab Admin
Other
participating
actors:
none
Other
interested
stakeholders:
Teaching Assistant-Send Lab slot requests
Description:
Manage the reservation process of free lab slots. Allocate the

lab slots in to different user requirements such as electronic
practicals, embedded system practicals, tutorial classes etc.
Preconditions
Internet Connection Available
SRS of Group 24
Dynamic
Page 48 of 69
SYSTEM ANALYSIS
03/25/15

Trigger
when teaching assistant request a lab slot
Typical Course
of Event
Actor action
System response
Manage a Time slot
check whether
time slot is free
the
Reserve the time slot

for
the
specified
requirement
Post conditions
none
Implementation
Constraints and
Specifications :
none
3.2.4.2.1 Reserve Lab Slot use case narrative

Use case name:
Reserve Lab Slot
Use case ID:
1201
Priority:
High
Source:
Use case Diagram 4
Primary
business actor:
Lab admin
Other
participating
actors:
none
Other
interested
stakeholders:
Teaching Assistant- Request for a lab slot
Description:
The purpose of this use case is to reserve a free lab slot

according to its requirements
Preconditions

Logged in as Lab admin
SRS of Group 24
Page 49 of 69
SYSTEM ANALYSIS
03/25/15

Trigger
When a request is come informing that a free lab slot is

requiered
Typical Course
of Event
Actor action
System response
Lab Admin reserves a lab

slot
Check whether that

there are free lab slots
available
in
the
Electronic laboratory
Reserves the specified
lab slot
Post conditions
none
Implementation
Constraints and
Specifications :
none
3.2.4.2.2. Cancel Reservation of lab slots use case narrative

Use case name:
Cancel Reservation of lab

slots
Use case ID:
1202
Priority:
Medium
Source:
Use case Diagram 4
Primary
business actor:
Lab Admin
Other
participating
actors:
none
Other
interested
stakeholders:
none
Description:
The System facilitates the cancellation of lab slot reservation

any time.
Preconditions
Internet Connection Available

Logged in as Lab Admin
SRS of Group 24
Page 50 of 69
SYSTEM ANALYSIS
03/25/15

Trigger
When there is a request to cancel the reservation or when

there is a special event
Typical Course
of Event
Actor action
System response
Cancels the reservation

Delete the reservation
entry
from
the
database and make
that lab slot free again
Post conditions
Display a massage saying that the reservation is successfully

cancelled
Implementation
Constraints and
Specifications :
There must be a reserved lab slot.
3.2.4.3. Accept/Decline lab slot requests use case diagram

Use case name:
Accept/Decline
requests
Use case ID:
1300
Priority:
High
Source:
Use case Diagram 4
Primary
business actor:
Lab Admin
Other
participating
actors:
none
Other
interested
stakeholders:
Teaching assistant- Requests the lab slots
Description:
Lab admin is responsible for Accepting or Declining the lab

slot requests
Preconditions

Logged in as the Lab admin
SRS of Group 24
Lab
Page 51 of 69
slot
SYSTEM ANALYSIS
03/25/15

Trigger
When Teaching assistant make a request to reserve a lab slot
Typical Course
of Event
Actor action
Post conditions
none
Implementation
Constraints and
Specifications :
none
Lab admin Accept

decline the request
System response
or
send a notification
about the request
status whether is has
been accepted or
declined
3.2.4.4. Request Lab slots use case narrative

Use case name:
Request Lab slots
Use case ID:
1400
Priority:
High
Source:
Use case diagram 4
Primary
business actor:
Teaching Assistant
Other
participating
actors:
none
Other
interested
stakeholders:
Lab Admin- Accept or Decline the requests

Undergraduate - Inform about the free slots
Description:
Teaching assistant can request free lab slots for practical

classes or for tutorial classes.Cancellation of the requests
can also be done. Viewing the schedule is included in to this
use case.
Preconditions

Logged in as Teaching assistant
SRS of Group 24
Page 52 of 69
SYSTEM ANALYSIS
03/25/15

Trigger
when Teaching assistant is informed about a free lab slot by

an undergraduate
Typical Course
of Event
Actor action
System response
Teaching assistant request

lab slots
a
notification
is
displayed in the lab
admin panel
Post conditions
none
Implementation
Constraints and
Specifications :
none
3.2.4.4.1 Add new Request narrative

Use case name:
Add new Request
Use case ID:
1401
Priority:
High
Source:
Use case Diagram 4
Primary
business actor:
Teaching assistant
Other
participating
actors:
none
Other
interested
stakeholders:
Lab Admin- Accept or Decline the requests

Undergraduate - Inform about the free slots
Description:
Teaching assistant add new lab slot request with the purpose
Preconditions

Logged in as Teaching assistant
Trigger
When undergraduate inform about the free slot
Typical Course
of Event
Actor action
System response
Teaching assistant add new

lab slot request
The Lab admin will be

notified about the
SRS of Group 24
Page 53 of 69
SYSTEM ANALYSIS
03/25/15

request
Post conditions
none
Implementation
Constraints and
Specifications :
The lab slot can be a previously requested or a free slot

the farthest request can be done is limited to one month from
the requested date
3.2.4.4.2 Cancel Request use case narrative

Use case name:
Cancel Request
SYSTEM ANALYSIS
Use case ID:
1402
Priority:
Low
Source:
Use case diagram 4
Primary
business actor:
Teaching assistant
Other
participating
actors:
none
Other
interested
stakeholders:
Lab Admin- will be notified about the cancellation
Description:
Teaching assistant can cancel the lab slot request at any

time. the purpose of cancellation must be given
Preconditions

Logged in as the Teaching assistant
Trigger
When there is a request to cancel the reservation or when

there is a special event
Typical Course
of Event
Actor action
System response
cancel the request

Delete request entry
from the database and
remove
the
SRS of Group 24
Page 54 of 69
03/25/15

notification from the
Lab admin.
Post conditions
A massage is displayed saying that the request is cancelled

successfully
Implementation
Constraints and
Specifications :
none
3.2.4.5 Inform free slots use case narratives

Use case name:
inform Free slots
Use case ID:
1500
Priority:
High
Source:
Use case Diagram 4
Primary
business actor:
Undergraduate
Other
participating
actors:
none
Other
interested
stakeholders:
Teaching assistant - Request lab slots according to the

undergraduates information
Description:
Undergraduates can inform about their free time to the

teaching assistant so that they can reserve a lab slot thruogh
the teaching assistant
Preconditions

logged in as undergraduate
Trigger
When wanted to inform teaching assistant about their free

time to do the practicals
Typical Course
of Event
Actor action
System response
view the schedule
display the
schedule
SRS of Group 24
Page 55 of 69
SYSTEM ANALYSIS
current
03/25/15

send information about the
free time to do practicals
Post conditions
none
Implementation
Constraints and
Specifications :
none
notify the corresponding

teaching
assistant
regarding the free time
to request a lab slot for
the undergraduate
3.2.4.6 View schedule use case narrative

Use case name:
view schedule
Use case ID:
1600
Priority:
High
Source:
use case Diagram 4
Primary
business actor:
Teaching Assistant, Undergraduate
Other
participating
actors:
none
Other
interested
stakeholders:
none
Description:
View the current lab slot allocation schedule to find out the
free lab slots
Preconditions

logged in as above mentioned user
Trigger
when inform the free time slots
Typical Course
of Event
Actor action
System response
View the Schedule
Display the current lab

slot allocations
Post conditions
none
SRS of Group 24
Page 56 of 69
SYSTEM ANALYSIS
03/25/15

Implementation
Constraints and
Specifications :
only a month ahead schedules can be viewed
3.2.5 Member management use case diagram
SRS of Group 24
Page 57 of 69
03/25/15
Use case Diagram 5
3.2.5.0 Invite Graduate and collaborator to register use case narrative
SRS of Group 24
Page 58 of 69
03/25/15

Use case name:
Invite
Graduate
and
collaborator to register
SYSTEM ANALYSIS
Use case ID:
090
Priority:
High
Source:
Use Case Diagram 4
Primary
business actor:
System Admin
Other
participating
actors:
Graduate
Other
interested
stakeholders:
None
Description:
System Admin can send an invitation via an e-mail

application to Graduates and collaborator for registration.
Preconditions

Logged in as System admin
Trigger
When clicked on Invite to Register
Typical Course
of Event
Actor action
System response
Choose Invite to Register

option.
Return to Invite to
register option
collaborator
Enter
Graduates
or
collaborators name and email address.
Choose Send option.
Post conditions
Message is displayed that invitation was sent successfully
Implementation
Constraints and
Specifications :
None
3.2.5.1 Manage login use case narrative
SRS of Group 24
Page 59 of 69
03/25/15

Use case name:
Manage Login
SYSTEM ANALYSIS
Use case ID:
091
Priority:
High
Source:
Use Case Diagram 5
Primary
business actor:
System Admin
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
This will allow System Admin to Add new members and

Delete or search existing members.
Preconditions

Logged in as System admin
Trigger
When clicked on Manage Login
Typical Course
of Event
Actor action
System response
Choose Manage Log in

option.
View Manage Log

in option which has
options
to
Add,
Delete,
Search
members
Post conditions
Show Manage Log in option
Implementation
Constraints and
Specifications :
None
3.2.5.1.1 Manage login use case narrative

Use case name:
Add Members
Use case ID:
092
SRS of Group 24
Page 60 of 69
SYSTEM ANALYSIS
03/25/15

Priority:
High
Source:
Use Case Diagram 5
Primary
business actor:
System Admin
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
This use case is used by the Lab Admin to add new members
to the database by submitting valid details of the new
member.
Preconditions

Logged in as System Admin.
Trigger
when adding a new member System admin chooses Add

Member option
Typical Course
of Event
Actor action
System response
Submit valid details of the

new member. Then choose
Add option.
Creates a new user

and adds it to the
database.
Post conditions
Message is displayed that user is created successfully.
Implementation
Constraints and
Specifications :
None

Use case name:
Delete Member
Use case ID:
093
Priority:
High
Source:
Use Case Diagram 5
SRS of Group 24
Page 61 of 69
SYSTEM ANALYSIS
03/25/15

Primary
business actor:
System Admin
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
With this use case, any user and his details can be removed
from the database.
Preconditions

Trigger
when deleting an existing member, System admin chooses

Delete Member option
Typical Course
of Event
Actor action
Choose
option.
Delete
System response
User
View a list of all

members
in
the
database
Select member and choose

Delete option.
All details of selected
member is removed
from the database.
Post conditions
Message is displayed that user is deleted successfully
Implementation
Constraints and
Specifications :
None

Use case name:
Search Member
Use case ID:
094
SRS of Group 24
Page 62 of 69
SYSTEM ANALYSIS
03/25/15

Priority:
High
Source:
Use Case Diagram 5
Primary
business actor:
System Admin
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
With this use case, any user and his details can be searched
from the database.
Preconditions

Trigger
When searching for an existing member, System admin

chooses Member Member option.
Typical Course
of Event
Actor action
Choose
option
Search
System response
User
All the details of the

user is displayed
Enter members name and

choose Search option
Post conditions
None
Implementation
Constraints and
Specifications :
None
3.2.5.2 Manage login use case narrative

Use case name:
Edit profile
Use case ID:
095
Priority:
High
Source:
Use Case Diagram
SRS of Group 24
SYSTEM ANALYSIS
Page 63 of 69
03/25/15

Primary
business actor:
Admin
collaborator
Temporary user
Teaching Assistant
Lab Assistant
Lecturer
Student
Other
participating
actors:
None
Other
interested
stakeholders:
None
Description:
With this use case details of the actor can be modified.
Preconditions

Logged in as Admin, collaborator, Temporary user, Teaching
Assistant, Lab Assistant, Lecturer or Student.
Trigger
When modifying details of an existing member, Actor

chooses Edit Profile option.
Typical Course
of Event
Actor action
Choose
option.
Profile
View full details and

editable places of
profile.
Do modifications to the
existing details.
Save changes to the

database.
Choose
option.
Edit
System response
Save
Changes
Post conditions
Message is displayed that user has made changes

successfully.
Implementation
Constraints and
Specifications :
None
SRS of Group 24
Page 64 of 69
03/25/15
3.3 Performance Requirements

The number of terminals to be supported
The number of
supported
One terminal
simultaneous users to be One user
Amount and type of information to be handled
3.4 Design Constraints

Safety and Security Constraints
The system has equipment information, user information so privacy needs to be
maintained. As laboratory is expected to maintain equipment information, a database
backup and restore procedure will be implemented.
Simplicity & User Friendliness
Graphical user interfaces will be used and no command driven interfaces can be used.
3.4.1 Standards Compliance

All language used in the software (including manuals and documentation) should comply
with IEEE guidelines.
The processes use to develop this system are under the rules and regulation of UCSC.
3.5 Software System Attributes

3.5.1 Reliability
All the members must register to access the system therefore more reliable.
Limited number of users can access the system data base therefore all the details are safe.
System use to identify equipment barcode and it read using barcode reader therefore reduce the
probability input incorrect ID numbers.
3.5.2 Availability
SRS of Group 24
Page 65 of 69
03/25/15

This system is web based system. It will be established on UCSC servers therefore
anyone with an any form Internet connection can access it as long as the servers are up
and running.
The system can be offline for back up or maintenance processes with a prior notice.
However it must be available at a minimum of 98% of time
3.5.3 Security
All the users provide a password and it will be validated with required strength and
length.
The system administrator is in charge of validating users to the system when new
members requesting membership.
Unauthorized member login would prohibited by the system.
Data entering and modifications to the already entered data can only be done by the
administrators.
Only the administrators will have full access to the system .
Log on and log off history data sets for a minimum period of 3 months (audit
requirement).
3.5.4 Maintainability
System should support the maintenance. System should need to be updated with
according to the change in the information. Therefore the maintenance is highly essential.
If there are any faults in the system, administrator is responsible for recover the system
back.
3.5.5 Portability
This system, being web based, can be used in any operating system without any technical
issue.
It is hosted in UCSC servers. The whole system will be host dependent so no need of
installing extra components for the system.
PHP which is famous for portability across platforms and support for important
web technologies like Java will be used for building this system.
SRS of Group 24
Page 66 of 69
03/25/15
4. Supporting Information
Development Costs
Item
Description
Cost (Rs.)
Desktop Computer with internet

connection.
Pentium IV or higher processor

and 1GB RAM
30,000.00
Barcode system
Barcode stickers and barcode

scanner
Software
All the software are free and

open sourced
0.00
Server (hosting cost)
servers are currently available in

UCSC
0.00
System design
will be done by UCSC students
0.00
Personal training
will be done by UCSC students
0.00
Hardware & Software
8,000.00
Personnel Costs
Total cost
38,000.00
Annual operating cost

Item
Description
Cost (Rs.)
Hardware & Software

Software
No licensing since freeware
0.00
Internet
Usage of internet
0.00
Hosting
will be hosted in UCSC servers
0.00
Current staff will be used.
0.00
Personal costs
Personal Costs
Total cost
SRS of Group 24
0.00
Page 67 of 69
03/25/15
SRS of Group 24
Page 68 of 69
03/25/15

UCSC Electronic Lab Management System

Uploaded by

Document Information

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

UCSC Electronic Lab Management System

Uploaded by

Copyright:

Available Formats

University of colombo school of computing | 28/04/2015

Software Requirements Specifications Document

Information System for Electronic Laboratory at

Software Requirements Specification (SRS)

The document in this file is an annotated outline for specifying software

Software Requirements Specifications Document

Software Requirements Specification (SRS)

Software Requirements Specifications Document

Software Requirements Specifications Document

Software Requirements Specifications Document

Increase publicity and connectivity among the users.

Software Requirements Specifications Document

1.3 Definitions, Acronyms, and Abbreviations

Software Requirements Specifications

University of Colombo School of Computing

Wireless Ad-Hoc and Sensor Network

Hypertext markup language

Unified Modelling language

Cascading Style Sheet

Sustainable Computing Research

Quick response code

Software Requirements Specifications Document

2. The Overall Description

2.1 Product Perspective

Software Requirements Specifications Document

2.1.2 Hardware Interfaces

Software Requirements Specifications Document

2.2 Product Functions

When designing this system we have to focus in these main functionalities.

Users will be registered by the system admin

Users can log-in by typing their user name

Add/Remove equipment, Edit equipment

Issue equipments/ Return equipments

Request lab slot

Particular users can request a lab slot and the

Particular users can view equipments and their

Manage news and researchers.

Particular users can update/edit news features

Guest users can donate money

Software Requirements Specifications Document

2.3 User Characteristics

High (Have a good

High (Have a good

Software Requirements Specifications Document

2.5 Assumptions and Dependencies

Software Requirements Specifications Document

To identify the users

This will include None

When the new users sign

To identify the privileges

Can select only

To identify courses of the

Can select only

Address 01 Not required. No of the

Units of Relation Data

Software Requirements Specifications Document

Address 03 Not required. Name of

Not required. To give

Software Requirements Specifications Document

Relations Data formats

To reserve the lab. Mouse

Should be date None

Software Requirements Specifications Document