Software Requirements Specification

For

NETWORK BASED COURSE REGISTRATION SYSTEM

Version 1.0

Prepared by

Group ***

EXAMPLE of a good SRS

NAMES ******

Date: 01 / 01/ 2017

Table of Contents

Acknowledgement: Sections of this document are based upon the IEEE Guide to Software
Requirements Specification (IEEE 830)
Table of Contents.....................................................................................................................ii

Revision History......................................................................................................................iii

1. Introduction.......................................................................................................................1
1.1 Purpose......................................................................................................................................1
1.2 Document Conventions..............................................................................................................1
1.3 Intended Audience and Reading Suggestions.............................................................................1
1.4 Product Scope.............................................................................................................................1
1.5 References..................................................................................................................................2

2. Overall Description............................................................................................................2
2.1 Product Perspective....................................................................................................................2
2.2 Product Functions.......................................................................................................................3
2.3 User Classes and Characteristics................................................................................................4
2.4 Operating Environment..............................................................................................................7
2.5 Design and Implementation Constraints....................................................................................7
2.6 User Documentation..................................................................................................................8
2.7 Assumptions and Dependencies.................................................................................................8

3. External Interface Requirements........................................................................................8

3.1 User Interfaces...........................................................................................................................8
3.2 Hardware Interfaces.................................................................................................................11
3.3 Software Interfaces..................................................................................................................12
3.4 Communications Interfaces......................................................................................................13

4. System Features...............................................................................................................13
4.1 System Feature 1......................................................................................................................13

5. Other Nonfunctional Requirements.................................................................................17

5.1 Performance Requirements.....................................................................................................17
5.2 Safety Requirements................................................................................................................18
5.3 Security Requirements.............................................................................................................18
5.4 Software Quality Attributes......................................................................................................18
5.5 Business Rules..........................................................................................................................19

Appendix A: Glossary.............................................................................................................20

ii
SRS Online CRS
Appendix B: Analysis Models.................................................................................................21

Appendix C: List of References.......................................................................................................21

iii
SRS Online CRS
1. Introduction

1.1 Purpose

The project aim is to improve the manual registration process in the school of mathematics and
computer science by implementing a network based registration course system .

1.2 Document Conventions

The document is made using Calibri where:

 Main section are indicated with bold letters font 14
 Subsections also bolded with font 14.
An appendix A is added for acronyms and abbreviations
A list of figures is also included for the figures used in the document as appendix B.

1.3 Intended Audience and Reading Suggestions

This document is intended to be read by the customer Group 2. This is a technical document and
the terms should be understood by the customer. The customer needs to understand this
document fully so that they can draft a design document using this SRS presented to them by the
analyst (Group 4).

1.4 Product Scope

The scope of this project includes our group of developers (Group4) assisted by our customer,
Group2. The scope thus far has been the completion of the basic interfaces that will be used to
build the system. The database to be used will be setup by the developers and given the necessary
permissions.
The network based registration system will be used by students whom may be familiar or not to
the online registration process thus the scope of the project must be user friendly for both our
customers and administrators.

This system will allow only students whom paid registration fees to register, constraints will be put
on the system, like prerequisites for all courses offered. Each student will indicate two alternative
choices in case a course offering becomes filled or cancelled. Once the registration process is

1
SRS Online CRS
completed for a student, the registration system sends information to the billing system so the
student can be billed for the semester.

The system will have to keep a billing after the registration process has been completed. The
communication and the monitoring of the application will be handled by the developers (Group4)
for a smooth registration process.

1.5 References
Sections of this document are based upon the IEEE Guide to Software Requirements Specification
(IEEE 830)

2. Overall Description

2.1 Product Perspective

Online
Registration
process
Student

Course
catalogue
System
DB
Administrator
Online registration
system

Figure 2.1 the online registration system environment

