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

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: …

27. Metamodel (simplified)

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