PABRE: Pattern-Based Requirements Elicitation

372 views
260 views

Published on

Presentation of the paper: PABRE: Pattern-Based Requirements Elicitation at RCIS 2009
Authors: Renault, S. ; Mendez-Bonilla, O. ; Franch, X. ; Quer, C.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5089271

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
372
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

PABRE: Pattern-Based Requirements Elicitation

  1. 1. PABRE: Pattern-Based Requirements Elicitation Samuel Renault CITI, CRPHT Óscar Méndez, Xavier Franch, Carme Quer GESSI, UPC RCIS’09 – Fès, Morocco
  2. 2. Index  Motivation. Call-for-tender Processes  The CRPHT case  Analysis of Requirement Books  Structure of the Catalog  Classification Schemas  The PABRE Method  Conclusions and Future Work
  3. 3. OTS-based systems Off-The-Shelf- (OTS-) Based Systems  Systems that are mostly composed of different OTS components customized and glued together  Several particular activities arise ◦ Market watching ◦ OTS integration ◦ … ◦ OTS selection
  4. 4. OTS Selection Processes Classical OTS Selection Processes overlap RE and Component Screening products under consideration acquired requirements Iteration nicely captures the idea of reconciling requirements and actual market offering But it does not fit well in call-for-tender processes
  5. 5. Call-for-tender processes OTS selection processes conducted by a public document that contains the requeriments and evaluation rules of the system-to-be Usually:  Public administrations  Great impact on the organization  Transparency is a must  Involve coarse-grained OTS components (ERP, CRM, SCM, …)
  6. 6. Call-for-tender processes Call-for-tender processes are different: products under considerat ion acquired requirements products under consideration acquired requirements
  7. 7. Index  Motivation. Call-for-tender Processes  The CRPHT case  Analysis of Requirement Books  Structure of the Catalog  Classification Schemas  The PABRE Method  Conclusions and Future Work
  8. 8. The CITI-CRPHT case Need s Knowledge of previous projects IT Consultant Customer Organization Supplier Supplier Supplier Call for tenders Bid Requirements Requirements Elicitation Bid  Requirements Book Bid OTS-based Solution Evaluation Acquisition Agreement Near 50 projects for SMEs supervised on business-oriented, coarse-grained OTS components in the last years
  9. 9. A sample of the requirements found (DMS) An easy-to-use mechanism shall allow binding a publication to an event. The pre-publishing actions (control, validation, etc.) will be identified for each type of workflow. The system must be available 22 hours per day and 7 days per week. The system should not stop more than 1 hour per working day. The solution’s availability rate should be 98% minimum. The solution should permit to trace all the user actions. The data to trace are: user name, date, accessed or modified data. The solution should have a graphical interface for all the functionalities presented. A Web interface for external access is also necessary
  10. 10. The challenge Knowledge Capitalization  requirement books have many similarities  how to transfer knowledge from one project to others  should lead to: ◦ more efficient requirements engineering processes ◦ requirement books with better quality  completeness, uniformity, understandability ◦ more efficient OTS-component evaluation
  11. 11. The adopted solution Requirement Patterns  An approach to specifying a particular type of reqt. cf. Software Requirements Patterns, S. Withall, 2007  Benefits: ◦ guidance ◦ saving of time ◦ consistency ◦ (in call-for-tenders) easier to guide later evaluation
  12. 12. The adopted solution Requirement Patterns  A language of requirement patterns ◦ catalog + relationships ◦ goal: producing requirements in natural language  Impacts the call-for-tenders process: ◦ pattern identification + application
  13. 13. The adopted solution Requirement Patterns  New processes emerge: ◦ pattern catalog construction and evolution ◦ all the processes shall be as lightweight as possible  A practical process: ◦ may fill the industrial gap among theory and practice
  14. 14. The CITI-CRPHT case revisited Need s Knowledge of of reqt. previous patterns projects IT Consultant Customer Organization Supplier Supplier Supplier Call for tenders Bid Requirements Requirements Elicitation  Requirements Book Knowledge of previous projects Reqt. Patterns Language Catalog Evolution Bid Feedback Repository Bid OTS-based Solution Evaluation Acquisition Agreement
  15. 15. Research approach Metamodel Analysis Requirement Patterns Catalog Consolidation  Elicitation of patterns: expert assessment ◦ Systematic (opportunistic in the future)  Contents of the catalog: conservative ◦ Style used by consultants is adopted  Iterative ◦ Driven by case studies
  16. 16. Index  Motivation. Call-for-tender Processes  A Case Study: the CRPHT case  Analysis of Requirement Books  Structure of the Catalog  Classification Schemas  The PABRE Method  Conclusions and Future Work
  17. 17. Consolidation of Requirement Books  Hand-made ◦ Not much information ◦ Repeated over and over ◦ Easy to align
  18. 18. Similarities in different RBs The solution should permit the trace of the modifications and access to the encrypted data in the database. The essential data to trace are: user name, date, accessed or modified data. The solution should permit to trace all the user actions. The data to trace are: user name, date, accessed or modified data. All the operations made over a type of object (dossier, document files, etc.) may be traced The solution should permit to trace all the access to protected data. The data to trace are: user name, date, accessed or modified data. An historical record of this accesses must be maintained
  19. 19. Analysis of Requirement Books  Contents  Structure  Impact on process
  20. 20. Analysis of Requirement Books  Contents ◦ About 7 * (120+70) requirements ◦ The potential benefits of patterns became evident ◦ Functional and non-functional requirements were (not surprisingly) radically different as “pattern-able”:  Functional requirements were different for different types of OTS components (ERP systems, CRM systems, …) First iteration: focus on non-functional requirements  Non-functional requirements were essentially the same  Structure  Impact on process
  21. 21. Analysis of Requirement Books  Contents  Structure ◦ different recurrent situations were identified ◦ concepts emerged: form, extension, … ◦ embraced in a meta-model  Impact on process
  22. 22. Analysis of Requirement Books  Contents  Structure  Impact on process ◦ a new process for consultants emerged: PABRE: Pattern-Based Requirements Elicitation ◦ includes collecting feedback information (for catalog evolution purposes)
  23. 23. Related work: main sources  General work on requirement patterns ◦ basically Withall’s textbook  Other proposals, many domain-oriented ◦ remarkably Konrad&Cheng  Patterns for building models ◦ but we are interested in natural language  Requirements metamodels ◦ especially REMM due to its aim
  24. 24. Index  Motivation. Call-for-tender Processes  A Case Study: the CRPHT case  Analysis of Requirement Books  Structure of the Catalog  Classification Schemas  The PABRE Method  Conclusions and Future Work
  25. 25. Pattern template Goal Description Requirement Pattern Failure Alerts Alert the user about failures …see paper Comments …see paper Sources RB xyz, rqt. 3.1.2; … Keywords Failure, Alert, Crash Dependencies IMPLIES: Failure Reports… Other metadata…
  26. 26. Pattern template Description …see paper Comments Specific Dependence: may (usually will) be applied more than once; different AL’s should not overlap Other metadata… Requirement Form The system shall trigger alerts of a certain type Fixed part depending on the type of failure text Extension Specific Dependence Alert Types Dependen ton Failure Types Extension text Parameter Parameter An alert of one of the types AL shall be gi-ven for a failure of some of the types FL AL: Set(AlertType), AL ≠ Ø AlertType = Nominal(e-mail, …) FL: …
  27. 27. Metamodel (simplified)
  28. 28. Observations  Observations: ◦ 32 patterns identified  44 forms (1-3, 9-2, 23-1)  79 extensions ◦ Coverage: no less than 90% of NF requirements  Example of uncovered requirement: The DB structure should be able to be adapted internally (e.g., merging attributes or tables) without blocking upgrades  Processing after application is not strictly necessary, although left to consultant’s preference
  29. 29. Ongoing work  The concepts presented so far illustrate the current form of the metamodel  We are currently considering some other concepts: ◦ Types of extensions ◦ Modifiers ◦ Qualifiers ◦ Patterns for patterns ◦ Derived requirements
  30. 30. Index  Motivation. Call-for-tender Processes  A Case Study: the CRPHT case  Analysis of Requirement Books  Structure of the Catalog  Classification Schemas  The PABRE Method  Conclusions and Future Work
  31. 31. Classification schemas  We keep separated the raw contents of the catalog and they way it can be classified ISO/IEC 9126-1 Classification Schema CRPHT Classification Schema Other Classification Schema - Req Pattern 1 - Req Pattern 2 . - Req Pattern i . - Req Pattern x Reqt. Pattern Catalogue
  32. 32. Link with the catalogue
  33. 33. Index  Motivation. Call-for-tender Processes  A Case Study: the CRPHT case  Analysis of Requirement Books  Structure of the Catalog  Classification Schemas  The PABRE Method  Conclusions and Future Work
  34. 34. The PABRE process Need s Knowledge of reqt. patterns IT Consultant Customer Organization Supplier Supplier Supplier Call for tenders Bid Requirements Requirements Elicitation  Requirements Book Knowledge of previous projects Reqt. Patterns Language Catalogue Evolution Bid Feedback Repository Bid OTS-based Solution Evaluation Acquisition Agreement
  35. 35. The PABRE Method based on classification and/or relationships S.0 Select next pattern Patterns exploration D.3 Check if pending needs for scope no S.1 Read the pattern (description & goal) S.2 Skip pattern D.1 Set importance of pattern D.2 Check if interested by the pattern Feedback: Reason for not using the pattern  yes ◦ May be patterns missing no low high Forms exploration Feedback: Statistics on use of pattern ◦ Not-automatic process yes S.10 Create new requirement without pattern S.2 Read the forms O.2 New requirement Feedback: Statistics on use of forms S.4 Choose most appropriate form for the pattern none S.11 Create new requirement form for selected pattern O.3 New requirement part(s) some Parts exploration Feedback: Statistics on use of parts S.5 Read the parts S.12 Create new requirement part(s) for selected form Requirement creation S.6 Choose extended part that apply missing parts chosen parts Feedback: Statistics on use of parameters based on dependency relationships S.8 Select values for parameters (if any) D.4 Check consistency ◦ Atomicity of information ◦ Complete classification schemas ◦ Process guided by one classification schema ◦ Catalogue existence made transparent to the customer S.7 Read detailed information for parameters O.1 Pattern used Form+Parts+Values Assumptions: S.9 Resolve conflicts (if any) Requirement extraction
  36. 36. The PABRE Method based on classification and/or relationships S.0 Select next pattern Patterns exploration D.3 Check if pending needs for scope no S.1 Read the pattern (description & goal) S.2 Skip pattern D.1 Set importance of pattern D.2 Check if interested by the pattern Feedback: Reason for not using the pattern yes no low high Forms exploration Feedback: Statistics on use of pattern Select next pattern yes S.10 Create new requirement without pattern S.2 Read the forms O.2 New requirement Feedback: Statistics on use of forms S.4 Choose most appropriate form for the pattern none S.11 Create new requirement form for selected pattern O.3 New requirement part(s) some Parts exploration Feedback: Statistics on use of parts S.5 Read the parts Requirement creation S.6 Choose extended part that apply missing parts S.7 Read detailed information for parameters  others: qualifiers… Feedback: Statistics on use of parameters based on dependency relationships S.8 Select values for parameters (if any) D.4 Check consistency  dependencies among patterns  keywords chosen parts O.1 Pattern used Form+Parts+Values  classification schema S.12 Create new requirement part(s) for selected form S.9 Resolve conflicts (if any) Requirement extraction
  37. 37. High-level view next Patterns exploration pattern does not apply AND pending needs for classifier pattern applies no form applies Requirement information for Forms + exploration creation catalogue evolution some form applies Parts exploration missing parts chosen parts Requirement extraction (part of) requirement from scratch requirement from catalogue
  38. 38. Index  Motivation. Call-for-tender Processes  A Case Study: the CRPHT case  Analysis of Requirement Books  Structure of the Catalog  Classification Schemas  The PABRE Method  Conclusions and Future Work
  39. 39. Conclusions  Ongoing, applied work on reqt. patterns application ◦ ◦  Benefits: elicitation, RB quality, insights gained Drawback: heaviness? Current characteristics of applicability: ◦ Call-for-tender processes ◦ Coarse-grained, business-application OTS components ◦ Requirements expressed in natural language ◦ Knowledge exists ◦ Not much requirements But some of them seem not inherent of the approach
  40. 40. Future work  Case studies  Improvements on catalogue structure  Link with the functional part  Further opportunities to explore: ◦ Etapatelecom (Ecuador) ◦ some isolated call for tenders in Barcelona  Patterns web site  Formalization and automatization
  41. 41. Thanks for your attention!  Please let me know any suggestion or interest

×