Skip to content

Domain analysis

A software-engineering process that compares related systems and their business context to model commonality, variation, and reusable assets for a product family or domain.

Version
v1 · 2026-09-28 · History
Domain-specific #
9042
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomains
Software Engineering, Software Product Lines → Computer Science & Software Engineering

Core Idea

Domain analysis is comparative engineering before it is modeling. Analysts declare a software and business domain, inspect several related systems and stakeholder practices, and identify which concepts, capabilities, and constraints recur and which vary. The output is a map of a product family, not a detailed specification of one product.

The findings become reusable artifacts: feature and facet tables, domain-specific languages, object or data models, and generic architectures. These guide later domain engineering and application construction. Because a legacy corpus mixes durable business structure with accidental implementation, the analysis must justify both its domain boundary and each claimed commonality or variation point.

How would you explain it like I'm…

Look at Many, Build Many

Before building a new toy, you could look at lots of toys that are alike, like many kinds of toy cars. You notice what all of them have, like wheels, and what is different, like colors or sizes. Then you make a plan that helps you build a whole family of toy cars, not just one.

Same-and-Different Map

Domain Analysis is what software builders do before making a whole family of related programs. They look at several existing programs and talk to the people who use them, all in the same area, like school libraries. They list the things every program needs and the things that change from one to another. That list becomes reusable building material, like templates and shared plans, for making future programs. They also have to explain why they drew the line around the area where they did, and why each shared or different thing is real and not just an accident of how an old program was built.

Product-Family Comparison

Domain Analysis is comparative study done before designing software for a whole area of business, such as airline booking. Analysts pick a domain, examine several related systems and how stakeholders actually work, and sort features into ones that recur (commonalities) and ones that differ (variation points). The result is a map of a product family rather than a detailed spec for one product. That map becomes reusable artifacts like feature tables, data models, domain-specific languages and generic architectures. Because old systems mix real business structure with accidental coding choices, the analysts must justify both where the domain's boundary sits and each commonality or variation they claim.

 

Domain analysis is comparative engineering done before modeling. Analysts declare a software and business domain, examine several related systems and stakeholder practices, and identify which concepts, capabilities and constraints recur across them and which vary. Its output is a map of a product family, not a detailed specification of any single product. The findings are packaged as reusable artifacts: feature and facet tables, domain-specific languages, object or data models, and generic architectures. Those artifacts then guide domain engineering and the construction of individual applications. A key difficulty is that a legacy corpus blends durable business structure with accidental implementation choices. So a sound analysis must justify both the boundary it draws around the domain and every commonality or variation point it claims.

Structural Signature

Sig role-phrases:

  • domain scope — sets which systems, stakeholders, and business concerns belong in the comparison It is essential. Counterfactual: Without a boundary, commonality is arbitrary and variation unbounded.
  • related-system corpus — provides concrete products and practices from which patterns are elicited It is essential. Counterfactual: Analyzing one system alone cannot establish product-line commonality.
  • commonality model — records stable capabilities, concepts, and architectural commitments It is essential. Counterfactual: Without common features there is no reusable domain core.
  • variation model — records optional, alternative, and constrained differences among systems It is essential. Counterfactual: Ignoring variation converts a family analysis into one reference design.
  • domain artifacts — externalize findings as features, languages, models, or generic architectures It is essential. Counterfactual: Unrecorded insight cannot systematically guide reuse.
  • reuse decision — connects the model to later architecture and application implementation It is characteristic. Counterfactual: A taxonomy without downstream engineering use falls short of the method's purpose.

What It Is Not

  • It is not requirements elicitation for one software project.
  • It is not a generic business-domain description without comparison of software systems.
  • It is not domain engineering as a whole; it is an initial analytic phase that informs later design and implementation.
  • It is not reuse by copying code without an explicit model of invariants and variation.
  • Closest near-miss. Domain modeling is a near neighbor and can be an output; domain analysis additionally includes comparative elicitation and reuse-oriented scoping.

Scope of Application

  • Software product lines. Feature models organize common capabilities, options, alternatives, and constraints.
  • Domain-specific languages. Analysis identifies vocabulary and operations stable enough to encode.
  • Reference architectures. Recurring components and interfaces become a generic architectural basis.
  • Legacy modernization. Several existing systems reveal domain knowledge while implementation accidents are filtered out.

Clarity

State the domain boundary, systems sampled, stakeholder sources, common elements, variation types, constraints, and artifact produced. 'Domain' must not drift between an industry, a software family, and one organization's application. Each reusable claim should be traceable to evidence beyond a single implementation.

Manages Complexity

By organizing many systems into a commonality–variability model, domain analysis replaces repeated discovery with a reusable knowledge base. That compression reduces product-by-product effort but creates governance obligations: variants evolve, features interact, and the sampled corpus may be biased. The model must therefore remain revisable rather than becoming an unquestioned template.

