Vision - Systems Engineering and Software Development Life Cycle
Contents
1. P lt Project Name gt Vision Version lt 1 0 gt Note The following template isgp se with the Rational Unified Process Text enclosed in square e i Blue is included to provide guidance to the author and should be deleted before publishing the d style Body Text Microsoft Word which display a gray background when selected select Title Subject and Company fields with the appropriate information for this File gt Propert document After iJ and pressing F9 or simply click on the field and press F9 This must be done separately for Hedders a ooters Alt F9 will toggle between displaying the field names and the field contents See Word nation on working with fields lt Project Name gt Date _ lt dd mmm yy gt ReVision document History SDLC Internal Use Only SDLC 2000 Page 2 lt Project Name gt Date _ lt dd mmm yy gt Table of Contents 1 Introduction 5 1 1 Purpose 5 1 2 Scope 5 1 3 Definitions Acronyms and Abbreviations 5 1 4 References 5 1 5 Overview 5 2 Positioning 5 2 1 Business Opportunity 5 2 2 Problem Statement 5 2 3 Product Position Statement 5 3 Stakeholder and User Descriptions 6 3 1 Market Demographics 6 3 2 Stakeholder Summary 6 3 3 User Summary 6 3 4 User environment 7 3 5 Stakeholder Profiles 7 3 5 1 lt Stakeholder Name gt 7 3 6 User Profiles 7 3 6 1 lt User Name gt 7 3 7 Key Stakeholder User Needs 8 3 8 Alternatives and Comp2. section and a discussion of compatibility issues with earlier releases Most users also appreciate documentation defining any known bugs and workarounds in the Read Me file 10 4 Labeling and Packaging Todays state of the art applications provide a consistent look and feel that begins with product packaging and manifests through installation menus splash screens help systems GUI dialogs etc This section defines the needs and types ofilabeling to be incorporated into the code Examples include copyright and patent notices corporate logos standardized icons and other graphic elements etc 11 Appendix 1 Feature Attributes Features should be given attributes that can be used to evaluate track prioritize and manage the product items proposed for implementation All requirement types and attributes should be outlined in the Requirements Management Plan however you may wish to list and briefly describes the attributes for features that have been chosen Following subsections represent a set of suggested feature attributes SDLC Internal Use Only SDLC 2000 Page 11 lt Project Name gt Vision Date lt dd mmm yy gt lt document identifier gt 11 1 Status Set after negotiation and review by the project management team Tracks progress during definition of the project baseline Proposed Used to describe features that are under discussion but have not yet been reviewed and accepted by the official channel s
3. Feature gt 6 Constraints Note any design constraints external constraints or other dependencies 7 Quality Ranges Definethe quality ranges for performance robustness fault tolerance usability and similar characteristics that are motcaptured inthe Feature Set 8 Precedence and Priority Define the priority of the different system features 9 Other Product Requirements At a high level list applicable standards hardware or platform requirements performance requirements and environmental requirements 9 1 Applicable Standards List all standards with which the product must comply These can include legal and regulatory FDA UCC communications standards TCP IP ISDN platform compliance standards Windows Unix etc and quality and SDLC Internal Use Only SDLC 2000 Page 10 lt Project Name gt Date _ lt dd mmm yy gt safety standards UL ISO CMM 9 2 System Requirements Define any system requirements necessary to support the application These can include the supported host operating systems and network platforms configurations memory peripherals and companion software 9 3 Performance Requirements Use this section to detail performance requirements Performance issues can include such items as user load factors bandwidth or communication capacity throughput accuracy and reliability or response times under a variety of loading conditions 9 4 Environmental Requiremen
4. Identify alt rnatives thesstakeholder perceives as available These can include buying a competitor s product building homegrown solution or simply maintaining the status quo List any known competitive choices that exist or may become available Include the major strengths and weaknesses of each competitor as perceived by the stakeholder 3 8 1 lt aCompetitor gt 3 8 2 lt anotherCompetitor gt 4 Product Overview This section provides a high level view of the product capabilities interfaces to other applications and systems configurations This section usually consists of three subsections as follows e Product perspective Product functions SDLC Internal Use Only SDLC 2000 Page 8 lt Project Name gt Date _ lt dd mmm yy gt Assumptions and dependencies 4 1 Product Perspective This subsection of the Vision document should put the product in perspective to other related products and the user s environment If the product is independent and totally self contained state it here If the product is a component of a larger system then this subsection should relate how these systems interact and should identify the relevant interfaces between the systems One easy way to display the major components of the larger system interconnections and external interfaces is via a block diagram 4 2 Summary of Capabilities Summarize the major benefits and features the product will provide For example a Vi
5. Name gt Date _ lt dd mmm yy gt 3 4 User Environment Detail the working environment of the target user Here are some suggestions Number of people involved in completing the task Is this changing How long is a task cycle Amount of time spent in each activity Is this changing Any unique environmental constraints mobile outdoors in flight etc Which systems platforms are in use today Future platforms What other applications are in use Does your application need to integrate with them This is where extracts from the Business Model could be included to outline the task and workers involved etc 3 5 Stakeholder Profiles Describe each stakeholder in the system here by filling in the following table for each stakeholder Remember stakeholder types can be as divergent as users strategy departments and technical developers A thorough profile should cover the following topics for each type of stakeholder 3 5 1 lt Stakeholder Name gt Representative Who is the stakeholder representativesto the project optional if documented elsewhere What we want here is names Description Brief description of the stakeholder type Type Qualify the stakeholder s expertisetechnical background and degree of sophistication thatis guru business expert casual user etc Responsibilities List the stakehold v s key responsibilities with regards to the system being developed that is their inte
6. being solved by this project The following format may be used Phe problem of describe the problem affects the stakeholders affected by the problem the impact of which is what is the impact of the problem a successful solution would be list some key benefits of a successful solution 2 3 Product Position Statement Provide an overall statement summarizing at the highest level the unique position the product intends to fill in the marketplace The following format may be used SDLC Internal Use Only SDLC 2000 Page 5 Date _ lt dd mmm yy gt statement of the need or opportunity The product name is a product category statement of key benefit that is compelling reason to buy primary competitive alternative Our product statement of primary differentiation A product position statement communicates the intent of the application and the importance of th project to all concerned personnel 3 Stakeholder and User Descriptions To effectively provide products and services that meet your stakeholders and users feal needs it is necessary to identify and involve all of the stakeholders as part of the Requirements Modeling process Yow must also identify the users of the system and ensure that the stakeholder community adequately represents them This section provides a profile of the stakeholders and users involved in the project and the key problems that they perceive to be addressed by the proposed s
7. etition 8 3 8 1 lt aCompetitor gt 8 3 8 2 lt anotherCompetitor gt 8 4 Product Overview 8 4 1 Product Perspective 9 4 2 Summary of Capabilities 9 4 3 Assumptions and Dependencies 9 44 Cost and Pricing 9 4 5 Licensing and Installation 9 5 Product Features 10 5 1 lt aFeature gt 10 5 2 lt anotherFeature gt 10 6 Constraints 10 7 Quality Ranges 10 8 Precedence and Priority 10 9 Other Product Requirements 10 9 1 Applicable Standards 10 9 2 System Requirements 11 9 3 Performance Requirements 11 SDLC Internal Use Only SDLC 2000 Page 3 lt Project Name gt Date _ lt dd mmm yy gt 9 4 Environmental Requirements 11 10 Documentation Requirements 11 10 1 User Manual 11 10 2 Online Help 11 10 3 Installation Guides Configuration Read Me File 11 10 4 Labeling and Packaging 11 11 Appendix Feature Attributes PI 11 1 Status 12 11 2 Benefit 12 11 3 Effort 12 11 4 Risk 12 11 5 Stability 12 11 6 Target Release 13 11 7 Assigned To 13 11 8 Reason 13 SDLC Internal Use Only SDLC 2000 Page 4 lt Project Name gt Date _ lt dd mmm yy gt Vision 1 Introduction The purpose of this document is to collect analyze and define high level needs and features of the lt lt System Name gt gt It focuses on the capabilities needed by the stakeholders and the target users and why these needs exist The details of how the lt lt System Name gt gt fulfils these needs are detailed in the use case a
8. example an assumption may state that a specific operating system will be available for thehardware designated for the software product If the operating system is not available the Vision dogtment will needito change 4 4 Cost and Pricing For products sold to external customers and for many in house applications cost and pricing issues can directly impact the applications definition and implementation In this section record any cost and pricing constraints that are relevant For example distribution costs of diskettes CD ROMs CD mastering or other cost of goods sold constraints manuals packaging may be material to the projects success or irrelevant depending on the nature of the application 4 5 Licensing and Installation Licensing and installation issues can also directly impact the development effort For example the need to support serializing password security or network licensing will create additional requirements of the system that must be SDLC Internal Use Only SDLC 2000 Page 9 lt Project Name gt Date _ lt dd mmm yy gt considered in the development effort Installation requirements may also affect coding or create the need for separate installation software 5 Product Features List and briefly describe the product features Features are the high level capabilities of the system that are necessary to deliver benefits to the users Each feature is an externally desired service that typica
9. ication that is guru casual user etc Responsibilities List the user s key responsibilities with regards to the system being developed that is captures details produces reports coordinates work etc Success Criteria How does the user define success How is the user rewarded Involvement How the user is involved in the project Relate where possible to RUP workers gt that is Requirements Reviewer etc Deliverables Are there any deliverables the user produces and if so for whom Comments Issues Problems that interfere with success and any other relevant information go here These would include trends that make the user s job ast r or harder 3 7 Key Stakeholder User Needs List the key problems with existing solutions as perceived by the stakeholder Clarify the following issues for each problem What are the reasons for this problem How is it solved now What solutions does the stakeholder want It is important to understand the relative importance thestakeholder or user places on solving each problem Ranking and cumulative voting techniques indicate problems that must be solved versus issues they would like addressed Fill in the following table if using ReqPro to capt re the Needs this could be an extract or report from that tool Need Priority Concerns Current Solution Proposed Solutions 3 8 Alternatives and Competition
10. lly requires a series of inputs to achieve the desired result For example a feature of a problem tracking system might b the ability to provide trending reports As the use case model takes shape update the description to refer toghe use cases Because the Vision document is reviewed by a wide variety of involved personnel the level of detail should be general enough for everyone to understand However enough detail should be available to ptovide the team with the information they need to create a use case model To effectively manage application complexity we recommend for any new system or n increment to an existing system capabilities are abstracted to a high enough level so 25 99 features result These features provide the fundamental basis for product definition scope management and project management Each feature will be expanded in greater detail in the use case model Throughout this section each feature should be externally perceivable by users operators or other external systems These features should include a description of functionality and any relevant usability issues that must be addressed The following guidelines apply Avoid design Keep feature descriptions at a general lefel kocus on capabilities needed and why not how they should be implemented e If you are using the Requisite toolkit all shouldbe selected as requirements of type for easy reference and tracking 5 1 lt aFeature gt 5 2 lt another
11. nd supplementary specifications The introduction of the Vision document should provide an overview of the entire document It should nelude the purpose scope definitions acronyms abbreviations references and overview of this Vision document 1 1 Purpose Specify the purpose of this Vision document 1 2 Scope A brief description of the scope of this Vision document what Project s it is associatedywith and anything else that is affected or influenced by this document 1 3 Definitions Acronyms and Abbreviations This subsection should provide the definitions of all terms acronyms and abbreviations required to properly interpret the Vision document This information may be provided by reference to the project Glossary 1 4 References This subsection should provide a complete list of altdocumentswr ferenced elsewhere in the Vision document Each document should be identified by title report number if applicable date and publishing organization Specify the sources from which the references cambe obtained This information may be provided by reference to an appendix or to another document 1 5 Overview This subsection should describetwhat thetrest of the Vision document contains and explain how the document is organized 2 Positioning 2 1 Business Opportunity Briefly describe the business opportunity being met by this project 2 2 Problem Statement Provide a statement summarizing the problem
12. olution It does not describe their specific requests or r quirements as these are captured in a separate stakeholder requests artifact Instead it provides the backgretind and justification for why the requirements are needed 3 1 Market Demographics Summarize the key market demographics that motivate yourptoduetdecisions Describe and position target market segments Estimate the market s size and growth by using the number of potential users or the amount of money your customers spend trying to meet needs that your product or enhancement would fulfill Review major industry trends and technologies Answer these strategic questions What is your organization s reputation in these markets What would you like it to be How does this product f service support your goals 3 2 Stakeholder Summary Present a summarydist ofall the identified stakeholders Represents Name the stakeholder type Briefly describe what they Briefly describe the role they are represent with respect to the playing in the development development i F For example Ensure this 3 3 User Summary Presenta summary list of all the identified users Description Stakeholder Name the user type Briefly describe what they List how the user is represented represent with respect to the by the stakeholders system a J For example Represented by Stakeholder 1 1 SDLC Internal Use Only SDLC 2000 Page 6 lt Project
13. rest as a stakeholder Success Criteria How doesthe stakeholder define success How is the stakeholder rewarded Involvement How the stakeholder is involved in the project Relate where possible to RUP workers thatis Requirements Reviewer etc Deliverables Are there any additional deliverables required by the stakeholder These could be Project deliverables or outputs from the system under development Comments Y Issues Problems that interfere with success and any other relevant information go here 3 6 User Profiles Describe each unique user of the system here by filling in the following table for each user type Remember user types can be as divergent as gurus and novices For example a guru might need a sophisticated flexible tool with cross platform support while a novice might need a tool that is easy to use and user friendly A thorough profile should cover the following topics for each type of user 3 6 1 lt User Name gt Representative Who is the user representative to the project optional if documented elsewhere This often refers to the Stakeholder that represents the set of users for example Stakeholder Stakeholder1 Description A brief description of the user type SDLC Internal Use Only SDLC 2000 Page 7 lt Project Name gt Date _ lt dd mmm yy gt Type Qualify the user s expertise technical background and degree of sophist
14. sion document f r a customer support system may use this part to address problem documentation routing and status reporting without mentioning the amount of detail each of these functions requires Organize the functions so the list is understandable to the customer or to anyone elsefreading the document for the first time A simple table listing the key benefits and their supporting features might suffice For example Customer Support System Customer Benefit Supporting Features New support staff can quickly get up Knowledge basesassists support personnel to speed in quickly identifying known fixes and workarounds Customer satisfaction is improved Problemsiare uniquely itemized classified because nothing falls through the and tracked throughout the resolution cracks process Automatic notification occurs for ing issues areas and gauge staff workload level review of problem status Distributed support teams can work Replication server allows current database together to solve problems information to be shared across the enterprise Customers can help themselves Knowledge base can be made available lowering support costs and improving over the Internet Includes hypertext response time search capabilities and graphical query engine 4 3 Assumptions and Dependencies List each ofthe factorssthat affects the features stated in the Vision document List assumptions that if changed will alterdhe Vision document For
15. t can be 11 3 Effort Set by the development team Because some features require more time and resources than others estimating the number of team or person weeks lines of code required or function points for example is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame Used in managing scope and determining development priority 14 4 Risk Set by development team based on the probability the project will experience undesirable events such as cost overruns Schedule delays or even cancellation Most project managers find categorizing risks as high medium and low sufficient although finer gradations are possible Risk can often be assessed indirectly by measuring the uncertainty range of the projects teams schedule estimate 11 5 Stability Set by analyst and development team based on the probability the feature will change or the team s understanding of the feature will change Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action SDLC Internal Use Only SDLC 2000 Page 12 lt Project Name gt Vision Date lt dd mmm yy gt lt document identifier gt 11 6 Target Release Records the intended product version in which the feature will first appear This field can be used to allocate features from a Vision document into a particular baseline release When combined wi
16. th the status field your team can propose record and discuss various features of the release without committing them to development Only features whose Status is set to Incorporated and whose Target Release is defined will be implemented When scope management occurs the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release 11 7 Assigned To In many projects features will be assigned to feature teams responsible for further elicitation software requirements and implementation This simple pull down list will help everyone on th ct team better understand responsibilities 11 8 Reason This text field is used to track the source of the requested feature Requirements exi sific reasons This field records an explanation or a reference to an explanation For example the reference to a page and line number of a product requirement specification or to a minute marker on a video of an important customer interview SDLC Internal Use Only SDLC 2000 Page 13
17. ts Detail environmental requirements as needed For hardware based systems environmental issues can include temperature shock humidity radiation etc For software applications environmental factors can include usage conditions user environment resource availability maintenance issues and error handling and recovery 10 Documentation Requirements This section describes the documentation that must be developed to support suecessful application deployment 10 1 User Manual Describe the purpose and contents of the User Manual Discuss destredlength level of detail need for index glossary of terms tutorial vs reference manual strategy etef Formatting and printing constraints should also be identified 10 2 On line Help Many applications provide an on line help system to asstst the user The nature of these systems is unique to application development as they combine aspectssof programming hyperlinks etc with aspects of technical writing organization presentation Many have found the development of on line help system is a project within a project that benefits from up front scope managementand planning activity 10 3 Installation Guides Configuration Read Me File A document that includes installation instructions and configuration guidelines is important to a full solution offering Also a ReadMe file is typi ally included as a standard component The Read Me can include a What s New With This Release
18. uch as a working group consisting of representatives from the project team product management and user or customer community Approved Capabilities that are deemed useful and feasible and have been approved for implementation by the official channek Incorporated Features incorporated into the product baseline atta specific point in time 11 2 Benefit Set by Marketing the product manager or the business analyst All requirements are notcreated equal Ranking requirements by their relative benefit to the end user opens a dialogue with customers analysts and members of the development team Used in managing scope and determining developmentgfiority 4 Critical Essential features Failure tosimplement means the system will not meet customer needs All critical features must be implemented in the release or the schedule will slip Important Features important to the effectiveness and efficiency of the system for most applications Thegynctionality cannot be easily provided in some other way Lack of inclusion of an important feature may affect customer or Usersatisfaction or even revenue but release will not be delayed due to lack of any important feature expected if such an item is not included in a release Useful Features that are useful in less typical applications will be used less frequently or for which reasonably efficient workarounds can be achieved No significant revenue or customer satisfaction impac
Download Pdf Manuals
Related Search