Srsfinaledit 140325142901 Phpapp02

Software Requirement
Specification
Student registration System
Rajarata University of Sri Lanka

Faculty of Applied Sciences
INFORMATION AND COMMUNICATION TECHNOLOGY
Table of Content
1. Introduction..03
1.1 Purpose..03
1.2 Scope03
1.3 Intended audience.04
1.4 Glossary..04
1.5 References05
1.6 Overview05
2. Functional Requirements06
2.1 Use case diagram...06
2.1.1 Use case for Super user...............06
2.1.2 Use case for Administrator.........07
2.1.3 Use case for Student.....................08
2.1.4 Use case for Guest.........................08
2.2 Use cases..09
Use Case 1
Use Case 2
Use Case 3
Use Case 4
Use Case 5
Use Case 6
Use Case 7
Use Case 8
Use Case 9
Use Case 10
Use Case 11
Use Case 12
Use Case 13
Use Case 14
Use Case 15
Use Case 16
Use Case 17
Use Case 18
Use Case 19
Use Case 20
Use Case 21
Use Case 22
Use Case 23
Use Case 24
Use Case 25
Use Case 26
Use Case 27
: Login into the system.09

: Change user password..10
: Add users.11
: Remove users12
: Manage users...13
: Edit profile information.14
: Remove selected subjects from student's selections..15
: Create new subjects..16
: Edit existing subjects17
: Delete subjects.18
: Create new subject lists.19
: Make adjustment of credits per subject20
: Subject combination tool 21
: Publish time table..22
: Update time table..23
: Current subjects by subject vice..24
: Past subject selections by subject vice25
: View past & present subject selections of a student26
: Edit student's profile.27
: Select subjects28
: Remove subjects from the list30
: Save31
: View previous semester information.32
: View Notices33
: Guest view of the student's profile.34
: Super user confirmation.35
: Access Control Matrix..36
1|Page
3. Activity Diagram..37
3.1 Super user...37
3.2 Administrator38
3.3 Student.39
3.4 Guest..40
4. Nonfunctional Requirements.41
4.1 Product.41
4.1.1 Usability requirements...41
4.1.2 Efficiency requirements.41
4.1.3 Performance requirements.41
4.1.3.1 Reliability requirements..41
4.1.3.2 Storage requirements..41
4.1.4 Portability requirements42
4.2 Organizational.42
4.2.1 Delivery requirements42
4.2.2 Implementation requirements .42
4.2.3 Standard requirements..42
4.2.4 Operational requirements42
4.3 External Requirements..43
4.3.1 Interoperability requirements...43
4.3.2 Ethical requirements43
4.3.3 Legislative requirements..43
4.3.3.1 Privacy requirements43
4.3.3.2 Safety requirements..43
5. Entity Relationship Diagram44
5.1 Entities and attributes.................46
6. Class Diagram47
7. Verification and Validation48
7.1 Verification..48
7.2 Validation.49
2|Page
1. Introduction
1.
1.1 Purpose
The purpose of this System Requirements Specification is to outline the functional, nonfunctional and business requirements of the Student Registration System of Rajarata
University of Sri Lanka. The document provides a detailed overview of the software product, its parameters and goals.
The requirements are documented in such a way that facilitates developers to understand
the functionality to be developed along with the constraints they meet. The document
would also provide assurance to the client that the development team has fully understood the needs of the system and would also support in validating the product delivered.
1.2 Scope
The main objective of the Student Registration System is to allow internal students of the
university to register for a new semester via internet. The system will maintain 3 categories
of user accounts in performing the tasks. They are namely Super user, Administrator
and Student.
The Super User is given supreme privileges in the system and therefore is able to do
anything in the system. S/he will also control the privilege access matrix of Administrator
and Student accounts. The Administrators are of different levels of privilege depending
on the tasks they perform. The administrators are entitled to manage other user accounts,
to make amendments to subjects, to add new subjects and also to view student details.
Students are of the lowest privilege level with only being able to register for a new semester, edit or view profile information, view previous and current semester information
and to view notifications.
All 3 categories of users must login to the system with the user name and the password
to perform any of the operations. Other than the above mentioned 3 user categories the
system will also allow guest users. However the guest users can only view the results of a
particular student by entering the student registration number and the index number.
Since the existing registration process is a manual one, the proposed Student Registration
System will increase the efficiency of the registration process quite significantly while
3|Page
providing time and cost benefits. Furthermore it will provide a sophisticated system for
the enrollment thus enhancing the decision making process of the administration.
1.3 Intended Audience
The document is designed for the developers of the system, ICT academic staff, and administration of faculty of applied sciences and also for any party who is interested.
1.4 Glossary
Term
Description
Activity Diagram
Shows the activities involved in a process or data processing

Person of the academic or non-academic staff of Rajarata university who is authorized to perform important
operations with regard to the Student Registration system
Shows object classes in the system and the associations
between them
A collection of stored related data
Administrator
Class diagram
Database
ER diagram
Guest user
Entity Relationship Diagram; Data model for describing

