by Sam Supakkul
NFR Representation Patterns | NFR Refinement Patterns | NFR Operationalization Patterns | NFR Rationale Patterns | NFR Selection Patterns
The following patterns capture modeling or developmental knowledge for modeling NFRs, mostly based on the NFR Framework notation and other related notations to represent the functional aspect.
The following are some patterns showing the desirable ways and anti-patterns showing undesirable ways to represent NFRs using various notations..
Using the NFR Framework, an NFR is represented by an NFR softgoal as depicted by a thin border cloud icon and named using "Type[Topic]" nomenclature where Type refers to the NFR in question and Topic the context for the NFR. For instance, "Security[Account]" refers to the security (Type) of Account (Topic). A means or solution to achieve an NFR softgoal is represented by an operationalizing softgoal as depicted by a thick border could. A means or solution is also considered a softgoal becuase it can become a goal to be achieved by more specific solutions.
The following are some patterns for representing NFRs either in a standalone or integrated with FRs manner.
The following are some undesirable ways to name NFRs using the "Type[Topic]" nomenclature.
An NFR softgoal may be refined using AND or OR decompositions and Equal (eql) refinement to clarify the meaning, where AND decomposition is depicted by single-bar lines linking a goal to more specific goals, OR decomposition by double-bar lines, and Equal by a uni-direction line with an "eql" label. An NFR softgoal should be decomposed to more specific goals, and a means or solution should be decomposed to detailed steps or mechanisms of the means or solution.
These patterns illustrate the use of AND/OR decomposition and Equal refinement to to clarify an NFR softgoal with more specific softgoal or to clarify a solution with more details of the solution.
An NFR softgoal should not be decomposed to solutions as it defeats the purpose of the decomposition concept, that is, to clarify. Using an analogy, when asked to clarify a question, one would clarify by rephrasing the question with different terms or with more specifics about the question. He would not clarify a question with answers. Granted that decomposing a goal into solutions is done in practice; it, however, has some drawbacks. For example, when exploring alternatives to achieve "Identification[Customer]" goal or the ability to identify each customer of a company, the company may consider two alternatives, including "using name" or "using social security number" (a unique number given to each US resident). We would want to be able to identify how well each alternative is towards achieving the goal. In this case, we may denote that "using name" only helps (e.g. denoted by a + sign) achieve the goal because given names are not unique in the US, and denote that "using social security number" makes (e.g. denoted by a ++ sign) or sufficiently achieves the goal. Differentiating different levels of contribution is not a concern in a decomposition. Therefore, when a goal is decomposed to solutions, we lose important information about the different contributions to make a proper selection and tradeoff analysis among alternatives.
Below are examples of some undesirable refinement where an NFR softgoal is refined to solutions.
To represent an alternative for operationalizing a goal, a contribution link is used to link the two. The NFR Framework provides four kinds of contributions, including Make(++), Help(+), Hurt(-), and Break(--). A Make(++) contribution indicates that the alternative is sufficient towards achieving the goal; Help(+), weakly positive; Hurt(-), weakly negative, and Break(--), strongly negative toward achieving the goal, or in other words it is sufficient in denying the goal. If the level of contribution is unknown, a more general contribution may be used, including SomePlus (S+) or SomeMinus (S-) for a general positive or negative contribution.
It is also desirable to denote any side-effects towards other NFR softgoals that may be caused by the alternative. The side-effect relationship is a contribution link with a distinction to differentiate it from the normal contribution link between the alternative and its goal (e.g. using a dashed line instead of a solid line).
It is sometimes useful to show just the summarized relationships between the top-level goals based on a more complete goal model. For example, "Confidentiality[Information]" is shown to have a SomeMinus (S-) side-effect towards "Usability[Information]" based on the goal model shown above with "Access control" and "Encryption" alternatives. The side-effect between two goals is a shorthand to represent that the alternatives for achieving "Confidentiality[Information]" have negative side-effects towards the "Usability[Information]" goal. The SomeMinus contribution is used because of different negative side-effects posted by "Access control" and "Encryption". On the other hand, "Authentication[User]" is shown with a shorthand to have two side-effects toward "Trustworthiness", a Break(--) from "Password" and SomePlus(S+) from "Security token" and "Biometrics". It is important to note that the relationships between top-level goals are denoted by "side-effect" relationships (dashed lines) rather than direct contributions (solid lines) because "Confidentiality[Information]" is not a solution for "Usability[Information]" and "Authentication[User]" not a solution for "Trustworthiness".
(TBD)
(TBD)
* The diagrams above are modeled using the RE-Tools.
© 2009-2011 Sam Supakkul
Updated Jan. 18, 2011