TOWARDS AN INTEGRATED SUPPORT FOR TRACEABILITY
OF QUALITY REQUIREMENTS USING SOFTWARE
SPECTRUM ANALYSIS
Haruhiko Kaiya, Kasuhisa Amemiya, Yuutarou Shimizu and Kenji Kaijiri
Shinshu University, 4-17-1 Wakasato, Nagano City, 380-8553, Japan
Keywords:
Traceability, Quality characteristics, Requirements specification, Source codes.
Abstract:
In actual software development, software engineering artifacts such as requirements documents, design di-
agrams and source codes can be updated and changed respectively and simultaneously, and they should be
consistent with each other. However, maintaining such consistency is one of the difficult problems especially
for software quality features such as usability, reliability, efficiency and so on. Managing traceability among
such artifacts is one of solutions, and several types of techniques for traceability have been already proposed.
However, there is no silver bullet for solving the problem. In this paper, we categorized current techniques for
managing traceability into three types: traceability links, central model and projection traceability. We then
discuss how to cope with these types of techniques for managing traceability for software quality features.
Because projection traceability seems to be suitable for quality features and there are few implementations of
projection traceability, we implement a method based on projection traceability using spectrum analysis for
software quality. We also apply the method to an example to confirm the usefulness of projection traceability
as well as traceability links and central model.
1 INTRODUCTION
During a software development, we cannot directly
write source codes that satisfy large and complex re-
quirements because of our cognitive and intellectual
limitation. Therefore, we have to stepwise refine ab-
stract requirements into more concrete artifacts. As
a result, a lot of artifacts are developed such as a re-
quirements document, design diagrams, test case doc-
uments, source codes and so on during the develop-
ment. In addition, an abstraction level of each arti-
fact is different from a level of another artifact. Ide-
ally, such artifacts are developed and completed in
turn along with refining one artifact to another, i.e.,
based on waterfall model. However, each artifact is
updated and changed simultaneously in fact. For ex-
ample, some codes are modified and then correspond-
ing design documents are updated.
We thus have to manage the relationships between
parts in an artifact and those in another for avoiding
inconsistencies between two different artifacts. For
example, inconsistencies can occur if we modified
codes but forgot updating corresponding design docu-
ments. Traceability is one of approaches for avoiding
such inconsistencies, and a lot of techniques have be-
en already proposed. However, most of them focus on
functional requirements.
Recently, quality requirements are focused as
well as functional requirements because completion
among different systems usually depends on the dif-
ferences of quality requirements. For example, most
stakeholders prefer to more usable system. Existing
traceability techniques can be of course applied to
quality requirements, but they are sometimes ineffi-
cient. The main reason is that most quality require-
ments are scattered features over a software engineer-
ing artifact. For example, usability is realized in a
design based on harmony among a lot of interaction
points such as GUI in a system. Other types of qual-
ity requirements such as efficiency, reliability and so
on are also realized in the same way. We thus have
to have another type of traceability techniques in ad-
dition to existing current techniques. In this paper,
we introduce a traceability approach called “projec-
tion traceability” for analyzing scattered features like
quality requirements. The idea of projection trace-
ability is as follows. Instead of explicit links between
artifacts, we first make each artifact to project its qual-
ity features on a model in the same way that a tree
projects its shadow on the ground. We then compare
187
Kaiya H., Amemiya K., Shimizu Y. and Kaijiri K. (2010).
TOWARDS AN INTEGRATED SUPPORT FOR TRACEABILITY OF QUALITY REQUIREMENTS USING SOFTWARE SPECTRUM ANALYSIS.
In Proceedings of the 5th International Conference on Software and Data Technologies, pages 187-194
DOI: 10.5220/0003008501870194
Copyright
c
 SciTePress