a data base in an abstract way
Grade Point Average; an internationally recognized calculation used to find the average results
A person who doesnt has a
Html
Hyper Text Markup Language
PHP
Privilege access matrix
Hypertext preprocessor; an open source scripting language

A matrix that decides the tasks each user can perform.
Student
Internal student of Rajarata University of Sri Lanka
Super user
Person of the academic or non-academic staff who has

the highest authority of the system
Known as user goal level. Something the actor is trying
to set done other levels kite level, cloud level, fish level
etc.
Representation of a users interaction with the system
and depicting the specifications of a use case
GPA
Sea level
Use case diagram
4|Page
1.5 References
UML A beginners guide- Jason T Roff

UML DeMYSTiFieD- Paul Kimmel
1.6 Overview of the Document

The next chapter of the document is on functional requirements of the system. It covers required
features of the software product and the services it provides in detail using Activity diagrams,
use case diagrams.
The 3rd chapter of the SRS is on non-functional requirements. This includes the emergent system
properties and constraints on the system such as reliability, portability, response time.
The 4th chapter includes Entity relationship diagram and class diagram.
The Final chapter includes the verification and validation methods used in the Student Registration System.
.
5|Page
2. Functional requirements
2.1 Use case diagram
2.1.1 Use case diagram for super user
6|Page
2.1.2 Use case diagram for administrator
7|Page
2.1.3 Use case diagram for student
2.1.4 Use case diagram for guest
8|Page
2.2 Use cases

Use Case 1
Login into the system.
Goal level
Aspect
:
:
Trigger
Actors
:
:
Sea Level
Moderators & users can log into the system to perform various
actions.
When someone attempts to use system functions.
Administrators of various privilege levels.
Super users
Students
Third party users
An activated login
Necessary requirements for public users.
Preconditions :
Main Success Scenario

1.
2.
3.
4.
5.
6.
User selects a login option.

Login interface is produced.
User enters password and username.
System validates input against system database.
System accepts user type.
Privileged user interface produced.
Alternative Scenarios
3a: Either user name field of password field is empty or contain unaccepted characters.
Error message display to verify input.
1. Lets user to re-enter username/password.
3b: Person use forgot my password.
1. System notifies to enter email address.
2. Action confirm by user.
3. System validates e-mail and sends information into it.
4a: Username/Password invalid
1. System notifies invalid username/password.
2. Lets user to re-enter login information again, for three consecutive attempts.
Exceptions:
4a: User failed to provide necessary information after all 3 attempts.
1. Interface is refreshed and directed to page asking to wait 10 minutes before
next attempt.
2. Upon time lock expiration, user is directed back login interface.
9|Page
Use Case 2
: Change user password
Goal level
Aspect
Trigger
Actors
:
:
:
:
Preconditions :
Sea Level
Users can change their own login password.
User clicks on change password after login.
Administrators
Super users
Student users
User must log into system.

1. User selects change my password option.
2. System produces change password interface.
3. User enters current password.
4. User enters new password.
5. User asked to re-enter new password.
6. User confirms change.
7. System validates current password.
8. System accepts new password and confirms.
3a: Incorrect current password entered.
1. System notify incorrect current password.
2. Go to step 4.
3a: User enter unmatching password secondly.
1. System notifies that password does not match.
2. Go to step 6.
Business Rules
1.
2.
3.
4.
Password should contain at least one upper case letter and lower case letter.
Password should be longer than 8 characters.
Password should contain at least one number.
Users will be given 3 attempt to log into the system, after 3rd unsuccessful
attempt, user will have to wait another 15 minutes for the next attempt.
10 | P a g e
Use Case 3
: Add users
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Add users into the system.
When administrator clicks on Add users.
Administrators with sufficient privileges, Super user.
User must be logged in, Users should possess necessary privileges.

1. User select add users option.
2. System displays Add new user.
3. User selects add a new user.
4. User enters new user name.
5. User enters new user password.
6. User selects type of the new user accounts.
7. User selects privileges level (admin/student) of new user account.
8. User modifies default capabilities of selected privilege level.
9. User enters email address associates with user account.
10. User confirms changes.
11. System prompts to enter current administrator password.
12. System validates the password.
13. System accepts changes and creates new profile.
14. Confirmation email sent to new user about his/her login.
9a: User enters an invalid email address.
1. Go to step 10.
2. System notifies the email address is already in use or not a valid one.
3. System prompts to re-enter the email.
4a: 9a: User leaves one or more required information fields blank.
1. Go to step 10.
2. System notifies to complete all fields.
3. Systems prompts data form to re-enter required data.
11a: User enters incorrect password.
1. Go to step 12.
2. System displays an error message.
3. User enters password again.
Business Rules :
1. Password should contain at least one upper case letter and lower case letter.
2. Password should be longer than 8 characters.
3. Password should contain at least one number.
4. Upon the password change, system will issue a notification email to the relevant email
address with a link to reset the changes.
11 | P a g e
Use Case 4
: Remove users
Goal level
Aspect
Trigger
Actors
:
:
:
:
Preconditions :
Sea Level
Remove existing users from the systems.
When user clicks on Remove users.
Admin
Super user
User must be logged in as an admin with required privileges or user
may logged as super user.

