Journal of Computer and Communications, 2013, *, **-**
doi:10.4236/jcc.2013.***** Published Online *** 2013 (http://www.scirp.org/journal/jcc)
An Analysis Method for Refinement and Decomposition of
Software Non-Functional Requirement*
Rui Yang, Yanhui Zhou
College of Computer Science and Information Technology, Southwest University, China, Chongqing
Email: covererlking@hotmail.com
Received Month Day, Year (2013).
ABSTRACT
With the development trend of information and software consumption, compared with the correct considerations of
software capabilities, consumer pay more attention to the software quality, especially the non-functional characteristics
such as security, safety, usability and performance etc. Because of the lack of method and practice, the developers
always feel difficult and confused to realize the non-functional characteristic in the software analysis and design
process. This study based on the research of Aspect-Oriented non-functional requirements analysis method from Chung.
An analysis method for refinement and decomposition of software non-functional requirement has been proposed in this
research. This method can separated the design and analysis, analyzed the non-functional requirements according to the
top-down levels. Finally, the design result can be used for a quantify evaluation. The assessment result can help
developer select one based on the client’s needs. This method provides a solution to analysis and design of
non-functional requirements, and an extend of the non-functional requirements framework.
Keywords: non-functional requirements; software quality; requirements decomposition; requirements refinement
1. Introduction
With the software development, people have more
profound understanding and requirement of software
quality[1]. People are not only concerned about the
function of the software, but also paid more attention to
software application quality[2] feature. Software
application quality feature is demonstrated usability,
security, performance, and other such features. The
software non-functional[9] feature has a great effect on
the software quality. In most of the traditional software
design, the business processes are regarded as the main
concern. Software non-functional characteristic cannot
have a good expression and implementation by
Architecture. As the complexity of description[3] of
software non-functional requirements, it is difficult to
analyze, design and verify the non-functional feature.
Besides that, by the lack of a effective analysis method,
the software analysis and design cannot be effective
converged and integrated with software functional
requirements.
In order to solve the above questions, the software
non-functional requirements can be isolated in the initial
* This paper is supported by the project 2012BAH77F05 of National
Technology Support Program and project cstc2012ggB004.
Copyright © 2013 SciRes.
of software lifecycle to analyzed and managed. It will be
able to make a better quality and reduce the possibility of
failure of this project. However, due to the feature of the
non-functional requirements, it does not have a
comprehensive method to help the designers to have
more comprehensive on non-functional requirement
analysis and decomposition. This study presents a
refined decomposition analysis method of software
non-functional requirement, based on the Soft goals
Independence Graph (SIGs)[4]. This method can refined
decompose the non-functional requirement to the
practical operable particles which combined with the
functional requirement, and have a quantitative measure
of design based on the decomposition results. And the
symbol system of Soft goals Independence Graph is
developed, which can express the relationships between
the targets more comprehensive.
2. Related Research
2.1. Home and Aboard Standards
As the software quality is becoming more and more
attention, both at home and abroad successively
formulated a series of standards. According to the
ISO/IEC 25000 “Software engineering - Software
JCC
2
An Analysis Method for Refinement and Decomposition of Software Non-Functional Requirement
product Quality Requirements and Evaluation (SQuaRE)
- Guide to SQuaRE”, which formulated by the
International Standards Organization and International
Electrotechnical Commission , the content and related
definitions of software quality requirement and
evaluation are given. ISO/IEC 14958[5] series standards
provides a method for the software product quality
measurement, assessment and evaluation. The external
and internal quality model is defined in the ISO/IEC
9126[2]. The software quality attributes are divided into
six sub features: functional, reliability, usability,
efficiency, maintainability and portability. A use of
quality model based on customer point of view is also
defined, which contains four features: functional,
productivity, security and satisfaction. The above
standards have a high significance of software quality
evaluation.
Figure 1. Legend of SIGs
2.2. Aspect-Oriented Programming
Aspect-oriented is proposed for the first time in 1997 by
Gregor[7] and some researchers. The core of
aspect-oriented is concern decomposition. The so-called
concern is a specific area we interested in. It is a basic
processing module in software system development. In
the design phase and abstract level of software
architecture, the research and application of
aspect-oriented technology is very important to modeling
the research of concern. First of all, the software
architecture can reduce mixed design problems, track
and clear reflect the concern by using aspect-oriented
design method. It can also improve the understandability
and maintainability of the software architecture, and
conductive to the reconstruction and reuse of software.
Secondly, using aspect-oriented design method can more
smoothly link up to the coding phase in the software
development [8].
2.3. Non-functional
Frame
Requirements
and
NFR
Software requirements are usually constitute by the
functional
and
non-functional
requirements[7].
Functional requirements describe a series of functions
which must be completed by the software.
Non-functional requirements demonstrate the binding
requirement to the functional requirement, for example,
the safety, reliability, usability, etc. Compared with the
accurate description and inherent form of functional
requirement, non-functional requirements are more
abstract, difficult to determine, objective and difficult to
formalized expression.
In 1992, L.Chuang explored the representation and
description of NFRs for the first time, and proposed NFR
Copyright © 2013 SciRes.
Figure 2. Typical SIGs
framework [11]. It is able to capture early NFRs, and use
a custom set of graphical elements, describing the
soft-targets and relationship between them. NFRs plans
to put forward the qualitative description method of
non-functional requirements, but cannot quantitative
analysis and validation.
3. E-SIGs
3.1. SIGs
Chung’s SIGs figure usually used to represent the quality
attributes[12] and architectural decisions[13]. But the
SIGs figure only for qualitative analysis has restricted
the use of it. Figure 1 shows the representation meaning
of SIG graph. Figure 2 is a typical SIGs figure,
expressed the ‘security’ and ‘usability’ of the system.
3.2. The Disadvantage of SIGs
Use The existing SIGs figure can decompose NFR, but
there are still some problems limits its application. 1.
With the NFR decomposition, the increasing number of
targets, a large number of SIGs figure are formatted. 2.
There is no path symbol. 3. The decomposition
relationship on NFR only limits at and / or. With the
decomposition running, it is not enough to describe the
relationship in the decomposition process. 4. Only
‘Good’, ‘Satisfy’ and other identification symbol can
JCC
An Analysis Method for Refinement and Decomposition of Software Non-Functional Requirement
pass in SIGs figure. There is no quantitative description.
3.3. Modification and Extension of SIGs
As the description is not sufficient for SIGs on the sub
target relationship, the following modifications and
extensions is necessary on symbol system.
 Use ‘direction arrow’ to describe the decomposition
path from parent goals to child goals.
 Discard the "arc" means "and", meet all child goals
can be met with a layer parent goals
 Consistently use "dual-arc + symbols + digital"
represents a relationship between all child goals.
"Multiple choice" (or), and "all selected" (and) are a
special case. Only need meet N out of M (where
M≥N）child goals which are decomposed from parent
goals, the parent goal would achieve.
 Abandon to use positive and negative correlation for
influence degree. Using a quantitative way to
describe the influence between child goals in
evaluation part.
3.4. E-SIGs
After modifications and extensions to the E-SIGs figure,
it has unified the symbols between child goals relation.
In this way, it is facilitate to read, convenient to convert
design diagram to evaluation tree and split it. It also
enriched the expression of sub-goals relationship for a
better representation of NFRs. Abandon to use positive
and negative correlation can reduces the symbols on the
design. It makes more concise in the design. The design
process should be focused on the design stage. The
expression of relationship for the influence between
sub-goals should use quantitative measure method in the
evaluation stage. Table 1 shows the differents between
E-SIGs and SIGs.
4. An Analysis Method for Refinement and
Decomposition of Software Non-Functional
Requirement
3
feature of NFRs considered as an aspect. The realization
of concern can meet NFRs from the client. This method
consists of two parts-analysis and evaluation. In the
analysis part, it will design the content of NFRs. The
results from analysis part will have a quantitative
evaluation and assess it.
4.1. The Separation Strategy of NFRs
Generally speaking, the FRs and NFRs from the users is
mixed together. It is necessary to carry out
decomposition to the software requirements. The
following examples would show the typical requirement
description:
 System needs to be able to have an information query
function; the query can be completed in 2S. (query
function & efficiency)
 System needs to be able to record the user's
operation. (functional requirements)
 System meets the relevant provisions of the state.
(laws and regulations)
From the above examples, it can be found that the first
one is mixed description. The second is the functional
requirements description. The third is a relatively single
description of NFRs. The main NFRs often involve the
efficiency, safety, ease of use, portability, reliability and
maintainability etc. All this are the software using quality
feature.
The interweaving of FRs and NFRs will cause
confusion and omissions in the design analysis. By using
the separate-compound method in design, it can reduce
the omission and conflict to improve the software
quality. The decomposition of NFRs means the
recognition of NFRs. Designers need to identify the
dominant and recessive NFRs, and match those
requirements with the features. Figure 3 would show the
main NFRs of software. It is based on the external and
internal models, and software application quality model
from ISO/IEC 9126.
In general, the requirement that, by through some
steps, the user expectation would be reached is functional
In this research, it presents an extension of the NFR
framework, as a quantitative evaluation method of
software NFRs. This method focus on a series of
sub-goals which are decomposed from NFRs, and the
Table 1. Advantages of E-SIGs.
spoliation possible
Quantitative
evaluation
Child node selection
control
Copyright © 2013 SciRes.
SIGs
×
×
E-SIGs
√
√
weak
strong
Figure 3. Use Quality Model.
JCC
An Analysis Method for Refinement and Decomposition of Software Non-Functional Requirement
4
description. And modified part of these functional
descriptions is NFRs description. Table 2 would help us
to identify the NFRS and FRs.
Table 2. Advantages of E-SIGs.
NFR
Efficiency
Availability
Definition
Under
prescribed
conditions, related to
the used resources, the
capability of adequate
performance supplied
by the software.
With
guaranteed
external
resources
supply, the capability
that the product can
meet the executable
requirement in the
stipulated
conditions
and time.
Reliability
Under
specified
conditions, the ability
that the software can
maintain at a prescribed
level of performance.
Security
confidentiality
The ability of software
that can protect the
information and data.
Unauthorized person or
system cannot read or
modify
these
information and data,
but able to access to
them.
Maintainability
The ability that the
software product can be
modified. Changes may
include
correcting,
improving and the
adaption of software
for the changing of
environment,
requirement
and
functional
specifications.
Usability
Under
specified
conditions, the ability
Copyright © 2013 SciRes.
Typical Description
It has a characteristic of
time in the description.
It often described as the
user expectation can be
achieved in a rated
time. Bandwidth and
hardware requirements
are commonly used in
the description
Emphasis on users can
quickly learn to use the
software function with
an entire instruction
function. Clients will
be able to focus on
their business rather
than on the software
structure.
The
requirement
description
would
emphasize
on
the
normal use duration of
the software, and the
consequences of the
failure. It would shows
the importance that no
failure or crash can be
occurred. Also needs
that the software is able
to
rapid
response
against under crash,
failure or under attack.
In
the
software
description, it will be
involved in ‘security’,
‘confidential’ and other
similar words. It will
emphasize
the
important
of
data
security, and require
multiple
security
methods,
such
as
authentication,
data
encryption and special
network equipment.
The
features
of
software
that
maintenance personnel
can quickly and easily
maintain the software.
(For example, easy test
and changes, good code
readability
and
complete
software
document,
etc.)
Compared with other
software
features,
maintainability is more
related to technical
person.
The description should
involve
the
that the software can be
understood,
learned,
used and attract users.
Portability
The ability that the
software
can
be
migrated from one
environment to another.
Others
Software products need
to comply with the
stipulation of files.
requirements
that
simple operation of
installation
and
software interface.
Description
would
involve more than one
type/version of system;
more
than
one
hardware device (e.g.,
PC and mobile phone).
Description
may
involve national laws,
industry
standard
regulations
files,
national customs taboo,
etc.
4.2. NFRs Top-down Decomposition
The decomposition of NFRs is an iterative top-down
decomposition process. Complete NFRs (NFF) would
consist of some aspects (nffi), expressed as 𝑁𝐹𝐹 =
{𝑛𝑓𝑓1 , 𝑛𝑓𝑓2 , 𝑛𝑓𝑓3 , … , 𝑛𝑓𝑓𝑖 , … , 𝑛𝑓𝑓𝑛 } , nffi is composed
by a set of concern (si) which decomposed according to
the sub-goals feature. Each decomposition will produce a
set of corresponding concern (si).
The results of decomposition and separation can be
shown as 𝑆 = {𝑠1 , 𝑠2 , 𝑠3 , … , 𝑠𝑖 , … , 𝑠𝑛 }, S stands as the
set of NFRs concern. For si which can be continuing
decomposed concern, it also includes the identified
NFRs set 𝑛𝑓𝑓𝑖 ⊆ 𝑁𝐹𝐹 and corresponding decomposed
concern (Sn). it can be achieved the final decomposition
result 𝐶 ⊆ 𝑆, and NFRs decomposition diagrams.
The time of the decomposition process stop
depends on the start time of requirement refinement.
It would have 3 to 5 times to complete the
decomposition for general scale software. The first
decomposition started on a whole system need and
the non-functional feature would be identified from
it. The NFRs would separate from FRs and
correspond to the non-functional feature in the
second decomposition. The third and fourth
decomposition is subdivided on the defined NFRs.
This method is just a suggestion not a regulation.
Because of the changing of number of
decomposition based on the complexity of the
system, the number of decomposition is not
necessarily same in each path. The end of
decomposition is determined by the start of
refinement process.
The
algorithm
description
(NFR_REFINEDECOMPOSE) shows in follows.
Step1: identify NFF decompose , NFF top =NFF;
Step2: NFF top →{s 1 ,……,s i }(i≥1, num = i);
Step3: if (i ≤ num & s i cannot_decompose)
JCC
5
An Analysis Method for Refinement and Decomposition of Software Non-Functional Requirement
then {s i →{s num+1 ,……,s num+j }; num =
num+j;}
else if(s i need_refine)
then {i =i+1;goto step3;}
else if (i>num)
then goto step4;
Step4: Stop
that effect the parent nodes, and 0＜v≤1. k represents
the evaluation value to this node, and 0＜k≤1. When the
set P is empty, this node is root node. When set B is
empty, this node is operation element.
For the operation element, v are equal to k. For the
4.3. NFRs Refinement
d j are child-node. For the design evaluation tree, each
The refinement of NFRs is a continuation of NFR
decomposition. It is a more elaborate analysis and design
for the decomposition result. The refinement process is
similar with the top-down decomposition process. The
final decomposition with design nodes (oi) which are
associated with FRs appear in the leaf nodes of the tree
structure. These operational nodes are the connection
between software non-functional and functional. The
result of NFRs refinement is a refinement selection
diagram which contains a finite number of possible
selections for design. The node on the branch called
operation element (oi). These nodes is described as some
measures, technologies etc, which can realize the FRs.
The NFRs refinement result can be described as 𝑂 =
{𝑜1 , 𝑜2 , 𝑜3 , … , 𝑜𝑖 , … , 𝑜𝑛 }, O stands for the set of operation
elements. For oi, the related parameters also comprise the
corresponding
concerns
𝑠𝑖 ∈ 𝐶
and
related
non-functional properties 𝑛𝑓𝑓𝑖 ⊆ 𝑁𝐹𝐹.
The refine process is similar with the
decomposition process, the algorithm description
(NFR_REFINE) shows in follows.
Step1: identify s refine , s top =s；
Step2: s top →{o 1 ,……,o i }(i≥1, num = i);
Step3: if (i≤ num & s i cannot_refine)
then {o i →{o num+1 ,……,o num+j };
num = num+j;}
else if (o i donotneed_refine)
then {I = i+1;goto step3;}
else if (i > num)
then goto step4;
Step4：Stop
sub-tree can be calculated independently. When the
content of design is complex, the whole design can be
divided into sub-trees which are easy to calculate, and
finally integrate them.
Quantitative evaluation process is a bottom-up
evaluation calculation process. The final evaluation
results depend on the affect weight of the chosen
operation element c ,called as evaluation value k . On
SIG figure, it has abandoned the graph which stands for
the content of influence each other. Instead of using the
evaluation value k from the quantitative evaluation part
4.4. Quantitative Evaluation
Quantitative evaluation of process is a bottom-up
evaluation calculation process. The final evaluation
results depend on the chosen of operation element. The
refinement selection diagram has a tree structure, similar
with node structure on the picture. The analysis tree is
defined as a 5-tuple model
𝐷 = ⟨𝑃, 𝐵, 𝑟, 𝑣, 𝑘⟩ .
where set P is the predecessor, called parent node set. Set
B is the node post-set, called child-node set. r stands for
the relationship between child-node. v means the value
Copyright © 2013 SciRes.
parent node, K d j 

di Bd j
(vd j *kdi ) ,where d i and
show it. Any k ci is composed by the evaluation value
knffi of operation element and the operation element to
the effects of nonfunctional characteristics value xnff .
Then,
kci  knffi 

nff j NFF
j
xnff j
When
j i ,
,
xnff j  0 .
5. Instance Analysis
5.1. Requirement Decomposition
First of all, NFRs and FRs would decompose from the
user description. This management system mainly
includes the following FRs.
 User management
a) The system administrator: add warehouse
administrator account, reset the password of the
warehouse administrator account.
b) Warehouse administrator: modify the personal
passwords, modify personal information.
 Warehouse information management