The online registration system involves three actors, the administrator, the system data
administrator and the users (students) .The administrator controls the communication and service
delivery for users, the database administrator monitors the database for applicants and financial
information and lastly the students communicate with the system through application for courses
offered.

2
SRS Online CRS
2.2 Product Functions

Password and
student number

Valid password invalid password

Select Prompt for
function reentry
No input tries again

View course Proceed to

catalogue registration

Proceed to registration No
Paid
registration fee
Yes

Select Proceed with

courses registration

Select again Courses meet

prerequisite rules

No
Yes

Submit registration /print

proof of registration

Figure 2.2 activity diagrams with system features

3
SRS Online CRS
The key features of this system can be abstracted as follows.

 Authentication through users’ personal computer

 Alternative authentication mechanism for special conditions.
 User status if registration fee is paid or not.
 Block students who did not pay registration fees.
 Block students who don’t have prerequisites to register a particular course but they can try
to register for courses that don’t require prerequisites.
 Provide student with relevant courses for registration and a course catalogue.
 Registration process –check box method.
 Provide a proof of registration once the process has been submitted and terminated.

2.3 User Classes and Characteristics

User
authenticatio
n

Catalogue
viewing
/changing
Student
Registration
fee checking

Prerequisite
checking
/blocking DB admin

Registration
process/submi
t

System administrator Course

billing/proof
of
registration
issuing
Online Figure 2.3 use case diagram
registration system
For entire network based registration

4
SRS Online CRS
The uses are listed in the diagram above which also depicts the use cases of the whole online
registration system with its three primary actors

2.3.1 Student
 The user access the online course registration system
 Since user will be an admitted student of the university , they will create an account
 User enters student number (user name)and password to access the registration process
 User view the course catalogue
 Then proceed to the registration phase
 Submits registration an receives proof of registration

Authentication:
account & Log-
in

View course
catalogue
/offered courses

Register –click
courses to
register/submit
Figure 2.3.1 student use case

2.3.2 System administrator

 Users must be admitted students for the university, when interacting with the system they
will have to provide information for the system and create and account, preferably the
username is the student number. The system administrators are also involved in this.
 Responsible for changing and updating the course catalogue if possible
 Validates the registration process, adds and deletes old courses, and maintain the
registration process.
 Management may want to change some features on the proof of the registration, the
system admin deals with this.

5
SRS Online CRS
 User
Authentication Registration
procedure
/updated by
system admin

Updates given
user course Proof of
catalogue registration
updated

Figure 2.3.2 use case for the system administrator.

2.3.3 DB system administrator

 Students who failed prerequisites cannot register some course for the next year , these
prerequisites change time-to-time by the university policy , the changes are made by the
DB admin
 The registration process and course that are available for registration are updated and
maintained by DB admin.
 Monitoring financial information

6
SRS Online CRS
 Prerequisites
changing

Addition and
subtraction of
courses for
registration

Billing
Figure 2.3.3 uses case for DB admin +financial
services

User characteristics
 The user should be familiar with the Internet.
 User should be computer literate.

2.4 Operating Environment

Network based course registration system is an internet oriented application, it set to operate on a
high available and Qos network, since registration is a sensitive thing, the quality of the network
should be good for this process. Mostly a device that can access the internet and can support a
huge web application for registration. Any OS can support this system as it is not particularly
software or hardware dependent

2.5 Design and Implementation Constraints

The system is network based system, a webapp that should be developed to support any web
browser to be used, registration in the University is a sensitive issue an must be secure , the
system design should include a lot of DB and SYSTEM validation . Courses are billed by the
University policy so this part must be secure ,so developers needs to be always there to support
the delivered system in terms of validation and maintenance.

7
SRS Online CRS
2.6 User Documentation

The project is available on the internet as it is a network based application. The University website
should provide a user manual on how to use an n online registration application. Users of the
system will be guided by the system all the way when registering.

2.7 Assumptions and Dependencies

