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, several differences emerge between the two processes. We'll discuss three of these differences now.
System analysis precedes system design
Here's where understanding the bigger picture of the system development life cycle 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 system's life from planning through launch to assessment. The SDLC is a critical concept in information technology encompassing software and hardware configurations. These can include systems comprising only software, hardware, or a combination.The SDLC is not a methodology. 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. The following are some of the steps necessary in developing a system, which typically include the same fundamental tasks:
Planning and preliminary analysis
System analysis
System design
Development
Testing and integration
Implementation
Operation and maintenance
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, only some phases are sometimes 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 SDLC's goal is to create high-quality information systems supporting identified needs, system analysis follows before system design. After all, for system design to start fulfilling requirements, software engineers must first know what those requirements are.
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 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 clients' and customers' needs. After feasibility studies and requirements engineering, they record this information in a system requirements specification document.
System design: The "how"
System design, a phase for figuring out how to meet requirements, follows a complete SRS. Imagine the final product as a one-of-a-kind blend of different elements. These components, which stand for extracted similarities in system design issues for easier reuse, will be referred to as building blocks to make this visualization more concrete.In this case, we'll use the sixteen tenets of contemporary system design. Imagine these components as bricks, a combinable raw material, and you'll know their value well. Using these building blocks to demonstrate creating something is easy once you understand their purpose. Reliable, effective, and maintainable systems for virtually any design problem.
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 several scenarios.
Feasibility studies
Recall that system analysis involves outlining a proposed solution to a defined problem. System analysts turn to feasibility studies to gauge the suitability of potential solutions.These studies typically involve the following steps:
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.
Identifying the new system's objectives, scope, and responsible users.
Preparing a flowchart of the proposed system.
Determining whether the proposal is feasible for the new or upgraded system.
This final step is concerned mainly with weighing three types of feasibility:
Technical feasibility: Noting the client or customer's current hardware and software resources 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 how its users expect, considering the availability of the people 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 analysis slice up feasibility, determining whether the proposed system for solving a defined problem can and should go ahead. System analysts can work on requirements engineering when this analysis results in a green light.
📞: Schedule a call today for more information!