one “shadow” of an artifact to another “shadow” of
another artifact to find inconsistencies between these
artifacts. We call such a “shadow” of a software engi-
neering artifact as QSM (Quality Specific Model) in
this paper. If some inconsistencies about some quality
features are found through such comparison, we may
put emphasis on the features and use existing trace-
ability techniques only for the parts of the artifacts
where the features are related.
The rest of this paper is organized as follows. In
the next section, we review current techniques for
traceability and categorize them into two types. We
also review techniques for measuring quality require-
ments. To complement problems of current traceabil-
ity techniques, we propose another type of traceabil-
ity techniques called “projection traceability” in sec-
tion 3. In section 4, we concretely implemented a
method that can be categorized as projection trace-
ability based on spectrum analysis for quality require-
ments. An example for applying the method is shown
in section 5 to confirm the usefulness of the method.
Finally, we summarize our current results and show
the future issues.
2 RELATED WORKS
Software quality requirements are widely focused in
the field of software, and we can find its special
issue in 2008 IEEE Software (Blaine and Cleland-
Huang, 2008). In the issue, importance and chal-
lenges about software quality requirements were sum-
marized, and one of challenges is measurement and
traceability for software quality requirements. In this
section, we briefly review researches about measure-
ment and traceability for software quality require-
ments to clarify the importance of software qual-
ity requirements. We use NFR (Non-Functional Re-
quirements) as a synonym of quality requirements
even though NFR contains more things than qual-
ity requirements (Blaine and Cleland-Huang, 2008),
(Glinz, 2008).
First, we focus on traceability links among differ-
ent kinds of software engineering artifacts. Managing
explicit links among different artifacts is normal idea.
For example, links between a section in a require-
ments document and classes and packages in design
documents help us to find change impacts on design.
Figure 1 shows a general example using traceability
links. However, maintaining such links takes a lot
of efforts in general. To mitigate such effort, several
kinds of ideas are proposed. Lucia et al. used an infor-
mation retrieval technique to mange such links (Lucia
et al., 2009). Mandelin et al. used a probability model
Stop Machine
Toll Machine
Num Machine
Manager
Unit Price
IN
OUT
Stop Machine
Toll Machine
Num Machine
Manager
Unit Price
IN
OUT
<<bound ary>>
Admin
+ down() : void
+ gettime() : int
<<bound ary>>
Stop
+ message (param1 : String) : void
<<bound ary>>
TenKey
+ setPrice(price : int) : void
<<bound ary>>
Register
+ get() : int
+ set(p : int) : void
UnitPr ice
+ remov eTransaction(lot :i nt) : void
+ getTransactio n(lot : int) : Transaction
+ enter(lot :in t) : v oid
<<control>>
Enter
+ getLot () : int
+ set(lot : int, ti me : int) : void
+ term(exittime : int) : int
-entertime : int
-l ot : int
Transact ion
0..*
+ notifyPaid() : void
+ setLot(lot :i nt ) : void
<<control>>
Exit
<<bound ary>>
Admin
+ down() : void
+ gettime() : int
<<bound ary>>
Stop
+ message (param1 : String) : void
<<bound ary>>
TenKey
+ setPrice(price : int) : void
<<bound ary>>
Register
+ get() : int
+ set(p : int) : void
UnitPr ice
+ remov eTransaction(lot :i nt) : void
+ getTransactio n(lot : int) : Transaction
+ enter(lot :in t) : v oid
<<control>>
Enter
+ getLot () : int
+ set(lot : int, ti me : int) : void
+ term(exittime : int) : int
-entertime : int
-l ot : int
Transact ion
0..*
+ notifyPaid() : void
+ setLot(lot :i nt ) : void
<<control>>
Exit
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
ti me++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
ti me++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
ti me++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
ti me++;
return time;
}
}
Figure 1: Traceability links.
Stop Machine
Toll Machine
Num Machine
Manager
Unit Price
IN
OUT
Stop Machine
Toll Machine
Num Machine
Manager
Unit Price
IN
OUT
<<boundary> >
Admin
+ down() : void
+ gettime () : int
<<boundary> >
Stop
+ message (param1 : String) : void
<<boundary> >
TenKey
+ setPrice(price :i nt) : void
<<boundary> >
Register
+ get() : int
+ set(p : int) : void
UnitPr ice
+ remov eTransaction(lot :i nt ) : void
+ getTransactio n(lot : int) : Transaction
+ enter(lot :in t) : void
<<control>>
Enter
+ getLot () : int
+ set(lot : int, ti me :int ) : void
+ term(exittime : int) :int
- entertime: in t
- lot : int
Transaction
0..*
+ notifyPaid() : void
+ setLot(lot : int ) : void
<<control>>
Exit
<<boundary> >
Admin
+ down() : void
+ gettime () : int
<<boundary> >
Stop
+ message (param1 : String) : void
<<boundary> >
TenKey
+ setPrice(price :i nt) : void
<<boundary> >
Register
+ get() : int
+ set(p : int) : void
UnitPr ice
+ remov eTransaction(lot :i nt ) : void
+ getTransactio n(lot : int) : Transaction
+ enter(lot :in t) : void
<<control>>
Enter
+ getLot () : int
+ set(lot : int, ti me :int ) : void
+ term(exittime : int) :int
- entertime: in t
- lot : int
Transaction
0..*
+ notifyPaid() : void
+ setLot(lot : int ) : void
<<control>>
Exit
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
time++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
time++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
time++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
time++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
time++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
time++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
time++;
return time;
}
}
public class Stop {
private int time=0;
private Enter enter;
public void setEnter(Enter enter) {
this.enter = enter;
}
public int gettime() {
time++;
return time;
}
}
Figure 2: Central model.
Stop Machine
Toll Machine
Num Machine
Manager
Unit Price
IN
OUT
Stop Machine
Toll Machine
Num Machine
Manager
Unit Price
IN
OUT
<<boundary>>
Admin
+ down() : void
+ gettime() : int
<<boundary>>
Stop
+ message(param1 : String) : void
<<boundary>>
TenKey
+ setPrice(price :i nt) : void
<<boundary>>
Register
+ get() : int
+ set(p : int) : void
UnitPrice
+ removeTransaction(lot :int ) : void
+ getTransaction(lot : int) : Transaction
+ enter(lot :in t) : void
<<control>>
Enter
+ getLot() : int
+ set(lot : int, ti me :int ) : void
+ term(exittime : int) : int
-entertime :i nt
-lot : int
Transaction
0..*
+ notifyPaid() : void
+ setLot(lot : int) : void
<<control>>
Exit
<<boundary>>
Admin
+ down() : void
+ gettime() : int
<<boundary>>
Stop
+ message(param1 : String) : void
<<boundary>>
TenKey
+ setPrice(price :i nt) : void
<<boundary>>
Register
+ get() : int
+ set(p : int) : void
UnitPrice
+ removeTransaction(lot :int ) : void
+ getTransaction(lot : int) : Transaction
+ enter(lot :in t) : void
<<control>>
Enter
+ getLot() : int
+ set(lot : int, ti me :int ) : void
+ term(exittime : int) : int
-entertime :i nt
-lot : int
Transaction
0..*
+ notifyPaid() : void
+ setLot(lot : int) : void
<<control>>
Exit
public clas s Stop {
private int time=0;
private Ent er enter;
public void setEnter(Enter enter) {
this.enter = ent er;
}
public int gettime() {
ti me++;
return ti me;
}
}
public clas s Stop {
private int time=0;
private Ent er enter;
public void setEnter(Enter enter) {
this.enter = ent er;
}
public int gettime() {
ti me++;
return ti me;
}
}
public clas s Stop {
private int time=0;
private Ent er enter;
public void setEnter(Enter enter) {
this.enter = ent er;
}
public int gettime() {
ti me++;
return ti me;
}
}
public clas s Stop {
private int time=0;
private Ent er enter;
public void setEnter(Enter enter) {
this.enter = ent er;
}
public int gettime() {
ti me++;
return ti me;
}
}
public clas s Stop {
private int time=0;
private Ent er enter;
public void setEnter(Enter enter) {
this.enter = ent er;
}
public int gettime() {
ti me++;
return ti me;
}
}
public clas s Stop {
private int time=0;
private Ent er enter;
public void setEnter(Enter enter) {
this.enter = ent er;
}
public int gettime() {
ti me++;
return ti me;
}
}
public clas s Stop {
private int time=0;
private Ent er enter;
public void setEnter(Enter enter) {
this.enter = ent er;
}
public int gettime() {
ti me++;
return ti me;
}
}
public clas s Stop {
private int time=0;
private Ent er enter;
public void setEnter(Enter enter) {
this.enter = ent er;
}
public int gettime() {
ti me++;
return ti me;
}
}
Convert
(Projection)
Convert
(Projection)
Convert
(Projection)
Figure 3: Projection traceability.
to do that (Mandelin et al., 2005). Ratanotayanon et
al. used differences between different versions of ar-
tifacts to manage traceability links efficiently (Ratan-
otayanon et al., 2009). Lopez et al. used techniques
of NLP (Natural Language Processing) and ML (Ma-
chine Learning) to trace quality requirements to archi-
tecture (Gokyer et al., 2008).
ICSOFT 2010 - 5th International Conference on Software and Data Technologies
188

