Practical Journal - Methodology SSUET/QR/114

REV# 00. Rev Date 01-11-07

Sir Syed University of Engineering & Technology, Karachi.

Computer Engineering Department

Practical Journal Methodology

Practical #10

B)Software Requirements
Specification
for

Continuing Education Program(CEP)

Nida Akbar
Suleman Shahab

October 12, 2010

2009-CE-096 1
 3.2. External Interface Requirements
3.2.1 User Interfaces.
The user interfaces are divided into two major components.
One part includes the user accessing the system using a cell phone or handheld. And the
other portion includes the user accessing the system using a PC.

All pages of the system are following a consistent theme and clear structure. The
occurrence of errors should be minimized through the use of checkboxes, radio buttons
and scroll down in order to reduce the amount of text input from user.
JavaScript implement in HTML in order to provide a Data Check before submission.
HTML Tables to display information to give a clear structure that easy to understand by
user. Error message should be located beside the error input which clearly highlight and
tell user how to solve it. If system error, it should provide the contact methods,
Each level of user will have its own interface and privilege to mange and modify the
project information such as supervisor able to monitor/manage his student progress and
make comment on it, student can change his detail, view the progress, submit project
idea.
The System should provide a feedback form for all users to give comments or asking
questions. It should provide a FAQ to minimize the workload of system administrator.
Our module also gives the functionality of User’s Feedback.

Other part for user interfacing is containing Pc(systems).

Also must contains the networking.

The diagram below illustrates the four major functionalities. These

functionalities will be displayed depending on the user. For instance, the
Administrator will see all functionalities while the normal user and the
students will only see the options and records of the database insert in by
the user, students and faculties.

2009-CE-096 2
 Selecting one of these functions will take the user to a different
user interface. For instance, choosing About CEP will display the
following web page. The title of this page is consistent with the function
selected, and since the user will instantly gets the knowledge about CEP.
The purpose of this is to allow the user know what part of the system they
are accessing. And if user interested to doing any course than he will have
options to choose any course with detail information. Furthermore, the
user can select any of the four functions.
Like History of CEP
Purpose
Our Mission
Our mandate

2009-CE-096 3
 The user can select any of the functionalities. For the sake of this
demonstration, if the user clicks on the CEP course list the diagram below
is displayed. Once again the title is the same as the main function and a
subtitle indicates the second function selected. In addition, the course list
provides the information for all the courses are held in CEP department of
SSUET. He/she will allow choosing any subject. The three buttons allow
the user to navigate through the interfaces. For instance, the Home button
will take the user to the main page.

2009-CE-096 4
 Than the Contact us may be clicked by user, this function gives the
functionality to give feedback instantly. Also we have academic calendar
which gives the whole schedule of the CEP department.

Now if user click on “Apply Online” than The following page

allows the user to fill the form as appropriate. Now, this page is part of the
Students Account function, and it is used here to insertion of a new record,
it can be drop request by administrator. This makes it easier for the

2009-CE-096 5
 students since they do not have to go back to the main menu and to access
their account.

Finally, the submit button displays the appreciation page as shown

below with a button to go to the main menu. There will be some
messages display for a user
I. View Report
II. Drop a request

2009-CE-096 6
 The above illustration has shown a brief overview of the user
interfaces involved for the students, default user and others who are
willing to doing any course from CEP Department. However if
Administrator allow the user to join the CEP course than a confirmation
message will be given by administrator, it may be any call or email.

The report selected here shows the number of reservation for each
insertion may be accept or rejected. But user will be inform by email or
any call.. The diagram below shows the report format to be displayed.

2009-CE-096 7
 As mentioned earlier, the system can also be accessed through the
wireless phones. In that case, the overall system will be the same as the
above presentation except that the format will be simplified, since the
phones do not have graphic support. The phones will have access to the
Make Insertion and students Account, however it is difficult to display the
reports and deletion, insertion, searching of information on a small screen
for the Administrator.

The aspects of optimizing the interface with the person who must use the
system are briefly described below:

• Allow new users to become members of the system.

• Allow current users to login into the system using a unique user id
and password.

• Allow the users to build new insertion of records, deletion of

records, searching in records. Searching not on extreme level just
to fetched record from existing database.

• Allow all users to access current scheduled courses offered by

CEP Department. Allow administrative users to change courses
schedules, entry in records either insertion or deletion.

• Allow administrative users to announce schedule changes.

• Provide administrative users with access to reports including

number of insertion of records in database, number of students
2009-CE-096 8
 turned away, number of no-shows, number and names of students
who showed up, and list of students who filled the form.

• Provide an on-line help for all users of the system.

3.2.2 Hardware Interfaces.

The ARRS includes two major hardware components: cellular
phones and regular PC's.
Cellular Phones

The cell phones require WAP (wireless application protocol)

