CMPSCI520/620 07 Requirements & UML Intro 07 Requirements SW Requirements Specification • Readings • How do we communicate the Requirements to others? • [cK99] Cris Kobryn, Co-Chair, “Introduction to UML: Structural and Use Case Modeling,” UML Revision Task Force Object Modeling with OMG UML Tutorial • It is common practice to capture them in an SRS Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, • But an SRS doesn’t need to be a single paper document Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • Purpose • [OSBB99] Gunnar Övergaard, Bran Selic, Conrad Bock and Morgan Björkande, “Behavioral Modeling,” UML Revision Task Force, Object Modeling with OMG UML • Contractual requirements Tutorial Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea elicitation Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational • Baseline Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • for evaluating subsequent products • [laM01] Maciaszek, L.A. (2001): Requirements Analysis and System Design. • for change control requirements Developing Information Systems with UML, Addison Wesley Copyright © 2000 by analysis Addison Wesley • Audience • [cB04] Bock, Conrad, Advanced Analysis and Design with UML • Users, Purchasers requirements http://www.kabira.com/bock/ specification • [rM02] Miller, Randy, “Practical UML: A hands-on introduction for developers,” • Systems Analysts, Requirements Analysts Copyright © 2002 TogetherSoft, Inc. [now at Borland site] • Developers, Programmers http://bdn.borland.com/article/0,1410,31863,00.html requirements • Testers validation • Project Managers UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 What about RFP/RFB/RFIs? Appropriate Specification • RFP = ‘SRS’ written by the procurer (or by an • Consider two different projects: independent RE contractor) • Tiny project, 1 programmer, 2 months work • Selected developer may create a more detailed ‘SRS’ • Programmer talks to customer, then writes up a 5-page memo • developer’s understanding of the customers needs • Large project, 50 programmers, 2 years work • basis for evaluation of contractual performance • Team of analysts model the requirements, then document • Not typically response to RFP them in a 500-page SRS • IEEE Standard recommends SRS jointly developed by Project A Project B procurer and developer Purpose of spec? Crystalizes programmer’s Build-to document; must understanding; feedback to contain enough detail for all • When to issue RFP/RFB? customer the programmers Management Spec is irrelevant; have Will use the spec to estimate • Early (conceptual stage) view? already allocated resource needs and plan the resources development • Late (detailed specification stage) Readers? Primary: Spec author; Primary: programmers, Secondary: Customer testers, managers; Secondary: customers UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 Rick Adrion 2004 (except where noted) 1 CMPSCI520/620 07 Requirements & UML Intro Hints & Guidelines There is no Perfect SRS • Validity (or “correctness”) • Ambiquity • expresses only the real needs of • every statement can be read in condense the stakeholders (customers, exactly one way users,…) • defines confusing terms ambiguousambiguous • Completeness • e.g. in a glossary • specifies all the things the system • Verifiablility expand must do and all the things it must • includes a process exists to test not do! satisfaction of each requirement expand • Conceptual Completeness • every requirement is specified • e.g. responses to all classes of input behaviorally • Structural Completeness • Understandablility (Clarity) redundantredundant formalize inconsistentinconsistent • e.g. no “to be determined” functions • e.g. by non-computer specialists • Consistency • technical notations should only be • not self-contradictory used as backup (e.g. in an reduce add • satisfiable appendix) explanations resolve • all terms used consistently • Modifiability not • inconsistency can be hard to • easy to change and modify not detect especially in timing aspects • good structure and cross- understandableunderstandable and business logic referencing incompleteincomplete • Necessary • must be kept up to date! • doesn’t contain anything that isn’t “required” see IEEE-STD-830-1993 © Steve Easterbrook 2000-2002 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 Typical mistakes IEEE std offers different templates • Noise • Jigsaw puzzles • External stimulus or external situation • text that carries no relevant • distributing key information across • e.g., for an aircraft landing system, each information to any feature of the a document and then cross- 1.Introduction different type of landing situation: wind gusts, no problem. referencing 1.Introduction fuel, short runway, etc • Purpose • Silence • Duckspeak requirements • Purpose • System feature •• ScopeScope • e.g., for a telephone system: call forwarding, call • a feature that is not covered by • requirements that are only there to • Definitions, acronyms, abbreviations blocking, conference call, etc any text. conform to standards • Definitions, acronyms, abbreviations • Reference documents • System response Over-specification Unnecessary invention of terminology • Reference documents • • • Overview • e.g., for a payroll system: generate pay-cheques, • text that describes a feature of the • e.g. ‘user input presentation • Overview report costs, print tax info; 2.Overall Description solution, rather than the problem. function’ 2.Overall Description • External object • Contradiction • e.g. ‘airplane reservation data •• ProductProduct perspective perspective • e.g. for a library information system, organize by • text that defines a single feature in validation function’ •• ProductProduct functions functions book type a number of incompatible ways. • Inconsistent terminology •• UserUser characteristics characteristics • User type • Ambiguity • inventing and then changing • Constraints • e.g. for a project support system: manager, • Constraints technical staff, administrator, etc. • text that can be interpreted in at terminology • Assumptions and Dependencies • Assumptions and Dependencies • Mode least two different ways. • Putting the onus on the development 3.Specific Requirements staff 3.Specific Requirements • e.g. for word processor: page layout mode, • Forward reference outline mode, text editing mode, etc • i.e. making the reader work hard to Appendices • text that refers to a terms or Appendices • Object features yet to be defined. decipher the intent Index Index • e.g., in a patient monitorng system, objects • Wishful thinking • Writing for the hostile reader include patients, sensors, nurses, rooms, • text that defines a feature that • fewer of these than friendly physicians, medicines, etc. cannot possibly be validated. readers from Steve Easterbrook © 2000-2002; he adapted from Kovitz, 1999 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 Rick Adrion 2004 (except where noted) 2 CMPSCI520/620 07 Requirements & UML Intro Maciaszek vs. IEEE SRS using a UML “package” construct 1.1.IntroductionIntroduction •• PurposePurpose •• ScopeScope •• Definitions,Definitions, acronyms, acronyms, abbreviations abbreviations •• ReferenceReference documents documents •• OverviewOverview 2.2.OverallOverall Description Description •• ProductProduct perspective perspective •• ProductProduct functions functions •• UserUser characteristics characteristics •• ConstraintsConstraints •• AssumptionsAssumptions and and Dependencies Dependencies 3.3.SpecificSpecific Requirements Requirements Appendices Appendices Index Index Probasco and Leffingwell Rational Software UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 SRS using a UML “package” construct UML & SRS • SRS • may include a single document, multiple documents, use case specifications and even the graphical use case model which describes relationships amongst the use cases. • Stakeholders • system analyst • use-case specifier • designers • implementers • project manager • testers • Features Drive Use Case Models “Combining Software Requirements Specifications with Use-Case Modeling,” Use Cases Interpret Leslee Probasco and Dean Leffingwell Requirements www.spc.ca/downloads/srs_usecase.doc UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 Rick Adrion 2004 (except where noted) 3 CMPSCI520/620 07 Requirements & UML Intro Example SRS format and style • openCMSstruts • Modifiability • http://opencmsstruts.sourceforge.net/vision.html • well-structured, indexed, cross-referenced, etc. • redundancy should be avoided or must