The document provides an overview of the inception phase of developing a plagiarism detector software. Key aspects discussed include: 1. Planning meetings were held with stakeholders to discuss project scope and requirements. 2. The main stakeholders identified were teachers who will use the software. Their viewpoints around ease of use and report generation were noted. 3. Requirements elicitation techniques used include collaborative gathering, quality function deployment, and defining a usage scenario. Interviews and questionnaires were also used to understand stakeholder needs and address issues around requirements scope and volatility.

1. Plagiarism Detector
v
Contents
Letter of Transmittal …………………………………………………………………………i
Letter of Endorsement ……………………………………………………………………….ii
Acknowledgement …………………………………………………………………………..iii
Executive Summary……………………………………………………………………….....iv
Table of contents……………………………………………………………………………...v
Introduction to Plagiarism Detector.........................................................................................2
1.1 Purpose ......................................................................................................................................... 2
1.2 Overview....................................................................................................................................... 2
1.3 Conclusion..................................................................................................................................... 3
Inception of Plagiarism Detector................................................................................................4
2.1 Introduction .................................................................................................................................. 4
2.2 Planning meeting .......................................................................................................................... 4
2.3 Identifying Stakeholders ............................................................................................................... 5
2.4 Our Questions to the Stakeholders............................................................................................... 5
2.5 Recognizing Multiple Viewpoints.................................................................................................. 5
2.6 Working towards Collaboration.................................................................................................... 6
2.7 Conclusion..................................................................................................................................... 6
Elicitation of Plagiarism Detector ..............................................................................................7
3.1 Elicitation of Plagiarism Detector ................................................................................................. 7
3.2 Eliciting Requirements of Plagiarism Detector ............................................................................. 7
3.2.1 Collaborative Requirements Gathering ................................................................................. 7
3.2.2 Quality Function Deployment................................................................................................ 9
3.2.3 Usage Scenario....................................................................................................................... 9
Scenario Based Modeling of Plagiarism Detector..............................................................10
4.1 Introduction ................................................................................................................................ 10
4.2 Usecase Diagrams and Scenario ................................................................................................. 11
4.3 Activity Diagram.......................................................................................................................... 14
4.4 Swimlane Diagram ...................................................................................................................... 16
4.5 Conclusion................................................................................................................................... 16
Data Model of Plagiarism Detector.........................................................................................17
5.1 Data Modeling Concept .............................................................................................................. 17
5.2 Data Identification and Define Attributes of each Data ............................................................. 17

2. Plagiarism Detector
vi
5.3 Entity Relationship Diagram and Schema Diagram .................................................................... 19
5.4 Conclusion................................................................................................................................... 20
Class-based model of Plagiarism Detector...........................................................................21
6.1 Class Based Modeling Concept ................................................................................................... 21
6.2 Identifying Analysis Classes......................................................................................................... 21
6.3 Potential class table:................................................................................................................... 22
6.4 Specifying Attributes................................................................................................................... 23
6.5 Defining Operations.................................................................................................................... 24
6.6 Class Diagram for Plagiarism Detector........................................................................................ 24
6.7 Class Responsibility Collaborator (CRC) ...................................................................................... 27
6.8 Conclusion................................................................................................................................... 28
Behavioral Model of Plagiarism Detector.............................................................................29
7.1. Introduction ............................................................................................................................... 29
7.2. Identifying Events with the Use Case......................................................................................... 29
7.3. State diagram for analysis classes.............................................................................................. 30
7.4. Sequence diagram...................................................................................................................... 31
7.5 Conclusion................................................................................................................................... 31
Conclusion .......................................................................................................................................32
Introduction to Architectural Design.....................................................................................34
9.1 Data Flow Diagram (DFD)............................................................................................................ 34
Representing the System in Context.......................................................................................35
10.1 Representing the System in Context......................................................................................... 35
Software Architecture Design...................................................................................................36
11.1 Software Architecture Design................................................................................................... 36
Component Level Design ............................................................................................................38
12.1 Component Level Design .......................................................................................................... 38
Step 1: Analysis class..................................................................................................................... 38
Step 2 : Design Component........................................................................................................... 40
Step 3: Elaborate Design Classes .................................................................................................. 42
Step 3.a: Collaboration Details...................................................................................................... 46
Step 3.b: Appropriate Interfaces................................................................................................... 47
Step 3.c: Elaborate Attributes....................................................................................................... 47
Step 3.d: Describe Processing Flow .............................................................................................. 48
Persistent Data...............................................................................................................................51

3. Plagiarism Detector
vii
13.1 Persistent Data.......................................................................................................................... 51
Elaborate Behavior.......................................................................................................................52
14.1 Elaborate Behavior.................................................................................................................... 52
Elaborate Deployment.................................................................................................................54
15.1 Elaborate Deployment.............................................................................................................. 54
User Interface Design...................................................................................................................55
16.1 User Interface Design................................................................................................................ 55
16.2 Target User................................................................................................................................ 55
16.3 Literacy...................................................................................................................................... 55
16.4 UI Diagram ................................................................................................................................ 55
17. User Manual .............................................................................................................................58
18. Test Cases..................................................................................................................................62

