Integrating FRs and NFRs A Use Case and

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 1. State of Current Practice 2. Problem of Inadequate Handling of NFRs 3. A Use Case and Goal Driven Approach • Associating NFRs with Use Cases • Propagating NFR Associations • Interdependencies Among NFR Associations • Illustration 4. 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 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 Actor Use Case Specialized Use Case Generalized Actor Specialized Actor Generalized Use Case Actor-Use Case Association 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 1. Supplier selects an RFP and requests system to submit a proposal against the RFP. 2. System prompts the Supplier for proposal information. 3. Supplier provides the following proposal information… 4. … Alternate Flows In step 3, Supplier may request to … Special Requirements Supplier may not see other suppliers’ identity and submitted proposals. Textual description for NFRs embedded in the use case special requirements section – not 1 st class citizens Problems: 1. NFRs not modeled and organized, and not visually 2. NFRs not traceable to architecture and design 3. Error prone if NFR applicable to multiple use cases

How to Improve the Situation? Objectives: 1. Better treatment of NFRs Strategies: => Adopt the NFR framework for addressing NFRs representation, organization, and analysis of NFR 2. Easy transition from current practice => Integrate NFRs in use case model UML de facto standard, Familiarity of user currently using use cases for FRs

A Use Case and Goal Driven Approach FRs - Use case driven l l Adopt UML NFRs - Goal driven l l l Adopt the NFR framework Modeling constructs for NFRs representation, organization, analysis, and architecture/design traceability Integration: l l 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

Adopting the NFR Framework UF of performing on-line Goal Decomposition transaction = UF of performing create service item, Approve price, submit price proposals NFR Softgoal Name = Type[Topic] Positive Contribution Claim Client-side scripting may be turned off, disabling localization feature. Providing tech support greatly helps achieve user friendliness Operationalizaing Softgoal (design decision, strategy) 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 With use cases With actors E. g. Scalability: Actor system supports up to 10, 000 concurrent requests; Actor is expert user. Ex. Performance, Reliability, Accuracy, Accountability

Associating NFR to Multiple Use Case Elements Current Practice: Repeating the NFR text in all applicable use cases Performance inherently associated with these 2 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) 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” Analogy: code and name inherited by these 2 classes

Propagation Rules: Actor-NFR But not associated with generalized actor (A 0) Rules: Explicitly associated with A 1 An NFR associated with an actor is inherently associated with directly and indirectly specialized actors, in a more strict form Example: N 2 (a more strict form of N 1) propagated to directly specialized actor A 2 N 3 (a more strict form of N 2) propagated to indirectly specialized actor A 3

Propagation Rules: Use Case. NFR Rules: Explicitly associated with U 1 • N 3 (a more strict form of N 1) propagated to U 3. N 9 (a more strict form of N 3 propagated to U 9 N 2(a more strict form than N 1) propagated to U 2. N 8 (a more strict form than N 2) propagated to U 8 An NFR associated with a use case is inherently associated with directly and indirectly specialized and included use cases, in a more strict form.

Propagation Rules: Actor-Use Case Association NFR Explicitly associated with L 1 N 2 (a more strict form of N 1) propagated to L 2 N 3 (a more strict form of N 2) propagated to L 3 Rules: An NFR associated with an actoruse case association is inherently associated with the association between directly or indirectly specialized actors and use cases, in a more strict form.

Propagation Rules: System NFR Explicitly associated with system N 1 (a more strict form of N 0) propagated to U 1 Rules: N 2 (a more strict form of N 1) propagated to U 2 An NFR associated with the system inherently associated with all use cases, in a more strict form.

FRs and NFRs Integration Process An iterative and interleaving process

Illustration using the Pricing System Step 1 -3: Identify Use Case Elements and Associated NFRs N 1 N 2 N 3 Use NFR N 1, N 2, N 3 as starting points of SIG

Step 4 -5: Refine and Satisfice NFR and Operationalizing Softgoals N 1 N 2 Type[Topic] = NFR [System] N 3 Traced to a new use case (FR) Secondary FR Traceability Influence UI design Traced to a sub-system Architecture/Design Traceability UI Design Constraints

Step 6: Develop Architecture and Design Sub-system / Component Design MVC (Model-View-Controller) Layers Envisioned from MVC pattern View Layer → (presentation) Controller Layer → (business logic) Model Layer → (data) Envisioned from MVC pattern Partitioned based on problem domain information model SIG indicated that Use Profile component be used to encapsulate locale retrieval and Envisioned from maintenance MVC pattern

Step 6: Develop Architecture and Design (Cont. ) Realize Submit Price Proposal Use Case with a sequence diagram The SIG indicates that: 1) input/output must be localized to satisfice user friendliness NFR. 2) User Profile component used to encapsulate locale information Therefore, SIG dictates the need to interact with the User Profile component in this sequence diagram. Components from subsystem design

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: • 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