Is the DRS complete, that is, does the checker know of any missing requirements, features or use cases or there any information missing from their individual descriptions? It also is relate to the following criteria:

• Is the DRS comprehensible, that is, can readers of the document understand what the features, requirements or use cases mean? Is granularity level right? Insufficient generality in the requirements leads to a design that is too brittle to deal with the change actually experienced over the lifetime of the product line Clements (2001). Abstract DRS comes with a high level of adaptation effort in product derivation. Thus, DRS should have a granularity level useful to use.
• Is the derived product requirements specification useful? Check whether DRS capture all domain variabilities accurately, whether derived DRS represents the problem that the corresponding SPL member solves.
  • Check if commonalities are missed.
  • Check if variabilities are missed.

Is the DRS consistent, that is, does the descriptions of different features, requirements and use cases include contradictions? The specification may contain inconsistencies among different work products of the DRS (additional complexity of variability modeling), for example inconsistency between features and requirements, or between requirements and use cases. Thus, consistency analysis restores the relationships among work products when one of those work products is altered. The following check items must be used:

• Contraction. The requirements A and not(A) are therefore part of the DRS of this SPL. The consistency check of this DRS would identify the contradiction between A and not(A) and would indicate that the DRS is inconsistent Lauenroth and Pohl (2008). A derived product cannot have A and not(A).
• Constraints. In each model, evaluating whether constraints have conflicts. For example, a mandatory object cannot require a variant object.
• Priorities. Are there conflicting priorities among requirements?

Is the DRS ambiguous, that is, are there different possible interpretations of the features, requirements and use cases? It must compare ambiguous DRS points with different stakeholders to investigate possible interpretations.

Is the DRS traceable, that is, are features, requirements, requirement variable part, use cases and requirement variable part unambiguously identified, do they include links to related features, requirements, requirement variable part, use cases and requirement variable part? The following check items must be used:

• Check if all use cases are related to functional requirements.
• Check if all composition relationships in the domain use cases and requirements are traceable. For example, whether a variation point is part of a use case then is necessary trace link between them.
• Check if all external associations (between objects of different work products of the DRS) are traceable. For example, which use cases are directly related with a requirement, and which requirements are directly related with a feature.
• Check if associated features are traceable.
• Check if all associated requirements are traceable.
• Check if all associated use cases are traceable.

Is the DRS conform to defined standards? Some additional check items are defined for this validation, as follows:

• Check if all work products are defined according to template.
• Check if all mandatory attributes are defined.
• Check if all variabilities are correctly represented.
  • All VPs have at least one variant.
  • Implication or exclusion rules are defined only from variant.
  • Binding time is defined only for variant.
  • All VPs with more that one variant have cardinality defined.
• Check if all non-functional requirements (quality attributes) are quantified.