4. Plagiarism Detector
viii
TABLE OF FIGURES
Figure 1 : Plagiarism Detector (Level-0)................................................................................................................ 11
Figure 2: Submission (Level 1)............................................................................................................................... 12
Figure 3: Calculation (Level 2)............................................................................................................................... 13
Figure 4: Report Generation (Level-3)................................................................................................................... 13
Figure 5: Plagiarism Detector (Level 1)................................................................................................................. 14
Figure 6: Insert and observe Activity (Level-2)...................................................................................................... 15
Figure 7: Report generation (Level-3)................................................................................................................... 15
Figure 8: Plagiarism Detector(Swimlane) ............................................................................................................. 16
Figure 9: ER diagram ............................................................................................................................................ 19
Figure 10: Schema diagram.................................................................................................................................. 20
Figure 11 : Class diagram...................................................................................................................................... 26
Figure 12: State Diagram- Teacher....................................................................................................................... 30
Figure 13: State diagram-System ......................................................................................................................... 30
Figure 14: Sequence Diagram............................................................................................................................... 31
Figure 15: Data Flow Diagram.............................................................................................................................. 34
Figure 16: Context Diagram.................................................................................................................................. 35
Figure 17: Architectural Design ............................................................................................................................ 37
Figure 18: All Design classes ................................................................................................................................. 40
Figure 19: All Design component.......................................................................................................................... 41
Figure 20: Elaborate Design classes...................................................................................................................... 45
Figure 21: Collaboration diagram with messaging............................................................................................... 46
Figure 22: Appropriate Interface .......................................................................................................................... 47
Figure 23: Activity diagram for insert_data() ....................................................................................................... 48
Figure 24: Activity diagram for observe_report() ................................................................................................. 49
Figure 25: Activity diagram for calculate_data().................................................................................................. 49
Figure 26: Activity Diagram for generate_report()............................................................................................... 50
Figure 27: Elaborate behavior .............................................................................................................................. 53
Figure 28: Elaborate Deployment......................................................................................................................... 54
Figure 29: Home Page........................................................................................................................................... 55
Figure 30: Upload File........................................................................................................................................... 56
Figure 31: Plagiarism Checker .............................................................................................................................. 57
Figure 32: Plagiarism Checker Result.................................................................................................................... 57
Figure 33: Home Page........................................................................................................................................... 58
Figure 34: Data file upload ................................................................................................................................... 58
Figure 35: Choose File........................................................................................................................................... 59
Figure 36: Add File ................................................................................................................................................ 59
Figure 37: File Added Successfully ........................................................................................................................ 60
Figure 38: Submit a new file to check plagiarism ................................................................................................. 60
Figure 39: Check Plagiarism.................................................................................................................................. 61
Figure 40: Percentage of plagiarism..................................................................................................................... 61

5. Plagiarism Detector
ix
List of Tables
Table 1: Noun table from scenario………………………………………………………………………………….………………………….......18
Table 2: Selection of potential class…………………………………………………………………………………………………………………22
Table 3: Event Identification …………………………………………………………………………………………………………………………..29

6. Plagiarism Detector
1
SOFTWARE REQUIREMENTS
SPECIFICATION

7. Plagiarism Detector
2
Chapter1
Introduction to Plagiarism Detector
Plagiarism detector is a web application that will be used by the teachers. The purpose of
plagiarism detector is to identify plagiarized content from thesis documents. It will be used
for education establishment by observing student data. It will be used for calculating whether
a new submitted document or a portion of an article is plagiarized of not. The sections below
give overview of everything included in this SRS document, also, the purpose of this
document is described here.
1.1 Purpose
The document is about the Software Requirements Specification (SRS), Architectural
Design and User Interface for Plagiarism Detector. The purpose the document is to give a
detailed description for Plagiarism Detector. This software requirements specification
document enlists all necessary requirements that are required for the project development.
To derive the requirements we need to have clear and thorough understanding of the
products to be developed. This has been prepared after detailed communications with the
project team and stakeholders.
The first part of the document includes a set of use cases that describe interactions the users
will have with the software. It will also explain the system constraints, interface and
interactions between the software and the users.
1.2 Overview
● The remainder of this document includes seventeen chapters.
● The second and third chapters introduce different types of stakeholders and their
interaction to the system. The chapters also provide the requirements specification
in detail and provide a description of the different system interfaces.
● The fourth one provides an overview of the system functionality and system
interaction with other systems based on the scenario of Plagiarism Detector.
● The fifth and sixth chapters show the interaction of data within the system using
various functionalities. Different specification techniques are used in order to
specify the requirements more precisely for different audiences.
● The seventh chapter describes the behavior of the software.
● Conclusion is in the eighth chapter.
● The ninth chapter describes the dataflow diagram.
● System Context and Architectural Design is described in chapter ten and eleven.
● Elaboration of component level design is in chapter twelve.
● Elaboration behavior and deployment are in chapter fourteen and fifteen.
● UI design is described in chapter sixteen.

