What Is the Difference Between System Analysis and System Design?
System analysis is the study of a problem to decide what a system must do. System design is the planning of how that system will be built to do it. Analysis produces a requirements document. Design produces a blueprint: the architecture, the data model, the interfaces, and the detailed structure of each part. Together they form the subject called system analysis and design (SAD). That is the standard name for the early phases of the software development life cycle (SDLC), the sequence of stages a project passes through from idea to retirement.
What a system is in this context
A system is a set of parts that work together for a purpose, with a boundary that separates it from its environment. A payroll system takes time sheets and tax rules as inputs, produces payslips and bank transfers as outputs, and stores employee records between runs. Analysis and design both begin by drawing that boundary, because everything inside it must be specified and everything outside it is an assumption.
What system analysis does
System analysis answers the question "what should the system do, and for whom?". The analyst studies the current process, interviews the people who use it, and records the problems to solve. Consider a hospital that wants an appointment system. The analyst learns that patients call a desk, that the desk double-books about 3 percent of slots, and that doctors want a daily list by 7 a.m.
The main steps. Study the existing system, gather requirements through interviews, observation, and questionnaires, model the requirements, and check that the project is feasible in cost, time, and technology.
The outputs. A software requirements specification (SRS) that lists functional requirements, which state what the system does, and non-functional requirements, which state how well it must do it. Analysis also produces use cases, which describe one interaction from the user's view, data flow diagrams (DFDs), which show where data moves, and a feasibility report.
The people. A systems analyst or business analyst leads this phase. Their skill is asking questions and writing precise statements, such as "the system shall prevent two appointments in the same slot with the same doctor".
What system design does
System design answers the question "how will the system do it?". It takes the requirements as fixed and makes the technical decisions that satisfy them. For the hospital, the designer stores appointments in a relational database with a unique constraint on doctor and time slot. The desk uses a web application, and a scheduled job generates the daily list at 6:30 a.m.
The two levels. High-level design (HLD) chooses the architecture: the major parts, how they communicate, the database type, and the deployment. Low-level design (LLD) specifies each part: the classes, methods, table schemas, and algorithms.
The outputs. Architecture diagrams, an entity relationship diagram (ERD) that shows the tables and their relationships, API specifications, class diagrams, and the interface layouts. The design document is what programmers build from.
The people. A software architect or senior engineer leads the design. Their skill is choosing between options and stating the trade-off of each choice, for example accepting a slower write to guarantee no double booking.
System analysis vs system design
| Aspect | System analysis | System design |
|---|---|---|
| Question | What must the system do? | How will the system do it? |
| Input | Business problem, current process | Requirements specification |
| Output | SRS, use cases, DFDs, feasibility report | Architecture, ERD, API spec, class diagrams |
| Focus | Users, processes, data needs | Technology, structure, performance |
| Main tools | Interviews, DFDs, use case diagrams | UML, ERDs, architecture diagrams |
| Owner | Systems analyst, business analyst | Architect, senior engineer |
| Typical failure | Building the wrong thing | Building the right thing badly |
How the two phases fit together
In the waterfall model, analysis finishes before design begins, and each phase produces a signed document. In iterative and agile models, the two repeat every two to four weeks for a small slice of the system. A few requirements are analyzed, designed, built, and reviewed, and then the next slice begins. The boundary between the phases stays the same. The difference is the size of the slice.
Errors move in one direction. A requirement missed in analysis is absent from the design, absent from the code, and discovered by a user. Studies of software projects have long reported that a defect found after release costs many times more to repair than one found during requirements. Analysis is therefore the cheapest place to be careful.
Where this appears in interviews and courses
University courses titled "System Analysis and Design" teach the whole sequence, with DFDs and ERDs as the main diagrams. Software engineering interviews use the words differently. A system design interview compresses both phases into 45 minutes: the first 5 to 10 minutes are analysis, where the candidate gathers requirements, and the rest is design.
Key Takeaways
- Analysis defines the problem, design defines the solution. The requirements specification is the handover between them.
- Analysis outputs are about users and data. Use cases, DFDs, and the SRS.
- Design outputs are about structure and technology. Architecture diagrams, ERDs, API specifications, and class diagrams.
- Agile does not merge the phases. It shortens the slice that passes through both.
The design half, from requirements to a full architecture, is taught step by step in Grokking the System Design Interview.
For the building blocks that appear in every design document, such as databases, caches, and load balancers, see Grokking System Design Fundamentals.
For low-level design, the class-level part of the blueprint, see Grokking the Object Oriented Design Interview.
GET YOUR FREE
Coding Questions Catalog
$99
$197
$72
