1. Integrating FRs and NFRs: A Use Case and Goal Driven Approach
Sam Supakkul
Network Surveillance Systems
MCI
Lawrence Chung
Dept. of Computer Science
University of Texas at Dallas

2. Outline State of Current Practice
Problem of Inadequate Handling of NFRs
A Use Case and Goal Driven Approach
Associating NFRs with Use Cases
Propagating NFR Associations
Interdependencies Among NFR Associations
Illustration
Conclusion

3. State of Current Practice UML – de facto standard for OOA; but FR-dominance!
A Meta-model for partial FRs and NFRs Integration
Use cases as primary tool for FRs elicitation and modeling
This slide describes the current state of FR-dominant practice.
Use use cases to describe functional aspect.
Use package dependency diagram or class diagram to describe structural components or classes and their relationship.
Use interaction diagram such as sequence diagram to capture interaction between components or objects to perform detailed functions to realize the use cases
Package Dependency Diagram or Class diagram to describe components/objects and their relationships
Use cases are realized with interaction diagram showing interaction between components or objects

4. What Are Use Cases? System Use Case Actor Actor-Use Case Association
Specialized Use Case
Generalized Actor
Specialized Actor
Generalized Use Case
Actor-Use Case Association
Here we describe the use case elements.
System = the system in question that provides the functionality represented by use cases
Actor = an external entity (human or system)
Use case = functionality (FRs) provided by the system
Actor-Use Case Association = an interface between an actor and the system
Use case details, including NFRs, are embedded textually using a template

5. Inadequate Handling of NFRs
Title
Submit Price Proposal
Description
Supplier submits price proposal against a RFP (request for proposal).
Actors
Supplier
Basic Flow
Supplier selects an RFP and requests system to submit a proposal against the RFP.
System prompts the Supplier for proposal information.
Supplier provides the following proposal information… …
Alternate Flows
In step 3, Supplier may request to …
Special Requirements
Supplier may not see other suppliers’ identity and submitted proposals.
Problems:
NFRs not modeled and organized, and not visually
NFRs not traceable to architecture and design
Error prone if NFR applicable to multiple use cases
Textual description for NFRs embedded in the use case special requirements section – not 1st class citizens
Here we show that NFRs are not adequately addressed because they are textually described in the special requirements section of the use case body.

6. How to Improve the Situation?
Objectives:
Better treatment of NFRs
Strategies:
=> Adopt the NFR framework for addressing NFRs
representation, organization, and analysis of NFR
Easy transition from current practice
=> Integrate NFRs in use case model
UML de facto standard,
Familiarity of user currently using use cases for FRs
To improve the situation, we set the objectives to:
first provide a better treatment of NFRs by adopting the NFR framework
secondly easy transition from use case driven practice by integrating NFRs in the use case model

7. Other Integration Schemes
Method
Integration Point
NFR Modeling Constructs
Drawbacks
Cysnerios’s [1]
Text (LEL)
SIG, Class/ERD extensions
Not using the preferred use case modeling for FR elicitation
Lee’s [2]
Use cases
Using use cases (FR constructs) to represent NFRs. No organizational constructs.
Moreira’s [3]
Text (use case template)
Unnamed use cases with stereo type name indicating the NFR, e.g., <<Security>>
Using use cases (FR constructs) to represent NFRs. Non-standard usage of unnamed entity. No organizational constructs.
Dimitrov’s [4]
Use cases, Sequence diagram, State chart, Activity diagram
Informal annotation on diagrams
Specific to performance NFR. No organizational constructs.
A short survey of currently proposed schemes for integrating FRs and NFRs. No single scheme achieving the following…
No single scheme providing all of following:
Use case driven
Modeling constructs for representing and organizing NFRs
Preserving underlying use case principles (e.g., ovals for FRs but not for NFRs)
Generic for a wide range of NFRs

8. A Use Case and Goal Driven Approach
FRs - Use case driven
Adopt UML
NFRs - Goal driven
Adopt the NFR framework
Modeling constructs for NFRs representation, organization, analysis, and architecture/design traceability
Integration:
Use case elements providing context for NFRs
Integrating NFRs at association points in the use case model
(Scope of NFRs governed by use case element relationships)
Rules of propagation
Interdependencies among NFR associations
We propose a use case and goal driven approach

