Slides refsq'14 ds v1

GESSI
Software Engineering for Information Systems Group
DEFINITION AND USE OF
SOFTWARE REQUIREMENT PATTERNS
IN RE ACTIVITIES

Outline
2
1. Motivation
2. Research Questions
3. Proposed approach
 What has been done
 What is pending to do
4. Research Methodology
5. Conclusions
DefinitionandUseofSRPinREActivities

Motivation - The Importance of Requirements
• Basis of every IT project
• If not elicited properly, the project will fail in some way
 Requirements problems are difficult and costly to solve
• RE goal: unambiguous, complete and consistent requirements
• Some interesting study facts:
 Top 2 factors of project failure [Standish Group, 1995]
• Incomplete requirements (13’1%)
• Lack of user involvement during RE (12’4%)
 RE weak maturity level (30%) [Swiss IT Company, 2012]
 Requirements Problems [Swiss IT Company, 2012]
• Ambiguousness (74’5%)
• Incompleteness (73’6%)
• Inconsistency (61’1%)
3

Motivation – Requirements Reuse
• Efficiently eliciting, validating and documenting requirements
 Better quality in requirements specification
 More effective engineering processes
• Different requirements reuse approaches
• Requirements reuse through patterns
 “Each pattern describes a problem which occurs over and over again in
our environment, and then describes the solution to that problem.”
Christopher Alexander [Ale77]
 Software Patterns
 Patterns for RE
• E.g.: Analysis patterns, Requirement patterns, Product family variability
patterns, …
• Approaches restricted to small-scale academic examples
4

Motivation – Putting Everything Together
5
The final quality of an IT project depends
on its requirements specification
Restricted to small-scale academic examples
or particular company problems
Ambiguous, incomplete and
inconsistent requirements
Lots of different proposals for
software patterns

Research Questions
6
Which are the existent approaches to the notion of pattern in the
context of RE knowledge reuse?
What is the best structure and semantics software requirement
patterns (SRP) should have to be applied over F, NF and NT
requirements and to improve the quality of the specifications?
How SRP can be integrated in the RE stage techniques and
processes so their application gives benefits that justify the cost
of their adoption?
Does the proposed framework give benefits and drive to higher
quality SRS when applied into RE activities?
- Define Software Requirement Patterns (SRP), encapsulating textual reqs
- Define the PABRE framework (PAtterns Based Requirements Elicitation) to
facilitate SRP use.
RQ1
RQ2
RQ3
RQ4

• PAtterns Based Requirements Elicitation (PABRE) Framework
 Use SRP to capture and use requirements knowledge
• Software Requirements Patterns (SRP)
 Solution: template that generate natural language requirements
 Context-problem: information to identify SRP applicability
 Classification: using classification schemas
• Benefits
 Less time required in recurrent requirements elicitation
• More time for creative requirements
 Improved quality of requirements specifications
• Consistency, Non-ambiguity, Completeness
Proposed Approach – The PABRE framework
7

Proposed Approach – The PABRE framework
8
Supplier Economic Information
Goal: Assessing the economic situation of the supplier
Economic Situation Information Form
• Fixed: The supplier shall provide economic
information of its company.
• Extended 1: The supplier shall provide
information of it’s company’s turnover on
the last amountOfTime timeUnit.
• Extended 2: The supplier shall provide
information of its company’s net income
on the last amountOfTime timeUnit.
• Fixed part cannot be applied more than
once.
• Extended 1 and Extended 2 parts cannot
be applied more than once.
SRPPartsConstraints
Economic Situation Prerequisites Form
• Fixed: The supplier shall fulfill some economic situation
prerequisites.
• Extended 1: The supplier's company shall have a
minimum net income of amount currencyUnit on the
last amountOfTime timeUnit.
• Extended 2: The supplier’s company shall have a
minimum turnover of amount currencyUnit on the last
amountOfTime timeUnit.
• Fixed part cannot be applied more than once.
• Extended 1 and Extended 2 can be applied more than
once if they are applied with disjoint values for the
parameters (amount, amountOfTime).
• Soft Constraint. Extended 1 and Extended 2 applications
should use the same currencyUnit and timeUnit.
SRPPartsConstraints
Does the Customer requires specific conditions on the economic situation of the supplier?
Parameter Metrics
amount, amountOfTime: integer (inv: integer must be greater than 0)
timeUnit: domain {years, months, ...}
currencyUnit: domain {USD, EUR, GBP, JPV, ...}

