There are many approaches to reuse in software engineering. Among them, patterns hold a prominent position. "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" (Alexander, 1979). We are interested in the use of patterns for the requirements analysis stage, namely Software Requirement Patterns. The patterns applicability to this context is clear, since requirements that appear over and over in requirements books could be identified as the solution to particular problems in a given context (the classical context-problem-solution scenario of patterns). Presentation of Software Requirement Patterns in the PABRE framework.

1. SOFTWARE
REQUIREMENT PATTERNS
GESSI
Cristina Palomares
Software Engineering for Information Systems Group
10/11/2010

2. GESSI: Software Requirement Patterns
Outline
1.
2.
3.
4.
5.
6.
7.
8.
Introduction
Example
Metamodel
SRP Catalogue
PABRE Method & Tools
Validation
Conclusions
Future work

3. GESSI: Software Requirement Patterns
1. INTRODUCTION

4. GESSI: Software Requirement Patterns
Context
Patterns
RequirementsEl
icitationStage
(less global errors)
RequirementsB
ook
Patterns
(more reqs. quality)
Requirement
(natural
language)
The system shall provide
the user interface available
in languagesSet languages.
4

5. GESSI: Software Requirement Patterns
What is the problem?
•
•
PROBLEM: Most of the requirements books contains ambiguous,
incomplete or incoherent requirements, and sometimes they are stated
in an unsystematic way.
SOLUTION: Software Requirement Patterns (SRP).
 Pattern
– Alexander, 1979 ‘‘each pattern describes a problem which occurs over and
over again in our environment, and then describes the core of the solution
to that problem’’
 Requirement Pattern
– Withall, 2007 ‘‘a requirement pattern is a guide to writing a particular type
of requirement’’
Patterns
•
BENEFITS
1. +↑ quality of requirements
2. −↓ time and effort spent during requirements elicitation ( economic saving).
Requirements
Elicitation Stage
(less global errors)
Requirements
Book
Patterns
(more reqs. quality)
Requirement
(natural
language)
The system shall provide
the user interface available
in languagesSet languages.
5

6. A Specific Organization
GESSI: Software Requirement Patterns
SSI department, Centre de Recherche Publique Henri Tudor (CRPHT)
• Helping SME with no experience in Requirements Engineering.
• Designing requirement books to conduct Call-For-Tender processes for
selecting Off-The-Shelf solutions.
1. The system must be available 22 hours
per day and 7 days per week.
2. Should be possible to use the system in English
or French.
3. The system should not stop more than 1
hour per working day. The solution’s
availability rate should be 98% minimum.
4. The solution should permit to trace all the user
actions. The data to trace are: user name, date,
accessed or modified data.
• More than 40 projects done.
• Appliedreuse: starting a new projectbyeditingthemost similar one.
• Better capitalization of requirements in a high-level manner.
• Avoiding ambiguous, incomplete or incoherent requirements.
Strategy
• Software RequirementsPatterns (SRP).
6

7. GESSI: Software Requirement Patterns
2. EXAMPLE

8. Example: Failure Alerts
GESSI: Software Requirement Patterns
Pattern’s Goal: Having system that provides alerts when system failures occur.
How do their requirements look like?
The solution should alert of disks close to their capacity .
alert
disks closetotheircapacity
In case of a network orserver disk crash the solution should alert immediately.
networkor server disk crash,
alert
The system should alert the administrator of the resources (physical or logical)
alert
resources (physicalorlogical)
closetotheircapacity
close to their capacity.
Requirement
template
The system shall trigger alerts in case of
failuresSet failures.
 failuresSet : set of possibleFailures
o possibleFailures: server crash | disk crash …
8

