Software Requirements Specification Template



DGM: Digitial Game Master

Software Requirements Specification

4.0

4/22/16

James William Hicks III

Prepared for

Marymount University, School of Business

IT210, Software Engineering

Revision History

|Date |Description |Author |Comments |

|2/5 |Version 1 |Hicks |First Revision |

|2/26 |Version 2 |Hicks |Added Use Caes |

|3/20 |Version 3 |Hicks |Added Diagrams |

|4/22 |Version 4 |Hicks |Prepared for Submission |

Document Approval

The following Software Requirements Specification has been accepted and approved by the following:

|Signature |Printed Name |Title |Date |

|James William Hicks III |James Hicks |Student |2/5/2016 |

|James William Hicks III |James Hicks |Student |2/26/2016 |

|James William Hicks III |James Hicks |Student |3/20/2016 |

Honor Code

I pledge that this document is my original work, and has not been copied from another source.

-James William Hicks III

Table of Contents

Revision History ii

Document Approval ii

Honor Code ii

1. Introduction 1

1.1 Purpose 1

1.2 Scope 1

1.3 Definitions, Acronyms, and Abbreviations 1

1.4 References 2

1.5 Overview 2

2. General Description 2

2.1 Product Perspective 2

2.2 Product Functions 2

2.3 User Characteristics 2

2.4 General Constraints 3

2.5 Assumptions and Dependencies 3

3. Specific Requirements 3

3.1 External Interface Requirements 3

3.1.1 User Interfaces 3

3.1.2 Hardware Interfaces 3

3.1.3 Software Interfaces 3

3.1.4 Communications Interfaces 4

3.2 Functional Requirements 4

3.2.1 Campaign Notes 4

3.2.2 Enter Player Character Data 5

3.2.3 Create Encounter 5

3.2.4 Create Initiative Order 6

3.2.5 Log In 7

3.2.6 Create Campaign 7

3.3 Use Cases 8

3.3.1 Campaign Notes 8

3.3.2 Enter Player Character Data 9

3.3.3 Create Encounter 9

3.3.4 Create Initiative Order 10

3.3.5 Log In 10

3.3.6 Create Campaign 11

3.4 Classes / Objects 11

3.4.1 11

3.4.2 11

3.5 Non-Functional Requirements 11

3.5.1 Performance 12

3.5.2 Reliability 12

3.5.3 Availability 12

3.5.4 Security 12

3.5.5 Maintainability 12

3.5.6 Portability 12

3.6 Inverse Requirements 12

3.7 Design Constraints 12

3.8 Logical Database Requirements 12

3.9 Other Requirements 12

4. Analysis Models 12

4.1 Sequence Diagrams 12

4.3 Data Flow Diagrams (DFD) 12

4.2 State-Transition Diagrams (STD) 12

5. Change Management Process 12

A. Appendices 13

A.1 Appendix 1 13

A.1.1 DFD Top Process 13

A.1.2 DFD Level 0 14

A.1.3 DFD Level 1 Select Campaign 14

A.1.4 DFD Level 2 List of Campaigns 15

A.2 Appendix 2 15

A.2.1 Static Structure 15

A.2.2 State Chart 16

A.2.3 Sequence Diagram 16

A.2.4 Deployment Diagram 17

1. Introduction

1.1 Purpose

The purpose of “Digital Game Master” or DGM is to simplify the experience of running a Tabletop Roleplaying Game for Game Masters (or GMs). By collating player character data, non-player character data, campaign notes, and other resources into one cloud-hosted platform that is web accessible, DGM will allow GMs to be better organized and will eliminate stress from the process of running a Tabletop Roleplaying Game.

1.2 Scope

DGM is a web application to allow GMs to store campaign notes in a central place in order to make the act of running a Tabletop RPG easier. DGM is designed to be game-neutral, allowing campaigns of all sorts to be run using it, regardless of the game system being used. Due to copyright concerns, most campaign information will have to be manually input into DGM by the end-user, although later releases may include data from the Open Source D20 System Resource Document preloaded in order to aid in the running of Dungeons & Dragons version 3.5 and other D20-compatible Tabletop RPGs.

