EE5206 Project SRS Final

Faculty of Engineering - University of Ruhuna
Software Requirement
Specification
Group 13
Version 1.0
10/29/20
OBE Curriculum Planning Tool Version: 1.0
Software Requirements Specification Date: 03-11-2020
EE3506/2020/SRS/Group 13
VERSION AND APPROVALS

This document has been approved as the official Software Requirements Document for OBE
Curriculum Planning Tool, and accurately reflects the current understanding of business
requirements. Following approval of this document, requirement changes will be governed
by the project’s change management process, including impact analysis, appropriate reviews
and approvals.
Document Approvals
Approver Name Project Role Signature/Electronic Date

Approval
Dr. Rajitha Project Supervisor

Udawalpola
Mr. Anduradha Project Supervisor

Mudhalige
Confidential ©<Company Name>, 2020 Page 1

PROJECT DETAILS
Project Name OBE Curriculum Planning Tool
Project Type New Initiative
Project Start Date 15/09/2020
Project End Date 05/02/2021
Project Sponsor No
Implementing an Outcome Based Education Curriculum

Primary Driver
Planning System
Secondary Driver Optimized Computer system instead of manual system
Division Software Division
Project
Department of Electrical and Information Engineering
Manager/Dept

OVERVIEW
This document defines the high-level requirements of OBE Curriculum Planning Tool. It will
be used as the basis for the following activities:
➢ Samples
➢ requirement gathering
➢ development tools
➢ project initiation
DOCUMENT RESOURCES
Name Business Unit Role
Lecturers Faculty of Engineering, University Teacher and Content creator

of Ruhuna
Students Faculty of Engineering, University Student

of Ruhuna
Administrative Faculty of Engineering, University Course Creator

staff of Ruhuna

GLOSSARY OF TERMS
Term/Acronym Definition
SRS Software Requirement Specification
ER Entity Relationship
OBE Outcome Based Education
CSS Cascade Style Sheet
HTML Hyper Text Markup Language
SQL Structured Query Language
HTTP Hypertext Transfer Protocol
JS Java Script
TCP/IP Transmission Control Protocol/Internet Protocol
UML Unified Modeling Language
ASP Active Server Pages
GUI Graphical User Interface

MSSMS Microsoft SQL Server Management Studio

Contents
Version and Approvals 1
Project Details 2
Overview 3
Document Resources 3
Glossary of Terms 4
Introduction 15
1.1 Purpose 15
1.2 Document Conventions 15
1.3 Intended Audience(stakeholders) and Reading Suggestions 15
1.4 Product Scope 16
1.5 References 16
Overall Description 17
2.1 Product Perspective 18
2.1.1 System Interfaces- 18
2.1.2 Interfaces 18
2.1.3 Hardware Interfaces 19
2.1.4 Software Interfaces 20
2.1.5 Communications Interfaces 21
2.1.6 Memory Constraints 21
2.1.7 Operations 21
2.1.8 Site Adaptation Requirements 21
2.2 Product Functions 21

2.3 User Classes and Characteristics 22

2.4 Operating Environment 23
2.5 Design and Implementation Constraints 23
2.6 Stakeholders 24
2.7 User Documentation 25
2.8 Assumptions and Dependencies 25
2.9 Apportioning of Requirements. 26
Functionality Requirements 27
3.1 Functionality 1 28
3.1.1 Description and Priority 28
3.1.2 Stimulus/Response Sequences 28
3.1.3 Functional Requirements 28
3.1.4 Use case diagram 28
3.1.5 Sequence Diagram 31
3.2 Functionality 2: 32
3.2.6 System Mock-up Screens 35







3.3 Logical Database Requirement 96
Non-functional Requirements 97
4.1 Performance Requirements 97
4.2 Safety Requirements 97
4.3 Security Requirements 97
4.4 Software Quality Attributes 98
4.5 Business Rules 99
Other Requirements 100
5.1 Online User Documentation and Help System Requirements 100
System Architecture 101
6.1 Component Architecture 103
6.2 Physical Architecture 104
Appendix A: Glossary 105
Appendix B: Analysis Models 105
Appendix C: To Be Determined List 105

List of Figures
Figure 2. 1 OBE Curriculum Design Process ......................................................................... 17
Figure 2.3. 1:- User Class diagram........................................................................................ 22
Figure 3.2. 1:Creating Lecturer Profile ................................................................................. 35
Figure 3.3 1:- Creating Student Profile ................................................................................. 39
Figure 3.4. 1:-System Login Sequence diagram .................................................................... 44

