1. User Requirements Notation URN Daniel Amyot damyot@site.uottawa.ca http://www.UseCaseMaps.org/urn/ October 2002 Requirements Engineering & User Requirements Notation

2. © 2002 Page 2 User Requirements Notation Objectives u Part I: Requirements Engineering – What is it? – A RE approach – Requirements characteristics u Part II: User Requirements Notation (URN) – Motivations and objectives – Goal-oriented Requirement Language (GRL) – Use Case Maps (UCMs) – MSC generation – Relationships with other languages – Tools

3. © 2002 Page 3 User Requirements Notation Part I Requirements Engineering

4. © 2002 Page 4 User Requirements Notation You said “Requirements”? u A requirement is an expression of the ideas to be embodied in the system or application under development u Requirements engineering is the activity of development, elicitation, specification, and analysis of the stakeholder requirements, which are to be met by systems – RE is concerned with identifying the purpose of a software system… and the contexts in which it will be used.

5. © 2002 Page 5 User Requirements Notation Requirements Engineering Requirements Development Requirements Management Elicitation Analysis Specification Verification Larry Boldt, Trends in Requirements Engineering People-Process-Technology, Technology Builders, Inc., 2001

6. © 2002 Page 6 User Requirements Notation About the steps… Requirements elicitation –Requirements discovered through consultation with stakeholders Requirements analysis and negotiation –Requirements are analyzed and conflicts resolved through negotiation Requirements specification –A precise requirements document is produced Requirements validation –The requirements document is checked for consistency and completeness

7. © 2002 Page 7 User Requirements Notation Vision and Scope Document User Requirements Use Case Document Functional Requirements Software Requirements Specification Constraints Quality Attributes System Requirements 1-7 Business Goals/Objectives Adapted from Karl Wiegers, Software Requirements A Requirements Engineering Approach

8. © 2002 Page 8 User Requirements Notation So many requirements…! u A goal is an objective or concern used to discover and evaluate functional and non-functional requirements. u A functional requirement is a requirement defining functions of the system under development u A non-functional requirement is a requirement characterizing a system property such as expected performance, robustness, usability, maintainability, etc. Non-functional requirements capture business goals/objectives and product quality attributes. u A user requirement is a desired goal or function that a user and other stakeholders expect the system to achieve

9. © 2002 Page 9 User Requirements Notation The Requirements Analyst u Plays an essential communication role – talks to users: application domain – talks to developers: technical domain – translates user requirements into functional requirements and quality goals u Needs many capabilities – interviewing and listening skills – facilitation and interpersonal skills – writing and modeling skills – organizational ability u RE is more than just modeling… This is a social activity! Karl Wiegers – In Search of Excellent Requirements

10. © 2002 Page 10 User Requirements Notation (Martin & Leffinwell) Distribution of Effort to Fix Defects Code 7% Other 10% Design 27% Requirements 56% Code 1% Other 4% Design 13% Requirements 82% Why Manage Requirements ? Distribution of Defects

11. © 2002 Page 11 User Requirements Notation Time Why? What? How? Who? When? If-Then Does It? Where? Project Management Process Quality Management Process Component & Configuration Management Process Risk Management Process Identify Business Needs Derive User & Functional Requirements Design Solutions TIME RE Process and Related Activities

12. © 2002 Page 12 User Requirements Notation Towards Good Requirements Specs! u Valid (or “correct”) – Expresses actual requirements u Complete – Specifies all the things the system must do –...and all the things it must not do! – Conceptual Completeness u E.g. responses to all classes of input – Structural Completeness u E.g. no TBDs!!! u Consistent – Doesn’t contradict itself (satisfiable) – Uses all terms consistently – Note: inconsistency can be hard to detect, especially in concurrency/timing aspects and condition logic – Formal modeling can help Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993

13. © 2002 Page 13 User Requirements Notation Towards Good Requirements Specs! u Necessary – Doesn’t contain anything that isn’t “required” u Unambiguous – Every statement can be read in exactly one way – Clearly defines confusing terms u E.g. in a glossary u Verifiable – A process exists to test satisfaction of each requirement – “every requirement is specified behaviorally” u Understandable (Clear) – E.g. by non-computer specialists u Modifiable – Must be kept up to date! Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993

