Software requirement specification

Software Requirement

Specification Student registration System

Rajarata University of Sri Lanka Faculty of Applied Sciences

INFORMATION AND COMMUNICATION TECHNOLOGY

1 | P a g e

Table of Content 1. Introduction………………………………………………………………………………………………..03

1.1 Purpose…………………………………………………………………………………………..03

1.2 Scope………………………………………………………………………………………………03

1.3 Intended audience………………………………………………………………………….04

1.4 Glossary…………………………………………………………………………………………..04

1.5 References………………………………………………………………………………………05

1.6 Overview…………………………………………………………………………………………05

2. Functional Requirements……………………………………………………………………………06

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 : Login into the system………………………………………………….09

Use Case 2 : Change user password………………………………………………..10

Use Case 3 : Add users………………………………………………………………….…11

Use Case 4 : Remove users………………………………………………………………12

Use Case 5 : Manage users……………………………………………………………...13

Use Case 6 : Edit profile information……………………………………………….14

Use Case 7 : Remove selected subjects from student's selections…..15

Use Case 8 : Create new subjects……………………………………………………..16

Use Case 9 : Edit existing subjects……………………………………………………17

Use Case 10 : Delete subjects…………………………………………………………….18

Use Case 11 : Create new subject lists……………………………………………….19

Use Case 12 : Make adjustment of credits per subject………………………20

Use Case 13 : Subject combination tool ……………………………………………21

Use Case 14 : Publish time table………………………………………………………..22

Use Case 15 : Update time table………………………………………………………..23

Use Case 16 : Current subjects by subject vice…………………………………..24

Use Case 17 : Past subject selections by subject vice…………………………25

Use Case 18 : View past & present subject selections of a student……26

Use Case 19 : Edit student's profile…………………………………………………….27

Use Case 20 : Select subjects………………………………………………………………28

Use Case 21 : Remove subjects from the list………………………………………30

Use Case 22 : Save………………………………………………………………………………31

Use Case 23 : View previous semester information…………………….………32

Use Case 24 : View Notices…………………………………………………………………33

Use Case 25 : Guest view of the student's profile……………………………….34

Use Case 26 : Super user confirmation……………………………………………….35

Use Case 27 : Access Control Matrix…………………………………………..………36

2 | P a g e

3. Activity Diagram…………………………………………………………………………………………..37

3.1 Super user………………………………………………………………………………….……..37

3.2 Administrator……………………………………………………………………………………38

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 requirements………………………………………………………42

4.2 Organizational………………………………………………………………………………….42

4.2.1 Delivery requirements…………………………………………………………42

4.2.2 Implementation requirements………………………………………… ….42

4.2.3 Standard requirements………………………………………………………..42

4.2.4 Operational requirements……………………………………………………42

4.3 External Requirements.…………………………………………………………………….43

4.3.1 Interoperability requirements……………………………………………...43

4.3.2 Ethical requirements……………………………………………………………43

4.3.3 Legislative requirements……………………………………………………..43

4.3.3.1 Privacy requirements………………………………………………43

4.3.3.2 Safety requirements………………………………………………..43

5. Entity Relationship Diagram…………………………………………………………………………44

5.1 Entities and attributes………………………………………………………….................46

6. Class Diagram………………………………………………………………………………………………47

7. Verification and Validation……………………………………………………………………………48

7.1 Verification………………………………………………………………………………………..48

7.2 Validation………………………………………………………………………………………….49

3 | P a g e

1. Introduction

1.

1.1 Purpose

The purpose of this System Requirements Specification is to outline the functional, non-

functional and business requirements of the “Student Registration System” of Rajarata

University of Sri Lanka. The document provides a detailed overview of the software prod-

uct, 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 under-

stood 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 se-

mester, 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

4 | P a g e

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 ad-

ministration 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 pro-

cessing

Administrator Person of the academic or non-academic staff of Raja-

rata university who is authorized to perform important

operations with regard to the Student Registration sys-

tem

Class diagram Shows object classes in the system and the associations

between them

Database A collection of stored related data

ER diagram Entity Relationship Diagram; Data model for describing