The assumptions and dependencies relevant to the system are as follows.

 All users have an a computer or any web enable device
 User should have internet access.
 The user must have access or be on a reliable network.
 Users should have been admitted to the University, and have a student number.
 Registration fees must be paid , or users will be blocked
 Users whom are returning, must have passed prerequisites, otherwise they will be blocked.
 User should read course catalogue careful in order not to make mistakes , cause they are un-
reversible
 Besides the user catalogue to be given, users must know which course is expected of them
to register.

3. External Interface Requirements

3.1 User Interfaces

The user is going to interact with the

system through different interfaces.
Listed below are the different
components of user interfaces under
their respective headings:

User interfaces samples:

8
SRS Online CRS
 Figure 3.1.1 student log-in /
create profile

 When a student logs in

to the online
registration system,
they will have to create
a profile if they are new
users of the system. or
they will login before
entering the system.

Figure 3.1.2 registration

process.

 Once log-in, user will

choose and action to
do, new users can
view course
catalogue and proceed to registration.
 Old users can cancel the registration or replace courses registered.

9
SRS Online CRS
 Figure 3.1.3
select level.

 Users will have to specify the level of study they are doing and the department. To make
the registration process more simple.

Figure 3.1.4 process.

 Once to the
registration
process, user will provide personal details once more, for the security purpose.
 Then type the courses which they are registering corresponding to the course catalogue

10
SRS Online CRS
Figure 3.1.5 creating profile.

 From figure 3.1.1 if user clicks create profile. This form will appear for the users personal
authentication and create a login detail

Screen layout constrains:

 All the images will be sized according to their importance and prominence per interface
 Some of the images on the screen will serve as buttons
 The standard screen resolution of the system will be 1046x768
 Some of the displayed material will be in HD (high definition)

Standard Buttons:
 Back button
 Forward button
 Help button
 About us

Keyboard shortcuts:
 ESC
 F1: Help

 CTRL+ESC: Open Start menu

 ALT+TAB: Switch between open programs

 ALT+F4: Quit program

11
SRS Online CRS
  SHIFT+DELETE: Delete item permanently

 Windows Logo+L: Lock the computer (without using CTRL+ALT+DELETE)

Error message standard:

To every command given to the system which is not part of the system an error message will be
sent to the user to please enter the right information.

3.2 Hardware Interfaces

This system will not be engaging with the hardware in terms of exchanging information or
functionalities, it will on run on the hardware. The system will be dependent on the capabilities of
the hardware and will not alter any functionalities of the hardware

Minimum Hardware Requirements:

The system will run on different hardware gadgets. Below are the minimum hardware
requirements for the smooth running of the system:
 1GB RAM PC
 1.8Hz processor
 14” color monitor
 120GB HDD CPU
 Proper running internet

3.3 Software Interfaces

The system will require a lot of software connections so it has to be compatible to external
software to be able to connect. The main system will be composed of the web portal, the operating
system used and the database all communicating together and exchanging information.

Below are the different software components that the system will need to be fully operational
under their respective section headings:

12
SRS Online CRS
Databases
The following databases can be used for the system
 MS access
 Apache DB tool
 MySQL

Operating systems
The system will be compatible to the following operating systems:
 Windows7
 Linux
 Mac OS

Tools

The following tools will be used for the system’s development:

 Ajax
 Eclipse
 Notepad++
 HTML 5
 PHP myadmin
 JavaScript
 CSS
 ASP
 ASP.NET
 Komodo Edit

3.4 Communications Interfaces

The main communication link that the system will be using is the internet. Below is the different
information transferring methods and their respective protocols:

Information transmission means:

 Web file transfer
 E-mail
 Social Networks information transfer

Protocols

13
SRS Online CRS
The protocols that are to be used in this system are the secure ones as confidentiality is of vital
importance in this system. Listed below are the protocols:

 HTTPs
 FTPs
 SMTPs
 MIMEs

4 System Features

4.1 System Feature

