121207conflicts

8/14/2019 121207conflicts

http://slidepdf.com/reader/full/121207conflicts 1/20

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/IFIPConference on Software Architecture (WICSA ‘04)

Presented by : K.W. Lee, 12/12/2007

8/14/2019 121207conflicts


Outline

1 Introduction

2 Model of Requirements & Architecture

3 The NFD Process4 Case: Dutch Road-Pricing System

5 Conclusion & discussion

8/14/2019 121207conflicts


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

8/14/2019 121207conflicts



Aim:

Develop a method for decomposing a system

based on the conflicts in the system requirements

8/14/2019 121207conflicts



Non-Functional Decomposition (NFD)

highlight the contrast with Functional

Decomposition

Emphasize the importance of Non-Functional

Requirements in this process

8/14/2019 121207conflicts



Benefit of NFD:

Yield a defined trace from those requirements to

the system structure

Give a better basis for architecture & project

decision trade-offs

8/14/2019 121207conflicts


3 Model of Requirements &

Architecture (1/9)

3.1 Accepted model for architectural design

8/14/2019 121207conflicts



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 thesystem development process rather than on the

system architecture

8/14/2019 121207conflicts



Architecture (31/9)

3.2 Refined requirements classification for

NFD

8/14/2019 121207conflicts



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

8/14/2019 121207conflicts



Architecture (5/9)

Supplementary Requirements:

1. Secondary Functional Requirements (SFRs)- Require functionality that is secondary to the goal

of the system

- Not quantifiable

8/14/2019 121207conflicts



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

8/14/2019 121207conflicts



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

8/14/2019 121207conflicts



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

8/14/2019 121207conflicts



Architecture (9/9)

8/14/2019 121207conflicts


4 The NFD Process (1/2)

8/14/2019 121207conflicts


4 The NFD Process (2/2)

Critical performance

High modifiability

In-group conflicts

8/14/2019 121207conflicts


5 Case: Dutch Road-Pricing

System (1/2)

Privacy

Verifiability

Provability

Security

Re-usability

Viability

Standardization

8/14/2019 121207conflicts


5 Case: Dutch Road-Pricing

System (2/2)

Privacy

Verifiability

Provability

Security

Re-usability

Viability

Standardization

8/14/2019 121207conflicts


5 Conclusion

NFD

Split the requirements into primary &

supplementary requirements

bring more clarity & structure in the mapping of

requirements onto a system architecture

121207conflicts

Documents