1.3 Definitions, Acronyms, and Abbreviations

• Campaign -A series of inter-related Tabletop RPG sessions sharing the same storyline.

• Campaign Notes -Story Notes, Planned Encounters, and other information written down by GM in order to help him/her keep track of where the players are in a campaign and how the GM plans to develop the story further

• Character Sheet-A print form where a player in a Tabletop RPG keeps track of their character’s information, including backstory and combat skills

• DGM -Digital Game Master

• Encounter -Combat or other adversarial events in a Tabletop RPG campaign

• GM -Game Master, the person who controls the world the players of a Tabletop RPG play in

• HTTPS -A secure version of Hypertext Transfer Protocol.

• Initiative -The order each character takes in battle. Usually determined by adding the character’s agility stat to the result of a 20 sided die.

• LAMP -Linux-Apache-MySQL-PHP, a common web server configuration

• NPC -Non Player Character, a character in a Tabletop RPG other than one controlled by a player. Includes adversaries for the players to fight in game.

• PII -Personally Identifiable Information

• SQL -Structured Query Language

• SRD -System Reference Document. An open source document put out by Wizards of the Coast describing the core mechanics of their flagship Tabletop Rolepalying Game Dungeons & Dragons allowing others to create content or other games based on it.

• SSL -Secure Socket Layer

• Tabletop Roleplaying Game (Tabletop RPG) - form on interactive storytelling where a Game Master creates a fictional world for players to interact with

• WYSIWYG - “What you see is what you get” a way to create documents without relying on markup language such as HTML

1.4 References

Wizards of the Coast System Reference Document

1.5 Overview

This SRS describes Digital Game Master, a tool for GMs to better organize their campaign notes for Tabletop RPG campaigns. Section 2 provides a general description of the Application, including general factors that affect DGM and its requirements. Section 3 includes specific information on the requirements for DGM.

2. General Description

This section of the SRS should describe the general factors that affect 'the product and its requirements. It should be made clear that this section does not state specific requirements; it only makes those requirements easier to understand.

2.1 Product Perspective

Other products currently providing a similar function include which is a platform for conducting Tabletop RPGs entirely online, and includes advanced functions such as dice rolling and playing background music for the players. However, these products are focused on playing these games over the internet, while DGM is focused playing the game on person while also simplifying the GM’s experience.

2.2 Product Functions

The functions DGM will perform will include keeping track of Player Data and NPC data, as well as keeping GM notes in a centralized location. These functions will simplify the experience of the GM, keeping this information online instead of in paper notebooks that are easily damaged or lost.

2.3 User Characteristics

The primary user of DGM will be the GM of a Tabletop RPG. He/She will be technically savy, most likely already being familiar with the use of web applications such as Google Docs, but will also have a creative streak similar to that of a Fiction writer.

2.4 General Constraints

The main constraints on development will be cost and time. Although Geek Culture has become more socially acceptable, Tabletop RPGs are still a niche product, and tools to aid in the running of a Tabletop RPG are an even more niche product. Because of the probability of a low profit margin, resources committed to developing and maintaining this application will most likely be limited.

2.5 Assumptions and Dependencies

Currently this SRS is written to be platform-independent, with the general design of the application not reliant on a specific architecture. As the project evolves and an architecture is chosen, this SRS may change in order to take best advantage of the platform’s capabilities. For example, if Microsoft Azure is chosen as the cloud provider, generalized requirements and descriptions may be replaced with Microsoft-specific ones in order to better leverage the tools of the platform.

3. Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

