University of Edinburgh

_______________________________________________________________________________________________________

Stage: Systems Analysis and Design

System Design Specification

Open Days & Tours Migration

[PROGRAMME NAME]
[PROJECT CODE]
[ANNUAL PLAN NUMBER]

Document Version: 0.2

Date: 07/03/2013
___________________________________________________________________________________
Information Services - Template Revised March 2011

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

Contents
1
1.1
1.2

DOCUMENT MANAGEMENT...................................................................3
Contributors.....................................................................................................3
Version Control.................................................................................................3

OVERVIEW................................................................................................4

DEVELOPMENT TOOLS AND STANDARDS..........................................5

3.1
3.2

Development Tools...........................................................................................5
Development Standards...................................................................................5

SYSTEM PROCESSES.............................................................................6

USER INTERFACE....................................................................................7

5.1
Transactional Interface....................................................................................7
5.1.1 MyEd Interface.............................................................................................15
5.2
6
6.1
6.2
6.3
7
7.1
7.2
7.3
7.4

Reporting Interface........................................................................................16
APPLICATION SECURITY......................................................................17
Authentication................................................................................................17
Authorisation..................................................................................................17
Business Objects.............................................................................................17
DATABASE DESIGN...............................................................................18
PG....................................................................................................................18
Tours................................................................................................................19
UG....................................................................................................................19
Users................................................................................................................20

APPLICATION INTERFACES.................................................................21

DATA........................................................................................................22

9.1
9.2

Data Migration...............................................................................................22
Archiving Policy.............................................................................................22

10

IMPLEMENTATION..............................................................................23

___________________________________________________________________________________
Page 2 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

1 Document Management
When completing this document, please mark any section that is not required as
N/A. A brief description of why the section is not required should also be included.

1.1 Contributors
Please provide details of all contributors to this document.
Role
Systems Analyst
Designer
(Owner)
Business Analyst
Project Manager
Project Sponsor
Business Area
Manager
Other document
contributors

Unit
IS Apps

Name
Ross Nicoll

1.2 Version Control

Please document all changes made to this document since initial distribution.
Date

Version

Author

Section

Amendment

___________________________________________________________________________________
Page 3 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

2 OVERVIEW
Please provide a general overview of the system design so that anyone reading this
section is able to gain an understanding of what functionality is provided and how
this functionality will be technically implemented.
Applicants and potential applicants can book tours and open days (split into UG and
PG open days) in which to visit the university.
The landing page for the tours is http://www.ed.ac.uk/about/campus/tours/student-led
and bookings are taken at http://www.ed.ac.uk/about/campus/tours/student-toursbooking
UG/PG open days are not currently bookable, but would normally be linked from
http://www.ed.ac.uk/studying/undergraduate/visiting/open-days /
http://www.ed.ac.uk/studying/postgraduate/open-day/on-campus-open-day/intro
respectively.
The current booking forms submit to PHP scripts currently located on the server
praline, which is to be decomissioned imminently. As such, they urgently require
migration to a new hosting environment.
There are also security issues with the current implementation not correctly protecting
against SQL injection and XSS attacks.
This project is to migrate the booking systems and their administration interface (also
on praline) to the LAMP stack provided by IS, and to fix its security issues.

___________________________________________________________________________________
Page 4 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

3 DEVELOPMENT TOOLS AND STANDARDS

3.1 Development Tools
Specify which technologies will be used to develop the application, eg Oracle 9i, Cold Fusion MX,
Oracle Forms, Business Objects, Java, PL/SQL etc.

Application is written in PHP 4 and is to be migrated to PHP 5.3. No specific IDE or

tools are required, although MySQL Workbench may be useful for database
management.

3.2 Development Standards

Tick the appropriate box to indicate the standards being followed for this application:
Standard

indicates compliance

Database Design
Cold Fusion
Java
Uportal Development
Accessibility
Web Style Standards
Supported Web Browsers

Note that interface is to match existing interface as closely as possible, and this may impact compliance
with accessibilty and web style.

___________________________________________________________________________________
Page 5 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

4 SYSTEM PROCESSES
Take each process specified in the Business Requirements Document (BRD) and state how it will be
implemented technically (please make reference to the corresponding paragraph number in the BRD).
Where applicable, a specification of each screen which makes up a process should be provided (ie a
screenshot and descriptions of every data item displayed).
A resource estimate should be provided for each process.
All paragraphs should be numbered to assist cross referencing in testing stages.

