Affinity and Tree Diagrams: A Practical Approach to
Control Requirement Volatility in Software Projects
B.R Shubhamangala
Research Scholar
Department of MCA
Dayananda sagar Institutions
Bangalore-78
[email protected]
V Suma
Associate Dean
Research Industry Incubation Centre,
Dayananda sagar Institutions
Bangalore-78
[email protected],
Abstract— Requirement volatility is considered as a critical risk
factor in software enterprises. Requirement volatility is driving
the project towards poor quality, higher cost and schedule
slippage. Hence, to address volatility, enterprises have taken
various measures. Though measures could not effectively address
volatility, the major four reasons causing volatility were brought
out. By exploring the origin of above said reasons and factors
influencing those reasons, it is evident that volatility can be
controlled but cannot be eliminated. The four reasons are
contributing towards volatility by rendering volatility defects.
Hence, research by industrial multiple case study approach is
undertaken with the motive of controlling volatility. Projects
considered under case study has spanned across major five
application domains from six CMMI level 5 certified companies.
Defect analysis of each of the four reasons is carried over in pre
release and post release phase of the projects. From the defect
analysis, a solution of affinity diagram followed by tree diagram
to address the volatility is introduced. Effectiveness of solution in
controlling volatility is made evident by the practical case study
example.
Key words: Requirement Volatility; Affinity Diagrams; Tree
diagrams; Case study
I. INTRODUCTION
Competitive business pressure of IT market and ever
increasing customer demands, are pushing the IT enterprises
to deliver niche quality products. Software quality is
determined by requirements [1].Since, the requirements span
across all the major activities project development such as
cost estimation, schedule allocation, deign specification,
coding etc, requirements are identified as key drivers of cost
and schedule. Quality, cost and schedule are the critical
project success factors and these factors are decided by the
requirements. In reality, requirements have become critical
risk factor instead of assuring project success, because of
changing nature of requirements [2]. Although initial set of
requirements called base requirements are well documented,
requirement changes occur during software development
process and these changes have greater impact on cost, quality
and schedule of the project. The requirement changes such as
addition, deletion and modification results in re-analysis, redesign, and re-implementation.
Hence, due to requirements changing nature, quality of the
product will suffer, cost will spiral out of control and schedule
increases beyond estimation and this drives the project to be a
L Manjunatha Rao
Director
Department of MCA
Dayananda sagar Institutions
Bangalore-78
[email protected]
challenged task for enterprise. Changing nature of
requirements is called volatility. Though enterprises are
applying efforts to restrict the frequency of volatility,
practically volatility it is growing out of control. Efforts of
enterprises have resulted in contributing two facts about
volatility. The first contribution is major four underplaying
reasons which are causing volatility are brought to light. For
the sake of clarity, these reasons are noted as R1, R2, R3 and
R4 in this paper. The reasons and corresponding notations are
given in table 1.
TABLE 1: REASONS CAUSING VOLATILITY
Table 1 infers that reasons R1 and R2 are related with human
interaction. The reasons R3 and R4are influenced by market
and organization polices and addressing the reasons R3 and
R4 are out of scope for project technical team. Second
contribution is that the reasons R1, R2, r3 and R4 are
contributing towards volatility, by rendering volatility defects.
By exploring the nature and origin of reasons from R1 to R4,
two facts are evident. The first fact is that volatility can be
controlled but cannot be eliminated. The second contribution
is that the problem is not with requirements volatility but
problem is with inadequate approaches in dealing with
requirements volatility.
In the current scenario, absence of efficient approach to
control and manage volatility, is leading to the practical
research. Since requirement volatility is a major challenge in
all the domains of project development, a multiple case study
spanning across five major application domains is undertaken
in six CMMI level5certified companies. Since, the enterprises
have found strong correlation between the volatility and its
corresponding defects caused due to reasons R1 to R4,
volatility can be addressed by addressing the defects caused
by reasons R1 to R4. This paper presents the results of
research undertaken, with respect to pre release and post
release volatility defect(VD) density and severity. Based on
the results of research, the reasons are prioritized and the
761
practical fact which is driving the reasons of volatility is found.
domains. Projects considered are from medium, low and
An effective solution to reduce the volatility is introduced by
high complexities and different methodologies of
employing affinity diagram and tree diagram in requirements
development. Prioritization of volatility reasons based on
elicitation and analysis phase. This paper is organized as
defects severity is carried over. Secondly solution to reduce
follows. Section I comprises of this introduction. Section II
volatility is based on the practical study carried over in
describes related work. Section III points out research
industries.
objective Section IV explains research design Section V
III. RESEARCH OBJECTIVE
explores key findings and analysis. Section VI contributes The following are the research objectives under taken in this
Solution to requirements volatility. Section VII draws paper.
discussions and Section VIII concludes.
1. What is the percentage of defects caused due to
requirement volatility in pre release and post release
II. RELATIVE WORK
phase?
Requirement volatility is inherent issue with requirements, 2. What is the percentage of defects and severity of defects
caused due to major four reasons causing the volatility in
extensive research work is carried out to find the reasons of
pre release and post release phase?
volatility, impact of volatility in terms of defects caused due
to volatility based on four projects, requirements change 3. Prioritize the reasons causing the volatility based on
defects analysis
management frame work and measures taken handle volatility
in industry. To the authors best knowledge and efforts any 4. Find the underplaying facts that are triggering the reasons
of volatility.
research undertaken to reduce the volatility, could not be
5. A solution to reduce the volatility.
found. The summary of the survey is summarized below.
Authors in [3] have undertaken study to investigate the impact
IV. RESEARCH DESIGN
of requirements instability on software defects. Study
indicates the pre release and post release changes, have impact
Due to the relative lack of literature on finding the measures
on defects generated. Authors also states that insufficient time
to reduce the effect of volatility, qualitative exploratory
spent on the design phase and inadequate communication with
research method is undertaken. Since case study approach is
the client could be some of the causes of requirements
appropriate for the undertaken research method, case study of
changes and consequently software defects. Authors in [4]
twenty customized software development projects developed
report on the “Industrial case study on Requirement Volatility
by six products cum service based hybrid type software
measures”. Goal of the study was to empirically validate set of
enterprises in India, is undertaken in this research. Projects
measures associated with volatility of use case models (UCM).
chosen for study have spread across major five potential
Analysis results have indicated that measures of size of UCMs
application domains of global software development. The
are good indicators of requirements volatility. No correlations
major domains considered are retail group, Finance, insurance
were found between subjective and objective volatility.
and banking group, manufacturing and automobile group,
Authors in [5] have taken qualitative and quantitative study on
Energy and utilities group and Hospital and Pharmacy coming
requirements change management and have proposed a model
under health care group. Projects chosen are of applications
for requirements change management process. Authors in [6]
software product type. Projects are chosen from different
have taken an empirical investigation of volatility awareness,
development methodologies such as web based, object
volatility management approaches, an industrial based study.
oriented, structured and component based. All the projects are
Authors have identified thirteen different approaches in
studied from its inception till implementation and also in the
managing the projects under volatility. Here volatility
annual Contract Maintenance (AMC). Table 2 gives the
management is handled in project management perspective.
summary of twenty projects studied.
Authors in [7] investigated on alternative to requirements
Inferences: From table 2 it is evident that twenty projects
change. Author proposes that if requirements are firm against
from major application domains namely Retail and Hospitality
the changes in user needs, risk due to requirements will not
sector four projects, banking and Finance sector four projects,
increase. Authors in [8] have worked on highlighting the
Energy and Utilities sector five projects, four projects from
effects of requirement volatility on software engineering
Manufacturing and Automobile sector and three projects from
process by simulation method. Authors in[9][10] proposes that
health care and pharmacy is studied from six companies. All
project managers can assess the complex impact of volatility
companies are having quality standards of CMM level 5
in development of projects. The paper discusses that cost,
common and ISO standards ISO14001 and ISO9002. Table 2
schedule, and quality impacts as a result of requirements
also infers that projects cost range were from 5 to 16 million
volatility. The simulation result demonstrates that complex
dollars and project contract type were belonging to fixed
setoff factor relationships and effects related to requirements
price project(FPP)or
Staff Augmentation(SA) or Covolatility in software projects.
Manage(CM)
or
Hybrid
categories.
Development
The summary of related work indicates the lack of
methodologies used are web based, component based,
research approach to reduce the volatility. The research
structured and object oriented.
undertaken by authors of this paper is very unique in two
ways. First the research is taken in five major application
762
TABLE 2: PROJECTS TAKEN FOR CASE STUDY
Company
Sector
A
One of the
large
software
company
B
India’ s
brand
leader
Retail&
Hospitali
ty
NP:04
C&D
India’s
globally
reputed
industrial
giants
E &F
Large
software
Companie
s
A&F
Projects
Scheduling lighting to turn on and off based on normal business hours and
multi-level day lighting control by server and cell phone.
Visual merchandizing and space planning in the shopping mall
Automation of customer relation database
Single RFID-EAS based tag for inventory visibility and loss prevention in retail
Risk estimation in corporate finance and valuation
Banking
and
Automatic analysis, measurement and identification of interest rate, currency
Finance
exchange and equity market in the share and stocks venture
Gold mortgage, loan, automation and database maintenance
NP:04
Smart grid based Margin and Collateral Management in corporate treasuries
Automation of petroleum terminal operations
Energy
and
Managing petrol storage and distribution- to petrol terminals- Nation wide
Utilities
Increase in Biomass energy system and its usage in rural economy through
advance technical instruments usage and metering
NP:05
Tax administration- Nation wide
Automation of Citizen’s identification
Manufac Modeling and simulation of petrol consumption in Cars
turing
Automotive mixture preparation and combustion control for spark-ignited
and
direct-injection gasoline engines
automob PLC based software control for hot molding power precise in galvanization plant.
ile
Software for Radio frequency based automatic action control for material
NP: 04
Transferring Robot
Health
Automatic blood management forecasting in minimally invasive and
Care and
conventional cardiothoracic surgery
pharmac
Automatic reactive symptoms gauging based on contrast administration in
y
patients with renal failure
NP:03
Augmented Reality Image Guidance Navigation for Beating Heart Mitral Valve
Contract
FPP
T&M
Hybrid
Hybrid
CM
Hybrid
SA
FPP
Hybrid
Hybrid
Hybrid
Hybrid
CM
FPP
FPP
Cost
in M$
5-10
FPP
CM
Object
oriented
WEB based
8-12
Structered,
web based
Component
based
9-13
Component
based
Objevt
oriented
Web based
1016
Component
based
Objevt
oriented
Web based
8-14
Component
based
Objevt
oriented
Structured
Hybrid
SA
Hybrid
DM
NP: Number of projects, DM: Development Methodology
Table 4: DEFECT ANALYSIS OF DEFECTS CONTRIBUTING VOLATALITY
Pre R.S VD :Pre Release Volatility Defects, Post R.S V.D: Post Release Volatility Defects, B; Blocker, M: Major, C: critical, T: trivial
763
V.
KEY FINDINGS AND ANALYSIS
Analysis of every case study is performed in three dimensions
based on the objectives of research stated in this paper. The
three dimensions are as follows. The first dimension the defect
analysis of volatility in Pre-release phase and post release
phase. Second dimension is to discover the contribution of
reasons of volatility in defect perspective. Apart from this
prioritization of reasons based on defect severity is carried
over. Third dimension of study is to find the key factors
supporting the reasons of volatility. Below is the summary of
key findings and analysis.
1. PRE-RELAESE AND POST RELEASE VOLATILITY DEFECTS
Requirements changes are distinguished into two types
namely pre-release requirement changes and post release
requirement changes Once the requirements gets specified as
functional specifications and SLA( Service Level Agreement)
and SOW ( Statement of Work) is signed off and requirements
gets freeze in the company. Once the requirements gets freeze,
project build starts from design. If changes are requested after
the requirement freeze and when the project is under anyone
of the development stages namely design, coding, testing or
implementation, such changes are called pre-release volatility.
In other words any requirement changes carried after SOW
within UAT (user acceptance test), such changes are called as
pre-release volatility. If any changes made in the project once
the project is deployed or in the annual contract period, such
changes are called Post release Volatility. Magnitude of prerelease and post release volatility is measurable through
defects percentage. All the projects under study were
examined to find the pre-release defects percentage and post
release defect percentage in all the three low, medium and
high complexity projects. To get the volatility defects, change
request management, review, auditing, inspection report,
customer feedback, test log sheets, project post mortem report
were considered. The summary of the defects found are
summarized in table 3.
Table3: VOLATILITY DEFECT CLASSIFICATION.
Domain
Complexity
Pre Release
VD% Range
Retail and
hospitality
High
Medium
Low
High
Medium
Low
High
Medium
Low
High
Medium
Low
High
Medium
Low
54-62
30-42
23-34
60-65
35-48
25-28
50-55
30-32
16-20
50-56
32-36
15-20
70-75
50-55
30-32
Banking and
Finance
Energy and
utilities
Manufacturing$
automobile
Health care and
pharmacy
VD: Volatility Defects
Post release
VD%
Range
10-12
8-9
3-5
12-14
10-12
8-10
13-16
10-12
8-9
11-13
8-10
5-6
10-18
8-11
2-3
Inferences: From table 3 it is evident that pre-release volatility
defects are in the higher range compared to post release
defects. As the complexity increases, defects percentage also
enhances. The maximum Pre release volatility defects are in
the percentages of 75%,, 65%, 34% and post release defect
are in the percentages of 18%, 13% and 10% for high,
medium and low complexity projects respectively.
Lesson learnt from table 3 is, if measures are taken to reduce
the pre-release volatility defects, post release defects can be
controlled. Post release defects are the major drivers of poor
quality, cost overrun and schedule slippage. Hence, post
release defects must to be reduced to improve project success
factor and to derive better business value. It is also observable
from the table 3 that percentages of volatility defects are
dependent on project complexity and application domain.
B.
DEFECTS CAUSED DUE TO REASONS CONTRIBUTING
VOLATILITY
Volatility defects are caused due to four major reasons and
given in table 1. If the patterns of defects caused by each of
the four reasons of volatility are found, then those causes can
be prioritized and later measures can be applied accordingly to
reduce the volatility. Hence, the defect percentage caused by
the entire four major causes of volatility, for all the projects
under study are found both in pre-release and post release
period. Defects percentage was found in all the three
complexities and under all the five application domains. For
the ease of analysis the defects percentage caused by R1-R4 is
converted to grading from 1 to 10, where grading 10 indicates
highest percentage of defects and 1 indicates lowest
percentage of defects. Severity of defects caused due to
reasonsR1to R4 are also found is summarized in table 4.
Inferences: Table 4 infers that major cause for volatility are
the reasons R1 and R2, accounting Poor initial understanding
of customer needs and system and Customer requested change
respectively.R1 and R2 are the major cause of higher
percentage of defects in the grade of 9. R1 and R2 are also
causing the defects of blocker type. Blocker type defects are
very fatal for the system performance and must to be
eliminated. R3 and R4 are contributing very less towards the
volatility.
Lesson learnt from table 4 is that, R1 and R2 are the
major players of requirements volatility in all the application
domains. Hence, if measures are designed to control R1 and
R2, requirement volatility can be effectively controlled. If R1
and R2 are controlled, impact of other reasons R3 and R4 will
automatically get reduced.
C. KEY FACTORS INFLUENCING THE REASONS WHICH ARE
CONTRIBUTING VOLATILITY
Following detailed analysis of reports, customer feedback,
discussions with project development personnel, it is found
that two major reasons are laying the foundation for reasons of
volatility. They are
764
1. Gap exists between customer need and customer statement
of need. This concept is given in figure 1.Customer realizes
this gap iteratively, only after viewing the product. Hence
customer keeps changing the requirements.
2. Elicitation technique does not have fixed frame work of
activities. Elicitation techniques are left to the choice of
elicitation team generally consisting of Subject matter expert
(SME), Program manager, Practice manager, Quality analyst,
and Business development manager (BDM).Due to the gap as
depicted in figure 1 and lack of defined frame work for project
requirement elicitation, poor requirements are elicited and
requirements change has become the inherent part of project
development
expressed in figure3, one primary need is divided into
secondary need and in turn they are divided into multiple
tertiary needs. The levels of details can continue till atomic
needs are obtained. These atomic needs if translated into
requirements, volatility can be controlled.
Figure 1.Gap between concept of need and statement of need by customer
Fig: 2 Affinity diagram to tree diagram translation
This paper contributes the results of research undertaken to
find a solution to reduce the gap. Solution is explained in the
next section.
VI. SOLUTION TO REQUIREMENTS VOLATILITY
From the analysis and key findings of case study, it is found
that, volatility is common in all the project application
domains. Among the four reasons R1 to R4, the major reasons
are R1 and R2. Gap between real need of customer to
statement of customer, and ad hoc elicitation techniques are
the key drivers of R1 and R2. Research contributes that if
affinity diagram followed by tree diagrams are used in both
requirements elicitation and requirements analysis process,
both the underplaying causes which are triggering R1 and R2
can be addressed and requirements volatility can be reduced to
a greater extent. Implementation of affinity and tree diagrams
is illustrated in figure 2.
Consider figure 2. The customer statements are in natural
language and it has to be translated into features and then into
functional points. Affinity diagram is a good tool to translate
the voice of customer to structured themes as shown in fig 2.
Under each theme, needs are noted. The major gap exists in
interpretation of each need, because need statements a can be
atomic also or composition of several needs also. The needs
are the statements of high level sometimes abstract level
customer requirements. It has to be decomposed into multiple
levels in a greater detail to define the real requirements of
customer. The major reason for volatility is that the
composite need is getting expressed as atomic need and once
the project gets started, requirements change requests influxes
and volatility surfaces the project build. To explore the depth
of every need into multiple levels tree diagrams are used. As
Consider an example a case study’ Scheduling lighting to turn
on and off based on normal business hours and multi-level day
lighting control by server and cell phone” project under Retail
hospitality domain given in table 1.When the research team
was undertaking case study , the project was suffering from
pre-release volatility up to 60% in the first build.. Once the
affinity diagram followed by tree diagram is used in the
second build, pre-release volatility was drastically reduced to
20%. Considerable reduction in post release volatility was
observed. Customer statements were categorized as themes by
affinity diagrams and one of such theme was “Electric power
must be saved” This theme was categorized into several needs.
One of the needs considered for analysis is “Scheduled light
control “Tree diagram is applied to this need. From the
diagram it is very clear how the high level requirement is
decomposed into multiple levels. Practically it involved
several levels to get atomic requirements.
Fig 3: Implementation of tree diagram
765
VII. DISCUSSIONS
The following contributions can be drawn from the study
• From the case study it is observed that though project
requirement elicitation techniques includes the activities
such as Affinity Diagram, Relations Diagram, Prioritization
Matrix, Root Cause Tree Diagram, Involvement Matrix,
PERT Chart, Risk Diagram (PDPC)) and Mind Map ,and
usage of one or more techniques is left to the choice of
elicitation team. No assurance that every project team
utilizes the affinity diagram tool. Moreover, elicitation
technique does not mention use of tree diagram after using
affinity diagram. Hence using only affinity diagram in
project elicitation does not result in the reduction of
Volatility. The research contribution of using
affinity
diagram followed by tree diagram is unique and effectively
reduces the gap. There by volatility also gets reduced.
• If volatility gets reduced, requirements stability index also
gets increased. If requirements stability increases by 1%,
project cost gets reduced by 10% and quality significantly
improves. Hence our approach of using affinity diagram
followed by tree diagram assures project success.
• Potential of the four reasons R1-R4which are causing the
volatility is well traceable by defect analysis. From defect
analysis it is observed that reasons R1 and R2 are the major
players of volatility, because they are contributing high
percentage of defects and defects are of blocker and critical
type.R3 and R4 are minor players because they are
contributing only very less percentage of defects and
severity is trivial and major.
• Volatility can be controlled by applying correction to R1
and R2.The reasons for selection of R1 and R2 alone is
twofold. The first reason is R1 and R2 are major contributes
of volatility defects. Second is R1 and R2 are interfaced
with human interaction. Hence, measures can be designed to
control, where as reasons R3 and R4 are not in project
teams control domain because, they are pertaining to market
conditions, business policies etc. If R1 and R2 are
controlled, the process of translating high level customer
needs to detailed requirements becomes strategic mandatory
process in the enterprises and this leads to reduction of
requirements volatility in the case requirements pertaining
to policies and market conditions. Hence by controlling R1
and R2, a considerable reduction in R3 and R4 can be
observed.
VIII. CONCLUSIONS
In the current scenario, enterprises are experiencing
business pressure to deliver projects with high quality, less
cost and with shorter delivery cycles. Enterprises are
witnessing the projects are not able to meet the expected
quality, cost and schedule due to requirement volatility.
Through various ways, robust efforts are applied by
enterprises to eliminate volatility, projects are continuing with
the issue of growth rate of volatility. But the efforts resulted in
two important contributions. The first is the principle
contributors of volatility were found and categorized into four
reasons. In this paper for the sake of clarity and ease of
understanding the four reasons are denoted as R1, R2, R3 and
R4.The second contribution is that the fact that due to
dynamic nature of SDLC, volatility cannot be eliminated but
can be controlled was made evident.
Hence, industrial multiple case study research was
undertaken to find measures to control volatility. As volatility
is correlated with defects, defect analysis of R1, R2, R3 and
R4, was carried over in pre release and post release phase. It is
found that the reasons R1 and R2 are associated with human
interactions. It is also observed that R1 and R2are contributing
blocker type, heavy percentage of defects. Reasons R3 and R4
are associated with market risks and policies, hence
controlling is out of scope of development team and it was
also found that R3 and R4 defect contribution percentage is
less and severity is majorly trivial type defects. Key factors
driving R1 and R2 are found through the research undertaken.
A solution of using affinity diagram followed by tree diagram
in both of the requirement elicitation and analysis phase is
introduced. A practical example by taking one of the retail
domain projects under case study is given. Practical example
assures that the usage affinity diagram followed by tree
diagram is an effective measure to reduce volatility and by
implementing it projects can meet its objectives and
enterprises can derive expected business value.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
1 Kenyer Domínguez, María Pérez, Anna C. Grimán, Maryoly Ortega,
Luis E. Mendoza,” software quality model based on software
development approaches” Published in 11 th International Conference
on Software Engineering and Applications (SEA '07), Pages 16 ,ACTA Press Anaheim, CA, USA, 2007
M. Takahashi and Y. Kamayachi. “An empirical study of a model for
program error prediction”. InProceedings of 8th International IEEE
Conference on Software Engineering, pages 330–336. IEEE, Aug.1985
Talha Javed, Manzil-e-Maqsood and Qaiser S. Durrani “A Study to
Investigate the Impact of Requirements Instabilityon Software Defects”
published in Journal ACM Software Engineering Notes, May 2004
Volume 29Number 4.
Loconsole, A.; Borstler, J.; , "An industrial case study on requirements
volatility measures," Software Engineering Conference, 2005. APSEC
'05. 12th Asia-Pacific , vol., no., pp. 8 pp., 15-17 Dec. 2005
Muhammad Akram Muhammad Akram, M. Hamid Fayaz, M. Imran
Shafi, M. Usman Shafique,, “Qualitative AndQuantitative Study For
Requirement Change Management
Model”,www.iqraisb.edu.pk/icbte/Proceeding_ICBTE_2010/.../104.pdf
Thakurta, R.; F. Ahlemann; “Understanding Requirements Volatility in
Software Projects—An Empirical Investigation of Volatility
Awareness,Manegment approaches and their applicability,43 Hawai
international conference,(HICSS) USA,2010
Alan M. Davis et al,”Requirements Change: What’sthe Alternative?”, l
IEEE International Computer Software and Applications
Conference(COMPSAC’08),2008, ISSN: 0730-3157, July 28 2008Aug. 1 2008, pg 635 – 638
Susan Ferreira et al, “Understanding the effects of requirements
volatility in software engineering by using analytical modeling and
software process simulation”, Journal of Systems and Software ,
Volume 82 Issue 10, October, 2009
T. R. Gopalakrishnan Nair, V. Suma, “Four Step Approach Model of
Inspection (FAMI) for Effective Defect Management in Software
Development”, Inter JRI-Science and Technology journal, Interline
publishers, Vol. 3, Issue 1, pp. 29-42, 2010
V. Suma, T.R. Gopalakrishnan Nair, “Better Defect Detection and
Prevention Through Improved Inspection and Testing Approach in
Small and Medium Scale Software Industry”, International Journal of
Productivity and Quality Management (IJPQM), InderScience
Publishers, USA, vol.6 , N1, pp. 71-90, 2010.
766