Figure 3.4. 2:- Login Page Mockup Screen ........................................................................... 45
Figure3.5. 1:- Create Course Sequence Diagram .................................................................. 49

Figure3.5. 2:- Create Course Mockup Screen ....................................................................... 50
Figure3.6. 1:- Edit Course Sequence Diagram ...................................................................... 54

Figure3.6. 2:- Edit Corse Mockup Screen ............................................................................. 55
Figure 3.7. 1:- Delete Course Sequence Diagram ................................................................. 59

Figure 3.7. 2:- Delete Screen Mockup Screen ...................................................................... 60

Figure 3.8. 1:- Adding Privileges to a Lecturer Sequence Diagram........................................ 64

Figure 3.8. 2:- Adding Privileges to a Lecturer to a Module Mockup Screen ......................... 65
Figure 3.9. 1:- Delete Privileges from a Lecturer .................................................................. 68

Figure 3.9. 2:- Delete Privileges from Lecturer Mockup Screen ............................................ 69
Figure 3.10. 1:- Add LO, PO.................................................................................................. 73

Figure 3.10. 2:- Add LO, PO Mockup Screen ........................................................................ 74
Figure 3.11. 1:- Edit LO, PO Sequence Diagram .................................................................... 78

Figure 3.11. 2:- Edit LO, PO Mockup Screen ......................................................................... 78
Figure 3.12. 1:- Delete LO, PO Sequence Diagram ............................................................... 82

Figure 3.12. 2:- Modules Interface Lecturer ......................................................................... 83
Figure 3.12. 3:- Add, Edit and Delete LO, PO Mockup Screen ............................................... 83
Figure 3.13 1:- Add Feedback Sequence Diagram ................................................................ 88

Figure 3.13 2:- Module Mockup screen for Student ............................................................. 89
Figure 3.13 3:-Feedback Adding Mockup Screen ................................................................. 89

Figure 3.14 1:- Adding and Viewing Results Sequence Diagram ........................................... 94
Figure 3.14 2:- Results Mockup Screen ................................................................................ 95
Figure 6. 1:- System Architecture ....................................................................................... 101

Figure 6. 2 :- Deployment Diagram ................................................................................... 102
Figure 6.4. 1:-Physical Architecture ................................................................................... 104

INTRODUCTION
1.1 Purpose
The base of the module content is the learning outcomes. The whole content is created as
covering the learning outcomes. In this project we are going to supply the possibility to
lectures to get to know how students have achieved learning outcomes. As well as students
can identify their achievements by themselves. Outcome-Based Education (OBE) represents
a clearly focused and powerful system of organizing and operating. Course professional
knowledge, skills, abilities, values and attitudes are the main focus points of OBE. By following
OBE students can improve their studies. As well as lectures can confirm success or failure of
teaching methods. In order to that overall targets can be achieved effectively.
The complete scope of the product is covered in this SRS
1.2 Document Conventions
In this document font ‘Calibri’ is used for all the text content in the document. All the main
headings are from font size 18 purple color. Headings are from font size 14 bold and the sub
topics are from font size 12 bold Italic text refers to web links.
This Document was created based on the IEEE template for System Requirement Specification
Documents.
1.3 Intended Audience(stakeholders) and Reading Suggestions
This project is a prototype for the OBE system and it is limited within the faculty premises.
This has been implemented under the guidance of the administration and the lecturers. This
project is useful for the below parties.
● Lecturers

● Current students
● Future students
● Accreditation panels
● University Grants Commission
Document should be read in given order.
1.4 Product Scope
In this project our intention is to make a system to define Learning outcomes program
outcomes, course outcomes and assess students based on those outcomes. Head of the
department will have the authorization to create the courses and the lecturers will be able to
define the outcomes and plan evaluations. Attainment calculation is done in both direct and
indirect approaches.
The direct attainment comprises results from class tests and final exam. Indirect
attainment consists of various surveys like CO exit survey, PO survey, alumni and feedback
forms. Based on the feedback, lecturers can change the teaching methods and assessment
methods (Quiz/Essay type Questions/ Laboratories).
1.5 References

OVERALL DESCRIPTION
The software OBE curriculum planning tool project is prepared for academic works of faculty.
In OBE systems the learning outcomes, program outcomes and course outcomes are properly
defined. The pre-defined outcomes are expected to help students accomplish their
educational goals. Students get a complete awareness of what they are going to learn prior
to starting the course. And they also can self-assess themselves. Lecturers as well as students
get benefits by the OBE systems. Lecturers can plan the module according to the outcomes
and evaluate students through exams. Assessments and exams ensure that the program
outcomes are achieved.
Figure 2. 1 OBE Curriculum Design Process