The Primary way the user will interact with the application will be a web form displayed by the application. In the main body of the page will be a field with the campaign notes for the campaign the user is running. Much of the content here will be generated by other functions of the application, but will be editable by the user. Off to the side will be various buttons for the functions handled by the application. The “Player Character Data” button will bring up a web form for the user to enter the data from each player’s Character Sheet into the application. The web form will also display each Player’s data so the user can insure the player isn’t cheating. “Create Encounter” will bring up a web from that will allow the user to enter NPC data for a specific encounter, along with a field to name the encounter. “Create Initiative Order” will automatically determine turn order for an encounter based on both Player Character Data and NPC data and will insert a table with the order into the Campagin Notes field.

3.1.2 Hardware Interfaces

The application will be required to be hosted on a machine with a reliable network connection and should have no less than 2 GB of RAM dedicated to it. For these reasons, it is recommended that DGM be hosted on a cloud provide such as Amazon Web Services or Microsoft Azure.

3.1.3 Software Interfaces

DGM will have to save data in an external database, such as MySQL or SQL Server, and then serve data to the user from these databases using server-side code written in a language such as PHP or in a framework such as . Because of this, in order to decrease development costs, it is recommended that DGM be built on top of an existing Content Management System such as Drupal or SharePoint. If the former, DGM will need to be hosted on a LAMP (Linux-Apache-MySQL-PHP) platform with Drupal installed. If the latter, DGM will need to be hosted on a Windows Server 2008 R2 or later server with IIS and SQL Server installed.

3.1.4 Communications Interfaces

The Application will be network accessible via HTTPS on port 443 through an SSL connection. This will ensure that user information is transmitted from the server to the user’s machine securely, minimizing the chance for the release of user PII.

3.2 Functional Requirements

3.2.1 Campaign Notes

This feature allows the GM to keep his/her notes on the campaign in one easily accessible place.

|Use Case Name |Campaign Notes |

|XRef |3.3.1 Campaign Notes |

|Trigger |The user selects the campaign they wish to open from the Application Home Page |

|Precondition |The user has an active campaign saved to the Web Application OR has used the “Create Campaign” feature |

|Basic Path |The user clicks the link they wish to open OR uses the “Create Campaign” feature |

| |The Campaign is opened in the web application |

| |The notes the user has entered are displayed in a rich text field in the center of the page |

| |The user enters more notes into the rich text field |

| |The updated notes are saved to the Web Application automatically every 30 seconds |

|Alternative Paths |The user clicks the link they wish to open OR uses the “Create Campaign” feature |

| |The Campaign is opened in the web application |

| |The notes the user has entered are displayed in a rich text field in the center of the page |

| |The user uses another feature, such as “Generate Initiative”, which appends the results to the end of the |

| |current notes |

| |The updated notes are saved to the application automatically every 30 seconds |

|Post Condition |The updated campaign notes are saved and displayed in a rich text field in the center of the page |

|Exception Paths |If the user is trying to enter notes for a campaign that no longer exists, or if the user loses their network |

| |connection, an error message informing them of this will be shown using the JavaScript Alert functions. |

| |Otherwise, a general error message will be shown with an error code for developer debugging. |

|Other | |

3.2.2 Enter Player Character Data

This function will allow the user to enter the information on their players’ character sheet. By default, the fields will come from the SRD, however the user will be able to add or subtract fields from this feature in order to match the game the user’s campaign is set in.

|Use Case Name |Enter Player Character Data |

|XRef |Wizards of the Coast System Reference Document |

| |3.3.2 Enter Player Character Data |

|Trigger |The user is clicks “Enter Player Character Data” |

|Precondition |The user is within the “Campaign Notes” feature |

|Basic Path |A form with a list of fields coming from the SRD is generated, with “+” and “-“ buttons next to each item |

| |The player enters data into each field. If the field is not needed, the player clicks the “-“ button. If a field|

| |the player needs does not exist, the player clicks a “+” button |

| |The player clicks OK |

|Alternative Paths |n/a |

|Post Condition |The data is appended to the Campaign Notes |

|Exception Paths |If the user attempts to add data to a character that no longer exists, a Not Found error will be thrown . In |

| |addition, DROP TABLES will not be accepted as input. |

|Other | |

3.2.3 Create Encounter

This feature will allow the user to enter information on NPCs that players will fight in a campaign.

