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

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

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

Software requirement specification

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Software requirement specification

Semelhante a Software requirement specification (20)

Mais de Ravi Yasas

Mais de Ravi Yasas (11)

Último

Último (20)

Software requirement specification