14. © 2002 Page 14 User Requirements Notation Typical Mistakes u Noise – the presence of text that carries no relevant information to any feature of the problem. u Silence – a feature that is not covered by any text. u Over-specification – text that describes a feature of the solution, rather than the problem. u Contradiction – text that defines a single feature in a number of incompatible ways. u Ambiguity – text that can be interpreted in at least two different ways. u Forward reference – text that refers to a feature yet to be defined. u Wishful thinking – text that defines a feature that cannot possibly be validated. u Jigsaw puzzles – e.g. distributing requirements across a document and then cross-referencing u Inconsistent terminology – Inventing and then changing terminology u Putting the onus on the development staff – i.e. making the reader work hard to decipher the intent u Writing for the hostile reader – There are fewer of these than friendly readers Source: Steve Easterbrook, U. of Toronto

15. © 2002 Page 15 User Requirements Notation For Further Information… u B. A. Nuseibeh and S. M. Easterbrook, Requirements Engineering: A Roadmap. In A. C. W. Finkelstein (ed) The Future of Software Engineering, ACM Press, 2000 – http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf u INCOSE Requirements Working Group – http://www.incose.org/rwg/ u Tools Survey: Requirements Management (RM) Tools – http://www.incose.org/tools/tooltax.html http://www.incose.org/tools/tooltax.html – See also http://www.systemsguild.com/GuildSite/Robs/retools.html http://www.systemsguild.com/GuildSite/Robs/retools.html u IEEE (1993) Recommended Practice for Software Requirements Specifications. IEEE Std 830-1993, NY, USA. u IEEE (1995) Guide for Developing System Requirements Specifications. IEEE Std P1233/D3, NY, USA. u RE Conference – http://conferences.computer.org/RE/ http://conferences.computer.org/RE/ u Software Product Line Bibliography – http://www.iese.fraunhofer.de/Pulse/Bibliography/index.html http://www.iese.fraunhofer.de/Pulse/Bibliography/index.html

16. © 2002 Page 16 User Requirements Notation Part II User Requirements Notation (URN)

17. © 2002 Page 17 User Requirements Notation Requirements and Service Description Stage 1 Message Sequence Information Stage 2 Protocols, Procedures, Behaviour Stage 3 SDL or UML Statechart diagrams MSC or UML interaction diagrams Informal requirements? Use Cases? URN! Motivation for URN (ITU-T SG17 Question 18)

18. © 2002 Page 18 User Requirements Notation URN - Initial Objectives u Focus on early stages of design, with scenarios u Capture user requirements when little design detail is available u No messages, components, or component states required u Reusability of scenarios and allocation to components – Evaluation of architectural alternatives u Dynamic refinement capabilities – Behaviour and structure u Early performance analysis u Early detection of undesirable interactions

19. © 2002 Page 19 User Requirements Notation URN - Additional Objectives u Express, analyse and deal with goals and non- functional requirements (NFRs) u Express the relationship between business objectives/goals and system requirements u Capture reusable analysis (argumentation) and design knowledge (patterns) u Traceabilty and transformations to other languages – Particularly MSC, SDL, TTCN, and UML u Connect URN elements to external req. objects u Manage evolving requirements

20. © 2002 Page 20 User Requirements Notation Current Proposal for URN u Draft documents for Z.150, Z.151, Z.152 – http://www.UseCaseMaps.org/urn/ u 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/) u Create ITU-T standard by end of 2003 (Z.150-153)

21. © 2002 Page 21 User Requirements Notation GRL in a Nutshell u Goal-oriented Requirement Language — a graphical notation that allows reasoning about (non- functional) requirements u GRL is concerned with intentional elements, actors, and their relationships u Intentional elements model the “why” aspect — objectives, alternatives, as well as decision rationale and criteria — but not operational details u GRL may be mapped to scenario-based notations and thus supports reasoning about scenarios u GRL satisfies most of URN’s additional objectives

22. © 2002 Page 22 User Requirements Notation Basic GRL Notation Means-End PasswordCardkeyBiometrics Correlation (side-effect) Cost of Terminal Belief Argumentation Biometrics is no regular off-the-shelf technology Goal Decomposition (AND) IdentificationAuthentication Task Make.. Access Authorization Encryption ? BreakHurtSome- Unknown MakeHelpSome+Equal Contribution Security of Host Security of Terminal Softgoal System Security

23. © 2002 Page 23 User Requirements Notation Evaluations with GRL.. PasswordCardkeyBiometrics Identification Cost of Terminal Biometrics is no regular off-the-shelf technology Access Authorization Encryption Authentication Satisficed Weakly Satisficed Undecided Weakly Denied Denied Security of Host Security of Terminal System Security

