Breaking Down Complex Problems
Problem analysis identifies gaps and ambiguities in a problem statement before you begin coding.
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
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?
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.
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.
The Analysis-to-Design Handoff
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.
Designing the backup request
Turn the clarified backup decisions into a functional requirements list.
Clarify the input: The program will accept a folder path as input. This answers how the program knows which location to examine.
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.
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.
Record the requirements: The decisions are written as a functional requirements list so they can guide implementation and be reviewed by other people.
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
- Read the problem statement and describe what it appears to request.
- List details that are missing, ambiguous, or open to more than one interpretation.
- Identify the decisions and rules that will affect the program's behavior.
- Decide whether the available information is sufficient to move into design.
- Ask questions or seek clarification when it is not sufficient.
- Write the answers as functional requirements.
- Review the design and return to analysis if the requirements reveal a new gap.
Why Designs Can Differ
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
Starting to code as soon as the request sounds simple
The implementation may be built around an interpretation that was never agreed upon.
Fix:
List the missing decisions first and seek clarification before designing the behavior.Treating an assumption as a requirement
The problem statement did not establish whether backups should be overwritten or whether multiple versions should be kept.
Fix:
Record the assumption as an unanswered question and obtain a decision.Believing analysis ends permanently when design begins
Design can reveal new gaps that were not visible during the initial analysis.
Fix:
Review the design and cycle back to analysis whenever a new question appears.Keeping the analysis only in one person's head
Other people cannot review the interpretation or catch misunderstandings before coding.
Fix:
Write the analysis and functional requirements so they create a shared understanding.
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
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.
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.
What to Carry Forward
- Problem analysis finds gaps, ambiguities, decisions, and rules before coding begins.
- A problem statement is not ready for design when important behavior can still be interpreted in multiple reasonable ways.
- Clarifying questions provide the information needed to create functional requirements.
- Design turns analysis answers into a concrete description of how the program should behave.
- 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.