a) The system administrator: add commodity
classification information, read logs, documents of
all output commodity.
 Warehouse management.
a) Warehouse administrator: commodity warehousing,
outbound, inventory physical count, product scrap.
 Query
a) Warehouse administrator: query the commodity
JCC
6
An Analysis Method for Refinement and Decomposition of Software Non-Functional Requirement
information.
After identify the FRs, there are many NFRs limit and
constraint the FRs. These NFRs are equally important.
The NFRs of this system mainly include: safety,
efficacy, reliability, efficiency, maintainability.
5.2. System Use Case
According to the requirement description, it would use
case model to represent the functional requirements. The
following Figure 4 shows the system use case diagram.
5.3. The NFRs Decomposition and Refinement
Decompose and refine the identified non-functional
feature. The non-functional feature is the root node of the
system. The analysis process shows in Figure 5.
Use ‘security’ as an example to have a simple
description of decomposition and refinement process:
1. Decompose the ‘security’ into ‘application
security’, ‘data security’, based on the domain
Figure 4. The use case diagram.
knowledge and system requirements.
2. Decompose the ‘application security’ into ‘log’,
‘access control’, based on the domain knowledge and
system description.
3. Refine the ‘data security’ into two operation
elements- ‘data encryption’, ‘firewall’, based on the
domain knowledge and system description.
4. Decompose and refine the ‘access control’ ‘log’
node.
5. Decompose the ‘log’, if it does not need,
decompose the next child node. There are no node has to
be decomposed or refinement.
Stop decomposition process and get the system
refinement alternative graph.
5.4. Quantitative Evaluation and Select Scheme
This step would build a tree structure evaluation graph
with the decomposition and refinement result. Each
evaluation value of node is defined by the investigation
from user and experts score.
Use ‘reliability’ as an example to show the quantitative
evaluation process.
Step1: It converts the refinement selection figure to
evaluation figure. Describe the relationship between
elements by using algebraic representation on each node.
The influence value and evaluation value of each node
would achieved by the experts score. Then, ‘reliability’
evaluation chart got as Figure 6.
Step2: Calculate the evaluation value. Use the
calculation of D3 element as an example. The value of
KD3 is the sum of set K.
𝐾𝐷3 = 𝑣𝐷3 ∗ 𝐾𝐷6 + 𝑣𝐷3 ∗ 𝐾𝐷7 ,
the after set of node D6 has a choice relation. So:
𝑣 ∗ 𝐾𝐷8 , 𝑐ℎ𝑜𝑜𝑠𝑒 𝐷8
𝐾𝐷6 = { 𝐷6
,
𝑣𝐷6 ∗ 𝐾𝐷9 , 𝑐ℎ𝑜𝑜𝑠𝑒 𝐷9
Calculated
𝐾𝐷6 = {0.42, 0.28} ,
then
𝐾𝐷3 = {0.288,0.232} ,
Figure 5. The diagram of refinement and
decomposition.
Copyright © 2013 SciRes.
The evaluation value of node D3 is set KD3.
Step3: Select the design scheme. Through quantitative
evaluation, the evaluation value set of the D3 node is
obtained. When the value of D8 is higher than the
evaluation value of the D9 node, without considering the
cost of the equipment, manpower and other
circumstances, it can draw that the maneuverability of
node D8 is superior to the node D9.
Step4: Comprehensive customer requirement. By
using color in the evaluation graph and alternative design
graph, it shows the selected operation element. Output
the evaluation value and marked design graph.
JCC
An Analysis Method for Refinement and Decomposition of Software Non-Functional Requirement
[4]
[5]
[6]
[7]
Figure 6.
The Assessment Diagram.
[8]
6. Conclusion
This method can decompose and refine the requirement
obtained from users, and in-depth analysis of the user’s
need. Eventually it changes into an analysis evaluation
model based on the analysis tree. It can improve the
quality of the product by a strict quality control from the
initial software life cycle. The method is lack of
decomposition standard and refinement guide. It is not
able to deal with the conflict software requirement. It
also needs a more formalized expression for the
evaluation model. It needs to continue to explore and
research in the future work.
[9]
[10]
[11]
REFERENCES
[1]
[2]
[3]
Chen Huowang ， Wang Ji ， Dong Wei,“High
confidence software engineering technologies”,
Acta
Electronica
Sinica ， Vol.41 ，
No.5,2003,pp.1933—1938(in Chinese)
ISO/IECJTC1/SC7/WG6.ISO/IEC9126-1.Informati
onTechnology-Software Quality Characteristics and
Metrics Part 1: Quality Model.
YANG Fang-chun,LONG Xiang-ming, “An
Overview on Software Non-Functional Properties
Research”. Journal of Beijing University of Posts
Copyright © 2013 SciRes.
[12]
[13]
7
and Telecommunications.Vol.27, No.3, 2004
Chung L, et al. Non-functional requirements in
software engineering. Kluwer Academic, 2000.
ISO/IECJTC1/SC7/WG6,
ISO/IEC14598
Part1~Part 6, Information Technology-Evaluation
of Software Product
郑旭飞,“ One Aspect—Oriented Non—Functional
Requirement Framework(AONFRF) Modeling
Method”,
Southwest
China
Normal
University,2005.
Liu Xiaomei ， Liu Shuhn ， Zheng Xiaojun,“
Adapting the NFR Framework to Aspectual Use
case Driven Approach”, 2009 Seventh ACIS
International Conference on Software Engineering
Research, Management and Applications ，2009,
USA, pp.209-214.
Wen Jing, Wang Huaimin, Ying Shi, Ni Youcong,
Wang Tao,“ Toward a Software Architectural
Design Approach for Trusted Software Based on
Monitoring”, Chinese Journal of Computers,
Vol.33, No12, 2010, pp.2320-2334
Sun
LS.Huang
G.Sun
YC.Chen
HJ.Mei
H,“Towards
Modeling
Non-Functional
Requirements in Feature Models”,Computer
Engineering and Science，VOL.28,No.z2,2006，
pp.139—141
ZHANG Yan, MEI Hong,“UML Non-Functional
Attributes Oriented Description and Verification in
UML Class Diagrams”, Journal of Software,
Vol.20,No.6,2009,pp. 1457-1469
CHUNG L ， MYLOPOULOS J ， NIXON
B,“Representing and Using Non-Functional
Requirements
：
A
Process-Oriented
Approach”,IEEE Transactions on Software
Engineering，Vol.18, No.6,1992，pp.483—497
Cysneiros L.etal,“Nonfunctional requirements:
from elicitation to conceptual models”, IEEE
Transactions on Software Engineering, Vol.30,
No.5, pp.328～350
Cooper K, et al,“ Integrating Visual Goal Models
into The Rational Unified Process”, Journal of
Visual Languages and Computing, Vol.17, 2006,
pp.551～583
JCC