Skip to main content

Identifying Architectural Characteristics from Requirements

What This Concept Is​

An architectural characteristic is a quality (from Cluster 2) that the architecture must deliberately support, because getting it wrong would shape the system's structure. "Identifying characteristics from requirements" is the craft of reading a messy stakeholder document and producing a short, defensible list of characteristics the architecture must optimize for.

The skill has three steps:

  1. Extract. Read the requirements and list every phrase that is a quality claim, explicit or implicit.
  2. Cluster. Group synonyms and near-duplicates. "Fast," "snappy," and "responsive" are probably one characteristic.
  3. Rank and justify. Pick the characteristics the architecture must actually optimize for, and write one sentence explaining why each is on the list.

Without step 3, every system ends up optimizing for 15 characteristics, which means optimizing for none.

Why It Matters Here​

Requirements documents are rarely written by people who know architectural vocabulary. They say "modern," "enterprise-grade," "world-class," "cloud-native." The architect's job is to turn that into a short list of concrete characteristics - and to defend it to the same stakeholders who wrote the fuzzy version.

This concept is the bridge between Cluster 2 (we know the qualities exist) and Cluster 3 Concept 8 (we will cap the list at three). Without the extraction craft, the top-3 rule has nothing to trim.

Concrete Example​

A one-page brief for a streaming video platform lands on your desk. Excerpts:

"We need to support millions of concurrent viewers. The product team wants to ship new features fast. The business is concerned about cloud cost; we're currently spending too much on video delivery. Security is important; we had a leak of creator content last quarter. We want to expand internationally soon, so the system should be usable in multiple regions."

Extraction (step 1):

  • "millions of concurrent viewers" -> scalability
  • "ship new features fast" -> modifiability, deployability
  • "cloud cost... too much" -> cost efficiency (an architectural characteristic in the Fundamentals taxonomy)
  • "security is important... leak" -> confidentiality
  • "multiple regions" -> multi-region availability, possibly data locality

Clustering (step 2): Ship-fast spans modifiability and deployability; treat them as one for now. Confidentiality and "leak prevention" cluster. Multi-region is one goal.

Ranking and justification (step 3):

  1. Scalability - the business is defined by high concurrency; losing it is an existential product failure.
  2. Cost efficiency - explicit current pressure; an architectural decision (CDN, chunked delivery, caching tiers) is the main lever.
  3. Confidentiality - recent incident makes this urgent and non-negotiable.

Modifiability and multi-region availability are important but pushed below the line for now - you will explicitly name them as "below top 3" so nobody forgets. Your stakeholder conversation is now about a defensible list of three.

Same exercise on the IoT platform's brief would likely produce availability, reliability, and modifiability as the top three.

Common Confusion / Misconception​

"Characteristics are in the requirements document." Usually not. Characteristics are implied by the requirements; you have to extract them.

"Every adjective is a characteristic." No. "Modern" is not a characteristic. It is a feeling about the system. Translate or discard.

"Characteristics are objective." They are judgement calls, grounded in evidence. Two architects will rank differently on the same brief. What makes a ranking defensible is the written justification, not the rank itself.

"The business folks should pick the characteristics." They should pick the business goals. The architect translates goals into characteristics. Asking a CFO to choose between "scalability" and "modifiability" is the wrong question.

How To Use It​

A practical routine when a requirements document or meeting produces new input:

  1. Read the document once end-to-end.
  2. Highlight every quality-adjacent phrase. Do not filter yet.
  3. For each phrase, write the candidate characteristic and the quote that triggered it.
  4. Cluster synonyms.
  5. Rank by business impact × architectural leverage (both high = top).
  6. Write one sentence of justification per characteristic on the short list.
  7. Name 2-3 characteristics explicitly not on the list, so the team knows they are recognized but deprioritized.

The last step is often the most useful. "We know modifiability matters, but we are prioritizing scalability and cost this quarter" is a design statement, not an omission.

Check Yourself​

  1. Why does extraction have to happen before ranking? What goes wrong if you rank as you read?
  2. Give one example where two characteristics look synonymous but are actually different (e.g., "scalability" vs "elasticity").
  3. What is the purpose of listing characteristics below the top-3 line?

Mini Drill or Application​

Find a real or realistic one-page requirements document (a PRD, a ticket, a project brief). Apply the 7-step routine and produce:

  • the full extracted candidate list
  • the clustered list
  • the ranked top-3 with one-sentence justifications each
  • a "below the line" list of 2-3 characteristics acknowledged but deprioritized

Hand the output to someone else and ask if they can defend it back to you. If they can, the justifications are doing their job.

Read This Only If Stuck​