Software Requirements Specification

For Mobile Clicker

Version 1.12

Prepared by

Ahmad Al-Toukhy
Amir Ahmed
Ahmad Ashkanani

Kuwait University
College of Engineering and Petroleum
Computer Engineering Department

Date created 8-May-08

 Table of Contents
1. Introduction 1
1.1 Purpose 1
1.2 Scope 1
1.3 Definitions, Acronyms and Abbreviations 1
1.4 References 1
1.5 Overview 1

2. Overall Description 1

3. Specific Requirements 3
3.1 Functionality 3
3.2 Usability 10
3.3 Reliability 10
3.4 Performance 11
3.5 Security 11
3.6 Safety 11
3.7 Design Constraints 11

3.8 Copyright and intellectual properties 12

4. Supporting Information 13
 Software Requirements Specification
1. Introduction
1.1 Purpose
This document will fully describe all the functional and nonfunctional requirements, design constraints,
and other factors necessary to provide a complete and comprehensive description of the requirements
for the Mobile Clicker Project. It will also describe the external behavior of the Mobile Clicker
Application.

1.2 Scope
The Mobile Clicker Application is a two-part project. The first part is a Java-based PC application that
is used by the instructor to take the attendance of the students registered in the class by discovering
their Bluetooth mobile devices. It is also used in asking any type of questions for the whole class like
surveys. The second part is a Java-based mobile application that is used by the student to answer the
question or the survey that the instructor may spread using the PC application.

1.3 Definitions, Acronyms and Abbreviations

Bluetooth: It is a wireless protocol utilizing short-range communications technology facilitating both
voice and data transmissions over short distances.
MTBF: Mean Time Between Failures
MTTR: Mean Time To Repair
Sustainability: Expected lifetime of the system

1.4 References
1- SRS template, 2008-05-10, Computer Engineering department, Kuwait University.

1.5 Overview
The rest of this document contains the following in the mentioned order:
1- Overall description of the project and its requirements.
2- Specific requirements for the project including the functionality, usability, reliability, performance,
security, safety, design constraints, and copy right and intellectual properties.
3- Supporting information in order to understand the project including diagrams that represent the
system.

2. Overall Description
This product is used mostly in Universities to provide some kind of interaction between the instructor
and the student. The product would be responsible for taking the attendance and store it in an
embedded database using the Bluetooth device of the instructor’s laptop. It requires the students to
activate the Bluetooth feature on their mobile devices.

The product has a lot of benefits including:

1- Saving the time needed to take the attendance manually by calling the names of the students.
2- Asking a question or giving surveys to all the students in the class and providing the instructor
with the statistical result of the students’ answers.

The product has a social risk, which is that the students may have the ability to chat and share files,
images, videos, and sound clips since they will have to open their Bluetooth devices of their mobile
phones. This may affect their understanding of the material and their concentration with the instructor.

The users of the product are the instructor and the student. The instructor should have a laptop and
should have the basic skills to deal with it, open programs, open, and close the Bluetooth device of his
laptop.

The student should have a mobile with a Bluetooth device in it. He should have the ability to use his

1
 mobile, install programs, open and close the Bluetooth device of his mobile. The product may be used
in every lecture by the instructor and the student.

Since the system has two main functions, the following two block diagrams interprets every function of
the them.

1- Block diagram for the attendance feature using Bluetooth device discovery:

Mobile clicker
application
10 M

Figure 1

2- Block diagram for sending and receiving data between the laptop and the mobile:

Mobile Clicker
application Sending data to mobile device

Retrieving data from mobile device

Figure 2

2
3. Specific Requirements
3.1 Functionality

3.1.1 Taking Attendance

A. Description and Priority

This feature is considered as one of the main benefits that Mobile Clicker system provides. It is a high
priority feature and it is implemented in a way that it can either be automated or manually taken care
of. In the automatic mode the system will take care of monitoring the attendance process by checking
the mobile phones within the Bluetooth device range. In the manual mode the instructor is capable of
adding any student to the attendance list manually and without using any Bluetooth resources.

B. Stimulus/Response Sequences

For Automatic mode, the user should press Start button in the main screen of the laptop application.
Then a Bluetooth discovery agent will look for nearby devices and register any student within the
range. For Manual mode, the instructor should press the Manual button and choose the student’s name,
from the students list, and his status (tardy, absent or present).

State Machine:

Idle Press “Start” Button in the attendance panel Automatic Mode

Press “Stop” Button in the attendance panel

Press “Manual” Button in the attendance panel

Manual Mode
Students are chosen and “Add to list” button is pressed

Figure 3: State Machine Diagram

Dataflow diagram:

Updated attendance data Database

Attendance
information
Laptop User Managing Attendance data
Attendance

Absence/Tardy Target mobile

