Software Requirements Specification 1. Introduction 2. Overall Description 3. External Interface Requirements 4. System Features 5. Other Nonfunctional Requirements 6. Other Requirements

Software Requirements
Specification

for

Online Examination System



Version 1.0 approved


Prepared By
Md. Abdullah Al Mahmud - 2013708642
Samira Ali - 2011423042


North South University


25-06-2022

Page ii

Table of Contents


Table of Contents
ii
Revision History
iii
1.  Introduction
1
1.1  Purpose
1
1.2  Document Conventions
1
1.3  Intended Audience and Reading Suggestions
1
1.4  Product Scope
1
1.5  References
2
2.  Overall Description
2
2.1  Product Perspective
2
2.2  Product Functions
2
2.3  User Classes and Characteristics
2
2.4  Operating Environment
2
2.5  Design and Implementation Constraints
2
2.6  User Documentation
3
2.7  Assumptions and Dependencies
3
3.  External Interface Requirements
3
3.1  User Interfaces
3
3.2  Hardware Interfaces
3
3.3  Software Interfaces
3
3.4  Communications Interfaces
4
4.  System Features
4
4.1  Log in using Google
4
4.2  Create an Exam-Cohort
5
4.3  Add other users as candidates
5
4.4  Create an assessment
6
4.5  Participate in exam
7
4.6  View obtained marks
7
4.7  Review and change marks
8
4.8  Download detailed mark sheets
8
4.9  Log out
9
5.  Other Nonfunctional Requirements
9
5.1  Performance Requirements
9
5.2  Safety Requirements
9
5.3  Security Requirements
9
5.4  Software Quality Attributes
10
5.5  Business Rules
10

Page iii

6.  Other Requirements
10
Appendix A: Glossary
10
Appendix B: Analysis Models
10


Revision History


Name Date Reason of Changes Version
N/A N/A N/A N/A
N/A N/A N/A N/A

Page 1

1. Introduction

1.1 Purpose
The purpose of this SRS document is to provide a detailed overview of our software product, its parameters and goals. This document describes the project's target audience and its user interface, hardware and software requirements. It defines how our client, team and audience see the product and its functionality. Nonetheless, it helps any designer and developer to assist in software delivery lifecycle (SDLC) processes.
1.2 Document Conventions
Heading: Font Style: Bold, Font Size: 18
Sub Heading: Font Style: Bold, Font Size: 14
Explanations: Font Style: Normal, Font Size: 12
1.3 Intended Audience and Reading Suggestions
This document is a prototype for an Online Examination System. This document is intended for a variety of readers, such as clients, developers, project managers, engineers, users, testers, and documentation writers. For instance, the clients will have clear instructions on how to handle the project (website/app). Most importantly, the developers team will be able to know every single detail of the software so that they can execute it accurately. Moreover, from this SRS, the project managers can estimate the required time and work load to finish this project, and thus plan everything accordingly. Software Engineers will not find it difficult to understand the functionality of the software, during the maintenance phase. Similarly, QA professionals need to understand all the technical aspects that lie behind the product's concept. User documentation writers will be able to write the “user's manual” in ease. Lastly, the users will be provided with precise instructions on how to use the software’s applications in both app and website versions. The remaining sections of this document provide a general description, including characteristics of the users of this project, the product's hardware, and the functional and data requirements of the product. It is suggested that the SRS be read in order using the table of content provided above.
1.4 Product Scope
The software system will be an Online Examination System for a wide range of users, not restricted to having evaluators who are professional educators only. Every user can create an examination cohort to take assessment and become an evaluator of that assessment. This system will be designed to maximize the productivity of each evaluator by providing tools to assist in automating the checking of the assessment and publishing the marks, which would otherwise have to be performed manually. By maximizing the evaluator's work efficiency the system will meet the examiner’s need while remaining easy to understand and use.

Page 2
1.5 References

2. Overall Description

2.1 Product Perspective
This Online Examination System is a self-contained product. It is mainly originated for the need of a fair assessment even though the candidates are not being invigilated during the assessment. This system makes taking assessments, setting questions and rechecking assessment not a laborious task for the evaluator.
2.2 Product Functions
The software functions are handy and user-friendly thus providing a smooth experience for any user. The major functions of the software are as follows:
  • Any user can create an examination cohort.
  • The user can create one or more assessments within the exam cohort.
  • The candidates can sit for an assessment.
  • The evaluator can adjust the mark of any evaluated assessment.
