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

  • View
    220

  • Download
    4

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 damyot@site.uottawa.ca http://www.UseCaseMaps.org/urn/ 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 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 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 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) 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