Integrating FRs and NFRs: A Use Case and Goal Driven Approach Sam Supakkul Network Surveillance Systems MCI ssupakkul@ieee.org Lawrence Chung Dept. of Computer Science University of Texas at Dallas chung@utdallas.edu

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

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

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

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.

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

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

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

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

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.

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”

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

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

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

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.

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.

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

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

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

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.

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.”

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