Turning Requirements into Effective Software Architecture Designs

Architecture design requirement analysis : the main purpose is to clarify which problems the architecture should solve, starting with researching the stakeholders' demands.

If an architecture department builds frameworks, components, or systems that no one uses, designing architecture for the sake of promotion should be abandoned.

Architecture design detached from business is merely rogue behavior.

1. Where does the requirement analysis for architecture design come from

The preliminary work of requirement analysis is vision description and vision analysis, i.e., the early investigation of needs.

From a software process perspective, requirement analysis is a bridging stage—"upstream" the vision, "downstream" the design. The work includes three aspects:

Requirement capture : understanding and communication.

Requirement analysis : what to do, what problems exist.

System analysis : why, how to implement.

These three are not independent; they occur concurrently and interactively.

Requirement capture : collect requirements from various sources and understand them. A typical tool is a "requirement collection card" containing description, proposer, recorder, type, etc.

Requirement analysis : the raw requirements captured are refined, organized, summarized, and validated into clear specifications. For example, a product manager may say the system is unstable and needs a refactored architecture for stability. This vision must be turned into a concrete requirement, such as achieving 99.99% feasibility and defining the necessary work.

2. Requirement classification: structuring requirements

Collecting requirements is numerous and varied; we need to understand and organize them. Using a two‑dimensional demand view expands the traditional "list of requirements" perspective, enhancing vision and thinking.

Two‑dimensional demand view

First, requirements are hierarchical :

1. Organization‑level requirements

2. User‑level requirements

3. Development‑level requirements

Second, requirements must be considered from different aspects . They can be classified into three categories:

1) Functional requirements: direct objectives at each level, what the system should do, which features are needed.

2) Quality requirements: runtime quality, design quality, user quality, system quality.

3) Constraint requirements: business environment factors, usage environment factors, build environment factors, technical environment factors.

ADMEMS matrix , which can be used as a tool for requirement sorting and review:

3. Key points for transforming requirements into design

Different requirements (functional, quality, constraint) affect architecture principles; they are the code for converting requirements into design.

Functional requirements, quality attributes, and constraints together determine the architecture. Proper handling of these three determines the success of architecture design.

Function: reflects the responsibility collaboration chain—what functions exist and how they cooperate.

Quality: drives the improvement of the architecture.

Constraint: shows that design is not free.

Quality attributes and constraints are non‑functional requirements and crucial "architecture decision factors". Quality attributes represent the overall quality of the software system, influencing most functions.

Constraint requirements are either mandatory limits in architecture design or, after analysis, transformed into quality or functional requirements. Because constraint analysis is often overlooked, derived constraints become "missing requirements", leading to architecture deviation or failure.

4. Prioritizing requirements

The essence of architecture design is to solve business problems. Architecture design is not about covering everything; it targets identified issues, so understanding the most critical problems is essential.

For example, if system complexity stems from tangled business logic and severe coupling, designing an architecture capable of 50,000 TPS is meaningless.

Problems usually arise to satisfy "high availability", "high performance", and "scalability". Even if leadership demands all three, they must be prioritized.

Typical issues in an online system include low runtime efficiency, complex upgrades prone to errors, low development efficiency, and frequent minor problems that are hard to locate.

Solution:

1. List the main complexity problems.

2. Prioritize based on business, technical, and team considerations.

3. Address the most critical complexity issues first.