8. Plagiarism Detector
3
1.3 Conclusion
In this document we have discussed our project overview including project purpose. In next
chapter the inception of this project will be described.

9. Plagiarism Detector
4
Chapter 2
Inception of Plagiarism Detector
2.1 Introduction
Inception is the beginning phase of requirements engineering. This phase helps to get
orientation to make a first draft about project planning.
The inception phase is not responsible to describe the requirements completely and in detail,
to restrict the problem field and also not to develop solutions. It defines how does this project
(Plagiarism Detector) get started and what is the scope and nature of the problem to be
solved. The goal of the inception phase is to identify concurrence needs and conflict
requirements among the stakeholders of this project. To establish the groundwork we have
worked with the following related to the inception phases:
 Planning meeting
 Identifying Stakeholders
 Recognizing multiple viewpoints
 Working towards collaboration factors
 Our questions to the stakeholders
2.2 Planning meeting
At an early stage in the project, several stakeholders and subject matter experts should be
convened to discuss the project and make the product plan. We should choose stakeholders
based on the nature and complexity of the project and its product deliverable. Depending on
the size of the project and its complexity, the meeting may take several days or weeks.
To make the project successful, we have made several times group discussion:
1. Date: 13 September, 2015
Place: IIT
Subject Matter: Identifying stakeholders
Members:
 Sheikh Muhammad Sarwar
 Md.Arafat Zaman Anik (BSSE-0410)
2. Date: 4 October, 2015
Place: IIT
Subject Matter: Collecting requirements from stakeholders
Members:
- Above all members
3. Date: 6 October, 2015
Place: IIT
Subject Matter: Discussion on requirements

10. Plagiarism Detector
5
Group Members:
- Above all members
4. Date: 8 October, 2015
Place: IIT
Subject Matter: Discussion on report writing about “Inception” phase
Group Members:
- Above all members
2.3 Identifying Stakeholders
Stakeholder refers to any person or group who can affect or is affected by the system directly
or indirectly. Stakeholders include end-users who interact with the system and everyone else
in an organization that may be affected by its installation. Stakeholder identification is the
process used to identify all stakeholders for a project. The number of our stakeholders is
small. Although the user number is small, they will use the system in different purpose and so
have different types of requirements and viewpoints. It is important to understand that not all
stakeholders will have the same influence or effect on a project, nor will they be affected in
the same manner. It should be done in a methodical and logical way to ensure that
stakeholders are not easily omitted. The following questions help us to identify stakeholders:
 Who uses the system?
 Who is affected by the outputs of the project?
 Who evaluates/approves system?
 Who maintains the system?
 Who has knowledge (specialist) about the system?
 Whose work will affect our project? (During the project and also once the project is
completed).
2.4 Our Questions to the Stakeholders
We set our questions in a way so that they could give their opinions and requirements for the
system. The questions are mentioned at the last part of SRS. Our questions also focus
measurable benefits and successful implementation of the project.
2.5 Recognizing Multiple Viewpoints
1. Teachers viewpoint
 Fully automated
 The user interface should be designed in a way so that it looks understandable to the
non-technical persons
 User-friendliness
 Report generation
 File must be uploaded
 Easy maintenance such as inserting

11. Plagiarism Detector
6
2.6 Working towards Collaboration
We have asked our stakeholders for their requirements and found out that each of them has
their own requirements. Some of the requirements are common as well as conflicting. So we
need to follow the steps given below to merge the requirements:
 Find out the common and conflicting requirements
 Divide the requirements into different categories
 Identify the specials requirements that the stakeholders have
 Identify the requirements according to the stakeholders priority points and prioritize
them
 Take final decisions about the requirements
2.7 Conclusion
Inception phase helped us to achieve the concurrence among all stakeholders on the lifecycle
objectives for the project as we recognized their multiple viewpoints. The inception phase is
of significance primarily for new development efforts, in which there are significant
requirements risks which must be addressed before the project can proceed. In next chapter
we have discussed about finding requirements and user scenario.

12. Plagiarism Detector
7
Chapter 3
Elicitation of Plagiarism Detector
3.1 Elicitation of Plagiarism Detector
Elicitation is the task that helps the customer to define what is required. To complete the
elicitation step of Plagiarism Detector we faced many challenges like problems of the scope,
problems of the volatility and problems of understanding. To help overcome these challenges,
we have worked with the elicitation requirement activity in an organized and systematic
manner.
3.2 Eliciting Requirements of Plagiarism Detector
Requirements elicitation of Plagiarism Detector combines elements of problem solving,
elaboration, negotiation and specification. It requires the cooperation of a group of end users
and developers to elicit requirements. To elicit requirements of Plagiarism Detector we
completed following tasks:
 Collaborative Requirements Gathering
 Quality Function Deployment
 Usage scenario