count

Figure 4: Dataflow Diagram

C. Functional Requirements
 In order for the automatic mode to work, a compatible Bluetooth interface must be
installed on both the laptop and the mobile phone.
 Preconditions: The Bluetooth device must be turned ON in both the laptop and the

3
 mobile phone. The mobile phone Bluetooth address should be provided on the
laptop before using the automatic mode.
 Postcondition: The attendance list is updated with the latest student names and their
status whether it is absent, tardy, or present and saved in the database.

3.1.2 Sending Questions / Receiving Responses

A. Description and Priority

This feature provides the instructor with more control over the class in terms of measuring the
understandability of the students. It’s considered as a high priority feature. A grade could be assigned
for the correct answer to each question and the student's “Grade” will be updated according to his
response.
B. Stimulus/Response Sequences

The instructor types the question in the “Question Text Area” and then he could either provide a
timeout for collecting the responses from the students or keep the time indefinite until he presses
“Stop” manually. In the first case, the instructor presses the “Send” button and then waits for certain
period of time determined by the timeout he provided. Then after the timeout elapses, a statistical graph
will show the results on a pie chart. The difference in the second case lies in the lack of a timeout.
Instead of providing a timeout, the instructor will control the process and decide when to stop receiving
responses from the students. If the question was provided with a grade, the system will update the
student’s record with the new grade according to whether the student answered correctly or not.

State Machine:

Awaiting
Press “Send” Button [Timeout exists] Question
Press “Send” Button [No timeout]

Waiting for Press “OK” Await manual

timeout to finish “Stop” event

Timeout expired Displaying Press “Stop” Button

statistics

[Question has a grade]

Saving Students
Grades

Figure 5: State Machine Diagram

4
 Dataflow Diagram:
Database
Students’ scores
Formatted answers
[Statistical Data]
Laptop User Receive
Answers
Answers

Questions
Send Question Target mobile

Formatted questions
[Bluetooth Message]

Figure 6: Dataflow Diagram

C. Functional Requirements
 The question will be sent to the students currently registered in the attendance list.
 Preconditions: The Bluetooth device must be turned ON in both the laptop and the
mobile phone. In order for the student’s response to be counted for, the student
must respond before the timeout or before the instructor presses the “Stop” button.
 Postconditions: A statistical model is drawn on the main screen with the responses
for the question. The student grade will be updated if the question was provided with
a grade.

3.1.3 Edit Students information

A. Description and Priority

Using this feature, the instructor will be able to create, edit, or delete students’ data. It is considered as
a medium priority feature.
B. Stimulus/Response Sequences

To create a new student data, the instructor will press “New” button under the “Student Panel”. When
he presses the new button, a message will appear asking the instructor to input the number of student
records he wants to create. After that a table with three columns will show up. A unique “Student ID”
field will be inputted in the first column to identify the student. The second column contains a field for
the student’s name. The third column contains a field for storing the student’s mobile phone Bluetooth
address. After inputting all the data, the instructor will press “Add Students” button to save the new
records in the database.

For updating or deleting student information, the instructor will press “Update” button under the
student’s panel. A new panel containing all the students in the class will show up and the instructor will
be able to modify any student information. After finishing the update process the instructor will press
the “Save Changes” button to save the updated records in the database. If the instructor wishes to delete
a student’s record he must highlight the student name and press the delete button.

5
 State Machine:

Idle
Press “New” Button Press “Update” Button

Inputting Update Student Data Appearance of

Student’s Data Students Panel

Press “Save Changes”

Button Press “Delete” button

Press “Add Student” button

Delete Student’s
data from the
database

Saving Student’s
data in database

Figure 7: State Machine Diagram

Dataflow Diagram:
Database
Students’ data

Students’ data
Laptop User Add Student

Students’ data
Student’s data

Update Student
data Student ID
Student ID

Delete Student

C. Functional Requirements
Figure 8: Dataflow Diagram

 The student data will be updated in the database.

 Preconditions: For updating student information, or deleting a student from the
database, the student record must be available at the database. For creating a new
student, the provided student id must be unique and valid.
 Postconditions: The database will either contain a new record or have an old record
be update or deleted.

6
 3.1.4 Edit Course information

A. Description and Priority

Using this feature, the instructor will be able to create or delete a course from the database. It is
considered as a medium priority feature.

B. Stimulus/Response Sequences

To create a new course data, the instructor will press “New Course” button under the “Startup Screen”.
When he presses the button a form will appear asking the instructor to input the course information.
After inputting all the data, the instructor will press “Add Course” button to save the new record in the
database.

For deleting a course, the instructor will press “Delete” button under the startup screen panel. The
course will be deleted from the database.

State Machine:

Idle
Press “New Course” Button Press “Delete” button

