Requirements Evolution. Ch. 6 Lecture Notes IN4MTX 113 February 2010

Transcription

1 Requirements Evolution Ch. 6 Lecture Notes IN4MTX 113 February 2010

2 Chapter 6 Topics Sources of change Versions (Revisions) and Variants Configuration Management Change propagation Trace links Verifiability Organization of a requirements document for change 2

3 Versions and Variants Versions: new in time sequence Variants: members of a product family having some features in common 3

4 4 A Simple Product Family

5 Configuration Management Version control systems (VCSs) capture the items to be versioned, the common properties shared by all version of an item, and the deltas [and also] determines the way version sets are organized [Clemm 2002] An Extensional approaches retrieve reversions of artifacts that have been previously checked in [Conradi 1998] Intensional approaches construct artifact versions based on rules describing consistent combinations [Conradi 1998] Example: Subversion Version Control with Subversion 5

6 Change Propagation What work do you have to do if: An error is found in a requirments document? A requirement is found to be infeasible (as a result of trying to design or program a solution) How does this change when managing a product family? Example: suppose the accelerator pedal sticks in a car -- what models do you recall/fix? 6

7 7 Trace links

8 Motivating Scenario Req Spec Func Spec Java package X Statecharts Test Suites X Use Cases Structural Design

9 Motivating Scenario Req Spec Func Spec Java package X Statecharts Module X Bug reports Test Suites Module X Test Results X Use Cases Notes Structural Design Sequence Charts Gantt Chart Mgmt Reports Module X

10 Why Software Traceability? It minimizes access time to relevant software artifacts Questions Why is this component used? Can it be replaced? Who owns the related artifacts? Is the component tested? Does it meet requirements (if it exists)? Traceability aids in System comprehension & impact analysis [Lindvall 1996, Ramesh 2001, Jarke 1998] Communication between stakeholders [Pohl 1994] System debugging [Jarke 1998, Richardson 2004]

11 Multi-faceted Traceability Problem High cost [Jarke 1998, Ramesh 2001] Explosion of artifact/relationship space [Domges 1998, Ramesh 2001] Link deterioration [Hayes 2007, Ramesh 2001] Heterogeneity of artifacts [Anderson 2002, Lindvall Practical] Heterogeneity of tools [Domges 1998, Gotel 1994, Ramesh 1995] Different groups [Gotel 1994, Ramesh 1995, Ramesh 2001] Different expectations [Gotel 1994, Ramesh 2001] Low motivation [Appleton 2005, Almeida 2006, Jarke 1998, Alexander 2002, Hayes 2005] Others privacy, politics, low priority, lack of time [Domges 1998, Gotel 1994, Jarke 1998, Ramesh 1995, Lindval 1996]

12 Current approaches Information Retrieval Techniques Automatically generated links have limited link semantics [Spanoudakis 2005] Usually require pre- & post-processing [Cleland-Huang 2007] Software Repository Mining Specialized searches & retrospective capture of links [Zimmerman 2004, Cubranic 2005] Design Rationale Difficult to retrieve & use [Horner 2005] Compendium [Shum 2006] capturing rationale requires significant effort ARM [Tang 2005] caters mainly to architects and assumes the existence of requirements prior to design Current Link Technology XML Topic Maps enable manual capture of links

13 Insights Experience in building an industrial software traceability tool Software Architecture Open Hypermedia e-science

14 ACTS X Local net Req Spec Statecharts Architect perspective Module X X Developer perspective X QA perspective X Test Suites Java package X Field engineer perspective Module X Test Results Bug reports Internet X Internet Module X

15 Chapter 6

16 Determine meeting date date Notify invited participants more stable than Determine meeting location date Use date preferences Use participant status more stable than Rule-based conflict resolution Notify participants by SMS Figure 6.2 Ordering features by levels of stability or commonality

17 Objectives, domain concepts, requirements, assumptions forward horizontal backward Architectural components & connectors vertical Source code Test data User manual Figure 6.3 Traceability links: forward, backward, horizontal, and vertical traceability

18 Dependency link Inter-version link Intra-version link Subtype Variant Revision Derivation Use Figure 6.4 A taxonomy of traceability link types

19 A affects dependson Dependency Figure 6.5 Dependency link type B

20 A master variantof B Variant Figure 6.6 Variant link type

21 A previous next Revision Figure 6.7 Revision link type B

22 A usedby uses Use Figure 6.8 Use link type B

23 A metby derivedfrom Derivation Figure 6.9 Derivation link type B

24 SOFREQ: software requirements ASM: environment assumptions Derivation SysReq: system requirement DOM: domain properties REQ: requirements ASM: environment Derivation G: system objective DOM: domain properties OP: system operations Derivation G: system objective Figure 6.10 Derivational traceability links implied by satisfaction arguments

25 Inter-version dependencies Intra-version dependencies Variant CM attributes Revision CM attributes VariantOf MasterVersion NextTo PreviousFrom 0..* RD item RefName Spec 1..* MetBy UsedBy 0..* Uses 0..* DerivedFrom Use Derivation 1..* Variant CM attributes VariantOf MasterVersion 0..* 0..1 SW lifecycle item DerivedFrom Revision CM attributes NextTo PreviousFrom RefName Spec Figure 6.11 Item traceability: an entity-relationship model

26 Inter-version dependencies Intra-version dependencies MS interface requirements Revision MS interface reqs + GSM interface reqs RefName: MSI/GSM Spec:. Use Objective: Anywhere anytime notification RefName: AA-Notif Spec:. Derivation Use Participant notification requirements Revision NextTo Uses DerivedFrom Notification requirements + SMS notification RefName: Notif+SMS Spec:. DerivedFrom Derivation Notifier Module Specs Notification Test Data User Manual Sect.: Notification RefName: NMS Spec:. RefName: NTD Spec: RefName: UMN Spec: Figure 6.12 Item traceability: model instantiation to meeting scheduling

27 Define traceability policy Establish traceability links Exploit traceability links Maintain traceability links Figure 6.13 Traceability management

28 T4 T3 T5 T1 T2 Figure 6.14 Single-relation traceability graph represented by the matrix in Table 6.2

29 MeetingScheduling MeetingInitiation MeetingNotification ConstraintsAcquisition Planning RuleBased ConflictResolution by bye-agenda Dates Dates&Locations by bysms WithoutPreferences WithPreferences Figure 6.15 Feature diagram for variants of the meeting scheduling system

30 Change initiation Change evaluation and prioritization Change consolidation Figure 6.16 Change control

31