Second, we focus on a central model shared by
software engineering artifacts. By using a central
model, we can easily trace an artifact to another via
the model. Figure 2 also shows a general example
using a central model for traceability. Jane et al.
proposed a method called “Goal Centric Traceabil-
ity” for quality requirements (Cleland-Huang, 2005),
(Cleland-Huang et al., 2008). In the method, a
goal model plays the role of a central model. The-
saurus and ontology are popular notations for a cen-
tral model. Daneva et al. proposed an ontology for
NFR (Kassab et al., 2009), (Kassab et al., 2008).
However, how to make links between ontology and
software artifacts was not mentioned. Saeki et al.
used a domain ontology for traceability between doc-
uments and source codes (Yoshikawa et al., 2009).
Finally, we briefly review researches about mea-
surement on quality requirements. One of the fa-
mous catalog for software quality requirements is
ISO9126 standard (International Standard ISO/IEC
9126-1, 2001), and the standard contains about 20
subcharacteristics such as accuracy, reliability and so
on. Washizaki et al. provided measurement meth-
ods using usual metrics on source codes and design
diagrams such as LOC (Lines of Codes) and CC
(Cyclomatic Complexity) for each subcharacteristic
(Washizaki et al., 2008). Jane et al. proposed a
method to detect and to categorize NFR contained in a
document using IR (Information Retrieval) and NLP
(Natural Language Processing) techniques. (Cleland-
Huang et al., 2006). To count and normalize the
number of NFR in a document, we can visualize a
distribution of NFR. Kaiya et al. proposed a tech-
nique to summarize such distribution and to visual-
ize it based on a metaphor about spectrum analysis
in optics (Kaiya et al., 2009). They used the tech-
nique to identify domain specific commonality by di-
rectly comparing one spectrum of a system to another.
These kinds of researches are useful for tracing qual-
ity requirements indirectly.
3 PROJECTION APPROACH FOR
QUALITY REQUIREMENTS
TRACEABILITY
As mentioned in the previous section, traceability link
approach and central model approach are used ac-
tively and seem to be effective. However, they have
several drawbacks respectively. Different kinds of ap-
proaches thus seem to mutually mitigate such draw-
backs. Because both approaches focus on the units in
software artifacts, it is not easy to handle scattered
features in artifacts. Quality requirements are typical
scattered features in software artifacts, thus another
approach suitable for such scattered features will be
helpful in addition to current two approaches.
In the same way as Figures 1 and 2, we depict a
general example called projection traceability in Fig-
ure 3. According to projection traceability, each soft-
ware engineering artifact is converted to (or projected
on) some specific model respectively. In Figure 3,
the specific model is written in bar charts. By com-
paring such specific models, we can easily recognize
scattered features such as quality requirements. We
never think projection traceability solves all problems
in quality requirements traceability. Projection trace-
ability can cope with another kinds of approaches
such as traceablity links or central model. For exam-
ple, we first use projection traceability to find what
kind of quality features is inconsistent between re-
quirements documents and design diagrams. We then
use traceablity links to browse concrete units of arti-
facts such as requirements sentences and classes with
inconsistency.
In projection traceability approach, how to project
each artifact on the model is important. As mentioned
in the previous section, we have already had some
techniques for measuring quality requirements. We
can use such techniques to construct projectors for
each type of software engineering artifacts.
4 TRACEABILITY USING
QUALITY SPECTRUM
ANALYSIS
In this section, we concretely implement a method
based on projection traceability approach in section 3
using spectrum analysis for software quality require-
ments (Kaiya et al., 2009).
4.1 Quality Spectrum Analysis
Spectrum analysis for quality requirements is one of
measurement techniques to summarize the scattered
quality features over a requirements document. The
technique enables us to visualize quality characteris-
tics in the same way as sound waves. We explain how
to perform spectrum analysis for quality requirements
by using an example in Figure 4. In the figure, there
is a list of requirements and a list of quality character-
istics. These two lists are inputs of the technique. An
analyst then decides quality characteristics related to
each requirement. For example, a requirement #3 is
related to both resource efficiency and changeability.
TOWARDS AN INTEGRATED SUPPORT FOR TRACEABILITY OF QUALITY REQUIREMENTS USING
SOFTWARE SPECTRUM ANALYSIS
189

