EDUCE Overview Copyright 2009 Nikolas S. Boyd.
All rights reserved.

Problem Description


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


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


Use a problem description when


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:

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


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