This task describes how to develop the overall vision for the system, including the problem to be solved, the key stakeholders, the scope/boundary of the system, the system's key features, and any constraints.

One of the simplest ways to gain agreement on the definition of the problem, is to write it down and see if everyone
agrees.

Ask the group: What is the problem?

It is very common to rush headlong into defining the solution, rather than taking time to first understand the
problem. Write down the problem, and see if you can get everyone to agree on the definition.

Then ask the group again: What is the problem, really?

Search for root causes, or the "problem behind the problem". The real problem is often hiding behind what is
perceived as a problem.

Don't accept the first statement of a problem. Continue to ask "why?" Explore the nature of the problem.

Sometimes the group can be so focused on an envisioned solution that it is hard to get them to formulate what the
underlying problem actually is. In such cases, it can be beneficial to explore the benefits of the solution, and then
try to find the problems being solved by those benefits. You can then explore whether or not those problems are "real"
problems in the organization. Common techniques used to find the problem behind the problem are brainstorming, Fishbone Diagrams and Pareto Diagrams.

Identify Stakeholders

Depending on the domain expertise of the development team, identifying the stakeholders may be a trivial or a
nontrivial step. Often, this simply involves interviewing decision-makers, potential users and other interested
parties. The following questions are helpful:

Who are the users of the system?

Who is the economic buyer for the system?

Who else will be affected by the outputs that the system produces?

Who will evaluate and bless the system when it is delivered and deployed?

Are there any other internal or external users of the system whose needs must be addressed?

Who will maintain the new system?

Is there anyone else?

Okay, is there anyone else?

Start to develop profiles of potential (or actual) users of the system. Initial information on key users and
their environment should be documented in the Vision
document.

Define the System Boundaries

The system boundary defines the border between the solution and the real world that surrounds the solution. In other
words, the system boundary describes an envelope in which the solution system is contained. Information, in the form of
inputs and outputs, is passed back and forth from the system to the users that live outside of the system. All
interactions with the system occur via interfaces between the system and the external world.

In many cases, the boundaries of the system are obvious. For example, the boundaries of a single user, shrink-wrap
personal contact manager that runs on Microsoft Windows® are relatively well defined. There is only one user and one
platform. The interfaces between the user and the application consist of the user interface dialogs that the user
accesses to enter information into the system, and any output reports and communication paths that the system uses to
document or transmit the resulting information.

Identify Constraints to be Imposed on the System

There are a variety of sources of constraints to be considered. Following is a list of potential sources and questions
to ask:

Political: Are there internal or external political issues that affect potential solutions? Interdepartmental?

Economic: Which financial or budgetary constraints are applicable? Are there costs of goods sold, or product
pricing considerations? Are there any licensing issues?

Environmental: Are there environmental or regulatory constraints? Legal? Other standards we are restricted by?

Technical: Are we restricted in our choice of technologies? Are we constrained to work within existing platforms or
technologies? Are we prohibited from any new technologies?

Feasibility: Is the schedule defined? Are we restricted to existing resources? Can we use outside labor? Can we
expand resources? Temporary? Permanent?

System: Is the solution to be built on our existing systems? Must we maintain compatibility with existing
solutions? Which operating systems and environments must be supported?

Formulate Problem Statement

With the whole group, work on easel charts and fill in the following template for each problem you have identified:

The 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 <list some key benefits of a successful solution>.

The purpose of this template is to help you distinguish solutions/answers from problems/questions.

Example:

The problem of: untimely and improper resolution of customer service issuesaffects: our customers, customer support reps and service technicians.The impact of which is: customer dissatisfaction, perceived lack of quality, unhappy employees and loss of
revenue.
A successful solution would: provide real-time access to a trouble-shooting database by support reps and
facilitate dispatch of service technicians, in a timely manner, only to those locations which genuinely need their
assistance.

Define Features of the System

Based on the benefits listed in your problem statements, develop a list of features you want in the system. Describe
them briefly, and give them attributes to help define their general state and priority in the project.

Evaluate Your Results

You should check the Vision at this stage to verify that your work is on track, but not review it in detail. Consider
the checklist for the Vision document (Checklist: Vision).