Func. Req. of a browser
1. bookmark shall be
supported.
2. offline browsing
shall be supported.
3. fonts shall be able to
be changed.
4. printing shall be
supported.
5. digital signature
shall be accepted.
ISO9126 characteristics
........
• Resource efficiency
• Changeability
• Interoperability
• Security
…….
0
1
Resource Change Interop. Security
Requirements Quality Characteristics
3/5
1/5 1/5 1/5
power
Figure 4: An example of spectrum analysis for require-
ments.
Design Impl.Req.
QSM
Development Process
QSM QSM
Spectrum
Analysis
Compare Compare
Manual
Trans.
Manual
Trans.
Projection
Spectrum
Analysis
Spectrum
Analysis
Projection Projection
Figure 5: Projection traceability using spectrum analysis.
After that, the analyst counts the number of require-
ments related to each quality characteristic. For ex-
ample, resource efficiency is related to 3 out of 5
requirements. The counted numbers of each qual-
ity characteristic lets us know how often each quality
characteristic is mentioned in a requirements docu-
ment, and we assume the number is the importance
of each quality characteristic. We call the number
as “power” of a quality feature such as resource ef-
ficiency according to a metaphor of waves. For ex-
ample in this figure, resource efficiency is more im-
portant than others because resource efficiency is fre-
quently mentioned in the list of requirements. We
may give some weights to each requirement based on
the priority among the requirements. We may also re-
format a requirements document (Ncube et al., 2007)
if the document is highly structured like i* or KAOS
goal models.
4.2 Projection Traceability over a
Development Process: An
Implementation
Although the spectrum analysis for quality require-
ments is a simple but a powerful technique to visu-
alize quality requirements over a requirements docu-
ment, the technique is applied only to a list of sen-
tences like documents. We find we can implement a
concrete method of projection traceability mentioned
in section 3 based on the spectrum analysis for quality
requirements if the spectrum analysis can be applied
to other types of software engineering artifacts such
as design diagrams and source codes.
We implement projection traceability in Figure 3
by generalizing the idea of spectrum analysis in Fig-
ure 4. The outline of the method of projection trace-
ability using the spectrum analysis is shown in Fig-
ure 5. Boxes at the top of the figure show software
engineering artifacts such as requirements specifica-
tion, design documents and source codes. During a
software development process, each artifact is trans-
formed into another if we regard the process as the
transformation from abstract artifacts (e.g., require-
ments) to concrete artifacts (source codes). Such
transformation is performed manually in general, but
it is sometimes performed automatically thank to
model-driven architecture. To establish projection
traceability, we project each artifact into QSM (Qual-
ity Specific Model), and apply spectrum analysis to
each QSM. QSM is a sub-structure of an artifact, and
the sub-structure can specify quality features of the
artifact. We expect such projection is achieved auto-
matically or semi-automatically. How to achieve such
projection is discussed in the rest of this section. Af-
ter obtaining QSM of each artifact, we may simply
apply spectrum analysis to each QSM, and compare a
spectrum to another. If there are some differences be-
tween two spectra, there can be some inconsistencies
among artifacts related to the spectra.
The major advantages of this method are as fol-
lows. First, traceability can be always checked even
if each artifact can be maintained and changed inde-
pendently. Second, the method does not restrict the
ordering of software development. For example, we
may change source codes and then update design doc-
ument. Projection traceability merely tells trends of
inconsistencies, thus it does not directly point out in-
consistency parts in artifacts. It is an inherent draw-
back of projection traceability.
ICSOFT 2010 - 5th International Conference on Software and Data Technologies
190