a data base in an abstract way

GPA Grade Point Average; an internationally recognized cal-

culation used to find the average results

Guest user A person who doesn’t has a

Html Hyper Text Markup Language

PHP Hypertext preprocessor; an open source scripting lan-

guage

Privilege access matrix 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

Sea level Known as user goal level. Something the actor is trying

to set done other levels kite level, cloud level, fish level

etc.…

Use case diagram Representation of a user’s interaction with the system

and depicting the specifications of a use case

5 | P a g e

1.5 References

UML A beginner’s 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 Registra-tion System.

.

6 | P a g e

2. Functional requirements

2.1 Use case diagram

2.1.1 Use case diagram for super user

7 | P a g e

2.1.2 Use case diagram for administrator

8 | P a g e

2.1.3 Use case diagram for student

2.1.4 Use case diagram for guest

9 | P a g e

2.2 Use cases

Use Case 1 : Login into the system.

Goal level : Sea Level

Aspect : Moderators & users can log into the system to perform various

actions.

Trigger : When someone attempts to use system functions.

Actors : Administrators of various privilege levels.

Super users

Students

Third party users

Preconditions : An activated login

Necessary requirements for public users.

Main Success Scenario

1. User selects a login option.

2. Login interface is produced.

3. User enters password and username.

4. System validates input against system database.

5. System accepts user type.

6. 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. Let’s 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. Let’s 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.

10 | P a g e

Use Case 2 : Change user password


Aspect : Users can change their own login password.

Trigger : User clicks on “change password” after login.

Actors : Administrators

Super users

Student users

Preconditions : 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. 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. 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.

11 | P a g e

Use Case 3 : Add users


Aspect : Add users into the system.

Trigger : When administrator clicks on “Add users”.

Actors : Administrators with sufficient privileges, Super user.

Preconditions : 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.

12 | P a g e

Use Case 4 : Remove users


Aspect : Remove existing users from the systems.

Trigger : When user clicks on “Remove users”.

Actors : Admin

Super user

Preconditions : 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 Admin’s

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 admin’s 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.

13 | P a g e

Use Case 5 : Manage users


Aspect : Allow/restrict certain users to perform their default privileges.

Suspend user accounts temporarily.

Modify user's profile type/privileges.

Actors : Super user

Preconditions : 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

14 | P a g e

Use Case 6:


Aspect : Edit profile information

Trigger : When user selects Edit profile information

Actors : Administrators, Super user

Preconditions : User must be logged in as Administrator/Super user


1. User login with their passwords and usernames.

2. User selects Edit profile information

3. System shows editable version of user's profile.

4. User make desired changes.

5. User confirms changes

6. System saves changes to the main database.

7. 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

15 | P a g e

Use Case 7 : Remove selected subjects from student's selections


Aspect : Remove subjects from the selection

Trigger : User clicks on remove subjects

Actors : Administrators, Super users

Preconditions : User must be logged in as privileged actor


1. User logs into the system

2. Select “subject operations”

3. Select “Remove selected Subject”

4. 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.

16 | P a g e

Use Case 8 : Create new subjects


Aspect : Introduce new subjects into the system

Trigger : When user selects “Create new subjects”

Actors : Administrators, Super user

Preconditions : User must login as a privileged administrator, or super user.


1. User logs in as administrator/super user

2. Selects “Subject operations”

3. Selects “Create new subjects”

4. Select relevant Academic year, Semester, Stream and other details *.

5. System views current subject lists that will be affected by the modification.

6. 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

17 | P a g e

Use Case 9 : Edit existing subjects


Aspect : Edit details of existing subjects and alter predefined attributes.

Trigger : When user selects Edit subject’s option

Actors : Administrators with relevant privileges, Super user

Preconditions : User must be logged as an Administrator/ Super user.


1. User login as an Administrator/Super user

2. Select “Subject operations”

3. Select “Edit subjects”

4. Choose relevant Academic year, Semester, Stream

5. System will display subject list in editable view.

6. Make necessary changes.

7. 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.

18 | P a g e

Use Case 10 : Delete subjects


