Using the User Requirements Notation

1. ITU-T Workshop on the "Use of Description Techniques" Using theUser Requirements Notation Daniel Amyot Q.18/17 Rapporteur SITE, University of Ottawa, Canada damyot@site.uottawa.ca

2. About this presentation • What is the User Requirements Notation (URN)? • What can we model with URN? • What answers can these models provide? • What are the typical/potential usages?

3. URN – Main objectives • Focus on early stages of development with goals and scenarios • From user requirements to system functional and non-functional requirements • No messages, components, or component states required • Reusability • of argumentations (goal patterns and analysis) • of scenarios (patterns and architectural alternatives) • Early performance analysis • Traceability and transformations to other languages • Particularly MSC, SDL, TTCN, and UML

4. Current Proposal for URN • Draft documents for Z.150, Z.151, Z.152 • Combined use of two complementary notations: • Goal-oriented Requirement Language (GRL) for NFRs (http://www.cs.toronto.edu/km/GRL/) • Use Case Maps (UCM) for Functional Requirements (http://www.UseCaseMaps.org/) • Create ITU-T standard by end of 2003 • http://www.UseCaseMaps.org/urn/

5. URN-NFR/GRL Goals, non-functional requirements, alterna-tives, rationales Informal Requirements, Textual Use Cases ? Structural Diagrams SDL, eODL, or UML class, object, component, & deployment diagrams URN-FR / UCMs Superimpose visually system level behavior onto structures of abstract components. Can replace UML use case & deployment diagams. ? MSC, UML Use Case Diagram & Activity Diagram Behavioral Diagrams MSC/SDL, or UML sequence, collabor., & statechart diagrams Testing and Performance LanguagesTTCN, LQN, ... DataASN.1 whereappropriate URN — Missing Piece ofthe Modelling Puzzle? UCMs link to operationalizations(tasks) in GRL models UCMs represent visually use cases in terms of causal responsibilities UCMs visually associate behavior and structure at the system level UCMs provide a framework for making high level and detailed design decisions

6. GRL in a Nutshell • Goal-oriented Requirement Language • graphical notation • connects requirements to business objectives • allows reasoning about (non-functional) requirements • GRL models the “why” aspect • objectives, alternatives, as well as decision rationale • no operational details • Supports goal analysis and evaluations

7. SystemSecurity Softgoal Break Hurt Some- Unknown Cost of Terminal Belief Contribution Make Help Some+ Equal Biometrics is no regular off-the-shelftechnology Security of Terminal Security of Host . . Make ? Argumentation Access Authorization Encryption Task Decomposition (AND) Correlation(side-effect) Authentication Identification Means-End Goal Cardkey Password Biometrics Basic GRL Notation

8. Satisficed SystemSecurity Weakly Satisficed Cost of Terminal Undecided Biometrics is no regular off-the-shelftechnology Weakly Denied Security of Host Security of Terminal . . Denied Access Authorization Encryption Authentication Identification Cardkey Password Biometrics Evaluations with GRL

9. UCMs in a Nutshell • Use Case Maps • graphical scenario notation • causal relationships between responsibilities • scenario elements may (optionally) be allocated to components • UCMs model the “what” aspects • functional requirements as scenarios • integration and reusability of scenarios • guidance for architecture and detailed behaviour • Performance analysis, conflict detection

10. c) PassWord Plug-in b) Biometrics Plug-In Timer OR-Fork Pool StartPoint Stub AND-Fork Slot End Point Responsibility Component a) Root UCM

11. GRL - UCM Relationship • Goal-based approach • Focuses on answering “why” questions • Scenario-based approach • Focuses on answering “what” questions • Goals are operationalized into tasks and tasks are elaborated in (mapped to) UCM scenarios • Focuses on answering “how” questions • GRL goals can guide the selection of a particular architecture for the UCM scenarios

12. Typical Usage of URN • Modelling and documentation • User and system requirements, rationales • Analysis of business goals • Evaluations of alternative requirements or solutions • Discovery of tradeoffs that can optimize the stakeholders’ degree of satisfaction for conflicting goals • Architecture analysis • Based on NFRs and design constraints • Performance analysis • Generation of individual scenarios • Training, documentation • Detection of conflicts • Transformation to MSC and test cases • Reverse-engineering

13. Experiences with GRL • Used on industrial projects • New family of Web-based telephone sets • Documentation of discussions involving multiple stakeholders • Visualization and analysis of conflicting goals • Evaluation of architectural solutions, and rationales for the retained solution • Proved to be very helpful for keeping discussions on track and for avoiding repeating the same discussions over and over again. • Accelerated the reaching of an agreement and • Improved (short-term and long-term) understanding. • Used in academic projects • Security applications • Web-based systems (in combination with UCMs) • Architectural/performance tradeoffs at a qualitative level

