Integrating FRs and NFRs: A Use Case and Goal Driven Approach

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 • 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 PracticeUML – 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

4. What Are Use Cases? System Use Case Actor 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

5. Inadequate Handling of NFRs • 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

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

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

8. 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) Negative Contribution Implementing actual localization greatly hurts user friendliness. Why? Architecture/design details

9. 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 Ex. Performance, Reliability, Accuracy, Accountability With actors E.g. Scalability: Actor system supports up to 10,000 concurrent requests; Actor is expert user.

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

11. 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 directlyspecialized actor A2 N3 (a more strict form of N2) propagated to indirectlyspecialized actor A3

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) propagatedto U3. N9 (a more strict form of N3 propagated to U9 N2(a more strict form than N1) propagated to U2. N8 (a more strict form than N2) propagated to U8

13. Propagation Rules: Actor-Use Case Association NFR 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. Explicitly associated with L1 N2 (a more strict form of N1) propagatedto L2 N3 (a more strict form of N2) propagatedto 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 SystemStep 1-3: Identify Use Case Elements and Associated NFRs N1 N2 N3 Use NFR N1, N2, N3 as starting points of SIG

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

18. 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 Model Layer → (data) Envisioned from MVC pattern

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