2.1 Product Perspective
This system is a new self-contained product. Main system is Outcome Based Learning system
and it consists of two subsystems known as Curriculum planning tool and result analysis tool.
This sub system is developed for those who are interested in Outcome Based Education. This
product mainly can be used to plan curriculum.
This system is a new self-contained product. Main system is the Outcome Based Learning
system and it consists of two subsystems known as Curriculum planning tool and result
analysis tool.
2.1.1 System Interfaces-
● Front end: React JS library, html, CSS, Bootstrap, JavaScript
● Back end: ASP.net core
● Database: MSSMS
2.1.2 Interfaces
The users of the system are lectures and students of the faculty. administrator to maintain
the system. The members we assumed to have basic knowledge of the computers and
internet browsing. The administrators of the system should have more knowledge of the
internals of the system and are able to rectify the small problems that may arise due to disk
crashes, power failures and other catastrophes to maintain the system. The proper user
interface, user manual, help and the guide to install and maintain the system must be
sufficient to the users to use the system without any problem.
● The admin provides certain facilities to the users in the form of Backup and Recovery

Forgot Password.
• The server must be maintained regularly and it has to be updated from time to time.
2.1.3 Hardware Interfaces
Server Side
Processor 1 GHz
RAM 512 MB
DISK SPACE
32-bit 4.5 GB
64-bit 4.5 GB
Chrome version: - Version 86.0.4240.111

2.1.4 Software Interfaces
Name Version Number Source
Windows 10,
Operating system
(Windows, Ubuntu)
Ubuntu 18.04
ASP.NET core Web API v 3.1.9 Microsoft Corporations
NodeJS v14.15.0 Open source
Visual Studio 2019 v16.4 Microsoft Corporation
Visual studio code v1.47.1 Microsoft Corporation
ReactJs v16.13.1 Open Source
HTML v5.0 World Wide Web

Consortium
JavaScript ES6
Bootstrap v4.0 Open Source
CSS v3.0 World Wide Web

Consortium
MSSMS 18 Microsoft corporation

2.1.5 Communications Interfaces
• STMP
• FTP
• HTTP
• TCP
• Broadband Connection with Internet
2.1.6 Memory Constraints
Not applicable
2.1.7 Operations
Data stored in the server will be backed up to the cloud from midnight to 2.00 am. This is
because all data updated in the day time can be successfully uploaded in the night time.
2.1.8 Site Adaptation Requirements
No site adaptation requirements.
2.2 Product Functions
• Create a Courses
• Create profiles
• Assign roles
• User authentication
• Add COs, LOs and POs
• Map LOs and POs
• Get feedbacks
• Assess the Achievement of the Outcomes
• Upload results

2.3 User Classes and Characteristics
Figure 2.3. 1:- User Class diagram

2.4 Operating Environment
Name Mnemonic Specification Version Number Source

Number
.NET Core 3.1 Microsoft

Corporation
ReactJs 16.13.1 Open Source
SQL Server 18.6 Microsoft

Management Corporation
Studio
2.5 Design and Implementation Constraints
The Product is developed using ASP.NET Core and the backend database for this is SQL Server.
The product is accomplished with a login facility so that specific functions are available to
specific users. Therefore, it is expected that the database would perform functionally all the
requirements that are specified by the administrator.
The database may get crashed at any certain time due to virus or operating system failure,
Therefore, it is required to take the database backup.
In this project we intend to develop a secured database for the faculty. There are different
categories of users namely lecturing staff, administrator, students etc. Depending upon the
category of user the access rights are decided. Therefore, proper user authentication should

be provided. It means if the user is an administrator then he can be able to modify the data
delete append etc. And also no one should be able to hack a user's password. The Quality of
the database is maintained in such a way so that it can be very user friendly to all the users of
the database.
The system requires a database in order to store persistent data. The database should have
backup capabilities. The development of the system will be constrained by the availability of
required software such as web servers, database and development tools.
2.6 Stakeholders
The following comprises the internal and external stakeholders whose requirements are
represented by this document:
Stakeholders
1. Lecturers
2. Students
3. Alumni