9. Example: Failure Alerts
GESSI: Software Requirement Patterns
Requirement Pattern Failure Alerts
Goal: Satisfy the customer need of having a system that provides alerts when system failures occur.
Template
The system shall trigger an alert in case of failure.
Extended
Fixed Part
multiplicity(Alerts Types) = 0..1 and
Parts
Constraint multiplicity(Failure Types) = 0..1
Requirement
Extended Part
Form
Homogeneous Alert Types
Failure Alerts
Template
The solution shall trigger %alertsSet% alerts in case of failure
Metric
Parameter
alertsSet alertsSet: Set(AlertType) Fax | Sound ….
AlertType: SMS | Mail |
Template
The system shall trigger alerts in case of %failuresSet% failures
Metric
Extended Part Parameter
Failure Types
failuresSet failuresSet: Set(FailureType) crash …
FailureType: server crash | disk
Template
Fixed Part
Requirement
Form
Heterogeneous
Failure Alerts
Thesystemshalltriggerdifferenttypes
failure.
of
alertsdependingonthetype
Extended
Parts
Constraint
of
Multiplicity(Alerts for Failure Types) = 0..*
Thesystemshalltrigger %alertsSet% alerts in case of %failuresSet%
failures.
Metric
Parameter
alertsSet alertsSet: Set(AlertType) Fax | Sound ….
AlertType: SMS | Mail |
failuresSet failuresSet: Set(FailureType) crash …
FailureType: server crash | disk
Template
Extended Part
Alerts for
Failure Types
9

10. GESSI: Software Requirement Patterns
3. METAMODEL

11. GESSI: Software Requirement Patterns
Metamodel – SRP Structure
A patternrepresents a cluster of
requirements (a group of
interrelatedrequirements).
Example:
Failure Alerts
A requirement
pattern…
A form captures a particular context that may
be the most appropiatefor a software project.
… has several
forms …
Examples:
Homogeneous Failure Alerts
Heterogeneous Failure Alerts
... and several
constrainst(s).
… that are made of 1
fixed part …
... and several
extended part(s)…
For declaring multiplicities or dependencies
among parts.
Examples:
excludes, requires …
A fixed partcontainsthemost
abstractexpression of a requirement.
A extended part contains other ways to
express a requirement (often with parameters).
Example:
The system shall trigger an
alert in case of failure.
Examples:
The system shall trigger an alert in
case of failure.
alert: SMS | Mail | Fax | Sound | …
failure: network crash | disk crash | …
11

12. GESSI: Software Requirement Patterns
Metamodel - Overview
CatalogueClas
sification
/
Core: SRP
Relationship
Application
PartsRelationshipexample:
Alerts for Failure Types↔ Data Integrity by Failure
(Failure Alerts)
(Recovery Procedures)
The system shall trigger alertsSet alerts in case
of failuresSet failures
Data shall be protected in case of failuresSet
failures.
12

13. GESSI: Software Requirement Patterns
4. SRP CATALOGUE

14. GESSI: Software Requirement Patterns
SRP Catalogue
•Set of all defined SRPs.
• SRP catalogue: organizedaccording to differentClassificationSchemas:
Hierarchical classification to index SRP.
Goals:
Makeeasierunderstanding and reuse of patterns.
Improvecatalogue’susability and portability.
14

15. SRP Catalogue – current version
GESSI: Software Requirement Patterns
• 29 non-functional & 3 non-technical requirement patterns.
• SRP catalogue according to ISO/IEC 9126-1 classification schema.
Functionality
Reliability
Suitability
-
Maturity
Failure alerts
Accuracy
Data precision
Fault Tolerance
Alternative data storage, Availability, Downtime, Uptime
Interoperability
Data exchange,Interoperability with external systems
Recoverability
Backups, Log
Security
Authentication, Authorization, Automatic logoff, Data
transmission protection, Stored data protection
R. Compliance
-
F. Compliance
-
Analyzability
-
Changeability
-
Stability
-
Usability
Maintainablity
Understandability
Interface Language, Interface type
Learnability
Online help, Interface learnability, Documentation
Testability
-
Operability
Failure alerts, Recovery procedures, Installation
procedures, Update procedures
M. Compliance
-
Attractiveness
-
Portability
U. Compliance
-
Adaptability
Development language
Installability
Platform
Efficiency
Time Behaviour
Interface load time, Concurrent users capacity
Coexistence
-
Resource Utilisation
Data capacity, Users capacity
Replaceability
-
E. Compliance
Backups, Log
P. Compliance
-
15

16. GESSI: Software Requirement Patterns
SRP Catalogue - construction
7 Requirement Books
Analysis of books
Focus on Non-Functional Requirements (NFR).
48 NFR Patterns
Refinement
1. Case studies (post-mortem analysis of some
requirement books).
2. Experts review (iterations between SSI & GESSI ).
3. Literature review (GESSI).
29 NFR Patterns
3 Non-Technical Patterns
16