|Use Case Name |Create Encounter |

|XRef |Wizards of the Coast System Reference Document |

| |3.3.3 Create Encounter |

|Trigger |The user clicks “Create Encounter” |

|Precondition |The user is within the “Campaign Notes” feature |

|Basic Path |A form with a list of fields coming from the SRD is generated, with “+” and “-“ buttons next to each item |

| |The player enters data into each field. If the field is not needed, the player clicks the “-“ button. If a field|

| |the player needs does not exist, the player clicks a “+” button |

| |The player clicks OK |

|Alternative Paths |n/a |

|Post Condition |The data is appended to the Campaign Notes |

|Exception Paths |If the user attempts to add data to a encounter that no longer exists, a Not Found error will be thrown. In |

| |addition, DROP TABLES will not be accepted as input. |

|Other | |

3.2.4 Create Initiative Order

If a GM suspects his players of fudging their Initiative Rolls, the GM can use this feature to determine Initiative.

|Use Case Name |Create Initiative Order |

|XRef |3.3.4 Create Initiative Order |

|Trigger |The user clicks “Create Initiative Order” |

|Precondition |The user is within the “Campaign Notes” feature and has used the “Enter Character Data” and “Create Encounter |

| |features. |

|Basic Path |The agility stats of each player entered in “Enter Player Character Data” and each NPC entered in “Create |

| |Encounter is pulled into the feature |

| |A pseudo-randomly generated number will be added to each agility stat. |

| |The characters and NPCs are ordered highest to lowest according to the sums of step 2 |

|Alternative Paths |n/a |

|Post Condition |The list of NPCs and Characters sorted by step 3 is apprehended to the Campaign Notes |

|Exception Paths |If no player data or encounter data has been entered, a “Data not found” error will be thrown. |

| | |

| |The user may lose their internet connection during the log in process. |

|Other |If the user attempts to add data to a character that no longer exists, a Not Found error will be thrown. In |

| |addition, DROP TABLES will not be accepted as input. |

3.2.4.2 Inputs

The agility stats of each player entered in “Enter Player Character Data” and each NPC entered in “Create Encounter” will be pulled into this feature when the user clicks on “Create Initiative Order”

3.2.4.3 Processing

A pseudo-randomly generated number will be added to each agility stat. The Player Data and NPC data will then be sorted based on the sums generated.

3.2.4.4 Outputs

The Initiative will be appended to the Campaign Notes data.

3.2.4.5 Error Handling

If no player data or encounter data has been entered, a “Data not found” error will be thrown.

3.2.5 Log In

This feature will log the user into the web application.

|Use Case Name |Log In |

|XRef |3.3.5 Log In |

|Trigger |The user has successfully navigated to the site where the Web Application has hosted |

|Precondition |“User Name” and “Password” fields are displayed for the user |

|Basic Path |The user types in their user name |

| |The user types in their password |

| |Both the user name and password are authenticated against a table of user names and passwords |

|Alternative Paths |n/a |

|Post Condition |A page is displayed with a list of campaigns the user has created and a button displaying “Create New Campaign” |

|Exception Paths |The user may enter in a wrong password. Alternatively, the user may lose their internet connection during the |

| |log in process. |

|Other | |

3.2.6 Create Campaign

This feature will allow the user to create a new campaign

|Use Case Name |Create Campaign |

|XRef |3.3.6 Create Campaign |

|Trigger |The user has successfully logged into the application |

|Precondition |A list of already created campaigns (if any) is displayed alongside a “Create Campaign” button |

|Basic Path |The user clicks “Create Campaign” |

| |A form is displayed with “Campaign Name” and “System” fields |

| |The user enters the Name of the Campaign and the RPG the campaign is being run in. |

| |The user clicks “OK” |

|Alternative Paths |n/a |

|Post Condition |The Campaign Notes feature is activated |

|Exception Paths |The user uses a name for a campaign that is already in use. Alternatively, the user may lose their internet |

