Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
QR Marks the Spot
Requirements Definition
Version 1.0
Page 1
Doc. No.:
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
Revision History
Date
2009-10-01
Version
0.01
Description
Initial Draft
Author
Rebeka Belavić
Page 2
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
Table of Contents
1.
2.
3.
Introduction
4
1.1
1.2
1.3
1.4
Purpose of this document
Intended Audience
Scope
Definitions and acronyms
1.4.1 Definitions
1.4.2 Acronyms and abbreviations
1.5
References
4
4
4
4
4
4
5
Requirements Description
5
2.1
2.2
2.3
2.4
2.5
2.6
5
5
6
6
7
7
Use Case Models
3.1
4.
5.
Introduction
General requirements
Game preferences
Database requirements
Web services requirements
Web site requirements
Use case Web Site
3.1.1 Use case “Sign up”
3.1.2 Use case “Read general information”
3.1.3 Use case “Sign in”
3.1.4 Use case “Select a game”
3.1.5 Use case “Join a game”
3.1.6 Use case “Update game status”
3.1.7 Use case “Leave a game”
3.1.8 Use case “Communicate with other players”
3.1.9 Use case “Modify or deactivate account”
3.1.10 Use case “Sign out”
3.1.11 Use case “Create a game”
3.1.12 Use case “Invite users to play a game”
3.1.13 Use case “Modify or delete a game”
8
8
8
9
9
9
10
10
11
11
12
12
12
13
13
Requirements Definition
14
4.1
4.2
4.3
14
14
14
15
Requirement Group Definitions
Requirement Sources
Requirements definitions
4.3.1 Change Log
Future Development
16
5.1
5.2
5.3
16
16
16
General Overview
Specific group 1
Specific group 2
Page 3
Project Name
Requirements Definition
1.
Version:
1.0
Date: 2009-10-01
Introduction
1.1 Purpose of this document
This document will provide the list of various requirements for QR Marks the Spot project. The requirement
definition will illustrate the main, general and specific requirements of the project.
The document will give the general and detailed overview of the project and its product.
1.2 Intended Audience
This document contains the list of requirements which can be used by:

Team members

Project leader / Team leader

Steering group

Customer.
1.3 Scope
This document describes the project requirements for QR Marks the Spot project. It contains general system
requirements, a list of specific requirements for each part of the system (database, web site, web services) , a list
of game requirements, a list of scenarios described with use case model and requirement definition.
1.4 Definitions and acronyms
1.4.1
Definitions
Keyword
QR
1.4.2
Definitions
Quick Response
Acronyms and abbreviations
Acronym or
abbreviation
MVC
PM
Definitions
Model View Controller
Personal Message
Page 4
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
1.5 References
2.
Requirements Description
2.1 Introduction
The goal of this project is to create a game based on QR codes. QR codes are two-dimensional barcodes and can
be used as a marker for both location marking and item tracking, thanks to their distinguishable and easily
notable features. Software capable of scanning 2D bar-codes is available for every mobile phone platform,
which makes it possible for anybody who owns a mobile phone to participate.
User has to have the option to play and create a game via Web site. A system that will allow the user to do that
will be developed with the MVC design architecture:
 web site as a user-friendly interface for communicating with the system,
 database where all the relevant data will be stored,
 web services which will connect these two (database and web site).
2.2 General requirements
In this section, general requirements will be explained. They are roughly divided in 3 parts:
 Model: The database will store all the relevant data concerning the users (players), games (game info,
game creator etc.), locations of QR codes and any other relevant information.
 View: Web site should be created to make the game accessible world-wide and to provide a userfriendly interface for communicating with the system, but also with other players. It also enables the
user to have different roles, whether as a simple player of the game, or as the creator of the game.
Different APIs like Google Maps, Facebook and Twitter will be used to help participants play the game
 Controller: Web Services will provide some of the most important system functionalities. They will
process the data exchanged between the database and the web site (see Figure 1).
Figure 1: MVC architecture of the system
Web service retrieves the data from a database (3) and displays it for the user on the Web Site (4). After the user
changes the data (1), the web service stores the updates in the database (2).
Page 5
Project Name
Requirements Definition
2.3
Version:
1.0
Date: 2009-10-01
Game preferences
Since the goal of this project is to create a game based on the QR codes, a set of game rules needs to be defined.
These rules will be presented to the user when creating a new game on the web site. The following game
preferences will be available to the user:
 Game types