2.3 User Classes and Characteristics
All users can access the software from two different platforms: Web and Android App.
There are two different types of actors for each assessment. They are the evaluators and the candidates.
2.4 Operating Environment
The operating environments are mentioned below. They are as follows:
  • Platform: Web and Android
  • Operating System: Windows
  • Android App: Any system with a modern web browser or for android with android version 7.0+
  • Database Configuration: MySQL
2.5 Design and Implementation Constraints
Users with an Android version less than 7 cannot use the app. The backend is developed using Django and the frontend is developed using ReactJS. The android app is developed using Java.

Page 3
2.6 User Documentation
The product will provide users with a user manual which will be divided into two sections. The first section will provide information to a user who wants to be an evaluator. This section will cover in detail: how the evaluator can set the questions and modify the automated marking of the assessment if required. The second section will provide the candidate with a methodology of how to give the assessment.
2.7 Assumptions and Dependencies
Users must have a working internet. Web users must have a working browser to use the product. Phone users must have android version 7+ installed.

3. External Interface Requirements

3.1 User Interfaces
The user will be taken to the homepage first. Users can sign in using Google. The user can create an exam cohort and prepare an assessment using the plus sign in the bottom right corner of the home page. The homepage serves like a dashboard where the user can see all the assessments where he/she is an evaluator or a candidate. The user can sit for an assessment by clicking the assessment window where he/she is a candidate.
3.2 Hardware Interfaces
The website and android application of the software uses a microphone to record the answers of the micro-viva of the candidate.
3.3 Software Interfaces
The Online Examination System depends on the following software components. They are as follows:
  • Django - Django is a high-level Python web framework that enables rapid development of secure and maintainable websites. The backend of the software is built using this framework.
  • ReactJS - React is a free and open-source front-end JavaScript library for building user interfaces based on UI components. The frontend or UI of this software is built using this library.
  • MySQL - MySQL is an open-source relational database management system. The data of this system will be stored in this DBMS.
  • Android framework - The android framework is the set of API's that allows to quickly and easily write apps for android phones. The mobile app version of the software will be built using this.

Page 4
3.4 Communications Interfaces
The web application will send data to the backend using rest API. The android application will also communicate through its rest API. For both web and android, an AI speech recognition will be used for English speech to text conversion. All these communications will happen via HTTP. Authentication for google sign up is done by google.

4. System Features

4.1 Log in using Google

Use case name:-

Log in using Google

Actor(s):-

User

Brief Overview:-

The user tries to log in to system using google log in.

Typical Course of Events
Actor action System response
1. The user clicks the "Log in using Google" button from the login page. 2. The system will response by verifying the credentials through google API. After successful verification, it will redirect to homepage.
Alternative Course of Events
4.1.1 If the user enter incorrect google credentials, the system will redirect to login page.

Page 5
4.2 Create an Exam-Cohort

Use case name:-

Create an Exam-Cohort

Actor(s):-

User

Brief Overview:-

The user creates an exam-cohort to take assessment.

Typical Course of Events
Actor action System response
1. The user clicks on the plus sign in the bottom right corner of the home page. 2. The system provides a form to enter the name of the exam-cohort.
3. The user enters the name and clicks the create button. 4. The system then assigns the user as the evaluator for that exam-cohort.
Alternative Course of Events
4.2.1 If the given name of the exam-cohort is greater than 255 characters, the system will notify the user and stay on the same page.
4.3 Add other users as candidates

Use case name:-

Add other users as candidates

Actor(s):-

User as evaluator

Brief Overview:-

The user adds other users as candidates.

Typical Course of Events
Actor action System response
1. The user clicks on the add button to add other users as candidates. 2. The system provides a text field to the user.
3. The user writes one or more email addresses and clicks the add button. 4. The system adds those users as candidates whose email addresses were provided by the evaluator.
Alternative Course of Events
4.3.1 If at least one of the email addresses is not registered in the system, the system will mark those email addresses and disable the add button.

Page 6
4.4 Create an assessment

Use case name:-

Create assessment

Actor(s):-

User as evaluator

Brief Overview:-

The user creates an assessment for the candidates.

Typical Course of Events
Actor action System response
1. The user clicks the create assessment button on the Exam-Cohort page. 2. The system asks for 'available date-time', the 'due date-time' for the assessment and to specify the type of question - mcq or micro-viva.
3. The user specifies the question type. For an mcq test, the user marks the correct answer(s). For a micro-viva, the user supplies the correct answer(s) as a recording with a maximum of five words. The user sets a specified mark and maximum time for answering each question. The system then saves the assessment created by the user.
Alternative Course of Events
4.4.1 The system sends an error message if the 'available date-time' for the assessment is before the current date and time.
4.4.2 The system sends an error message if the 'due date-time' for the assessment is after a long period of time from the 'available date-time' of the assessment.
4.4.3 The system sends an error message if the recorded answer for the miro-viva exceeds five words.