| |connection during the log in process. |

|Other | |

3.3 Use Cases

[pic]

Above is the Use Case Diagram for the entire Application. Below are the use cases for each individual feature.

3.3.1 Campaign Notes

[pic]

Brief Description:

1. The user clicks the link they wish to open OR uses the “Create Campaign” feature

2. The Campaign is opened in the web application

3. The notes the user has entered are displayed in a rich text field in the center of the page

4. The user enters more notes into the rich text field

5. The updated notes are saved to the Web Application automatically every 30 seconds

6. The updated campaign notes are saved and displayed in a rich text field in the center of the page

3.3.2 Enter Player Character Data

[pic]

Brief Description:

1. A form with a list of fields coming from the SRD is generated, with “+” and “-“ buttons next to each item

2. The player enters data into each field. If the field is not needed, the player clicks the “-“ button. If a field the player needs does not exist, the player clicks a “+” button

3. The player clicks OK

4. The Data is appended to the Campaign Notes

3.3.3 Create Encounter

[pic]

Brief Description:

1. A form with a list of fields coming from the SRD is generated, with “+” and “-“ buttons next to each item

2. The player enters data into each field. If the field is not needed, the player clicks the “-“ button. If a field the player needs does not exist, the player clicks a “+” button

3. The player clicks OK

4. The Data is appended to the Campaign Notes

3.3.4 Create Initiative Order

[pic]

Brief Description:

1. The agility stats of each player entered in “Enter Player Character Data” and each NPC entered in “Create Encounter is pulled into the feature

2. A pseudo-randomly generated number will be added to each agility stat.

3. The characters and NPCs are ordered highest to lowest according to the sums of step 2

4. The list of NPCs and Characters sorted by step 3 is apprehended to the Campaign Notes

3.3.5 Log In

[pic]

Brief Description:

1. The user types in their user name

2. The user types in their password

3. Both the user name and password are authenticated against a table of user names and passwords

4. A page is displayed with a list of campaigns the user has created and a button displaying “Create New Campaign”

3.3.6 Create Campaign

[pic]

Brief Description:

1. The user clicks “Create Campaign”

2. A form is displayed with “Campaign Name” and “System” fields

3. The user enters the Name of the Campaign and the RPG the campaign is being run in.

4. The user clicks “OK”

5. The “Campaign Notes” feature is activated.

3.4 Classes / Objects

3.4.1

3.4.1.1 Attributes

3.4.1.2 Functions

3.4.2

…

3.5 Non-Functional Requirements

Non-functional requirements may exist for the following attributes. Often these requirements must be achieved at a system-wide level rather than at a unit level. State the requirements in the following sections in measurable terms (e.g., 95% of transaction shall be processed in less than a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value, etc).

3.5.1 Performance

3.5.2 Reliability

3.5.3 Availability

3.5.4 Security

3.5.5 Maintainability

3.5.6 Portability

3.6 Inverse Requirements

State any *useful* inverse requirements.

3.7 Design Constraints

Specify design constrains imposed by other standards, company policies, hardware limitation, etc. that will impact this software project.

3.8 Logical Database Requirements

Will a database be used? If so, what logical requirements exist for data formats, storage capabilities, data retention, data integrity, etc?

3.9 Other Requirements

Catchall section for any additional requirements.

4. Analysis Models

List all analysis models used in developing specific requirements previously given in this SRS. Each model should include an introduction and a narrative description. Furthermore, each model should be traceable the SRS’s requirements.

4.1 Sequence Diagrams

4.3 Data Flow Diagrams (DFD)

4.2 State-Transition Diagrams (STD)

5. Change Management Process

Identify and describe the process that will be used to update the SRS, as needed, when project scope or requirements change. Who can submit changes and by what means, and how will these changes be approved.

A. Appendices

Appendices may be used to provide additional (and hopefully helpful) information. If present, the SRS should explicitly state whether the information contained within an appendix is to be considered as a part of the SRS’s overall set of requirements.

