Vision Document

Introduction

Overview (An overview of the system including the problems it attempts to solve.)

Purpose (The purpose of the system including rationale for certain major design decisions.)

Block diagram of system: (Illustrate basic components of the system and depict external interfaces to the environment.)

Design Constraints and Considerations

Assumptions / dependencies:

i.      (Example: All communications will occur over a local area network.)

ii.      (Example: All thick client machines will be using Windows XP.)

iii.      (Example: There will be a dependency on existing back-end servers being capable of scaling up to nearly twice as many transactions per minute.)

Design Drivers

i.      (Example: The customer’s expectation of a reliable system will require the use of commercial-off-the-shelf components that will be delivered as part of the system.)

ii.      (Example: The customer’s expectation of a low price will require use of our existing development tools to develop and support the system.  This will constrain the types of technologies we can consider.)

iii.      (Example: The customer’s expectation of accessing the system using only a web-browser for certain user roles will limit the types of client-side technology that can be used to support those user roles.)

System Usage

Describe the domain served by the system. (Describe the system attributes that will serve this domain.)

Describe the future users of the system. (Provide a descriptive profile of each category of expected system user.)

Describe the target environment for the system. (Describe the anticipated usage patterns as well as the software and hardware platforms in use.)

Important use cases:

i.      (Ex: User opens a browser and logons in a certain user role determined by their account profile.)

ii.      (Ex: User runs a report that requires data from legacy database servers as well as data from this system.)

System Requirements and Supporting Features

Desired system features table: (Briefly describe user-desired features that are currently planned for the system.)

Feature

Rationale

Ex: Thin Client Browser Access

User is familiar with web browser interface and wants to utilize that interface where possible.

Ex: Open Database Access

User is already heavily invested in a certain DBMS technology that supports ODBC and wants the system under development to communicate with that existing infrastructure. Using an industry-standard open database API allows working with pre-existing, heterogeneous database servers.

Ex: Utilization of Reliable COTS Middleware

The user wants a reliable system that uses industry-accepted technology. Using a proven COTS product to provide certain system functions increases the reliability of the final system.

User Requirements / system features table: (Describe the features of the system under development and how those features will fulfill the expressed requirements of the customer organization.)

User Requirement

Supporting Feature(s)

Ex: Ease of use - User shall train within two weeks

The thin client approach allows users to use a standard browser interface to access system functions.

Ex: System shall use existing infastructure

Using an open database access API (such as ODBC) allows for interaction with existing database servers.

Ex: System shall be reliable supporting an MTBF of ### hours.

Using a proven, COTS middleware component should increase overall system reliability.

Note: The user requirement column will contain

the free-form (or prose form) of the customer organization’s requirements. These are the user requirements that will be analyzed in order to derive the system requirements.