software requirement patterns (srp)

GESSISoftware Engineering for Information Systems Group

SOFTWARE REQUIREMENT PATTERNS

REFSQ’10Intl. Working Conf. on Requirements Engineering:

Foundation for Software Quality

Cristina Palomares

10/11/2010

OutlineGESSI: Software Requirement Patterns

1. Introduction2. Example3. Metamodel4. SRP Catalogue5. PABRE Method & Tools6. Validation7. Conclusions8. Future work

GESSI: Software Requirement Patterns

1. INTRODUCTION

Context

4


Requirements Elicitation Stage

Requirement(natural

language)

Requirements Book

Patterns(less global errors)

Patterns(more reqs. quality)

The system shall provide the user interface available in languagesSet languages.

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’’

• BENEFITS1. +↑ quality of requirements2. −↓ time and effort spent during requirements elicitation ( economic saving).

5


RequirementsElicitation Stage

Requirement(natural

language)

RequirementsBook

Patterns(less global errors)

Patterns(more reqs. quality)

The system shall provide the user interface available in languagesSet languages.

A Specific OrganizationGESSI: 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.•Applied reuse: starting a new project by editing the most similar one.

•Better capitalization of requirements in a high-level manner.•Avoiding ambiguous, incomplete or incoherent requirements.

•Software Requirements Patterns (SRP).

6

Strategy


2. EXAMPLE

Example: Failure Alerts

8

The solution should alert of disks close to their capacity .

In case of a network or server disk crash, the solution should alert immediately.

The system should alert the administrator of the resources (physical or logical) close to their capacity.

failuresSet : set of possibleFailureso possibleFailures: server crash | disk crash …

The system shall trigger alerts in case of failuresSet failures.

alert

alert

alert

disks close to their capacity

network or server disk crash

resources (physical or logical)close to their capacity


Pattern’s Goal: Having system that provides alerts when system failures occur.

Requirement template

How do their requirements look like?


9

Requirement Pattern Failure Alerts

Goal: Satisfy the customer need of having a system that provides alerts when system failures occur.

RequirementForm Homogeneous Failure Alerts

Fixed Part

Template The system shall trigger an alert in case of failure.

Extended Parts Constraint

multiplicity(Alerts Types) = 0..1 andmultiplicity(Failure Types) = 0..1

Extended Part Alert Types

Template The solution shall trigger %alertsSet% alerts in case of failure Parameter Metric

alertsSet alertsSet: Set(AlertType)AlertType: SMS | Mail | Fax | Sound ….

Extended Part Failure Types

Template The system shall trigger alerts in case of %failuresSet% failures Parameter Metric

failuresSet failuresSet: Set(FailureType)FailureType: server crash | disk crash …

RequirementForm Heterogeneous Failure Alerts

Fixed Part

TemplateThe system shall trigger different types of alerts depending on the type of failure.

Extended Parts Constraint

Multiplicity(Alerts for Failure Types) = 0..*

Extended Part Alerts for Failure Types

Template The system shall trigger %alertsSet% alerts in case of %failuresSet% failures.

Parameter Metric

alertsSet alertsSet: Set(AlertType)AlertType: SMS | Mail | Fax | Sound ….

failuresSet failuresSet: Set(FailureType)FailureType: server crash | disk crash …



3. METAMODEL

Metamodel – SRP Structure

11GESSI: Software Requirement Patterns

A requirement pattern…

… has several forms …

… that are made of 1 fixed part …

... and severalextended part(s)…

A fixed part contains the most abstract expression of a requirement.

A extended part contains other ways to express a requirement (often with parameters).

A form captures a particular context that may be the most appropiate for a software project.

A pattern represents a cluster of requirements (a group of interrelated requirements).


Examples: Homogeneous Failure Alerts Heterogeneous Failure Alerts

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

... and severalconstrainst(s).

For declaring multiplici- ties or dependencies among parts.Examples: excludes, requires …

Metamodel - Overview

12

Catalogue Classification

Core: SRP

Relationship

/

Application

Parts Relationship example:

Alerts for Failure Types ↔ Data Integrity by Failure

Data shall be protected in case of failuresSet failures.

The system shall trigger alertsSet alerts in case of failuresSet failures

(Failure Alerts) (Recovery Procedures)



4. SRP CATALOGUE

SRP Catalogue

14

• Set of all defined SRPs.

• SRP catalogue: organized according to different Classification Schemas: Hierarchical classification to index SRP. Goals:

Make easier understanding and reuse of patterns. Improve catalogue’s usability and portability.


SRP Catalogue – current version

15

• 29 non-functional & 3 non-technical requirement patterns.

• SRP catalogue according to ISO/IEC 9126-1 classification schema.

Functionality

Suitability -

Accuracy Data precision

Interoperability Data exchange, Interoperability with external systems