24. © 2002 Page 24 User Requirements Notation GRL Model with Actors.. PasswordCardkey Biometrics Identification Cost of Terminal Biometrics is no regular off-the-shelf technology Access Authorization Encryption Authentication Security of Host Security of Terminal System Security Actor Boundary TaxPayer Payment Forward Tax Forms Resource Dependency Electronic Accountant Actor Keep Password Secret

25. © 2002 Page 25 User Requirements Notation Key Points - GRL Introduction & Notation u GRL (Goal-oriented Requirement Language) provides an intentional view of a system, focusing on the “why” aspect u Goals provide the right abstraction level for many requirements activities u The basic elements of the GRL notation are goals, softgoals, tasks, qualified contribution and correlation links, means-end links, and decomposition links u GRL graphs document rationale of subjective issues u Evaluations of GRL graphs show the impact of qualitative decisions on high level softgoals

26. © 2002 Page 26 User Requirements Notation UCMs in a Nutshell u Use Case Maps – a graphical scenario notation for describing causal relationships between responsibilities u Scenario elements may (optionally) be linked to components, providing a grey-box view of systems u The intent of UCMs is to facilitate the integration, reusability, and analysis of scenarios, and to guide the design of high level architectures and detailed scenarios from requirements u UCMs satisfy most initial URN requirements

27. © 2002 Page 27 User Requirements Notation Component Start Point End Point Responsibility Stub AND-Fork Pool a) Root UCM Slot b) Biometrics Plug-In c) PassWord Plug-in Timer OR-Fork

28. © 2002 Page 28 User Requirements Notation Electronic Accountant: Highlight Biometrics selected, Successful scenario

29. © 2002 Page 29 User Requirements Notation UCM Scenario Definitions u Enhances the behavioral modeling capability of UCM paths and path elements u Requires a path data model – Currently, global and modifiable Boolean variables – Scenario definition: initial values and start points – Used in conditions for OR-forks and dynamic stubs – Variables may be updated in responsibilities u Combined to a path traversal algorithm u Mapping rules for transformations

30. © 2002 Page 30 User Requirements Notation UserAAgentAAgentBUserB req msg1 ring vrfy upd chk UserASwitchSNUserB req chk upd msg2 ring msg5 msg4 msg3 vrfy SN req chk upd User:BUser:ASwitch vrfy ring User:AAgent:AAgent:BUser:B req ring vrfy upd chk Refining UCMs with Messages

31. © 2002 Page 31 User Requirements Notation MSC for Biometrics Successful

32. © 2002 Page 32 User Requirements Notation Why Stop at MSCs? UCM spec (XML) MSC’2000HMSC UML collaboration diagrams UML sequence diagrams Scenario Output (XML) MSC ’96 L OTOS test cases TTCN-3 test cases Performance models Documentation (ps, pdf, cgm)

33. © 2002 Page 33 User Requirements Notation UCMs and Performance Response Time Requirement From T1 to T2 Name Response time Percentage SecurityE_Accountant Ready Continue CheckBio TaxPayer Access T1 Timestamp T2 Device Characteristics Processors, disks, DSP, external services… Speed factors Rejected Arrival Characteristics Exponential, or Deterministic, or Uniform, or Erlang, or Other Population size Responsibilities Data access modes Device demand parameters Mean CPU load (time) Mean operations on other devices OR Forks Relative weights (probability) Components Allocated responsibilities Processor assignment Can generate Layered Queuing Networks (LQN) automatically!

34. © 2002 Page 34 User Requirements Notation GRL - UCM Relationship u Goal-based approach – Focuses on answering “why” questions – Addresses functional and non-functional requirements u Scenario-based approach – Focuses on answering “what” questions u Goals are operationalized into tasks and tasks are elaborated in (mapped to) UCM scenarios – Focuses on answering “how” questions

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

36. © 2002 Page 36 User Requirements Notation GRL Tool: OME3 u Java tool, developed by Prof. Eric Yu, Dr. Lin Liu, and others (University of Toronto) u Conceptual modeling tool and model analysis tool u OME3 supports many frameworks – NFR (Non-Functional Requirements Framework) – i* (Strategic Actor-based Modelling Framework) – GRL (Goal-Oriented Requirements Language) u Based on TELOS u Exports to XML u Version 3.10: http://www.cs.toronto.edu/km/GRL/

37. © 2002 Page 37 User Requirements Notation