9. Adopting the NFR Framework
UF of performing on-line transaction = UF of performing create service item, Approve price, submit price proposals
Goal Decomposition
NFR Softgoal
Name = Type[Topic]
Positive Contribution
Providing tech support greatly helps achieve user friendliness
Claim
Client-side scripting may be turned off, disabling localization feature.
Operationalizaing Softgoal (design decision, strategy)
An introduction to the NFR framework.
When goal decomposition slides in, the green text describes the decomposition along the use case specialization relationship by saying “user friendliness of performing on-line function = user friendliness of performing create service item, approve price, and submit price proposals functions.
When Positive Contribution slides in, green text describes the operationalizing softgoal being pointed by the arrow.
When negative contribution slides, the green text describes the negative contribution, and ask ourselves why it is a negative contribution, which will be explained when “Claim” slides in.
When Claim slides in, it describes the reason why implementing “actual localization” is negative contribution. This is because to provide actual localization, there is a need for client-side scripting to access locale info from the desktop. However, because user may intentionally or unintentionally turn off the scripting capability, therefore, user friendliness cannot be guaranteed.
Negative Contribution
Implementing actual localization greatly hurts user friendliness.
Why?
Architecture/design details

10. NFR Association Points in the Use Case Model
With system
E.g. Portability,
Servicability,
Maintainability
With actor-use case associations
E.g. Security,
Confidentiality,
User friendliness,
Configurability,
Adaptability
Describe the 4 NFR association points that provide context for different type of NFRs.
With use cases
Ex. Performance,
Reliability,
Accuracy,
Accountability
With actors
E.g. Scalability: Actor system supports up to 10,000 concurrent requests; Actor is expert user.

11. Associating NFR to Multiple Use Case Elements
Performance inherently associated with these 2 use cases
Current Practice:
Repeating the NFR text in all applicable use cases
Problems:
Time consuming: same text in multiple places
Error prone:
One change to NFR requires multiple synchronized changes
Thorough proof-read required to ensure correctness (no visual representation of NFRs)
Analogy:
code and name inherited by these 2 classes
Here we describe the problem of textual description of NFR when the NFR is applicable for multiple use cases.
A Rule-based Solution:
“An NFR associated with a use case element is
propagated to other relevant use case elements in
a more strict form”

12. Propagation Rules: Actor-NFR
But not associated with generalized actor (A0)
Rules:
An NFR associated with an actor is inherently associated with directly and indirectly specialized actors, in a more strict form
Explicitly associated with A1
Example:
N2 (a more strict form of N1) propagated to directly specialized actor A2
Here we describe the rules for actor-NFR association. The real example has only one level deep hierarchy instead of 2 level deep as depicted in the left hand side diagram.
Formalization:
specializedBy = a predicate returning true if parm1 is specialized by parm2.
nfrOf = returning true if parm1 is an NFR associated with parm2
N3 (a more strict form of N2) propagated to indirectly specialized actor A3