3.2.1 Collaborative Requirements Gathering
The goal is to identify the problem, propose elements of the solution, negotiate different
approaches, and specify a preliminary set of solution requirements in an atmosphere that is
conducive to the accomplishment of the goal. To better understand the flow of events of
Plagiarism Detector as they occur, we present a brief usage scenario that outlines the
sequence of events that lead up to the requirements gathering meeting, occur during the
meeting, and follow the meeting. We discuss with our stakeholders of Plagiarism Detector to
come up with the deserved results. To gather the requirement, we have used a technique
called use “4Ws and an H”. It refers to:
1) Who 2) What
3) When 4) Where 5) How
There are three problems that are encountered as elicitation of Plagiarism Detector:
1. Problems of the scope: The boundary of the problem of Plagiarism Detector is well
defined.
2. Problems of the understanding:
-what is needed from the software
-the capabilities and limitation of the computing environment

13. Plagiarism Detector
8
-the domain of the problem
The users sometimes have trouble communicating their needs with the system engineer. They
specify problems that are sometimes ambiguous and not verifiable.
3. Problems of the volatility: Requirements change overtime. This is due to dynamic
environment. The problem of volatility is an important aspect.
Requirement elicitation through interview: Interviews are often the best means to elicit
qualitative information of Plagiarism Detector such as opinion, policies and narrative
description of activities of the problem.
Requirement elicitation through questioning: Wide distribution questionnaires ensure that
the respondent has great anonymity.
Questionnaires
1. Why is it needed?
2. Do you have any existing system to compare new thesis document?
3. What is the purpose and objectives of the project?
4. How will you define the boundary of the new system?
5. What functions do you want?
6. Is there anything else you want to specify?
7. Have you considered about a web based application?
8. Can the provided information to be considered as final requirements?
9. Are my questions relevant to the problem that you have?
10. Which one is your preferred system’s operating environment?
11. Any suggestion for data input system?
12. How do you prefer to view the data?
13. Do you have any suggestion for the outlook of the system?
14. What are the benefits?
15. Who are the users?
16. Will it be cost-effective?
17. What are the benchmarks?
18. How is the security ensured?
19. How will it be useful to teachers and students?
20. Is it feasible to add extra functionalities like notification?
21. Will it provide storage benefit?
22. Can it be collaborated with social media (like email)?
23. Is any Interaction module (like comment box) be available?
Record view : A good volume of records and reports of Plagiarism Detector provide useful
information about the existing system.
Observation : Observation provides first-hand information of Plagiarism Detector about
how activities are carried out.

14. Plagiarism Detector
9
3.2.2 Quality Function Deployment
Quality function deployment (QFD) is a quality management technique that translates the
needs of the customer into technical requirements for software. QFD “concentrates on
maximizing customer satisfaction from the software engineering process”. With respect to
our project the following requirements are identified by a QFD.
Normal Requirements
 This system will be able to count textual frequency
 Vector token archiving
 Matching with indexed archiving vector and new submitted article
 Identify percentage of similarity
 Easily maintainable
 Easily accessible
 Help feature to explain what they are looking for
Expected Requirements
 The user interface of the system shall be easy to use
 The interface will be designed in a manner which implements functionalities that are
easily accessible by the user
Exciting Requirements
 Error message will be provided
3.2.3 Usage Scenario
Plagiarism Detector is an automated software for detecting plagiarized contents. Users of
this software can be categorized as following:
 Teachers
In any educational institute an amount of thesis papers are submitted to the teachers for the
requirement of the course. The widespread use of computers and the advent of the Internet
has made it easier to plagiarize the work of others. It is important to detect plagiarized articles
to establish the identity of uniqueness. No local plagiarism detection tools exists in
Bangladesh.
The system will make a posting list with frequency. When a new paper or article is submitted,
the system will generate a report about the percentage of similarity. Teachers are the main
users of this software. After authentication teachers can view the lists and report. By
observing the report, the teacher will take decision about the new submitted article.

15. Plagiarism Detector
10
Chapter 4
Scenario Based Modeling of Plagiarism Detector
4.1 Introduction
Scenario based modeling comprises of three diagrams:
 Usecase diagram
 Activity diagram
 Swimlane diagram
Based on the scenario described in previous chapter, we have designed usecase diagram,
activity diagram and swimlane diagram of the project.
A usecase diagram is a graphic depiction of the interactions among the elements of a system.
A usecase is a methodology used in system analysis to identify, clarify and organize system
requirements and it contains some components.
 the actors, usually individuals involved with the system defined according to their
roles
 the use cases, which specific roles are played by the actors within and around the
system
 the relationships between and among the actors and the use cases