1. User selects remove users.
2. System produces a list of users who can be removed depending on Admins
privileges.
3. Admin searches for the desired user.
4. Admin selects the user or users from the list.
5. Admin selects remove.
6. System prompts for me admins password.
7. System validates password.
8. System displays confirmation messages.
2a: Admin cannot find required user in the eligible to remove list.
1. Admin has no privileges to remove that user.
2. Admin will have to contact super user or another privileges Admin.
3a: Invalid user names entered.
1. Click search.
2. System will display an error message.
3. System prompt user to enter user name again.
6a: Invalid password is entered.
1. Go to step 7.
2. System notify Invalid password entered.
3. System prompts to enter password again.
Post conditions:
1. System deletes the user information from the system.
Business Rules:
1. Administrators cannot remove another Admin, only super user can do so.
12 | P a g e
Use Case 5
: Manage users
Goal level
Aspect
:
:
Actors
:
Preconditions :
Sea Level
Allow/restrict certain users to perform their default privileges.
Suspend user accounts temporarily.
Modify user's profile type/privileges.
Super user
Users must be logged as super user.

1. Super user selects update users.
2. System will list down all users with their privileges levels and basic information.
3. Super user can select desired user and change his/her privilege level,
capabilities.
4. Super user selects access control.
5. System display access control interface enable super user to allow/restrict
individual users have certain features.
6. Super user selects necessary suspending options it necessary.
7. Super user confirms changes.
8. System display operation successful message.
9. System sends profile updates messages to particular users to view upon the
log on.
8a: Targeted user is logged into the system at the particular movements.
1. Systems will automatically logout the user with a notification to re-log in.
2. User will not gain access until upper user moves changes and confirm.
3. When user re-login, new configurations will be applied into his account.
Business Rules:
1. Changes will be notified to users by system
13 | P a g e
Use Case 6:
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Edit profile information
When user selects Edit profile information
Administrators, Super user
User must be logged in as Administrator/Super user

1.
2.
3.
4.
5.
6.
7.
User login with their passwords and usernames.

User selects Edit profile information
System shows editable version of user's profile.
User make desired changes.
User confirms changes
System saves changes to the main database.
System displays successfully completed message.
1a. User enters incorrect username/password
1: System notify Incorrect password/username error.
2: System prompts user to enter re-enter username/password.
6a.System cannot connect to the database to save changes
1: System notify Unable to save changes error message.
2: Retries to establish connection.
Business Rules :
1. User will not be able to change username, Name, and other registration details
14 | P a g e
Use Case 7
: Remove selected subjects from student's selections
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Remove subjects from the selection
User clicks on remove subjects
Administrators, Super users
User must be logged in as privileged actor

1.
2.
3.
4.
User logs into the system

Select subject operations
Select Remove selected Subject
System will display current time tables that selected subject will affect
5. Select confirmation to proceed

6. System removes subject from future student's selection lists
4a: Use selects Remove from the current timetables also option
1: Subject will be removed from current timetables.
2: Relevant users will be sent notices to view upon the login.
Business Rules :
1. Subject that is being currently followed, should not be removed.
15 | P a g e
Use Case 8
: Create new subjects
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Introduce new subjects into the system
When user selects Create new subjects
Administrators, Super user
User must login as a privileged administrator, or super user.

1.
2.
3.
4.
5.
6.
User logs in as administrator/super user

Selects Subject operations
Selects Create new subjects
Select relevant Academic year, Semester, Stream and other details *.
System views current subject lists that will be affected by the modification.
Confirm to continue.
Descriptions
* Details such as Lecturer, No of credits per subject, No hours per semester, practical hours,
and Subject coordinator. These details will be available in the same interface.
5a: User selects apply modifications immediately into subject selections
1: Added subject will be available to select from subject selections immediately.
Business Rules :
1. New subjects will have to be introduced with Super user approval

2. New subjects will have to get approval from UGS first
16 | P a g e
Use Case 9
: Edit existing subjects
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Edit details of existing subjects and alter predefined attributes.
When user selects Edit subjects option
Administrators with relevant privileges, Super user
User must be logged as an Administrator/ Super user.

1.
2.
3.
4.
5.
6.
7.
User login as an Administrator/Super user

Select Subject operations
Select Edit subjects
Choose relevant Academic year, Semester, Stream
System will display subject list in editable view.
Make necessary changes.
Confirm to proceed.
7a: Select Apply modifications immediately
1: Modifications will affect immediately in timetables, subject lists
2: System will notify relevant users to be viewed upon the login.
Business Rules :
1. Credit level of the subject should not be altered without notifying respective
parties.
2. Changes should only be applied immediately if that subject is not followed
currently.
17 | P a g e
Use Case 10
: Delete subjects
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Remove subjects from system.
User selects Remove subject option
Administrators with relevant privileges, Super users
User must be logged as an Administrator/Super user

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
User login as Administrator/Super user

