The step Classify is responsible for list all elicited requirements and group them in functional and non-functional category. Functional requirements describe what the system should do and non-functional requirements place constraints on how these functional requirements are implemented Sommerville (2005). For example, a functional requirement might state that a system must provide some facility for authenticating the identification of a system user; a non-functional requirement might state that the authentication process should be completed in four second or less. However, it is not always as simple as this. A requirement could be interpreted as functional or non-functional according to the above definition. High-level non-functional requirements are often decomposed into functional system requirements Sommerville (2005).

The non-functional requirement can be quality attribute or constraints, such as are shown in following Table.

* These are examples, other quality attributes can be found.

After classification, the requirements are detailed. The steps Classify and Detail can be performed iteratively until the domain requirements become complete.

In this step the requirements are described and their variabilities are represented. There are mandatory and variant requirements. A mandatory requirement is common for all products in the SPL. A variant requirement is not common for all products in the SPL, it there is in some products. The variability also can be found in requirement part, i.e. a text fragment can be a variant.  For each requirement are defined the following attributes:

• Id. Unique identifier, which can be standardized according to requirement type. Thus, whether requirement is functional, its identifier can be FRX. Whether requirement is non-functional, its identifier can be NFRX. In both cases, X is a unique number for identification.Type. It can be Functional or Non-Functional.
• Name. The name that better represent the requirement.
• Variability Type. Mandatory or Variant.
• Binding time. It is defined when variability type is variant. It decides when variant is bound to the member of the SPL. The variants will be bound at certain phase of the product life cycle, such as scoping time (when select the requirements of the product), run time, compile time, installation time and load time. The scoping time is the default value, so whether it section is not defined, the default value is assumed.
• Priority. The priorities are relative to core asset implementation order. They can be High, Medium or Low.
• Rationale. It defines reasons for requirement existence.
• Description. Description about requirement that can have variant text fragment that represent variation point.
• Implication. It presents dependency relationship between requirement and another requirement object (requirement or requirement part). It occurs when a requirement requires another object.
• Exclusion. It means that a requirement cannot exist in presence of another object.  

Wherever possible, quality attributes should be quantified in a way which can be objectively measured and assure the precision of the results. The following metrics are presented as examples on [Sommerville2005]:

• Usability: i) Time taken to learn 75% of user facilities and ii) Average number of errors made by users in a given time period.
• Performance: i) Number of transactions to be processed per second and ii) Response time to user input.
• Reliability: i) Mean time to failure and ii) Rate of occurrence of failure.
• Availability: i) Probability of failure on demand.

The requirement variability type can be defined from feature model whether requirement is mapped to feature and this feature represents directly the requirement or it encompasses the requirement. When a feature encompasses requirements, their variabilities types are the same. In this case, whether feature variability type is Mandatory then requirement variability type is Mandatory. Whether feature variability type is Optional, Alternative or OR, then the requirement variability type is Variant. The requirement variability type can be defined from feature model whether requirement is mapped to feature and this feature represents directly the requirement or it encompasses the requirement. When a feature encompasses requirements, their variabilities types are the same. In this case, whether feature variability type is Mandatory then requirement variability type is Mandatory. Whether feature variability type is Optional, Alternative or OR, then the requirement variability type is Variant.

When requirement is not mapped to feature then its variability type must be identified in elicitation. In this case, it must identify whether all products require or does not require the requirement. The SPL requirements priorities must be defined by decision-maker (e.g. customer, executive and SPL owner). However, it is necessary that SPL development team support this work for assure consistent priorities, analyzing dependencies among requirements and their reuse potential. Potential end-users and domain expert also can have influence in the priorities decisions. Therefore, stakeholders with different goals and needs can define conflicting priorities, so it is necessary negotiate conflict among priorities.

 These priorities affect directly the core assets implementation order and the products releases plan. Thus, they should be carefully analyzed according to following types:

• High. This requirement is absolutely needed. The SPL will not enable the derivation of a useful product without this requirement.
• Medium. This requirement is important to the stakeholder and will provide a key driver to convince stakeholders of usefulness of the derived products. Including this requirement into the final system will provide verifiable benefits to the stakeholder.
• Low. This requirement clearly provides additional value to the stakeholder, but it can be omitted without affecting the main uses of the derived products.

The priorities can be influenced by several factors, such as:

• Business strategies. The decision-makers can define requirement priority according to its cost, time to market, value and competitively. These factors can characterize also the priorities among products. For example, the release of the first product can be based in the high amount of core assets, high business value, and time to market not so big.
• Variability type. For optimizing the SPL reuse potential, it is best that mandatory requirements are implemented before variant requirements. However, in some situations can have variant requirement with major priority than mandatory requirement. For example, whether a variant requirement presents a market differential for a product that need be launch quicker. Or, whether a mandatory requirement does not present differential for the products, its priority is low.
• Design constraints.  Relationship of dependency among requirements can affect their priorities.

Variability found in requirement text fragment is represented by Variation Point (VP). A requirement can have 0 to n VPs. For each VP should be identified the following attributes:

• Id. All VPs have unique identifier to assure traceability between objects. The identifier can be standardized as Y.VPX, where Y is the identifier of the requirement that VP is part, and X represents a sequential number of the VPs in the requirement (e.g. FR1.VP1).  
• Description. Characterization about VP. It can inform the basis to make choice between the variants. It is optional.
• Cardinality. Cardinality indicates how many variants can be applied to the variation point and are given by pairs [min, max]. This attribute is required when there are two or more variants. Some examples of cardinality are:

[1, 1]: Exactly one variant should be selected for a variation point. The variants are mutually exclusive.
[1, n] At least one variant should be selected for a variation point. The variants are not mutually exclusive.
[0, 1] One variant may or may not be selected for a variation point.
[0, n] Zero or more variants may be selected for a variation point.

• Variant. A variation point can have 1 to n variants. These variants are options of the variation point. Each variant also have a unique identifier that must be standardized as Y.X.VZ, where Y and X are respectively the identifiers of the requirement and VP that the variant is part, and Z represents a sequential number of the variant in the VP (e.g. FR1.VP1.V1).
• Binding time. It decides when variants are bound to the member of the SPL. The scoping time is the default value, so whether it section is not defined, the default value is assumed.
• Implication. It presents dependency relationship between variations. It occurs when a variation (variation point or variant) requires another variation. More than one implication should be separated by commas
• Exclusion. It means that a variation cannot exist in presence of another. More than one exclusion should be separated by commas.
  

Dependencies can occur between different objects, such as requirement-requirement (e.g. NFR1 in Requirements Example),  requirement-VP, VP-VP (e.g. FR1 in Requirements Example), VP-variant (e.g. FR2 in Requirements Example), variant-variant and requirement-variant. However, a mandatory object cannot depend of a variant object. 

Links must be established to explicitly interrelationships among information in the different work product that are direct linked with requirements (see Traceability Guideline). 

After requirements description is necessary to verify the specification to assure consistency, accuracy and completeness. During the verification process, if necessary, a set of requirements may be added, deleted, or refined. Changes in feature model also can occur.