1. 1 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements evaluation: outline  Inconsistency management –Types of inconsistency –Handling inconsistencies –Managing conflicts: a systematic process  Risk analysis –Types of risk –Risk management –Risk documentation –DDP: quantitative risk management for RE  Evaluating alternative options for decision making  Requirements prioritization

2. 2 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons DDP: quantitative risk management for RE  DDP = Defect Detection Prevention  Technique & tool developed at NASA [Feather, 2003]  Quantitative support for Identify-Assess-Control cycles  Three steps:

3. 3 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Step 1: Elaborate the Impact matrix risk-consequence table  Build a risk-consequence table with domain experts for... –prioritizing risks by critical impact on all objectives –highlighting the most risk-driving objectives  For each objective obj, risk r: Impact (r, obj) = estimated loss of satisfaction of obj by r 0 (no loss) --> 1 (total loss)  Last line, for each risk r: Criticality (r) =  Likelihood (r)    obj (Impact (r, obj)   Weight (obj))  Last column, for each objective obj: Loss (obj) =  Weight (obj)    r (Impact (r, obj)   Likelihood (r))

4. 4 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Impact matrix: example for library system

5. 5 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Step 2: Elaborate the Effectiveness matrix risk-countermeasure table  Build a risk-countermeasure table with domain experts for... –estimating risk reduction by alternative countermeasures –highlighting most globally effective countermeasures  For each countermeasure cm, weighted risk r: Reduction (cm, r) = estimated reduction of r if cm applied 0 (no reduction) --> 1 (risk elimination)  Last line, for each risk r: combinedReduction (r) = 1   cm (1  Reduction (cm, r))  Last column, for each countermeasure cm: overallEffect (cm) =  r (Reduction (cm, r)   Criticality (r))

6. 6 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Effectiveness matrix: example for library system

7. 7 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Step 3: Determine optimal balance risk reduction vs. countermeasure cost  Cost of each countermeasure cm to be estimated with domain experts  DDP can then visualize... –risk balance charts: residual impact of each risk on all objectives if cm is selected –optimal combinations of countermeasures for risk balance under cost constraints simulated annealing search for near-optimal solutions optimality criterion can be set by user e.g. “maximize satisfaction of objectives under this cost threshold” “minimize cost above this satisfaction threshold”

8. 8 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements evaluation: outline  Inconsistency management –Types of inconsistency –Handling inconsistencies –Managing conflicts: a systematic process  Risk analysis –Types of risk –Risk management –Risk documentation –DDP: quantitative risk management for RE  Evaluating alternative options for decision making  Requirements prioritization

9. 9 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Evaluating alternative options for decision making  The RE process raises multiple alternative options of different types –alternative ways of satisfying a system objective –alternative assignments of responsibilities among system components –alternative resolutions of a conflict –alternative countermeasures to reduce a risk  Preferred alternatives must be negotiated, selected... –agree on evaluation criteria ( e.g. contribution to NFRs) –compare options according to criteria –select best option  Qualitative or quantitative reasoning techniques for this

10. 10 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Qualitative reasoning for evaluating options  Goal  Goal: determine qualitative contribution of each option to important non-functional requirements (NFRs): very positively (++), positively (+), negatively (-), very negatively (--)  Example: meeting scheduling  Qualitative labels “+”, “-” on higher-level NFRs are obtained by bottom- up propagation from lower-level reqs in goal-subgoal refinement/conflict graph ([Chung et al 2000], see chap. 16)  Given “+”, “-” contributions of each option to lowest-level reqs, option with best contribution to critical high-level NFRs is taken

11. 11 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Quantitative reasoning for evaluating options weighted matrix  Build a weighted matrix for... –estimating score of each option on each evaluation criterion (weighted by relative importance) –selecting option with highest overall score on all criteria  For each option opt, criterion crit: Score ( opt, crit ) = estimated score percentage of opt on crit 0 --> 1, Y/100 means “crit satisfied in Y% of cases”  Last line, for each option opt: totalScore (opt) =   crit (Score (opt, crit)   Weight (crit))

