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

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

3. State of Current Practice UML – de facto standard for OOA; but FR-dominance! Use cases as primary tool for FRs elicitation and modeling Use cases are realized with interaction diagram showing interaction between components or objects Package Dependency Diagram or Class diagram to describe components/objects and their relationships A Meta-model for partial FRs and NFRs Integration

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

5. Inadequate Handling of NFRs TitleSubmit Price Proposal DescriptionSupplier submits price proposal against a RFP (request for proposal). ActorsSupplier 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 FlowsIn step 3, Supplier may request to … Special RequirementsSupplier 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

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

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

8. Adopting the NFR Framework NFR Softgoal Name = Type[Topic] Goal Decomposition Operationalizaing Softgoal (design decision, strategy) Positive Contribution Negative Contribution Claim Architecture/design details UF of performing on-line transaction = UF of performing create service item, Approve price, submit price proposals Providing tech support greatly helps achieve user friendliness Implementing actual localization greatly hurts user friendliness. Why? Client-side scripting may be turned off, disabling localization feature.

9. With system E.g. Portability, Servicability, Maintainability NFR Association Points in the Use Case Model With actors E.g. Scalability: Actor system supports up to 10,000 concurrent requests; Actor is expert user. With use cases Ex. Performance, Reliability, Accuracy, Accountability With actor-use case associations E.g. Security, Confidentiality, User friendliness, Configurability, Adaptability

10. Analogy: code and name inherited by these 2 classes 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” Associating NFR to Multiple Use Case Elements 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) Performance inherently associated with these 2 use cases

11. Propagation Rules: Actor-NFR 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 N2 (a more strict form of N1) propagated to directly specialized actor A2 N3 (a more strict form of N2) propagated to indirectly specialized actor A3 But not associated with generalized actor (A0) Example:

12. Propagation Rules: Use Case- NFR Rules: 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. N2(a more strict form than N1) propagated to U2. N8 (a more strict form than N2) propagated to U8 N9 (a more strict form of N3 propagated to U9

13. Explicitly associated with L1 Propagation Rules: Actor-Use Case Association NFR N2 (a more strict form of N1) propagated to L2 Rules: 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. N3 (a more strict form of N2) propagated to L3

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

15. FRs and NFRs Integration Process An iterative and interleaving process

16. Illustration using the Pricing System Step 1-3: Identify Use Case Elements and Associated NFRs N1N2 N3 Use NFR N1, N2, N3 as starting points of SIG

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

18. Step 6: Develop Architecture and Design MVC (Model-View-Controller) Layers 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 maintenance Sub-system / Component Design

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

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

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