14. T2 Performance Engineering with UCMs • Device Characteristics • Processors, disks, DSP, external services… • Speed factors • Arrival • Characteristics • Exponential, or • Deterministic, or • Uniform, or • Erlang, or • Other • Population size Timestamp • Response Time • Requirement • From T1 to T2 • Name • Response time • Percentage TaxPayer Security E_Accountant T1 CheckBio Continue Ready Access Rejected • Components • Allocated responsibilities • Processor assignment • Responsibilities • Data access modes • Device demand parameters • Mean CPU load (time) • Mean operations on other devices • OR Forks • Relative weights (probability) Automated translation to Layered Queuing Networks (LQNs), for analytical evaluations and simulations. Being applied to industrial case studies.

15. UCM Scenario Definitions and Path Traversal (Highlight) • Extraction of individual scenarios • Conditions attached to selection points • Initialization of Boolean variables, and selection of start points

16. Tool Support: UCMNav 2.1

17. From UCM Requirements to More Detailed Design Models • Requires: • Path Data Model (global Booleans variables) • Scenario Definitions • Path Traversal Mechanism • Mapping Rules (MSC, UML, TTCN, LQN, LOTOS...)

18. Experiences with TIA’s Wireless Intelligent Network ICS invocation with Normal Termination and Distinctive Alerting

19. NormalAlerting (NA) CallSetup(CS) Screening (S) IncomingCall (IC) PlayBlockAnnounce (PBA) CallBlocked(CB) Simplified UCM for Incoming Call Screening • WIN Phase 1 covers three major services: • Calling Name Presentation (CNAP) • Incoming Call Screening (ICS) • Voice Controlled Services (VCS) • The following ICS Use Case Map is for illustration purpose.

20. Incoming Call Screening Scenario on Functional Entities IC IC FE5 FE1 FE3 FE1 FE3 CS NA S FE1 IC S FE6 FE2 FE4 FE2 FE4 S CB CB CB NA NA PBA PBA PBA CS CS (a) First Structure (b) Second Structure (c) Different Mapping of UCM

21. NE1 NE3 NE2 NE4 NE1 NE3 NE3 NE1 FE1 FE2 FE3 FE1 FE2 FE3 FE1 FE4 NE2 NE2 FE2 FE3 FE4 FE4 (a) First Structure (b) Second Structure (c) Different Mapping of FEs Binding Functional Entities to Network Entities

22. NE1 NE3 NE3 NE2 NE1 NE1 NE2 NE3 FE2 FE1 IC IC m1 m1 m2 m4 m2 m5 m3 CS Refinement with MSC IC NE2 FE3 S S NA FE4 S PBA CB CB NA PBA CS (a) UCM to FEs to NEs (b) A MSC for <IC,S,NA,CS> (c) A MSC for <IC,S,PBA,CB>

23. + + SCP Legend Blk : Blocking Chk : Check CF : CheckFunction DA : DistinctiveAlerting NA : NormalAlerting Nb : Number PBA : PlayBlockAnnounce Req : Request SF : ScreeningFunction VM : VoiceMail Loc : Location HLR LRFH SDF SF Chk SCF NA DA SCF Loc CF VM Nb MSC MACF Routing SSF IP SRF PBA Blk IncomingCall CCF CallSetup Req VoiceMail SRF Announcement CallForwarded CallBlocked + + Plug-in UCM for ICS

24. Coming soon… • URN-oriented Reverse-Engineering • UCMs for reverse-engineering already popular. • Can cope with very complex systems • UCM to UML scenarios • UCM to TTCN test cases • URN and Requirements Management • UCM and Requirements-based Design (synthesis) • Already a tool-support mapping to LOTOS

25. Conclusions • URN • Allows engineers to specify or discover requirements for a proposed system or an evolving system, and review such requirements for correctness and completeness. • Is usable in industry and in standardization bodies • Combines goals and scenarios • Helps bridging the gap between informal and formal concepts, and between requirements models and design models • Big benefits for little modelling investment, even when used informally • GRL • For incomplete, tentative, (non-functional) requirements • Capture goals, objectives, alternatives and rationales • UCM • For operational and functional requirements • Enables analysis and transformations • Architectural alternatives and dynamic systems

26. 7th Feature Interaction Workshop Ottawa, June 9-11, 2003 http://www.site.uottawa.ca/fiw03/ Submission deadline: December 9