4.3 QSM for Requirements
Specification
In the case of requirements, the original spectrum
analysis mentioned in section 4.1 can be directly used,
and QSM of requirements is the list of requirements
sentences.
We have no fixed idea of QSM for design docu-
ments. However, we will use sequence diagrams and
activity diagrams for QSM.
4.4 QSM for Source Codes
main
method A
openfile method C
method B
method D
callcall
call
call
call
Figure 6: An example of path based weight on a call graph.
In the case of source codes, we focus on a call graph
among methods or functions as a candidate of QSM.
The reasons are as follows. First, a call graph can be
generated automatically based on source codes. In the
case of object-oriented programs, we cannot gener-
ate complete call graphs because of dynamic binding.
However, approximate call graphs can be obtained.
Second, a sequence of methods linked by call rela-
tionships (we simply call such a sequence as “path”
in this paper) almost corresponds to a use case, thus
the path corresponds to a requirement.
By using Figure 6, we explain how to obtain a
quality spectrum from a call graph. In the figure, there
is a simple call graph and it contains five methods
except main method. We then make relationship be-
tween each method and quality characteristics in the
same way as a requirement in Figure 4 according to
terms in each method and its comments. For exam-
ple, a method “openfile” may be related to usability
if it includes GUI for opening files. Three paths can
be identified in the call graph, and each method is
contained in several paths. The number of paths on
a method is used as a weight of the method, and such
weights are used to calculate powers in a quality spec-
trum. Suppose “openfile” method is contained three
paths, the method is related to usability, and no other
methods are related to usability. A power of usability
is then three.
5 EXAMPLE
To confirm the usefulness of a projection traceability
method mentioned in section 4, we apply the method
to an example. The main goal of this example is to
confirm whether the method can help us to find in-
consistencies of some quality requirements between
requirements and source codes.
5.1 Overview of the Example
To achieve the main goal above, we prepared the fol-
lowing three software engineering artifacts.
• R: a requirements list of a system where some
quality features are important.
• X: source codes for the system and the codes are
consistent with R. In other words, all quality fea-
tures are implemented in the codes X. Actually,
codes X did not exist but we virtually developed
codes X. We will explain this point in section 5.3.
• Y: source codes for the system and the codes are
not consistent with R with respect to quality fea-
tures. In other words, all quality features are not
implemented in the codes Y.
Stopper
Money Collector
Section
Figure 7: A car park.
We concretely used a system for controlling stop-
pers and a money collector in a car park as shown
in Figure 7. There is a car park, and it has several
sections for each car and one machine for collecting
money. In each section, there is a stopper to fix a car
until its payment is finished. The system controls the
money collector and stoppers automatically.
In this system, following quality features are es-
pecially important because of each reason.
• Performance (Pe): Because more than one car can
enter several sections simultaneously, the system
should control several stoppers at the same time.
The system is thus required enough performance.
• Usability (Us): The system interacts with a man-
ager as well as hardware devices because the
TOWARDS AN INTEGRATED SUPPORT FOR TRACEABILITY OF QUALITY REQUIREMENTS USING
SOFTWARE SPECTRUM ANALYSIS
191