Page 7
4.5 Participate in exam

Use case name:-

Participate in exam

Actor(s):-

User as candidate

Brief Overview:-

The user can participate in the exam.

Typical Course of Events
Actor action System response
1. The user starts the exam by clicking the start exam button. 2. The system will provide mcq or micro-viva questions one by one in random order. The options for the mcq questions will also be randomized.
3. For a mcq test, the user clicks the desired option to answer each question. For a micro-viva, the user answers using his/her voice by clicking on the record button. The user clicks the next button. 4. For the mcq test, the system saves the assessment given by the user. For the micro-viva, the system records and saves the answer given by the user.
Alternative Course of Events
4.5.1 If the time limit for an answer exceeds, the system will automatically change the question and keep record of the given answer.
4.5.2 If the user fails to provide any answer before the time limit, the system will save the empty answer.
4.6 View obtained marks

Use case name:-

View obtained marks

Actor(s):-

User as candidate

Brief Overview:-

The user can view obtained marks.

Typical Course of Events
Actor action System response
1. The user clicks on the view score button to view the scores. 2. The system presents the score obtained in the assessment.
Alternative Course of Events
N/A

Page 8
4.7 Review and change marks

Use case name:-

Review and change marks

Actor(s):-

User as evaluator

Brief Overview:-

The user can review and change marks.

Typical Course of Events
Actor action System response
1. The user clicks on the check score button to review or change marks. 2. The system presents the scores obtained in the assessment by each candidate.
3. To review or change marks the user chooses to see/hear/read the answers of a candidate. 4. The system then updates the score of a candidate if his/her marks have been changed.
Alternative Course of Events
4.7.1 The system shows warning message if the user tries to leave the review page before saving any changes.
4.8 Download detailed mark sheet

Use case name:-

Download detailed mark sheet

Actor(s):-

User as evaluator

Brief Overview:-

The user can download a detailed mark sheet as a spreadsheet.

Typical Course of Events
Actor action System response
1. The user clicks the download button to download a detailed mark sheet. 2. The system downloads the detailed mark sheet as a spreadsheet.
Alternative Course of Events
N/A

Page 9
4.9 Log out

Use case name:-

Log out

Actor(s):-

User

Brief Overview:-

A user can log out from the application whenever he/she wants to

Typical Course of Events
Actor action System response
1. User clicks the "Log out" button. 2. The system logs out the user from the application and redirects to homepage.
Alternative Course of Events
N/A

5. Other Nonfunctional Requirements

5.1 Performance Requirements
Mobile App: Needs to be lightweight and responsive.
Database: The queries for DBMS data should be optimized as there would be a huge number of users.
Speech to text recognition: The AI used for this feature must be up to date. Inability of correct transformation to text might lead to serious confusions. Overall Performance: The software should have an optimal speed of response, throughput, execution time, and storage capacity.
5.2 Safety Requirements
All data must be stored and never deleted from the database. For instance, the marks of each candidate of older assessments must be accessible even if the assessment is over.
5.3 Security Requirements
Only the user as evaluator in an exam-cohort can review or change marks. The time constraint for each assessment can only be altered by the evaluator.

Page 10
5.4 Software Quality Attributes
Availability: It is an online system and available 24/7 to all users.
Correctness: This software provides correct automated evaluation of assessment.
Flexibility: The software has both web and mobile app versions, thus making it flexible to use.
Maintainability: This software can be restored easily and rapidly after a failure.
Reliability: This software is made secure so that no candidate will be able to tamper with the obtained results in the assessment and also the time constraint given to complete an assessment.
Interoperability: The software follows the service-oriented architecture.
Usability: This software has a user-friendly user interface.
5.5 Business Rules
This product will be free to use for all the users with a Google account.

6. Other Requirements

Appendix A: Glossary
  • AI: Artificial Intelligence in full, is the simulation of human intelligence processes by machines, especially computer systems.
  • API: It stands for Application Programming Interface. An API is basically a software intermediate that allows two applications to interact with each other.
  • Candidate: User sitting for an assessment.
  • Database: Collection of all the information monitored by this system.
  • Evaluator: User who created an exam cohort.
  • Exam-Cohort: Virtual platform for creating one or more assessment.
  • Framework: An abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software.
  • HTTP: HyperText Transfer Protocol in full, a standard application-level protocol used for exchanging files on the World Wide Web.
Appendix B: Analysis Models
Not Available Currently