12. 12 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements evaluation: outline  Inconsistency management –Types of inconsistency –Handling inconsistencies –Managing conflicts: a systematic process  Risk analysis –Types of risk –Risk management –Risk documentation –DDP: quantitative risk management for RE  Evaluating alternative options for decision making  Requirements prioritization

13. 13 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements prioritization  Elicited & evaluated reqs must be assigned priorities... –conflict resolution –resource limitations (budget, personnel, schedules) –incremental development –replanning due to unexpected problems  Some principles for effective req prioritization... (1) by ordered levels of equal priority, in small number (2) qualitative & relative levels (“higher than”,...) (3) comparable reqs: same granularity, same abstraction level (4) reqs not mutually dependent (one can be kept, another dropped) (5) agreed by key players  Too early ranking at elicitation time might be subjective => risk of inadequate, inconsistent results 

14. 14 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Value-cost prioritization  Systematic technique, meets principles (1) - (3)  Three steps: value 1. Estimate relative contribution of each req to project’s value cost 2. Estimate relative contribution of each req to project’s cost value-cost diagram 3. Plot contributions on value-cost diagram: shows what req fits what priority level according to value-cost tradeoff 

15. 15 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Estimating relative contributions of requirements to project value & cost  AHP technique from Decision Theory (“Analytic Hierarchy Process”, [Saati, 1980] )  Determines in what proportion each req R 1,..., R N contributes to criterion Crit  Applied twice: Crit = value, Crit = cost  Two steps: comparison matrix 1. Build comparison matrix: estimates how R i ’s contribution to Crit compares to R j ’s 2. Determine how Crit distributes among all R i 

16. 16 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons AHP, Step 1: Compare requirements pairwise  Scale for comparing R i ’s contribution to Crit to R j ’s: 17 1: contributes equally 7 : contributes very strongly more 39 3: contributes slightly more 9 : contributes extremely more 5 5 : contributes strongly more  In comparison matrix, R ji = 1 / R ij (1  i, j  N)  Crit: value

17. 17 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons AHP, Step 2: Evaluate how the criterion distributes among all requirements  Criterion distribution = eigenvalues of comparison matrix 2.a Normalize columns: R’ ij := R ij /  i R ij 2.b Average accross lines: Contrib (R i, Crit) =  j R’ ij / N   AHP has rules for ensuring consistent estimates & ratios

18. 18 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Plotting contributions on value-cost diagram cost  Replay Steps 1 & 2 of AHP with Crit = cost  Visualize value/cost contributions on diagram partitioned in selected priority levels 

19. 19 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements evaluation: summary  Inconsistencies are frequent during req acquisition –For clashes in terminology, designation, structure: a glossary of terms is best –For weak, strong conflicts: variety of techniques & heuristics to support cycles “identify overlaps, detect conflicts, generate resolutions, select preferred”  Product-/process-related risks must be carefully analyzed –Loss of satisfaction of system/development objectives –Variety of techniques for risk identification, incl. risk trees & their cut set –Likelihood of risks & consequences + severity need be assessed, qualitatively or quantitatively, with domain experts –Heuristics for exploring countermeasures, selecting cost-effective ones –DDP: an integrated quantitative approach for RE risk management

20. 20 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements evaluation: summary (2)  Alternative options need be evaluated for selecting preferred, agreed ones –Different types, incl. resolutions of conflicts & risks –Qualitative or quantitative reasoning for this (weighted matrices)  Requirements must be prioritized –Due to resource limitations, incremental development –Constraints for effective prioritization –AHP-based value-cost prioritization: a systematic technique Model-driven evaluation provides structure & comparability for what needs to be evaluated (see Part 2 of the book)

21. 21 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons

22. 22 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde

23. 23 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Fundamentals of RE Chapter 4 Requirements Specification & Documentation

24. 24 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons start Chap. 2: Elicitation techniques Chap. 3: Evaluation techniques alternative options agreed requirements documented requirements consolidated requirements Chap. 4: Specification & documentationtechniques Chap.1: RE products and processes

