User Requirements Notation N R Requirements Engineering User

  • Slides: 46
Download presentation
User Requirements Notation N R Requirements Engineering & User Requirements Notation U Daniel Amyot

User Requirements Notation N R Requirements Engineering & User Requirements Notation U Daniel Amyot damyot@site. uottawa. ca http: //www. Use. Case. Maps. org/urn/ October 2002

Page 2 Objectives u Part I: Requirements Engineering – – – u What is

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

Page 3 Part I Requirements Engineering © 2002 User Requirements Notation

Page 3 Part I Requirements Engineering © 2002 User Requirements Notation

Page 4 You said “Requirements”? u A requirement is an expression of the ideas

Page 4 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 – © 2002 RE is concerned with identifying the purpose of a software system… and the contexts in which it will be used. User Requirements Notation

Page 5 Requirements Engineering Requirements Development Elicitation Analysis Requirements Management Specification Larry Boldt, Trends

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

Page 6 About the steps… • Requirements elicitation – • Requirements analysis and negotiation

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

Page 7 A Requirements Engineering Business Approach Goals/Objectives Vision and Scope Document User Requirements

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

Page 8 So many requirements…! u u © 2002 A goal is an objective

Page 8 So many requirements…! u u © 2002 A goal is an objective or concern used to discover and evaluate functional and non-functional requirements. A functional requirement is a requirement defining functions of the system under development 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. A user requirement is a desired goal or function that a user and other stakeholders expect the system to achieve User Requirements Notation

Page 9 The Requirements Analyst u Plays an essential communication role – – –

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

Page 10 Why Manage Requirements ? Distribution of Defects Requirements 56% Code 7% Other

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

Page 11 RE Process and Related Activities Why? Identify Business Needs What? Derive User

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

Page 12 Towards Good Requirements Specs! u Valid (or “correct”) – u Expresses actual

Page 12 Towards Good Requirements Specs! u Valid (or “correct”) – u Expresses actual requirements Complete – – – Specifies all the things the system must do. . . and all the things it must not do! Conceptual Completeness u – 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 E. g. responses to all classes of input Structural Completeness u E. g. no TBDs!!! Source: Adapted from Blum 1992, pp 164 -5 and the IEEE-STD-830 -1993 © 2002 User Requirements Notation

Page 13 Towards Good Requirements Specs! u Necessary – u u Doesn’t contain anything

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

Page 14 Typical Mistakes u Noise – u Silence – u u text that

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

Page 15 For Further Information… u B. A. Nuseibeh and S. M. Easterbrook, Requirements

Page 15 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 – u INCOSE Requirements Working Group – u u http: //www. incose. org/tools/tooltax. html See also http: //www. systemsguild. com/Guild. Site/Robs/retools. html IEEE (1993) Recommended Practice for Software Requirements Specifications. IEEE Std 830 -1993, NY, USA. IEEE (1995) Guide for Developing System Requirements Specifications. IEEE Std P 1233/D 3, NY, USA. RE Conference – u http: //www. incose. org/rwg/ Tools Survey: Requirements Management (RM) Tools – u http: //www. cs. toronto. edu/~sme/papers/2000/ICSE 2000. pdf http: //conferences. computer. org/RE/ Software Product Line Bibliography – © 2002 http: //www. iese. fraunhofer. de/Pulse/Bibliography/index. html User Requirements Notation

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

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

Page 17 Motivation for URN (ITU-T SG 17 Question 18) Stage 1 Stage 2

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

Page 18 URN - Initial Objectives u u Focus on early stages of design,

Page 18 URN - Initial Objectives u u 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 – u Dynamic refinement capabilities – u u Evaluation of architectural alternatives Behaviour and structure Early performance analysis Early detection of undesirable interactions © 2002 User Requirements Notation

Page 19 URN - Additional Objectives u u Express, analyse and deal with goals

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

Page 20 Current Proposal for URN u Draft – documents for Z. 150, Z.

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

Page 21 GRL in a Nutshell u u u Goal-oriented Requirement Language — a

Page 21 GRL in a Nutshell u u u Goal-oriented Requirement Language — a graphical notation that allows reasoning about (nonfunctional) 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 may be mapped to scenario-based notations and thus supports reasoning about scenarios GRL satisfies most of URN’s additional objectives © 2002 User Requirements Notation

Page 22 Basic GRL Notation Softgoal ? Break Hurt Some- Unknown Belief Make Help

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

