Team Skill 3: Defining the System The Vision Document (16) 1

Vision Document The vision document ▫Combination of some marketing and product requirements Use of the Vision document is usually required ▫Scope or business blueprint Can define vision for an organization or software product 2

Vision Document Major Challenge ▫Is to keep everything understandable by all major stakeholders  Business and Technical ▫Write at a low level of detail 3

Vision Document Is a synopsis of the problem to be addressed Includes the solution proposed Captures what the system ▫Will do ▫Won’t do 4

Vision Document The Vision describes: ▫The users of the system;  Demographics  Profile  Environment ▫Alternative solutions and competition ▫The product,  Benefits  Competition  Capabilities  Dependencies  Cost ▫Key features ▫Key use cases ▫Non-functional requirements 5

6 Vision Document High level senior management level review Highly concise ▫Should not attempt to describe detail ▫Summarize some of the UCs ▫Summarize the SS ▫Should outline key benefits and issues Try and show these in graphical format ▫Graphs ▫Charts ▫Bulleted lists

Vision Document Product Concepts can changes during the latter stages of the SDLC How will we document these changes in understanding of our problems and solutions? 7

Delta Vision Document Create a Delta Vision Document ▫The basic product information can be reused  So there is no duplication of information ▫Focus on changes to the product and solution 8

Delta Vision Document Delta Vision Documents work very well with different releases ▫ You can describe  New features in version being released  Removed features from the previous version  Planned future features ▫Gives you a high level description of how the system is changing 9

Delta Vision for Legacy Systems What do you do if you want to create a vision document for a legacy system? ▫Problem:  Don’t want to have to create an vision document for the entire system  This could be extremely time consuming ▫Solution  Use a delta vision document  Capture the changes you are/want to make to the system  Avoids documenting the entire system such as elements that are not changing 10