Inputting Course Delete Course

OK
Data data from the
database

Press “Add Course” button

Saving Course
data in database

Figure 9: State Machine Diagram

Dataflow Diagram:
Database
Course data

Course selection
Laptop User Add Course

Course ID
Course selection Delete Course

7
 Figure 10: Dataflow Diagram

C. Functional Requirements
 The course data will be saved in the database.
 Preconditions: For deleting a course from the database, the course record must be
available at the database. For creating a new course, the provided course id must be
unique.
 Postconditions: The database will either contain a new record or have an old
recorded been updated.

3.1.5 View Score and Attendance Records

A. Description and Priority

Using this feature the student will be able to receive his attendance and score records on his mobile
phone. It’s considered as a low priority feature.

B. Stimulus/Response Sequences

The student will open the mobile application and wait for the records data to be received from the
laptop.

State Machine:

Awaiting state

Data received from laptop

Data is printed on
mobile screen

Figure 11: State Machine Diagram

Dataflow Diagram:

Student information
Laptop Send Bluetooth message Mobile phone
Attendance and
Score records
Attendance records

Database Figure 12: Dataflow Diagram

8
 C. Functional Requirements
 In order for this feature to work, a compatible Bluetooth interface must be installed
on both the laptop and the mobile phone.
 Preconditions: The Bluetooth device must be turned ON on both the laptop and the
mobile phone.
 Postcondition: The mobile phone receives and prints the attendance and score
records on the mobile phone screen.

3.1.6 Send/Receive Text data

A. Description and Priority

Using this feature the instructor will be able to send a question to the student and the student will be
able receive it from the laptop using his mobile phone. This feature is considered as a high priority
feature.

B. Stimulus/Response Sequences

When the “sending question” feature is used by the instructor, the laptop will call this feature. Upon
calling it, the laptop will start a Bluetooth connection with the mobile phone and start sending the data.
When the student responds, the mobile phone will send back the response using another Bluetooth
connection.

State Machine:

Idle
Implicit call made by the laptop
Finished receiving the response

Send text data to Receiving

mobile response from
mobile

Finished sending the data

Implicit call from mobile phone

to send the response
Waiting for a
response from
mobile

Figure 13: State Machine Diagram

9
 Dataflow Diagram:

Bluetooth message Mobile phone

Text data
Laptop Send Text data

Text data
Bluetooth message Receive text
data

Figure 14: Dataflow Diagram

C. Functional Requirements
 In order for this feature to work, a compatible Bluetooth interface must be installed
on both the laptop and the mobile phone.
 Preconditions: The Bluetooth device must be turned ON on both the laptop and the
mobile phone.
 Postcondition: Both the mobile phone and the laptop receive text data.

3.2 Usability

 The system’s interface is user-friendly and easy to get familiar with.

 It is recommended that users read the product’s manual in order to understand all
features and to use the full power of the system.
 Training wise, any user with who is familiar with a PC should be able to use the system
with maximum training of 1 hour.

3.3 Reliability

 Availability: 99.99 %.
 Average hours of use: 3 hours per week.
 Mean Time Between Failures (MTBF): 30 days.
 Mean Time To Repair (MTTR): 1 hour.
 Accuracy: 100%.

o The system shall accurately calculate the score of any student (mobile user).

o The system shall not mistake or swap the scores of one student (mobile user)
with another.
 Bugs:

10
  Critical:
 Complete loss of data.
 Significant:
 System failure.

3.4 Performance

 Response time for a transaction - average: 250 milliseconds, maximum: 2 seconds.

A transaction involves sending one question or receiving one response.
 Throughput – an average of 4 transactions per second.
 Capacity – the system can communicate with 100 students’ mobiles at the same time.
 Degradation mode - If the system is degraded when we exceed 100 students, we will
remain in the normal mode of operation with longer response time.

3.5 Security
The following is a list of security requirements that indicate how the system shall protect itself
and its sensitive data and communications from accidental, malicious, or unauthorized
access, use, modification, or destruction.
 The system shall not allow Bluetooth addresses of unauthorized Bluetooth devices to be
stored into the system’s repository.

 The system shall not permit unauthorized Bluetooth devices to access or participate in
any activity started by the server (laptop) user.

 The system shall not allow confidential data stored in the system’s database to be
accessed, whether directly or indirectly, by client (mobile) users.

 The system shall force the laptop user to confirm any data deletion to prevent any
accidental erasure of sensitive data.

3.6 Safety
The following is a list of the safety requirements to indicate how the system shall prevent any
possible threat to human lives.
 The system’s Bluetooth technology shall not cause any side-effects or physical harm
(directly or indirectly) to users of the system.

3.7 Design Constraints

This section will indicate the design constraints that apply on the system being developed and
that shall be adhered to during the development phase of the project.
 Programming languages: The server program that resides on the laptop shall be