Example Appendices could include (initial) conceptual documents for the software project, marketing materials, minutes of meetings with the customer(s), etc.

A.1 Appendix 1

A.1.1 DFD Top Process

[pic]

A.1.2 DFD Level 0

[pic]

A.1.3 DFD Level 1 Select Campaign

[pic]

A.1.4 DFD Level 2 List of Campaigns

[pic]

A.2 Appendix 2

A.2.1 Static Structure

[pic]

A.2.2 State Chart

[pic]

A.2.3 Sequence Diagram

[pic]

A.2.4 Deployment Diagram

[pic]

A.2.5 Component Diagram

[pic]

A.3 Appendix 3: Software Project Test Plan

A.3.1 Purpose

This document intends to define the process and expectations for testing DGM’s system. This includes test methodologies, traceability, resources required, and estimated schedule.

A.3.2 Audience

The audience of this document is the project team and the project management team. This document is also written for the extended test team. The test lead, testers, and any outsourced testers should be able to utilize this document to understand the scope of work that must be accomplished by the test team. The document is intended to accomplish its purpose only for the intended audiences.

A.3.2 Revision History

|Revision |Date |Updated By |Update Comments |

|0.1 |03/19/2016 |James Hicks |Initial document creation |

|0.2 |03/22/2016 |James Hicks |Section 2. – 4. |

|0.3 |03/29/2016 |James Hicks |Section 5. – 8. |

|0.4 |04/01/2016 |James Hicks |Section 9. – 10. |

A.3.3 Introduction

This section describes the objectives and extent of the tests. The goal is to provide a framework that can be used by managers and testers to plan and execute the necessary tests in a timely and cost-effective manner.

A.3.4 Test Objectives

Analyze the software and identify the differences between prevailing and necessary conditions and to assess the features of the software. The testing approach will run through a phased sequence of automatic and manual tests. Developers will check the systems functional integrity manually for the user interaction component, while the components that don’t involve user interaction will be tested automatically via scripts.

A.3.5 Extent of Tests

The tests referenced herein are written to validate use cases, requirements (both functional and non-functional), system architecture, and object design. The structured tests for object design will be run first as the components of the system are developed. The structured tests to validate the system architecture will be run next as the system is integrated in bottom-up fashion during integration test.

A.3.6 Scope

The lifecycle for the development for Digital Game Master will consist of several testing phases as the product is created. This test plan describes the integration and system test that will be conducted for the DGM application.

A.4 Test Design

A.4.1 Unit Testing

This process will examine the testable parts of the application which will inspect for accurate operation. This will involve only those characteristics that are vital to the performance of the application.

1. Authenticate User (Valid Log In)

|Unit To Test |Log In |

|Assumption |The initial log in screen is displayed and waits for the user’s input |

|Input |Valid User ID and Password |

|Expected Output |The DGM Main Screen is displayed |

|Pass |DGM Main Screen is displayed w/ all user’s Campaigns (if any) |

|Fail & Probable Error |Proper Input, but unable to log in. Connection to database is lost |

2. Create Campaign

|Unit To Test |Create Campaign |

|Assumption |The User is Logged In and is at the DGM main screen |

|Input |User clicks “Create Campaign |

|Expected Output |The “Campaign Notes” feature is activated w/ a new, blank Campaign |

|Pass |Expected Output is shown |

|Fail & Probable Error |Other output is shown, Most Likely due to Connection Loss or Database Error |

3. Create Encounter

|Unit To Test |Create Encounter |

|Assumption |The User is in the “Campaign Notes” feature and is logged in |

|Input |User clicks “Create Encounter |

|Expected Output |A form with a list of fields coming from the SRD is generated, with “+” and “-“ buttons next to each |

| |item |

|Pass |Expected Output is shown |

|Fail & Probable Error |Other Output is shown, most likely due to loss of connection |

A.4.2 Integration Testing

Several related unites will fall under one integration test known as horizontal bottom-up integration. For example, a Campaign Notes test would test the integration of Create Campaign, Create an Encounter and Enter Player Character Data, Determine Initiative, and Campaign Notes. Since Create Campaign has no pre-requirement, it should be tested first.