Please note that the order of this starts with the most difficult and/or infrastructure
changes first, and works towards tasks that are easier and/or can re-use existing work,
and accordingly time estimates for later stages are lower.
1. Database is to be brought in-line with design standards (1 day minimum, 1.5
days likely, 2 days worst case):
a. Transition all tables to an ACID-compliant database engine (InnoDB)
b. Change column types to better fit the content (for example replace
TEXT with VARCHAR types where content is a character string of
constrained length).
c. Add foreign key constraints to enforce data integrity.
d. Replace subject columns (on application table) with a separate table
that lists subjects per application.
e. Merge application, application11, application10, etc. tables
together. d) is a pre-requisite for this as the tables are currently
incompatible due to changes in subjects over time. It should be noted
that there is significant complexity in doing this as tables require reindexing during merging.
f. Move data that needs to be changed over time (for example tours
available, countries, subjects) from hard-coded values into the database
for future maintainability.
2. Replace tours booking interface with a Yii-based version (1.5 days minimum,
2 days likely, 3 days worst case) as fastest route to migrating it to a security,
maintable infrastructure.
3. Replace tours admin interface with a Yii-based version (1.5 days minimum,
2.5 days likely, 3 days worst case).
4. Add user management tools (copied from previous work, resource usage under
an hour).
5. Add role-based access controls (0.5 day minimum, 1 day likely, 1.5 day worst
case):
a. Add database tables for roles and roles associated with a user.
b. Modify User model to be able to understand these roles and check
for their presence.
c. Modify user edit/add functions to allow granting of roles to users.
6. Add new tour editing tools (1 days minimum, 1.5 days likely, 2 days worst
case).
7. Replace UG open day booking interface with Yii-based version. This can reuse much of the work from step 2 and accordingly estimates are lower: 0.5
days minimum, 1 day likely, 2 days worst case.
___________________________________________________________________________________
Page 6 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

8. Replace UG open day admin interface with Yii-based version (1.5 days
minimum, 2.0 days likely, 3 days worst case).
9. Add UG open day editing tools based on tour editing tools (0.5 days
minimum, 0.5 days likely, 1.5 days worst case).
10. Replace PG open day booking interface with Yii-based version (0.5 days
minimum, 0.5 days likely, 1.5 days worst case).
11. Replace PG open day admin interface with Yii-based version (1 day minimum,
1.5 days likely, 2 days worst case); note this includes adding in statistical
summary pages.
12. Add PG open day editing tools based on tour editing tools (0.5 days minimum,
0.5 days likely, 1.5 days worst case).

___________________________________________________________________________________
Page 7 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

5 USER INTERFACE
5.1 Transactional Interface
Use this section to link to an application prototype built by a Designer. The screens should be built in
conjunction with the business partner.
If this section is not applicable then please state why.

The booking interfaces should closely match the existing interfaces as much as
possible. The student-led tours booking page is shown below as an example:

The administration interface will be broken down into the following sections:
PG open days
Student-led tours
UG open days
Users
___________________________________________________________________________________
Page 8 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

5.2 Bookings
For open day and tour bookings, there will be options to:

Show bookings on tours that are in the future (see Figure 1)

Show bookings on tours that are in the past (see Figure 1)
Export future bookings to a spreadsheet-compatible format (CSV, TSV or
Excel)
Update a booking (see Figure 3)
Create a new booking on behalf of a prospective student (see Figure 2)
Delete a booking for a tour in the future (see Figure 4)
Show summary statistics of bookings split by calendar year (see Figure 5)

Figure 1: Listing of bookings

___________________________________________________________________________________
Page 9 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

Figure 2: Adding a booking

Figure 3: Updating a booking

___________________________________________________________________________________
Page 10 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

Figure 4: Deleting a booking

Figure 5: Booking statistics

5.3 Tours
For the tours and open days, there will be options to:
___________________________________________________________________________________
Page 11 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

Show all future tours (Figure 6)

Update a future tour (Figure 7)
Add a new future tour (Figure 8)
Delete a future tour (Figure 9)
Show an individual tour (future or past) and bookings against it (Figure 10)

Figure 6: List of tours

___________________________________________________________________________________
Page 12 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

Figure 7: Update a tour

Figure 8: Add new tour

___________________________________________________________________________________
Page 13 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

Figure 9: Delete tour

Figure 10: View a tour (read-only)

5.4 Users
For users there will be views for:
Showing all users (see Figure 11)
___________________________________________________________________________________
Page 14 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

Updating a user (see Figure 13)

Creating a new user (see Figure 12)
Deleting a user (see Figure 14)

Figure 11: Listing of users

Figure 12: Add user

___________________________________________________________________________________
Page 15 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

Figure 13: Update user

Figure 14: Delete user