Aspect : Remove subjects from system.

Trigger : User selects “Remove subject” option

Actors : Administrators with relevant privileges, Super users

Preconditions : User must be logged as an Administrator/Super user


1. User login as Administrator/Super user


3. Select “Delete Subjects”'

4. Choose relevant Academic year, Semester, Stream

5. System will display the subject list.

6. Select the subject need to be deleted.

7. Select Delete

8. Confirm to continue

9. System will remove the subject and all its related data, records. *

10. 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

19 | P a g e

Use Case 11 : Create new subject lists


Aspect : Add new subject lists into the student's selections

Trigger : When user selects to add subject list






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 *


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.

20 | P a g e

Use Case 12 : Make adjustment of credits per subjects


Aspect : Adjust no of credits defined for a Subject

Trigger : User selects Adjust no of credits option



1. User login as an Administrator/Super user


3. Select “Make adjustment of no of credits”

4. Choose relevant Academic year, Semester, Stream.

5. System will display subject list with credits in editable view.

6. Make necessary changes.



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.

21 | P a g e

Use Case 13 : Subject combination tool


Aspect : Subject combinations that students are able to select and

incompatible combinations will be defined.

Trigger : When user selects “Subject combination tool”




1. User logs into the system.


3. Selects “Subject combination tool”

4. Selects Academic year, Semester, Stream.

5. System will display an editable matrix to select which core subjects cannot be

selected with each other.

6. Select which subjects cannot be taken simultaneously?

7. System will display editable matrix to select which subjects should be taken with

each other simultaneously.

8. Select which subjects that should be taken together.

9. System will show any rising conflicts.

10. User confirm changes and resume.

11. 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.

22 | P a g e

Use Case 14 : Publish time table


Aspect : Creating timetables for students

Trigger : User click on create timetables option




1. Subject coordinating administrators log into system

2. Create timetables and allocate practical times in Labs

3. System shows conflicts and problems likely to rise

4. User confirms timetables

5. System saves timetables and notify relevant users by notices upon login.

6. 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.

23 | P a g e

Use Case 15 : Update time table


Aspect : Modify existing timetable

Trigger : User selects timetable updating option.




1. Subject coordinating administrators log into system

2. Select Edit timetable option.

3. Select relevant academic year, stream, and semester

4. System view show editable timetable.

5. Edit subjects, scheduled time, practical sessions and other details

6. System shows any conflicts or likely to rise problems.


8. System updates databases.

9. 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.

24 | P a g e

Use Case 16 : Current subjects by subject vice


Aspect : View student's selections by subject vise

Trigger : User selects to view student's current subject selections





2. Select “View student's choices” option.

3. Enter student's index number


5. System will display information view interface with options.

6. Select “Current 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 :

1. Only viewing, no editing capability is provided.

25 | P a g e

Use Case 17 : Past subject selections by subject vice


Aspect : To view student's past subject selections

Trigger : User selects view student's subject selections option.









6. Select “Past subjects by subject vise”



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 :


26 | P a g e

Use Case 18 : View the past and present subject selections of a student


Aspect : View all past and present subject selection of student.

Trigger : User select the subject selection option.









6. Select “Past and present subject selections by subject vise”



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 :


27 | P a g e

Use Case 19 : Edit student's profile


Aspect : Let student to edit his/her profile

Trigger : Student selects Edit profile option

Actors : Student user

Preconditions : Users should login to system as student users


1. Users log into system using username/password

2. System provides an editable interface of student's profile.

3. Edits selected data and values.

4. Selects other options if needed.

5. Confirms changes

6. 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.

28 | P a g e

Use Case 20 : Select subjects


Aspect : Student user can select their subjects from available subject lists

Trigger : User selects “Select subjects” option

Actors : Student Users

Preconditions : User must be logged as a Student


1. User login as a student with his/her username/password.

2. Selects “Select subject” option

3. System determines Student's academic year, semester, and stream

4. System determines whether student is eligible to take subjects*

5. System displays available subject list

6. Student selects desired subject levels under defined constraints**


8. System will check necessary requirements of the selection.