25. 25 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Specification & documentation: as introduced in Chapter 1...  Precise definition of all features of the agreed system –Objectives, concepts, relevant domain properties, system/software requirements, assumptions, responsibilities –Rationale for options taken, satisfaction arguments –Likely system evolutions & variants  Organization of these in a coherent structure  Documentation in a form understandable by all parties –Often in annex: costs, workplan, delivery schedules Requirements Document Resulting product: Requirements Document (RD)

26. 26 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements specification & documentation: outline  Free documentation in unrestricted natural language  Disciplined documentation in structured natural language –Local rules on writing statements –Global rules on organizing the Requirements Document  Use of diagrammatic notations –System scope: context, problem, frame diagrams –Conceptual structures: entity-relationship diagrams –Activities and data: SADT diagrams –Information flows: dataflow diagrams –System operations: use case diagrams –Interaction scenarios: event trace diagrams –System behaviors: state machine diagrams –Stimuli and responses: R-net diagrams –Integrating multiple system views, multi-view spec in UML

27. 27 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements specification & documentation: outline (2)  Formal specification –Logic as a basis for formalizing statements –History-based specification –State-based specification –Event-based specification –Algebraic specification

28. 28 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Free documentation in unrestricted natural language  Unconstrained prose writing in natural language (NL)...  Unlimited expressiveness, communicability, no training needed  Prone to many of the spec errors & flaws (cf. Chap.1) ambiguities  In particular, ambiguities are inherent to NL; can be harmful or and for which “Full braking shall be activated by any train that receives an outdated acceleration command or that enters a station block at speed higher than X m.p.h. and for which the preceding train is closer than Y yards.”  Frequent confusions among logical connectives in NL –e.g. case analysis: If Case1 then or if Case2 then (amounts to true!) vs. If Case1 then and if Case2 then 

29. 29 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Disciplined documentation in structured NL: local rules on writing statements stylistic rules  Use stylistic rules for good NL spec, e.g.  Identify who will read this; write accordingly  Say what you are going to do before doing it  Motivate first, summarize after  Make sure every concept is defined before use  Keep asking yourself: “Is this comprehensible? Is this enough? Is this relevant?”  Never more than one req, assumption, or dom prop in a single sentence. Keep sentences short.  Use “shall” for mandatory, “should” for desirable prescriptions  Avoid unnecessary jargon & acronyms  Use suggestive examples to clarify abstract statements  Supply diagrams for complex relationships among items (More in the book) 

30. 30 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Disciplined documentation in structured NL: local rules on writing statements (2) decision tables  Use decision tables for complex combinations of conditions if input if-conditions then output then-conditions binary filling with truth values one case = AND -combination  Systematic, simple, additional benefits... 2 N –Completeness check: 2 N columns required for full table –Table reduction: drop impossible cases in view of dom props; merge 2 columns differing only by single “T”, “F” => “-” –Test cases for free (cause-effect coverage) 

31. 31 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Disciplined documentation in structured NL: local rules on writing statements (3) statement templates  Use standardized statement templates Identifier Identifier --suggestive; hierarchical if compound statement Category Category --functional or quality req, assumption, domain property, definition, scenario example,... Specification Specification --statement formulation according to stylistic rules Fit criterion Fit criterion --for measurability (see next slide) Source Source --for traceability to elicitation sources Rationale Rationale --for better understanding & traceability Interaction Interaction --contribution to, conflict with other statements Priority Priority level --for comparison & prioritization StabilityCommonality Stability, Commonality levels --for change management 

32. 32 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Fit criteria make statements measurable  Complement statements by quantifying the extent to which they must be satisfied [Robertson, 1999]  Especially important for measurability of NFRs  Spec: Spec: Info displays inside trains shall be informative & understandable Fit criterion Fit criterion: A survey after 3 months of use should reveal that at least 75% of travelers found in-train info displays helpful for finding their connection Spec: Spec: The scheduled meeting dates shall be convenient to participants Fit criterion Fit criterion: Scheduled dates should fit the diary constraints of at least 90% of invited participants in at least 80% of cases