Page 23 Evaluations with GRL Satisficed System Security Weakly Satisficed Undecided Weakly Denied Biometrics

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

Page 24 GRL Model with Actors Actor Resource Dependency Payment Electronic Accountant Tax. Payer

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

Page 25 Key Points GRL Introduction & Notation u u u GRL (Goal-oriented Requirement

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

Page 26 UCMs in a Nutshell u u Use Case Maps – a graphical

Page 26 UCMs in a Nutshell u u Use Case Maps – a graphical scenario notation for describing causal relationships between responsibilities Scenario elements may (optionally) be linked to components, providing a grey-box view of systems 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 UCMs satisfy most initial URN requirements © 2002 User Requirements Notation

Page 27 Pool Start Point Stub AND-Fork Slot End Point Responsibility Component a) Root

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

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

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

Page 29 UCM Scenario Definitions u Enhances the behavioral modeling capability of UCM paths

Page 29 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 © 2002 User Requirements Notation

Page 30 Refining UCMs with Messages User. A Agent. B User. B req User:

Page 30 Refining UCMs with Messages User. A Agent. B User. B req User: A Agent: B chk vrfy upd req User: B chk msg 1 ring vrfy upd ring SN User. A chk User: A Switch req Switch msg 2 msg 3 msg 4 User: B vrfy req upd ring msg 5 vrfy upd © 2002 User Requirements Notation SN ring chk User. B

Page 31 MSC for Biometrics Successful © 2002 User Requirements Notation

Page 31 MSC for Biometrics Successful © 2002 User Requirements Notation

Page 32 Why Stop at MSCs? UML sequence diagrams UML collaboration diagrams HMSC MSC’

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

Page 33 UCMs and Performance Arrival Characteristics • Exponential, or • Deterministic, or •

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

Page 34 GRL - UCM Relationship u Goal-based approach – – u Scenario-based approach

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

Page 35 URN — Missing Piece of the Modelling Puzzle? Structural Diagrams SDL, e.

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

Page 36 GRL Tool: OME 3 u u u Java tool, developed by Prof.

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

Page 37 © 2002 User Requirements Notation

Page 37 © 2002 User Requirements Notation

Page 38 © 2002 User Requirements Notation

Page 38 © 2002 User Requirements Notation

Page 39 UCM Tool: UCMNAV u u By A. Miga, D. Petriu, D. Amyot

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

Page 40 UCMNAV and Scenario Highlight © 2002 User Requirements Notation

Page 40 UCMNAV and Scenario Highlight © 2002 User Requirements Notation

Page 41 UCMNAV Facts u u u Load/save/import/export in XML Developed in C++, GUI

Page 41 UCMNAV Facts u u u Load/save/import/export in XML Developed in C++, GUI in Xforms Requires an X-server – u Multiple platforms are currently supported – u Solaris, Linux, and Windows (all) Current stable version: 2. 0. 1 – u E. g. Xfree 86 freeware (http: //xfree 86. cygwin. com/) Freely available at http: //www. Use. Case. Maps. org Free and Open Source: – © 2002 http: //ucmnav. sourceforge. net User Requirements Notation

Page 42 UCMNav Documents u u XML file format (conforms to UCM DTD) Export

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

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

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

Page 44 URN – Emerging Projects u u u URN for Reverse-Engineering (KLOCwork Suite)

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

Page 45 Conclusion u URN – – u GRL – – u Combines goals

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

Page 46 Selected References u URN: http: //www. Use. Case. Maps. org/urn u ITU-T

Page 46 Selected References u URN: http: //www. Use. Case. Maps. org/urn u ITU-T SG 17: Draft Recommendations Z. 150, September 2002 ITU-T SG 17: Draft Recommendations Z. 151 and Z. 152, February 2002 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 D. Amyot and G. Mussbacher, URN: Towards a New Standard for the Visual Description of Requirements. In: 3 rd SDL and MSC Workshop (SAM’ 02), Aberystwyth, U. K. , June 2002. G. Mussbacher, D. Amyot (2001), A Collection of Patterns for Use Case Maps. In: First Latin American Conference on Pattern Languages of Programming (Sugar. Loaf. PLo. P 2001), Rio de Janeiro, Brazil, October 2001. 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. 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. 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. D. Amyot and G. Mussbacher (2000), On the Extension of UML with Use Case Maps Concepts. In: The 3 rd International Conference on the Unified Modeling Language (<<UML 2000>>), York, UK, October 2000. 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. u u u u u © 2002 User Requirements Notation