27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang [email protected] School of Computer Science The.

1/1627/3/2008

A FRAMEWORK FOR REQUIREMENTS ENGINEERING

PROCESS DEVELOPMENT (FRERE)

Dr. Li [email protected]

School of Computer ScienceThe University of Adelaide

2/1627/3/2008

Overview

Introduction Attributes of Techniques, and Software Projects

Attributes of RE Processes and Techniques Attributes of Software Projects

FRERE Framework RE Process Knowledge Base (REPKB) RE Process Development Methodology RE Process Assessment Models

A Case Study Develop a hypothesis and selection of the Pilot Project Summary of the Case study Quantitative and Qualitative Analysis of the Software

Project Results

Conclusions and Future Work

3/1627/3/2008

Introduction (1) Requirements Engineering (RE) is a critical process within the

Software Engineering (SE)

Research has shown, it is critical to use the most suitable RE process and proper RE techniques since: Suitable RE process and techniques will contributes to the

overall success of software project No single technique provides a complete solution for all RE

problems A pragmatic, project-oriented combination of RE techniques

has positive influence on the success of SW projects. The gap between RE theory and practice is still large

Few methods existed provide limited means to help analysis and selection of RE techniques for a software project

Requirements Engineering

System requirements

Software Architecture

Safty Critical Software

Introduction

Attributes

FRERE Framework

Case Study

Conclusion

4/1627/3/2008

Introduction (2)

Engineering principle is addressed

The cost and time to market issues are addressed

Standardization issues are addressed

Software Projects

Characteristics of Software

Project

Characteristics of the Best SE Processes, Techniques

RE technique

Design Tech

Test Tech

……Mapping

Models

Heuristic rules Logical Relationship

31 technique attributes identified

21 project attributes identified

- A SolutionIntroduction

Attributes

FRERE Framework

Case Study

Conclusion

5/1627/3/2008

Attributes of RE Techniques 31 attributes for RE techniques were defined in the research,

e.g.

Categories Attributes of the Techniques

Elicitation:

Ability to facilitate communicationAbility to get domain knowledgeAbility to identify non-functional requirements……

Analysis & Negotiation:

Ability to understand the notations used in analysis Ability to facilitate negotiation with customersAbility to prioritize requirements……

…… ……

Other AspectsIntroduction cost, Application cost …..

……

Introduction

Attributes

FRERE Framework

Case Study

Conclusion

6/1627/3/2008

Project Attributes

Project Size Project Complexity Requirements Volatility Project Category Degree of Safety Criticality Quality Standard Time Constraints Cost Constraints Team Size Acquaintance with Domain Reusability

Defined based on the number of requirements. The values are:

Very Big (X>=4000 requirements),

Big (4000=>X>=2500),

Medium (2500=>X>=1000),

Small (1000=>X>100),

Very Small (X<100).

Introduction

Attributes

FRERE Framework

Case Study

Conclusion

7/1627/3/2008

FRERE Framework

Assessment models

RE process development

Techniques selection

MethodologiesRE process

knowledge base

RE process maturity model

Technique suitability assessment

model

Major COREs model

Building blocks

RE process template

Project cases

Rules Others

FRERE FrameworkIntroduction

Attributes

FRERE Framework

Case Study

Conclusion

8/1627/3/2008

Requirements Engineers

Assessment

Identification

Reasoning

Selection

Development

New Process Model

Identify the characteristics of project and product

Constraints of the projectsIdentification

RE process major concerns assessment

RE process maturity model assessment

Technique suitability assessment

Assessment

Case-based reasoning

RE Process Knowledge Base

Reasoning

RecommendationSelection

Project cases

Guidelines Building blocks

……

Process Development Methodology

PDA (Process development Assistant)

Development

Development based on the recommendation

Select-Modify-Delet-Split-Add-

Operations

……

Introduction

Attributes

FRERE Framework

Case Study

Conclusion

9/1627/3/2008

Technique Selection Methodology

Scoring the attributes of the software project

Derivation of the initial

recommendation (CBR)

Technique

analysis (Based

on clustering)

Getting suggested techniques from

requirements engineers

Calculation based on the objective function

Refinement of the selected techniques combination

Analysis of the techniques and construction of the recommendation space

