Workflow Detail: Analyze the Problem

Description

The first step in any problem analysis is to make sure that all parties involved agree on what the problem is that needs to be solved-or opportunity that will be realized-by the system.  In order to help avoid misunderstandings, it is important to agree on common terminology which will be used throughout the project. Starting early in the lifecycle, you should define your project terms in a glossary which will be maintained throughout the life of the project.

In order to fully understand the problem(s) that need to be addressed, it is very important to know who the stakeholders are in the conceptual vision for the project. Note that some of these stakeholders-the users of the system-will be represented by actors in your use-case model.

The Requirements Management Plan is used to provide guidance on the requirements artifacts that you should develop, the types of requirements that should be managed for the project, the requirement attributes that should be collected and the approach to requirements traceability that will be used in managing the product requirements.
(See also: requirements traceability, requirements attributes).

The primary artifact in which you capture the information gained from your problem analysis is the Vision, which identifies the high-level user or customer view of the system to be built. In the Vision, initial high-level requirements identify the key features it is desired that the appropriate solution will provide. These are typically expressed as a set of high-level features the system might possess in order to solve the most critical problems.

Key stakeholders should be involved in gathering the set of features to be considered, which might be gathered in a requirements workshop. The features can then be assigned attributes such as rationale, relative value or priority, source of request and so on, so that dependencies and work plans can begin to be managed.

To determine the initial scope for your project, the boundaries of the system must be agreed upon.  The System Analyst identifies users and systems - represented by actors - which will interact with the system.

If you have developed a domain model, a business use-case model, along with any business rules, these will be useful inputs to help perform the analysis.
(See also: developing a domain model, Guidelines: Going from Business Models to Systems, business use-case model).

This workflow detail should be revisited several times during Inception and early Elaboration. Then, throughout the lifecycle of the project, it should be revisited as necessary while managing the inevitable changes that will occur in your project, in order to ensure that you continue to address the correct problem(s).

Related Information

This section provides links to additional information related to this workflow detail.

• Guideline: Brainstorming and Idea Reduction
• Guideline: Fishbone Diagrams
• Guideline: Going from Business Models to Systems
• Guideline: Pareto Diagrams
• Guideline: Requirements Workshop

Timing

This work is normally undertaken early in an iteration.

Optionality

Performed primarily in early iterations where the problem being addressed need to be understood.

How to Staff

The project members involved in analyzing the problem should be efficient facilitators and have experience in techniques for finding the problem behind the problem. Of course, familiarity with the targeted technology is desirable, but it is not essential. Active involvement from various stakeholders in the project is required.

Work Guidelines

See the Related Information section for additional guidance that will help you in performing this work.

Rational Unified Process