SOFTWARE REQUIREMENTS

SPECIFICATION
(SRS DOCUMENT)

for

Plagiarism Detection
sContents
1. Introduction ........................................................................................................................................................... 3
1.1 Purpose ......................................................................................................................................................... 3
1.2 Scope ............................................................................................................................................................. 3
2. Overall description ................................................................................................................................................ 3
2.1 Product Perspective..................................................................................................................................... 3
2.2 Operating Environment.............................................................................................................................. 3
3.1 Use Case Diagram ....................................................................................................................................... 3
3.1.1 Student ..................................................................................................................................................... 4
3.1.2 Teacher ........................................................................................................................................................ 5
3.1.3 Admin .......................................................................................................................................................... 6
4. Usage Scenarios .................................................................................................................................................... 6
4.1.1 UC-01: Login .............................................................................................................................................. 7
4.1.2 UC-02: Logout ..................................................................................................................................................... 7
4.1.3 UC-03: Register ................................................................................................................................................... 7
4.1.4 UC-04: Validate the User ..................................................................................................................................... 8
4.1.5 UC-05: Submit the Assignment ........................................................................................................................... 9
5. Specific Requirements......................................................................................................................................... 10
5.1 Functional Requirements ......................................................................................................................... 10
6. Non Functional Requirements ............................................................................................................................. 11
7. Methodology ....................................................................................................................................................... 11
1. Introduction
1.1 Purpose
This document contains the Plagiarism Detection System software requirements. It contains detailed
functional, non-functional and support requirements and provides a basic system development
requirement. The SRS requirements are independent, unique and organized by topic. In the second section,
the overall system use case diagrams are present which represent all the basic functionalities within our
system and give an overall view of interaction between different actors and the system. In next section of
this document, the use cases mentioned within the use case diagrams are elaborated in detailed tabular
form and every use case contains the flow with which they will be used

1.2 Scope
This document will cover two key topics in the field of plagiarism - a system of authenticated users and
plagiarism detection of documents submitted by students. The student will upload their assignments and
papers (Word, Pdf files) and the system will process and detect the plagiarism and will generate a
plagiarism report. The teacher can view the assignment and grade it accordingly.

2. Overall description
2.1 Product Perspective
Online education is now very popular and dominant throughout the world because of the corona virus.
According to SOPs for corona viruses, students can learn from home comforts and stay safe online through
online classes during this pandemic. Despite the many advantages of online education, there are also
problems associated with it such as student plagiarism. Students usually submit assignments plagiarized
from various sources, such as the Internet and other student assignments. For teachers to manually control
plagiarism is very difficult.

Plagiarism Detection is a web-based application that solely focuses on how to tackle this issue.
It provides an online platform to both student and teachers where student can submit their assignments
and system will process it and detect plagiarism. The plagiarism report will be generated by the system
eventually which will help teachers a lot to grade the student assignments. The students can also view their
assignments plagiarism report and can view remarks of their teacher on the assignment. Therefore, this
online submission and plagiarism detection system will make the task easy for teachers to stop these
unethical activities.

2.2 Operating Environment

OE-1: The System shall operate correctly with the following web browsers: Firefox versions 28 through
48; Google Chrome (all versions); and Apple Safari versions 8.0 through 11.1.

3. Requirement Identifying Technique

3.1 Use Case Diagram
3.1.1 Student
Given below is the use case diagram of the student.
3.1.2 Teacher
Given below is the use case diagram of the teacher.
3.1.3 Admin
Given below is the use case diagram of the admin.

