Create a description of the SPL domain, characterizing key technical objectives of included systems.

You may consider the following heuristics when performing this step:

•     Extend the one-sentence domain description to two pages, at most, of intuitive and not overly-restrictive text. Try to focus on the essential nature, scope, and variety of systems in the domain.
•     Characterize the type of problem that systems in the domain solve, and the external environment (.i.e, users, systems, devices) with which systems interact.
•   Describe the observable behavior that systems exhibit in solving the problem.
•      You might also establish significant constraints concerning how the systems operate in terms of performance, reliability, or distribution concerns
•   Describe the primary functions performed by every system in the domain and any important functions performed by only some systems. Maintain a black-box perspective when describing functional aspects of the system.

Create definitions of all significant terms used by domain experts in discussing the requirements or engineering of systems in the domain.

You may consider the following heuristics when performing this step:

•       Make definitions as precise as possible.
•      Create a structure that shows term specializations and relationships among similar concepts, as well as term composition. For instance, you can use a UML class diagram for represent this structure. This action will reveal missing terms that represent generalizations or specializations of known terms.
•       Maintain term definitions in alphabetical order for ease of reference. Provide cross-references to related terms.
•        Use definitions from standard glossaries where possible. Make note of such sources in each definition for future traceability.
•      Make sure that all terminology used in the Domain Synopsis is defined in the Glossary.

For each term in the Domain Glossary, determine whether the term indicates a commonality or a variability among systems in the domain. Create an assumption accordingly.

Compare the characteristics of existing systems to facilitate the identification of common features and variations.

Distinguish between system-generation and real-time variation when  developing  assumptions about variable  aspects of the domain. Treat a run-time variation that is characteristic of all  systems In the domain as a commonality.

Detail commonality assumptions for each characteristic specified in the Domain Synopsis that is shared by all systems in the domain.

Elaborate commonality assumptions to uncover specific variabilities assumptions associated with them. This will more precisely characterize a subset of the product family.

Detail and extend variability assumption for each characteristic specified in the Domain Synopsis that is not shared by all systems in the domain.

It is not sufficient to note only that some characteristic varies. You must establish how much flexibility the application engineer needs to characterize different systems adequately. Therefore, make variability assumptions precise by indicating the type of decision the application engineer must make to resolve the variability.

You may consider the following heuristics when performing this step:

•   Consider characteristics anticipated for future systems to identify additional variability assumptions.
•  Uncertainties that arise from analysis of customer requirements are often a good source of needed variability. These uncertainties are questions that customers, in the end, must resolve, but must be asked or be given additional information to be able to do so.
•    Look at the maintenance history of existing systems for an indication of how systems in the domain change over their life cycles. The histories of these systems indicate likely variabilities that characterize the evolution of individual systems.
•     Use information on technological advancements that could impact the development of future systems in the domain to identify potential variations.
•     Elaborate variability assumptions to find more specific commonality and subsequent variability assumptions that further distinguish members of the subfamily.

Describe  exclusionary assumptions to clarify a domain's boundary.

Do not enumerate every type of system or function that is outside the domain. Rather, exclude explicitly those functions or characteristics that a domain expert might incorrectly assume to be part of a system when reading the Domain Synopsis. Thus, you can answer the question of whether a particular system belongs within the domain more directly by checking the exclusions. Exclusions often result from a viability analysis of the domain.