Problem Solving Techniques

SWEBOK Ch. 13 Section 1

1.1. Definition of Problem Solving

Problem solving refers to the thinking and activities conducted to answer or derive a solution to a problem. There are many ways to approach a problem, and each way employs different tools and uses different processes. These different ways of approaching problems gradually expand and define themselves and finally give rise to different disciplines. For example, software engineering focuses on solving problems using computers and software.

While different problems warrant different solutions and may require different tools and processes, the methodology and techniques used in solving problems do follow some guidelines and can often be generalized as problem solving techniques. For example, a general guideline for solving a generic engineering problem is to use the three-step process given below.

    • Formulate the real problem.

    • Analyze the problem.

    • Design a solution search strategy.

Definition of Problem Solving Resources


1.2. Formulating the Real Problem

Gerard Voland writes, “It is important to recognize that a specific problem should be formulated if one is to develop a specific solution” [2*]. This formulation is called the problem statement, which explicitly specifies what both the problem and the desired outcome are.

Although there is no universal way of stating a problem, in general a problem should be expressed in such a way as to facilitate the development of solutions. Some general techniques to help one formulate the real problem include statement-restatement, determining the source and the cause, revising the statement, analyzing present and desired state, and using the fresh eye approach.

Formulating the Real Problem Resources

Typical Problem Statement components (from LinkedIn Learning video, with specific software engineering information and definitions using IEEE SEVOCAB when applicable from me):

  • Goals (high level intended outcomes; for software, a Product Backlog)

  • Boundaries / Scope (where the functions and responsibilities of the solution start and end / what it should do and what is left to other systems to do)

  • Success criteria (set of conditions to be satisfied at completion; must be measurable and verifiable, like a test)

  • Constraints (externally imposed limitations on system requirements, design, or implementation or on the process used to develop or modify a system)

  • Assumptions (things that are accepted as true or as certain to happen, without proof)

  • Stakeholders (individuals or organizations having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations; identify them by role and describe how or why they are stakeholders)

  • Timelines (for software, a breakdown of high level goals like from the Product Backlog into time-bound smaller, more detailed tasks, like in Sprint Backlogs)

1.3. Analyze the Problem

Once the problem statement is available, the next step is to analyze the problem statement or situation to help structure our search for a solution. Four types of analysis include situation analysis, in which the most urgent or critical aspects of a situation are identified first; problem analysis, in which the cause of the problem must be determined; decision analysis, in which the action(s) needed to correct the problem or eliminate its cause must be determined; and potential problem analysis, in which the action(s) needed to prevent any reoccurrences of the problem or the development of new problems must be determined.

Analyze the Problem Resources

The 5 Whys

Eric Ries video


Problem Analysis / Root Cause Analysis

1.4. Design a Solution Search Strategy

Once the problem analysis is complete, we can focus on structuring a search strategy to find the solution. In order to find the “best” solution (here, “best” could mean different things to different people, such as faster, cheaper, more usable, different capabilities, etc.), we need to eliminate paths that do not lead to viable solutions, design tasks in a way that provides the most guidance in searching for a solution, and use various attributes of the final solution state to guide our choices in the problem solving process.

1.5. Problem Solving Using Programs

The uniqueness of computer software gives problem solving a flavor that is distinct from general engineering problem solving. To solve a problem using computers, we must answer the following questions.

    • How do we figure out what to tell the computer to do?

    • How do we convert the problem statement into an algorithm?

    • How do we convert the algorithm into machine instructions?

The first task in solving a problem using a computer is to determine what to tell the computer to do. There may be many ways to tell the story, but all should take the perspective of a computer such that the computer can eventually solve the problem. In general, a problem should be expressed in such a way as to facilitate the development of algorithms and data structures for solving it.

The result of the first task is a problem statement. The next step is to convert the problem statement into algorithms that solve the problem. Once an algorithm is found, the final step converts the algorithm into machine instructions that form the final solution: software that solves the problem.

Abstractly speaking, problem solving using a computer can be considered as a process of problem transformation—in other words, the step-by-step transformation of a problem statement into a problem solution. To the discipline of software engineering, the ultimate objective of problem solving is to transform a problem expressed in natural language into electrons running around a circuit. In general, this transformation can be broken into three phases:

a) Development of algorithms from the problem statement.

b) Application of algorithms to the problem.

c) Transformation of algorithms to program code.

The conversion of a problem statement into algorithms and algorithms into program codes usually follows a “stepwise refinement” (a.k.a. systematic decomposition) in which we start with a problem statement, rewrite it as a task, and recursively decompose the task into a few simpler subtasks until the task is so simple that solutions to it are straightforward. There are three basic ways of decomposing: sequential, conditional, and iterative.

Mock Interview

I wanted to change the world

When I was a young man, I wanted to change the world.

I found it was difficult to change the world, so I tried to change my nation.

When I found I couldn't change the nation, I began to focus on my town. I couldn't change the town and as an older man, I tried to change my family.

Now, as an old man, I realize the only thing I can change is myself, and suddenly I realize that if long ago I had changed myself, I could have made an impact on my family.

My family and I could have made an impact on our town.

Their impact could have changed the nation and I could indeed have changed the world.

Written by an unknown Monk around 1100 A.D.