9. System displays time period remaining to alter student's selection.

10. System saves changes into the databases.

11. 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.

29 | P a g e

2: User re-arrange his/her selection.

3: System will save changes.

8b: 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.

30 | P a g e

Use Case 21 : Remove subjects from the list


Aspect : Student can remove subject that he/she selected earlier

Trigger : When student user needs to change subject selection

Actors : Student users

Preconditions : 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.

31 | P a g e

Use Case 22 : Save


Aspect : Save changes users make in the system into database

Trigger : When any user make an update, input a data into the system

Actors : System

Preconditions : 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.

32 | P a g e

Use Case 23 : View previous semester information


Aspect : Student will see an overview of his/her previous semesters

Trigger : Student selects “View previous semester’s information” option.

Actors : Student users

Preconditions : 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 :


33 | P a g e

Use Case 24 : View Notices


Aspect : Student's will see important notices generated by system changes,

and administrators.

Trigger : When there's a change occurred, a relevant notice will be generated.

Actors : System, Administrators

Preconditions : 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.

34 | P a g e

Use Case 25 : Guest view of the student's profile


Aspect : People outside the system will be able to view records of a student

with his index number.

Trigger : When someone outside the system logged into the system.

Actors : Guests

Preconditions : 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.

35 | P a g e

Use Case 26 : Super user confirmation


Aspect : 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.

Trigger : When a super user logs into the system with username/password

Actors : Super user


1. Super user enter username/password into the system.

2. An additional email will be sent to the assigned email account with a key.

3. User logs into the relevant email and enter the Key to the login

4. 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.

36 | P a g e

Use Case 27 : Access Control Matrix


Aspect : Super user defines other administrator's privileges and access

capabilities

Trigger : When user selects “Access Control Matrix”

Actors : Super users

Preconditions : User must be logged as a Super user


1. Super user selects “Access control Matrix”

2. User “selects subject operation” combo box.

3. Define what each user is capable of doing.

4. System sends notification to other users if “send notifications” selected.

4. 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.

37 | P a g e

3. Activity diagrams

3.1 Super user

38 | P a g e

3.2 Administrator

39 | P a g e

3.3 Student

40 | P a g e

3.4 Guest

41 | 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

42 | 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 sub-

ject to the decision of the Super user.

Registration cancellation deadlines for courses should be available in the course infor-

mation. 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.

43 | 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 unau-

thorized 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

44 | P a g e

5. Entity relationship diagram

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

Password AdminLevel IndexNo Name SubjectName Title Day CourseCode CourseCode SubNmae EndDate

E mail Name Add users Result Description Time Credit Year ExamDate

Mobile Remove users Credits Author SubjectName Year

Manage users TotalGPA BeginimgDate Code Semester

View users Profile EndingDate Coordinator

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

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-

dent

Reg-

no

In-

dexNo

Fname Lname Mo-

bile

Dept-

name

Course

name

Pass-

word

Email Name Sem-

no

Year

Important days Sem-no Year Sub-name End date Start date Exam date

Compulsory Sub-name Credit Code Year 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 Admin-level

User Name E-mail Password

Current semester Sem-no Year Sub-name

Time table Code Day Time Sub name Course name

Subject list Course code Subject name

47 | P a g e

6. Class diagram

48 | 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 non-

academic 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.

49 | 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 Click the button without entering the user name and password

o Click the button after only entering user name

o Click the button with wrong username and wrong password

o Click the button with correct username and wrong password

o 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.

50 | 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 Regis-

tration 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 Confidentiality

o SQL insertion attacks

o Data security

o Authorization

o System is according to all security regulations

51 | P a g e

Team name: Humming Bird

Team leader: W.D.R.Y. Jayasundara

Members:

Y.M.Y.T.K Yaparatne ICT/10/11/050 2687

K.Gunawardana ICT/10/11/008 2640

K.A.D.C.P. Kaluarachchi ICT/10/11/057 2650

S.D. Thrimawithana ICT/10/11/032 2675

W.D.R.Y. Jayasundara ICT/10/11/013 2648

Education

Software requirement specification