Select Delete Subjects'
Choose relevant Academic year, Semester, Stream
System will display the subject list.
Select the subject need to be deleted.
Select Delete
Confirm to continue
System will remove the subject and all its related data, records. *
Relevant users will receive notifications on the modification.
8a: Select Remove from system but keep current assignments
1: Subject will no longer available to select but will be appear on timetables
2: System will not send notifications to current students, but a general notification
will be displayed about subject's discontinuity.
Business Rules :
1. Subjects should be only deleted if that subject it not being followed by students
at that time
18 | P a g e
Use Case 11
: Create new subject lists
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Add new subject lists into the student's selections
When user selects to add subject list

1. User logs into the system
2. Selects Subject operations
3. Selects Create new subject lists
4. Selects relevant Academic year, Semester, Stream.
5. System will display add new subject list interface.
6. Enter Subjects and relevant details regarding them *
7. Confirm to proceed.
8. System will accept new Subject list.
9. Successful notification will be displayed.
10. Notifications will be sent to relevant users.
7a:
User selects apply changes immediately.

1: The new subject list will be available to select overriding any predefined list.
2: System will prompt if any conflicts are likely to occur.
3: If user decides to make the changes confirm, system will update accordingly.
Descriptions:
* No of credits, Lecturer, course content, course coordinator.
Business Rules :
1. Subject lists should be able to fulfill credit requirement of a semester.
2. Before creating subject lists, prospectus should be referred.
19 | P a g e
Use Case 12
: Make adjustment of credits per subjects
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
1.
2.
3.
4.
5.
6.
7.
Sea Level
Adjust no of credits defined for a Subject
User selects Adjust no of credits option
User login as an Administrator/Super user

Select Make adjustment of no of credits
Choose relevant Academic year, Semester, Stream.
System will display subject list with credits in editable view.
Make necessary changes.
Confirm to proceed.
7a: Select Apply modifications to system, affecting all calculations
1: Modifications will affect immediately in timetables and subject lists.
3: New credit scheme will be used to calculate GPA process.
4: Relevant users will be sent notifications and notify via emails.
7b: Select Apply modifications to system, affecting from now onwards only
1: Modifications will affect immediately in timetables and subject lists.
3: New credit scheme will be used to calculate GPA process in future calculations,
old calculations will be remain unchanged.
4: Relevant users will be sent notifications to be view upon login.
Business Rules :
1. Credit levels should be determined considering lecture hours and no of

practical hours.
20 | P a g e
Use Case 13
: Subject combination tool
Goal level
Aspect
:
:
Trigger
:
Actors
:
Preconditions :
Sea Level
Subject combinations that students are able to select and
incompatible combinations will be defined.
When user selects Subject combination tool

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
User logs into the system.

Selects Subject operations
Selects Subject combination tool
Selects Academic year, Semester, Stream.
System will display an editable matrix to select which core subjects cannot be
selected with each other.
Select which subjects cannot be taken simultaneously?
System will display editable matrix to select which subjects should be taken with
each other simultaneously.
Select which subjects that should be taken together.
System will show any rising conflicts.
User confirm changes and resume.
System will be updated and it will use these defined constraints when students
chose subjects.
Business Rules :
1. Upon adding new subjects, administrators should define subject selection
constraints using Subject combination tool.
21 | P a g e
Use Case 14
: Publish time table
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Creating timetables for students
User click on create timetables option

1.
2.
3.
4.
5.
6.
Subject coordinating administrators log into system

Create timetables and allocate practical times in Labs
System shows conflicts and problems likely to rise
User confirms timetables
System saves timetables and notify relevant users by notices upon login.
Successful message is displayed.
3a: System detects some problems
1: User resolves issues manually changing timetables
2: With the confirmation of user, system will make necessary changes.
Business Rules :
1: Timetables should be covering required no of hours for each lecture in including
practical.
2: Changing and assigning subjects for time table should be completed with first
week of the semester.
3: Timetable should contain end of semester and exam dates with it.
22 | P a g e
Use Case 15
: Update time table
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Modify existing timetable
User selects timetable updating option.

1.
2.
3.
4.
5.
6.
7.
8.
9.
Subject coordinating administrators log into system

Select Edit timetable option.
Select relevant academic year, stream, and semester
System view show editable timetable.
Edit subjects, scheduled time, practical sessions and other details
System shows any conflicts or likely to rise problems.
User confirms changes.
System updates databases.
System will send notices to relevant users which they will see upon login.
6a.
User confirms even though there's conflicts present

1: System will alert before proceeding into next step.
2: User's decision will be in effect after confirmation.
8 a:
Database update fails

