Resolving Requirement

Conflicts through Non-

Functional 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 Introduction
2 Model of Requirements & Architecture
3 The NFD Process
4 Case: Dutch Road-Pricing System
5 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)
 Therelationship 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)
 Supplementary Requirements:
1. 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