In plagiarism detector the usecase diagram represents the whole process and activities of
plagiarism detection.
The actors are to be identified from the scenario.
These actors are of two types:
 Primary Actor
 Secondary Actor
Primary actor: the actors those both produce and consume information of a system
Secondary actor: the actors those either produce or consume information of a system
The identified actors of plagiarism detector are:
 Teacher
 System

16. Plagiarism Detector
11
4.2 Usecase Diagrams and Scenario
Figure 1 : Plagiarism Detector (Level-0)
Usecase Name: Plagiarism Detector
Usecase ID: 1
Primary Actor: Teacher, System
Secondary Actor: System, Teacher
Actions of the actors
The actions of the actors are given below:
Actor: Teacher
1. Action: Insert data
Reply: Data inserted or not
2. Action: Observe report
Reply: Report observed or not
Actor: System
3. Action: Store

17. Plagiarism Detector
12
Reply: Stored successfully or not
4. Action : Calculation
Reply: Calculation success or fail
5. Action: Report Generation
Reply: Report generated or not
Figure 2: Submission (Level 1)
Usecase Name: Submission
Usecase ID: 2
Actor: Teacher
6. Action: Insert data
Reply: Data inserted or not
Actor: System
7. Action : Get data
Reply: Successful or not

18. Plagiarism Detector
13
Figure 3: Calculation (Level 2)
Usecase Name: Calculation
Usecase ID: 3
Actor: System
8. Action: Calculate data
Reply: Calculation successful
9. Action: Store
Reply: Successful or not
Figure 4: Report Generation (Level-3)
Usecase Name: Report Generation
Usecase ID: 4
Actor: System
10. Action: Report generation

19. Plagiarism Detector
14
Reply: Report generated or not
Actor: Teacher
11. Action: Report observed
Reply: Report observed or not
In this section usecase diagram and scenario are described elaborately. Each usecase diagram
contains its name, level number, primary and secondary actors.
4.3 Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. The activity diagrams of our
system are given below:
Figure 5: Plagiarism Detector (Level 1)

20. Plagiarism Detector
15
Figure 6: Insert and observe Activity (Level-2)
Figure 7: Report generation (Level-3)

21. Plagiarism Detector
16
4.4 Swimlane Diagram
The swimlane diagrams of our system are given below:
Figure 8: Plagiarism Detector(Swimlane)
4.5 Conclusion
We have done this part to develop the scenario. In next chapter the data based model is
appeared.

22. Plagiarism Detector
17
Chapter 5
Data Model of Plagiarism Detector
5.1 Data Modeling Concept
Data modeling is a common activity in the software development process of information
systems, which typically use database management systems to store information. The output
of this activity is the data model, which describes the static information structure in terms of
data entities and their relationships. This structure is often represented graphically in entity-
relationship diagrams (ERD).
The data model of our project contains important architectural information and serves the
following practical purposes:
 Provide a conceptual design of objects in the system’s domain and their relationships
 Provide a blueprint for creating the database structure
 Guide implementation of code units that access the database
 Guide performance enhancement in data access operations
A set of following activities is done to design the data model
 Data identification and define attributes for each data
 Create data relationship diagram
 ER diagram
 Table or schema diagram
5.2 Data Identification and Define Attributes of each Data
A data object or data is a representation of information which has different properties or
attributes that must be understood by the software. To identify a data object all the nouns of
the scenario are needed to be analyzed. So we prepared a noun table to identify the data
objects.

23. Plagiarism Detector
18
Noun Table
Noun Accepted/Rejected Comments
Computer × Software installation
Software × Java Program
Teacher ✓ It is the super user that insert
data, observe data
Institute × Educational organization
Thesis paper × Article on a specific topic
Database controller ✓ File manager
Internet × Internet to find content
Frequency × Frequency is count to store
database
Report ✓ Database will store result
System ✓ System will calculate result
and store
File ✓ File will be submitted
Table 1: Noun table from scenario
From the noun table we identified the data objects and the attributes:
Data Object
Teacher
Attributes
 Id
 Password
 userName
Database controller
Attributes
 File-Name
System
Attributes
 Id
 type
Report

24. Plagiarism Detector
19
Attributes
 Id
File
Attributes
 Id
5.3 Entity Relationship Diagram and Schema Diagram
ER Diagram shows the total picture of the interactions of data and it facilitates to construct
schema and database designing of the system.
Figure 9: ER diagram

25. Plagiarism Detector
20
Schema
Figure 10: Schema diagram
5.4 Conclusion
In this chapter we have identified all the nouns and their attributes. We have established
relationships among data objects. In next chapter we will describe the class model.