manger set the unit price for example. The sys-
tem is thus required usability.
• Reliability (Re): Because the system is a kind of
embedded systems, reliability is important.
• Accuracy (Ac): Accuracy is also important be-
cause the system handles the amount of money.
• Changeability (Ch): We can easily assume
changes about hardware devices. For example,
the number of money collectors increases for bet-
ter availability of payment. The system thus has
to take changeability into account.
We simply abbreviate the name of each feature to its
first two letters like “Pe” in the following part of this
paper.
5.2 Requirements projected on QSM
We prepare a requirements list i.e., R, and the list con-
tains the following ten requirements.
1. The system shall enable a manager to set a unit of
price.
2. The system shall receive an ID of a stopper and
the current time when the stopper raises. Note
that each stopper raises when a car enters a sec-
tion where the stopper is equipped.
3. The system shall receive a numerical number put
into a money collector. The number specifies a
section and its stopper which fixes a car.
4. The system shall know the amount of money (pay-
ment) when someone puts money into a money
collector.
5. The system shall know whether a car is fixed or
not in a section.
6. The system shall know the current time.
7. The system shall decide whether the payment is
enough for parking of a car.
8. The system shall release a car if its payment is
enough and a stopper fixes the car.
9. The system shall pay back all payment if the pay-
ment is not enough.
10. The system shall ignore a numerical number put
via a money collector if no car is fixed at a section
specified by the number.
According to the spectrum analysis mentioned in sec-
tion 4.3, we obtained the relationships between each
requirement and quality characteristics. For exam-
ple, req#02 is related to performance and reliability
because the requirement is about receiving data from
stoppers. Because the system interacts hardware de-
vices frequently, the number of relationships between
requirements and reliability is relatively high. We
then calculate and visualize their spectrum as shown
in Figure 8. For example in the figure, the power of
reliability (Re) is 0.8. This value implies reliability is
so important in this system.
5.3 Codes X and Y projected on QSM
We developed source codes Y based on requirements
R, but Y could not completely satisfy quality require-
ments in R. The codes contain 8 classes of Java and
31 methods. Concretely, Y could not satisfy the fol-
lowing quality requirements in R.
• Performance
• Changeability
Because we did not have actual hardware devices, the
codes Y could run as a console application on gen-
eral OS. Interactions between the system and devices
were represented as standard inputs and outputs on
the console. We applied spectrum analysis mentioned
in section 4.4 to QSM of Y. Table 1 shows the data
for quality spectrum of codes Y. As shown in the ta-
ble, there are 31 methods in Y, and a method “Ad-
min.inputPrice” is related to usability and accuracy
because this method is about UI for setting unit of
price for example. The last column in the table shows
the number of paths on each method, thus scores in
other columns are weighted with the number when
powers of each quality characteristics are calculated.
For example, the power of usability is four even when
usability is related to only two methods. Note that
each power is normalized with 46 (the total number
of the last column) when we visualize the powers as a
spectrum.
We did not actually write codes X that completely
satisfy quality requirements R, but we put comments
to each method in Y. Such comments specify how to
improve a method to satisfy all quality requirements
in R. We regard codes Y with such comments as codes
X, and applied spectrum analysis mentioned in sec-
tion 4.4 to QSM of X.
5.4 Discussion
Figure 8 shows spectra of requirements R, codes X
and Y. We have following two expectations to these
spectra.
1. We expect a spectrum of R is similar to another of
X because X was virtually written to satisfy qual-
ity requirements R.
2. We expect a spectrum of R is different from
another of Y with respect to performance and
changeability.
ICSOFT 2010 - 5th International Conference on Software and Data Technologies
192

