ch 1 RE-UML2_5697c40bc88ce1f095d2171064b42430.pdf

Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde w...

Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 1  Fundamentals of RE Chapter 1 Setting the Scene www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 2  Setting the Scene  What is Requirements Engineering? – The problem world & the machine solution – The scope of RE: the WHY, WHAT and WHO dimensions – Types of statements involved: descriptive vs. prescriptive – Categories of requirements: functional vs. non-functional – The requirements lifecycle: actors, processes, products – Target qualities and defects to avoid – Types of software projects – Requirements in the software lifecycle – Relationship to other disciplines www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 3  Types of Statements: System Requirements, Software Requirements  System requirement: prescriptive statement refering to environment phenomena (not necessarily shared) – to be enforced by the software-to-be possibly together with other system components – formulated in a vocabulary understandable by all parties TrainMoving DoorsClosed  Software requirement: prescriptive statement refering to shared phenomena – to be enforced by the software-to-be solely – formulated in the vocabulary of software developers measuredSpeed  0 doorsState = 'closed’ (A software req is a system req; the converse is not true) www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 4  Types of Statements: Domain Properties, Assumptions, Definitions  Domain property: descriptive statement about problem world phenomena (holds regardless of any software-to-be) trainAcceleration > 0 trainSpeed  0  Assumption: statement to be satisfied by the environment of the software-to-be – formulated in terms of environment phenomena – generally prescriptive (e.g. on sensors or actuators) measuredSpeed  0 iff trainSpeed  0  Definition: statement providing a precise meaning to system concepts or auxiliary terms – no truth value “measuredSpeed is the speed estimated by the train’s speedometer” www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 5  Relating Software Reqs to System Reqs: the 4-variable Model [Parnas95] Input Devices (e.g. sensors) trainSpeed measuredSpeed M: monitored variables I: input data Environment SoftwareToBe DoorsClosed doorsState C: controlled variables O: output results Output Devices (e.g. actuators) SysReq  M  C relation on environment monitored/controlled variables SofReq  I  O relation on software input/output variables SofReq = Map (SysReq, Dom, Asm) translates SysReq using domain properties and assumptions www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 6  Mapping System Reqs to Software Reqs Involves Satisfaction Arguments SOFREQ, ASM, DOM |= SysReq “If the software requirements in SOFREQ, the assumptions in ASM and the domain properties in DOM are all satisfied and consistent, then the system requirements SysReq are satisfied” SofReq: measuredSpeed  0 doorsState = 'closed’ ASM: measuredSpeed  0 iff trainSpeed  0 doorsState = 'closed’ iff DoorsClosed Dom: TrainMoving iff trainSpeed  0 --------------------------------------------------------------------------- SysReq: TrainMoving DoorsClosed Further to requirements, we need to elicit, evaluate, document, consolidate relevant assumptions & domain properties www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 7  Categories of Requirements  Functional requirements: prescribe what services the software-to-be should provide – capture intended software effects on environment, applicability conditions – units of functionality resulting from software operations “The software shall control the acceleration of all trains”  Non-functional requirements: constrain how such services should be provided – Quality requirements: safety, security, accuracy, time/space performance, usability,... – Others: compliance, architectural, development reqs – To be made precise in system-specific terms “Acceleration commands shall be issued every 3 seconds to every train” www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 8  A Taxonomy of Non-functional Requirements Non-Functional Requirement Quality of Service Compliance Architectural Constraint Development Constraint Accuracy Safety Security Reliability Performance Interface Installation Distribution Cost Maintainability Cost Deadline Variability ConfidentialityIntegrity Availability Time Space User Device Software interaction interaction interoperability Subclass link Usability Convenience  See definitions and examples in the book  No clear-cut boundaries, possible overlaps – Functional/non-functional: e.g. functional reqs for firewall management are security-related – Non-functional overlaps: e.g. “high frequency of train commands” is related to performance www.wileyeurope.com/college/van lamsweerde and safety Chap.1: Setting the Scene © 2009 John Wiley and Sons 9  Requirements Taxonomies are Helpful...  More specific definition of what requirements are in specific classes  More semantic characterization of requirements... – prescribing desired behaviors e.g. many functional reqs – ruling out inadmissible behaviors e.g. many safety, security, accuracy reqs – indicating preferred behaviors e.g. soft, “ility” reqs  Elicitation/analysis can be guided by taxonomy browsing – Is there any confidentiality req on information X ? – Is there any accuracy req on information Y ? – Is there any conflict between confidentiality and accountability reqs in my system? www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 10