38. © 2002 Page 38 User Requirements Notation

39. © 2002 Page 39 User Requirements Notation UCM Tool: UCMNAV u By A. Miga, D. Petriu, D. Amyot and others, since 1997 u Editing and navigating of UCMs u Supports UCM path and component notations u Maintains bindings – Plug-ins to stubs, responsibilities to components, sub-components to components, etc. u Editing is transformation-based – Operations maintain syntactic correctness – Enforce some static semantics constraints u Scenario definitions – Path highlighting and MSC generation (Z.120, textual) – XML scenario generation u Performance analysis – Performance annotations – Generation of Layered Queuing Networks (LQN)

40. © 2002 Page 40 User Requirements Notation UCMNAV and Scenario Highlight

41. © 2002 Page 41 User Requirements Notation UCMN AV Facts u Load/save/import/export in XML u Developed in C++, GUI in Xforms u Requires an X-server – E.g. Xfree86 freeware (http://xfree86.cygwin.com/) u Multiple platforms are currently supported – Solaris, Linux, and Windows (all) u Current stable version: 2.0.1 – Freely available at http://www.UseCaseMaps.orghttp://www.UseCaseMaps.org u Free and Open Source: – http://ucmnav.sourceforge.net

42. © 2002 Page 42 User Requirements Notation UCMNav Documents u XML file format (conforms to UCM DTD) u Export of UCM figures – Encapsulated PostScript (EPS) – Maker Interchange Format (MIF) – Computer Graphics Metafile (CGM) – Scalable Vector Graphics (SVG) u Flexible report generation – Content options – PostScript, with PDF hyperlink information

43. © 2002 Page 43 User Requirements Notation Report Generation in PS/PDF

44. © 2002 Page 44 User Requirements Notation URN – Emerging Projects u URN for Reverse-Engineering (KLOCwork Suite) u UCM/XML Scenarios to MSC, UML, TTCN, Doc… u URN and Requirements Management (DOORS) u URN and Requirements-based Design (synthesis) u URN and Performance Engineering (UCM2LQN) u ASM-Based Semantics for URN

45. © 2002 Page 45 User Requirements Notation Conclusion u URN – Combines goals and scenarios – Helps bridging the gap between requirements models and design models u GRL – For incomplete, fuzzy, non-functional requirements – Capture goals, objectives, alternatives and rationales u UCM – For operational and functional requirements – Enables analysis and transformations – Architectural alternatives and dynamic systems

46. © 2002 Page 46 User Requirements Notation Selected References u URN: http://www.UseCaseMaps.org/urnhttp://www.UseCaseMaps.org/urn u ITU-T SG 17: Draft Recommendations Z.150, September 2002 u ITU-T SG 17: Draft Recommendations Z.151 and Z.152, February 2002 u D. Petriu and M. Woodside, Analysing Software Requirements Specifications for Performance. In: Third International Workshop on Software and Performance (WOSP 2002), Rome, Italy, July 2002 u D. Amyot and G. Mussbacher, URN: Towards a New Standard for the Visual Description of Requirements.In: 3rd SDL and MSC Workshop (SAM’02), Aberystwyth, U.K., June 2002. u G. Mussbacher, D. Amyot (2001), A Collection of Patterns for Use Case Maps. In: First Latin American Conference on Pattern Languages of Programming (SugarLoafPLoP 2001), Rio de Janeiro, Brazil, October 2001. u D. Amyot (2001), Specification and Validation of Telecommunications Systems with Use Case Maps and LOTOS. Ph.D. thesis, SITE, U. of Ottawa, Canada, September 2001. u A. Miga, D. Amyot, F. Bordeleau, D. Cameron, and M. Woodside (2001), Deriving Message Sequence Charts from Use Case Maps Scenario Specifications. In: Tenth SDL Forum (SDL'01), Copenhagen, Denmark, June 2001. u L. Liu and E. Yu (2001), From Requirements to Architectural Design –Using Goals and Scenarios. In: From Software Requirements to Architectures Workshop (STRAW 2001), Toronto, Canada, May 2001. u D. Amyot and G. Mussbacher (2000), On the Extension of UML with Use Case Maps Concepts. In: The 3rd International Conference on the Unified Modeling Language ( >), York, UK, October 2000. u R.J.A. Buhr (1999), Use Case Maps as Architectural Entities for Complex Systems. In: Trans. on Software Engineering, IEEE, Vol. 24, No. 12, December 1998, pp. 1131-1155.