Task Descriptor: Define Vision |  |
Define the vision for the future system. Describe the problem and features based on Stakeholder requests.
Based on Method Task: Define Vision
Relationships
Roles | Main: Visionary | Additional: Analyst Architect Executive Sponsor Project Manager | Assisting:
Inputs | Mandatory: None | Optional: Vision Work Items List | External: None
Outputs | Glossary Vision Work Items List
Steps
Identify Stakeholders
Identify the decision-makers, customers, potential users, partners, domain experts, industry analysts and other interested parties (see Role: Stakeholder). Develop profiles of potential (or actual) users of the system that map to the roles of human actors of the system that you are developing. Document the initial information on key users and their environment in the Vision.
Gain agreement on the problem to be solved
Avoid rushing into defining the solution. First, gain agreement on the definition of the problem by asking the stakeholders what they see as the problem. Then search for root causes, or the “problem behind the problem.” Use techniques like the ones described in Guideline: Requirements Gathering Techniques. Formulate the problem statement, and then fill in the corresponding section from Template: Vision. The purpose of this is to help you distinguish solutions and answers from problems and questions.
Capture a common vocabulary
Every project has its own specialized terminology that everyone on the team must understand well to communicate effectively with stakeholders. Work with stakeholders to create a glossary that defines acronyms, abbreviations, and relevant business and technical terms. Work with stakeholder to continually expand and refine the glossary throughout the project life cycle.
Gather stakeholder requests
Use the most appropriate method to gather information, such as the ones in Guideline: Requirements Gathering Techniques. Each one is applicable in a particular situation or to a certain type of stakeholder. If you can meet stakeholders in person, then you can conduct an interview or a brainstorming session. This face to face collaboration is extremely valuable and reduces the chances of the project team misunderstanding the needs of the stakeholders. Some requirements may already be documented in an existing Work Item List. This can often be used as a solid starting position from which a full set of requirements can be created. Any requirements gathered during this step should be captured in the Work Item List. For more information, see Task: Find and Outline Requirements.
Define the system boundaries
Find and define the line that divides the solution and the real world that surrounds the solution. Identify interfaces, as well as input and output information exchanged with users, machines, or systems. Collaborate with the Project Manager and the Architect since decisions concerning system boundaries will have a major impact on cost, schedule and system architecture. A Use-Case Model is one technique that can prove useful in defining the system boundaries. For more information, see Task: Find and Outline Requirements.
Identify constraints on the system
Consider the various sources of constraints that can impact the design or the project itself: Political Economic (budget, licensing) Environmental (regulatory constraints, legal, standards) Technical (platforms, technology) Feasibility (schedule, resources allocation, outsourcing) System (solutions compatibility, support of operating systems and environments). Collaborate with the Project Manager and the Architect since decisions concerning system constraints will have a major impact on cost, schedule and system architecture.
Define features of the system
Work with stakeholders to capture a list of features that stakeholders want in the system, briefly describing them and giving attributes to help define their general status and priority in the project. Update the Vision to capture the features identified and their attributes.
Achieve concurrence
Conduct a review of the project vision with relevant Stakeholders and the development team to ensure agreement, assess quality, and identify required changes. See Guideline: Effective Requirement Reviews for more information.
Properties
Multiple Occurrences |
Event-Driven |
Ongoing |
Optional |
Planned |
Repeatable |
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. OpenUP Copyright. OpenUP/DSDM Copyright.