33. 33 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Disciplined documentation in structured NL: global rules on organizing the RD  Grouping  Grouping rules: Put in same section all items related to common factor... –system objective –system component –task –conceptual object –software feature –... templates  Global templates for standardizing the RD structure –domain-specific, organization-specific, company-specific

34. 34 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons IEEE Std-830 template for organizing the RD 1. Introduction 1.1 RD purpose 1.2 Product scope 1.3 Definitions, acronyms, abbreviations 1.4 References 1.5 Overview 2. General Description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions & Dependencies 2.6 Apportioning of requirements 3. Specific Requirements sw-environment boundary: interfaces with users, devices, other sw glossary of terms domain, scope, purpose of system-to-be elicitation sources functionalities of software-to-be assumptions about users development constraints (hw limitations, implem platform,...) environment assumptions (subject to change) optional, deferable reqs

35. 35 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons IEEE Std-830 template for organizing the RD (2) 3. Specific Requirements 3.1 Functional requirements 3.2 External interface reqs 3.3 Performance reqs 3.4 Design constraints 3.5 Software quality attributes 3.6 Other requirements Appendices Index NFRs: development reqs NFRs: interoperability alternative templates for specific types of system NFRs: time/space performance NFRs: quality reqs NFRs: security, reliability, maintainability  Variant: VOLERE template [Robertson, 1999] –explicit sections for domain properties, costs, risks, development workplan,...

36. 36 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Use of diagrammatic notations  To complement or replace NL prose specific aspects  Dedicated to specific aspects of the system (as-is or to-be)  Graphical: to ease communication, provide overview  Semi-formal... –Declaration of items in formal language (syntax, semantics) => surface checks on RD items, machine-processable –Informal spec of item properties in NL  This chapter  This chapter: typical sample of frequently used diagrams, showing complementarities  Part 2  Part 2: in-depth study + systematic method for building complex models using integrated set of diagrams

37. 37 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements specification & documentation: outline  Free documentation in unrestricted natural language  Disciplined documentation in structured natural language –Local rules on writing statements –Global rules on organizing the Requirements Document  Use of diagrammatic notations –System scope: context, problem, frame diagrams –Conceptual structures: entity-relationship diagrams –Activities and data: SADT diagrams –Information flows: dataflow diagrams –System operations: use case diagrams –Interaction scenarios: event trace diagrams –System behaviors: state machine diagrams –Stimuli and responses: R-net diagrams –Integrating multiple system views, multi-view spec in UML

38. 38 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons System scope: context diagrams componentsinterfaces  Declare system components & their interfaces [DeMarco ’78] => system structure what is in system, what is not environment of each component: neighbors, interfaces Handbrake Controller Driver Car handbrake.Sw motor.Regime pedal Pushed button Pressed system component connection through shared phenomenon (data, event)

39. 39 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons System scope: problem diagrams  More detailed form of context diagram: highlights... Machine –the Machine among system components controlsmonitors –for shared phenomenon: who controls it, who monitors it –requirements –requirements, components affected by them Driver Car HC ! handbrake.Sw C ! motor.Regime DR ! {pedalPushed, buttonPressed} Handbrake shall be... activated if the brake button is pressed, released if the acceleration pedal is pushed {pedalPushed, buttonPressed} {BrakeActivation, BrakeRelease} controlling component Handbrake Controller Machine constrains refers to requirement

40. 40 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons System scope: frame diagrams problem patterns  Capture frequent problem patterns CEY –typed phenomena (C: causal, E: event, Y: symbolic) CBX –typed components (C: causal, B: biddable, X: lexical)  E.g. Simple Workpieces, Information Display, Commanded Behavior (see book) Commanded Behavior frame Control Machine Operator Commanded World Component CM ! C1 CWC ! C2 OP! E4 Command-based control rules E4 C3 BC biddable causal event

