I need vision Document for project that is about game Clue-Less, I already did the project plan and just need Vision Document for that (create a vision document template including cover page with team information), on bottom I explain about my project plan and the game, can anyone make me good vision document for this project, the vision Document need to have the following:

Documents the vision of the product from the stakeholder viewpoint.

Documents the problem.

Identifies stakeholder groups and their needs.

You can modify the template used in the lecture and remove any items that arent really applicable to this project.

Clue-Less

Just like the real game but less!

This game is a simplified version of the popular board game, Clue. The main simplification is in the navigation of the game board. In Clue-Less there are the same nine rooms, six weapons, and six people as in the board game. The rules are pretty much the same except for moving from room to room.

The rooms are laid out in a 3x3 grid with a hallway separating each pair of adjacent rooms. (See fig. 1.)

Each hallway only holds one person. If someone is currently in a hallway, you may not move there.

When it is your turn, you dont need to roll a die.

Your options of moving are limited to the following:

o If you are in a room, you may do one of the following:

Move through one of the doors to the hallway (if it is not blocked).

Take a secret passage to a diagonally opposite room (if there is one) and make a suggestion.

If you were moved to the room by another player making a suggestion, you may, if you wish, stay in that room and make a suggestion. Otherwise you may move through a doorway or take a secret passage as described above.

o If you are in a hallway, you must do the following:

Move to one of the two rooms accessible from that hallway and make a suggestion.

If all of the exits are blocked (i.e., there are people in all of the hallways) and you are not in one of the corner rooms (with a secret passage), and you werent moved to the room by another player making a suggestion, you lose your turn (except for maybe making an accusation).

Your first move must be to the hallway that is adjacent to your home square. The inactive characters stay in their home squares until they are moved to a room by someone making a suggestion.

Whenever a suggestion is made, the room must be the room the one making the suggestion is currently in. The suspect in the suggestion is moved to the room in the suggestion.

You may make an accusation at any time during your turn.

You dont need to show weapons on the board, since they really dont do anything (but this would be a nice feature). But you should show where each of the characters is.

Requirements for your computerized version of Clue-Less:

Each player should access the game from a separate computer, with a graphical user interface.

The game rules are the same as in regular Clue except for the navigation (which is described above).

Each time the game state changes (a person is moved, a suggestion is made, a player disproves a suggestion, or a player is unable to disprove a suggestion) all players should be notified.

You should document the message interface to the Clue-Less server in your software requirements specification document.

Consider using a text based client for the minimal system, and a GUI version in the target.

Feel free to change any of the names of people, rooms or weapons, as well as graphics.

In fact, it would be a nice feature for a player to be able to load this set of names and graphics at the beginning of a game. This set of names and graphics should be stored in the client. Messages to and from the server should use standard identifiers of people, weapons and rooms, and the mapping from the standard names to the user selected names should be done in the client.

Here are the original rules of the (Classic Edition) game. In later versions of the product, some of the rules may have changed and some features may have been added.

http://www.hasbro.com/common/instruct/clueins.pdf

We recommend that you obtain the actual Clue Classic Edition game and play it a few times to see how the game is played.

The Project Plan

Features

Skeletal

1. System Architecture

A high-level system diagram of the various architectures components will be developed and

presented to the team. An initial software stack of applicable technologies is chosen. The stack

will be chosen to fulfil the requirements laid out by the architecture.

2. Subsystems Defined (SRS Documents)

All subsystems identified by the system architecture design diagrams should be clearly

identified with detailed requirements. Software Requirements Specification documents must be

written for each subsystem with clearly defined architecture and subsystem communication.

3. Skeletal System Implementation

The main purpose of the skeletal software implementation is to validate the system architecture

designs and initial technology choices. All team members should have local development

environments configured with the ability to contribute to a common software baseline. A basic

configuration management strategy will be defined to ease the development process and

prepare for minimal system implementation. There will be little to no user interface.

Minimal

1. Improve System Design

Upon completing the skeletal system implementation, feedback will be provided to the Chief

Architect. Any system architecture designs will be updated and improved based upon this

feedback. The Software Requirements Specification will also be updated to flesh out detailed

requirements for the Target system.

2. Basic Functionality from subsystems

All subsystems should support basic functionality as defined in the Software Requirements

Specification. Inter-system communication works as defined in the System Architecture. A

subset of core functionality is complete in order to support the User Interface.

3. Basic User Interface

The basic user interface will be primarily text-based. Users should be able to start a game with

other users. Any actions performed by other users should be shown to each user in a log

