Software Requirements Specification Notes | CS 430, Study notes of Software Engineering

Download Software Requirements Specification Notes | CS 430 and more Study notes Software Engineering in PDF only on Docsity!

S

Cheat Check

SOFTWARE

REQUIREMENT

S

SPECIFICATION

For CS 430 at West Virginia University, Fall 2008 Lee Zaniewski, Kai Ma, Aaron Costa, Chris Cole 2/14/

Table of Contents

1.0 Introduction

This document will describe all requirements and functionality of the Cheat-Checker Plagiarism Detection Application (CCPDA), which is designed to aid instructors in insuring that student submitted documents meet academic standards for honesty. This document will summarize our product for the customer and developer.

1.1 Goals and objectives

The initial purpose of CCPDA is to check source code to see if it was plagiarized from another source such as a student or any publicly searchable online database. We hope to make CCPDA platform independent, easy to use, and easily extensible for other document formats.

1.2 Statement of scope

CCPDA will compare documents submitted to the instructor and/or to public databases for similarities and show these similarities in an easily readable graphical format.

1.3 Software context

Our software will attempt to quicken the process of checking for plagiarism in an academic setting. Our team realized the difficulty involved for instructors attempting to prevent academic dishonesty, and hope to ease some of the burden in reviewing large number of submissions.

1.4 Major constraints

The major constraints of this project are limited design and implementation time due to the length of the academic semester.

2.0 Usage scenario

This section provides a usage scenario for the software. It contains organized information collected during requirements elicitation into use-cases.

2.1 User profiles

Our primary users will be educational instructors. It is likely they have had some previous computer experience. It can also be assumed they have experience with whatever language the document is in.

2.2 Use-cases

4.0 Functional Model and Description This section contains descriptions of each major software function, along with a data flow diagram.

4.1 Gather Project Information

This function takes user input for files or directories to be evaluated as well as a project name and a project type (source code, poem, etc.) User also specifies the run mode (local or global) and various other configurables via the Graphical Interface.

4.1.1 Processing narrative (PSPEC) for Gather Project Information

The user selects all project options via the user interface. Once all user options are entered, the selected files are represented in internal data structures and are now ready to be analyzed against other documents.

4.1.2 Function Gather Project Information flow diagram

4.1.3 Function Gather Project Information interface description

The interface would consist of a pop-up menu to define project options and a second screen for run time options. The output interface would be a graphical listing of options selected.

4.1.4 Performance Issues

Since graphical processing is done in a single main loop, this functionality is not processing intensive.

4.1.5 Design Constraints

The user interface should be intuitive as well as follow Human Interface Guidelines (HIG). For example see: http://developer.gnome.org/projects/gup/hig

4.2 Compare Documents

The program will take the files from the user input and compare them lexically using tokens.

4.2.1 Processing narrative (PSPEC) for Compare Documents

The program compares the files using the tokenized format that the precious function put them in using a specialized algorithm and then returns the results of the comparison.

4.2.2 Compare Documents flow diagram

4.2.3 Compare Documents interface description

While comparing the documents, the user will be presented with a progress bar and possibly statistics on finished documents.

4.2.4 Performance Issues

This will be the most intensive part of the program, and could possibly take several minutes to complete.

4.2.5 Design Constraints

We will attempt to write this is the most computationally efficient manner, as it is the most expensive.

4.3 View Results

Once processing is completed, the user will be directed to a results screen in the user interface, where the date from the comparisons will be represented in a graphical format. The user can print and export the results for later viewing.

4.3.1 Processing narrative (PSPEC) for View Results

Once the comparison engine has finished, the raw output data will be displayed graphically. If the user chooses, the file will be printed or saved.

4.3.2 Function View Results flow diagram

4.3.3 Function View Results interface description

The results interface will consist of output percentages and graphs from the comparison engine, as well options to save and print.

4.3.4 Performance Issues

Performance issues should be minimal in graphing sets of our raw data.

5.0 Behavioral Model and Description

A description of the behavior of the software is presented.

5.1 Description for software behavior

A detailed description of major events and states is presented in this section.

5.1.1 Events

User sets project options User initiates local or global analysis System queries databases System parses documents System Looks for Matches System returns results User exports results

5.1.2 States

User Input Prepare List of Project Files Import Project Files Prepare Query Query Repository Load Engine Parse Documents Compare Documents Prepare Results Return Results Display Results Save Results Print Results

5.2 State Transition Diagrams

7.0 Validation Criteria

The approach to software validation is described.

7.1 Classes of tests

We will test for different forms of plagiarism. We obviously cannot be completely exhaustive, as the number of possible inputs is infinite. However, we will insure that certain predefined patterns of plagiarism will be caught. We will also test cases that are not plagiarism. We should be able to test our inner subsystems independently e.g. parse engine, document queries, etc. We will also test the results to make sure that they are outputted correctly for common scenarios.

7.2 Expected software response

As stated before, after a query is run, the outputs will be displayed in the GUI window in a graphical format.

7.3 Performance bounds

The performance bounds will be the number of search matches from online databases as well as reasonable run time for comparisons of size 50 or less.

8.0 Appendices

8.1 Early Prototype Concepts

We created a rapid prototype of the User Interface after brainstorming, and based our requirements and functionality off of this.

8.2 Product Strategies

This specialized product should be targeted towards institutions of higher learning and the open source community.