4. Usage Scenarios
User authentication of Plagiarism Detection System can be separated into three parts named as sign up,
sign in and sign out. Sign up form contains student name, faculty name, department name, registration
number, class, email address, session, password and class roll. When a student fills up the sign up form,
a verification request is sent to admin. Verification request contains all the information about the student
except the password. If admin verifies the student, the account becomes active. Admin has the right to
create or remove any student. Students can sign in through email and password. Students can change their
password, but other information are not changeable. There are some super users who are basically
teachers. Teachers can registered by signing up to the system. Teachers’ signup form contains fields such
as name, faculty name, department name, email address and designation. Admin verify the teacher
request. Teachers can reset their password at any time. Teachers can be removed by admin. Users can
exit from the system through sign out. Signed in students can submit any kind of document (Doc, PDF
etc) at any time. To submit a document, student has to mention submission type, title and course code.
After submitting the document, student will get a report link about validity of the submitted document. If
the document contains negligible amount of plagiarism the report contains the message that submission
is successful. On the other hand, if the document contains significant amount of plagiarism, the report
contains the message that submitted document contains plagiarism. The report also contains how similar
previous files were with the submitted document. Teachers can view any kind of submission. Teachers
can also download any document. Each submission in the submission history is associated with the link
of report of that submission. Admin and Teachers can view reports through these link
4.1.1 UC-01: Login

Use Case ID: UC-01

Use Case Name: Login
Actors: Admin (primary actor), Teacher (primary actor), Student (primary Actor)
Description: User shall login to get access to his/her account in order to facilitate him/her self with the system.

Trigger: User clicks the “Login” button to sign in his/her account

Preconditions: PRE-1. User is registered in the system

PRE-2. System is available to the user
Postconditions: POST-1. User successfully logged in his/her account and has access to his/her profile.

Normal Flow: 1. User clicks on the sign in button.

2. User enters his/her credentials.
3. User clicks on the login button.
Alternative Flows: N/A
Exceptions: 2a. In step 2 of normal flow, if the user enters invalid credentials.
1. System will prompt an error message to user “invalid username or password”.
2. User will enter correct credentials.
3. Use case resumes on the step 3 of normal flow.
Business Rules N/A
Assumptions 1. User has internet connection.
2. User has a registered account.

4.1.2 UC-02: Logout

Use Case ID: UC-02

Use Case Name: Logout
Actors: Admin (primary actor), Teacher (primary actor), Student(Primary Actor)
Description: User shall logout from his/her account once he/she is finished acquiring the system resources.

Trigger: User clicks the “Logout” button to sign in his/her account

Preconditions: PRE-1. User is logged in the system

PRE-2. System is available to the user
Postconditions: POST-1. User successfully logged out of his/her account.

Normal Flow: 1. User clicks on the logout button from the menu.
2. User is redirected to the Login page.
Alternative Flows: N/A
Exceptions: N/A
Business Rules N/A
Assumptions 1. User has internet connection.

4.1.3 UC-03: Register

Use Case ID: UC-03
Use Case Name: Register
Actors: Student (primary actor), Teacher(primary actor)
Description: Registration is necessary step for using the system. In this use case user will register by filling the
respective registration form
Trigger: User clicks the “Register” button.
Preconditions: PRE-1. User has a working internet connection.
PRE-2. System is available to the user.
Postconditions: POST-1. User request for registration will be submitted.
Normal Flow: 1. User clicks on register account button.
2. User will fill out the information required in the form.
3. User will fill out the email address text field.
4. User will fill out the password text field.
5. User will fill out the confirm password text field.
6. User will click on the create account button.
Alternative Flows: N/A
Exceptions: 3a. In step 2 of the normal flow if the user enters incorrect email address
1. System will show error message “incorrect email address”.
2. User will enter the correct email address.
3. Use case resumes on step 3 of normal flow.
3b. In step 4 of the normal flow if the password doesn’t match with password in the step 3
1. System will show error message “the passwords don’t match”
2. User will enter the correct password.
3. Use case resumes on step 5 of the normal flow
3c. In step 3 of the normal flow if the email address of user already exists.
1. System will prompt error message to user “email address already exists”.
2. User will enter the correct email address.
3. Use case will resumes on the step 3 of the normal flow.
Business Rules N/A
Assumptions 1. User has internet connection.
2. Password must contain one upper case letter, one special case character, and one digit.

4.1.4 UC-04: Validate the User

Use Case ID: UC-04
Use Case Name: Validate the User
Actors: Admin (primary actor)
Description: Admin shall validate the user account i.e. request for registration.

Trigger: User clicks the “Verify Account” button.