1: Changes will not be in effect.
2: System will try to establish connectivity again.
3: System will notify when the update is completed.
23 | P a g e
Use Case 16
: Current subjects by subject vice
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
View student's selections by subject vise
User selects to view student's current subject selections

1.
2.
3.
4.
5.
6.
7.

Select View student's choices option.
Enter student's index number
Confirm to proceed.
System will display information view interface with options.
Select Current subjects by subject vise
Exit interface after viewing.
3a: Invalid index no is entered
1: Go to step 4
2: System will notify with Invalid Index Number error message.
3: Enter Index number again
Business Rules :
1. Only viewing, no editing capability is provided.
24 | P a g e
Use Case 17
: Past subject selections by subject vice
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
To view student's past subject selections
User selects view student's subject selections option.

1. User logs into the system
2. Select View student's choices option.
3. Enter student's index number
4. Confirm to proceed.
5. System will display information view interface with options.
6. Select Past subjects by subject vise
7. Exit interface after viewing.
3a: Invalid index no is entered
1: Go to step 4
2: System will notify with Invalid Index Number error message.
3: Enter Index number again
Business Rules :
25 | P a g e
Use Case 18
: View the past and present subject selections of a student
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
View all past and present subject selection of student.
User select the subject selection option.

1.
2.
3.
4.
5.
6.
7.

Select View student's choices option.
Enter student's index number
Confirm to proceed.
System will display information view interface with options.
Select Past and present subject selections by subject vise
Exit interface after viewing.
6a: Select View student's subject selection overview
1: System shows student's subject selection history.
6b: Select View all student's subject selection overview
1: Enters desired subject stream.
2: Enters an Academic year, semester and a calendar year.
3: System shows subject selection history for that time period of all student's.
Business Rules :
26 | P a g e
Use Case 19
: Edit student's profile
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Let student to edit his/her profile
Student selects Edit profile option
Student user
Users should login to system as student users

1.
2.
3.
4.
5.
6.
Users log into system using username/password

System provides an editable interface of student's profile.
Edits selected data and values.
Selects other options if needed.
Confirms changes
System saves details into database.
1a:
Invalid username/password entered

1: Go to step 5
2: System produces an Invalid password error.
3: System lets user to re-enter password/username
6a:
Database is not available

1: System notify an Error saying Error in connectivity
2: System will not save any configurations due to risk of data loss.
3 System will try to establish connectivity again.
Business Rules :
1. Users are only able to remove subjects within the time duration declared by
Administrator
2. After expiring the time period to modify subjects, users will have to contact an
Admin for any inquiries.
27 | P a g e
Use Case 20
: Select subjects
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Student user can select their subjects from available subject lists
User selects Select subjects option
Student Users
User must be logged as a Student

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
User login as a student with his/her username/password.

Selects Select subject option
System determines Student's academic year, semester, and stream
System determines whether student is eligible to take subjects*
System displays available subject list
Student selects desired subject levels under defined constraints**
User confirms changes.
System will check necessary requirements of the selection.
System displays time period remaining to alter student's selection.
System saves changes into the databases.
System notify Successful operation message.
Descriptions
* Administrator will define a time period that a student can select subjects, alter their
choices at the begin of the student enrollment. After expiring this time period, any student
will not be able to select or change courses without contacting a system administrator
with relevant privilege levels.
** Subject administrators will introduce certain constraints for subject selections
depending on the Department heads. Students will not be able to take some subjects
along with certain subjects, and some subjects will be compulsory which cannot be
skipped though credit level is met.
1a:
Invalid username/password entered

1: System produces an Invalid password error.
2: System lets user to re-enter password/username.
8a:
Predefined no of minimum credits per semester is not met.

1: System notify the Incomplete Selection error.
28 | P a g e
8b:
2: User re-arrange his/her selection.

3: System will save changes.
Predefined no of minimum credits per semester is not met.
1: System notify the Incomplete Selection error.
2: User select to skip the process for now.
3: System displays contact details of relevant subject coordinator.
4: System will not save any details of the session.
Business Rules
1. A semester will have to have a minimum number of credit for all children in
all streams. This limitation will be vary with the university.
2. Student may chose more than required minimum level for a semester but
not less than it.
29 | P a g e
Use Case 21
: Remove subjects from the list
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Student can remove subject that he/she selected earlier
When student user needs to change subject selection
Student users
User must be logged as Student user

1. Selects Remove subjects option.
2. System determines that student is eligible to make changes to subject selection.*
3. System displays editable view of subject list.
4. User selects necessary subject's to be removed.
5. User confirm changes and continue.
Descriptions
* If the administrator defined time period is expired then user will no longer able to alter
any of his selections. (E.g. after two weeks of enrollment time, students are no longer able
to change their subjects)
2a: User is no longer able to alter selections
1: System notifies that user is no longer able to perform this action
2: User may have to contact relevant administrator to do the necessary changes.
Business Rules :
1. Changes can be done only within the time period Administrator defined.
2. After enrollment period expired, students will have to contact administrator to
make any changes.
30 | P a g e
Use Case 22
: Save
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Save changes users make in the system into database
When any user make an update, input a data into the system
System
Relevant database is connected and connection is up.

