Embed Size (px)
Citation preview
Software Requirements Specification
for Python Checker
Version 1.0 approved Prepared by Matthew Arnold, Seong, Ian
Computer Science Team 4 February 4th 2015
Table of Contents
Table of Contents i Revision History ii 1. Introduction 3 1.1 Purpose 3 1.2 Document Conventions 3 1.3 Intended Audience and Reading Suggestions4 1.4 Product Scope 4 1.5 References 4
1.6 Document Overview 5 2. Overall Description 5 2.1 Product Perspective 5 2.2 Product Functions 5
2.3 Client Characteristics 5 2.4 User Classes and Characteristics 6 2.5 Operating Environment 6 2.6 Design and Implementation Constraints 6 2.7 User Documentation 7 2.8 Assumptions and Dependencies 7 3. General Requirements 7 3.1 User Interfaces 7 3.2 Network Requirements 8 3.3 Error Handling 8
3.4 Security Requirements 9 3.5 Input Requirements 9
3.6 Output Requirements 9
3.7 NonRequirements 9
Glossary
Appendix A: UML Graphics 10 Appendix B: Document Writing Contributions 11
Revision History
Name
Date
Reason For Changes
Version
1.Introduction
1.1Purpose Python Checker is a web application that allows users to run their python code and check their output against the expected output. The user will upload their .py files and run their code and if their output is an expected output, they will receive a token, letting the administrator know that the user was successful in getting the same output as the test cases. The overall goal is to allow an application to check the python code.
1.2Document Conventions Each section of the document will begin with a heading noting the contents of that section as well as a section number (EG section 1.Introduction). The subject will then be broken down into subsections each with a corresponding number(EG section 1.2Document Conventions). For a further breakdown of the information located in each section, consult the index at the beginning of this document.
1.3Intended Audience and Reading Suggestions The Python Checker is targeted for Dr. Cooper, the adjunct professor, and his students for his Computer Science class. While the intended audience is the teacher and his students, this application could be used to anyone who is trying to learn python to check whether their code is producing the successful output. It is important to read the introduction section of the document as it mentions the purpose of the application and its scopes. After, the overall description provides different aspect of the application and its characteristics. Once you have the introduction and the overall aspect, we can go more deeply into the detailed oriented description of this application such as the external interface requirements and the system features.
1.4Product Scope
The Python Checker will have an administrator who could upload different assignments and different test cases for that assignment. Once the administrator has the assignment up, any student, the users, can go to this application and run their python code to check whether their code prints out the expected output for each test cases. If successful, each user will receive a token that will acknowledge the administrator that the users code printed an expected output, directing that their code works the way the administrator wanted to.
1.5References Seong Cho: [email protected] Ian Hill: [email protected] Matthew Arnold: [email protected]
1.6Document Overview The Python Checker document has 4 major sections. The Introduction, Overall Description, General Requirements, and Glossary. The introduction gives a brief explanation as to the reason for the products conception. Additionally it contains contact information for the requirement gathering team should any questions arise. The Overall Description gives an explanation on the functionality, characteristics and constraints of the project. It also contains suggestions or options on how to implement certain features of the system.
The General Requirements lists in detail all of the requirements that the system has. The Glossary contains relevant figures created in the brainstorming of this document. Additionally the contributions of each team member are also listed.
2.Overall Description
2.1Product Perspective The Python Checker is the creation of Gusty Cooper and is a selfcontained, new product. There are other products that are similar to the Python Checker, however here are no noticeable existing products that are entirely similar. In example, there are checkers for Javascript and Java, however there is nothing that clearly supports the checking of Python programs.
2.2Product Functions
● Upload Test Cases and Python Code ● Allow Creation of Administrators and Super Administrators ● Run Test Cases ● Run User Submitted Python Code ● Check Submitted Python Code for Errors ● Check Submitted Python Code against Test Cases ● Report on Test Case failures and where student code failed ● Generate and Submit token to student upon success of test cases to then submit to
admin ● Check authenticity of token upon Administrative receival of token
2.3Client characteristics Client Meeting Schedule and Contact Information. The client specified that he would like to meet once every other week to check on progress. Additionally this would allow him to give feedback on any features that are completed. Please allow one business day for him to return your emails. The clients best form of contact is via Email: [email protected] The client is willing to work with the development team on a meeting time and location, though requests that it not be too late. A suggested time of before 6P.M. MondayFriday was requested.
2.4User Classes and Characteristics There will be 3 types of Users: Super Administrator: A Super Administrator (aka Gusty) is in charge of their own current projects/test cases that they have submitted to the Python Checker, as well as adding and deleting other potential professors who may want to use the system for their classes. Super Admins also have the ability to check the validity of tokens for successful student code. Super Admins will have Login Credentials. Administrator: The Administrator is Responsible for uploading their own current projects/test cases that they have submitted to the Python Checker. Administrators are created by the Super Administrator and have their own instances of the Python Checker. They can also be removed at any point by the Super Administrator. Admins also have the ability to check the validity of tokens for successful student code. Admins will have Login Credentials. Student User: A Student User has access to the site via a URL that they may enter in their browser. Upon uploading their code to the site, and depending on their code’s quality, they may receive feedback in one of three ways: A compiling/runtime error, an error detailing a failed use case, or a token to submit to their teacher, verifying that their code has successfully passed all Test Cases for the individual project.
2.5Operating Environment Constraints The system will exist in the format of a Web Application. It will sit in an Amazon AWS deployment, and through this should function perfectly with any backend logic that will be written in python.
2.6Design and Implementation Constraints There are no restraints on how the front end of the Web Application should be created. The development team has the liberty to choose between whatever weblanguage they feel comfortable with (i.e. Javascript, Ruby on Rails, Python, PHP, etc.). However, the backend must be written in python in order to allow for optimal performance. A python backend allows for the code being tested to run in a normalized environment, and will reduce the need for tools or libraries that might plague other potential serverside language choices. A database will also be necessary, and is again at the developers choice between relational or
nonrelational databases. Regardless of the database, the database will need to be secured as it will hold not only the test cases, but the Super Admin and Admin credentials for the site. Given this is a lowprofile, lowtraffic application, SHA2 encryption will suffice.
2.7User Documentation Documentation on the functionality of the site will be provided server side for local developers to view, in case expansion of the product is necessary in the future. Instructions on how to use the application, and features the application includes, will be provided on the front end of the application for all users benefit.
2.8Assumptions and Dependencies ● AWS Deployment could be an issue, depending on price ● Rosemary or Domain of Ones Own alternatives
3.General Requirements
3.1User Interface Requirements
3.1.R1 Graphical User Interface The system will have a Browser accessible Graphical User interface. No Specifications or suggestions of GUI appearance were supplied from the client on how to implement a GUI. The Requirements Team suggests a simple easy to read template that allows students and professors an easy way to navigate through the content. We suggest that the GUI be broken up into three distinct pages. The three template pages are listed below. Home Page The home page layout will contain links to all of the assignment pages. Each assignment page will be clearly defined and difficult to mix up with previous or alternate assignments. There was interest in allowing other professors to utilize this product if the product proved successful. As such this page should support multiple super sections that then could contain the individual assignments. A basic HTML example format is below. Python Checker CS110 Section 01 Professor Ian
Assignment 1
Assignment 2 CS110 Section 02 Professor Matthew
Assignment 1 Assignment 2
Test Page The test page GUI will need to be copied for every assignment. This is the page that will allow users to test their code vs the test cases. Admin Page The admin page allows Admins to change and update the test cases. This page does not allow them to change how the back end logic of the site works. Instead it allows the creation and manipulation of “Test Pages” (Defined above).
3.2 Network Requirements
3.2.R1 Network Availability The system will be available for 90% of its operating life cycle. 6% of the remaining time will be accounted for in scheduled downtime for maintenance. The other 4% is for unpredicted outages. In order to be available for when students need the system it must have very little down time.
3.3 Error Handling Requirements
3.3.R1 User Test Code Errors The system will notify the user of errors generated by the test code. The errors expected from this test are such things as compilation errors and may be displayed onto the screen. 3.3.R2 Database Generated Errors The system will notify the Admin and Super Admin whenever a Database Generated error occurs. If the database generates an error the admins need to be notified. The two options the requirement team thought of were either system generated automatic emails. And/or a display to the students informing them to contact their professor about a “Database system error”.
3.4 Security Requirements
3.4.R1 Password Protected Accounts There will be a protected password required when creating an admin and super admin accounts. Those password protects others from trying to enter the application as an admin or a super admin. These can be alphanumeric characters. 3.4.R2 Secure Token Generation When an user receives a token for a successful run, the token will be text based that was generated and stored in the database. These text based token will be protected by an unique ID.
3.5 Input Requirements
3.5.R1 Input Validation All relevant login sections must be checked for validity. If a database is used to store the test cases and admin information as suggested by the requirements team, that data must be checked for malicious code. (Such as SQL injection) 3.5.R2 Test Code input The users will upload a python “.py” extension file when attempting to test their code. Another possible method is to have the users copy and paste their code in a relevant window. However this feature should only be considered after requirement 3.5.R2 is finished.
3.6 Output Requirements 3.6.R1 Token Generation The system will generate a text based “token” when a users submitted code clears the test cases. The output for a successful python file will receive a text based token that will verify that their code’s output was same as to the test case’s. The students can use this token to verify with Dr. Cooper that their code ran successfully. The token must have a unique ID so that it cannot be duplicated.
3.7 NonRequirements 3.7.NR1 Maximum Capacity The system must not be required to have a maximum capacity.
With a classrooms running from 25 to 30 students, it is timeconsuming for professors to individually check everyone’s code. Python Checker is the solution to this problem, as it’s purpose is to check python codes to determine that this code’s output was the expected output. As for capacity, there is no limit because anyone can upload their python file to test their code. The users upload their own file and do all the work themselves as the professor checks the token to verify their work.
Glossary Appendix A: UML Graphics This section contains all of the UML graphics and projects that were created while brainstorming this product.
Figure B.1: Use case Diagram of the product
Figure B.2 Use case cards Appendix B: Document Writing Contributions Matthew’s contribution All of section 2 with the exception of 2.3. Seong’s Contribution Introduction(1.11.5). Section 3.7.NR1, 3.4, 3.6 Ian’s contribution Appendix A, section 1.2, 1.6, 2.3, 3.1, 3.2, 3.3, 3.5 and formatting and editing.