format. Some elements of the user interface will be non-functional or not entirely supported. A

more detailed graphical user interface design sketch will be prepared.

Target

1. Functional Web-based and Graphical User Interface

The User Interface closely resembles the design sketch prepared during the Minimal system

implementation. Players should see a visualized game board and pieces. Textual components

are replaced with graphical components that have been styled per design sketches. Some

elements of the user interface may not be entirely functional.

2. Implementation of subset of Clue-Less ruleset

Most navigation rules should be implemented to support the user interfaces game board.

Interaction between users is real-time and for the most part smooth and continuous.

Dream

1. Complete Implementation of Clue-Less ruleset

All navigation rules for Clue-Less are fully supported. Players can play the game in its entirety.

Games can be saved and resumed later once all players are present. User information is

remembered, so that users can track their scores and past games.

2. Web-based User Interface that matches design

The User Interface should exactly match design sketches. All components of the user interface

are fully functional with no unsupported operations. Users with disabilities should also be able to

successfully navigate and use the user interface.

3. Cross-Platform Native Applications

Clue-Less users can play games not only via web browsers but through native applications for

iOS, Android, and Windows. Players join games and play against others regardless of

application type (platform or web), so a user on an Android tablet can play against a user on the

web.

Risk Assessment Plan

Our risk assessment plan will revolve around 1) identifying the most probable sources of

risk, 2) determining the impact of and prioritizing those risks, and 3) creating strategies to

reduce the probability and/or impact of those risks. Since this project has a fixed timeline of

deliverables, risks that affect the delivery date of each milestone must be prioritized.

We anticipate that the largest risk to the project will be setting up the initial framework

and code base of the Clue application. A framework that is difficult to learn/use will inevitably

delay our timeline, and switching frameworks in the middle of the project would be a severe

setback. To mitigate this risk, we will carefully research multiple different application

frameworks and decide as a group which one is the most appropriate for the project.

Another probable risk is a lack of communication between group members after tasks

are assigned. This is inherent in the structure of online courses, which dont require that

developers be colocated. A severe consequence of this setup is that bugs and obstacles that

occur might not be detected and communicated in time before a deadline. Another is that code

written by multiple different developers wont fit together correctly. We will establish a system of

frequent checkpoints in order to communicate what has been coded so that each team member

knows how to use anothers code.

An omnipresent risk is that not all team members will be using the same operating

system while coding the application. This may complicate environmental variables and other

system requirements between different pieces of code. A moderate consequence is that some

time may be wasted trying to adapt code from one operating system to work correctly on

another. One solution is that as code is written in a given environment, we will document the

necessary changes needed to run that code if it is moved to another environment. Doing such

will generate a list of best practices for code that is frequently moved between operating

systems.

The risks that require tracking are communication and framework usability. It is

important to keep track of any difficulties or quirks of our coding environment. This will allow the

team to maintain best practices and increase our collective knowledge of the code base. We

anticipate that building the Clue application will have some challenges, as the teams coding

knowledge is not equally distributed between all members. Thus, frequent communication

between team members is a must in order to reduce the risk of missing a deadline.

Quality Plan

Quality Assurance

o Quality Assurance Engineer will work closely will the developers.

o Responsible for picking testing framework and final testing. Mocha, Jasmine are few

examples for Node.js test frameworks.

o Responsible working with the customers to make sure all the functionalities are delivered.

o Acceptance testing will be performed before the release for the product. The responsibility of

acceptance testing will be handled by the Architect.

Testing

o The Architect & developer will write the unit tests before programming (Test Driven

Development).

o Developers will ensure functional testing before passing off to Quality Assurance.

o Lead Software Quality Assurance Engineer will be responsible for functional and

nonfunctional testing.

o Acceptance testing will be performed before the release for the product.

Configuration Management

o Version Control include using tools such as Git and Github remotely to make and keep track

of any changes.

o The developers who are mainly involved in the programming will be merging any branches

before the release of a new build.

o The Architect will work with System Engineer to ensure successful deployment of software to

a production environment.

Schematic diagram of the board in Clue-Less. Miss Scarlet Lounge Prof Plum Billiard Library l...,,,,,,,,,, Dining Room. Room Mrs. Peacock Ball Conserv room. Mr Mrs White Green. Col Mustard Schematic diagram of the board in Clue-Less. Miss Scarlet Lounge Prof Plum Billiard Library l...,,,,,,,,,, Dining Room. Room Mrs. Peacock Ball Conserv room. Mr Mrs White Green. Col Mustard