2.7 User Documentation
An Introductory session will be carried out to give a basic training for the system when the
system is delivered.
Short videos will be provided about the software products.
2.8 Assumptions and Dependencies
# Assumptions
The coding should be error free and the system should be user friendly so that it is
easy to use for the users. The information of all users, courses must be stored in a
database that is chasuble by the website. The system should have more storage
capacity and provide fast access to the database. The system should provide search
facility and support quick transactions
This System is running 24 hours a day Users may access from any computer that has
Internet browsing capabilities and an Internet connection
Users must have their correct usernames and passwords to enter into their online
accounts and do actions
The end users (admin) should have proper understanding of the product

The system which runs the application should have basic requirements listed in the
document.
The information of all the users must be stored in a database that is accessible by the
system admin.
# Constraints
2.9 Apportioning of Requirements.
Adding of Result analysis tool to the curriculum planning tool.

FUNCTIONALITY REQUIREMENTS
Figure 3. 1:- Complete Use case diagram

3.1 Functionality 1
Create a profile for faculty administrator
3.1.1 Description and Priority
Creating a profile for the faculty administrator is done by the network administrator. It has
high priority. In this system the Faculty administrator has high level controlling power. He is
the major role of this system. Other users are also controlled by the faculty administrator. So,
this function is the important one. Without proper authentication to the faculty administrator
system cannot be handled properly.
Priority: High
3.1.2 Stimulus/Response Sequences
3.1.3 Functional Requirements
3.1.4 Use case diagram
Use Case ID: 01
Use Case Name: Create profile for faculty administrator
Created By: Network administrator Last Updated By:
Date Created: Date Last Updated:

Actors: Network Administrator, Faculty administrator
Description: Giving privilege to the faculty administrator to create courses, assign

lecturers.
Preconditions: Faculty administrator group identity has been authenticated
Postconditions: Authenticate the access of faculty administrator by giving full

authentication by the network administrator
Normal Course: 1) Starting web browser

2) Navigate to the application via URL
3) Make the login for the faculty administrator
4) Transferring the authentication details to the faculty admin
Alternative Courses: None
Exceptions: None
Includes:
Priority: High
Frequency of Use: Once for a Faculty administrator
Business Rules

Special Requirements: 1)System can support English language
Assumptions: None
Notes and Issues: None

3.1.5 Sequence Diagram
Figure 3.1. 1:- Creating Faculty Administrator Profile

3.2 Functionality 2:
Create profile for faculty Lecturers
Create profile for faculty lectures are done by Network administrators. After the faculty
administrators, lectures have controlling power of this system. They also have big
responsibilities. With lecturers’ proper handling the outcome of the system can be taken
effectively.
Priority: High
Use Case ID: 02
Use Case Name: Create profile for lecturers

Actors: Network administrator, Lecturer
Description: Giving logging access to lecturers
Preconditions: Faculty lecturer group identity has been authenticated
Postconditions: Authenticate the access lectures to logging by giving full authentication

by the network administrator

3) Make the login for the faculty administrator
4) Transferring the authentication details to the faculty
administrator
Exceptions: None
Includes:
Priority: High
Frequency of Use: Once for a Faculty lecturer
Business Rules

Assumptions: None

Figure 3.2. 1:Creating Lecturer Profile
3.2.6 System Mock-up Screens
3.3 Functionality 3
Create profile for faculty students

Create profile for faculty students is done by the network administrator. Students only have
privilege to view and give feedback. They do not contribute to handling the system.
Priority: Medium
Use Case ID: 03
Use Case Name: Create profile for students
Actors: Network administrator, Student
Description: Giving logging access to students
Preconditions: Faculty student group identity has been authenticated

Postconditions:

3) Make the login for the students
4) Transferring the authentication details to the faculty admin
Exceptions: None
Includes:
Priority: Medium
Frequency of Use: Once for a Faculty student
Business Rules
Assumptions: None


Figure 3.3 1:- Creating Student Profile

3.4 Functionality 4
Login
All users should log into the system at first. For that they should enter the correct password
and username. If the system cannot identify the user system does not allow to log the system.
Priority: High
Stimulus: The user clicks the login button
Response: The systems provides the login form
Stimulus: The user enters the relevant user name and the password
Response: The system logs the user to the system and give the authorization
REQ-1: The system allows the user to login to the system with filling user name and
password fields.
REQ-2: The system allows user to re-enter the user name or password if they are incorrect.
REQ-3: The system should validate user and log to the system as a authorized user.

Use Case ID: 04
Use Case Name: Login
Created By: Last Updated By:
Actors: Faculty administrator, Lecturers, Students
Description: Login to the system by using the login details as username and password
Preconditions: User has a login created by the Network Administrator
Postconditions: Login to the OBE system
Normal Course: 1) Open the browser and navigate to the system login
2) Log in to the system by providing username and password
Exceptions: Display error message if the login username and password is not matched