written in Java using the Standard Edition (SE v1.5) development kit. The client
program that resides on the mobile shall be written in Java using the Micro Edition
(ME) development kit.
 Database: Apache Derby (v10.3.2.1) shall be used as the system’s database
management system. The database shall be stored on the server.
 Development tools: The Eclipse 3.2 IDE and the NetBeans 6.0 IDE shall be used as
the primary development tools to build the server and client programs.

11
  Components and class libraries: The library “derby.jar” shall be used as a driver for
the server-to-database connection. The library “chart.jar” shall be used as an external
component to generate the statistical pie chart that is viewed by the server. The
library “bluecove 2.0.2” shall be used to allow the server program to access the
Bluetooth stack and connect to clients through Bluetooth connections.
 Energy consumption: For most laptops, the average voltage required for operation
ranges from 18V to 24V, and the average current required for operation ranges from
1.5A to 3.5A, thus leading to an average power consumption of 55.5 Watts. The
energy used by the mobile phones is drawn from battery power, so assuming that the
energy consumed by the phone during one lecture is approximately ¼ of full battery
power (with Bluetooth activated) then the average power required by the phone is 1.8
Watts (current: 350mA~400mA, voltage: 3.5V~5.5V). Therefore, for a class of 40
students and one instructor, the total average power consumed in one lecture is:
PW = (55.5) + (40)*(1.8) = 127.5 Watts
 Operating environment temperature and humidity: The system shall be functional in
both indoor and outdoor environments, even though the system will mostly be used in
interior classrooms under optimum temperatures (20~25°C) and humidity (30~40%).
 Standards: The server program shall be able to work under Windows XP, Windows
Vista, Linux, and the Mac OSX operating systems. The server requires that the Java
1.5 (or above) Runtime Environment be installed on the laptop. The laptop hardware
specifications must meet the minimum requirements of 1.0 GHz CPU speed, 256 MB
of RAM, and at least 10 MB of hard disk space for database storage. The client
program shall be able to function on all mobile phones that have the Java Runtime
Environment installed.
 Legal Constraints: The only authority that must approve the installation of the system
is the services department of the educational organization (or any equivalent
division).
 Economic: There is a cost of about $350 per class for the laptop, and a cost of about
$100 per mobile for each student. The system will be released as open source
software, therefore there is no profit.
 Sustainability: The system is expected to live for at 10 least years or until a new
version is released to replace it.

3.8 Copyright and intellectual properties

This software will be considered as open-source software and protected under GPL (GNU
General Public License). It can be redistributed and/or modified under the terms of the GNU
General Public License as published by the Free Software Foundation; either version 2 of the
License, or any later version.

12
4. Supporting Information
4.1 Use Case diagram for the Laptop User

User

Sending questions/
receiving responses

Edit course
information

Taking
Edit student attendance
information

Figure 16: Use Case Diagram for the laptop user

4.2 Use Case diagram for the Mobile User

13
 User

Send/Receive View score and

text data attendance record

Figure 17: Use Case Diagram for the mobile user

4.3 State Transition Diagram

14
 Run application

Clicked “Delete” Clicked “New”

Display course list
Deleting course Adding new course

OK OK

Clicked “Exit” Clicked “Exit”

Clicked Clicked
“Select”[Bluetooth OFF] “Select”[Bluetooth ON]

entry/ Display main screen

entry/ Display main screen
do/ Enable attendance and start
do/ Disable attendance Bluetooth Activated
device discovery

Bluetooth off Bluetooth on

Checking
A
Bluetooth status
Clicked
“Remove”
Clicked
Clicked
“Remove”
“Update”

Clicked
“Manual” Clicked
“Manual”
Clicked
“Update” Click “Start”

Remove student Manually attend Add/Modify Write question/

from the list students students Click “Send”

Select
Student
student to
added
add Adding nearby Sending question
mobiles to list to all mobiles
Adding to student Finish task

Finish task list

Answers arrived from all OK
nearby mobiles
Finish task
Finish task
Compute
statistics on
received answers
A and display chart

Figure 18: State Transition Diagram

15
4.4 Data Flow Diagram

Discovered address
Add student to list of mobile
Attendance Target Mobile

Tardy/Absence Send score and

Formatted
record attendance record
Questions

List of students in course Stored address of

mobile
Updated student records
New student data Database

New course data Course to delete

Add new course Delete course

New Student Course
Information selection

Add new student Modify students’

information
New student
Information Student
selection
Manual Attendance Send question
to all mobiles
Add Student
student selection Answers
to list
Remove student Receive data
Questions from mobiles

Remove Student
student selection
from list

Laptop User
Formatted answers

Figure 19: The Data Flow Diagram

16