Turning Requirements into Effective Architecture Designs: A Practical Guide

1. Where Requirement Analysis Comes From The first step is to define the problem the architecture must solve by researching the stakeholders' needs. If the architecture team builds unused frameworks or components, the effort is wasted; architecture driven solely by promotion or personal advancement is ineffective.

Requirement analysis bridges vision and design. It consists of three interrelated activities:

Requirement Capture : Collect and understand needs from various sources, often using a "requirement capture card" that records description, proposer, recorder, type, etc.

Requirement Analysis : Transform raw needs into clear, measurable specifications. For example, a product manager may say the system is unstable and needs a redesign; the analyst must turn this into a concrete goal such as achieving 99.99% stability and define the work required.

System Analysis : Identify root causes and determine how to address them.

2. Structuring Requirements – Two‑Dimensional View

Requirements are layered and must be considered from multiple perspectives:

Organizational‑level needs

User‑level needs

Developer‑level needs

They can also be classified into three categories:

Functional Requirements : What the system must do, specific features and functions.

Quality Requirements : Runtime quality, design quality, user experience, and overall system quality.

Constraint Requirements : Business, usage, build, and technical environment constraints.

ADMEMS Matrix can be used as a tool for requirement sorting and review.

3. Key Factors When Translating Requirements to Design

Functional, quality, and constraint requirements together dictate architectural decisions. Proper grasp of these three aspects determines the success of the design.

Functional : Defines the responsibility chain and how components collaborate.

Quality : Drives the architecture’s refinement and improvement.

Constraint : Limits design freedom and must be respected.

Both quality attributes and constraints are non‑functional requirements that heavily influence architectural choices. Constraints often generate derived requirements that are easily overlooked, leading to design gaps.

4. Prioritizing Requirements

The purpose of architecture is to solve business problems, not to address every possible issue. Identify the most critical problems first. For example, if system complexity stems from tangled business logic and high coupling, aiming for a 50,000 TPS performance target is meaningless without first simplifying the architecture.

Typical pain points include low runtime efficiency, difficult upgrades, high error rates, low development productivity, and frequent minor bugs that are hard to locate.

Solution Steps

List the major sources of complexity.

Rank them based on business impact, technical difficulty, and team capacity.

Address the highest‑priority issues first.

By following this structured approach, architects can ensure that their designs are aligned with real business needs and deliver measurable value.