What is problem analysis in software engineering?

Problem analysis in software engineering is the process of understanding and defining a problem before designing a solution for it. It produces a written problem statement, a list of requirements and constraints, a root cause for any defect, and a measurable definition of success. It is the first activity in the software development life cycle, and it comes before design, coding, and testing.

The reason it exists is simple. A team that starts coding on a vague request usually builds the wrong thing, or builds the right thing for the wrong reason. Problem analysis costs a few days at the start and saves weeks of rework later.

The terms: problem statement, problem domain, and root cause

A problem statement is one or two paragraphs that say who has the problem, what the problem is, and why it matters. It names the affected users, the current behavior, the desired behavior, and the gap between them. A good problem statement does not mention a solution.

The problem domain is the area of the real world the software is about. For a train booking system the domain is trains, seats, fares, and passengers. Understanding the domain means learning its vocabulary and rules before writing any code.

A root cause is the underlying condition that produces a visible symptom. Frequent crashes are a symptom; a memory leak in one module is a root cause. Problem analysis separates the two, because fixing a symptom leaves the problem in place.

The five steps of problem analysis

Step 1: Understand and state the problem. Talk to the people who have the problem and write the problem statement. Confirm it with them in their own words.

Step 2: Gather requirements and set the scope. Functional requirements describe what the system must do, such as booking a seat. Non-functional requirements describe how well it must do it, such as responding within 500 milliseconds. Scope states what is in and what is out, which prevents the project from growing without a decision.

Step 3: Break the problem into parts. Split the whole into smaller pieces that can each be understood alone. An online store becomes user accounts, catalog, inventory, cart, and payments. Then rank the parts by which ones must be solved first.

Step 4: Find the root causes and the constraints. For an existing system, use the five whys technique, which asks "why" repeatedly until the answer is a cause you can change. A fishbone diagram groups possible causes by category such as people, process, tools, and data. Constraints include hardware limits, budget, deadlines, legal rules, and the systems the software must connect to.

Step 5: Define success criteria. Write down the measurable result that means the problem is solved. "Reduce query response time from 5 seconds to 1 second" is a success criterion. "Make it faster" is not.

A worked example: a train ticket booking system

Suppose a railway company asks for a new booking system because customers sometimes receive tickets for the same seat.

Understanding the problem. The problem statement reads: passengers occasionally book a seat that another passenger has already booked, which forces staff to reassign seats at the platform. The company wants zero double bookings and fast checkout.

Requirements and scope. Functional requirements include searching trains, checking seat availability, paying, and issuing a ticket. Non-functional requirements include handling up to 10,000 users at the same time and meeting payment card security standards. Refunds are out of scope for the first release.

Breaking it down. The parts are user authentication, seat availability checks, payment integration, and ticket issue.

Root cause. The five whys trace the double bookings to a race condition. Two requests read the same seat as free, and both write a booking, because nothing prevents the second write. The cause is in the database update, not in the user interface.

Success criteria. Introduce a lock or an atomic update on the seat row so that only one booking can succeed. Measure the result: double bookings fall to zero and failed bookings stay under 1 percent under a 10,000-user load test.

Problem analysis in one table