Are you a software engineer interested in advancing in your career and getting an advantage in the job market? Learning system design can help you with both. By understanding this process for creating modern systems to satisfy real-world requirements, you’ll be better prepared to provide resilient and scalable solutions in your day-to-day work. Having system design skills in your toolkit will also help you progress in your field and move up in your organization.
System design has become essential to the software development process. That’s why it’s good to take a step back and analyze the big-picture impact of good design on the long-term efficiency, longevity, and success of software and information systems. System design and the requirements that it targets don’t exist in a vacuum. As a software engineer, it works to your advantage to know why certain requirements are being targeted, how they relate to the business goals of your organization, and how these decisions impact the overall user experience.
To better understand the many factors that contribute to a system’s design, and how information technology professionals respond when a system’s implementation runs into trouble, we need to talk about system analysis.
Today, we’ll be looking at system design and system analysis topics through a comparative lens. We’ll explore what these processes are, how they fit into the broader system development life cycle, and how to differentiate them.
Try one of our 400+ courses and learning paths: Grokking Modern System Design Interview for Engineers & Managers.
System analysis is a process for reviewing a technological system for troubleshooting, development, or improvement. Such a system might be a software implementation, like a system or application program. It’s important to consider system analysis as one phase in a larger process, the systems development life cycle (SDLC), which we’ll discuss in more detail later. In the system analysis phase, analysts are concerned with outlining a proposed solution to a defined problem. In doing so, they consider how viable and effective the product is or will be. System analysts consider the system’s overarching goals, which they can then break down into components or modules to enable individual analyses.
Two tasks commonly facilitate these analyses: feasibility studies and requirements engineering.
We’ll explore both of these tasks in greater detail later.
While completing these tasks, system analysts generally work toward a key output: a finalized system requirements specification (SRS), or system requirements document. When system analysts hand off this product, they provide software engineers with the principal input for the next phase of the life cycle: system design.
In software development, system design is the process of defining the architecture, interfaces, and data model for a system to satisfy the requirements outlined in the SRSs. At this stage, software engineers translate business requirements into technical specifications to build a new physical system or update an existing one. If the system is designed well, it will serve clients’ needs and, ultimately, fulfill business objectives.
As its name implies, system design is a process that should happen systematically. By considering a system’s infrastructure completely and in an orderly manner, from hardware and software to data and how it’s stored, you can help ensure that the final design has important characteristics like reliability, effectiveness, and maintainability.
This overview barely scratches the surface of system design by intention. We’ll continue to unpack the design process in the next section on the differences between system analysis and system design, but a short primer or thorough guide could also be helpful.
As sequential phases of the SDLC, system analysis and system design share a broader purpose: developing technological systems that serve customer and business needs. From there, a number of differences emerge between the two processes. We’ll discuss three of these differences now.
Here’s where understanding the bigger picture of the system development life cycle (SDLC) helps. The SDLC, also called the software development life cycle or the application development life cycle, is a multi-phase process for creating an information system. It covers the life of the system from planning, through launch, to assessment. A key concept in information technology, the SDLC encompasses a mix of software and hardware configurations. These can include systems consisting of only software, only hardware, or a combination of both.
The SDLC is not a methodology. It is a description of phases. There are, however, several methodologies or models that fit within the SDLC. Some well-known examples include Waterfall, Agile software development, and Rapid prototyping.
Depending on your source, you may find variations in the numbers and names of SDLC phases. But developing a system will usually involve the same major tasks, and one way this process breaks down into phases is as follows:
The SDLC phases are generally meant to be implemented in sequence, with the completion of one preceding the initiation of the next. This sequencing lets developers, engineers, and programmers concentrate on one phase at a time and simplifies the development process. Depending on the organization and methodology, at times, not every phase is carried out. At other times, the phases may overlap.
Regardless, one thing usually stands true: system analysis and system design are essential and sequential parts of the process. Since the goal of the SDLC is the creation of high-quality information systems supporting identified needs, it follows that system analysis comes before system design. After all, in order for system design to start fulfilling requirements, software engineers first need to know what those requirements are.
System analysis and system design divide their responsibilities in multiple ways. We’ve already discussed the importance of timing, and how requirements gathering needs to precede the technical solution’s design. In addition, system analysts and software engineers have different focuses for their deliverables, which we can label the “what” vs the “how” of system development.
As discussed earlier, system analysis is an early and fundamental phase in the SDLC. In the context of software engineering, system analysts review a technological system for various purposes, ultimately proposing a solution to a problem using a computer system. In other words, they identify what is required to serve the client and customer needs. After feasibility studies and requirements engineering, they record this information in a system requirements specification (SRS) document.
With a finished SRS, the process advances to system design, which amounts to a phase for determining how to satisfy requirements. To visualize the desired outcome, think of creating a unique combination of distinct components. To make this visualization more tangible, we’ll call these components building blocks, representing similarities shared across system design problems that have been extracted for easier reuse.
For our purposes, there are 16 building blocks of modern system design that you can draw from. To understand the utility of these building blocks, it can help to think of them as bricks, a kind of combinable raw material. Once you grasp what these building blocks do, you can use them to demonstrate how to create reliable, effective, and maintainable systems for virtually any design problem.
Another distinction to make between system analysis and system design is in terms of the work process. ]Two conventions are used in system analysis: feasibility studies and requirements engineering. Meanwhile, the complexity of system design prevents any single method from solving every problem, but engineers can use a variety of consistent procedures to solve problems systematically. We’ll discuss one reusable approach that can address a number of scenarios.
Recall that system analysis involves outlining a proposed solution to a defined problem. To gauge the suitability of potential solutions, system analysts turn to feasibility studies.
These studies typically involve the following steps:
This final step is mostly concerned with weighing three types of feasibility:
Additional types of feasibility may include social feasibility, management feasibility, legal feasibility, and time feasibility. But no matter how system analysts slice up feasibility, the expected outcome is the same: a determination of whether the proposed system for solving a defined problem can and should go ahead. When this analysis results in a green light, system analysts can work on requirements engineering.
In requirements engineering, also known as requirements analysis, analysts will define, document, and maintain requirements pertaining to the proposed system. In general, this process includes examining data about the system’s goals and objectives, such as:
Later, software engineers will look for specific coding solutions that align with these findings.
A major focus of requirements engineering is ensuring a thorough understanding of clients’ needs and expectations. Communication between the company producing the system and clients is key, and requirements engineering can include several activities to support alignment:
During feasibility studies and requirements engineering, systems analysts might use several kinds of tools. These can include flowcharts (of the organization, existing system, or proposed system architecture) and user interface (UI) mockups (to understand how end users interact with the system).
After determining the feasibility and fine-tuning requirements, system analysts produce the SRS. This document enables system design engineers to begin working on the design for the new or updated system.
Although no one-size-fits-all method exists for the design phase, the RESHADED approach offers engineers a flexible way to break down many problems. This approach articulates the steps for designing almost any system from scratch, whether you’re working on a client project or sitting for system design interviews. We’ll quickly look at what the acronym stands for.
The utility of the RESHADED approach is most apparent in its flexibility as a general guideline to solving system design problems. However, it’s not meant to solve every design problem, so don’t be afraid to be creative and resourceful when it comes to designing new solutions.
Try one of our 400+ courses and learning paths: Grokking Modern System Design Interview for Engineers & Managers.
At this point, you should have a good idea of how system analysis and system design fit into the software development process and how they differ. Even if your primary focus will be on system design in your career, it’s good to understand what happens beforehand and what systems analysts contribute to the overall SDLC.
If you’re a software engineer or aspiring to become one, we hope the discussion of system design has inspired you to learn more about this essential process. To help you master system design, we’ve created the course Grokking Modern System Design Interview for Engineers & Managers. This interactive course offers a modern perspective on designing complex systems using various components in a microservices architecture. You’ll learn all about the building blocks and RESHADED approach discussed in this article, and have opportunities to apply these concepts to real-world design problems.
Join a community of more than 1.4 million readers. A free, bi-monthly email with a roundup of Educative's top articles and coding tips.