Treasure hunt
“Classic“ treasure hunt
- Treasure hunt with riddles
- The solution is the next location
- The solution unlocks the next location on the web site

Race
Game visibility

Private game (invitation only)

Public game
o
o
Limited number of players
Unlimited number of players

Game style
Time unlimited
Time limited
o
Start and end times defined
o
Maximum time between joining the game and finishing is defined

Number of possible winners
Single/Multiple winners

Additional options:
Standalone game
Series of games (game is part of a bigger game)
Game can also be inactive (in design – if the creator doesn’t want to activate it immediately) or active (finished,
playable).
There are going to be 2 different types of the QR code games supported by the system – treasure hunt and race and each one will have a number of variations. The main difference between these 2 games is: in the race game,
the player is given all the locations of the QR codes while in the treasure hunt game, the player is given one by
one location.
Creator of the game can define a content of the QR code (i.e., riddle, location, code number). The content is
translated into QR code by using QR code generator.
2.4 Database requirements
The technology we’ll use for creating the database is MySQL.
The database will serve as a central location for storing all the information concerning:
 User: personal information, games he is playing and his game status in the game (i.e., at which point in
the specific game he is at, which games he has created, his personal messages (PM)), his game level
based on gaming experience (i.e., the number of finished games)
 Game: game information (name, description, creator), various game preferences, game statistics (i.e.,
most popular games), QR code locations for each game
The database will be accessed by web services. In order to enable this communication, Hibernate will be used.
Hibernate is an object-relational mapping library for Java language which provides a framework for mapping an
Page 6
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
object-oriented domain model to a traditional relational database.
2.5 Web services requirements
Web services will process the data exchanged between the web site and the database and provide the
basic system functionalities. Web services will be related to:
 User
 Storing the data about the user when the user signs up
 Retrieving the data about the user from the database
 Checking whether the user exists in the database and process user credentials when
the user signs in
 Updating user information
 Deactivating the user
 Game
 Storing the data about the game (game preferences) when the game is created
 Retrieving the data about the games (general information)
 Retrieving the data about specific game that a specific user is playing (i.e., user’s
game status in this game)
 Updating the status of the game for specific user
 Inviting other players to play a game
 Changing game preferences
 Deactivating the game
 Search
 By user
 By location
 By game
 By various game preferences
 Etc.
2.6 Web site requirements
Technologies used for designing the web sites are: XHTMLs, CSS, JavaScript, PHP and APIs.
Required Web site features are:
 making the created QR code games accessible world-wide
 registering new users
 creating new games
 playing games which includes updating game status
 communication between the players
 providing help and useful information to the users