The online registration system comprises of two main features, namely, internet connectivity
which will enables users to communicate with the server through a browser or web agent, and
secondly the system requires database service to store the user’s data. In a nutshell this system is
web application and thus is only operational in an internet enabled environment.

4.1.1 Description and Priority

Ratings (1-9)
Features Description Priority
Risk Cos Penalt
t y
5 7 4
Database service Data manipulation and Storage High
Access and operation of system 7 1 6
Internet service High
Student authentication 3 7 5
Security High
Password Student authentication and recovery 3 6 6
Medium
Recovery
Users of the internet and university 3 8 6
Multi-user population Medium

Figure 4.1.1 description and priority

4.1.2 Stimulus/Response Sequences

St-1: Click “Register” Button: Account Registration

14
SRS Online CRS
 1. The system shall allow non-registered user to create a secure account.
2. The system shall require the following information: First name, Last name, E-mail
address.
3. The system shall ask the user for student number as a username and password.
4. The system shall confirm the username and password are acceptable
5. The system shall store the information in the database

St-2: Click “Login” Button: Account Login

1. The system shall allow a registered user to log-in to their account.
2. The system shall require a username and password from the user.
3. The system will verify the username and password, and the user will be considered
“logged-in”.

St-3: Click “Registration” Button: Course Registration

1. The system shall allow users to register for courses offered.
2. The system shall require user’s personal formation such as: Full name, Identity number,
date of birth, Address, etc.
3. The system shall require the user to specify the level of study and allow the user to
select courses to register for.
4. The system shall confirm all valid courses offered for the level of study selected by user.
5. The system shall also require the user to provide credit information.
6. The system shall allow user to save the already entered details for later continuation.
7. After the user filled the entire form, the system shall save the data in the database.

St-4: Click “Cancel Registration” Button: Cancel

1. The system shall allow the user to cancel the entire registration.
2. Alternately the user may wish to cancel while filling the form.

St-5: Click “Replace Course” Button: Replace

15
SRS Online CRS
 1. The system shall allow user to replace one with another.
2. This can happen while or after registration.
3. The system shall be given option to progress back to invalid courses entered.

St-6: Click “View available Courses” Button: View Courses

1. The system shall allow user to view available courses before registration.
2. The system shall view available space left for each course.

St-7: Click “submit registration “Button: submit

1. After filling in the registration form, the system shall allow user to submit the
registration.
2. After submitting a copy of the proof of registration will appear on the screen.

St-8: Click “view registration status” Button: view status

1. System shall allow user to click and view their registration status. This includes the
courses registered and proof of registration.
2. System shall allow user to print the proof of registration

4.1.3 Functional Requirements

REQ-1: The system shall be internet oriented and require an online server.
1. The online registration process shall be done online with the user requesting HTML
documents through a browser using TCP/IP and the server shall use PHP script to
manipulate the entered details and SQL to manipulate the data.
2. The server shall request response from the user for data saving and data requesting.

REQ-2: The system shall save the user’s details to a remote database service

16
SRS Online CRS
 1. The user shall be allowed to enter account details which will be saved in a remote
database server.

REQ-3: The system shall allow users to register and to log in a user account
1. The system will identify each user by a user account.
2. Each user shall be able to access the system through the account and therefore be able
to register for courses.

REQ-4: The system will allow users to register for courses following the University
Rules.
1. Before registering for courses, the users must be qualified for registration and the
registration fee must have been paid.
2. The pre-requisite courses shall be considered before registration.

REQ-5: The system shall automatically update the course catalog

1. The system shall allow users to view courses, the number of applicants and the space
left for admission.
2. This information must be updated by the administrator.

REQ-6: The system shall block users who did not pay registration fees
1. Users who did not pay the registration fees will not have access to the registration
process.
2. They will be notified as not cleared for registration.

REQ-7: The system will block courses for students whom failed prerequisites
1. If student failed prerequisites, they will be blocked to register courses that require the
prerequisites.

