Table 4 Heuristics for the verification of the concern identification process

Description: each software requirement is related to its main concern.

Justification: each software requirement must be related to a main concern, because each requirement should be written with one purpose.

Description: if there is a “positive contribution” relationship “rel” that binds the concerns “A” (source) and “B” (target) and “B” was found in the software requirements, then “A” or any of its sub-concerns was identified too.

Justification: the fact that “A” contributes positively to “B” provides evidences that if “B” was identified, “A” (or any of its sub-concerns) should also be. However, this is not an error. More than one concern can contribute positively to “B” and the software engineer could choose just one option. For example, “Performance” and “Standardization” contribute positively to “Usability,” but only one of them may be addressed in the software. However, it is necessary to generate a warning occurrence, since it may indicate concerns that the software engineer had not previously considered. This is especially important in cases where implicit concerns in the software exist.

Description: if there is a “dependency” relationship “rel” that binds the concerns “A” (source) and “B” (target) and “A” was found in the software requirements, then “B” or any of its sub-concerns was identified too.

Justification: the fact that “A” depends on “B” means that for that “A” exists, “B” (or any of its sub-concerns) must exist too. For example, the catalog of Fig. 3 presents a dependency relationship between “Payment” and “Transaction.” Then, for that “Payment” exists, “Transaction” must exist too.

Description: if a non-functional concern “A” was found in the software requirements, then “A” (or any of its sub-concerns) is related to one or more functional requirements.

Justification: it is well known in the scientific community that non-functional concerns commonly presents a crosscutting behavior, such as “Logging,” “Persistence,” “Distribution,” “Security,” among others [8]. Thus, at the end of the concern identification process, if there are non-functional concerns identified in the software that do not affect any functional requirements, the crosscutting behavior of this concern is being omitted. This is not an error occurrence, but is a warning that needs to be checked by the software engineer.