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.

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.

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.

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?

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 issues
affects: 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.

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.

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).