PABRE: Pattern-Based Requirements Elicitation

PABRE: Pattern-Based Requirements

Elicitation

Samuel RenaultCITI, CRPHT

Óscar Méndez, Xavier Franch, Carme QuerGESSI, UPC

RCIS’09 – Fès, Morocco

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

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

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

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, …)

products under

consideration


Call-for-tender processes

Call-for-tender processes are different:

products under

consideration


products under

consideration


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

The CITI-CRPHT case

Call for tenders

IT Consultant

Needs

Customer Organization

Requirements

Knowledge of previous

projects

Supplier

Bid

SupplierSupplier

Requirements

BookEvaluation

OTS-basedSolution

AcquisitionAgreement

Bid Bid

Requirements Elicitation

Near 50 projects for SMEs supervised on business-oriented,coarse-grained OTS components in the last years

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

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

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



A language of requirement patterns

◦ catalog + relationships

◦ goal: producing requirements in natural language

Impacts the call-for-tenders process:

◦ pattern identification + application



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

Call for tenders

IT Consultant

Needs


Requirements

Supplier

Bid

SupplierSupplier

Requirements

BookEvaluation

OTS-basedSolution


Bid Bid


Reqt.Patterns

Language

FeedbackRepository

CatalogEvolution

Knowledge of reqt. patterns


projects


projects

The CITI-CRPHT case revisited

Research approach

Requirement Patterns Catalog

Consolidation

Analysis

Metamodel

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

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

Consolidation of Requirement Books

Hand-made◦ Not much information

◦ Repeated over and over

◦ Easy to align

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

Analysis of Requirement Books

Contents

Structure

Impact on process


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, …)

Non-functional requirements were essentially the same

Structure

Impact on process

First iteration: focus on non-functional requirements


Contents

Structure◦ different recurrent situations were identified

◦ concepts emerged: form, extension, …

◦ embraced in a meta-model

Impact on process


Contents

Structure

Impact on process◦ a new process for consultants emerged:

PABRE: Pattern-Based Requirements Elicitation

◦ includes collecting feedback information (for catalog evolution purposes)

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

Index


Pattern template

Requirement Pattern

Failure Alerts

Goal Alert the user about failures

Description …see paper

Comments …see paper

Sources RB xyz, rqt. 3.1.2; …

Keywords Failure, Alert, Crash

Dependencies

IMPLIES: Failure Reports…

Other metadata…

Form 1

…

Form n

Pattern template

Require-ment Form

Alert Types

Dependenton

Failure Types

Description

…see paper

Comments Specific Dependence: may (usually will) be applied more than once; different AL’s should not overlap

Other metadata…

Fixed part text

The system shall trigger alerts of a certain type depending on the type of failure

Extension Specific Dependence

Extension text

An alert of one of the types AL shall be gi-ven for a failure of some of the types FL

Parameter AL: Set(AlertType), AL ØAlertType = Nominal(e-mail, …)

Parameter FL: …

Metamodel (simplified)

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:

Processing after application is not strictly necessary, although left to consultant’s preference

The DB structure should be able to be adapted internally (e.g., merging attributes or tables) without blocking upgrades

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

Index


Classification schemas

We keep separated the raw contents of the catalog and

they way it can be classified

- Req Pattern 1- Req Pattern 2.- Req Pattern i.- Req Pattern x

ISO/IEC 9126-1ClassificationSchema

CRPHTClassificationSchema

OtherClassificationSchema Reqt. Pattern Catalogue

Link with the catalogue

Index


Call for tenders

IT Consultant

Needs


Requirements

Supplier

Bid

SupplierSupplier

Requirements

BookEvaluation

OTS-basedSolution


Bid Bid


Reqt.Patterns

Language

FeedbackRepository

CatalogueEvolution

Knowledge of reqt. patterns


projects

The PABRE process

Requirementcreation

Requirementextraction

S.0Select next

pattern

S.1Read the pattern

(description &goal)

D.2Check if

interested bythe pattern

no

S.8Select values for

parameters (if any)

chosen parts

S.10Create newrequirement

without pattern

S.5Read the

parts

some

Feedback:Statistics on use

of pattern


of parameters


of forms

Feedback:Reason for not

using the pattern

yes

S.2Read the

forms

S.2Skip pattern


of partsmissing

parts

O.2New requirement

O.1Pattern used

Form+Parts+Values

D.1Set importance

of pattern

high

low

D.4Check

consistency

Partsexploration

Formsexploration

Patternsexploration

no

based on dependencyrelationships

none

based onclassification and/or

relationships

S.9Resolve conflicts

(if any)

D.3Check if

pending needsfor scope

S.4Choose most

appropriate form forthe pattern

S.6Choose extended

part that apply

S.7Read detailedinformation for

parameters

S.11Create new

requirement form forselected pattern

yes

S.12Create new

requirement part(s)for selected form

O.3New requirement

part(s)

The PABRE Method

Assumptions:

◦ May be patterns missing

◦ Not-automatic process

◦ Atomicity of information

◦ Complete classification schemas

◦ Process guided by one classification schema

◦ Catalogue existence made transparent to the customer

Requirementcreation


S.0Select next

pattern

S.1Read the pattern

(description &goal)

D.2Check if

interested bythe pattern

no

S.8Select values for

parameters (if any)

chosen parts

S.10Create newrequirement

without pattern

S.5Read the

parts

some


of pattern


of parameters


of forms

Feedback:Reason for not

using the pattern

yes

S.2Read the

forms

S.2Skip pattern


of partsmissing

parts

O.2New requirement

O.1Pattern used

Form+Parts+Values

D.1Set importance

of pattern

high

low

D.4Check

consistency

Partsexploration

Formsexploration

Patternsexploration

no

based on dependencyrelationships

none

based onclassification and/or

relationships

S.9Resolve conflicts

(if any)

D.3Check if

pending needsfor scope

S.4Choose most

appropriate form forthe pattern

S.6Choose extended

part that apply

S.7Read detailedinformation for

parameters

S.11Create new

requirement form forselected pattern

yes

S.12Create new

requirement part(s)for selected form

O.3New requirement

part(s)

The PABRE Method

Select next patternSelect next pattern

classification schema

dependencies among patterns

keywords

others: qualifiers…

High-level view

Formsexploration

Partsexploration


requirement from

catalogue

Requirementcreation

(part of) requirement from scratch

chosen parts

missing parts

some form applies

no form applies

pattern applies

pattern does not applyANDpending needs for classifier

Patternsexploration

next

+ information for catalogue evolution

Index


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

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

Thanks for your attention!

Please let me know any suggestion or interest

PABRE: Pattern-Based Requirements Elicitation

Technology

ots integration ots

shelf ots

otsbased systems

modified data

software requirements

different ots components

encrypted data

essential data