System analysis vs system design: What every dev needs to know

What is system analysis?#

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.

• Feasibility studies focus on several measures of how likely a proposed solution is to solve the defined problem
• Requirements engineering determines what the proposed solution must accomplish

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.

What is 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.

• Reliable systems are resilient against errors, failures, and faults.
• Effective systems satisfy users’ needs and requirements set by the business.
• Maintainable systems prove flexible and simple to scale up or down. It’s generally easier to add new features to maintainable systems, as well.

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.

System analysis vs system design#

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.

1. System analysis precedes system design#

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:

1. Planning and preliminary analysis
2. System analysis
3. System design
4. Development
5. Testing and integration
6. Implementation
7. Operation and maintenance
8. Evaluation

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.

2. Focusing on “what” vs “how”#

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.

System analysis: The “what”#

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.

System design: The “how”#

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.

3. Completing different tasks#

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.

Feasibility studies#

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:

1. Identifying deficiencies in the existing system. This can begin with preparing a flowchart of the system, including its subsystems, and then examining it for vulnerabilities or points of failure.
2. Identifying the new system’s objectives, scope, and responsible users.
3. Preparing a flowchart of the proposed system.
4. Determining whether the proposal is a feasible solution for the new or upgraded system.

This final step is mostly concerned with weighing three types of feasibility:

• Technical feasibility: Noting the current hardware and software resources of the client or customer, and deciding whether the existing set-up can meet the technical requirements of the proposed system.
• Economic feasibility: Conducting a cost-benefit analysis of the proposed system and comparing the results with the project budget.
• Operational feasibility: Determining whether the system will work in the way that its users expect, considering the availability of the people who will be needed to develop and implement the system.

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.

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:

• How the proposed system would work at a high level
• What qualities or properties the proposed system must have to provide the expected results

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:

• Solicitation: Initially collecting the requirements from the client
• Analysis: Assessing the clients’ requirements in more detail
• Specification: Producing a formal document, sometimes called a requirements specification
• Validation or verification: Ensuring that the documented requirements are consistent and meet the client’s needs
• Management: Matching proposed system processes to requirements

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.

The RESHADED approach to system design#

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.

• Requirements: Gather all functional and non-functional requirements reflecting the needs of the client business or organization. Functional requirements represent core features, without which the system wouldn’t work as the end user expects, while non-functional requirements are essential considerations that don’t contribute to the core functionality.
• Estimation: Gauge the hardware and infrastructural resources needed to implement a system at scale.
• Storage schema (optional): Articulate a data model, with data flow diagrams, if relevant to the problem at hand. You’ll want to define the structure of the data, which tables to use, the types of fields in the tables, and the relationships between tables (optional). You might need this step when expecting highly normalized data, needing to store different parts of data in different formats, or facing performance and efficiency concerns around storage.
• High-level design: Select from the 16 building blocks we discussed earlier to fulfill certain functional requirements.
• APIs: Create interfaces that users can use to call various services within the system. Interfaces take the form of API calls and are typically a translation of functional requirements.
• Detailed design: Analyze and improve the high-level design, adding or replacing building blocks to meet non-functional requirements, then outlining these building blocks. This outline should identify how and why the components work, why they’re needed, and how they will be integrated.
• Evaluation: Compare the detailed design against the requirements. Justify tradeoffs and weigh the pros and cons of alternative designs. Identify areas for improvement and consider solutions to any overlooked issues.
• Distinctive component/feature: Discuss a unique feature added to your design to satisfy requirements. This discussion, which can follow various steps in the process, may be most relevant to system design interviews or presentations.

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.