You are on page 1of 20

Resolving Requirement Conflicts through NonFunctional Decomposition

Authors : Eltjo R. Poort, LogicaCMG Peter H.N. de With, LogicaCMG From : Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA ‘04) Presented by : K.W. Lee, 12/12/2007

Outline
1 2 3 4 5

Introduction Model of Requirements & Architecture The NFD Process Case: Dutch Road-Pricing System Conclusion & discussion

1 Introduction (1/4)
 Functional

Decomposition (FD)

Only deal with generic best practices for achieving software quality No rules to deal with system-specific quality requirements

1 Introduction (2/4)
 Aim:

Develop a method for decomposing a system based on the conflicts in the system requirements

1 Introduction (3/4)
 Non-Functional

Decomposition (NFD)

highlight the contrast with Functional Decomposition Emphasize the importance of Non-Functional Requirements in this process

1 Introduction (4/4)
 Benefit

of NFD:

Yield a defined trace from those requirements to the system structure Give a better basis for architecture & project decision trade-offs

3 Model of Requirements & Architecture (1/9)
 3.1

Accepted model for architectural design

3 Model of Requirements & Architecture (2/9)
 The

relationship between quality attributes & non-functional requirements is oversimplified

Ignore the fact that functional requirements can be very important in system design Ignore that NFRs often put constraints on the system development process rather than on the system architecture

3 Model of Requirements & Architecture (31/9)
 3.2

Refined requirements classification for NFD

3 Model of Requirements & Architecture (4/9)
 Primary

Functional Requirements

Require functions which directly contribute to the goal of the system

 Supplementary

Requirements

Other requirements imposed on the system

3 Model of Requirements & Architecture (5/9)

1.
-

Supplementary Requirements:
Secondary Functional Requirements (SFRs)
Require functionality that is secondary to the goal of the system Not quantifiable

-

3 Model of Requirements & Architecture (6/9)
2.

Quality Attribute Requirements (QARs)
-

Not quantifiable quantifiable requirements about system quality attributes

2.
-

Implementation Requirements
Constitute the third category of supplementary requirements Not about system quality

-

3 Model of Requirements & Architecture (7/9)
 3.3

The nature of requirement conflicts

In designing system architectures, the supplementary requirements are more important than the primary requirements
 

Primary requirements are never conflicting Secondary functional requirements can appear to be conflicting

3 Model of Requirements & Architecture (8/9)

3 ways to achieve supplementary requirements:
– – –

Making choice in the software building process Making choice in the structure of the software Building functionality

3 Model of Requirements & Architecture (9/9)

4 The NFD Process (1/2)

4 The NFD Process (2/2)

In-group conflicts
Critical performance High modifiability

5 Case: Dutch Road-Pricing System (1/2)

Privacy Verifiability Provability Security Re-usability Viability Standardization

5 Case: Dutch Road-Pricing System (2/2)

Privacy Verifiability Provability Security Re-usability Viability Standardization

5 Conclusion
 NFD

Split the requirements into primary & supplementary requirements bring more clarity & structure in the mapping of requirements onto a system architecture