26. Plagiarism Detector
21
Chapter 6
Class-based model of Plagiarism Detector
This Chapter is intended to describe class based modeling of plagiarism detector.
6.1 Class Based Modeling Concept
Class-based modeling represents the objects that the system will manipulate, the operations
that will applied to the objects, relationships between the objects and the collaborations that
occur between the classes that are defined. The elements of a class-based model include
classes and objects, attributes, operations, class-responsibility-collaborator (CRC) models,
class diagrams.
6.2 Identifying Analysis Classes
Examining all the nouns from the usage scenario potential classes can be identified. For class
identification we have to go through the following steps.
Step 1
Identifying and categorize all nouns in following ways:
 External Entities (e.g. other systems, devices, people) that produce or consume
information to be used by a computer-based-system.
 Things (e.g. report, displays, letters, signals) that are part of the information domain
for the problem.
 Occurrence or events (e.g. a property transfer or the completion of a series of robot
movements) that occur within the context of system operation.
 Roles (e.g. manager, engineer) played by people who interact with the system.
 Organizational units (e.g. division, group, and team) that are relevant to an
application.
 Places (e.g. manufacturing floor or loading dock) that establish of the problem and the
overall function of the system.

 Structures (e.g. sensors, vehicles or computer) that define a class of objects or related
classes of object.

27. Plagiarism Detector
22
Step 2
Selection of potential class is performed by considering six selection characteristics.
1. Retained information: The potential class will be useful during analysis only if information
about it must be remembered so that the system can function.
2. Needed services: The potential class must have a set of identifiable operations that can
change the value of its attributes in some way.
3. Multiple attributes: During requirement analysis, the focus should be on “major”
information; a class with a single attribute may, in fact, be useful during design, but is probably
better represented as an attribute of another class during the analysis activity.
4. Common attributes: A set of attributes can be defined for the potential class and these
attributes apply to all instances of the class.
5. Common operations. A set of operations can be defined for the potential class and these
operations apply to all instances of the class.
6. Essential requirements. External entities that appear in the problem space and produce or
consume information essential to the operation of any solution for the system will almost
always be defined as classes in the requirements model.
6.3 Potential class table:
Potential class General Classification Characteristics
Home Controller Structure Accepted all applied
Database
Controller Structure Accepted all applied
Plagiarism
checker Structure Accepted all applied
File Service Structure Accepted all applied
File process Structure Accepted all applied
Document Parser Structure Accepted all applied
Gram Structure Accepted all applied
Porter Structure Accepted all applied
Cosine Similarity Structure Accepted all applied
Table 2: Selection of potential class
From this table we found the following potential classes:
 Home Controller 
 Database Controller 

28. Plagiarism Detector
23
 Plagiarism checker 
 File Service 
 File process
 Document parser
 Gram
 Porter
 Cosine Similarity 
6.4 Specifying Attributes
Attributes describe a class that has been selected for inclusion in the requirements model. In
essence, it is the attributes that define the class—that clarify what is meant by the class in the
context of the problem space.
We can represent the attributes of selected classes in the following manner:
Home Controller = serialVersionUID
Database Controller = serialVersionUID

Plagiarism checker = Nil

File Service = Nil

File process = Nil

Document parser = Nil

Gram = Nil

Porter = Nil

Cosine Similarity =Nil 

29. Plagiarism Detector
24
6.5 Defining Operations
Operations define the behavior of an object. The operations or methods are given below:
Home Controller = doGet(), doPost()
Database Controller = doGet(), doPost() 
Plagiarism checker = doGet(), doPost() 
File Service = uploadFile(), extractFileName(), DeleteFile
File process = LiftOfFile()
Document parser = getParsedString()

Gram = Gram()

Porter = has suffix(), vowel(), measure(), containsVowel(), cvc(), stripPrefix(), stripSuffix(),
stripAffix()
Cosine Similarity = indexDocuments(), CalcualteIdf(), CalcualteTfIdf(), CalcualteSimilarity()
6.6 Class Diagram for Plagiarism Detector
Home Controller
SerialVersionUID
doget()
doPost()
Database controller
SerialVersionUID
doget()
doPost()

30. Plagiarism Detector
25
Plagiarism Checker
...
doget()
doPost()
DocumentParser
....
getParsedString()
FileService
…
uploadFile()
extractFileName()
deleteFile()
FileProcess
…
ListOfFile()
Gram
….
ListOfFile()
Porter
….
hasSuffix()
vowel()
measure()
containsVowel()

31. Plagiarism Detector
26
cvc()
stripPrefixes()
stripSuffixes()
stripAffix()
Cosine Similarity
….
Calculate
Similarity()
indexDocuments()
CalculateIdf()
CalculateTfIdf()
Figure 11 : Class diagram

32. Plagiarism Detector
27
6.7 Class Responsibility Collaborator (CRC)
Class name: Home Controller
Responsibility Collaborator
1.Manage option Database controller, plagiarism
checker
Class name: Database controller
Responsibility Collaborator
1. file upload File service
Class name: Plagiarism Checker
Responsibility Collaborator
1. File upload
2. File process
3. Calculate similarity
File Service
File Process, porter
Cosine Similarity
Class name: Document Parser
Responsibility Collaborator
1. Parse Pdf Cosine Similarity
Class name: File Service
Responsibility Collaborator
1. Upload File Database Controller
Class name: File Process
Responsibility Collaborator
1. Make list of File Plagiarism Checker
Class name: Gram