Techniques clustering helps to find:* Functionally comparable techniques* Functionally complementary techniques

Derivation of recommendation and techniques analysis

Techniques clustering is based on the techniques evaluation schema developed in the research

Introduction

Attributes

FRERE Framework

Case Study

Conclusion

10/1627/3/2008

Assessment Models

Requirements Engineering

Process Maturity Model

Technique Suitability

Assessment Model

A RE Process

Major CORE Model

Principles

of RE

Maturity of RE

Process

Feasibility to the Software Project

√

√

Models Major PerspectivesIntroduction

Attributes

FRERE Framework

Case Study

Conclusion

11/1627/3/2008

A Case Study

Project Name: Port Scheduling System

Project Attributes:Project Size: Medium (>=700 and <1200 Requirements)Project Complexity: Medium Requirements Volatility: LowOrganization and Customer Relationship: SCR (SCR stands for responding to a Specific Customer Request)Project Category: Semi-detached Team Size: 49Degree of Knowledge of Requirements: MediumDegree of Safety Criticality: HighQuality Standard: HighProduct Type: New

- The Project InformationIntroduction

Attributes

FRERE Framework

Case Study

Conclusion

12/1627/3/2008

A Case Study

Categories Final Selected Technique

Elicitation Focus group, Interview, Ethnography

Analysis & Negotiation

Viewpoint-Based Analysis

Documentation Viewpoint-Based Definition

Verification and Validation

Formal Requirements Inspection

Tool Requirements management supported by an in-house requirements management tool called “DocManager”

- Selected TechniqueIntroduction

Attributes

FRERE Framework

Case Study

Conclusion

13/1627/3/2008

A Case Study

Activities in the model Category Affiliation

Consider the system stakeholders Elicitation VORD

Identify the viewpoints by referencing to the viewpoints template

Elicitation VORD

Hold focus group meeting to elicit requirements from various stakeholders

Elicitation New

Record the sources and rationales of requirements

Elicitation BB

28 activities are defined for the project Examples:

Introduction

Attributes

FRERE Framework

Case Study

Conclusion

14/1627/3/2008

A Case Study

Result of the case study: Project is considered as a success based on the

quantitative and qualitative analysis of the software project results

Much better quality of requirements specification Less delay in project schedule Satisfaction of requirements engineers, project

managers and customers.

Conclusion: FRERE framework did offer the suitable RE

process model for the project.

Introduction

Attributes

FRERE Framework

Case Study

Conclusion

15/1627/3/2008

Conclusions

Using the most appropriate RE process model and the most suitable techniques remain a challenging issue

This research offers a constructive solution to tackle the problem with the following contributions: Establishment of the RE Process Knowledge Base (REPKB) Development of a RE techniques analysis schema Identification of the relationships between RE techniques Development of assessment models Explicitly linking project characteristics with RE process

development

The case study in industry shows the feasibility of the FRERE

Introduction

Attributes

FRERE Framework

Case Study

Conclusion

16/1627/3/2008

Future Work

Enrichment of RE process knowledge base

Investigation the relationships between RE technique and process models in depth

Investigation of the use of the framework in diverse software projects

Completion of the FRERE tool

Introduction

Attributes

FRERE Framework

Case Study

Conclusion

17/1627/3/2008

Questions ?

Thank you !

Questions ?Questions ?

18/1627/3/2008

Back-up slides

19/1627/3/2008

Quality RE Process

Premise

Quality Requirements Specification

Quality Products

RequiresRequires

Contribute Contribute

Focus Project

Introduction

FRERE

Tool

Case Study

Conclusion

20/1627/3/2008

Existing RE Process Models- Examples

Water-Fall RE process model Volere Goal Based model

KAOS Viewpoints based

VORD Domain Oriented

SREM RATS

Others RUP Agile pattern (XP, SCRUM) Combinations

21/1627/3/2008

Existing RE Techniques - Examples

Elicitation JAD, Focus Group, etc. Interview, Brainstorming, etc

Analysis and Negotiation Use case, Structured Analysis, etc. FSM, Petri-net, etc.

Documentation Nature Language, Structured Language Formal Notations such as Z, VDM, etc.

Verification and Validation Inspection, Technical Review, Test cases. Formal Method based

22/1627/3/2008

RE Process Building Blocks