5.4.1 MyEd Interface

Where a MyEd channel is being used to deliver some or all of the transactional interface, complete the
following template (one per channel) and link each completed template to this document. The
___________________________________________________________________________________
Page 16 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

information in this template will form the basis of the channel publishing information used in MyEd
when building channels.

Channel Publishing Template

There is no MyEd interface.

5.5 Reporting Interface

Where applicable, please state how reporting is to be delivered, eg Webi, HTML.
The design of any pre-written reports should be specified, and if Webi is to be used, the Universe
should be defined (ie classes/measures/dimensions and source data).

There is an included breakdown of bookings group by day and broken down into
applicants and extras, however there is no substantial reporting interface.

___________________________________________________________________________________
Page 17 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

6 APPLICATION SECURITY
This section relates to application rather than physical security which is covered in the Technical
Architecture Document (TAD).

6.1 Authentication
Authentication is handled by EASE.

6.2 Authorisation
Include application, menu and page authorisation and any application roles.

The application will maintain its own list of users who are allowed to access it. Each
user will have one or more roles from the following list:
Administrator (can access all areas and manage users)
PG read (can read PG open day data but not edit)
PG write (can read/write PG open day data)
Tour read
Tour write
UG read
UG write
Each section of the user interface (PG bookings, tour bookings, UG bookings and
users) will be hidden unless the user has the relevant role to access that section.

6.3 Business Objects

Include any specific object/row authorisation.

___________________________________________________________________________________
Page 18 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

7 DATABASE DESIGN
Insert an Entity-Relationship Diagram of the system. If new tables have been added to an existing
system then highlight these in your ER Diagram (full diagram of existing system not needed).
Full specifications should be provided for all new tables/views/columns in the system (ie name,
datatype, mandatory, default values, constraints).

E-R diagrams are split into four individual diagrams for clarity:

7.1 PG
Two tables are used, containing the booking details for an applicant, and a list of open
days that are available to book:

___________________________________________________________________________________
Page 19 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

7.2 Tours
The tour_booking table contains bookings made, and tour contains tours that can
be booked. The opaquely named tour_flag field on tour is represented in the
existing user interface as Active? and contains a Y/N value.
country and stage provide suggested values for person_country and
person_stage fields on tour_booking, but historical data in tour_booking mean
they cannot be used for foreign key constraints.

7.3 UG
UG open day bookings are similar structurally to PG bookings, however with addition
of a list of subjects of interest to the applicant. The available subjects are stored in the
subject table (with an in_use flag as some values are no longer applicable) and
mapped to bookings via ug_booking_subject.

___________________________________________________________________________________
Page 20 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

7.4 Users
The users tables contain a list of valid roles (role), and a user_role table to map
users to zero or more roles:

___________________________________________________________________________________
Page 21 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

8 APPLICATION INTERFACES
Provide technical details of any inputs to the system from other applications and any outputs from the
system to other applications. Full data specifications should be included. Identify possible impact on
existing processes.

The application does not interact directly with any other applications. An export
function as tab-separated values is provided for importing into Excel or similar.

___________________________________________________________________________________
Page 22 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

9 DATA
9.1 Data Migration
Include any mappings between existing systems and the new system

Data is to be migrated from praline as part of the implementation. Scripts will be

provided to do the migration, however of note is that the process includes merging
several incompatible tables (bookings are split into individual academic year tables in
the database). The UG booking tables (previously application, application11,
application10, etc.) in particular contained a very large number of rows, one for
each subject that an applicant could be intersested in.
The migration scripts produce a separate subject table to contain a list of possible
values, and a ug_booking_subject table to handle the association. This is also
significantly easier for generating statistics (as results can be grouped by subject
rather than having to query each subject individually).
Merging of tables has also required re-indexing of the data (as primary keys were not
unique across multiple tables); UUIDs were generated as temporary identifiers for
each row during migration. This particularly applies to the tour bookings tables
(previously person and person_old) where there was significant overlap in the
data.

9.2 Archiving Policy

No data archival is to be done.

___________________________________________________________________________________
Page 23 of 24

Systems Analysis & Design: System Design Specification

[Version: x.x]

[Project Name]

_______________________________________________________________________________________________________

10 IMPLEMENTATION
Specify any implementation issues that should be considered when creating an implementation plan at
the Build stage.

The migration process is unusually complex due to merging multiple tables, and early
independent testing of the database migration process is suggested. Its also worth
noting that two previously independent databases are to be merged as part of
migration.
Implementation should otherwise follow a relatively standard pattern for Yii-based
PHP applications.

___________________________________________________________________________________
Page 24 of 24