Preconditions: PRE-1. User has a working internet connection.
PRE-2. System is available to the user.
Postconditions: POST-1. User verified the account of student and teacher.
Normal Flow: 1. User logins in the account.
2. User will click on the verify account button.
3. System displays all users request.
4. User clicks on the detail of the user.
5. User after verifying the detail click on the approve button.
6. User gets registered as his/her account is verified
Alternative Flows: N/A
Exceptions: N/A
Business Rules N/A
Assumptions 3. User has internet connection.
4. Password must contain one upper case letter, one special case character, and one digit.

4.1.5 UC-05: Submit the Assignment

Use Case ID: UC-05
Use Case Name: Submit the Assignment
Actors: Student(primary actor)
Description: User shall be able to submit his/her assignment on the website

Trigger: User clicks the “Submit the Assignment” button.

Preconditions: PRE-1. User has a working internet connection.
PRE-2. System is available to the user.
Postconditions: POST-1. User assignment is submitted.
Normal Flow: 1. User logins in the account.
2. User select the class he/she enrolled in.
3. User clicks on the submit assignment button
4. Form shall be displayed to the user.
5. User fills the necessary data on the form
6. User clicks on the submit button.
6. User assignment get submitted.
Alternative Flows: N/A
Exceptions: N/A
Business Rules N/A
Assumptions 1. User has internet connection.
2. Password must contain one upper case letter, one special case character, and one digit.
5. Specific Requirements
5.1 Functional Requirements
Following are the functional requirement for the plagiarism detection website application.

ID Requirement Dependencies
FR-01 The user shall be able to login in the system with the FR-02, FR-03,FR-04,FR-06
correct credentials
FR-02 The student shall be able to sign-up in the system by FR-06
filling signup form
FR-03 The teacher shall be able to sign-up in the system by FR-06
filling the signup form
FR-04 The system shall validate user login credentials FR-01
FR-05 System shall redirect user to his/her dashboard after FR-01, FR-02
logging in or signing up to the site.
FR-06 The Admin shall validate the users once they sign- FR-01
up (approve/disapprove) to the site.
FR-07 The student shall be able upload his/her assignment FR-01
documents in the system.
FR-08 The system shall generate the plagiarism report of FR-01
the user file.
FR-09 The student shall be able to view his/her report FR-01
FR-10 The user shall be able to enroll into different FR-01
courses/classes so he/she can submit his/her course
assignments.
FR-11 The student shall be able to view grade he/she gets FR-01
on his/her assignment/assessment.
FR-12 The teacher shall be able to view student FR-01
assignments/assessments.
FR-13 The teacher shall be able view plagiarism report of FR-01
against each assignment submitted by the student.
FR-14 The teacher shall be able to upload grade of each FR-01
assignment/assessment.
FR-15 The system shall generate the plagiarism report FR-01
once student had upload his/her assignment.
FR-16 The admin shall be able to delete a user record. FR-01
FR-17 The admin shall be able to update a user record. FR-01
FR-18 The admin shall be able to view user record FR-01
details.
6. Non Functional Requirements
Following are the nonfunctional requirements for Power HR.

Performance
PER-1: The average response time per every user click shall be less than 4 seconds. And
the maximum average time per every click shall be less than 6 seconds.

Usability
USE-1: The system user interface shall be user friendly i.e. the minimum amount of time
taken by novice user to learn the system shall be 15 minutes.

Maintainability
Main-1: The system can make new changes on the basis of the requirements, if demanded
after completion of the system. The maintainability of the system can be done by integrating
new modules and offering new solutions for the raised problems.

Reliability
REL 1: The system shall have less than 6 hour downtime per two months
REL 2: Maximum Bugs per 1000 lines should not be greater than 9.

7. Methodology
We are using Object Oriented design methodology for development of this project. The basic
motivation behind using object-oriented design methodology is we are using Python which is
object-oriented language. OOM (object oriented methodology) provides reusability of
components. OOP methods makes code more maintainable, we can identify errors easily because
object is encapsulated. OOP applications are more scalable than structured programming roots.
OOP makes it easy to maintain and modify our existing code as new object can be created with
small differences to existing one. Furthermore, changes in one part of code won’t affect the
whole code.

We will use incremental methodology for this project. As this system is built incrementally on
different modules working together, this will help us develop the system in different stages and
help improve the system functionality time by time, even if the requirement changes the system
will be able to adapt the changes. This will help us test the system incrementally.