Breaking Down Complex Problems

Analysis is complete enough to move forward when the decisions that affect the program's behavior have been clarified. If a decision still has several reasonable answers, ask for clarification instead of selecting one without agreement.

Programming

From Request to Real Problem

A programming request can sound simple while hiding decisions that must be made before coding begins. For example, a request to write a program that backs up important files appears to describe a basic copying task. However, the request does not yet explain which files count as important, where the backup should go, or what should happen when a backup already exists. Problem analysis is the process of finding these gaps and ambiguities before you begin coding.

The goal of analysis is not to solve the problem immediately. Its goal is to understand what the program must do, what decisions must be made, and what rules the program must follow. Coding should wait when the problem statement does not provide enough information to make those decisions responsibly.

Finding the Missing Decisions

What information is missing from the problem statement, and how do those gaps affect whether coding can begin?

A useful analysis asks questions such as: Which files should be included? Should the program back up every file, or only certain types? How is importance determined? Where should the backup be stored? Should the program create a folder? Should it overwrite an existing backup, or keep multiple versions?

Definition

A problem statement is insufficient when it leaves important behavior open to multiple interpretations and you cannot choose among those interpretations from the information provided.

Key point

The Analysis-to-Design Handoff

How does an ambiguous problem statement become a concrete list of functions the program must perform?

Once analysis identifies and resolves the missing information, design turns those decisions into a functional requirements list. A functional requirement describes behavior the program must provide. It is more concrete than the original request and gives coding a target to implement.

Worked example

Designing the backup request

Turn the clarified backup decisions into a functional requirements list.

1
Clarify the input
The program will accept a folder path as input. This answers how the program knows which location to examine.
2
Clarify file selection
The program will back up all files in that folder. This replaces the unclear phrase important files with a specific selection rule.
3
Clarify storage
Backups will be saved to a folder named backups_YYYY-MM-DD in the user's home directory. This specifies the destination and gives the backup folder a date-based name.
4
Record the requirements
The decisions are written as a functional requirements list so they can guide implementation and be reviewed by other people.

Result

The design now states what input the program accepts, which files it backs up, and where it stores the result.

The handoff from analysis to design is not a leap from vague idea to code. It is a translation: questions discovered during analysis are answered with decisions, and those decisions become requirements that describe the program's expected behavior.

A Repeatable Analysis Workflow

What steps happen between reading a problem statement, uncovering ambiguities, confirming constraints, and designing a solution?

1
Read the problem statement and describe what it appears to request.
2
List details that are missing, ambiguous, or open to more than one interpretation.
3
Identify the decisions and rules that will affect the program's behavior.
4
Decide whether the available information is sufficient to move into design.
5
Ask questions or seek clarification when it is not sufficient.
6
Write the answers as functional requirements.
7
Review the design and return to analysis if the requirements reveal a new gap.

Why Designs Can Differ

How can two people start with the same problem but identify different assumptions, requirements, and program designs?

Two people can begin with the same vague request and produce different analyses because they may notice different ambiguities or make different assumptions about what the request means. One person might interpret important files as every file in a chosen folder. Another might interpret the phrase as selected file types. They might also propose different ways to handle the backup destination or existing backups.

Different initial designs do not automatically mean that one person is careless or that the other is correct. The original statement may not have determined a single design. The purpose of clarification and written requirements is to turn individual assumptions into a shared understanding that others can review before coding begins.

Mistakes During Problem Analysis

Common mistake
Starting to code as soon as the request sounds simple
What it looks like
Beginning the backup program without deciding which files are important or where backups belong.
Why it fails
The implementation may be built around an interpretation that was never agreed upon.
Do this instead
List the missing decisions first and seek clarification before designing the behavior.
Common mistake
Treating an assumption as a requirement
What it looks like
Assuming that the program should overwrite an existing backup.
Why it fails
The problem statement did not establish whether backups should be overwritten or whether multiple versions should be kept.
Do this instead
Record the assumption as an unanswered question and obtain a decision.
Common mistake
Believing analysis ends permanently when design begins
What it looks like
Refusing to revisit the original questions after writing a first requirements list.
Why it fails
Design can reveal new gaps that were not visible during the initial analysis.
Do this instead
Review the design and cycle back to analysis whenever a new question appears.
Common mistake
Keeping the analysis only in one person's head
What it looks like
Relying on an informal interpretation instead of writing down the decisions.
Why it fails
Other people cannot review the interpretation or catch misunderstandings before coding.
Do this instead
Write the analysis and functional requirements so they create a shared understanding.

Best practice

When you notice uncertainty, phrase it as a concrete question. Questions such as Which files should be included?, Where should the backup be stored?, and What should happen to an existing backup? are more useful than a general note that the request is unclear.

Practice: Test the Statement

MEDIUM

Imagine that you receive the request: Create a program that organizes important documents. Before designing the program, identify at least three questions that must be answered and explain why each answer could change the program's behavior.

Hints

Look for an unclear definition of important.
Ask what input location or collection of documents the program should use.
Consider what result the program should create and what should happen to documents that are already organized.

Your attempt (not saved)

MEDIUM

After identifying your questions, write three functional requirements that could be created once those questions have been answered. Each requirement should describe a behavior the program must provide, not merely a general goal.

Hints

Begin with a behavior such as accept, identify, place, or preserve.
Make the input, selection rule, or result specific enough for another person to review.
If an answer is not provided, state the decision that still needs clarification rather than inventing it.

Your attempt (not saved)

What to Carry Forward

1
Problem analysis finds gaps, ambiguities, decisions, and rules before coding begins.
2
A problem statement is not ready for design when important behavior can still be interpreted in multiple reasonable ways.
3
Clarifying questions provide the information needed to create functional requirements.
4
Design turns analysis answers into a concrete description of how the program should behave.
5
Analysis and design can loop, and written requirements help different people build a shared understanding.

Key Takeaways

Analyze a problem before coding when the request leaves important behavior unclear.
Find missing details by asking which decisions, inputs, rules, and outcomes still need clarification.
Convert clarified answers into a functional requirements list that describes program behavior.
Expect analysis and design to be iterative; a design can reveal new questions.
Write down the analysis and requirements so other people can review the shared understanding.

More concepts starting with B