Nokkis

Software requirements document

1. Introduction

Physical access control to events, such as conferences, workshops and concerts, is logistically a time-consuming task. This project implements a system for access control, based on 2D-bar codes. The basic idea is that the customer gets access to an event and gets a access-granting 2D-bar code. The printed document with the bar code can then at the physical access control site, be checked with a standard laptop and webcam.

The software will have to have a client- and a server-part. The server will have to handle the database-requests and the creating of the ticket, which includes the creating of the unique barcode. The client are responsible of reading the barcode and sending the information to the server. The client then discards or accepts the ticket, depending on the answer from the server.

The software is designed primarily to be a ticket system and will not include customer handling. How a customer buys or pays a ticket is irrelevant to the system design. However the system will be implemented in such a fashion that adding user or customer handling functions later on is possible.

The software requirements document describes all the requirements the software meets. These are divided into user requirements, system requirements and system architecture design. User requirements describe what needs to be done with the software. System requirements answer to the same questions on technical level. System architecture describes the hardware environment where the software is going to be used. Besides these requirements this document clarifies the system life span.

2. Glossary

  • 2D-barcode - a 2-dimentional QR (quick response) code
  • Client (in the scape of this project) - a computer equipped with a web-camera running a software reading 2D-barcodes and associating recognized codes to tickets payed in advance.
  • Server (in the scape of this project) - a computer storing user registrations and ticket data. A backend for client queries.

3. Use cases

  • Add an event
    • Admin of the system should be able to add an event to the database, with the necessary information
  • Modify an event
    • Admin of the system should be able to modify event information.
  • Create a ticket
    • An organizer for the event can create tickets for a given event.
    • Server will send the ticket as pdf's into customers e-mail.
  • "Use" a ticket at the event place
    • When a costumer arrives at the ticket-checking-place, he/she will need to have the bar code printed on a paper. An organizer can check the ticket by holding it up to a web cam on a computer that is running the ticket-checking-program.
  • Combine an event to a client
    • At the event place the client-software has to be combined to an event

4. User requirements

  • Several events (festivals, conventions) are in a need of a ticket system
  • Tickets are based on 2D-barcodes
  • Tickets should be printed on paper and be presented at the entrance of the event
  • Checking the tickets at the entrance should be fast
    • Example: During Ropecon opening 1000 visitors / hour = 4 seconds / visitor
  • Checking the tickets at the entrance should be reliable
    • The system should work also without internet connection
  • Checking the ticket at the entrance should be easy
    • Showing the ticket to the web-camera and immediate feedback is required
  • Ticket system has to be able to link a 2D-barcode into a given event
  • Ticket system has to be secure
    • Not possible to forge or fake tickets easily (e.g. protection using SHA or other encryption method)
  • Ticket system shouldn't allow re-using the same ticket

5. System architecture

  • Client-Sever architecture
    • Client
      • Barcode scanner
      • GUI
      • Network layer
        • HTTP
    • Server
      • Database
      • Event creation UI
      • Network layer
        • HTTP

6. System requirements

  • Client has to work on a computer and a web-camera
  • Client has to run on Linux
    • If client works also on Windows and OSX, all the better - however this is not mandatory
  • Client has to be able to read the barcode from a ticket and give the feedback (access granted/denied) in X seconds.
    • From the user's point-of-view, the procedure has to be easy (automatic?) in order to be fast.
  • Client has to be able to work also without network connection.
    • The lack of network connection shouldn't make the access procedure any slower.
  • Client has to be able to exchange information with the server as often as possible in order to prevent the same ticket being used at several entrances.
  • Barcodes have to be unique and complex enough to make faking tickets
    impossible.
  • The system has to support several clients (entrances) for one event.
  • Client-server communication has to be secure and reliable.
  • Server has to support several events.
  • Server has to support following features:
    • Adding an event
    • Modifyin an event
    • Creating a ticket to a specific event
    • Marking a ticket used

7. System models

A typical workflow for managing events and tickets has following steps:

  1. Admin creates a new event, sets the event data, date and maximum tickets
  2. (Outside the system) User buys / pays a ticket
  3. System receives a request for creating a ticket together with user data
  4. System sends a ticket to user in e-mail

The system model presented in a data flow diagram:

8. System lifespan

There's no plans to develop the application further after it's completition. However the source code and documentation will be handed out to make sure future development is possible.

The API between the client and server is in this release simple, but designed at the same time so that it can be expanded, if the requirements for the ticket system are increased. Both the client and server are designed so that they should scale also for events that exceed the requirements in the original design.

9. Appendices


Attachments:
dataflow.png (image/png)