Abstract Reasoning

  1. Define the business and software boundary and the reuse objective.
  2. Select related systems, documents, and stakeholders that represent meaningful variation.
  3. Elicit recurring concepts, capabilities, constraints, and terminology.
  4. Separate mandatory commonality from optional, alternative, and conditional variation.
  5. Represent findings in features, models, languages, or architecture suited to downstream use.
  6. Validate the model against systems not used to formulate it and revise unsupported generalizations.

Knowledge Transfer

Domain analysis transfers among software product families when multiple related systems and a reuse objective are present. A literature review called 'domain analysis' in information science is a different disciplinary use unless it performs this software commonality–variability process. The portable cargo is comparative extraction of reusable invariants and controlled variation; the output notation may change.

Examples

Applied / In Practice

An analysis of several payment platforms identifies shared authorization and settlement features plus country-specific regulatory variants.

Mapped back: family extraction → The corpus, common core, variable rules, and constraints become a feature model and generic architecture..

Applied / In Practice

Recurring concepts and operations in industrial controllers are captured in a domain-specific language.

Mapped back: artifact → The language externalizes reusable domain semantics rather than copying one controller..

Applied / In Practice

A team models entities and workflows for a single hospital scheduling application.

Mapped back: boundary → Useful domain knowledge is produced, but no related-system comparison establishes commonality and variation..

Structural Tensions

T1 — Stable Reuse Core versus Necessary Variability. Overgeneralization makes assets vague, while overspecialization reproduces each product separately.

Diagnostic: Trace every proposed invariant and variation point to multiple systems and stakeholder needs.

T2 — Business Vocabulary versus Implementation Legacy. Existing systems reveal practice but may encode accidents that should not become domain rules.

Diagnostic: Separate business constraints from platform-specific conventions before freezing the model.

Structural–Framed Character

The method is structural in its comparative workflow but framed by chosen scope and business purpose. No algorithm determines the correct domain boundary, and stakeholder judgments shape what counts as common or variable. Explicit traceability keeps those decisions reviewable.

Structural Core vs. Domain Accent

The skeleton is sample comparison, invariant extraction, variation modeling, and reuse. Software engineering supplies product lines, features, architectures, DSLs, and implementation assets. Removing those engineering aims yields broader domain inquiry rather than this method.

This entry under conditions is a kind of Analytical Method.

  • Approved root. The frozen graph leaves the method unparented pending later DAG densification.

  • Related — domain engineering and model-driven engineering. Domain analysis initiates the former and can supply models used by the latter, but neither is identical to it.

Relationships to Other Abstractions

Local relationship map for Domain analysisParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Domain analysisDOMAINDomain-specific abstraction: Analytical Method — is a kind of, conditionalAnalyticalMethodDOMAIN

Current abstraction Domain analysis Domain-specific

Parents (1) — more general patterns this builds on

  • Domain analysis is a kind of, conditional Analytical Method Domain-specific

    Supported for systematic analytical method senses, not every high-level domain study.

    Condition / exception Supported for systematic analytical method senses, not every high-level domain study.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Domain analysis sits in a crowded region of the domain-specific corpus (39th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Organizational Patterns & Management Concepts (29 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With

  • Requirements analysis. Tell: Targets the needs of a particular system rather than family-wide commonality and variation.
  • Domain modeling. Tell: Produces conceptual representations and can be one artifact of the broader analysis process.
  • Domain engineering. Tell: Includes implementation and maintenance of reusable assets beyond the initial analysis.
  • Information-science domain analysis. Tell: A distinct use concerning knowledge domains and discourse communities.

References

  • Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/Domain_analysis (revision 1328178894).
  • Preserved source candidate: http://www.bayfronttechnologies.com/l02draco.htm#diss80
  • Preserved source candidate: http://g.oswego.edu/dl/oosdw3/ch13.html
  • Preserved source candidate: https://web.archive.org/web/20160303214746/http://g.oswego.edu/dl/oosdw3/ch13.html
  • Preserved source candidate: http://www.iva.dk/bh/core%20concepts%20in%20lis/articles%20a-z/Domain%20analysis.htm
  • Preserved source candidate: https://web.archive.org/web/20111105172824/http://www.iva.dk/bh/core%20concepts%20in%20lis/articles%20a-z/Domain%20analysis.htm
  • Preserved source candidate: http://wfrakes.wordpress.com/2008/07/24/dare-bibliography/
  • Preserved source candidate: https://web.archive.org/web/20110810170108/http://208.29.54.207:8080/dareonline/
  • Preserved source candidate: http://www.sei.cmu.edu/reports/90tr021.pdf

The frozen Wikipedia revision is discovery provenance. The retained source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; a thin authority surface is recorded as a nonblocking source-strengthening repair rather than concealed.