Proposed Approach – What has been done
9
RQ1. Systematic Literature Review
 What is the State of the Art to reuse knowledge during RE using
patterns?
RQ2. SRP: Semantics and Structure definition
RQ3. PABRE Framework: Design and Implementation
RQ4. Validation
 Frameworks assets validation separately
 Online questionnaires

10
patterns?
RQ4. Validation

11
patterns?
RQ2. SRP: Semantics and Structure Definition
RQ4. Validation

12
patterns?
RQ4. Validation

13
SRP ROI
Model
Requirement
Analyst
Customer
SRP
Catalogue
PABRE
System
PABRE
Method
Requirement
Projects
SRP&Catalogue
Metamodel

14
Classification
part Core part:
SRP structure
Relationship
part
Application
part

15

16
patterns?
RQ2. SRP: Semantics and Structure Definition
RQ4. Validation
 Online questionnaire
• Requirements reuse state of the practice
• PABRE requirement patterns opinion

Proposed Approach – What is pending to do
17
RQ1. Maintaining SLR up-to-date (RQ1)
RQ1. Study of requirements reuse in RMTs
RQ2. Improve SRP relationships
RQ3. Evolving PABRE framework assets
 Methods for SRP usage and evolution
 Economic model
 PABRE System
RQ4. Validation
 Finishing online survey
• Complement with semi-structured interviews
 Case study

Research Methodology
18
• Started as a response to TUDOR needs
• Scientific paradigm
1. Problem definition
• TUDOR
• Literature
2. Scientific problem definition
• RQs
3. Solution design
• Studying SRS
• Literature
4. Empirical evaluation

Conclusions
19
• Software Requirements Patterns (SRP)
 Textual requirements reuse using templates
 Embraced inside the PABRE Framework
1. SRP & Catalogue metamodel
2. SRP Catalogue with 29 NF-SRP, 37 NT-SRP and 45 F-SRP
3. Methods for creating, evolving and using SRPs
4. PABRE system
5. SRP-ROI economic model
• Benefits
 Less time required in recurrent requirements elicitation
 Improved quality of requirements specifications
• Feedback on:
 General approach
 Ideas for validation
 Future plan for the PhD

References
20
• [Ale77] Alexander C., Ishikawa S., Silverstein M., Jacobson M., Fiksdahl-King
I., Angel S., “A Pattern Language”. Oxford University Press, 1977.
• [Standish Group, 1995] The Standish Group, “The Standish Group Report -
Chaos”, 1995. Available at: http://www.projectsmart.co.uk/docs/chaos-
report.pdf. Last access: June 2013.
• [Swiss IT Company, 2012] SwissQ, “SwissQ Requirements Trends & Bench-
marks Switzerland 2012”, 2012. Available at: http://www.swissq.it/wp-
content/uploads/2013/03/SwissQ_Req_Trends_2012_Web_EN.pdf. Last
access: June 2013.

GESSI
Software Engineering for Information Systems Group
DEFINITION AND USE OF SOFTWARE
REQUIREMENT PATTERNS IN RE ACTIVITIES

Slides refsq'14 ds v1

Recommended

Recommended

More Related Content

Similar to Slides refsq'14 ds v1

Similar to Slides refsq'14 ds v1 (20)

More from GESSI UPC

More from GESSI UPC (20)

Recently uploaded

Recently uploaded (20)

Slides refsq'14 ds v1