Distributed Classroom Requirements Document
DRAFT 1
Created on Feb. 1, 1999 by Amir Lopatin
 

1.0 Problem Statement
How best can the physical walls of the  educational classroom be replaced by networked software?

1.1 Overview
The past couple of years has seen more and more  classroom resources find their way on to the web. We have all benefited from this digital migration in our cs classes with their newsgroups and web pages but  there is still further to travel. The current state of  computing and networking technology allows us to take this trend to its ultimate conclusion: that is, having classes that take place entirely on the web. This idea is just  beginning to explode across the educational scene and already dozens of  universities offer Online courses as part of continuing education programs.
Examples include:

Although few students are involved in these programs as of yet, they are growing quickly. Many of them, though, are designed for low bandwidth users and are restricted to asynchronous modes of teaching. That is the student and the instructor do not really interact concurrently during lecture but mostly communicate via email or newsgroups. In this document I propose the  requirements for a system that models a superior form of distance education. One in which all the participants can communicate and interact concurrently over high bandwidth networks. I call this system the distributed classroom. The goal of the distributed classroom is to model the experience of the physical classroom as closely as possible.
I do not mean to limit the concept by the metaphor though. There are many ways that a distributed classroom can improve upon its physical counterpart. Such possibilities include but are not limited to: I propose that we attempt to create a distributed class room system for our cs190 project

5.0 Client and Target Users
The target users for this system are the intro level CS classes here at Brown. Already many of them are too large to fit in their classrooms and use alot of telecommunication technology to expand the walls of their physical classroom. We are especially qualified to understand the needs of such clients because we have all taken these classes. Specifying the subject  to be taught in our distributed classroom will also simplify some design decisions.
 
 

2.0 Functional Requirements

2.1 Outline
 

2.2 Priorities
The number in parentheses next to each billeted item reflects the priority of the item. A rank of  "1" reflects the highest priority. These features must be included in the initial release. Items of higher rank have a lower priority and will be implemented  only after all items of  lower rank have been successfully completed.

2.3 Functionality Description
In the next couple of sections I will go into greater detail on the above components

2.3.1 Broadcast system:
The broadcast systems is the system by which the instructors lecture is transmitted in real-time to his/her students. It should include live audio and video streaming and ideally an automatic text transcription module as well. This could be accomplished by an off the shelf voice-recognition product. This broadcast would also contain a separate window in which  the instructor could broadcast and point to lecture slides. A simple integrated web browser  could account for this functionality. The final component of the broadcast lecture would be a virtual blackboard which the teacher could use just like a physical blackboard.

2.3.2 Student-Instructor Dialogue
 A lecture is not a one way thing.  The students must be able to interrupt  the lecturer  and ask the instructor to clarify things they don't understand. Similarly, the  lecturer must be able to pose questions to the entire class to assess their understanding. Our software must support this type of dialogue. I believe in this aspect our software can actually improve upon the conventional classroom. In a conventional classroom the teacher has no way of determining who raised there hand first or who has had there hand up the longest. Our software could automatically and fairly determine things like that. Also in a regular classroom a Teacher's question can only be answered by one person. Using our software the entire class can respond. The teacher can then search for keywords to determine whose answer he wants to broadcast. If done right, the software could even determine who is getting it right and who is getting it wrong. This could help the instructor determine who needs more help or if he is going too slow.

2.3.3 Examination Module
Our software will contain a module in which the instructor can write (multiple choice?) exams that can then be automatically delivered and graded.  I imagine that cheating would be a big concern  with this type of exam and so various countermeasures must be taken. One way I imagine that cheating could be counteracted is by presenting only one question at a time with a relatively short time limit for each answer. This would keep people from using reference material.

2.3.4 Administrative module
There are alot of bookkeeping and  administrative details involved in running a class. The distributed classroom package will facilitate the teacher in keeping track of these. It will have a database where grade information can be entered as well as attendance records. Classroom participation can also be monitored and kept track of.

2.3.5 Assignment Module
The function of this module is similar to what most cs classes at Brown already have. A simple program that allows for the electronic handin of assignments. Additional features that can be added to this module if time allows are automatic anti cheating measures and automatic grading programs. Programs that provide such functionality already exist  for free and only need to be integrated with our package.

2.3.6 Class Web Page
No CS course can be complete without a class web page, and this program should be able to automatically produce web pages with links to course content: lecture recordings, lecture slides, grades, etc. If there is time, a web-based bulletin board would be a nice additional feature.

3.0 Hardware and OS Requirements
The server program will run on Solaris.
The client program will run on the Java VM.
High bandwidth internet connection