Software Requirements Specification

Version 2.0
CROSS-SECTIONS AND SLICES
(December 11, 2000)
THE CONEHEADS
TEAM 09-1 MEMBERS:

Brandon Napier (cocheez@mail.utexas.edu)

Jason Diaz (jdiaz@austin.rr.com)
Imran Sheikh (imran@cs.utexas.edu)
Anthony Thane (mailto:%20thanea@mail.utexas.edu)
Stephen Kattner (s.kattner@mail.utexas.edu)
Chris Goyer (cgoyer@mail.utexas.edu)

TABLE OF CONTENTS
1.0 Introduction
1.1 Purpose of this Document
1.2 Scope of the Development Project
1.3 Definitions, Acronyms, Abbreviations
1.4 References
1.5 Overview Of Document
2.0 General Description
2.1 User Personas and Characteristics
2.2 Product Perspective
2.3 Overview of Functional Requirements
2.4 Overview of Data Requirements
2.5 General Constraints, Assumptions, Dependencies, Guidelines
2.6 User View of Product Use
3.0 Specific Requirements
3.1 External Interface Requirements
3.2 Detailed Description of Functional Requirements
3.3 Performance Requirements

3.4 Quality Attributes

3.5 Other requirements

1.0 Introduction
1.1 Purpose of this Document

This SRS document describes the functionality and performance goals for the
software project "Cross-sections and slices". The project is being designed for Dr.
Maggie Myers on behalf of the Dana Center. This document lists constraints and
considerations that the team will keep in mind throughout the design and
development of the project. Furthermore, the document defines terminology,
provides a list of references, and gives an overview of functional and user
requirements for the creation of the product.
1.2 Scope of the Development Project

The "Cross-sections and slices" product is an interactive learning tool that will help
demonstrate the relationship between common three-dimensional figures and their
respective two-dimensional cross-sections. The product will support the Texas
Essential Knowledge and Skills d1A on cross sections for three-dimensional
figures. Since this project is a new development, the two primary goals are to
provide the basic functionality and to create code and documentation that will
enable later projects to improve upon the initial design.
The project will be limited by the target hardware due to their dial-up internet
connections and slow processor speeds. Concerns about the clients technology
capabilities have dictated a multi-platform approach utilizing Java APIs.
The product will include the following features.

The ability for students to manipulate three-dimensional objects with a

mouse or other type of pointer.
The program will create two-dimensional shapes as the student manipulates
the object across a two-dimensional plane.
The program will be platform-independent to allow the program to run on
most computing environments.
The ability for the student to manipulate a plane that will intersect a doubleended cone. This will allow the students to create circles, parabolas, ellipses,
and hyperbolas by intersecting the 3D object with a 2D plane.

1.3 Definitions, Acronyms, and Abbreviations

API Application Program Interface.

AWT Abstract Windowing Toolkit
Browser An interface program designed to retrieve and view information over the
Internet. Internet Explorer and Netscape are both examples of Internet browser.
Java An platform independent object-oriented programming language.
JVM The Java Virtual Machine; interprets and executes Java bitcode, and interacts
with the native operating system.
Java Applet Programs that are downloaded from the the internet and run inside a
web page. To run an applet, one needs a Java-enabled browser such as Netscape
Navigator.
SRS Software Requirements Specification.
TEKS Texas Essential Knowledge and Skills
3D Short for three-dimensional; indicates that an image produces the illusion of
depth
Web A subset of the Internet providing hypertext services.
1.4 References

Schach, Stephen R. Classical and Object Oriented Software Engineering with

UML and Java. St. Louis: McGraw-Hill, 1999.(pgs. 302-311)
Dorfman, Merlin and Richard H. Thayer eds. Software Engineering. Los Alamitos,
CA: IEEE Computer Society Press, 1997.(pgs. 83-85, 90-91)
Eckel, Bruce.Thinking in Java: The Definitive Introduction to Object-Oriented
Programming. Upper Saddle River, NJ: Prentice Hall PTR, 1998.
"The Source for Java Technology", provides tutorials, downloads, and
documentation for the Java programming language.http://www.java.sun.com/
1.5 Overview of Document

