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? what is the surrounding context?
• why - why does the problem need to be solved? 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:

• required behavior - what conditions must be maintained by controlling the behavior of some part of the world?
• commanded behavior - what commands may an operator use to control the behavior of some part of the world?
• information display - what information must be displayed to observe the states and behavior of some part of the world?
• simple workpieces - what information must be captured and displayed regarding some part(s) of the world?
• transformation - what 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.

TODO: value proposition, event facts: who what when where how much, value exchange, promises

value exchange can be modeled as stock flow duality via McCarthy ERA model

§ § §