The RUP Vision Document
In short In the Rational Unified Process (RUP), the Vision is a short document stating what the product is, why it is being built, who it serves and what its main features are. The team uses it to make decisions throughout the project and as the yardstick at acceptance.
Based on: IBM RUP Vision template; “Developing a Product Vision in IBM Rational Unified Process” (article); Yu. A. Maglinets, Analysis of Requirements for Information Systems, lecture 4; D. Leffingwell, D. Widrig, Managing Software Requirements, ch. 4 and 17.
On this page
Key ideas#
Why it matters#
The article on the RUP Vision cites the Standish Group CHAOS report: alongside executive support and user involvement, clear objectives and a minimized scope rank among the strongest success factors. A Vision puts both on paper cheaply. Other methods call it a project concept.
Structure#
The RUP template has six main parts: introduction, positioning, stakeholder and user descriptions, product overview, product features, and constraints (quality ranges, standards, system, performance and documentation requirements). The outline under “Template” below shows what each holds. Two items in the positioning part do most of the work.
The problem statement has four slots: the problem, who it affects, its impact, and what a good solution would bring. The format comes from Leffingwell and Widrig’s five-step problem analysis. The position statement uses Geoffrey Moore’s keywords: target customer, need, product, category, key benefit, main alternative, key difference.
Features and their attributes#
Leffingwell and Widrig recommend describing a product as roughly 25 to 99 features: enough to see the whole, few enough to manage. Each feature carries attributes such as status (proposed, approved, incorporated), benefit (critical, important, useful), effort, risk, stability, target release, owner and rationale. The same attributes appear in the Requirements Management Plan, so features plug straight into traceability.
Vision versus scope#
Maglinets stresses that the two differ and that you need both. The vision is deliberately unconstrained: it describes what the ideal solution would look like, so planning starts from goals rather than from today’s resources. Scope is the bounded part of that vision you will actually build within time, budget and staff limits.
A good vision helps the customer see the problem behind the problem and improve the business, not just automate today’s process. Maglinets quotes G. Kalyanov: automating processes as they are is like paving the paths cows have trodden.
Related formats#
- GOST 34.601-90, the Russian standard on stages of creating automated systems, has a separate concept stage and asks for several alternative concepts, so the customer chooses rather than invents. See GOST Standards for Automated Systems.
- MSF vision/scope (Microsoft Solutions Framework), as Maglinets summarizes it, covers business benefits, the solution concept, scope and release strategy, and design strategies, with a risk assessment prepared alongside.
Delta Vision for later releases#
Leffingwell and Widrig point out that rewriting the full Vision for version 2.0 wastes effort and hides what changed. Keep version 1.0 as the baseline and write a Delta Vision that records only the differences: new features, removed features (ones that proved unnecessary or were replaced), and newly identified future features. Together the two define the product at 2.0.
The same idea helps with legacy systems: understand current behaviour from code, specifications and the team’s knowledge, then document only what this release changes.
How to apply it#
- Write the problem statement with the sponsor. If you cannot fill all four slots, you are not ready to describe a product.
- Write the position statement and test it with several stakeholders separately.
- Profile stakeholders and users; list key needs with priorities.
- List 25–99 features together with the customer and the developers.
- Make a quick estimate, as Maglinets describes after Leffingwell: the customer rates each feature’s priority, developers rate effort and risk, all on a three-point scale. Put it in one table and choose the first baseline.
- Record constraints, get sign-off, and use the Vision at acceptance to check the delivered product.
- For the next release, write a Delta Vision.
Template#
# Vision: <product name>, version <n>
## 1. Introduction — purpose, scope of this document, terms, references
## 2. Positioning
- Opportunity — why now
- Problem statement — problem / who is affected / impact / benefits of a good solution
- Position statement — customer / need / product / category / benefit / alternative / difference
## 3. Stakeholders and users
- Stakeholder profiles — representative, responsibilities, success criteria, involvement
- User profiles — who uses it, how often, skill level
- Key needs — need, priority, current workaround
- Alternatives — what users would do without this product
## 4. Product overview
- Product perspective — standalone or part of a larger system
- Capabilities, assumptions and dependencies
- Cost, pricing and licensing — if relevant
## 5. Features — 25–99 items; for each: ID, description, status, benefit, effort, risk, target release
## 6. Constraints — quality ranges, standards, platform, performance, documentation
Example#
The Workshop (a fictional chain of 12 bike-repair workshops):
- Problem statement: customers cannot see where their repair stands; this affects customers and front-desk staff; the impact is constant calls and wasted trips; a good solution would cut calls and free staff for customers in the shop.
- Position statement: for cyclists who need a repair without wasted trips, Workshop Online is a booking and tracking service that shows the real repair status. Unlike phoning the shop, it works at any hour.
| ID | Feature | Benefit | Effort | Risk | Release |
|---|---|---|---|---|---|
| F1 | Book a repair slot online | Critical | Medium | Low | 1.0 |
| F2 | Status notifications to customers | Critical | Medium | Medium | 1.0 |
| F3 | Parts reorder suggestions for managers | Useful | High | High | 2.0 |
Pitfalls#
- Hundreds of features. That is a specification, not a vision. Group them into 25–99.
- A vision that only describes today’s process. Ask what the business should look like.
Sources and further reading#
- IBM Rational Unified Process (RUP) document templates: Vision.
- “Developing a Product Vision in IBM Rational Unified Process” (article, in Russian) — document structure and the case for a Vision.
- Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007, lecture 4 (vision versus scope, GOST concept stage, MSF vision/scope, quick estimate).
- D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000, ch. 4 (problem statement), ch. 17 (vision document, Delta Vision).
- Standish Group. CHAOS report, as cited in the RUP Vision article.