Using Defect Reports to Build Requirements Knowledge in Product Lines2nd International Workshop on Managing Requirements K...
Problem Overview<br />Goal: use defect analysis to incrementally improve the requirements knowledge for a product line<br ...
Results Overview<br />Our analysis of defect reports from testing of flight software product line implicated undocumented,...
Some Related Work<br />Knowledge sharing:  Savolainen and Sajaniemi; Maalej and Happel; Kruchten, Lago & van Vliet<br />Ta...
Application Domain<br />Product line of flight software for spacecraft, previously used on seven missions managed by JPL, ...
Approach<br />Product Lines offer an opportunity for incremental requirements <br />knowledge and quality improvement.<br ...
 Tasks<br />How to capture relevant product-line requirements knowledge from the defect reports<br />Used Orthogonal Defec...
1. Defect-derived Requirements Knowledge<br />Newly discovered requirements,  e.g., complicated interface information surf...
2a). Preserve Defect-derived Tacit Requirements Knowledge<br />Extended Feature Model:<br />FMs are extended with assumpti...
2b). Convey Defect-derived Tacit Requirements Knowledge<br />PLA-DPs (Product Line Analysis-Defect Paradigms)* are stories...
Conclusion<br />Defect reports from past product-line members are a rich, and insufficiently tapped, source of tacit requi...
Upcoming SlideShare
Loading in …5
×

01 Using Defect Reports to Build Requirements Knowledge in Product Lines

970 views
853 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
970
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