17. GESSI: Software Requirement Patterns
5. PABRE METHOD & TOOLS

18. GESSI: Software Requirement Patterns
PABRE Method
Knowledge of the
Reqt. pattern
catalogue
Needs
IT Consultant
Customer
•PABRE: PAtternBasedRequirementsElicitation.
Supplier
Supplier
Supplier
6
•Method to create and useSRPs.
Requirements Elicitation
•Goals:
Patterns
Exploration
Parts
Exploration
Requirem.
Extraction

Call for
tenders
Requirements
1. Generation of theneededrequirementsbook.
Book
Requirem.
2. Help in therequirementselicitationphase:
Creation
 Less time to do it.
 Less errors in theresult.
Reqt.
Patterns
Catalogue
Knowledge of
previous projects
Forms
Exploration
Catalogue
Evolution
Feedback
Repository
Requirements
Expert
OTS-based
Solution
Heavy Process
 Why don’t we
use tools?
18

19. GESSI: Software Requirement Patterns
PABRE Method – with Tools
19

20. GESSI: Software Requirement Patterns
6. VALIDATION

21. GESSI: Software Requirement Patterns
Validation
• During building the catalogue and metamodel:
 SSI conducted two case studies to do an initial
validation:
1. Improve the contents and the metamodel of the catalogue:
the first one (a digital library system).
2. Catalogue validation: the second one (a CRM SaaS project)
used fro validation to obtain feedback of the adequacy of the
resulting catalogue.
• All the approach:
 SSI did a small project for a company (July 2010):
• 29 NFRs stated  using 21 different SRPs.
 (only 2 reqs didn’t become from SRPs!)
21

22. GESSI: Software Requirement Patterns
7. CONCLUSIONS

23. GESSI: Software Requirement Patterns
Conclusions
Software Requirement Patterns (SRP)
↑quality
starting point
SRP Catalogue
Tools
(current version)
http://www.upc.edu/gessi/PABRE
PABRE-Man
PABRE-Cft
Initial
validation
23

24. GESSI: Software Requirement Patterns
8. FUTURE WORK

25. GESSI: Software Requirement Patterns
Future Work
•
Validation of the approach (catalogue, method, tool,
etc.):
 Call-for-tender processes: collaboration of SSI-CPRHT and
CASSIS consultants.
 Other different domains.
•
Improve and expand tools’ functionalities.
 Interoperability with other requirement engineering tools (Irqa,…).
•
•
Expand SRP catalogue with other types of requirements
(non-technical, functional).
Automatic computation of patterns from requirement
books.
25

26. SOFTWARE
REQUIREMENT PATTERNS
GESSI
Cristina Palomares
Software Engineering for Information Systems Group
10/11/2010

27. GESSI: Software Requirement Patterns
Other approaches
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
Scope
General purpose
General purpose
Business applications
General purpose
Embedded systems
Security requirements
Security requirements
General purpose
General purpose
Notation
Natural language
Object models
Event-Use case
Semi-formal models
Logic-based
UML class diagrams
Natural language
Natural language
Problem frames + i*
Application
Req. elicitation
Variability modeling
Identify patterns
Writing req. models
From informal to formal reqs.
Security goals elicitation
Req. elicitation in SOC
Writing SRS
Knowledge management
Metamodel?
Just templates
Yes
No
Yes
No
No
No
Just template
No
Ours
General purpose
Natural language
Writing SRSs
Yes
5. A. Durán, B. Bernárdez, A. Ruíz, M. Toro. “A Requirements Elicitation Approach Based in Templates and
Patterns”. WER 1999.
6. B. Moros, C. Vicente, A. Toval. “Metamodeling Variability to Enable Requirements Reuse”. EMMSAD 2008.
7. S. Robertson. “Requirements Patterns Via Events/Use Cases”. PLoP 1996.
8. O. López, M.A. Laguna, F.J. García. “Metamodeling for Requirements Reuse”. WER 2002.
9. S. Konrad, B.H.C. Cheng. “Requirements Patterns for Embedded Systems”. RE 2002.
10. D. Matheson, I. Ray, I. Ray, S. H. Houmb. “Building Security Requirement Patterns for Increased Effectiveness
Early in the Development Process”. SREIS 2005.
11. A. Mahfouz, L. Barroca, R. C. Laney, B. Nuseibeh. Patterns for Service-Oriented Information Exchange
Requirements. PLoP, 2006.
12. J. Withall. Software Requirements Patterns. Microsoft Press, 2007.
13. J. Yang, L. Liu. “Modelling Requirements Patterns with a Goal and PF Integrated Analysis Approach”. COMPSAC
2008.
27