41. 41 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Reusing problem frames  Candidate system-specific problem diagram can be obtained by instantiation, in matching situations (cf. Chap. 2) –under typing constraints –mutiple frames reusable for same problem world Instantiated Commanded Behavior frame Driver Car HC ! handbrake.Sw C ! motor.Regime DR ! {pedalPushed, buttonPressed} Handbrake shall be activated if the brake button is pressed, released if the acceleration pedal is pushed {pedalPushed, buttonPressed} {BrakeActivation, BrakeRelease} Handbrake Controller

42. 42 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Conceptual structures: entity-relationship diagrams  Declare conceptual items, structure them  Entity  Entity: class of concept instances... –having distinct identities –sharing common features (attributes, relationships) e.g. Meeting, Participant relationship  N-ary relationship: feature conceptually linking N entities, each playing a distinctive role (N  2) –Multiplicity –Multiplicity, one one side: min & max number of entity instances, on this side, linkable at same time to single tuple of entity instances on the other sides e.g. Invitation linking Participant and Meeting  Attribute  Attribute: feature intrinsic to an entity or a relationship –has range of values e.g. Date of Meeting

43. 43 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Entity-relationship diagram: example entity attribute attributes of relationship binary relationship A meeting invites at least 1 up to an arbitrary number of participants role specialization or Multiplicities may capture requirements or domain properties  No distinction between prescriptive & descriptive

44. 44 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Entity-relationship diagrams (2) specialization  Entity specialization: subclass of concept instances, further characterized by specific features (attributes, relationships) –by default, inherits attributes & relationships from superclass –rich structuring mechanism for factoring out structural commonalities in superclasses e.g. ImportantParticipant, with specific attribute Preferences Inherits relationships Invitation, Constraints, attribute Address (Email of ImportantParticipant inhibits default inheritance) annotations  Diagram annotations: to define elements precisely –essential for avoiding spec errors & flaws e.g. annotation for Participant: “Person expected to attend the meeting, at least partially, under some specific role. Appears in the system when the meeting is initiated and disappears when the meeting is no longer relevant to the system”

45. 45 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements specification & documentation: outline  Free documentation in unrestricted natural language  Disciplined documentation in structured natural language –Local rules on writing statements –Global rules on organizing the Requirements Document  Use of diagrammatic notations –System scope: context, problem, frame diagrams –Conceptual structures: entity-relationship diagrams –Activities and data: SADT diagrams –Information flows: dataflow diagrams –System operations: use case diagrams –Interaction scenarios: event trace diagrams –System behaviors: state machine diagrams –Stimuli and responses: R-net diagrams –Integrating multiple system views, multi-view spec in UML

46. 46 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Activities and data: SADT diagrams  Capture activities & data in the system (as-is or to-be)  Actigram  Actigram: relates activities through data dependency links  –East  : input data; West  : output data  –North  : controlling data/event; South  : processor –Activities refinable into sub-activities  Datagram  Datagram: relates data through control dependency links  –East  : producing activity; West  : consuming activity  –North  : validation activity; South  : needed resources –Data refinable into sub-data  Data-activity duality: –data in actigram must appear in datagram –activities in datagram must appear in actigram

47. 47 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons SADT diagrams: actigram example refinement input data output data processor controlling data activity

48. 48 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons SADT diagrams: datagram example producing activity controlling activity consuming activity resource  Consistency/completeness rules checkable by tools –Every activity must have an input and an output –All data must have a producer and a consumer –I/O data of an activity must appear as I/O data of subactivities –Every activity in a datagram must be defined in an actigram,... data

49. 49 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Information flows: dataflow diagrams  Capture system operations linked by data dependencies –simpler but less expressive than actigrams  Operation = data transformation activity  Input, output links = data flows –operation needs data flowing in to produce data flowing out (  control flow !)  Data transformation rule to be specified... –in annotation (structured NL) –or –or in another DFD (operation refinement, cf. SADT)  System components, data repositories = origins, ends of flow  Consistency/completeness rules checkable by tools, cf. SADT