Includes: None
Priority: High
Frequency of Use: Every time a user logs in to the system
Business Rules
Special Requirements: Response times comparable to common web mapping solutions
24/7 access
low memory usage
low bandwidth usage
Assumptions: None
Notes and Issues:


Figure 3.4. 1:-System Login Sequence diagram

Figure 3.4. 2:- Login Page Mockup Screen
3.5 Functionality 5
Create course
The course is created by the faculty administrator. They decide the courses that are offered
to students.
Priority: High

Stimulus: Log into the system
Response: Validate the user and log the user to the system as a Admin
Stimulus: Admin clicks the create a course button
Response: Fill the form of the course details
Stimulus: User clicks the submit button
Response: Success message appeared
REQ-1: The system allows users to submit the forms and save it in the database.
Use Case ID: 05
Use Case Name: Create course
Created By: Faculty administrator Last Updated By:
Actors: Faculty administrator

Description: Creating a module by the faculty administrator. Faculty administrators

can create multiple modules.
Preconditions: The password entered is correct
User has been assigned as a faculty administrator
Postconditions: Course has been created
Normal Course: 1) log in to the system

2) Verify as a faculty admin
3) Create the course
4) Define Course Outcomes
Exceptions: None
Includes: None
Priority: High
Frequency of Use: Once per course
Business Rules
24/7 access

Assumptions: None
Notes and Issues:

Figure3.5. 1:- Create Course Sequence Diagram

Figure3.5. 2:- Create Course Mockup Screen
3.6 Functionality 6
Edit course
Edit course is done by the faculty administrator. It does not do frequently. From the result
analysis they decide what are the suitable changes of courses. It is not an essential thing.

Priority: Medium
Response: Validate the user and log the user to the system as a Admin
Stimulus: Admin clicks the Edit course button
Response: Auto Fill the form of the course details
Stimulus: User edit the course and enter submit button
REQ-1: The system should check the all the required data fields are filled.
REQ-1: The system allows users to edit the course and submit the forms and save it in the
database.
Use Case ID: 06
Use Case Name: Edit course

Description: Edit the module by the faculty administrator. Any changes of the module
content can be done by faculty administrator
Postconditions: Course has been edited
Normal Course: 1) log in to the system

2) Verify as a faculty admin
3) Edit the course
Exceptions: None
Includes: None
Priority: Medium
Business Rules

24/7 access
Assumptions:
Notes and Issues:

Figure3.6. 1:- Edit Course Sequence Diagram

Figure3.6. 2:- Edit Corse Mockup Screen
3.7 Functionality 7
Delete course
Delete course is done by the faculty administrator. Courses are not deleted always. It is
done rarely with the new syllabus updates.
Priority: Low
Response: Validate the user and authorize the user to the system as an Admin

Stimulus: Admin select the course and clicks the Delete course button
REQ-1: The system allows the admin to delete the course and updates it in the database.
Use Case ID: 07
Use Case Name: Delete course
Description: Course can be deleted by the faculty administrator
Postconditions: Course has been deleted
Normal Course: 1) log into the system

2) Verify as a faculty administrator

3) Delete the course
Exceptions: None
Includes: None
Priority: Low
Business Rules
24/7 access
Assumptions:
Notes and Issues:


Figure 3.7. 1:- Delete Course Sequence Diagram

Figure 3.7. 2:- Delete Screen Mockup Screen
3.8 Functionality 8
Add privilege to lectures
Add privilege to lecturers is done by the faculty administrator. Without giving privilege to
lecturers, lecturers cannot do relevant updates.
Priority: High

Stimulus: The user log to the system
Response: The system authorized the user as an admin to the system
Stimulus: User click the assign lecturer button
Response: Lecturers in the department will appear here
Stimulus: Admin select the relevant lecturer and click the assign button
Response: Success message will appear.
REQ-1: System should retrieve the lecturers list
Use Case ID: 08
Use Case Name: Add Privilege to lecturers
Actors: Faculty Administrator, Faculty Lecturers

Description: Giving the privilege to the lecturers to add details, add Learning
Outcomes, Program outcomes and map the outcomes.
Preconditions: Lecturer has been identified to the relevant course
Faculty administrator has been logged into the system
Postconditions: Lecturer has privilege to edit the course details and outcomes
Normal Course: 1) Login as Faculty administrator