28. GESSI: Software Requirement Patterns
Metamodel - Relationships
… pattern
relationship, …
… form
relationship
and…
Implies all the forms
and all the parts of
the related patterns.
Implies all the
parts of the
related forms.
… part
relationship.
Only applying to
these 2 parts.
A general relationship
is specified in…
If A is related to B and A is applied in a project, is mandatory know
the type of this relationship: for instance, apply or avoid B.
Example:
Authorization pattern
IMPLIES
Authentication pattern
But relationship types not defined more flexibility.
28

29. GESSI: Software Requirement Patterns
Metamodel - Classification
… is compossed for 1 or more Root
Classifiers and each one of them…
A Classification
Schema…
Hierarchical classification to index patterns.
Example:
Usability, Portability, Efficiency …
Example:
ISO/IEC 9126-1
/
… contains 1 or more
Classifiers. A Classifier
can be…
Example:
Attractiveness, U. Compliance,
Operability, Learnability …
… a Basic Classifier or…
… a Compound Classifier.
Contains only SRP.
Again contains 2 or more classifiers.
Example:
The basic classifier Operability
contains the following patterns:
Installation Procedures, Recovery
Procedures, Failure Alerts …
Example:
The compound classifier Reliability
contains the following classifiers:
Fault Tolerance, Maturity,
Recoverability …
29

30. SRP Catalogue - construction
•1st phase  result: 1st version of the catalogue (48 SRPs) and
GESSI: Software Requirement Patterns
metamodel
1. Analysis req. books focus on Non-functional requirements.
2. GESSI - UPC academic experts + SSI experts knowledge.
3. GESSI - UPC knowledge: analysis structure, relationship and
organization of requirements in req. books.
4. SSI experts knowledge: feedback, suggestions, requirements
on the pattern structure.
1st catalogue
1stmetamodel
•2nd phase  result: 2nd version of the catalogue (29 NFR & 3
Non-technical SRPs) and metamodel
1. Use req.books to validate catalogue: applying patterns for recreating
them.
2. SSI experts knowledge + requirement engineers experienced in OTS:
review first catalogue version.
3. SSI experts knowledge: 2 case studies
1) To improve the contents of the catalogue.
2) For validation: to obtain feedback about the adequacy of the
resulting catalogue.
4. Literature review (3 types of sources).
5. SSI experts knowledge + requirement engineers experienced in OTS:
review catalogue structure ( metamodel). Relevant attributes and
new elements in the pattern structure (as questions).
2nd catalogue
2ndmetamodel
30

31. GESSI: Software Requirement Patterns
PABRE-Man (Patterns Management Tool)
•SRP repository management. Create, update and delete:
 SRPs.
 Metrics.
 Classification schemas.
•SRP repository
exploration:
 Browsing of SRP repository according to different classification schemas.
 Browsing of all defined metrics.
•SRP use:
 Import an xml concerning to a project to update the statistics about the
use of patterns.
 Consult use of different SRPs with the aim to update the SRP catalogue.
• SRP catalogue exportation:
Pdf or rtf.
31

32. GESSI: Software Requirement Patterns
PABRE-Man (Patterns Management Tool)
32

33. GESSI: Software Requirement Patterns
PABRE-Cft(Projects Management Tool)
•Projects repository management:
 Create, copy, update and delete projects.
 Create, update and delete requirements:
a. Created as an instance of a SRP.
b. Created from scratch.
•Project and SRP repository browsing:
 Browsing of projects and their requirements.
 Browsing of SRP repository.
•Generation of call-for-tenders document.
• Exporting projects:
 Xml or pdf.
• Exporting SRPs use.
33

34. GESSI: Software Requirement Patterns
PABRE-Cft(Projects Management Tool)
34