1. System detects any changes as user confirm his/her actions
2. System connects to the database
3. System save changes into the system.
2a: Database is not available
1: System notify an Error saying Error in connectivity
2: System will not save any configurations due to risk of data loss.
3 System will try to establish connectivity again.
Business Rules :
1: Database connectivity should not be down more than an hour during working days.
2: During enrollment duration, database should maintain high level of reliability, thus it
should accompanied with methods to increase its performance without compromising
minimum requirements.
31 | P a g e
Use Case 23
: View previous semester information
Goal level
Aspect
Trigger
Actors
Preconditions
:
:
:
:
:
Sea Level
Student will see an overview of his/her previous semesters
Student selects View previous semesters information option.
Student users
User must logged in as student actors

1. Selects View previous semester information
2. Systems shows student's academic history and current GPA
2a: User selects View list of semesters
1: System will display all available information on student's academic history.
2: A GPA chart for class distinctions will be displayed bottom of the page.
3: A GPA calculator will be available to use.
Business Rules :
32 | P a g e
Use Case 24
: View Notices
Goal level
Aspect
:
:
Trigger
:
Actors
:
Preconditions :
Sea Level
Student's will see important notices generated by system changes,
and administrators.
When there's a change occurred, a relevant notice will be generated.
System, Administrators
User must log into the system as a student user.

1. User see available notices upon the log in.
2. Some important notices will be received via E-mails also.
1a: User does not log into the system to view the notice.
1: All notices will be kept in a database, and will be available upon user login...
Business Rules :
1. Student user will have an inbox capable of holding 20 notices, Administrator

will have an inbox of 100 notices and user should clean inbox occasionally.
33 | P a g e
Use Case 25
: Guest view of the student's profile
Goal level
Aspect
:
:
Trigger
:
Actors
:
Preconditions :
Sea Level
People outside the system will be able to view records of a student
with his index number.
When someone outside the system logged into the system.
Guests
Guest user logs into the system using index number and guest
password.

1. User views student's academic performance.
2. System displays additional contact information of referees.
1a: User selects to view addition details.
1: Users can view student's past academic related activities, projects and extra
activities.
Business Rules :
1. Guest view is for the Prof Purposes in various situations. For example, online searching in
the interviews is common practice today. This Guest profile will facilitate that, and the guest
user account will require student's index number and a password provided by the student.
But guest view will not display any private information other than required performance
Profs.
34 | P a g e
Use Case 26
: Super user confirmation
Goal level
Aspect
:
:
Trigger
Actors
:
:
Sea Level
Super user login should be handled with extra security, this method
will confirm super user identity other than username/password, its
use E-mail confirmation also.
When a super user logs into the system with username/password
Super user

1.
2.
3.
4.
Super user enter username/password into the system.

An additional email will be sent to the assigned email account with a key.
User logs into the relevant email and enter the Key to the login
System authenticates super user login.
3a. Entered key is not matching to the system's key
1: System notifies about mismatch.
2: User is given another attempt to re-enter the key.
Business Rules :
1. Upon the entering correct username/password, system will send special

random access code to the related email address of the user account. And user
will have to provide this code into the confirmation interface.
2. This confirmation will have to best quickly, eliminating unnecessary delay.
35 | P a g e
Use Case 27
: Access Control Matrix
Goal level
Aspect
:
:
Trigger
Actors
Preconditions
:
:
:
Sea Level
Super user defines other administrator's privileges and access
capabilities
When user selects Access Control Matrix
Super users
User must be logged as a Super user

1.
2.
3.
4.
4.
Super user selects Access control Matrix

User selects subject operation combo box.
Define what each user is capable of doing.
System sends notification to other users if send notifications selected.
Exits the interface.
Alternative Scenarios:
1a: User selects different categories from the selections
1: System displays relevant matrix below.
2: Changes are recorded to database.
3: If asked, notifications will be sent to users.
Business Rules :
1: Super user will give proper capabilities to other users but not all privileges to one
Admin. This will share responsibilities among Admins and it'll be easier to manage
duties.
2: Administrators may not be technical professionals and tend to be careless on security.
So admins will not get all the privileges of a super user, in case of a security breach,
system's damage will be minimal.
3. All the important privileges should not be accessible to a one admin.
4. Super user can define what others may see, access and operate.
36 | P a g e
3. Activity diagrams
3.1 Super user
37 | P a g e
3.2 Administrator
38 | P a g e
3.3 Student
39 | P a g e
3.4 Guest
40 | P a g e
4. Nonfunctional requirement
4.1 Product Requirements
4.1.1 Usability Requirements
The Student Registration System shall include three types of accounts; Super User, Administrators
and Students.
To login to the system user name and password is required. The user name shall be name of the
user and the password as they prefer.
If a password is forgotten by a system user, an e-mail should be sent to the relevant e- mail
account with a recovery password within 2 minutes.
The system should be implemented with simple HTML interfaces for it to be easy to understand
and easy to learn.
Interface action and elements should be consistent.
Only limited attractiveness is required since the system is for the internal university community.
There should be help pages included that explain how to achieve common tasks.
It should also include error messages explaining how to recover from the error.
The actions which cannot be undone should ask for confirmation.
4.1.2 Efficiency Requirements
The system should response to user actions within 20ms