01 Using Defect Reports to Build Requirements Knowledge in Product Lines

  1. 1. Using Defect Reports to Build Requirements Knowledge in Product Lines2nd International Workshop on Managing Requirements Knowledge (MaRK’09)<br />Robyn Lutz<br />Flight Software Systems Engineering <br />& Architectures <br />Jet Propulsion Lab/Caltech<br /> & Iowa State University<br />Nicolas Rouquette<br />Flight Software Systems Engineering <br />& Architectures <br />Jet Propulsion Lab/Caltech<br />Pasadena, CA <br />nicolas.rouquette@jpl.nasa.gov<br />rlutz@cs.iastate.edu<br />The research described in this paper was carried out in part at the Jet Propulsion Laboratory, California Institute of Technology ,and funded by NASA’s OSMA <br />Software Assurance Research Program.<br />
  2. 2. Problem Overview<br />Goal: use defect analysis to incrementally improve the requirements knowledge for a product line<br />Approach: use information in defect reports from previous product-line members to improve the quality of future members and reduce their requirements-related defects<br />Challenge: can we improve propagation of the requirements knowledge exposed by past defects to future products in the product line?<br />Courtesy NASA/JPL-Caltech<br />Courtesy NASA/JPL-Caltech<br />2<br />Courtesy Classroom Clipart<br />Courtesy NASA/JPL-Caltech<br />Lutz_Rouquette_MaRK&apos;09<br />
  3. 3. Results Overview<br />Our analysis of defect reports from testing of flight software product line implicated undocumented, tacit requirements information<br />We describe 4 types of new requirements knowledge found in the defect reports <br />We are adapting two mechanisms, new to product lines, to better preserve and convey defect-derived requirements knowledge to upcoming product-line members<br />3<br />Lutz_Rouquette_MaRK&apos;09<br />
  4. 4. Some Related Work<br />Knowledge sharing: Savolainen and Sajaniemi; Maalej and Happel; Kruchten, Lago & van Vliet<br />Tacit knowledge:Grunbacher & Briggs; Stone & Sawyer<br />Rationale management:Dutoit and Paech; Lago & van Vliet<br />Product Lines: Jirapanthong and Zisman; Trew; Cho, Lee & Kang; Pohl, Bockle & van der Linden; Weiss & Lai<br />Defect analysis for improvement:Chillarege et al.; Dalal et al.; Ostrand & Weyuker; Mohagheghi, et al.; Lausen & Vinter; Fenton & Ohlsson; Leszak, Perry & Stoll; Lutz and Mikulski; Shull et al. <br />Power of anecdotes: Petroski, Herschbach, Bayer, Rasmussen, Dvorakthe<br />To the best of our knowledge, the work reported here is the first attempt to systematically use defect analysis to incrementally improve the requirements knowledge for a product line<br />4<br />Lutz_Rouquette_MaRK&apos;09<br />
  5. 5. Application Domain<br />Product line of flight software for spacecraft, previously used on seven missions managed by JPL, with two more missions in development <br />Example of a commonality: all products have software fault protection to respond to power loss <br />Example of a variability: the choice of reaction wheels used to control spacecraft attitude (i.e., position) differs among the products<br />5<br />Lutz_Rouquette_MaRK&apos;09<br />
  6. 6. Approach<br />Product Lines offer an opportunity for incremental requirements <br />knowledge and quality improvement.<br />6<br />Lutz_Rouquette_MaRK&apos;09<br />Defect analysis of earlier PL members, together with forward propagation of results, provides a way to achieve this.<br />
  7. 7. Tasks<br />How to capture relevant product-line requirements knowledge from the defect reports<br />Used Orthogonal Defect Classification to identify defect patterns<br />ODC previously used on spacecraft anomalies [RE’03, TSE’04]<br />How to pro-actively communicate the new requirements-related information to developers of future product-line members<br />Preserve: Specify the information so as to enable retrieval of the defects-learned requirements knowledge by future developers (a “pull” mechanism)<br />Convey: Also need a “push” mechanism so that the requirements knowledge that could have prevented the defects in previous product-line applications will be remembered in future product-line applications <br />7<br />Lutz_Rouquette_MaRK&apos;09<br />
  8. 8. 1. Defect-derived Requirements Knowledge<br />Newly discovered requirements, e.g., complicated interface information surfaced during testing<br />Unexpected requirements dependencies, e.g., incorrect assumptions about relationships among variabilities<br />Tacit* requirements rationales (insufficiently documented or incorrect), e.g., hardware idiosyncrasy known, but not by testers<br />Misunderstood requirements, e.g., software behavior surprised testers, often due to ambiguous or partial documentation <br />*Tacit knowledge: “knowledge that is essential but not documented” [Kruchten, Lago & van Vliet]<br />Lutz_Rouquette_MaRK&apos;09<br />8<br />
  9. 9. 2a). Preserve Defect-derived Tacit Requirements Knowledge<br />Extended Feature Model:<br />FMs are extended with assumption specifications [Lago & van Vliet, ICSE’05]<br />9<br />Lutz_Rouquette_MaRK&apos;09<br />
  10. 10. 2b). Convey Defect-derived Tacit Requirements Knowledge<br />PLA-DPs (Product Line Analysis-Defect Paradigms)* are stories of past PL anomalies, packaged in the product-line repository & told to future PL projects to “remember old lessons learned”<br />“During testing on MRO the power software got confused [defect due to erroneous assumption] when the Reaction Wheel (to aim the spacecraft) was turned off by an uplinked software command & right back on by the fault-protection software. It turned out that there was a race condition which revealed a new software requirement. This is why [rationale] the software sometimes disables the schedule-verification function when the switch is being commanded.”<br />Courtesy Classroom Clipart<br />*Modeled on Petroski’s Design Paradigms<br />10<br />Lutz_Rouquette_MaRK&apos;09<br />
  11. 11. Conclusion<br />Defect reports from past product-line members are a rich, and insufficiently tapped, source of tacit requirements knowledge for future product-line members<br />Future work will expand scale (to include more members of the product line) and continue investigating how to better preserve and convey defect-derived requirements knowledge <br />feature models extended with assumption specifications (formal)<br />structured anecdotes of paradigmatic product-line defects (informal)<br />11<br />Lutz_Rouquette_MaRK&apos;09<br />

×