Page 82 -

ChaPter 3 • ProjeCt management 49

Defining the Problem
Whether using the classical SDLC or an object-oriented approach, an analyst first defines the problems
and objectives of a system. These form the foundation of determining what needs to be accomplished
by the system. Methods such as Six Sigma (see Chapter 16 for details) start with a problem definition.
A problem definition usually contains some sort of problem statement, summarized in a
paragraph or two. This is followed by a series of issues or major independent pieces of the prob-
lem. The issues are followed by a series of objectives or goals that match the issues point by
point. Issues are the current situation; objectives are the desired situation. The objectives may be
very specific or worded using a general statement.
Here are some examples of business questions relating to business objectives:
• What are the purposes of the organization?
• Is the organization a for-profit or nonprofit organization?
• Does the company plan to grow or expand?
• What is the organization’s attitude (culture) about technology?
• What is the organization’s budget for IT?
• Does the organization’s staff have the expertise?
Needless to say, a systems analyst needs to understand how a business works.
Finally, the problem definition contains requirements, the things that must be accomplished,
along with the possible solutions and the constraints that limit the development of the system.
The requirements section may include security, usability, government requirements, and so on.
Constraints often include the word not, indicating a limitation, and may contain budget restric-
tions or time limitations.
The problem definition is produced after completing interviews, observations, and docu-
ment analysis with the users. The result of gathering this information is a wealth of facts and
important opinions in need of summary. The first step in producing the problem definition is to
find a number of points that may be included in one issue. Major points can be identified in the
interview in a number of ways:
1. Users may identify an issue, a topic, or a theme that is repeated several times, sometimes
by different people in several interviews.
2. Users may communicate the same metaphors; such as saying the business is a journey, a
war, a game, an organism, a machine, a family, a journey, and so on.
3. Users may tell a story to illustrate a problem that includes a beginning, middle, and an end-
ing, a hero, obstacles to overcome, and a successful (or hoped for) resolution.
4. Users may speak at length on a topic.
5. Users may tell you outright “This is a major problem.”
6. Users may communicate importance using body language or may speak emphatically on an
issue.
7. The problem may be the first thing the user mentions.

Once the issues have been created, the objectives must be stated. An analyst may have to do a
follow-up interview to obtain more precise information about the objectives. After the objectives are
stated, the relative importance of the issues or objectives must be determined. If there are not enough
funds to develop the complete system, the most critical objectives must be completed first. Users are
the best people to identify critical objectives (with the support of analysts) because users are domain
experts in their business area and they know how they work best with technologies in the organization.
One technique is to ask the users to assign a weight for each issue or objective in the first
draft of the problem definition. This is a subjective judgment by the user, but, if a number of
users all assign weights and they are averaged together, the result might reflect the bigger pic-
ture. After the weights have been determined, the problem definition issues and objectives are
re-sequenced in order of decreasing importance, the most important issues listed first. Software
such as that created by Expert Choice (www.expertchoice.com) and other decision support soft-
ware can assist with weighting and prioritizing objectives.
Besides looking through data and interviewing people, a systems analyst should try to witness
the problem firsthand. When looking at the same situation, an employee may view a problem very
differently than a system analyst does. This also gives analysts the opportunity to confirm their
findings. Using multiple methods strengthens the case for taking appropriate action.