33. Plagiarism Detector
28
Responsibility Collaborator
1. define tf Cosine Similarity
Class name: Porter
Responsibility Collaborator
1. stem Cosine Similarity
Class name: Cosine Similarity
Responsibility Collaborator
1. Calculate similarity
2. Calculate tf, tf-idf
Plagiarism checker
Plagiarism checker
6.8 Conclusion
We have identified all potential classes, drawn class diagram and developed CRC. Next chapter
is about behavioral model.

34. Plagiarism Detector
29
Chapter 7
Behavioral Model of Plagiarism Detector
7.1. Introduction
Behavioral model describes the control structure of a dynamic system. This can be things like:
 Sequence of operations
 Object states and
 Object interactions
The behavioral model indicates how software will response to external events. Here, we first
identified all the events from the use case, then we drew state diagram for analysis class and we
drew sequence diagram.
7.2. Identifying Events with the Use Case
We identified the following events from the scenario:
 Teacher inserts data
 System calculates data
 System store result in database
 System generates report
 Teacher observers report
The table for the events identification is:
Event Initiator Collaborator
Insert data Teacher System
Calculate data System File
Store System Report
Calculation System Report
Table 3: Events identification

35. Plagiarism Detector
30
7.3. State diagram for analysis classes
One component of a behavioral model is a state diagram that represents active states for each
class and the events that cause changes between these active states. We consider two different
characterization of state:
a) The state of each class as the system perform its function
b) The state of the system as observed from the outside as the system performs its function.
The state of the class takes on both active and passive state. State diagram for the analysis class
of our system is given below:
Figure 12: State Diagram- Teacher
Figure 13: State diagram-System

36. Plagiarism Detector
31
7.4. Sequence diagram
Sequence diagram indicates how events cause transitions from object to object. Here is only one
sequential diagram for our project. The sequence diagram of plagiarism detector is:
Figure 14: Sequence Diagram
7.5 Conclusion
In this chapter we have identified all events. Based on this events we have drawn state diagram
and sequential diagram.

37. Plagiarism Detector
32
Chapter 8
Conclusion
The first part of the document represents complete SRS report on plagiarism detector. Here we
have tried our best to identify necessary requirements from our stakeholders and based on the
requirements, we have illustrated different models with diagrams which will help the developers,
software designers and other people associated with it to understand about the system and to do
their tasks in a better way. Students as well as teachers may use this document as academic
learning resource. We hope that the readers will get benefit from the document.

38. Plagiarism Detector
33
SOFTWARE ARCHITECTURAL
DESIGN

39. Plagiarism Detector
34
Chapter 9
Introduction to Architectural Design
Software design is the process of implementing software solutions to one or more set of
problems. It is a process that follows a sequence of steps enabling the designers to describe the
software that is to be built. In this document we designed our software named Plagiarism
Detector so that we can describe all the aspects of this before implementation. We designed the
Data flow diagram (DFD), architecture and context diagram, completed component level
designing and finally designed the user interfaces.
9.1 Data Flow Diagram (DFD)
A data flow diagram is a graphical representation that depicts information flow and the
transforms that are applied as data move from input to output. The DFD takes an input-process-
output view of a system. In the figures, data objects are represented by labeled arrows and
transformations are represented by circles. The DFD of our system is given below:
Figure 15: Data Flow Diagram

40. Plagiarism Detector
35
Chapter 10
Representing the System in Context
10.1 Representing the System in Context
Context diagram depicts the environment in which a software system exists. The context diagram
shows the name of the system in the middle representing the system boundary. Rectangles
outside the boundary represent external entities which could be users or actors, organizations,
other software systems or hardware devices that interface to the system. The context diagram of
our system is given below:
Figure 16: Context Diagram

41. Plagiarism Detector
36
Chapter 11
Software Architecture Design
11.1 Software Architecture Design
The software architecture of a system is the structure or structures which comprise the
components, heir externally visible properties and relationship among those components. We
designed the architecture for our software by identifying the components, representing the whole
system in context. We followed the steps given below:
 Step 1.Review the fundamental system model. 

 Step 2.Review and refine DFD for the software 

42. Plagiarism Detector
37
 Step 3.Determine whether the DFD has transform or transaction flow characteristics 

 Step 4.Identify the transaction center and flow characteristics along each of the action
paths 

 isolate incoming path and all action paths 
 each action path evaluated for its flow characteristic 

 Step 5. Map the DFD in a program structure amenable to transaction processing 

 Step 6. Factor and refine the transaction structure and the structure of each action path 

 Step 7. Refine the first iteration program structure using design heuristics for improved
software quality 
Figure 17: Architectural Design