Table 1: Data for spectrum of codes Y.
Performance (Pe) Usability (Us) Reliability (Re) Accuracy (Ac) Changeability (Ch) Num. of Paths on the method
31 methods
Admin.inputPrice 1 1 1
Admin.setUnitPrice 1
Enter.enter 1 2
Enter.getTransaction 3
Enter.removeTransaction 1
Enter.setStop 1
Exit.notifyPaid 3
Exit.setEnter 1
Exit.setLot 1 1 6
Exit.setRegister 1
Exit.setStop 1
Exit.setTenKey 1
Exit.setUnitPrice 1
Main.getLotNumber 0
Main.main 0
ReadLn.readln 0
ReadLn.readnat 0
Register.setExit 1
Register.setPrice 1 1 3
Stop.carEntered 1 2
Stop.down 1 1
Stop.gettime 1 1
Stop.setEnter 1
TenKey.driverReturned 1 6
TenKey.message 1 2
TenKey.setExit 1
Transaction.getLot 1
Transaction.set 1 1
Transaction.term 1
UnitPrice.get 1
UnitPrice.set 1
powers (not normalized) 0 4 17 7 7 46
According to expectation 1, a spectrum of R is al-
most similar to another of X except reliability. As
mention in earlier part in this section, the system did
not control actual hardware devices but it merely run
on a generic OS. Because reliability largely depends
on interfaces between the system and hardware de-
vices, we thus overlooked reliability related to state-
ments or comments even in codes X.
According to expectation 2, a spectrum of R is
different from another of Y with respect to reliabil-
ity, performance and changeability. As mentioned
in a paragraph above, the difference about reliabil-
ity was caused because codes did not actually interact
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
Pe Us Re Ac Ch
R X
Y
power
Figure 8: Spectra of requirements, codes X and Y.
with hardware devices. The differences about perfor-
mance and changeability were intentionally embed-
ded in codes Y, thus projection traceability based on
spectrum analysis seems to work well. After finding
such differences, we may use or establish traceability
links or a central model to browse concrete parts of
requirements and source codes.
6 CONCLUSIONS
In this paper, we first reviewwhat kinds of traceability
techniques exist and discuss what kinds of character-
istics each kind of the techniques has. We roughly
categorized such techniques into two types: trace-
ability links and central model. As a result, we re-
gard we have to explore another type of techniques
other than existing techniques because existing tech-
niques are not good at analyzing scattered features in
software engineering artifacts such as quality charac-
teristics. We thus proposed a traceability approach
called “projection traceability” based on a concept of
a spectrum analysis for software quality requirements
(Kaiya et al., 2009). Projection traceability helps us
to find the tendency of inconsistencies among differ-
ent types of artifacts such as a requirements document
and source codes. After identifying tendency of such
inconsistencies, existing techniques such as traceabil-
ity links can be used efficiently. We finally apply
a method of projection traceability to an embedded
software system, and we confirmed the method could
help us to find the tendency of quality inconsistencies
to an extent.
In an actual software development, some types of
requirements are added even after release of a system
(Nakatani et al., 2008). Therefore, we never complete
requirements, design and codes in turn. Projection
traceability can be applied even in such a develop-
ment because software engineering artifacts can be
TOWARDS AN INTEGRATED SUPPORT FOR TRACEABILITY OF QUALITY REQUIREMENTS USING
SOFTWARE SPECTRUM ANALYSIS
193