Page 7
Project Name
Requirements Definition
3.
Version:
1.0
Date: 2009-10-01
Use Case Models
3.1 Use case model – Web site
Figure 2. Web site use case scenario
3.1.1
Use case “Sign up”
Initiator:
Visitor
Goal:
Page 8
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
To register the visitor within the system
Main Scenario:
1. Visitor opens the home page
2. Visitor selects the “Sign up” option
3. A sign up form is displayed
4. After filling in the form, visitor clicks the “Submit” button
5. Submitted data is sent to the appropriate web service
6. Web service stores the data in the database
Extensions:
4. Requirement field empty
Resume at 3.
3.1.2
Use case “Read general information”
Initiator:
Visitor, User, Creator
Goal:
To find out some information the user is interested in
Main Scenario:
1. Visitor opens the home page
2. Visitor selects “Community” / ”Support” in the main menu
3. A community / support page is opened
3.1.3
Use case “Sign in”
Initiator:
User, Creator
Goal:
To authenticate the user
Main Scenario:
1. User opens the home page
2. User enters his credentials (username, password) in the required fields
3. Entered credentials are being checked by the web service
4. Web service checks whether the user exists in the system
5. Web service checks whether the entered credentials are correct
6. User is signed in
Extensions:
4. User does not exist in the system or entered credentials are incorrect
Resume at 2
3.1.4
Use case “Select a game”
Initiator:
User
Goal:
To select a desired game
Page 9
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
Main Scenario:
1. User opens the page containing a list of games by selecting the “Games” option in
the main menu
2. User chooses the desired game from the list
3. Web service retrieves all the information about selected game from the database
4. Retrieved information is displayed to the user
3.1.5
Use case “Join a game”
Initiator:
User
Goal:
To join a specific game
Main Scenario:
1. After retrieving the information about a game (see 3.1.4) the user is given the
option to join the game
2. User clicks the join button
3. Web service processes the request and retrieves the location of the QR codes for
this specific game
4. A location or a list of locations depending on the game type (hunt or race) is
displayed
3.1.6
Use case “Update game status”
Initiator:
User
Goal:
To update game status and get the next location or finish the game
Main Scenario:
1. User selects the “Games” option in the main menu
2. User selects the “My game” option in the main menu
3. Web service retrieves a list of games the user is currently playing
4. The list is displayed to the user
5. User selects the game he wishes to update
6. Web service retrieves the user’s game status for the selected game
7. Current status is displayed to the user
8. User enters the required field for updating the status (i.e., a code, a solution to the
riddle, a list of locations etc.) and clicks submit button
9. Web service checks if the input is correct (does the user’s input match the expected
values for this game)
10. If the input is correct, the next stage of the game is unlocked and the web service
returns the information about the next stage
10. The information about the next stage is displayed to the user (i.e., the location of
the next QR code the user must find, notification if the game is finished)
Extensions:
8. User’s input is incorrect
Resume at 7
Page 10
Project Name
Requirements Definition
3.1.7
Version:
1.0
Date: 2009-10-01
Use case “Leave a game”
Initiator:
User
Goal:
To leave a game
Main Scenario:
1. User selects the “Games” option in the main menu
2. User selects the “My game” option
3. Web service retrieves a list of games the user is currently playing
4. The list is displayed to the user
5. User selects the game he wishes to update
6. Web service retrieves the user’s game status for the selected game
7. Current status is displayed to the user
8. User selects the “Leave this game” button
9. Web service processes the request and stores the changes in the database
10. A message of leaving the game is displayed to the user
3.1.8
Use case “Communicate with other players” #1
Initiator:
User
Goal:
To communicate with other users via private messages
Main Scenario:
1. User selects the “Inbox” option in the main menu
2. Web service retrieves the messages for the user
3. Messages are displayed to the user
4. User selects the “Compose” or “Reply” options
5. The form for new message is displayed
6. The user writes the message and clicks the “Send” button
7. Web service stores the message in the database in the table which contains
messages for users
8. A “Message sent” message is displayed to the user
9. Recipient opens a received message (step 2)
Extensions:
7. Wrong or unknown recipient
Resume at 5
3.1.9
Use case “Communicate with other players” #2
Initiator:
User
Goal:
To communicate with other players about games via comments
Main Scenario:
1. User selects the “Games” option in the main menu
Page 11
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
2. User selects the “My games” option
3. Web service retrieves a list of games the user is currently playing
4. The list is displayed to the user
5. User selects the game he wishes to comment on
6. Web service retrieves the information for the selected game and the list of
previous comments
5. The list of comments for specific game and a form for new comment are displayed
6. The user writes the comment and clicks the “Send” button
7. Web service stores the comment in the database in the table which contains user
comments for specific game
3.1.10 Use case “Modify or deactivate account”
Initiator:
User
Goal:
To change the information in the user’s profile or deactivate the profile
Main Scenario:
1. User selects the “My profile” option in the main menu
2. Web service retrieves his profile information
3. Profile is displayed to the user
4. User changes the values he wishes to update and clicks “Save changes” button
5. Web service stores the updates in the database
6. If the user clicks the “Deactivate account” button on the “My profile” page
7. User is asked to enter his credentials (username, password) in the required fields
8. Web service checks whether the entered credentials are correct,
9. Web service stores the update in the database
10. User is given the instructions about reactivating the account
Extensions:
8. User credentials are incorrect
Resume at 7.
3.1.11 Use case “Sign out”
Initiator:
User, Creator
Goal:
To sign out of the system
Main Scenario:
1. User selects the “Sign out” option in the main menu
2. User is signed out
3. Home page is displayed
3.1.12 Use case “Create a game”
Initiator:
Page 12
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
Creator
Goal:
To create a new game based on QR codes
Main Scenario:
1. Creator selects “Games” option in the main menu
2. Creator selects the “Create new game” option
3. Game creation form is displayed
4. Creator selects the desired game preferences from the offered set of rules
5. Creator selects the locations for the QR codes and their order
6. Creator enters the content of each QR code
7. Creator clicks “Create game” button
8. Web service stores the game information, preferences, QR code locations and
contents in the database
9. Appropriate QR codes are generated using the code generator and displayed to
the user
10. The option to save generated codes in a pdf file format is displayed
Extensions:
7. Requirement field empty
Resume at 3.
3.1.13 Use case “Invite users to play a game”
Initiator:
Creator
Goal:
To invite a specific user to the game
Main Scenario:
1. Creator selects “Games” option in the main menu
2. Creator selects the “My games” option
3. Web service retrieves the list of games the user has created, all the information
about them
4. Creator selects the desired game
5. Creator selects “Invite player” option
6. Form for inviting new players is displayed
7. Creator fills the form and clicks “Invite” button
8. Web service stores the invitation in the database (table which contains messages
for users)
Extensions:
8. Requirement field empty
Resume at 6.
8. Unknown recipient
Resume at 6.
3.1.14 Use case “Modify or delete a game”
Initiator:
Creator
Goal:
To change the game preferences or delete the game
Page 13
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
Main Scenario:
1. Creator selects “Games” option in the main menu
2. Creator selects the “My games” option
3. Web service retrieves the list of games the user has created, all the information
about them
4. Creator selects the desired game
5. Information about the game (general information and game preferences) is
displayed to the user
4. User changes the values he wishes to update and clicks “Save changes” button
5. Web service stores the updates in the database
6. If the user clicks the “Delete game” button, he is asked to enter his credentials
(username, password) in the required fields
8. Web service checks whether the entered credentials are correct,
9. Web service stores the update in the database
Extensions:
6. User credentials are incorrect
Resume at 6.
4.
Requirements Definition
4.1 Requirement Group Definitions
Identification
DB
WS
WSC
G
Requirement Group
Rem.
Database
Web site
Web services
Game
4.2 Requirement Sources
Source
Description
Rem.
Customer (Marin Orlić)
Required as a consequence of system design (contractor’s
requirement)
Developer’s suggestion
Ctm
Sys
Ds
4.3 Requirements definitions
Identity
Sta
tus
Prio
rity
Description
Source
Games
Page 14
Project Name
Requirements Definition
G-1
G-2
G-3
G-4
G-5
G-6
I
I
I
I
I
I
1
1
1
1
1
1
DB-1
DB-2
I
I
I
1
1
DB-3
1
I
DB-4
WSC-1
WSC-2
WSC-2.1
WSC-2.2
WSC-2.3
WSC-3
I
I
I
I
I
I
I
WSC-4
I
WS-1
I
WS-2
I
WS-3
WS-4
I
I
WS-6
I
WS-7
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Version:
1.0
Date: 2009-10-01
QR codes should be used in the game
The game should take place in the real world
Multiple game types should be supported
Games should be user-created
QR code readers on mobile phones should be used in the game
Needed GPRS use should be kept at a minimum
Database
The database should be normalized
The database itself should be free
All data regarding players, games, locations and any other aspect
of user interaction with the system should be stored in the
database
A persistence API should be used for mapping the RDBMS to
objects (Hibernate)
Web services
Web services should be described using WSDL
Web services should process all user information and requests
At least one web service for processing all user related requests
At least one web service for processing all games related
requests
At least one web service for processing all search related
requests
Only web services can access the database
Web service should provide the infrastructure needed for user
authentication
Web site
The game should have a web site to make it accessible
worldwide
Participants should be able to communicate using the game’s
web site
Various existing APIs should be used (GogleMaps, Facebook
etc.)
Web site should provide the visitors with the option to “Sign up”
The users should have the ability to play games or create their
own
Web site should provide an intuitive interface for creating new
games
Ctm
Ctm
Ds
Ctm
Ctm
Ctm
Sys
Sys
Sys
Sys
Sys
Sys
Sys
Sys
Sys
Sys
Sys
Ctm
Ctm
Ctm
Sys
Ctm
Ds
Requirement status:
I = initial (this requirement has been identified at the beginning of the project),
D = dropped (this requirement has been deleted from the requirement definitions),
H = on hold (decision to be implemented or dropped will be made later),
A = additional (this requirement was introduced during the project course).
4.3.1
Change Log
Identity
Acti
on
Date
Comments
Page 15
Project Name
Requirements Definition
Version:
1.0
Date: 2009-10-01
Requirement status:
D = dropped (this requirement has been deleted from the requirement definitions),
H = on hold (decision to be implemented or dropped will be made later),
A = added (this requirement was introduced during the project course).
R = resurrected (dropped or on hold requirement was reactivated)
5.
Future Development
5.1 General Overview
5.2 Specific group 1
5.3 Specific group 2
Page 16