PABRE: Pattern-Based Requirements Elicitation
Download as PPT, PDF2 likes565 views
The document discusses the PABRE method, which is a pattern-based requirements elicitation approach aimed at enhancing the efficiency and quality of requirements engineering processes particularly for off-the-shelf systems in call-for-tender situations. It highlights the importance of leveraging previous project knowledge and requirement patterns to improve consistency and reduce redundancy in requirement books. Various aspects such as catalog structure, pattern evolution, and the potential impacts on procurement processes are explored, suggesting a need for ongoing research and practical application.
PABRE: Pattern-Based Requirements Elicitation
- 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. 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. 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. 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. 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. Call-for-tender processes Call-for-tender processes are different: products under considerat ion acquired requirements products under consideration acquired requirements
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Consolidation of Requirement Books Hand-made ◦ Not much information ◦ Repeated over and over ◦ Easy to align
- 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. Analysis of Requirement Books Contents Structure Impact on process
- 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. Analysis of Requirement Books Contents Structure ◦ different recurrent situations were identified ◦ concepts emerged: form, extension, … ◦ embraced in a meta-model Impact on process
- 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. 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. 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. 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. 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: …
- 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. 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. 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. 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. Link with the catalogue
- 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. 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. 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. 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. 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. 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. 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. 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. Thanks for your attention! Please let me know any suggestion or interest