Commentary: Vision - UML

When someone joins the project, it is useful to be able to say, "Welcome! Please go read the 7 - page Vision at the project website." It is also useful to have an executive summary that briefly describes the project, as a context for the major players to establish a common vision of the project.

The Vision should not be long, nor should it attempt to describe firm requirements in detail. And it should summarize some of the information in the Use - Case Model and Supplementary Specification.

The Key High - Level Goals and Problems of the Stakeholders

This section summarizes the goals and problems at a high level often higher than specific use cases - and reveals important non - functional and quality goals that may belong to one use case or span many, such as:

  • We need fault - tolerant sales processing.
  • We need the ability to customize the business rules.

Guideline: What are Some Facilitation Methods?

It is especially during activities such as high - level problem definition and goal identification that creative, investigative group work occurs. Here are some useful group facilitation techniques to discover root problems and goals, and support idea generation and prioritization: mind mapping, product vision box creation, fishbone diagrams, pareto diagrams, brainstorming, multi - voting, dot voting, nominal group process, brain writing, and affinity grouping. Check them out on the Web. I prefer to apply several of these during the same workshop, to discover common problems and requirements from different angles.

Summary of System Features

Simply listing the use case names is not sufficient in the Vision to grasp the major features. Why?

  • Too detailed or low - level. People want a short summary of the big ideas. There could be 30 or 50 use cases.
  • The use case name can hide interesting major features stakeholders really want to know about. For example, suppose that the description of automated payment authorization functionality is embedded in the Process Sale use case. A reader of a list of use case names can't tell if the system will do payment authorization.
  • Some noteworthy features span or are orthogonal to the use cases. For example, during the first NextGen requirements workshop, someone might say "The system should be able to interact with existing third - party accounting, inventory, and tax calculation systems."

Therefore, an alternative, complementary way to express system functions is with features, or more specifically in this context, system features, which are high - level, terse statements summarizing system functions. More formally, in the UP, a system featureis "an externally observable service provided by the system which directly fulfills a stakeholder need" [KruchtenOO].

For example:

The system does payment authorization.

Functional system features are to be contrasted with various kinds of non - functional requirements and constraints, such as: "The system must run on Linux, must have 24 / 7 availability, and must have a touch - screen interface." Note that these fail the linguistic test; for example, the system does Linux.

Guideline: How to Write the Feature List?

Terse is good in the Vision - indeed, in any document.

Here is a features example at a high level, for a large multi - system project of which the POS is just one element:

The major features include:

  • POS services
  • Inventory management
  • Web - based shopping

It is common to organize a two - level hierarchy of system features. But in the Vision document more than two levels leads to excessive detail; the point of system features in the Vision is to summarize the functionality, not decompose it into a long list of fine - grained elements. A reasonable example in terms of detail:

The major features include:

POS services:

  • sales capture
  • payment authorization
  • Inventory management:
  • automatic reordering

How many system features should the Vision contain?

Guideline: Should We Duplicate Other Requirements in the Vision?

In the Vision, system features briefly summarize functional requirements often detailed in the use cases. Likewise, the Vision can summarize other requirements (for example, reliability and usability) that are detailed in the Supplementary Specification. But be careful to avoid going down the path of repeating yourself.

Guideline: Should You Write the Vision or Use Cases First?

It isn't useful to be rigid about the order. While developers are collaborating to create different requirements artifacts, a synergy emerges in which working on one artifact influences and helps clarify another. Nevertheless, a suggested sequence is:

  • Write a brief first draft of the Vision.
  • Identify user goals and the supporting use cases by name.
  • Write some use cases in detail, and start the Supplementary Specification.
  • Refine the Vision, summarizing information from these.

Glossary Revision History

Glossary Revision History



All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

UML Topics