Security Authentication, Authorization, Automatic logoff, Data transmission protection, Stored data protection

F. Compliance -

Usability

Understandability Interface Language, Interface type

Learnability Online help, Interface learnability, Documentation

Operability Failure alerts, Recovery procedures, Installation procedures, Update procedures

Attractiveness -

U. Compliance -

Efficiency

Time Behaviour Interface load time, Concurrent users capacity

Resource Utilisation Data capacity, Users capacity

E. Compliance Backups, Log

Reliability

Maturity Failure alerts

Fault Tolerance Alternative data storage, Availability, Downtime, Uptime

Recoverability Backups, Log

R. Compliance -

Maintainablity

Analyzability -

Changeability -

Stability -

Testability -

M. Compliance -

Portability

Adaptability Development language

Installability Platform

Coexistence -

Replaceability -

P. Compliance -


SRP Catalogue - construction

16

48 NFR Patterns

29 NFR Patterns3 Non-Technical Patterns

7 Requirement Books

Analysis of books Focus on Non-Functional Requirements (NFR).

Refinement1. Case studies (post-mortem analysis of some requirement books).2. Experts review (iterations between SSI & GESSI ).3. Literature review (GESSI).



5. PABRE METHOD & TOOLS

PABRE Method


Requirements Elicitation

IT Consultant Customer

Supplier SupplierSupplier

Requirements

Book

6

Knowledge of the Reqt. pattern

catalogue

Reqt.Patterns

Catalogue

FeedbackRepository

Call for tenders

CatalogueEvolution

RequirementsExpert

OTS-basedSolution

Needs

PatternsExploration

FormsExploration

PartsExploration

Requirem.Extraction

Requirem.Creation

Knowledge of previous projects

• PABRE: PAttern Based Requirements Elicitation. • Method to create and use SRPs. • Goals: 1. Generation of the needed requirements book.

2. Help in the requirements elicitation phase: Less time to do it. Less errors in the result.

Heavy Process Why don’t we use tools?


PABRE Method – with Tools


6. VALIDATION

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


7. CONCLUSIONS

Conclusions

23

Software Requirement Patterns (SRP)

SRP Catalogue(current version)

http://www.upc.edu/gessi/PABRE

Tools

↑ quality starting point

Initial validation

PABRE-Man

PABRE-Cft



8. FUTURE WORK

Future Work

25

• 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.G

ESSI: Software Requirement Patterns

GESSISoftware Engineering for Information Systems Group

SOFTWARE REQUIREMENT PATTERNS

Thanks for your attention!

Cristina Palomares

10/11/2010

Other approaches

27

Scope Notation ApplicationMetamodel?

[5] General purpose Natural language Req. elicitation Just templates[6] General purpose Object models Variability modeling Yes[7] Business applications Event-Use case Identify patterns No[8] General purpose Semi-formal models Writing req. models Yes[9] Embedded systems Logic-based From informal to formal reqs. No

[10] Security requirements UML class diagrams Security goals elicitation No[11] Security requirements Natural language Req. elicitation in SOC No[12] General purpose Natural language Writing SRS Just template[13] General purpose Problem frames + i* Knowledge management No

Ours General purpose Natural language Writing SRSs Yes5. 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.G

ESSI: Software Requirement Patterns

Metamodel - Relationships

28

A general relationship is specified in…

Only applying to these 2 parts.

… pattern relationship, …

… part relationship.

… form relationship and…Implies all the forms

and all the parts of the related patterns.

Implies all the parts of the related forms.

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 Authentication pattern

But relationship types not defined more flexibility.

IMPLIES


Metamodel - Classification

29

A Classification Schema…

Hierarchical classifica-tion to index patterns.

Example: ISO/IEC 9126-1

… is compossed for 1 or more Root Classifiers and each one of them…

Example: Usability, Portability, Efficiency …

… contains 1 or more Classifiers. A Classifier can be…

Example:Attractiveness, U. Compliance,Operability, Learnability …

… a Basic Classifier or…

Contains only SRP.

Example: The basic classifier Operability contains the following patterns: Installation Procedures, Recovery Procedures, Failure Alerts …

… a Compound Classifier.

Again contains 2 or more classifiers.

Example: The compound classifier Reliability contains the following classifiers: Fault Tolerance, Maturity, Recoverability …

/


SRP Catalogue - construction

30

• 1st phase result: 1st version of the catalogue (48 SRPs) and 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

1st metamodel

• 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

2nd metamodel



31

• 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.

PABRE-Man (Patterns Management Tool)


32

PABRE-Man (Patterns Management Tool)


33

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.


34

PABRE-Cft (Projects Management Tool)

software requirement patterns (srp)

Technology

requirement extended

failure alerts gessi

software requirement

software requirement

software requirement

requirement templatethe

requirement books

system failures