User Requirements Notation URN Daniel Amyot damyot@site. October 2002 Requirements Engineering & User Requirements

  • View

  • Download

Embed Size (px)

Text of User Requirements Notation URN Daniel Amyot damyot@site. October 2002 Requirements Engineering...

  • Slide 1

User Requirements Notation URN Daniel Amyot October 2002 Requirements Engineering & User Requirements Notation Slide 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 Slide 3 2002 Page 3 User Requirements Notation Part I Requirements Engineering Slide 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. Slide 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 Slide 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 Slide 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 Slide 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 Slide 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 Slide 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 Slide 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 Slide 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 Doesnt 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 Slide 13 2002 Page 13 User Requirements Notation Towards Good Requirements Specs! u Necessary Doesnt contain anything that isnt 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 Slide 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 Slide 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 u INCOSE Requirements Working Group u Tools Survey: Requirements Management (RM) Tools See also 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 u Software Product Line Bibliography Slide 16 2002 Page 16 User Requirements Notation Part II User Requirements Notation (URN) Slide 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) Slide 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 Slide 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 Slide 20 2002 Page 20 User Requirements Notation Current Proposal for URN u Draft documents for Z.150, Z.151, Z.152 u Combined use of two complementary notations: Goal-oriented Requirement Language (GRL) for NFRs ( Use Case Maps (UCM) for Functional Requirements ( u Create ITU-T standard by end of 2003 (Z.150-153) Slide 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 URNs additional objectives Slide 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 Slide 23 2002 Page 23 Us