[pic]

A.4.3 System Testing

This process will require zero understanding of the inner design of the code or logic in the system. Instead, much like black-box testing, this method will assess the systems with its identified requirements.

A.5 System Overview

This section, focusing on the structural aspects of testing, provides an overview of the system in terms of the components that are tested during the unit test. The granularity of components and their dependencies are defined in this section.

A.5.1 Test Name Scheme

The names of test cases will indicate from where they have been derived using a system of prefixes. The following prefixes are use to denote the tests were derived from the following places.

uc_ tests derived from use cases

nfrs_ tests derived from nonfunctional requirements

odd_ structured tests derived from the subsystem decomposition and component diagram

A.6 Features to be Testes/Not Tested

A.6.1 Features to be Tested

This section, focusing on the functional aspects of testing, identifies all features and combinations of features to be tested. It also describes all those features that are not to be tested and the reasons for not testing them.

• Database Interface

• Security/User Permissions

• Response Time

• User Creation

A.6.2 Items that will not be tested

• Scalability limits

• Hardware availability

A.7 Pass/Fail Criteria

This section specifies generic pass/fail criteria for the tests covered in this plan. They are supplemented by pass/fail criteria in the test design specification. Note that “fail” in the IEEE standard terminology means “successful test” in our terminology.

A.7.1 Suspension Criteria

Upon critical failure, test case execution will be suspended if that failure impedes the ability or value in performing the associated test us discovered.

A.7.2 Resumption Criteria

Once the developer suspects the issue causing the suspension has been resolved, only then will the test case execution resume. Any modified portion of the project test cases will be re-executed as well.

A.7.3 Approval Criteria

In order for each test case to be considered approved, the results will have to correlate with the established projected results reported in the test case.

A.8 Approach

This section describes the general approach to the testing process. It discusses the reasons for the selected integration testing strategy. Different strategies are often needed to test different parts of the system.

A.8.1 Component Testing

Each component will be tested over the course of the system’s development in an arranged and organized manner. It’s important to note, independent component testing on all levels will be difficult due to the dependence of the higher layers with respect to functionality in the lower layers.

A.8.2 Integration Testing

The approach for integration testing will require a comprehensive set of test cases to be implemented and executed. The development of a test matrix will ensure the coverage of all necessary requirements detailed in the SRS.

A.8.3 Systems Test

The manual tests will start by validating functionality based on the requirements. Later stages of system test will include manual end-to-end tests to validate use cases.

A.8.4 Performance Test

This test will be conducted manually. The majority of this testing will rely on contact with the user interface to observe the system and determine whether or not the system responds in a reasonable manner. To clarify the term “reasonable” in how it relates to the processing time of the system, in this context, it is what the average person would deem as reasonable in reference to the speed of a standard app’s processing time. The system's performance requirements do not demand a more rigorous methodology.

A.8.5 Test Case alignment with test phases

[pic]

A.9 Testing Process

A.9.1 Test Deliverables

A report of all tests’ will be contained within the project deliverables. This will include test cases, formal test executions and a summary of the final state of the validation suite which will show the specified behaviors of the software program.

A.9.2 Testing Tasks

• Complete test report

• Report discovered defects

• Arrange for separate database to be used for automated programmed testing

• Cultivate test cases

A.9.3 Responsibilites

The completion of all components and integration testing tasks will be the responsibility of every developer associated with the development of Digital Game Master.

The designated Project Manager will give the final approval in reference to the Test Plan & Test Cases.

A.10 Environmental Requirements

A.10.1 Hardware

Four Microsoft Windows PC computers with a broadband connection and one Microsoft Windows Server with a broadband connection to one of the PCs above.

A.10.2 Software

All PC’s will require the installation of:

1) Windows 10

2) .NET Framework 3.5

3) Visual Studio Code

4) SQL Server Express

A.10.3 Security

No specific environment required for testing.