17
SRS Online CRS
5 Other Nonfunctional Requirements

5.1 Performance Requirements

The system is required a fair amount of speed especially while browsing through the catalogue and
presenting different possibilities for the schedule. The outcomes of the product are not directly
influenced by its speed, because all the operations are linked to each other and one operation
cannot be computed before the one causing it and also since the availability of the internet
connection is not predictable.
The database shall be able to accommodate a minimum of 10000 records of students.
The software will support multiple users, with their respective accounts of course.

5.2 Safety Requirements

The system will provide a protection of the database such as the one that the university already
provides. However, the system will have to increment this level of protection because of the
personal data made available on the system, and the larger share of people that will be having
access to it through the online registration.

The users’ privacy will be granted by the limited access that the log-in process is going to give to
the database. Also, the system does not grant direct access to the database itself. Stakeholders
(group2) and developers (group4) who need to access the database will have to access it from a
source independent from the registration system.
Information transmission should be securely transmitted to server without any changes in
information. Also guest users must not be able to edit any information. The online registration
system shall be accompanied with a backup file system.

5.3 Security Requirements

The main security concern is for users account hence proper login mechanism should be used to
avoid hacking. The online registration system shall not disclose personal information of students to
unauthorized users or the public.

18
SRS Online CRS
5.4 Software Quality Attributes

Speed and Latency Requirements

The system is required a fair amount of speed especially while browsing through the catalogue and
presenting different possibilities for the schedule. The outcomes of the product are not directly
influenced by its speed, because all the operations are linked to each other and one operation
cannot be computed before the one causing it.

Reliability and Availability Requirements

The reliability of the system is directly linked to the level of update of the documents to which it is
correlated, such as the catalogue or the students’ database. The system and the external
documents must be updated constantly according to the necessities of the stakeholders. Both
catalogue and database will have to be available to students 24/7. The official registration,
however, should be allowed only during office hours, in order to prevent those students who do
not have Internet at home to be disadvantaged with regard to those who instead do.

Robustness or Fault-Tolerance Requirements

When the system is disconnected or frozen due to over access at the same time, it should save all
the process of the users have made up to the point of abnormal happenings. When the users log in
with the same ID, all the work should be provided.

Capacity Requirements

The system should be able to manage all the information incoming from the database and the
catalogue.

5.5 Business Rules

 The online registration system shall include two types of accounts: the administrators and
the students.
 To log in to the system user name and password is required. User name shall be the student
number of the student and the password as they prefer,

19
SRS Online CRS
  The system shall be implemented with HTML interfaces for it to be easy to understand.
 There will be help pages included that will explain how to recover from an error, how to
work the system, etc.

20
SRS Online CRS
Appendix A: Glossary

DB – database

SQL – simple query language

Admin –Administrator

SRS –software requirements specification

Webapp – web application

TCP/IP – transmission control protocol /internet protocol

ID – identity

Std no: - student number

RAM – random access memory

PC – personal computer

CPU – central processing unit

CTRL – control

DEL – delete

OS – operating system

HTTP – hypertext transmission protocol

FTP – file transfer protocol

SMTP – simple mail transfer protocol

21
SRS Online CRS
Appendix B: figures

 Figure 2.1 the online registration system environment

 Figure 2.2 activity diagrams with system features
 Figure 2.3 use case diagram For entire network based registration
 Figure 2.3.1 student use case
 Figure 2.3.2 use case for the system administrator.
 Figure 2.3.3 uses case for DB admin
 Figure 3.1.1 student log-in / create profile
 Figure 3.1.2 registration process.
 Figure 3.1.3 select level.
 Figure 3.1.4 process.
 Figure 3.1.5 creating profile.
 Figure 4.1.1 description and priority

Appendix C: List of References

1. IEEE Recommended Practice for Software Requirements Specifications," IEEE Std 830-1998

22
SRS Online CRS