network protocol, which is already programmed in the latest phones. This
is similar to the seven layers of network protocol, except that they are
broken down into five protocols. The WAP protocol is able to
communicate with the servers known as Gateway servers, which listen to
requests made using these phone frequencies. The request is then
transmitted to the regular server.
The cellular phone has a processor, which is designed to process a
language known as WML (wireless markup language). Therefore, the
server formats the data in WML format, and passes these pages to the
Gateway servers, which transmits the WML pages to the cellular phones.
The processor on these phones then translates the WML into a simplified
version of the actual web page.
Server Side
The web application will be hosted on one of the department’s
Linux servers and connecting to one of the school Oracle Database
server. The web server is listening on the web standard port, port
80.
Client Side
The system is a web based application; clients are requiring using a
modern web browser such as Mozilla Firebox , Internet Explorer and
Enable Cookies. The computer must have an Internet connection in order
to be able to access the system
PC’s

The second component involves the regular PC’s, which

communicate with the server. The server then communicates with the
database.
The protocol involved between the PC's and the server is the HTTP
protocol, which allows communication between the PC's and the Server.
The remote PC's, such as someone accessing the CEP from home
using the Internet, are able access the information. The requests come in
through the HTTP protocol, and using the database results are returned
and processed using Perl to give an HTML web page. The format of the
output is displayed as web pages.

2009-CE-096 9
 3.2.3 Software Interfaces.
An Oracle DBMS will be used to manage the database and any changes
made to it. Furthermore, the DBMS will make regular backups of the
database and generate reports regularly so that they can be accessed by the
Administrator. The Apache server between the client and the database will
handle all communication, and the server will run on a Linux operating
system. Furthermore, the HTML pages must be implemented such that
they can be displayed on two common browsers: Mozilla Firefox and
Internet Explorer.

Information about the products used for the ARRS:

(1) Name: Oracle

(2) Mnemonic: Oracle
(3) Version Number: 8
(4) Source: Oracle

(1) Name: Linux

(2) Mnemonic: Linux
(3) Version Number: 6.2
(4) Source: Unix

(1) Name: Internet Explorer

(2) Mnemonic: IE
(3) Version Number: 5.00
(4) Source: Microsoft

(1) Name: Mozilla Firefox

(2) Mnemonic: Firefox
(3) Version Number: 3.68
(4) Source: Mozilla Organization

(1) Name: Xampp

(2) Mnemonic: Localhost
(3) Version Number: 1.6.7
(4) Source: Apache Server

(1) Name: Macromedia Dreamweaver

(2) Mnemonic: Dreamweaver
(3) Version Number: 8
(4) Source: Adobe Software Foundation

3.3 Performance Requirements.

The following sections list the performance requirements for the system.

3.3.1 User Requirements

2009-CE-096 10
 User Requirements Description of Requirement
For Design Environment
Location(s) and Number(s) of Users Guangzhou, Nanjing, Shanghai
Expected Growth in Number of Users
After 1 Year 50%
After 2 Years To be done
After 3 Years To be done
User Expectation
Interactivity User expect that it provides a very
easy to use graphical user interface
Reliability For some applications, reliability
must be 100% during the application
session. User demands reliability first
Adaptability Network must adapt to user
insertions, deletions, searching and
changes as per requirements.
Security Encryption software would be used
for transactions and security on
SSUET site need as when students,
faculty and administrator log in their
Id, password must be secured.
Cost / Funding Less than $250K

User class – Student

This section is for SSUET School of Students of all departments having interest
in doing courses diplomas.
1. Student registration form. Student can be register on the system and
fill in all detail and forward to choose project/supervisor.
2. Change Detail. Student can change detail if information is incorrect
such as telephone number.
3. Change Password. Student can change his login password at any time
for security reason.
4. Forget password. Student can request his password if he/she forgotten
the password.

User class – Faculty

All staff can view the details of any student.
3.3.2User class – Unit Cohort coordinator
Certain staff may be designated as Unit or Cohort coordinators and can change
the details of any student doing their unit or project cohort.
Change Student Detail
Unit Cohort coordinator can change student detail for incorrect information.

View Student Detail

Unit Cohort co-ordinator can view student information and monitor their
progress.
2009-CE-096 11
 List Student
Unit Cohort co-ordinator can list all students in different period of different
group.

Change Password
Unit Cohort co-ordinator can reset the student’s password if required.

3.3.3 User class – System Administrator

List Student
System Administrator can list all students in different period of different group to
check any error.

Change Password
System Administrator can reset the student’s password if required.

3.3.4 User class – Administration Staff

List Student
Administration Staff can list all students in different period of different group.

3.3.5 Design constraints

The system need to design base on the existed code and database using J2SE 5.0,
J2EE 1.4 and Struts 1.2.x.

3.4 Application Requirements

Since no specified service is indicated, then we have listed the applications

as best – efforts. This may change as we learn more about the application.

The communication package is determined to be bursty in nature, with

small data sizes and frequent transmissions. We can consider this
application to be interactive-burst, while the database transaction-
processing application is described by the CRM as transferring large
amounts of data (initial estimates are 1 MB/transaction), we have listed
this application as interactive-bulk.

Categorizing Application
Applications Best- Locations
Effort
s
Communication 100 Kb/s All locations
Database Access 400 Kb/s All Locations
Database Transaction processing 1.5 Mb/s All Locations

3.4.1 Host Requirements

2009-CE-096 12
 Type of Numbers and
