CHAN-BLOG.DEV
Back to blog
System Design4 min read2025년 12월 3일

Review: Software Architecture & Design of Modern Large Scale Systems (2)

Course notes on gathering requirements before design: actors, use cases, user flows, and the quality attributes that shape the system.

Annyeong!

This post series is a note from things that I’ve learned from the Udemy course: Software Architecture & Design of Modern Large Scale Systems.

Requirement Gathering Steps

When gathering information before we actually design the system, we need to gather sufficient information by following below steps:

  1. Identify all the actors / users in the system.
  2. Capture & describe all the possible use cases / scenarios (listing use cases).
  3. Describe user flow — expand each use case through flow of events. Each event contians action and data.

Let’s take an exmaple of the hitchhiking service. The initial idea of this service is to allow people to join drivers on a route, who are willing to take passengers for a fee.

  1. The actors in this service will be driver and rider.
  2. Use cases are as below:
  3. Rider first time registration
  4. Driver registration
  5. Rider login
  6. Driver login
  7. Successful match and ride
  8. Unsucessful ride(match)
  9. We can represent the user flow using a Sequence Diagram.

Sequence Diagram

Unified Modeling Language (UML) Unified Modeling Language (UML)

Sequence Diagram is a diagram that represents interactions between actors and objects. This is a type of a Unified Modeling Language (UML), which is a standard for visualizing system design.

In practice, UML diagrams are used mostly for software design. While UML isn ot strictly followed in the industry, the Seqeunce Diagrams are frequently used to represent interactions between entities.

System Quality Attributes Requirements

Systems are frequently redesigned NOT because of the functional requirements, but they change because of the system as it stands:

  • It is not fast enough
  • It doesn’t scale efficiently
  • It is slow to develop
  • It is hard to maintain
  • It is not secure enough

Quality attributes are non-functional requirements. More specifically, they are qualities of the functional requirements. In other words, the quality attributes doesn’t say what the system does, but instead they provide a quality measure on how well the system performs on a particular dimension.

The system quality attributes have direct correlation with the architecture of the system. Let’s take an example of an online store where users can look for products based on some search keywords.

“when a user clicks on a search button after they typed in a particular search keywords, the user will be provided with a list of products that closely match the search keyword within at most a 100 milliseconds.”

  • The functional requirement here is that the action that the system takes when the user clicks the search button.
  • The quality attribute in this case is that the performance dimension describes how fast this action is to be performed (it should be performed within at most a 100 milliseconds).

Important Considerations of Quality Attributes

1. Quality attributes need to be measurable, and testable. If we cannot prove that the system satisfied the required quality attributes, we don’t know if the system performs well or poorly.

  1. There’s no silver bullet — no single software architecture can provide all the quality attributes. Certain quality attributes contradict one another. So, some combinations of quality attributes are very hard or impossible to achieve. In this case, we need to make the right tradeoff to have a higher chance of success of the system.
  • The very intuitive example here is the contradict of the performance and security. The more secure a system is, the slower the performance will be.
  1. Feasibility is important. We need to make sure that the system is capable of delivering with the client asking for. It sounds pretty obvious — but keep in mind that some clinets may ask for something that is either technically impossible and/or prohibitively expensive to implement. It is our (as a software architect) job to call that our early on the process.
  • Let’s think about implementing the 100% availability of a system. This basically means that the system will never fail on any reasons. This means that it should have full protection against attackers and always have a stable network bandwidth, disaster-tolerant, etc. I believe implementing 100% availability is impossible.

To add some notes, there are some ways to measure & test the quality attributes using Datadog :)

  • Service Level Objectives (SLOs) are the key tool to measure your service in any kind of dimensions. This provides a framework for defining clear targets around applications performance, which ultimately help teams provide a consistent customer experience, balance feature development with platform stability, and more. For more information, you can check out the following link: https://docs.datadoghq.com/service_management/service_level_objectives/
  • Synthetic Testing and Monitoring allows you to test the system in application level. This observes how the systems and applications are performing using simulated requrests and actions from around the globe, making it easy to test the performance and/or availability. For more information, you can check out the following link: https://docs.datadoghq.com/synthetics/

Service Level Objectives

Synthetic Testing and Monitoring

That’s it for today! See you in the next post ;)

Topics

system-designrequirements