The Vision Document Group members: Zainab BSEF07M025 Noreen BSEF08M021 Sana BSEF08M0 Yousra BSEF08M0 Nadia BSEF08M0

What is a Vision Document..? The Vision document describes the application in general terms, including descriptions of the target market, the system users, and the application features. It defines both the problem and the solution at a high level.

Why to make a Vision Document? Vision document, even if short or perhaps incomplete, helps assure that everyone working on the project is working toward a single objective. The team has common goals and a common playbook. Otherwise, the team will work toward unknown or conflicting objectives, and chaos will likely result.

Components of Vision Document A Vision Document captures: Needs of the user Features of the system Other common requirements of the project Scope of the vision document extends over the top two levels of the requirements pyramid. Needs Features Scope of vision document

For a software product, the Vision document also serves as the basis for discussion and agreement among the three primary internal stakeholder communities of the project: The marketing and product management team. The project team developing the application. The management team.

Importance of Vision Document The Vision document is uniquely important because it captures the essence of the product from all significant perspectives in a short, abstract, readable, and manageable form. As such, the Vision document is the primary focus in the early phases of the project, and any investment made in the process of gathering Vision document information will pay handsome returns in later phases.

Template for a Software Product Vision Document

1. Introduction Provide an overview of the entire Vision document. 1.1 Purpose of the Vision Document State the purpose of the Vision document: to collect, analyze and define high-level user needs and features of the product. 1.2 Product Overview State the purpose of its application, its version, and new features for delivery. 1.3 References Provide a complete list of all documents referenced elsewhere in the Vision document. 2. User Description Briefly describe the perspective of the users of your system.

2.1 User/Market Demographics Summarize the key market demographics that motivate your product decisions. 2.2 User Profiles Briefly describe the prospective users of your system. 2.3 User Environment Describe the working environment, including elements such as applications and platforms in use, and specific usage models. 2.4 Key User Needs List the key problems or needs as perceived by the user. 2.5 Alternatives and Competition Identify any alternatives the user perceives as available.

3. Product Overview 3.1 Product Perspective Provide a block diagram of the product or system and its interfaces to the external environment.

3.2 Product Position Statement Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace. Moore [1991] recommends the following format. For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category) That (statement of key benefit, i.e compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation) 3.3 Summary of Capabilities Summarize the major benefits and features the product will provide. Customer Benefit Supporting Features Benefit 1 Feature Benefit 2 Feature Benefit 3 Feature

3. 4 Assumptions and Dependencies 3 3.4 Assumptions and Dependencies 3.5 Cost and Pricing Describe any elements of continuing product cost as well as anticipated product price points. 4. Feature Attributes Describe the feature attributes that will be used to evaluate, track, prioritize, and manage the features. The following are some suggestions. Status Proposed, Approved, Incorporated Priority Cumulative vote results; order ranking; or Critical, Important, Useful Effort Low, Medium, High; team-weeks; or person months Risk Low, Medium, High Stability Low, Medium, High Target release Version number Assigned to Name Reason Text field

5. Product Features This section of the document lists the product features. 5.1 Feature 1 5.2 Feature 2 6. Exemplary Use Cases Describe a few key use cases, perhaps those that are architecturally significant or those that will most readily help the reader understand how the system is intended to be used. 7. Other Product Requirements 7.1 Applicable Standards List all standards with which the product must comply. 7.2 System Requirements Define any system requirements necessary to support the application, such as operation systems, network performance, and the like.

7.3 Licensing, Security, and Installation Describe any licensing, security, or installation requirements that also affect the development effort or that create the need for separate installation software. 7.4 Performance Requirements Use this section to detail performance requirements. 8. Documentation Requirements Describe the documentation that must be developed to support successful application deployment.

8.1 User Manual Describe the purpose and contents of the product user manual. 8.2 Online Help List requirements for online help, tool tips, and so on 8.3 Installation Guides, Configuration, and Read Me Files 8.4 Labeling and Packaging 9. Glossary

Summary The vision document is a concise description of everything you consider most important about the product or application. Write the vision document in plain language and at a level of detail that makes it easy for the primary stakeholders for the project to review and understand the document.

The Delta Vision Document

What is the delta vision document?

The Delta Vision document focuses primarily on what is NEW and what is DIFFERENT about this release.

Delta Vision Document For subsequent releases of a product, the Vision document focuses only on two things: What has changed Other information that must be included for context

The development and management of the vision document can play a key role in the success and failure of a software project.

Vision Document Provide activities for: Customers. Users. Product managers. Team members. Marketing staff. --- even the “Executive Management” involved in documents development.

So, Keep the vision document as: - Keeping the vision document understandable and manageable is an important team skill. So, Keep the vision document as: Short Concise To the point as possible

This is not particularly difficult in the first release of the document. Every item in the outline will be new to the project.

In Future Release… It is counterproductive to repeat features that have been combined in the previous releases and other information that has not changed in this particular project context as: Markets served User profile Existing features There fore Delta Vision Document is introduced to addresses these issues.

The Vision Document for Version 1.0 Version 1.0 is a comprehensive starting point.

In case of : new document: every element of the vision document must be developed and elaborated. Otherwise, simply remove that element from the template we presented… and don’t write about it.

Vision document must include: General and introductory information. Description of the user of the system Features intended for release in version 1.0 Regularity and environmental. Future features that have been elicited but will not be incorporated in the 1.0 release. Genintroeral Users and market Features of 1.0ther requirements Future releases

Advantage: This document serves as the foundation for the 1.0 release and drives the more detailed software requirements and use cases that will more fully elaborate the system.

Delta Vision 2.0

Features become fully elaborated, new features will be discovered and added to the document. If the features in v 1.0 does not deliver the intended values, you can remove the features in next release.

Delta vision document focuses on the following things: What has changed. Only other information that must be included for context.

v.1 defines the comprehensive starting point. v.2 defines the different in this release. v.1 and v.2 constitutes whole product definition.

Application of delta vision document: It will help you to manage requirement process better by allowing your team to focus on what really matters

Delta Vision Document in a Legacy System

Legacy Software Rarely, if ever, is it practical to document the complete requirements of a large-scale legacy system???

Things to decide first applying requirements management skills to the evolution of legacy IS/IT systems. are there complete and adequate requirements specifications is it practical to stop and re-document the past

Importance avoid wastage of time in performing "requirements archaeology" Performing above tasks will help to start code at appropriate time

Starting from scratch Some of the suggestions: you must proceed on a best-efforts basis using resources found around you to come to an understanding of what the system apply the Delta Vision process to define your features around the changes you are going to make to the legacy system.

following this process, you and your team can focus on what's new and what's different in this next release your customer and your team will gain the benefits of a well-managed requirements process. the requirements record create d will provide a documentation trail for others to follow behind you.

Conclusion No effective software development team should ever “Leave Home Without It”

Questions?