SDD-FinalYearProject

Software Design Description
for
Final Year Project Subject Selection
Version 1.0 unapproved
Prepared by
Alexandre Amado de Castro
University of Surrey
26 June 2013

Software Requirements Specification for Final Year Project Subject Selection Page ii
Table of Contents
1. Introduction...............................................................................................................................1
1.1 Purpose........................................................................................................................................ 1
1.2 Intended Audience and Reading Suggestions ............................................................................. 1
1.3 Scope ........................................................................................................................................... 1
1.4 Overview...................................................................................................................................... 1
2. System Overview.......................................................................................................................2
3. System Architecture..................................................................................................................3
3.1 Architecture Design..................................................................................................................... 3
Figure 1: Application’s Data Flow Diagram...................................................................................4
3.2 Decomposition Description......................................................................................................... 5
3.3 Design Rationale.......................................................................................................................... 5
4. Data Design................................................................................................................................7
4.1 Database Description .................................................................................................................. 7
5. Component Design....................................................................................................................9
5.1 Common Application Requirements........................................................................................... 9
5.2 Select Keywords .......................................................................................................................... 9
5.3 Update Keywords ...................................................................................................................... 10
5.4 Define Accessible Dates ............................................................................................................ 10
5.5 Insert/Replace Student Access List ........................................................................................... 10
5.6 Insert Student Access Permission ............................................................................................. 10
5.7 Delete Student Access Permission............................................................................................ 11
5.8 Insert/Replace Keywords List.................................................................................................... 11
5.9 Insert Keyword .......................................................................................................................... 11
5.10 Delete Keyword......................................................................................................................... 11
5.11 Generate Report........................................................................................................................ 11
5.12 Clear Process ............................................................................................................................. 12
5.13 Change Password ...................................................................................................................... 12
6. Human Interface Design .........................................................................................................13
6.1 Overview of User Interface ....................................................................................................... 13
6.2 Screen Images............................................................................................................................ 14
6.3 Screen Objects and Actions....................................................................................................... 17
7. References ...............................................................................................................................18
Revision History
Name Date Reason For Changes Version
Alexandre Castro 26/06/2013 First Draft 1.0

Software Design Description for Final Year Project Subject Selection Page 1
1. Introduction
1.1 Purpose
The purpose of this Software Design Description (SDD) is to describe the architecture and system design of
a web application which will be used to provide an easy interface for students from the Final Year to
choose their final year project subjects. This SSD implements all of the designs concerns stated as software
requirements in the SRS [1].
1.2 Intended Audience and Reading Suggestions
This document is intended for further developers to improve the system and for understanding the
functionality of the present system.
The reader can begin with the overview sections and proceeding through the sections that are most
pertinent.
1.3 Scope
This SDD describes the development of a web application where the students from the final year, using
their university login, can select up to five keywords related to the subject for their preferred final year
project and receive visual information of the overall ranking of keywords in order to permit a conscious
choice.
The application will also provide an administrator panel, where reports, students and keywords inclusion
and exclusion will be provided.
The benefit of this application is to students being able to select the keywords by their own, and predict
the chance of being chosen for each of their selected keywords.
1.4 Overview
Firstly an overview of the system is presented in order to provide context and to aid understanding of the
design.
In the section 3 the system architecture description is provided, followed by the data, components and
human interface designs.

2. System Overview
This SDD describes the implementation for a web application which will be used to provide the students an
easy environment for selection their final year project subjects through keywords selection.
Today the students don't receive enough information regarding this process, this information is important
in order to provide a better context so the students can take a concise choice of the subject of their
preference.
In this application keywords where selected instead of the subject title, this provide an easier
understanding and a wider selection for each keyword.
While this application will provide the interface for the students it also will provide some required
administrative tools such as reports and inclusion/exclusion of keywords and students access definition.
In order to provide the reports and keeping the information provided by the students to the administrator
a database will be provided.
The application is target for web environment, since this could be accessed by any devices, such as
personal computers, notebooks, tablets and mobile phones. The application will use PHP, JavaScript,
jQuery, HTML, CSS and MySQL database in a Linux environment in order to deliver all the requirements.