2) Assign lecturer to a relevant course
3) Giving privilege to the lecturers
Exceptions: None
Includes: None
Priority: High
Frequency of Use: Once per a lecturer
Business Rules
24/7 access
Basic Computer System Knowledge

Assumptions:
Notes and Issues:

Figure 3.8. 1:- Adding Privileges to a Lecturer Sequence Diagram

Figure 3.8. 2:- Adding Privileges to a Lecturer to a Module Mockup Screen
3.9 Functionality 9
Delete privilege of lecturers
Delete privilege of lecturer is done by the faculty administrator. Then the particular lecturer
cannot do updates in the system. This is done rarely.
Priority: Low

Response: The system authorized the user as a admin to the system
Stimulus: User click the remove Assignation button
Response: Success message will appear.
REQ-1: Remove assignation button should be inactive
Use Case ID: 09
Use Case Name: Delete privilege of lecturer
Actors: Faculty administrator, Faculty lecturers
Description: Remove all privileges of the lecturer, given by the faculty administrator at
the beginning. Lecturer is removed from the course
Preconditions: Faculty administrator group identity has been authenticated

Postconditions: Authenticate the access of faculty administrator by giving full

authentication by the network administrator
Normal Course: 1. Starting web browser

2. Navigate to the application via URL
3. Make the login for the faculty administrator
4. Transferring the authentication details to the faculty admin
Exceptions: None
Includes: None
Priority: Low
Frequency of Use: Once per a lecturer
Business Rules
24/7 access
Assumptions: None

Figure 3.9. 1:- Delete Privileges from a Lecturer

Figure 3.9. 2:- Delete Privileges from Lecturer Mockup Screen
3.10 Functionality 10
Add PO/LO
Add PO/LO is done by the lecturer. This is the basic thing of the system. All analyses are
done based on the PO/LO. Assigned lecturer for the particular course adds relevant PO/LO
for the course.
Priority: High
Response: The system authorized the user as a Lecturer to the system

Stimulus: User click the Add LO/PO button
Response: System provides a form to fill LO/PO
Stimulus: Lecturer fills the relevant details in the form and click submit button
Response: System shows Success message.
REQ-1: System should check whether required fields are filled.
REQ-2: System should update the database
Use Case ID: 10
Use Case Name: Add PO/LO
Created By: Lecturer Last Updated By:
Actors: Lecturer
Description: Adding program outcomes and learning outcomes.
Mapping them with course outcomes.

Preconditions: Lecturer’s identity has been authenticated.
The lecturer has access to the course.
Postconditions: Mapped PO and LO.
Normal Course: 1) Login to the system as a lecturer

2) Navigate to a specific module
3) Add LOs and POs of the module
4) Map LOs and POs with the COs
Exceptions: Display an error message if the Outcomes are not properly added and
mapped
Includes: None
Priority: High
Frequency of Use: Several times for a course
Business Rules None
Special Requirements: Lecturers have a proper knowledge about the outcomes and how to map
them with COs
Assumptions: None


Figure 3.10. 1:- Add LO, PO

Figure 3.10. 2:- Add LO, PO Mockup Screen
Edit PO/LO
Edit PO/LO is done by the faculty lecturers. Assigned lecturer has the privilege to edit PO/LO
of the particular course. It is not always done. According to necessity PO/LO is edited.
Priority: Medium

Stimulus: User click the Edit LO/PO button
Response: System provides an auto filled form.
Stimulus: Lecturer edits the relevant details in the form and click submit button
REQ-1: System should check whether required fields are filled.
Use Case ID: 11
Use Case Name: Edit PO/LO
Created By: Lecture Last Updated By:
Actors: Faculty lecture

Description: Edit program outcomes and learning outcomes.
Mapping them with course outcomes.
Preconditions: Lecturer’s identity has been authenticated.
Postconditions: Updated PO and LO.
Normal Course: 1) Login to the system as a lecturer

2) Navigate to a specific module
3) Edit LOs and POs of the module
4) Map LOs and POs with the COs
Exceptions: None
Includes: None
Priority: Medium
Business Rules None
them with COs

Assumptions: None

Figure 3.11. 1:- Edit LO, PO Sequence Diagram
Figure 3.11. 2:- Edit LO, PO Mockup Screen

Delete PO/LO
Delete PO/LO is done by the faculty lecture. Assigned lecturer has the privilege to Delete
PO/LO. It is not always done.
Priority: Medium
Stimulus: User selects and click the delete LO/PO button