50. 50 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Dataflow diagram: example Initiator Ask Constraints copyOf constraints Request constraintRequest meeting Request meeting Constraints individual Constraints Collect Constraints Participant Merge Constraints participantConstraints Determine Schedule meeting Notification Check Request invalid Request validRequest operation data repository system component input data flow output data flow

51. 51 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons System operations: use case diagrams  Capture operations to be performed by a system component & interactions with other components –yet simpler, outline view... but vague –to be made precise by annotations, interaction scenarios,... –introduced in UML to replace DFDs  Structuring mechanisms... – >: to specify “suboperation” – > + precondition: to specify “variant” operation in exception case

52. 52 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Use case diagram: example Determine Schedule Collect Constraints Scheduler Check Request Initiator Conflict Resolver Participant > Unauthorized > Deny Request Ask Constraints Merge Constraints Resolve Conflicts Participant operationinteraction environment component software component variant operation suboperation every thing good in UML is not new, every thing new in UML is not good operation performer

53. 53 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements specification & documentation: outline  Free documentation in unrestricted natural language  Disciplined documentation in structured natural language –Local rules on writing statements –Global rules on organizing the Requirements Document  Use of diagrammatic notations –System scope: context, problem, frame diagrams –Conceptual structures: entity-relationship diagrams –Activities and data: SADT diagrams –Information flows: dataflow diagrams –System operations: use case diagrams –Interaction scenarios: event trace diagrams –System behaviors: state machine diagrams –Stimuli and responses: R-net diagrams –Integrating multiple system views, multi-view spec in UML

54. 54 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Interaction scenarios: event trace diagrams  Capture positive scenarios by sequences of interactions among instances of system components (cf. Chap. 2) –variants: MSC (ITU), sequence diagrams (UML, cf. Chap. 13)  Parallel composition of timelines –one per component instance  Pairwise directed interactions down timelines –information transmission through event attributes  Interaction event synchronously controlled by source instance & monitored by target instance –total order on events along timeline (event precedence) –partial order on all diagram events

55. 55 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Event trace diagram: example interaction event attribute component instance controls interaction monitors interaction self-interaction timeline

56. 56 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons System behaviors: state machine diagrams  Capture the admissible behaviors of system components  Behavior  Behavior of component instance = sequence of state transitions for the items it controls state  SM state = set of situations where a variable characterizing a controlled item has always the same value –e.g. state MeetingScheduled: always same value for Date, Location (while other variable WithWhom on Meeting may change value) –Initialfinal –Initial, final states = states where item appears, disappears –States may have some duration state transition  SM state transition: caused by associated event –if –if item in source state and event ev occurs then then it gets to target state –Events are instantaneous phenomena

57. 57 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Example of state machine diagram: meeting controlled by a meeting scheduler initial state final state state event guard state transition

58. 58 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons State machine diagrams: transitions and guards  Event occurrence is a sufficient condition for transition firing –Event can be external stimulus (e.g. meetingRequest ) or application of internal operation (e.g. determineSchedule )  Guard = necessary condition for transition firing... –Item gets to target state... if if item is in source state and event ev occurs and only if and only if guard condition is true –Guarded transition with no event label: fires as soon as guard gets true (= trigger condition)  Non-deterministic behavior: multiple outgoing transitions with same event and no or overlapping guards –often to be avoided for safety, security reasons

59. 59 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Scenarios and state machines trace  SM trace = sequence of successive SM states up to some point –e.g. –always finite, but SM diagram may have infinitely many traces generalizes  A SM diagram generalizes ET diagram scenarios: –from specific instances to any component instance –trace coverage: SM traces include ET traces, and (many) more e.g. scenario/SM trace from previous slides: < ValidatingMeetingData; ConstraintsRequested; Planning; MeetingScheduled; MeetingNotified >

60. 60 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Concurrent behaviors and statecharts  Components often control multiple items in parallel  Problems with flat SM diagram... –N item variables each with M values => M N states ! –same SM state mixing up different variables  Statechart  Statechart = parallel composition of SM diagrams [Harel, 1987] –one per variable evolving in parallel state –statechart state = aggregation of concurrent substates –from M N explicit SM states to M  N statechart states !  Statechart trace = sequence of successive aggregated SM states up to some point  Interleaving semantics: for 2 transitions firing in same state, one is taken after the other (non-deterministic choice)