3. System Architecture
3.1 Architecture Design
The interface of the web application will be implemented using HTML for the structure, jQuery for visual
information, such as the student chart, and fields validation and CSS for deploying the design features,
while for the files processing, database interactions and login will be implemented using PHP. The database
will be implemented using MySQL. All these elements will be implemented in a Linux server and will use
the University of Surrey internet provider.
Figure 1 show to overall architecture of the design elements. A deployable application will consist of the
required input features by the administrator to provide the necessary information in order to the
application continue with the keywords selection process, a student interface for the student’s users be
able to select their keywords, a report generator to provide the students keywords selection data back to
the administrator and report users, a login with the capability identifying the type of user and guarantee
the right access to each one and a clean process in order to clear the database and provide a fresh start
each time the application must be used. This information will be storage within a MySQL database in order
to provide data integrity and security.
For the students view a chart will be supplied to best provide the keywords data. In the administration
tools the input/replace students access list and keywords list will accept comma-separated values or
character-separated values (CSV) files in order to do the processing and validation for inserting the data in
the database. The reports generated by the generate report feature will be provided in the same type of
file, providing a standard type of file to be process in the application.

Figure 1: Application’s Data Flow Diagram.

3.2 Decomposition Description
The functions demonstrated in the Figure 1 can be divided in features as exposed in Figure 2.
Figure 2: Functions decomposed in application features.
In the Figure 2 the functions are enumerated and positioned in the necessary order of processing for the
application function properly.
Firstly the necessary data must be inserted in the application database, and then the students can select
their keywords, in the end of the keywords data range selection a report can be generated using the data
inserted by the administrator during the input data function and by the students in the select keywords
function. Finally the clean process can be placed for providing a fresh start the next time the application is
required for use.
3.3 Design Rationale
The SRS [1] defines nine features that must be provided by the application: 1) Select keywords, 2) Update
keywords selection, 3) Define Accessible dates, 4) Insert/Replace Student Access List, 5) Insert Student