A.11 Test Cases

This section, the core of the test plan, lists the test cases that are used during testing. Each test case is described in detail in a separate Test Case Specification document. Each execution of these tests will be documented in a Test Incident Report document.

A.11.1 Test specifications derived from nonfunctional requirements

nfrs_3.5.1 Performance_ServerAvailability

nfrs_3.5.2 Reliability_SystemFailureDetection

nfrs_3.5.2 Reliability_AutonomousTroubleShoot

nfrs_3.5.2 Reliability_AutonomousSet&Restore

nfrs_3.5.4 Security_ServerSecurityCheck

nfrs_3.5.4 Security_SystemStructuralIntegrity

nfrs_3.5.5 Maintainability_ CodeFunctions

A.11.2 Test specifications derived from the use cases in the functional requirements

uc_3.2.1_CampaignNotes

uc_3.2.2_EnterPlayerCharacterData

uc_3.2.3_CreateEncounter

uc_3.2.4_CreateInitativeOrder

uc_3.2.5_LogIn

uc_3.2.9_CreateCampaign

A.12 Testing Schedule

This section of the test plan covers responsibilities, staffing and training needs, risks and contingencies, and the test schedule.

A.12.1 Responsibilities

The Test Manager as represented above under Testing Schedule is liable for the overall design and fabrication of the test plan and test resources over the course of the project. From the specifications as outlined in the SRS, he will then generate the systems Test Plan as well as the Test Cases.

The component testers are tasked with the responsibility of executing tests in reference to their respective component of the system for which they were assigned. They will look to find defects in the components and verify the functioning of the software to ensure that each component of the application is working effectively.

The system testers will encompass an array of different test functions on the whole system which will include requirement specifications, use cases, operating system. Essentially, they will be responsible for all the functional testing and performances testing. System testers will verify that the system to be delivered meets the specification and purpose of Digital Game Master.

A.12.2 Risks & Contingencies Matrix

|Risk |Probability |Risk Type |Owner |Contingencies/Mitigation Approach |

|Availability of key personnel |30% |Personnel |Test Manager |Increase Testing Resources |

|and testing resources | |Schedule | | |

|Late or non-delivery of required|25% |Equipment |Program Manager |Re-plan to deliver in prioritized |

|hardware, software, test data or| | |Test Manager |phases |

|tools | | |Development Manager | |

|Inability to test all features |5% |Third Party |Alliance Manager |Accept the risk and set aside |

| | | | |contingencies to deal with fall out in |

| | | | |the event that risk is materialized |

|Changes to the original |25% |Schedule |Development Manager |Reduce the scope |

|requirements or designs | | | | |

|Turnover |5% |Personnel |Test Manager |Testers will work in pairs on |

| | | | |components. If a single member of the |

| | | | |team decides to leave, remaining member|

| | | | |of pair will be able to train new |

| | | | |tester or finish work. Schedule must be|

| | | | |adjusted accordingly |

A.13 Appendix D: MS Project Software

Development Plan and Excel Budget

A.13.1 Introduction

The project plan for Digital Game Master consists of 134 days. This plan defines how much time each task will take and when completion dates will be. Some tasks are reliant on others so some criteria must be met before some tasks are completed. This project plan establishes a firm timeline for the development team to space out their tasks accordingly.

A.13.2 MS Project Screenshot

The following screen shot shows the duration layout of Digital Game Master. It shows the Scope task took 3.5 days; mostly split between securing sponsorships and acquiring resources. The Analysis/Software Requirements took a bit longer at 14 days. The largest chunk of this 14-day period was used for the needs analysis. Overall, the Testing and Training take up a large chunk at almost 100 days.

[pic]

A.13.3 Excel Budget

This Budget Plan has been put together to show the monetary flow of Digital Game Master. It outlines the Total Initial Investments, Total Benefits and Total Costs. It takes in to account the incremental sales from increased promotional effectiveness. The Costs sections outlines the total maintenance costs to keep Digital Game Master running year round.

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download