61. 61 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Statechart example  Trace example: < (doorsClosed, trainStopped); (doorsClosed, trainMoving); (doorsClosed, trainStopped); (doorsOpen, trainStopped) >  Model-checking tools can generate counterexample traces leading to violation of desired property (cf. chap. 5) parallel composition variable doorsState variable trainSpeed

62. 62 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Stimuli and responses: R-net diagrams  Capture all required responses to single stimulus [Alford, 1977] –chain of response operations to be performed by a system component –operation may generate stimuli for other R-nets  Decision points, operation application under conditions  Good for visualizing... WHAT IF ? –answers to WHAT IF ? questions –required software reactions to environment events

63. 63 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons R-net diagram: example input stimulus precedence response operation decision point

64. 64 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Integrating multiple system views  Diagrams of different types cover different, complementary views of the system (as-is or to-be) –components & interfaces, conceptual structures, operations, flows, interaction scenarios, behaviors,....  Overlapping aspects => integration mechanism needed for ensuring compatibility & complementarity among diagrams inter-view consistency rules  Standard mechanism: inter-view consistency rules the specifier should meet –cf. static semantics rules enforced by compilers “every used variable must be declared” “every declared variable must be used”,... –can be used for inspection checklists –enforceable by tools –constrain diagram evolution

65. 65 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Inter-view consistency rules: examples problem diagram ET diagram  Every component & interconnection in a problem diagram must be further specified in an ET diagram problem diagram ET diagram ER diagram  Every shared phenomenon in a problem diagram must appear as event in an ET diagram or as entity, attribute, or relationship in an ER diagram DFD diagram ER diagram  Every data in a flow or repository of a DFD diagram must be declared as entity, attribute, or relationship in an ER diagram SM diagram ER diagram  Every state in a SM diagram must correspond to some value for some attribute or relationship in an ER diagram ET scenario SM diagram  Every interaction event in an ET scenario must appear in a corresponding SM diagram

66. 66 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Multi-view specification in UML The Unified Modeling Language (UML) has standardized notations for diagrams relevant to RE  Class diagrams  Class diagrams: ER diagrams for structural view  Use case diagrams  Use case diagrams: outline of operational view  Sequence diagrams  Sequence diagrams: ET diagrams for scenarios  State diagrams  State diagrams: SM diagrams for behavioral view Further studied in Chaps. 10-13 in a systematic method for building multi-view models

67. 67 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Diagrammatic notations: pros & cons  Formal declaration of different system facets + informal annotations of properties for higher precision  Graphical declaration => overview & structuring of important aspects easy to understand, communicate surface-level analysis, supported by tools (e.g. query engines)  Semi-formal specification =>  language semantics may be vague (different interpretations)  only surface-level aspects formalized, not item properties  limited forms of analysis  functional and structural aspects only => formal specification needed for mission-critical aspects

68. 68 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements specification & documentation (1) : summary  Free documentation in unrestricted NL is subject to errors & flaws  Disciplined documentation in structured NL is always necessary –Local rules on statements: stylistic rules, decision tables, statement templates –Global rules on RD organization: grouping rules, structure templates  Diagrams for graphical, semi-formal spec of complementary aspects –System scope –System scope: context, problem, frame diagrams –Conceptual structures –Conceptual structures: entity-relationship diagrams –Activities and data –Activities and data: SADT diagrams –Information flows –Information flows: dataflow diagrams –System operations –System operations: use case diagrams –Interaction scenarios –Interaction scenarios: event trace diagrams –System behaviors –System behaviors: state machine diagrams –Stimuli and responses –Stimuli and responses: R-net diagrams multiple views –Integrating multiple views, multi-view spec in UML

69. 69 www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene  © 2009 John Wiley and Sons Requirements specification & documentation (2) : formal specification  Logic as a basis for formalizing statements  History-based specification  State-based specification  Event-based specification  Algebraic specification