The system should handle 100 users/second
4.1.3 Performance Requirements
4.1.3.1 Reliability Requirements
Database processing time should not exceed 100ms

The system shall facilitate data integrity
Downtime with in a day should not exceed 100ms
The system shall be available 24 hours everyday
4.1.3.2 Storage Requirements
The space provision for images should not exceed 200mb

The space provision for the database should be greater than 10GB
If a student drops a selected subject that should be removed from the relevant
tuple of the database
41 | P a g e
4.1.4 Portability Requirements
Users should be able to log in to the system through a PC, a laptop or a smartphone
4.2 Organizational Requirements

4.2.1 Delivery Requirements
The system shall be deployed within six months
The system shall be completed within the allocated budget.
4.2.2 Implementation Requirements
The web based student registration system should be implemented with HTML and CSS
for interfaces, PHP for sever side scripting, Java script for the validation and MYSQL for
database management system.
The environment that shall be hosting the system should contain minimum hardware
requirements.
The environmental that shall be hosting the system should contain minimum software
requirements. (Windows XP/ Vista / 7, Linux Debain 6.*, operating system, PHP version
5.3.)
The university staff will shall be provided with training upon implementation.
4.2.3 Standard Requirements
A student shall complete minimum of 30 credits per semester.
Cancellation of a registered subject is permitted within 14 days of selection and it is subject to the decision of the Super user.
Registration cancellation deadlines for courses should be available in the course information. Contact Super user for more information.
Public viewer shall be able to search results of a particular student by entering the student
index number and the registration number.
4.2.4 Operational Requirements
University will require appropriate staff and other resources for the new system.
There shall be an initial Super User in the system, who can login in to the system.
The Super user shall create accounts for the administrators.
The Administrator shall create accounts for the students.

42 | P a g e
4.3 External Requirements

4.3.1 Interoperability requirements
The system shall be interoperable with the other existing systems of the university.
4.3.2 Ethical requirements
GPA should be calculated in accordance with the standard procedure.

The super user shall not be permitted to change students personnel data.
4.3.3 Legislative requirements
4.3.3.1 Privacy requirements
The system shall not disclose personnel information of students to unauthorized users or public.
4.3.3.2 Safety requirements
Guest users must not be able to edit any information

The system shall be facilitated with a backup file system
43 | P a g e
5. Entity relationship diagram
44 | P a g e
User
Super User
Administrator
Student
Department
Course
ControlMatrx
ResultPrevi
ew
Notice
TimeTable
Subjects
SubjectList
CurrentSeme
ster
ImportantDay
s
Name
SuperUserID
AdminID
Reg_No
DeptName
CourseName
Admin-ID
CourseCode
NoticeID
Coursename
SubName
SubName
SemNo
StartDate
AdminLevel
IndexNo
Name
SubjectName
Title
Day
CourseCode
CourseCode
SubNmae
EndDate
Name
Add users
Result
Description
Time
Credit
Year
ExamDate
Mobile
Remove users
Credits
Author
SubjectName
Year
Manage users
TotalGPA
BeginimgDate
Code
Semester
Password
E mail
View users Profile

Remove selected
subject from
selection
Create new
subjects
Edit existing
subjects
Delete subjects
Create new
subject lists
Make adjustments
of no of credits
Subject
combination tool
Time table
management
Create time table
Update time table
View student
choices
EndingDate
Coordinator
5.1 Entity and Attributes
Result preview
Reg-no Index-no Course code Name Sub-name Result Credits Total GPA
Subjects
Code Semester Year Credits Sub-name Admin-ID
Stu- Regdent no
InFname Lname ModexNo

bile
Important days
Compulsory
Sem-no
Year
Sub-name
Credit
Deptname
Sub-name
Code
Course
name
Pass- Email Name

word
End date Start date
Year
Exam date
Semester
Optional
Sub-name Credit Code Year
Semester
Notices
Title Start date End date Author Description Notice-ID Admin-ID
Super user
Super user ID
Include
Course name Code
Course
Course name Dept-name
Admin
Admin-ID
User
Name E-mail Password
Admin-level
Current semester Sem-no Year Sub-name

Time table
Code Day Time Sub name Course name
Subject list
Course code
Subject name
Semno
Year
6. Class diagram
47 | P a g e
7. Verification and Validation