Section one provides a brief introduction to the software requirements of the

project. The second section presents several user personas, data requirements, and
the types of anticipated interaction between the users and program. The third
section discusses the interface, functional, and performance requirements in detail.

2.0 General Description

2.1 User Personas and Characteristics

Our primary users will be high school students and some junior high students at
various schools throughout Texas. Our team has come up with the following three
personas:
User A's name is Bart, a male 9th grade student who uses a computer to e-mail
friends and play computer games on a daily basis and feels comfortable using a
computer. He is interested in art and music, specifically cubist painting. He likes
to write short stories. Up until this point he has focused on subjects like English
and history. He is a little uncomfortable with mathematics and his perception is
that he is not very good at algebra.
User B's name is Julie, a female 11th grade student. She does not own a computer
but has used one at school on occasion. She feels comfortable using a computer if
someone shows her how to get an application up and running and how to use the
application. She has excelled in math and science and is a good overall student.
She hopes to go to a top university and study physics. She comes from a low
income family and therefore her family does not have the resources to buy a
computer. She realizes the importance of computers in academics and the
workplace today and is very receptive to any chance she can use one.
Mr. Finkelstein is a high school Calculus teacher who has taught mathematics to
high school kids for 12 years. He is an experienced computer user who spends time
in the evening researching snails on the Internet. He is interested in using
computers to enhance calculus concepts in the classroom by using a computers
ability to show information visually. He is competent at using a computer although
he does not feel comfortable with installing software or hardware.
2.2 Product Perspective

This product is a single functional unit and is not a sub-unit of any other
program.
This product will require a web browser and will determine the interface's
appearance. The program will be supported by Microsoft Internet Explorer
and Netscape browsers that support Java.
This program does not require any new or special hardware. Suggested
hardware includes a mouse, 486DX/66 MHz or higher processor with 16
MB of RAM, and a monitor.

2.3 Overview of Functional Requirements

1. Tutorial/Demonstration Screen: A screen to provide instruction on the use

of the program. This will include instructions on how to manipulate the
shapes as well as an introduction to the idea of conic sections

2. Shape Screen: Allows the user to manipulate the relative positions and
orientations of the cutting plane in relation to the cone.
3. Intersection Screen: Required to display the result of intersecting the cone
and plane positioned by the user in the Shape Screen.
4. Button Panel: Provides the user the opportunity to toggle between moving
and rotating the cutting plane.
2.4 Overview of Data Requirements

No data need be stored in files; the information required to depict the cone and
two-dimensional curves will be generated dynamically.
2.5 General Constraints, Assumptions, Dependencies, Guidelines

The project will be web based. It must run on as many hardware configurations and
operating systems as possible. Ideally, the software should allow real time
manipulation of the shapes, but this may not be possible on all hardware
configurations. The project should not be dependent on any software add-on
packages. It should attempt to use older standards when possible since many
schools do not update their software very often.
2.6 User View of Product Use

The software starts in interactive mode. The user sees a split screen. On the left
side is a picture of a cone. A vertical line divides the left and right side of the
screen into two; the left side shows the three-dimensional object. On the right side
of the screen is a two dimensional picture of the intersection defined by the shape
and plane. The user, with the mouse or with keyboard commands, rotates and
positions the cutting-plane across the shape. The right-hand side of the screen
updates the image of the intersection in real time. If the user pauses for a couple of
seconds, the right-hand side generates a description of the intersection, such as
"hyperbola", and displays other useful information such as the equations describing
the curve.

3.0 Specific Requirements

3.1 External Interface Requirements

Operator/user interface will be primarily driven by a mouse or other

pointing device.
The interface between the program and hardware will consist of the user
interface, the mouse and keyboard. Three-dimensional rendering can often
require the use of special three-dimensional accelerators, however, since this
is not a complex image, this will not be necessary for this product.

The product's interface with other software will include web browsers and
the operating system. The web browser must include the necessary libraries
to run the three dimensional graphics or be able to add them as a
plugin. The operating system must also be able to handle these libraries, but
that should not be a concern, since the browser will manage the majority of
software to software interface.

