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.

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. Inclusion test: A positive case compares multiple related systems within a declared domain and produces explicit commonality, variability, context, and reuse artifacts. Exclusion test: Requirements analysis for one application is not domain analysis merely because it discusses a business domain. Nearest boundary: Domain modeling is a near neighbor and can be an output; domain analysis additionally includes comparative elicitation and reuse-oriented scoping. Exit condition: The process exits when it no longer distinguishes family-wide invariants from variation across related systems. Common misclassifications: 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. Nearest named distinctions: Requirements analysis: Targets the needs of a particular system rather than family-wide commonality and variation. Domain modeling: Produces conceptual representations and can be one artifact of the broader analysis process. Domain engineering: Includes implementation and maintenance of reusable assets beyond the initial analysis. Information-science domain analysis: A distinct use concerning knowledge domains and discourse communities.

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¶

Define the business and software boundary and the reuse objective.
Select related systems, documents, and stakeholders that represent meaningful variation.
Elicit recurring concepts, capabilities, constraints, and terminology.
Separate mandatory commonality from optional, alternative, and conditional variation.
Represent findings in features, models, languages, or architecture suited to downstream use.
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.

Relationships to Other Abstractions¶

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

Domain analysis → Analytical Method

Neighborhood in Abstraction Space¶

Domain analysis sits in a crowded region of the domain-specific corpus (39^th 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