The SPL evolution control is ensured by appropriate practices of changes management, including changes in requirements. These practices are part of the Evolution Management process (EM), thus it will not be considered in this process. However, this work presents the evolution context in RE and purposes some guidelines for it.

Evolution can occur by several concerns, such as new customer needs, regulation changes, technical progress, developers’ increased understanding of the product or domain, business pressure, opportunities and/or change in business goals. During the development of a product (member of the SPL), requirements often arise that are not in the scope of the SPL. Hence, the scope of the product line must be either expanded or product-specific requirements must be created.

Changes can impact different areas, such as business (e.g. price), system (e.g. functionality, quality attribute, technological constraints) and project (e.g. release, schedule). Changes also can conflict between them, so their decisions can need of negotiations among different stakeholders.

In DRS, some options of changes are:

• New feature, requirement or use case.
• New variant in variation point.
• New variation point.
• Turn a variant or variation point into an obsolete (remove).
• Turn a feature, requirement or use case into an obsolete.
• Mandatory feature changes into optional, and vice versa.
• Mandatory requirement changes into variant, and vice versa.
• Mandatory use case changes into variant, and vice versa.
• New cardinality, how many variants can be applied to the variation point.
• Turn a high priority into a low or medium. 
• Turn a medium priority into a high or low.
• Turn a low priority into a medium or high.
• New measurable value of the quality attribute.
• Detail use case or requirement.

For analyzing a change, it must be checked its impact in the SPL, which can be verified by traceability links that identify relationships between different assets.  The following items must be checked:

• Conflicts between new requirements (including features and use cases) and product line core assets (e.g. architecture and DRS). The core assets must be taken into account, analyzing the impact of new requirement in the product line.  For example, requirements which do not conform to the architecture can only be implemented with high effort and modification of the reuse infrastructure or even cannot be implemented at all.
• Priority conflicts. Changes in requirement can affect existing priorities.
• Conflict in quality attributes.  News constraints, functionalities or non-functional requirement can affect existing quality attributes.
• Changes can impact the dependency relationship (implication and exclusion) between objects of the DRS.
• News variations can affect existing variation points (e.g. cardinality, variability type).
• News requirements (including features and use cases) or variants can replace others.

After analyzing changes, conflict resolution can be necessary negotiation with different stakeholders. Accepted decisions must be submitted to EM.

Change Requests must have change description, justification about change, and cause type. The cause types can be:

• Incompleteness. Missing requirements, features or use cases or there any information missing from their individual descriptions (see Verification Checklist).
• Defect. It is with relation to inconsistency, ambiguity, traceability, standardization (see Verification Checklist).
• Improvement. Evolution over time.
  

Requirements management requires traceability information to be recorded (see Traceability Guideline).