COP 4331C, Fall, 2014

• Software to be Produced
• Reference Documents
• Applicable Standards

• Assumptions
• Stakeholders
• Event Table
• Use Case Diagram
• Use Case Descriptions

• Functional Requirements
• Interface Requirements
• Physical Environment Requirements
• Users and Human Factors Requirements
• Documentation Requirements
• Data Requirements
• Resource Requirements
• Security Requirements
• Quality Assurance Requirements

• Concept of Operations
• Project Management Plan

Applicable Standards:

Definitions of Acronyms:

• NPC = non-playable character
• D-Pad = Directional pad used for player movement.

---

SECTION 2: Product Overview

Assumptions:

• The game will work with the touch screen sensor on the Android device. It is assumed the player movement will be controlled by an on screen D-Pad.

Stakeholders:

• Customer: user of final product
  
• Developer: creators of final product
  
• Professor: grade final product

Event Table:

Event Name	External Stimuli	External Responses	Internal data and state
Phone Alert	Outside Call	NA	Game play must be paused and saved.
User Input	Touch screen	NA	The game must be responsive to player input.

 

Use Case Diagram:



Use Case Descriptions:

• Game mode selection - User chooses which type of game to play.
• Continue current game - User continues game from last time the game was saved.
• Start a new game - User begins a new game from the start of the game.
• Character selection - User chooses which character to play as in the game.
• Character customization - User can change certain aspects of their current character.
• Start game - Game starts the level and the user can begin to play the game.
• Pause game - Game freezes gameplay until the user resumes to play.
• Restart level - Current game level is reset and user starts again from beginning of that level.
• Inventory - User can view and equip the gear and weapons of their character.
• Character leveling - User gains experience and levels up once enough experience is acquired.

---

SECTION 3: Specific Requirements

No: 1

Statement: The game shall have character leveling

Source: Client

Dependency: None

Conflicts: None

Supporting Materials: TBT

Evaluation Method: If the player character is able to progress from one character level to another, than this requirement is met.

Revision History:

No: 2

Statement: The game shall have a player inventory

Source: Client

Dependency: None

Conflicts: None

Supporting Materials: TBT

Evaluation Method: If the player character can access a screen from which they can select the gear and weapons they have acquired, than this requirement is met.

Revision History:

No: 3

Statement: The game shall have an NPC merchant

Source: Client

Dependency: Inventory

Conflicts: None

Supporting Materials: TBT

Evaluation Method: If the player character is able to find an NPC merchant in the game levels and purchase gear and weapons from that merchant, than this requirement is met.

Revision History:

No: 4

Statement: The game shall have character selection

Source: Client

Dependency: Diferent character objects

Conflicts: None

Supporting Materials: TBT

Evaluation Method: If the player character is able to select which character they want to play as, than this requirement is met.

Revision History:

No: 5

Statement: The game shall have game levels

Source: Client

Dependency: None

Conflicts: None

Supporting Materials: TBT

Evaluation Method: If the player character is able to progress through multiple different game levels, than this requirement is met.

Revision History:

No: 6

Statement: The game shall have a score system

Source: Client

Dependency: None

Conflicts: Game saving

Supporting Materials: TBT

Evaluation Method: If the player character is able to accumulate a score by defeating enemies or completing other tasks, than this requirement is met.

Revision History:

 

3.1 Functional Requirements:

• < Describe the fundamental actions that the software must perform. Functional requirements can be partitioned into subfunctions or subprocesses. Note: the software design partition does not have to correspond with the functional requirements partition. Functional requirements include:
• validity checks on the inputs,
• exact sequence of operations,
• responses to abnormal situations, including: overflow, communication facilities, and error handling and recovery
• effect of parameters
• relationship of outputs to inputs, including: input/output sequences, formulas for input to output conversion

3.2 Interface Requirements:

• The system will interact with the user by taking in the user’s commands via touchscreen. Feedback from the user’s commands will be instant (< 1 second).

3.3Physical Environment Requirements:

• The game will run on an Android device. Since this is a mobile platform, its environment will always change.
• Android Device
• location of the equipment could be anywhere
• environmental considerations: NA

3.4 Users and Human Factors Requirements:

• The user could be anyone who downloads the App through the Android marketplace.
• The game should support anyone with a current Android device
• Users need no special skills to use system. In game tutorial should be all the training needed
• No user should need special accommodations.
• The game does not need to protect against misuse.

3.5 Documentation Requirements:

• The game will have a small tutorial to explain the key features.
• The user is assumed to be experienced in the art of video gaming.

3.6 Data Requirements:

• The game will use basic calculations to determine hit points.
• Some weapons will have additional damage elements that will need to be calculated along with basic hit point calculations.

3.7 Resource Requirements:

• The system will be built using Unity and Android development tools. It will be a software system and not need of its own physical space or power; only what is provided by the Android device.
• The system will be built and maintained throught the course of the semester
• The sceadule is will be maintained online, within the team website, webcourses and our facebook page.
• There is no funding availible to our group at this time.
• The current hardware and sofware tools include our personal computers, Unity, Git, and Android Studio.

3.8 Security Requirements:

• The system will not need any special security functions.

3.9 Quality Assurance Requirements:

• Describe quality attributes:
• The terminal goal of our test activity is to deliver a finished product polished to the point in which any remaining bugs (if any) do not obstruct the end-user’s ability to enjoy the finished product from beginning to end. This will be achieved through careful dissection of the product into distinct parts on which we will run rigorous and repeated test exercises to ensure that any faults commonly experienced can be identified and corrected.

SECTION 4: Supporting Material

---

Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000

This page last modified by Adam Stack (bigstack80@knights.ucf.edu ) on 09/18/2014