Host or Locations
Equipment
Host A PC Homes any
where
Host B Database Appache
Server
Host C Application Xammp
Server

3.4.2 Standards Compliance.

There are no design constraints that can be imposed by other standards
limitations.

3.4.2.1 Software Limitations.

• must be able to run Internet Explorer or Mozilla Firefox web
browsers to access the system.
• must have cell-phone web based capability to access the
system from a mobile phone.

3.4.2.2 Hardware Limitations.

• Input/Output: One or two-button mouse, keyboard, cell-phone,
or touch screen required.
• Network card required at thin-client terminals to make
communication with server possible.
• Using compatible Pc’s by users.

3.5 Quality Characteristics System attributes

There are a number of quality characteristics that apply to the ARRS software
system.

3.5.1 Security
The system needs to log client’s information of registration such as IP
address and time for security purpose.
Password should encrypted and store in the database.
The CEP module should not compromise the customer information at any
time. The user information will never be unsecured and will be kept
secure at all times. Users will be authenticated to ensure that no
unauthorized users gain access to private information.

3.5.2 Maintainability
The system developing using Xampp, all action is detailed in index.html
and online.html that easy to modify and make update. The CEP source
code will be kept well structure and documented so that it is easier to
maintain and extend the system. All changes to the system will be
documented.
2009-CE-096 13
 3.5.3 Portability
The web application is coding in dreamweaver and xampp, therefore, it
should be transferable between different databases. The CEP will be
developed using HTML and PHP so that it can be accessed from any type
of system using just a regular web browser. It will also be available to
users that have web access on their cellular phones. The system will be
tested on all types of hardware before being released to ensure that is it
compliant with this requirement.

3.5.4 Reliability
The system should be capable of processing a given number of insertions,
deletion, searching and changing within a give time frame with no errors
and the system should be available and operational all the time. During
the development of the prototype for the students it should be working in a
convenient manner.

3.5.5 Usability

The CEP will be developed so that it is an easy to use system that requires
the least amount of user input possible. Every input will be validated.
The user should only have general computer use knowledge. Error
messages will be displayed if the user enters an invalid value or tries to
access a function without the required permissions. An easy and well-
structured user manual will be provided to the Administrator and the
system will include descriptive help for all operations allowed.

3.5.6 Correctness

The CEP module will be considered correct when the Administrator

approves the prototype presented and agrees that all the functions they
require are implemented as stated in the Software Requirements
Specification.

3.5.7 Flexibility

The CEP module should be developed in such a way that it is easily

customizable. If new functions are required by Administrator, there will
be little effort required to update the system to support new change or
transaction of data.

3.6 Other Requirements.

2009-CE-096 14
 Certain requirements may, due to the nature of the software, the user
organization, etc., be placed in separate. For further extending, is able to
send notification by SMS.

Supporting Information
Table of contents
Appendixes
Index

Categories such as those below.

3.6.1 Data Base.

The Continuing Education Programmed will have single database.

This deals with the academic calendar as well as Apply Online
registration. This database will be created with Xampp (Client/Server)
version 1.6.7. The following are the requirements for these databases that
are to be developed as part of the deliverable/increment. They include:

Apply Online Registration

Schedule information for the students,

Types of
including courses offered CEP department,
information
Academic calendar, history etc
The database should allow access to at least
1,000 people at once; the users will have a
Accessing general access to the information about the
capabilities CEP academic schedule, and a secure access
to the reports (available only to Administrator
officials) using a username and a password
Data element and
To be determined
file descriptions
Relationship of
data elements, To be determined
records and files
Static and
dynamic To be determined
organization
CEP department of SSUET gives the
Retention approval for a willing candidate. And drop
requirements for request may be send by Administrator. The
data reports information will be available at least
for 5 years

3.6.2 Operations.

2009-CE-096 15
 The normal operations required by the user can be viewed as the
following:

User-initiated Operations:

These operations include the login operation, which is initiated by the

users. Also, the process of becoming a new user is in this category.
Building, changing, and viewing itineraries, as well as paying for the
itinerary are all initiated by the users. The user initiates the report
generation activity, as well as changing in academic calendar schedules.

Interactive Operations and Unattended Operations:

The users initiate all the operations mentioned above, and almost all of
them are somehow interactive. Displaying the schedule is non-interactive.
The report display is a non-interactive operation, although selecting the
desired reports will require user input. User Id must be unique.

Data Processing Support Functions:

The user account data is used to create new accounts, as well as to validate
user id's during login functions. For building itineraries, user input, user
account data, and academic schedule data are used, and processed. User
data along with final results of user, maximum communication with users,
in result maximum requirements are collected, and used for report
generation purposes. Administrative users' inputs are collected in order to
modify and present schedules.

Backup and Recovery Operations:

Database used (Apply Online Registration) are production databases. The

main operation used for the backup and recovery is Oracle's built-in cold
backup, which is also known as the "archive mode". Depending on the
customer's needs and budget, additional redundancy can be added using
systems like RAID 5 and tape backup.

3.6.3 Site Adaptation Requirements.

There are no site adaptation requirements for this project.

4. Supporting Information.
There is no supporting information required for this project.

2009-CE-096 16