Software Requirements Specification (SRS)

The document in this file is an annotated outline for specifying software requirements, adapted from the IEEE Guide to Software Requirements Specifications (Std 830-1993).

SYNERGY

CS4893 (Synergy) Software Requirements Specification Document

Synergy member: Guangming Wang Karam Kim Wanjia Chuang

Version: (1.2)

Date: (03/07/2010)

Change Log
Version Date
1.0 2/15/10

Change Description
Initial draft is based on the Software Requirements Understanding

Author
Guangming Wang Wanjia Chuang Karam Kim

1.1 1.2

2/22/10 3/07/10

Changes made based of 1st review. Changed made based on 2nd review.

Guangming Wang Wanjia Chuang

Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.5 Overview 2. The Overall Description 2.1 Product perspectives 2.1.1 System Interfaces 2.2 Product Functions 2.3 User Characteristics 3. Specific Requirements 3.1 Performance Requirements 3.2 Logical Database Requirements 3.3 Software System Attributes 3.5.1 Availability 3.5.2 Security 3.5.3 Portability 4. Document Approvals 4 4 4 4 4 5 5 5 5 6 6 6 6 6 6 7 7

1. Introduction

1.1 Purpose
The purpose of the SRS is to present the client and the organization developing the software with an overview of the functionality promised to be delivered by the product. The intended audience of the SRS is both the client and the members of the organization responsible for developing the product.

1.2 Scope
The software product to be produced is called OASIS which stands for Online Automated in-class Instant Assessment System. The software will enhance student involvement in class learning, interaction between instructor and students in the classroom, and collaborative exploration among students via a real-time online Java learning assessment system. This software is to be applied in a classroom setting to benefit both the teacher and the student. It will enhance student involvement and establish inquiry-based learning, which leads to hands-on learning and understanding rather than just listening and remembering for the students. It will benefit the teachers by allowing them to track student progress in this interactive learning environment.

1.3 Definitions, Acronyms, and Abbreviations.

OASIS - Online Automated in-class Instant Assessment System MVC- Modle View Controller JDK-Java Development Kit JSP-Java Sever Page JCRT-Java Compile Run Test JSTL- JavaServer Pages Standard Tag Library AJAX- asynchronous JavaScript and XML

1.5 Overview
The SRS will contain an introduction intended for a quick overview of the software product. This section will be most useful as an executive summary. Section 2 will contain some of the general requirements that will be fulfilled by the software product intended for the client. Section 3 will entail a more detailed version of the requirements intended for the developers of the software.

2. The Overall Description

6 This system supports Java online compilation, testing and verification and an online runtime environment. It can test Java console, GUI, and Web Applet programs.

2.1 Product Perspective

The developed Online Automated in class Instant Assessment System is a student active and collaborative learning environment for introductory Java Programming. 2.1.1 System Interfaces Instructor Aspect Log in. Add students into the system. Assign students logins. Add courses into the system. Edit course information. Generate problem specification, including problems description, tests, hints and test cases. Modify existing problems. Review a statistics report on student performance that shows the percentage of success and failure, and the common issues which cause the failure Student Aspect Log in. Do fill-in blanks problems created by instructors. Compile the program. Run the program. Share works with classmates in a collaborative way. Submit their work. Receive feedback individually with test diagnosis results and hits right after the submission.

y y y y y y y y

y y y y y y y

2.2 Product Functions Instructor Aspect:

y y y y y y y y Log in Add student into the system. Assign students logins. Generate Problems: Create problems by specifying the description, demo screenshots and standard answer(source code). Generate Questions: Add a new question to an existing problem by making parts or all of the standard source code blank. Modify Questions. Design Test Cases: generate test cases to validate students submission. Session setup:Set a timeout for each in-class assessment session.

7 y Report Review: Review the statistics report based on students performance. Student Aspect Fill in blanks: try to solve problems by filling in blanks. Collaboration: Share works with classmates in a collaborative way. Compilation: Compile programs. Running: Run compiled programs. Submission: Submit completed work. Get Feedback: Get feedback on submitted works. Off-class Practice: select the programming problems in the OASIS repository to review and practice off class.

y y y y y y y

2.3 User Characteristics y The main users of this product are general university or college students who have basic computer operating knowledge and instructors who have technical expertise in programming and experience. y Our product also can be used for such kind of people who want to learn programming. Basically, such kind of people does not have much programming background.

3. Specific Requirements
This is our first version specific requirement, since our client gives us different goals as time goes by based on our learning ability and Web knowledge background. Because this project has a lot of things, for example, JSP, Web-flow, Java Applet, that some of us have little knowledge about that, some of us need to be more familiar with those things, we have to learn them by ourselves as soon as possible to finish our goals on time.

3.1 Product goals 3.1.1 Implementation of adding and editing a new problem including test suites to a course in OASIS from a instructors view. 3.1.2 Implementation of creating, saving, deleting test cases based on users requirements within a test suite of a problem. 3.2 Goal requirements
We need to have concrete understanding of Java Web-flow, XML, Javascript, JSP and be able to comprehend the existing source code of OASIS in order to integrate our work with it. The following part is our final goal requirement, based on the existing source code of OASIS.

8 y y y y Implementation of adding the corresponding new test suite when adding a new problem. Implementation of adding new test cases to an existing test suite Implementation of deleting Implementation of displaying correct data when users come back to problems they created before Testing for what we have done so far

3.2 Performance Requirements

y y Students will get feedback within 20 seconds after their submissions. The system should be able to support up to 50 users simultaneously.

3.3 Logical Database Requirements

The problem specifications, as well as the historical evaluation results, are stored in the problem bank. The standard answer and the programs submitted by the students are stored in Java source file format in the file system of the server, the test cases are encoded in XML format stored in the servers file system, as well.

3.4 Software System Attributes

3.4.1 Availability The OASIS runs only infrequently on-demand and system recovery is not required since the system is instant. 3.4.2 Security Only professors and students with authorization are able to log in our system. Others dont have accounts assigned. 3.4.3 Portability The OASIS is fully portable because its supported by an online Java compiler, tester, and runtime execution server engine

4. Document Approvals

9 Identify the approvers of the SRS document. Approver name, signature, and date should be used.