3.2 Detailed Description of Functional Requirements

Sections 3.2.2 through 3.2.5 detail the functional requirements of the major
components of the project. The template used to describe each is given in section
3.2.1.
3.2.1 Template for describing functional requirements

purpose
inputs

processing

outputs

a general description of the functional requirement of

the component
which inputs; in what form/format will inputs arrive;
from what sources input will be derived, valid domains
of each input element
describes the outcome rather than the implementation;
include any validity checks on the data, exact timing of
each operation (if needed), how to handle unexpected
or abnormal situations
the form, shape, destination, and volume of the output;
output timing; range of parameters in the output; unit
measure of the output; process by which the output is
stored or destroyed; process for handling error
messages produced as output

3.2.2 Tutorial/Demonstration Screen

purpose

inputs
processing
outputs

A screen that provides instructions on the use of the

program. These will include instructions on how to
manipulate the shapes as well as an introduction to the
idea of conic sections
Inputs will come in the form of mouse clicks on HTML
links.
The web browser will fetch the requested screen of
instructions
The instructions and information will be displayed as
needed by the user.

3.2.3 Shape Screen

purpose

Allows the user to manipulate the relative positions and

orientations of the cutting plane in relation to the cone.

inputs
processing
outputs

The user will drag the mouse to position the cone

and/or plane.
The program will keep track of the transformations and
use the information to calculate the information needed
to display the shape and plane for each frame.
A 3D image of the shape will be displayed.

3.2.4 Intersection Screen

purpose

inputs

processing

outputs

Displays the result of intersecting the cone and plane

positioned by the user in the Shape Screen.
The user will only indirectly provide input by using the
mouse to interact with the Shape Screen. The
Intersection Screen will take as input the
transformations recorded by the Shape Screen.
The transformations will be used to determine the
nature of the intersection between the cone and plane.
The equations describing the intersection will be
derived
A 2D picture of the resulting intersection will be
displayed. The picture must update in real time as the
user interacts with the Shape Screen.

3.2.5 Button Panel

purpose

inputs

processing

outputs

Allows the user to control how the plane is

manipulated.
The user will select radio boxes on the left hand side of
the screen depending on whether they want to rotate or
translate the plane. An option to "snap" the plane into
common angles will be included as well.
The selection that the user makes will determine which
state the plane is in. By manipulating the plane, that
information will then be used as the plane is either
rotated or moved.
When the mouse button is held down, movement inside
the three-dimensional window will affect the position
of the plane.

3.3 Performance Requirements

The files containing the project should be small enough so that the program can be
loaded in less than one minute over a 28.8 kbps dial-up internet connection. Also,
the program will not require the user to download any plug-ins or any other
additional software. The program will run well on hardware that is less than four
years old as older computers may not include the JVM software. The program will

create a realistic 3D rendering of the cone inside the shapes screen and real-time
2D curve drawing within the intersection screen .
3.4 Quality Attributes

The security of this program should not be a concern. There will be no negative
effects on the client's hardware or software caused by running the program. Once
the program is downloaded, it will run on top of the JVM and will not have direct
access to any of the underlying hardware.
The program will be available through the team's home page or possibly later on a
CD compilation of the s2s projects. The reliability of the product is assured as
long new browsers continue to provide a JVM to execute Java code, and the APIs
utilized within the code are not deprecated by Sun Microsystems in the future.
The design of the project will encourage extendibility of the source code to include
new shapes and shape manipulation. An object-oriented design will enable later
groups to easily modify, improve, and expand the original program.
3.5 Other requirements

None at this time.

Change History:
10/10/00 version 1.0- Creation of initial document.
10/31/00 version 1.1 - Adjusted layout, brought bibliography into MLA
conformance, clarified section 3.4, and modified portions of 3.2 in light of new
client requirements.
12/11/00 version 2.0 - Added requirements for the button panel in 3.2.5 and 2.3,
removed review questions requirement in 2.3, fixed spelling errors and
bibliography formatting.

To Top of Document