Problem Description

Intent

Describe and frame the business problem(s) that need solution(s).

Motivation

The world has problems that need solutions, some of which may benefit from software solutions. Problems exist in the world outside of a computer. Jackson has noted this challenge regarding problems: that we must remain focused on the world when describing problems.

“Not only does everyone agree that you should focus on the problem before the solution; almost everyone agrees that you should focus on what the system will do before you focus on how it will do it. What before how is the motto.”

“But it’s not a very helpful motto. It’s often hard to distinguish a problem from its solution, and it’s no easier to distinguish what from how. It’s more helpful to distinguish where. That is, to recognize that the solution is located in the computer and its software, and the problem is in the world outside.”

Applicability

Use a problem description when

  • you need to describe a business (improvement) opportunity that may benefit from a software solution.

Considerations

First and foremost, it is useful to determine why a business requires a solution. Is there really a problem to be solved? Can it be either resolved or dissolved instead? If not, then what is the “simplest thing that could possibly work?”

Problem descriptions should focus on the entities, phenomena, events, sequences, and facts that exist and/or occur in the world. Problem descriptions intend to answer the following questions:

  • where – where does the problem exist?
  • where – what is the surrounding context?
  • why – why does the problem need to be solved?
  • why – what are the business policies to which a solution must be aligned?
  • what – what are the problem elements: entities, values, relations, states, transitions, events, sequences?

The answers to these questions will often fit into one of the following problem frames:

frame  description
required behaviorwhat conditions must be maintained by controlling the behavior of some part of the world?
commanded behaviorwhat commands may an operator use to control the behavior of some part of the world?
information displaywhat information must be displayed to observe the states and behavior of some part of the world?
simple workpieceswhat information must be captured and displayed regarding some part(s) of the world?
transformationwhat are the formats and the rules that determine how to transform data from one format to another?

Consequences

Benjamin Kovitz offers an excellent introduction to the usage of problem descriptions and problem frames in the context of software requirements. Problem descriptions and problem frames can be used in conjunction with usage descriptions to capture software requirements.

The dominant metaphors used in object-oriented design intentionally blur the distinction between a problem and its solution. Object-oriented designs structure and name design entities (objects) so that they resemble the structure and vocabulary of the entities and activities found in the world (more often, a description of a problem found in the world). Therefore, when using object-oriented design, it becomes even more important to distinguish a problem from its solution, and to describe a problem in terms of its place in the world, and the opportunities offered and the improvements intended by a software solution.