Process Risk Management

Techniques

Analysis & Negotiation

Documentation

RequirementsManagement

Validation & Verification

Process Development Guidance

Reuse

Elicitation

Interaction Metrics

Tools Process Models

1 2 3 4

9875

1110

6

1312

23/1627/3/2008

A Decision Support Model

24/1627/3/2008

Case Based Reasoning

Similarity Calculation

k

jjjij

i

),yxFW

K,Y)(X

1,(

Similarity i=1,··· ,n; j=1,…,k

),( , jji yxF =1

1)(

1

1-)( ,

j

j

j

ji

R

yr

R

xr i=[1..n], j=[1..k]

F = 0.5 if are in nominal scale and

F = 0 if are in nominal scale and .

),Y(X jji, jji y,x ,

jji y,x ,),Y(X jji,

jji yx ,

jji yx ,

is defined as:),( , jji yxF

if are in ordinal scalejji y,x ,

(1)

(2)

(3)

25/1627/3/2008

Major COREs

Elicitation Identification of Stakeholders and their viewpoints User participation Identification of the goals, expectation, scope and context

of the project or system Effective communication Elicitation of functional requirements Elicitation of non-functional requirements and system

constraints

Analysis & Negotiation Classification of requirements Requirements Prioritization Negotiation with various stakeholders to ensure agreed

requirements are finalized Modelling and understanding functional requirements Understanding of non-functional requirements and

constraints of the system

- Examples

26/1627/3/2008

Assessment Models- RE Process Maturity Model

Maturity Level

Number of The

Guidelines

Assessment Scores in REPMM Model

Level 1: Initial 36

Less than 55 in the basic guidelines. May have implemented some intermediate guidelines

Level 2: Repeatable

21

Above 55 in the basic guidelines but less than 40 in the intermediate and advanced guidelines

Level 3: Defined

9

More than 85 in the basic guidelines and more than 40 in the intermediate and advanced guidelines.

27/1627/3/2008

Product Attribute1 Technique1 Technique2

Degree of safety criticalAgile-based

Documentation

Formal method based

Documentation

Ordinal Measure

Numerical value

Very Low 0 1 0

Low 0.25 0.75 0.25

Middle 0.5 0.5 0.5

High 0.75 0.25 0.75

Very high 1 0 1

Assessment Models- An Example of Technique Evaluation

28/1627/3/2008

The Target RE Process Model

The target process model should possess following characteristics:

The process model satisfies the constraints of the software project.

The process model must Address the relevant major COREs. Implement many good practices proposed in REPMM

model Techniques used are considered the most suitable for

the given project (i.e. the higher mark with regard to the RE technique suitability assessment )

The complexity of the overall process model is compatible with the complexity of the project.

29/1627/3/2008

Examples of Rules (1)

Rule Type: Assent Logical Operation: AND Condition 1: Stakeholder Heterogeneity Of ?X Is High Condition 2: Degree Of The Importance Of Usability Of ?X Is High Condition 3: Importance OF The Eliciting Implicit Knowledge Of ?X Is High Condition 4: Customer Availability Of ?X Is High Technique 1: Ethnography Action : Recommend To ?X

Notes: ?X indicates a specific software project

30/1627/3/2008

Examples of Rules (2)

Rule Type: Dissent Logical Operation: OR Condition 1: Time Constraint OF ?X Is High Condition 2: Customer Availability Of ?X Is Low Condition 3: Cost Constraints Of ?X Is High Technique 1: Ethnography Actions: Not Recommend To ?X

Notes: ?X indicates a specific software project

31/1627/3/2008

Examples of Rules (3)

Rule Type: Consistency Logical Operation: AND Condition 1: Technique “eXtreme Programming (XP)” IN ?P Condition 2: Technique “Z” IN ?R Actions: Prompt information “Mutually Exclusive Techniques are used”

Notes: (1) ?P indicates the newly developed process model (2) “Z” is a technique for requirements analysis and documentation where the mathematical notation is used for describing requirements

32/1627/3/2008

FRERE Tool

33/1627/3/2008

FRERE Tool

34/1627/3/2008

FRERE Tool

35/1627/3/2008

FRERE Tool

36/1627/3/2008

FRERE Tool

37/1627/3/2008

FRERE Tool