Use Case ID: 12
Use Case Name: Delete PO/LO
Created By: Lecture Last Updated By:
Actors: Faculty lecture
Description: Delete program outcomes and learning outcomes.
Preconditions: Lecturer identity has been authenticated.
Predefined LOs and POs
Postconditions: Deleted PO and LO.
Normal Course: 1. Login to the system as a lecturer

2. Navigate to a specific module
3. Delete LOs and POs of the module

Exceptions: None
Includes: None
Priority: Medium
Business Rules None
them with COs
Assumptions: None

Figure 3.12. 1:- Delete LO, PO Sequence Diagram

Figure 3.12. 2:- Modules Interface Lecturer
Figure 3.12. 3:- Add, Edit and Delete LO, PO Mockup Screen

Add feedback
Students can give feedback. To observe effectiveness of the system feedback can be used.
Priority: Low
Response: The system authorized the user as a student to the system
Stimulus: User click the one of the course name which is a button
Response: System provides a web page to fill the feedback.
Stimulus: Student fills the feedback form click submit button
REQ-1: System should check whether the required fields are filled or not. If filled it should
proceed to the success message.

Use Case ID: 13
Use Case Name: Add feedback
Created By: Student Last Updated By:
Actors: Students, Lecturer
Description: Student can add feedback
Preconditions: Faculty student identity has been authenticated
Postconditions: Feedback has added
Normal Course: 1. Login to the system as a student

2. Add feedback

Exceptions:
Includes:
Priority: Low
Frequency of Use: Once per student
Business Rules
Special Requirements:
Assumptions: None


Figure 3.13 1:- Add Feedback Sequence Diagram

Figure 3.13 2:- Module Mockup screen for Student
Figure 3.13 3:-Feedback Adding Mockup Screen

Results
Lecturers can upload results and students can observe their achievements.
Priority: High
Response: The system authorized the user as a lecturer to the system
Stimulus: Lecturer clicks the upload results button
Response: System provides a web page to drag and drop the results excel file.
Stimulus: Lecturer clicks the submit results button
Response: System provide the Success message
Req 1: System should allow uploading the results file.

Use Case ID: 14
Use Case Name: Result
Created By: Lecturer Last Updated By:
Actors: Faculty lecturers, Students
Description: Results are added to the system and students can view
Preconditions: Faculty lecture identity has been authenticated to upload result
Faculty student identity has been authenticated to view results
Postconditions: Results have uploaded and viewed
Normal Course: 1. Login to the system as lecturer

2. Upload results
3. Login to the system as student
4. View results

Exceptions: None
Includes:
Priority: High
Frequency of Use: Frequently
Business Rules
Special Requirements:
Assumptions: None


Figure 3.14 1:- Adding and Viewing Results Sequence Diagram

Figure 3.14 2:- Results Mockup Screen

3.3 Logical Database Requirement
Figure 3.3. 1 :- Entity Relationship Diagram of the System

NON-FUNCTIONAL REQUIREMENTS
4.1 Performance Requirements
● .NET core enhances the overall performance by native optimization, smart caching
technologies, and JIT(Just-In-Time) compilation. Therefore ASP.NET core is suitable for
development when considering performance parameters.
● System will not be down when the data backup process runs.
● Response time in case of updating, deleting, adding of data will be maximum 1 minute.
● Authentication of a user will be done in less than a minute.
● System should have the ability to handle expected and non-expected errors in a way
that it prevents long downtime and loss in information.
4.2 Safety Requirements
The database can get crashed at any situation due to virus or server-side failure. Therefore, it
is necessary to take a database backup everyday so data will not be lost. Proper UPS facilities
have to be there in case of a power supply failure.
Adding an Antivirus web protection service for better protection of data and files.
4.3 Security Requirements
● There are different categories of users such as Administrators, Students and Lecturers
etc. Therefore, upon the category of user access rights are defined. As an example,
administrator can edit, delete and add data. But other users have customized access
constraints.
● There should be separate account types for administrators and students.

● Proper user authentication should be provided.

● Passwords should consist 12-18 characters. Which should contain at least a Uppercase
letter, digit and symbol with alphanumeric characters.
● No one should be able to hack a user's password.
● Use a strong hashing function to hash the user’s passwords to prevent hacking.
● System will have to use a secured database.
4.4 Software Quality Attributes
Characteristic
ID H/M/L 1 2 3 4 5 6 7 8 9 10 11 12
1 Correctness H
2 Efficiency M
3 Flexibility M
4 Integrity/Securit M
y
5 Interoperability M
6 Maintainability H

7 Portability M
8 Reliability H
9 Reusability H
10 Testability M
11 Usability H
12 Availability H
4.5 Business Rules
Administrators have to give the permission to the lecturers to access the specified Module
to edit or update.

