What do you learn in system analysis design?

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.

What is taught in system analysis design?

What is the basic purpose of a course in systems analysis and design?

What are the three major objectives of systems analysis and design?

What is the main purpose of system analysis?