analyzed respectively.
In architecture, design and codes, quality features
are implemented by using specific structures of mod-
ules, design patterns or algorithms. For example,
MVC is a famous design pattern for high changeabil-
ity. We do not yet focus on such points when we de-
velop projectors for design diagrams and codes, thus
we want to take them into account in the future. In
addition, existing software components, e.g., libraries
and application frameworks are used in most of all
software systems, and such components off course
give effects on whether quality requirements are sat-
isfied or not. We also want to focus on how to han-
dle impacts by reused components when we analyze
traceability about quality requirements.
ACKNOWLEDGEMENTS
This research was partially supported by the Ministry
of Education, Science, Sports and Culture, Grant-in-
Aid for Scientific Research (C), 20500032, 2010.
REFERENCES
Blaine, J. D. and Cleland-Huang, J. (2008). Software qual-
ity requirements: How to balance competing priori-
ties. IEEE Software, 25(2):22–24.
Cleland-Huang, J. (2005). Toward Improved Traceability of
Non-Functional Requirements. In International Work-
shop on Traceability in Emerging Forms of Software
Engineering (TEFSE), pages 14–19.
Cleland-Huang, J., Marrero, W., and Berenbach, B. (2008).
Goal-centric traceability: Using virtual plumblines to
maintain critical systemic qualities. IEEE Trans. Soft-
ware Eng., 34(5):685–699.
Cleland-Huang, J., Settimi, R., Zou, X., and Solc, P. (2006).
The detection and classification of non-functional re-
quirements with application to early aspects. In RE,
pages 36–45.
Glinz, M. (2008). A risk-based, value-oriented approach to
quality requirements. IEEE Software, 25(2):34–41.
Gokyer, G., Cetin, S., Sener, C., and Yondem, M. T.
(2008). Non-functional requirements to architec-
tural concerns: Ml and nlp at crossroads. Software
Engineering Advances, International Conference on,
0:400–406.
International Standard ISO/IEC 9126-1 (2001). Software
engineering - Product quality - Part 1: Quality model.
Kaiya, H., Tanigawa, M., Suzuki, S., Sato, T., and Kaijiri,
K. (2009). Spectrum Analysis for Quality Require-
ments by Using a Term-Characteristics. In 21th Inter-
national Conference Advanced Information Systems
Engineering (CAiSE 2009), pages 546–560, Amster-
dam, The Netherlands. LNCS 5565.
Kassab, M., Daneva, M., and Ormandjieva, O. (2008). A
meta-model for the assessment of non-functional re-
quirement size. In SEAA, pages 411–418.
Kassab, M., Ormandjieva, O., and Daneva, M. (2009). An
ontology based approach to non-functional require-
ments conceptualization. Software Engineering Ad-
vances, International Conference on, 0:299–308.
Lucia, A. D., Oliveto, R., and Tortora, G. (2009). Assess-
ing ir-based traceability recovery tools through con-
trolled experiments. Empirical Software Engineering,
14(1):57–92.
Mandelin, D., Xu, L., Bod´ık, R., and Kimelman, D. (2005).
Jungloid mining: helping to navigate the api jungle.
In PLDI, pages 48–61.
Nakatani, T., Hori, S., Ubayashi, N., Katamine, K., and
Hashimoto, M. (2008). A case study: Requirements
elicitation processes throughout a project. In RE,
pages 241–246.
Ncube, C., Lockerbie, J., and Maiden, N. A. M. (2007).
Automatically generating requirements from * mod-
els: Experiences with a complex airport operations
system. In REFSQ, pages 33–47.
Ratanotayanon, S., Sim, S. E., and Raycraft, D. J. (2009).
Cross-artifact traceability using lightweight links. In
TEFSE ’09: Proceedings of the 2009 ICSE Workshop
on Traceability in Emerging Forms of Software Engi-
neering, pages 57–64, Washington, DC, USA. IEEE
Computer Society.
Washizaki, H., Hiraguchi, H., and Fukazawa, Y. (2008).
A metrics suite for measuring quality characteristics
of javabeans components. In PROFES, pages 45–60.
LNCS 5089.
Yoshikawa, T., Hayashi, S., and Saeki, M. (2009). Recov-
ering traceability links between a simple natural lan-
guage sentence and source code using domain ontolo-
gies. In ICSM, pages 551–554.
ICSOFT 2010 - 5th International Conference on Software and Data Technologies
194