13. Propagation Rules: Use Case-NFR
An NFR associated with a use case is inherently associated with directly and indirectly specialized and included use cases, in a more strict form.
Explicitly associated with U1
N3 (a more strict form of N1) propagated to U3.
N9 (a more strict form of N3 propagated to U9
Here we describe the rules for use case – NFR association. The propagation takes place only along the specialization and “includes” relationships.
Formalization:
includedBy = a predicate returning true if parm1 is included by parm2.
N2(a more strict form than N1) propagated to U2.
N8 (a more strict form than N2) propagated to U8

14. Propagation Rules: Actor-Use Case Association NFR
An NFR associated with an actor-use case association is inherently associated with the association between directly or indirectly specialized actors and use cases, in a more strict form.
Explicitly associated with L1
N2 (a more strict form of N1) propagated to L2
N3 (a more strict form of N2) propagated to L3
We describe the rules for actor-use case association here.
Formalization:
assocOf = a predicate returning true if parm2 is an actor-use case association of parm1.
ACTOR = a function returning all actors associated with “actor-use case association” parm1
SPECIALIZER = a function returning all specialized use case elements of parm1
USECASE = a function returning the use case associated with “actor-use case association” parm1

15. Propagation Rules: System - NFR
Explicitly associated with system
Rules:
An NFR associated with the system inherently associated with all use cases, in a more strict form.
N1 (a more strict form of N0) propagated to U1
N2 (a more strict form of N1) propagated to U2
We describe rules for system – NFR association.

16. FRs and NFRs Integration Process
An iterative and interleaving process
The integration process enhances the existing use case driven process where we first identify the system. We also specify global and system NFR at the same time. When we identify actors, we also think about actor related characteristics/NFRs. When identify use cases, we also consider service related NFRs.
Once we have the integrated use case diagram that contains both FRs and NFR, we use the NFR framework to analyze goals and their satisficing.
We then develop detailed design to realize use cases.

17. Illustration using the Pricing System Step 1-3: Identify Use Case Elements and Associated NFRs
Here we show the end result of integrating NFRs with use case elements. We use the identified NFR-use case association as the starting point of SIG. N3
Use NFR N1, N2, N3 as starting points of SIG

18. Step 4-5: Refine and Satisfice NFR and Operationalizing Softgoals
Type[Topic] = NFR [System] N3
In SIG, we analyze the NFR softgoals, refine them if necessary. The possible results of this analysis are:
Lead to secondary FR/use cases. Here we see that operationalizing softgoal “Maintain locale info” leads to the need for the system to provide functionality for users to maintain the user defined locale info.
We may identify hard design decision, such as using certain components. So this is the traceability to the architecture and design.
Some operationalizing softgoal may call for UI design contraints. In this case, to provide confidentiality, UI must not show identity and submitted price proposals of other suppliers
Traced to a new use case (FR)
Secondary FR Traceability
Influence UI design
Traced to a sub-system
UI Design Constraints
Architecture/Design Traceability

19. Step 6: Develop Architecture and Design
Sub-system / Component Design
MVC (Model-View-Controller) Layers
Envisioned from MVC pattern
View Layer →
(presentation)
Envisioned from MVC pattern
Partitioned based on problem domain information model
Controller Layer →
(business logic)
SIG indicated that Use Profile component be used to encapsulate locale retrieval and maintenance
Here we show a structure design of pricing system components. We use MVC pattern to structure the roles of components. The components are identified based on MVC layers: view layer handling presentation. Here the component is “Web presentation” component.
The middle layer is MVC’s controller. The Pricing, Service Item, Bill of Material components were defined based on functional partition of respective classes on the problem domain class model. In the problem domain model, I use class diagram to describe all business level entities and relationship to visually capture the real-world information. Some people do away with the problem domain model by describing the entities and relationship textually in the use case body. But this technique can make the information ambiguous and less complete. Class diagram is a better tool to describe such information. Once we have the problem domain model, we can define components based on types of information.
In this diagram, User Profile component is first identified as an operationalizaing softgoal in the SIG to encapsulate the retrieval and maintenance of user preferred locale informationl
Model Layer →
(data)
Envisioned from MVC pattern

20. Step 6: Develop Architecture and Design (Cont.)
Realize Submit Price Proposal Use Case with a sequence diagram
Components from sub-system design
The SIG indicates that:
input/output must be localized to satisfice user friendliness NFR.
User Profile component used to encapsulate locale information
Once we have the component design, we can describe white-box view of interaction between the components to realize the use cases.
Therefore, SIG dictates the need to interact with the User Profile component in this sequence diagram.

21. Feedback MCI, the NFR framework for requirements analysis:
identified and confirmed business goals of current requirements
identified “gaps” (i.e. incorrect or missing) in current requirements
comment: “a good analysis method that should be used in all projects”
e-gatematrix, the FRs and NFRs integration for NFR elicitation:
NFR association with use case elements eliminated questions about the context to which the NFRs are applicable
received as compatible with existing use case driven practice
e.g. “a use case tool could provide a list of applicable NFRs when selecting a use case element as a checklist of what NFRs should be examined.”

22. Conclusion Contributions: Future Work:
FRs (Use Cases) and NFRs (Softgoals) integration
NFR association propagation
Relationship Among NFR-use case Associations
Future Work:
Tool support
NFR association propagation rules validation
Integration process fine tuning
Meta-model for precise definition of all relevant framework concepts
NFR organization along the different relationship types in the context of use case model