High Level Requirements Document

CSCE 320

Write a document giving the High Level Requirements for the game project. Use the document outline given in
the text in Figures 10.9 and 10.10. The contents of chapters 10, 11, and 12 are especially relevant here. In
particular, note the examples in the book of this document for the Encounter Video Game case study (sections
11.10 and 12.14). (Don't despair at their length and detail; our game is much simpler!)
This should represent the overall requirements for the entire project. We will organize the detailed requirements
according to the project increments.
When you organize the requirements pay particular attention to the fact that you will be doing an OO design but
don't use the Figure 12.2 organization as I don't think it is helpful. Instead incorporate the Classes/Object section
of the OO part of Figure 12.2 into the 3.7.3 section of what is in Figure 10.10.
At this point your class design is going to be high level and will need to be modified as the detailed design of the
increments is performed. Still, it is very useful to start thinking about class design while you are organizing high
level requirements.
The delivery should be targeted towards the customer as this document is often used as the basis of a contract.
You must present and explain all context and design decisions and you should not assume your audience has ever
seen the project proposal.
These are high level requirements that apply to the whole project. There will be separate detailed requirements
for the increments in the development (authentication, matchmaking, game play, ).
Your document should be professional in quality and appearance. Look at the document guidelines on the class
project page.
The general outline and structure of the document should match that in Fig 10.9 and 10.10 in the text. In part 3,
Specific Requirements, you should include several organizing concepts of section 3.7 despite the fact that the
text implies you only need one. You should include at least these: Feature (i.e. functionality), Use Case, GUI
(navigational path and sketches of the main views), State (for the client and server), Communication (between
the client and server), and Class (a first draft of the essential classes of the applications).
The IEEE 830-1998 Requirements standard is available from the project page.

Evaluation Rubric each person will be evaluated as follows

A

Weight & Score

The purpose, scope, definitions, references, and

overview for the document are complete and
correct.

There are one or two elements that are incomplete,

inconsistent, or incorrect.

The document is not adequately described.

5%

2.1 Product Perspective

The project is well described in term of how it

relates to other hardware, software, and systems
in the customer's environment. User interfaces
should only be described in general terms with
sketches postponed until section 3.1.

One or two perspectives are missing, weak,

ambiguous, or incorrect.

2.2 Functional requirements

The functionality of the project is complete, clear,

and unambiguous.
A complete and clear Use Case model is given.
Each Use Case has a clear and well written
description showing actors and their interactions.

The functionality is missing one or two essential

elements. The Use Case Model covers the essentials
but is weak in that it is missing some cases. Use Case
descriptions are missing some details or lack
extensions etc.

Model is incomplete or inaccurate. Descriptions

are weak.

10%

2.3-6 Constraints,
Assumptions, Apportioning

Well described and clear listing of constraints and

assumptions. The project increments are clearly
defined.

There are one or two elements missing or weak.

These are incomplete or inaccurate.

5%

3.1 Interfaces

The User, Hardware, and Software interfaces are

well described in detail. The GUI navigational
path is clear and complete.

One or two interface elements are missing,

ambiguous, or contradictory.

The interfaces are not well described.

20%

3.2 Requirements

The requirements are organized and explained

using several tools such as state diagrams,
communication diagrams, class diagrams, that
are clear, consistent, and completely describe the
project.

The requirements are mostly well described but one

or two are either missing or very weak.

The requirements are not clearly described.

25%

3.3-4 Performance and Design

constraints

These are clearly and completely described.

The description is weak or missing elements.

The description is ambiguous.

5%

3.5-6 Other requirements

These are clearly and completely described.

The description is weak or missing elements.

The description is ambiguous.

5%

Document

Document looks professional with title page,

TOC, bibliography and numbered sections. There
are no spelling or grammar errors and the prose is
clear and well organized.

Document is missing two or more attributes. At most

two or three trivial spelling or grammar errors.

Document does not look professional at all. Weak

phrasing and many spelling or grammar errors.

10%

Evaluations how you

evaluate others

Evaluations of peers is constructive and

informative with a good range of values from high
to low. Evaluation by peers shows you are a
useful member of the group.

Peer evaluations either do not have much range or are

not descriptive. Evaluations by peers shows minor
problems.

Peer evaluations are weak and uninformative.

Evaluations by peers shows some problems.

5%

Evaluations how others

evaluate you

Other members of your group cite specific valued

contributions to the project.

Your evaluations show that you are a constructive

member of the group.

One or more negative evaluations are given.

5%

Group Evaluations
1. Introduction

2. Overall Description
5%

3. Specific Requirements

Group Total
Individual Evaluations

Individual Total
Total