User Requirements Notation (URN )

1. User Requirements Notation (URN ) Daniel Amyot Q18/17 (URN) Rapporteur damyot@site.uottawa.ca

2. Objectives • Brief overview of URN • Goal-oriented Requirement Language (GRL), Use Case Maps (UCMs), and their relationships • Connections between URN and several languages from ITU and OMG • Several Challenges

3. Stage 1 Stage 2 Stage 3 Requirements and Service Description Message Sequence Information Protocols, Procedures, Behaviour Motivation for URN • Need improvement to cope with new realities of complex, dynamic, and evolving systems • Common design and standardisation methodologies already use scenarios Informal requirements? Use Cases? MSC or UML interaction diagrams SDL or UML Statechart diagrams URN!

4. URN - Initial Objectives • Focus on early stages of design, with scenarios • Capture user requirements when little design detail is available • No messages, components, or component states required • Reusability of scenarios and allocation to components • Dynamic refinement capabilities • Modelling of agent systems, early performance analysis, and early detection of undesirable interactions

5. URN - Additional Objectives • Express, analyse and deal with non-functional requirements (NFRs) • Express the relationship between business objectives/goals and system requirements • Capture reusable analysis (argumentation) and design knowledge (patterns) for addressing non-functional requirements • Connect to other ITU-T languages (and to UML)

6. Current Proposal for URN • Draft documents for Z.150, Z.151, Z.152 • http://www.UseCaseMaps.org/urn/ • 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 (Z.150-153)

7. GRL in a Nutshell • Goal-oriented Requirement Language — a graphical notation that allows reasoning about (non-functional) requirements • GRL is concerned with intentional elements, actors, and their relationships • Intentional elements model the “why” aspect — objectives, alternatives, as well as decision rationale and criteria — but not operational details • GRL satisfies most of URN’s additional objectives

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

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

10. UCMs in a Nutshell • Use Case Maps – a graphical scenario notation for describing causal relationships between responsibilities • Scenario elements may (optionally) be linked to components • The intent of UCMs is to facilitate the integration and reusability of scenarios, and to guide the design of high level architectures and detailed scenarios from requirements • UCMs satisfy most initial URN requirements

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

12. GRL - UCM Relationship • Goal-based approach • Focuses on answering “why” questions • Addresses functional and non-functional requirements • 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

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

14. URN-NFR/GRL Goals, non-functional requirements, alterna-tives, rationales Informal Requirements, Textual Use Cases ? Structural Diagrams SDL, or UML Class, Object, Component, & Deployment Diagrams URN-FR / UCMs Superimpose visually system level behavior onto structures of abstract components ? UML Use Case Diagram & Activity Diagram Behavioral Diagrams MSC/SDL, or UML Sequence, Collabor., & Statechart Diagrams Testing and Performance LanguagesTTCN, LQN, ... URN — OMG/SG17 Puzzle UCMs represent visually use cases in terms of causal responsibilities UCMs link to operationalizations(tasks) in GRL models UCMs visually associate behavior with structure at the system level UCMs provide a framework for making high level and detailed design decisions

15. Several Challenges (I) • Degree of formalisation • Qualitative/quantitative GRL evaluations? • UCM path traversal algorithms? • Reasoning in presence of looseness, incompleteness, inconsistencies? • Formalisation of languages • BNF? Graphical grammar? XML & schemas? • Layout information?

16. Several Challenges (II) • Extensibility and Adaptability • UML Profiles? • Connections to other languages • Traceability, transformations, meta-model? • Methodologies • What subsets of languages make sense together? • Do methodologies drive the evolution of standard languages? • Who are the stakeholders?