43. Plagiarism Detector
38
Chapter 12
Component Level Design
12.1 Component Level Design
Component-level design occurs after the first iteration of the architectural design. It can be
represented using some intermediate representation that can be translated into source code.
Step 1: Analysis class
Home Controller
SerialVersionUID
doget()
doPost()
Database controller
SerialVersionUID
doget()
doPost()
Plagiarism Checker
...
doget()
doPost()
DocumentParser
....
getParsedString()

44. Plagiarism Detector
39
FileService
…
uploadFile()
extractFileName()
deleteFile()
FileProcess
…
ListOfFile()
Gram
….
ListOfFile()
Porter
….
hasSuffix()
vowel()
measure()
containsVowel()
cvc()
stripPrefixes()
stripSuffixes()
stripAffix()
Cosine Similarity
….

45. Plagiarism Detector
40
Calculate
Similarity()
indexDocuments()
CalculateIdf()
CalculateTfIdf()
Figure 18: All Design classes
Step 2 : Design Component

46. Plagiarism Detector
41
Figure 19: All Design component

47. Plagiarism Detector
42
Step 3: Elaborate Design Classes

48. Plagiarism Detector
43

49. Plagiarism Detector
44

50. Plagiarism Detector
45
Figure 20: Elaborate Design classes

51. Plagiarism Detector
46
Step 3.a: Collaboration Details
Figure 21: Collaboration diagram with messaging

52. Plagiarism Detector
47
Step 3.b: Appropriate Interfaces
Figure 22: Appropriate Interface
Step 3.c: Elaborate Attributes
Teacher
Id: string= null

53. Plagiarism Detector
48
Name: string= null
Password: string= null
Report
Report_id: string= null
Date: date=null
Body: string=null
Subject: string= null
System
Id: string= null
Type: string= null
Desc: string= null
Subject: string= null
Step 3.d: Describe Processing Flow
Figure 23: Activity diagram for insert_data()

54. Plagiarism Detector
49
Figure 24: Activity diagram for observe_report()
Figure 25: Activity diagram for calculate_data()

55. Plagiarism Detector
50
Figure 26: Activity Diagram for generate_report()

56. Plagiarism Detector
51
Chapter 13
Persistent Data
13.1 Persistent Data
Uploaded files

57. Plagiarism Detector
52
Chapter 14
Elaborate Behavior
14.1 Elaborate Behavior

58. Plagiarism Detector
53
Figure 27: Elaborate behavior

59. Plagiarism Detector
54
Chapter 15
Elaborate Deployment
15.1 Elaborate Deployment
Figure 28: Elaborate Deployment

60. Plagiarism Detector
55
Chapter 16
User Interface Design
16.1 User Interface Design
User interface design requires good understanding of user needs. User interfaces can be
designed following different processes like gathering functional requirements, tasks of users.
We designed the user interfaces of our software in a way that can be easily fitted to the
normal workflow of our users. The UI design of our system is provided.
16.2 Target User
1. Teacher
16.3 Literacy
When Admin will login into the system, he/she will see home window. User can upload files
by clicking upload options. User can go to “Plagiarism Checker” option and upload a new
file to check for plagiarism. The percentage of similarity will be shown in result window.
16.4 UI Diagram
When a user login into the system, he/she will see the home page.
Figure 29: Home Page

61. Plagiarism Detector
56
User can upload the files that will be compared to the sample files.
Figure 30: Upload File
User can check plagiarism by uploading a new file and compare it with the previous files.

62. Plagiarism Detector
57
Figure 31: Plagiarism Checker
Figure 32: Plagiarism Checker Result

63. Plagiarism Detector
58
17. User Manual
 After running the application, home page will be shown. There are two options here. Upload
files and plagiarism checker.
Figure 33: Home Page
 User can upload data files by clicking Database
Figure 34: Data file upload

64. Plagiarism Detector
59
 User can choose file from computer and add it into the dataset.
Figure 35: Choose File
Figure 36: Add File
 File/Files will be successfully added.

65. Plagiarism Detector
60
Figure 37: File Added Successfully
 Then user will choose the file to check for plagiarism and check for plagiarism.
Figure 38: Submit a new file to check plagiarism

66. Plagiarism Detector
61
Figure 39: Check Plagiarism
 The result will be generated in percentage
Figure 40: Percentage of plagiarism

67. Plagiarism Detector
62
18. Test Cases
Test Case: User tries to upload new file in database.
Response: Success.
Test Case: User tries to upload file without any file.
Response: Fail.
Test Case: User tries to upload another file.
Response: Success.
Test Case: User tries to submit new file to check plagiarism.
Response: Successfully submitted.
Test Case: User tries to submit file without any file.
Response: Fail.
Test Case: User tries to submit another new file to check plagiarism.
Response: Success.
Test Case: User can view the results.
Response: Successfully viewed.
Test Case: User tries to upload and same file.
Response: Successfully 100 percent plagiarized detected.