OTHER REQUIREMENTS
The users of the system are network administrator, faculty administrator and lecturers of the
faculty who act as administrator to maintain the system. The network administrator of the system
should have more knowledge of the internals of the system and is able to rectify the small
problems that may arise due to disk crashes, power failures and other catastrophes to maintain
the system. The proper user interface, user manual, online help and the guide to install and
maintain the system must be sufficient to educate the users on how to use the system without
any problems.
5.1 Online User Documentation and Help System Requirements
As developers, we have to take the responsibility for training the users for the system at the
beginning. We have decided to prepare documented guidelines and some short video
tutorials which explain how to perform the functionalities relevant to the system and
provided to the faculty staff.

SYSTEM ARCHITECTURE
Figure 6. 1:- System Architecture

Figure 6. 2 :- Deployment Diagram

6.1 Component Architecture
Figure6.3. 1:-Component Architecture

6.2 Physical Architecture
Figure 6.4. 1:-Physical Architecture

APPENDIX A: GLOSSARY
APPENDIX B: ANALYSIS MODELS
APPENDIX C: TO BE DETERMINED LIST

EE5206 Project SRS Final

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EE5206 Project SRS Final

Uploaded by

Copyright:

Available Formats

Faculty of Engineering - University of Ruhuna

Software Requirements Specification Date: 03-11-2020

VERSION AND APPROVALS

Approver Name Project Role Signature/Electronic Date

Dr. Rajitha Project Supervisor

Mr. Anduradha Project Supervisor

Confidential ©<Company Name>, 2020 Page 1

Software Requirements Specification Date: 03-11-2020

Project Name OBE Curriculum Planning Tool

Project Type New Initiative

Project Start Date 15/09/2020

Project End Date 05/02/2021

Implementing an Outcome Based Education Curriculum

Secondary Driver Optimized Computer system instead of manual system

Division Software Division

Confidential ©<Company Name>, 2020 Page 2

Software Requirements Specification Date: 03-11-2020

Name Business Unit Role

Lecturers Faculty of Engineering, University Teacher and Content creator

Students Faculty of Engineering, University Student

Administrative Faculty of Engineering, University Course Creator

Confidential ©<Company Name>, 2020 Page 3

Software Requirements Specification Date: 03-11-2020

SRS Software Requirement Specification

OBE Outcome Based Education

CSS Cascade Style Sheet

HTML Hyper Text Markup Language

SQL Structured Query Language

HTTP Hypertext Transfer Protocol

TCP/IP Transmission Control Protocol/Internet Protocol

UML Unified Modeling Language

ASP Active Server Pages

GUI Graphical User Interface

Confidential ©<Company Name>, 2020 Page 4

Software Requirements Specification Date: 03-11-2020

MSSMS Microsoft SQL Server Management Studio

Confidential ©<Company Name>, 2020 Page 5

Software Requirements Specification Date: 03-11-2020

Confidential ©<Company Name>, 2020 Page 6

Software Requirements Specification Date: 03-11-2020

2.3 User Classes and Characteristics 22

Confidential ©<Company Name>, 2020 Page 7

Software Requirements Specification Date: 03-11-2020

3.3.3 Functional Requirements 36

Confidential ©<Company Name>, 2020 Page 8

Software Requirements Specification Date: 03-11-2020

Confidential ©<Company Name>, 2020 Page 9

Software Requirements Specification Date: 03-11-2020

3.10.3 Functional Requirements 70

Confidential ©<Company Name>, 2020 Page 10

Software Requirements Specification Date: 03-11-2020

3.13.6 System Mock-up Screens 89

Confidential ©<Company Name>, 2020 Page 11

Software Requirements Specification Date: 03-11-2020

Figure 2.3. 1:- User Class diagram........................................................................................ 22

Figure 3.2. 1:Creating Lecturer Profile ................................................................................. 35

Figure 3.3 1:- Creating Student Profile ................................................................................. 39

Figure 3.4. 1:-System Login Sequence diagram .................................................................... 44

Figure3.5. 1:- Create Course Sequence Diagram .................................................................. 49

Figure3.6. 1:- Edit Course Sequence Diagram ...................................................................... 54

Figure 3.7. 1:- Delete Course Sequence Diagram ................................................................. 59

Confidential ©<Company Name>, 2020 Page 12

Software Requirements Specification Date: 03-11-2020

Figure 3.8. 1:- Adding Privileges to a Lecturer Sequence Diagram........................................ 64