Access Permission, 6) Delete Student Access Permission, 7) Insert/Replace keywords list, 8) Generate
Reports and 9) Clear Process. Moreover the login must also be provided.
The web was chosen as platform for the application because it can provide major accessibility and sustain
the security standards, since all the devices with internet access will be able to access the application
(mobile phones, tablets, notebooks, laptops and personal computers) and the data will remain secure in
the University of Surrey database.
Moreover the web satisfy the background services without depreciating the application performance, the
reports can be generated, the students and keywords can be inserted or deleted from the database
without impacting the performance of the web application for the students. The performance does not
depend of the user device, it will depend of the internet connection but the major process will be provided
directly by the server without any major impact in the connection anyhow.
The data will be stored within the University of Surrey server in a MySQL database. This is an important
requirement since the student’s data and the administrator and report users login and password cannot be
accessed by anyone except the administrator.
The University of Surrey server was limited to Linux, because of that MySQL and PHP were chosen. A
Microsoft platform (ASP.NET, C# and Windows Server) was suggested but refused because of lack of
licenses for this particular application.

4. Data Design
4.1 Database Description
Figure 3: Database structure.
The biggest amount of data is in the students table (ad_students) and in the keywords table
(ad_keywords). The dates table (ad_dates) and administrator table (ad_administrator) storage a small
amount of data and this do not change often like the other two tables.

Both, student and keywords, tables are of common importance of the functionality of the application,
losing one makes the other useless.
The student table provide all the data of each student with has the right to access the application, the login
will use this information to guarantee the access before matching the password with the University of
Surrey student database. Moreover this table storage the student selection, one selection in each provided
field, and the selection is represented by the ID of the keyword. That is the why if the keyword table is
accidentally dropped the choices would be useless since is impossible to have sure if the new table will
have the same ID's. Once the choices are inserted in the database it also receive a Date data, this is the
date and time of the last change in each student choices.
The keywords table is composed by the ID, keyword, number of tutors and students which already have
selected it keyword. This last feature will be updated using PHP and AJAX at the end of the selection
keywords feature process.
The date table provide only an ID, start and end dates. The ID is provided only in order to be easier to
manipulate the data within the database in case for future implementations more than one date range
must be provided.
The administrator table contains an ID, administrator login and password and report user login and
password. The ID is provided only in order to be easier to manipulate the data within the database in case
for future implementations more than one set of administrator and report users became necessary.
The only fields which can be instantiated null are the date fields and the student’s selection fields.

5. Component Design
5.1 Common Application Requirements
Requirements: IL3, IL4, IL5, IL6, IL7, IL8, IL9, IL25, IL30, IL39, IL40, IL46, IL49, IL59, IL65, IL69, IL 74, IL 76
The administration tools will only be available for the administrator user, this will be provided by the
application using a simples system of login and password.
The application will provide a different screen for each type for user, it will first verify if it is an
administrator or report user login, since these are in the local database, and after validate if the student
match with any student in the local student data table in order to verify if the student have the right to
access the application and then if the login and password match with the ones provided by the University
of Surrey students database. This verification will use PHP in order to provide the communication with the
database.
The access to the University of Surrey student database will provide to the application by passing the login
and password of the student directly to the University of Surrey database and receiving back the
confirmation and the student data in order to know which student have logged in.
The provision of errors, either for miss login or for not having the right to access the application, will be
provided using PHP.
A timer will be implemented using PHP and JavaScript, if the application goes idle for more than five
minutes it wills self-logoff.
5.2 Select Keywords
Requirements: IL11, IL13, IL15, IL16, IL17, IL18, IL19, IL20
This view will be only available to the student’s users, the list of keywords represented in the chart will be
retrieved directly from the database together with the number of tutor and the number of students which
have already selected each keyword for each keyword and then inserted in a Array and this will be
provided to the jQuery chart to be composed.
The drop down lists will use the same array in order to provide the selection for the students. Once the
student select a keyword in one of the drop down lists this keyword will be hidden from the others using
jQuery functionality.
Once the update button is pressed the keywords will be inserted in the database in the other of selection,
each drop down list has it respective field in the database. Moreover the date and time of the insert will
also be stored in the database and then displayed for the user by the left side of the update button.
JQuery validation functionality will be implemented in order to obligate the user to select all the five drop
down lists before update.

AJAX functionality will be provided for refreshing the chart after the update without the necessity of
refreshing the web page.
5.3 Update Keywords
Requirements: IL22, IL23, IL24
The application will retrieve the keyword selection from the database and update the selection in the drop
down lists, the same applies for the last update status by the left side of the update button.
During the pre-defined student’s access dates the student’s users will be able to access the application and
change their keywords as much as wanted, every time it is updated the old information is deleted and
replaced by the new one.
5.4 Define Accessible Dates
Before entering in the application the following validations will be executed: verify if it is an administrator
or report users, verify if the data range is already defined, verify if the application is already within the
defined and then verify if the student users input the right combination of login and password with the
University of Surrey database.
If the user isn’t an administrator or report user, the application will verify the data range, if it is already
defined or if the application is within the data range, neither is false then a pop up error will be provided to
the user with the necessary information.
5.5 Insert/Replace Student Access List
Requirements: IL32, IL33, IL34, IL35, IL36, IL37, IL38
The file input field will be validated using jQuery in order to accept only comma-separated values or
character-separated values (CSV) files, and proving the error if necessary. The file will also be validated
using a jQuery library (jquery-csv) and later inserted in the database using PHP.
For cleaning up the database before the data replacement the database will be truncated, this will provide
a fresh restart by dropping every data in the students table in the MySQL database.
5.6 Insert Student Access Permission
The text fields will be validated using jQuery in order to accept the required type of data, and proving the
error if necessary. After validation the data will be inserted in the database using PHP.

5.7 Delete Student Access Permission
Requirements: IL47, IL48
PHP will be used to provide the drop down list with the student’s information and deleting it from the
database.
5.8 Insert/Replace Keywords List
Requirements: IL51, IL53, IL54, IL55, IL56, IL57
The file input field will be validated using jQuery in order to accept only comma-separated values or
character-separated values (CSV) files, and proving the error if necessary. The file will also be validated
using a jQuery library (jquery-csv) and later inserted in the database using PHP. The data field regarding the
number of students which have already selected each keyword is initialized with the value 0 (zero).
For cleaning up the database before the data replacement the database will be truncated, this will provide
a fresh restart by dropping every data in the students table in the MySQL database.
5.9 Insert Keyword
The text fields will be validated using jQuery in order to accept the required type of data, and proving the
error if necessary. After validation the data will be inserted in the database using PHP.
5.10 Delete Keyword
PHP will be used to provide the drop down list with the keywords information and deleting it from the
database.
Before deleting it from the database it will reassure if the keyword haven’t been selected by any student, if
it has been the application will provide an error and update the drop down list.
5.11 Generate Report
The reports will be provided in a single page application with all the backend code provided using PHP. The
data will be retrieved directly from the MySQL database and saved in a CSV file.

5.12 Clear Process
Requirements: IL75
The clear process is a simple truncate command provided to the MySQL database using PHP.
A validation with a check box will be provided in order to verify the intention of the user, the validation if
the check box is checked and the provision of the error if it not will use jQuery.
5.13 Change Password
Requirements: IL78, IL79
The change password feature will be provided inside a Lightbox feature using JavaScript.
The comparison between the fields in order verify the correct typing of the password will be provided
using jQuery, the same for the error if the fields do not match. After the validation the data will be inserted
in the database using PHP.

6. Human Interface Design
6.1 Overview of User Interface
This application will have three different types of user. Independent of the type of user the first screen
provided is the login screen. The login screen is composed by a login field, a password field, a submit
button and a chart proving visual information about how many students has already selected they
keywords.
The Student user will login using the University of Surrey login, but they can only access the application
during a defined data range provided by the administrator.
Once logged in the application will provide a list of the keywords with the number of tutors for each
keywords in parenthesis by the side of the keyword, a visual information (bar chart) with the number of
students that has already selected each keyword, five drop down lists numbered from one to five, these
will be the keyword selection boxes for the users, a update button, for finishing the keywords selection and
a logout button.
This is a minimalist interface. It aims to provide an easy and intuitive environment for the students be able
to select their keywords swiftly.
Moreover the second time the same student login in the application the previous keyword selection will be
provided, and a data and time from the last update will be placed by the side of the update button.
The administrator user will have access to the administration tools of the system, but will not have access
to the student’s environment.
The administration tools will be separated by three different types of tabs:
The preparation tab will be composed of all the features which need to be fulfilled before the student’s
user can access the application. These features are: define date, input students list and input keywords list.
The modification tab will be composed by the features which can be used, if necessary, during the time in
which the student’s users have access to the application. These features are: delete student, insert
student, delete keyword and insert keyword.
The reports tab will be composed of only one feature the generate report feature, this feature is a part
because the report user will have only access to it.
And the clean tab composed by the clean process feature, this feature is separated since if it is used
wrongly or by mistake it will be very destructive for the process, as it intend to be.
More over the administrator panel has a logout and a change password buttons. The change password
button provides a pop up with two fields for each user, the administrator and report users. The fields can
be used to change the password of each user.
Finally the report user will have access only to the generate report feature in the reports tab.

The main principle is to provide a clean, easy and friendly application for every user to can use it as quickly
as possible making the performance of the application to be enchanted, not by hardware, but by the high
possibility of having a low number of users using it at the same time.
6.2 Screen Images
Figure 4: Login screen.
Figure 5: Student user interface.

Figure 6: Administrator Panel – Preparation Tab
Figure 7: Administrator Panel – Modification Tab

Figure 8: Administrator Panel – Reports Tab
Figure 9: Administrator Panel – Clean Tab
Figure 10: Administrator Panel – Change Password pop up

6.3 Screen Objects and Actions
This application aims to have an easy and friendly interface, but it is also required fulfil the requirements
stated in the SRS [1].
The login screen fulfil the interface requirement IL3, providing the same login page for every user.
The student user interface fulfil the requirements IL10, IL12, IL14, IL15, IL18, IL23, providing an interface
with the keywords listed in the chart, after each keyword there is the number of tutors between
parenthesis and a bar representing the number of students which already have selected each keyword. For
the student selection is also provided the five drop down lists with their preference identified by a number
on the left side of each drop down list. Finally an update button and the date and time of the last update
are provided in the bottom right corner of the interface.
The administrator panel fulfil the requirements: IL26, IL31 and IL50 in the preparation tab; IL41, IL47, IL60,
IL66 in the modification tab; IL69 in the reports tab and IL77 in the change password pop up.
The preparation tab provide the required data fields in order to provide the range of dates in which the
students will have the right to access the application and both file input fields for the students and
keywords lists.
The modification tab provide the required text fields for inputting the student information or the keyword
information and both drop down lists composed with the information of all the students or all the
keywords to be deleted from the database.
The reports tab provides the drop down list with all the reports that the application can generate with the
information stored in the database.
The clean tab doesn’t have any interface requirement, in this interface a checkbox was provided in order to
guarantee the intention of cleaning the database.
The change password pop up provide the required text fields for inputting the new password, and
verification, for both users.

7. References
[1] Alexandre Castro, "Software Requirements Specification for Final Year Project Subject Selection,"
University of Surrey, Guildford, SRS Document 2013.

SDD-FinalYearProject

More Related Content

What's hot

Similar to SDD-FinalYearProject

SDD-FinalYearProject