Verification and Validation is a process that should be applied to all stages of the software
development life cycle.
7.1 Verification
Verification is the process of assuring that the software meets its specifications. This is a human
based approach to ensure that the software is as per the requirements specification.
Validity check :
Checking the extent to which the requirements of each stakeholder is met and the compromises
made.
Consistency check :
Checking whether the requirement contradict with each other.
Completeness check :
Checking whether the SRS covers all the functional requirements of the Student Registration
System
Realism check :
Checking whether the identified requirements can be met with the existing technology, budget
and time constraints.
To perform the above checks we will be using the following activities.
Requirements review :
This approach is where the requirements are analyzed by a review team systematically. The
review team will be consisting of members of the development team and academic and nonacademic staff members.
Inspection :
This is involves a team of inspectors who will be given the code and associated documents to
discover errors. The inspection team will consist of some of the developers and representatives
of the client.
48 | P a g e
Walkthroughs :
This is an informal approach which involves both developers and the client of the Student
Registration System. This will be helpful in achieving a common understanding and to gather
feedback.
7.2 Validation
This is the dynamic mechanism of validating and testing the Student Registration System. This
involves executing the code.
Prototyping :
An executable model of the Student Registration System will be given to the client and the end
users. The prototype then will be used to identify necessary changes to the requirements.
Test case generation :
Test cases are generated based on test scenarios produced. There will be number of test
scenarios for the Student Registration System on which test cases are developed.
e.g.: Checking the functionality of the login button.
The test cases for this scenario will be:
o
o
o
o
o
Click the button without entering the user name and password
Click the button after only entering user name
Click the button with wrong username and wrong password
Click the button with correct username and wrong password
Click the button with correct user name and correct password
Component Testing :
The different components of the Student Registration System is tested in Isolation.

e.g.: Login component: test whether the component can check the validity/invalidity of a given
username and password.
49 | P a g e
Integration Testing :
Testing the system for correct interactions between the system components. This will be done
by developer/testers with the use of test cases. Integration testing will discover the
inconsistencies in the combination of components.
E.g.: testing whether login component route to the student component without causing
problems when a student successfully login to the system.
Stress Testing :
This is the test which is performed to test how a system behaves when it fails. Stress testing is
carried by exercising the system beyond its maximum design load or by taking away resources
to identify the breaking point.
e.g.:
o Test how the system reacts when 125users/sec log in to the Student Registration System.
o Shut down or restart of network ports randomly
o Turning the database on and off
Security Testing :
This involves testing the Student Registration System in order to identify flaws and gaps from
security and vulnerability point of view. The following aspects of the system is tested under
security testing;
o
o
o
o
o
Confidentiality
SQL insertion attacks
Data security
Authorization
System is according to all security regulations
50 | P a g e
Team name:
Team leader:
Members:
Humming Bird
W.D.R.Y. Jayasundara
Y.M.Y.T.K Yaparatne
K.Gunawardana
K.A.D.C.P. Kaluarachchi
S.D. Thrimawithana
W.D.R.Y. Jayasundara
ICT/10/11/050
ICT/10/11/008
ICT/10/11/057
ICT/10/11/032
ICT/10/11/013
2687
2640
2650
2675
2648
51 | P a g e

Srsfinaledit 140325142901 Phpapp02

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Srsfinaledit 140325142901 Phpapp02

Uploaded by

Copyright:

Available Formats

Software Requirement

Rajarata University of Sri Lanka

: Login into the system.09

1.3 Intended Audience

Shows the activities involved in a process or data processing

Entity Relationship Diagram; Data model for describing

Hyper Text Markup Language

Hypertext preprocessor; an open source scripting language

Internal student of Rajarata University of Sri Lanka

Person of the academic or non-academic staff who has

Use case diagram

UML A beginners guide- Jason T Roff

1.6 Overview of the Document

2.1.2 Use case diagram for administrator

2.1.3 Use case diagram for student

2.1.4 Use case diagram for guest

2.2 Use cases

Login into the system.

Main Success Scenario

User selects a login option.

: Change user password

Main Success Scenario

Main Success Scenario

Main Success Scenario

Main Success Scenario

Main Success Scenario

User login with their passwords and usernames.

: Remove selected subjects from student's selections

Main Success Scenario

User logs into the system

5. Select confirmation to proceed

: Create new subjects

Main Success Scenario

User logs in as administrator/super user

1. New subjects will have to be introduced with Super user approval

: Edit existing subjects

Main Success Scenario

User login as an Administrator/Super user

Main Success Scenario

User login as Administrator/Super user

: Create new subject lists

Main Success Scenario

User selects apply changes immediately.

: Make adjustment of credits per subjects

User login as an Administrator/Super user

1. Credit levels should be determined considering lecture hours and no of

: Subject combination tool

Main Success Scenario

User logs into the system.

: Publish time table

Main Success Scenario

Subject coordinating administrators log into system

: Update time table

Main Success Scenario

Subject coordinating administrators log into system

User confirms even though there's conflicts present

Database update fails

: Current subjects by subject vice

Main Success Scenario

User logs into the system

1. Only viewing, no editing capability is provided.

: Past subject selections by subject vice