Investigating Dependencies in Software Requirementsfor Change Propagation Analysis

He Zhang∗,a, Juan Lic, Liming Zhub, Ross Jefferyb, Yan Liud, Qing Wangc, Mingshu Lic

aState Key Laboratory of Novel Software Technology, Software Institute, Nanjing University, Jiangsu, ChinabNICTA, University of New South Wales, Australia

cInstitute of Software, Chinese Academy of Sciences, ChinadPacific Northwest National Laboratory, USA

Abstract

Context: The dependencies between individual requirements have an important influence on software engineering activ-ities e.g., project planning, architecture design, and change impact analysis. Although dozens of requirement dependencytypes were suggested in the literature from different points of interest, there still lacks an evaluation of the applicabilityof these dependency types in requirements engineering.Objective: Understanding the effect of these requirement dependencies to software engineering activities is useful butnot trivial. In this study, we aimed to first investigate whether the existing dependency types are useful in practise, inparticular for change propagation analysis, and then suggest improvements for dependency classification and definition.Method: We conducted a case study that evaluated the usefulness and applicability of two well-known generic depen-dency models covering 25 dependency types. The case study was conducted in a real-world industry project with threeparticipants who offered different perspectives.Results: Our initial evaluation found that there exist a number of overlapping and/or ambiguous dependency typesamong the current models; five dependency types are particularly useful in change propagation analysis; and practition-ers with different backgrounds possess various viewpoints on change propagation. To improve the state-of-the-art, a newdependency model is proposed to tackle the problems identified from the case study and the related literature. The newmodel classifies dependencies into intrinsic and additional dependencies on the top level, and suggests nine dependencytypes with precise definitions as its initial set.Conclusions: Our case study provides insights into requirement dependencies and their effects on change propagationanalysis for both research and practise. The resulting new dependency model needs further evaluation and improvement.

Key words: requirement dependency, requirement traceability, requirement relationship, change propagation, impactanalysis, case study

1. Introduction

In developing software intensive systems, most individ-ual requirements relate to and affect each other in complexmanners [26]. Various and complex dependencies amongrequirements increase the difficulties in understanding therequirements and influence many software engineering ac-tivities such as architecture design [18], product releaseplanning [6] and change impact analysis [27]. Requirementdependencies are also important inputs for component se-lection [14] and web service composition [31].

In recent volatile environment, software systems mustevolve to adapt themselves to the rapid changes of stake-

∗Corresponding author. Tel: +86 25 83621369; Fax: +86 2583621370.

Email addresses: dr.hezhang@gmail.com (He Zhang),lijuan@itechs.iscas.ac.cn (Juan Li), liming.zhu@nicta.com.au(Liming Zhu), ross.jeffery@nicta.com.au (Ross Jeffery),yan.liu@pnl.gov (Yan Liu), wq@itechs.iscas.ac.cn (Qing Wang),mingshu@itechs.iscas.ac.cn (Mingshu Li)

holders’ needs, technologies and business environments [20].To control the risks brought by software evolution, it is vi-tal to analyse change propagation in order to determinewhat other parts of a software may be affected if a changeis made. Evolution of software systems is mostly stud-ied at the level of code and design with a focus on codereengineering/migration, architectural evolution and soft-ware refactoring [1, 34]. However, it is also necessaryto analyse change propagation earlier at the requirementslevel. This kind of change propagation analysis can pro-vide important change-related information from a busi-ness point of view. Requirements-level change propagationanalysis has also been regarded as one important area insoftware evolution research [13].

Requirements dependency is the relationship betweenrequirements and acts as the basis for change propagationanalysis. Dozens of dependency types have been proposedto reflect the complex relationships between requirementsat both structural and semantic levels. These dependency

Preprint submitted to Information and Software Technology June 17, 2013

types have different levels of abstraction and are used invarious aspects of project management. Pohl [24], Dahlst-edt and Persson [9] proposed the dependency types respec-tively based on literature survey in the areas of require-ments engineering. Karlsson et al. introduced the depen-dency types to prioritise requirements [17]. Carlshamreet al. presented a study of requirements dependencies inrelease planning [7].

However, there still lacks an evaluation of the applica-bility of these dependency types in a real-world project andtheir effectiveness in change propagation analysis. Thislimits the wide use of these dependency types for both de-pendency identification and change propagation analysis.In practise, researchers and practitioners usually choosefrom these dependency types based on their own experi-ences and ignore other dependencies that may propagatechanges. As a result, the accuracy of the change propaga-tion result may decrease. In one of our early studies [23] wechose three dependency types arbitrarily from Dahlstedt’sdependency model [9] to estimate the change impact at thecode level. This choice ignored other dependency types inDahlstedt’s dependency model that may have propagatedchanges and subsequently influenced our change propaga-tion estimation. In addition, some change impact analysisresearch merely focuses on change propagation in a spe-cific requirements model, such as use case map model [15],which severely constrains the range of dependency typesand causes change propagation analysis incomplete.

Given the very limited evaluation endeavour on re-quirements dependency, our research aims to empiricallyinvestigate the usefulness and applicability of existing de-pendency models (types), and further propose the im-provements that are based upon the evaluation results toeffectively facilitate dependency identification and changepropagation analysis. To achieve the goals, we conducteda case study with three participants to evaluate the use-fulness and applicability of existing dependency types ina real-world industry project. The evaluation objects are25 dependency types defined in Dahlstedt’s dependencymodel (D-model) [9] and Pohl’s dependency model (P -model) [24], which are the two most adopted dependencymodels in software requirements. This case study is aimedto answer four research questions:

RQ1 What dependency types are (not) used to identifyrelationships between requirements and why?

RQ2 What dependency types are (not) used in changepropagation analysis and why?

RQ3 How effective/ineffective are dependency types used?

RQ4 What are the main factors affecting the discovery ofdependencies?

Corresponding with these research questions, the eval-uation presented in this article has found that: 1) sevendependency types in the P -model and three dependency

types in the D-model were deemed applicable by the prac-titioners to describe relationships between requirements;2) five dependency types can indicate change propagationparticularly well, but their definitions need to be clarified;3) dependency types are helpful to find more dependen-cies, but some dependency types have ambiguous defini-tions or overlap with each other which increases the diffi-culty of use; 4) four main factors affecting the discovery ofdependencies. We also find participants with various back-grounds have different viewpoints on change propagation.Change impact analysis should involve a wide range ofstakeholders including project managers, requirements en-gineers, designers and developers. Moreover, we provide agroup of specific dependency types for change propagationanalysis based on our empirical findings.

Based upon our empirical evaluation of existing de-pendency models and the critique of current dependencytypes, we further propose a new dependency model by re-fining, integrating and extending the previous ones. Thenew dependency model classifies dependencies into intrin-sic dependencies and additional dependencies on the toplevel. The former reflects essential dependencies exist-ing among requirements, which are more likely to impactmany various software engineering activities; the latterrepresent relationships imported by certain software en-gineering tasks. The initial set of the new model includesnine generic dependency types.

This article is the extended version of the conferencepaper published in EASE 2012 [22]. Compared to the orig-inal version, the major extensions in this article are the de-tailed description of the case study design, execution, anddata analysis (Section 3 & 4), as well as the presentation ofa new dependency model (Section 5) based on the findingsfrom the case study. In addition, this article also includenumerous minor updates, corrections, and enhancementsto the conference paper.

The rest of this article is structured as follows. Sec-tion 2 introduces the background and the related workabout requirements traceability, requirement dependency,and change propagation analysis, and also briefly comparesthe existing dependency types whose problems motivatedour research. Section 3 describes the context and methodof the case study for evaluating the existing dependencytypes. The results and analysis of the case study are re-ported in Section 4 for answering the research questions interms of usefulness and applicability. Section 5 proposesa new dependency model and redefines a set of commondependency types based on our empirical findings. Section6 discusses the dependency types for change propagationanalysis in particular as well as the limitations of our studyat this stage. We conclude our research with suggestionsfor further work in Section 7.

2

2. Background and Motivations

2.1. Dependency in Requirements Engineering

In order to analyse the impact of a proposed softwarechange, it is vital to determine which parts of the soft-ware system may be affected by the change and ascertaintheir possible risks [5]. Change propagation means that achange can impact on not only source code, but also othersoftware artifacts, such as requirements, design and testcases [4]. Bohner proposed an impact analysis process [5]which examines the change requests to identify the Start-ing Impact Set (SIS) of software artifacts that could beaffected by the required change. Artifacts in the SIS arethen analyzed to identify other artifacts anticipated to beaffected. The newly identified artifacts are incorporatedinto SIS to form the Candidate Impact Set (CIS). On theother hand, an Actual Impact Set (AIS) consists of theset of artifacts actually modified after the change is im-plemented. The goal of the impact analysis process is toestimate a CIS that is as close as possible to the AIS. Alongthis topic, Fasolino and Visaggio [12] showed how CIS canbe determined step by step starting from the highest-leveldocumentation (e.g., requirements specification) affectedby the changes down to the source code to be changed.This top-down analysis approach can be efficiently sup-ported through traceability information [10].

Traceability research is gaining an increasing atten-tion in many areas such as requirements engineering andmodel driven architecture [29]. A traceability link is “anyrelationship that exists between artefacts involved in thesoftware engineering life cycle” [2]. It includes not onlythe forward and backward links between artefacts (e.g.,requirements and architecture, requirements and code),but also links between items within a software develop-ment artefact (e.g., requirements dependency, code depen-dency). Correct traceability is the basis for change propa-gation analysis [27] which is important for all aspects of asoftware development project.

Many existing research studies explore how to discovertraceability automatically. For example, information-retrievaltechnology is used to identify the relationships betweendocumentation and code [3], between requirements and re-quirements [16], and between requirements and test cases [11].However, solutions are far from mature and practitionersstill need to manually identify or confirm dependencies es-pecially for requirements due to the rich semantics in na-ture language based requirements.

To help people identify relationships between require-ments, many (inter-)dependency models (e.g., [24, 17, 7,9]) have been proposed to assist in identifying and clas-sifying requirements relationships into dependency typesbased on the structural and semantic properties of require-ments. Whereas, there has been no empirical evaluationof any these dependency types within real world softwareprojects in terms of the degree of usefulness and applica-bility.

Requirements dependencies also play an important rolein change propagation analysis. Hassine et al. applied de-pendency analysis at the use case map level (rather thanbetween requirements in natural languages) to identify thepotential impact of requirement changes on the overall sys-tem [15]. Khan et al. developed a concern-oriented de-pendency taxonomy to capture the relationships betweenrequirements-level concerns and their manifestation at thearchitectural level [19]. Yan et al. discussed the ripple-effect of requirements evolution based on requirements de-pendency [30]. Though all these studies evaluated thegeneric dependency type with some definitions loosely re-lated to the dependency types defined in the Pohl’s [24]and Dahlstedt’s [9] dependency models, there is no em-pirical evaluation of the effectiveness of dependency typesdefined in the both models in terms of change propagationanalysis.

2.2. Requirements Dependency Models

Many dependency types have been proposed in vari-ous dependency models over years and most of them havedifferent levels of abstraction and different criteria for cate-gorisation. This has increased the difficulty for evaluation.Among these models, there are two representative genericrequirement dependency models. These models suggest25 dependency types to categorise different characteristicsof relationships between requirements. The dependencymodel proposed by Pohl [24] in 1996 was based on a sur-vey of over thirty publications in the area of requirementsengineering (Figure 1). The other is a requirement (inter-)dependency model proposed by Dahlstedt and Persson [9]in 2005 (Figure 2). The dependency types evaluated inthis study come from these two well-known dependencymodels.

Dependency Types

condition

constraints

precondition

similarcontent

compares

contradicts

conflicts

documents

example_for

test_case_for

prurpose

background

comments

asbstraction

refines

generation

evolutionary

replaces

satisfies

based_on

formalizeselaborates

Figure 1: Pohl’s dependency model

The Pohl’s dependency model (P -model) includes 18dependency types based on a literature survey. The Dahlst-edt and Persson’s interdependency model (D-model) pro-poses 7 dependency types which combine some existingdefinitions (including [24, 17, 6, 7, 25, 27]) into an in-tegrated view. According to the definitions in the D-model, some dependency types in the P -model overlapwith and encompass the dependency types in the D-model

3

Dependency Types

Structured dependencies Constraint

dependencies

Cost/Value dependencies

Refined_to

Change_to Similar_to RequiresConfilicts

_withIncreases/Decreases

_cost_ofIncreases/Decreases

_value_of

Figure 2: Dahlstedt’s dependency model

(as shown in Table 1). The semantics of some dependencytypes in the D-model is more general than the P -model. Inour study, we do not differentiate these overlapping depen-dency types because we want to identify which dependencytypes are more applicable in practical use.

Table 1: Dependency overlapping between D-model and P -model

D-model P -modelExplains Replaces,Based_on,Formalises,Elaborates,Generalise,RefinesRequires PreconditionSimilar_to SimilarConflict_with Constraint,Conflicts

In addition, some existing literature tends to addressrequirement dependency (or relationship) based on specificproblems, e.g., requirement prioritisation [17], softwareproduct release planning [7], requirement recycling [28].Although the existing research proposes dependency typesfrom different perspectives, we observe there is still a largeoverlapping in all these dependency (or relationship) mod-els. Table 2 shows the dependency types we classified fromthe above mentioned models according to their uses forproject and product related activities, in which many sim-ilar dependency types appear in several models.

Table 2: Dependency types vs. software engineering activities

SE activity Related requirement dependency type

Architecturedesign

Constraint, Conflicts[24]; Conflict_with[9];verb categorisation related relationship typesto identify crosscutting dependency[8]

TestPrecondition[24]; Requires[9, 7]; Temporal,And[25, 7]; Task, Causality[25]

Change impactanalysis

Similar[24]; Similar_to[9]; Structure,Resource[25]; Similarity, Reference[23];Refines[24]; Refined_to, Generalise[9]

Requirementquality checking

Compares, Contradicts[25]; Example_for,Test_case_for, Purpose, Background,Comments[24]

Requirementevolution

Replaces, Satisfies, Based_on, Formalises,Elaborates, Changes_to[24]

Product releasing

Increase/Decrease_cost_of,Increase/Decrease_value_of[9]; Cannot_exist,Must_exist, Positive_cost, Negative_cost,Positive_value, Negative_value[17]; Requires,And, Temporal, Or, CValue, ICost[7]

2.3. Motivations

The above review, comparison and analysis imply anapparent need for a basic and common set of dependencytypes among requirements with clear definitions, and in-spire us to develop an integrated dependency model. Toachieve this, we first need to obtain an overall understand-ing about and in-depth analysis of requirement dependen-cies and their use in real world software projects. Never-theless, the current literature still lacks related empiricalresearch on this topic. The case study reported in thisarticle provides an initial evaluation of the usefulness andapplicability of the typical requirement dependency typesin a real-world industry project.

Based upon the existing dependency models in theliterature, in particular the initial evaluation of the P -model [24] and the D-model [9], we next propose a newdependency model to define the links between different re-lationships at the concept level. This model may help toreduce the ambiguity and overlapping between the existingmodels by providing clear and precise definitions.

3. Case Study: Method

The goal of the case study is to empirically evaluate theusefulness and applicability of all the dependency types de-fined in the two well-known dependency models (P -modeland D-model) in terms of both dependency identificationand change propagation analysis.

3.1. Context

The Lending Industry XML Initiative (LIXI) is an in-dependent non-profit organisation that has been estab-lished to remove data exchange barriers within the Aus-tralian lending industry. Through the work of LIXI, mem-ber organisations are able to provide services to their cus-tomers more efficiently and at lower cost. This is achievedby establishing an open XML standard for the format andexchange of lending-related data that replaces numerousincompatible and proprietary approaches. Members ofLIXI come from a broad range of companies and organ-isations across the lending industry in Australia. Theyinclude major banks, mortgage originators and brokers,mortgage insurers, property valuers, settlement agents,trustees and information technology providers. In 2008,NICTA developed a property valuation system (PVS v2.0)for a company in the LIXI organisation using the LIXIstandards [32, 33]. This system includes a ‘Pocket Val-uer’ sub-system (running on PDA) for capturing propertyvaluation data in field, a desktop sub-system for manag-ing information and a web-based business process systemfor managing the workflow. Now, the company is makingplans to move all the desktop sub-system to a web-basedsystem and implement some new functions. In this pa-per, this new system is called PVS v3.0. This study isconducted as part of the PVS v3.0 requirements develop-ment and system design project. Our study uses require-ments of PVS v2.0 for dependency identification as well

4

as change propagation analysis triggered by new require-ments in PVS v3.0.

3.2. Method

The case study was designed and conducted in orderto answer the four research questions (cf. Section 1).

3.2.1. Participants

Three practitioners (A, B, and C) from NICTA wereinvolved in this case study. Participant A is the projectmanager and the architect of the PVS systems who hadeight years of experiences with project management andsoftware architecture. Participant B is a new requirementsengineer/researcher who was not familiar with the systemvery much but had five years of practical experience of re-quirements analysis and management. Participant C is adeveloper with two years of software development experi-ences who knew the system well.

Due to the nature and the size of the project, three par-ticipants came with different backgrounds. Although suchdifference may impact the case study results, this selec-tion gave us the opportunity to explore whether differentbackgrounds affect the dependency identification and thechange propagation analysis.

3.2.2. Execution

The case study selected the response variables in cor-responding to the research questions: number of depen-dency types and dependencies identified (RQ1), number ofdependency types and dependencies used in change prop-agation analysis (RQ2), efficiency, correctness and distri-bution of dependency types and dependencies (RQ3 andRQ4).

Prior to the execution of the case study, the threeparticipants received an introduction about requirementstraceability, requirements (inter-)dependencies, and changepropagation analysis. When the case study started, eachparticipant was given the following materials: 1) PVS v2.0requirements document in natural language (144 require-ments in 19 modules), 2) PVS v3.0 requirements document(33 requirements in 9 modules), 3) matrix for dependencyidentification, and 4) original D-model and P -model doc-uments.

The participants first learned the requirement depen-dency types by reading the materials (D-model and P -model documents). With reference to the documents ofthe two dependency models, the participants read the re-quirements specification of PVS v2.0, as well as discovereddependencies in the requirements of the system and iden-tified their corresponding dependency types individually.The identified dependencies were recorded in a dependencymatrix. Next in change propagation analysis, they manu-ally analysed the requirements (PVS v2.0) estimated to bechanged because of the change requests from the new re-quirements of PVS v3.0, and recorded the identified changepropagation paths.

The study was conducted at NICTA Sydney Lab, andthe whole process was under supervision. The time spenton the case study (including self-learning, dependency iden-tification, and change propagation analysis) was not lim-ited. When they finished, they were asked to complete aquestionnaire to report problems and their experience, aswell as evaluate the two dependency models.

3.2.3. Data Collection and Analysis

The direct outputs of this case study that were col-lected in the end individually are: 1) all dependenciesidentified in PVS v2.0 requirements (in the form of de-pendency matrix), 2) change propagation paths and de-pendency types used in change impact analysis. Initialrationale and comments were collected from each of theparticipant as a part of their exercise.

The usefulness and applicability of the dependency typesin both identification and change propagation were anal-ysed cross the three participants. The follow-up question-naire was used to elicit in-depth reasons behind the differ-ences and the similarity. Common consensus was reachedon all issues.

The detailed data we intended to collect are shownin Table 3. These data are linked to research questionsand collected through a dependency matrix, lists of de-pendency and propagation path identified, and a question-naire. The collected data was in quantitative (mainly forRQ1 and RQ2) and qualitative (for RQ3 and RQ4) for-mats. The quantitative data from each participant wasanalysed individually, then compared across the three. Thequestionnaires completed by the participants in the end ofthe case study capture the data for answering RQ3 andRQ4. After the case study, the three participants wereinterviewed individually to collect rich qualitative infor-mation regarding RQ3 and RQ4, as well as any issues andconcerns raised in the questionnaires.

Table 3: Data collection for research questions

RQ Data to collect- Dependency types identified from a set of requirements

RQ1 - Dependency types missing from a set of requirements (andreasons)- Problems in dependency types- Time spent in learning and identifying dependency- Processes used for analysing change propagation

RQ2 - Dependency types used for change propagation- Dependency types not used in change propagation analysis(and reasons)- Time spent in analysis

RQ3/4 - Participants’ evaluations of dependency types

4. Case Study: Results and Analysis

This section presents our initial analysis of the casestudy results1 for answering the four research questions.

1The raw data of the case study is available at http://itechs.

iscas.ac.cn/en/products/downloadfiles/case_study_data.rar.

5

4.1. Dependency types in relationship identification (RQ1)

Dependency types used by three participants are listedin Table 4, which clearly shows the usage of all dependencytypes in this case study. We found the uses of some depen-dency types were not limited to their original definitionsand participants might possess their own understandingsabout some dependency types, in particular on the follow-ing dependency types.

Table 4: Dependency types found (not found) in PVS v2.0

Dependency type Found by Reason (if unused)Requires A B C

Precondition A B CSimilar_to A B CSimilar A B C

Constraint A B -Satisfies A - -

Contradicts - B -Comment - B - never foundBased_on - B - never foundRefines - - C never found

Refined_to - - C never foundCompares - - - hard to understandConflicts A - C hard to understand

Conflicts_with - - - never foundChange_to - - - never found

Example_for - - - never foundTest_case_for - - - never found

Purpose - - - never foundBackground - - - never found

Increase/Decrease_cost_of - - - never foundIncrease/Decrease_value_of - - - never found

Replaces - - - never foundElaborates - - - never foundFormalises - - - never foundGeneration - - - never found

� Similar_to is more precise than Similar. Similarmeans “two objects are similar”, while Similar_to

means “one stated requirement is similar to or over-lapping with one or more other requirements”. Al-though in the D-model Similar_to is regarded thesame as Similar, in the case study, three partici-pants preferred Similar_to because its definition isclearer and easier to use. Similar_to exists betweenrequirements which describe different operations onthe same objects, such as ‘add valuation informa-tion’, ‘delete valuation information’ and ‘modify val-uation information’.

� Precondition is identical with Requires. They areoften used to describe the process control relation-ships. In the P -model and the D-model, Requiresand Precondition are used to describe the hierar-chical relationship between two requirements. In thiscase, for example, ‘the ability to create valuation re-quests’ is the precondition of ‘the ability to deletevaluation requests’. Here, Precondition is the mostidentified dependency in individual modules and be-tween modules.

� Refines is the alternative to Refined_to. They areused to describe the relationships between require-

ments at the same level. Refines means “a require-ments is defined in more detail by another require-ment”, and Refined_to means “a high-level require-ment is refined by a number of more specific require-ments”. In the D-model and the P -model, these twodependency types describe the hierarchical structureof requirements. For example, in one function mod-ule in this case, ‘set user permissions’ refines ‘onlypermit users to view/edit/delete data that they havethe correct permissions for ’.

� Constraint can be used to describe the relationshipsbetween non-functional requirements and functionalrequirements. Constraint links are used to “relatea constraint to a particular object”. But what is ‘aconstraint ’ is not clearly explained in the P -model.

� Satisfies describes a specific kind of constraint re-lationship between requirements. Satisfies expressesthat “if the target object is reached by the final sys-tem, the source object is also satisfied”. For example,in the PDA system, one requirement ‘sign off screen(with signature capture)’ in the desktop system sat-isfies another requirement ‘the valuer must submittheir valuation for authorisation once they are com-plete’.

Table 4 also indicates some dependency types neverused (found) in the case study. According to the partici-pants’ feedback, the reasons why these dependency typeswere not used might be:

1. Some dependency types are hard to understand.

� Compares describes “the result of a compari-son and the objects which have been compared”.This definition does not state the use of this de-pendency type and is hard to understand.

� Conflicts indicates that “fulfilling one require-ment has negative influence on the other one”.But the definition does not state clearly what‘negative influence’ is. Two participants foundthis dependency, but their understandings weredifferent. One regarded ‘negative influence’ asthe requirements could not be implemented andthe other understood it as the requirement wouldconflict with other requirements. So its defini-tion needs to be clarified.

2. Some dependency types could not be found in re-quirements.

� Example_for, Test_case_for, Background andPurpose. There are no related contents in therequirements document.

� Increase/Decrease_value_of andIncrease/Decrease_cost_of. Given their orig-inal definitions, these two dependency types arehard to judge in requirements document.

6

� Evolutionary links in the P -model, e.g., Replaces,Elaborates and Based_on. These dependencytypes record the change history of requirements.There are no such dependencies in PVS v2.0 re-quirements (discussed in the next subsection).

4.2. Dependency types in change propagation analysis (RQ2)

There are two steps in change propagation analysis pro-cess used by three participants: direct change propagationand indirect change propagation. The first step is to iden-tify PVS v2.0 requirements directly impacted by PVS v3.0requirements. The next step is to identify requirementsimpacted indirectly in PVS v2.0.

1. Replaces and Elaborates were used in the directchange propagation analysis.

Two participants used these two types to judge howPVS v2.0 functional requirements were impacted byPVS v3.0 requirements. Replaces and Elaborates

belong to evolutionary links in the P -model whichdescribe how requirements evolve into their new ver-sions. In this case, Replace results in a wider impactscope than Elaborate because if the new require-ment replaces the old one, the old function may bediscarded.

� Replaces are used to express a particular re-quirement (source object) has been replaced bythe target object. In this case, some desktopfunctions in PVS v2.0 need to be migrated toweb system. This change can be identified asnew (web) requirements replace old (desktop)requirements.

� Elaborates typically means the new require-ment improves another previous requirement.In this case study, some functions are to beupgraded between versions of the system. Forexample, the valuation request can only be cre-ated manually in PVS v2.0, but in PVS v3.0 thevaluation request can be created automaticallyfrom PDF file. This kind of change scenariomeans the old functions have to be refined.

2. Precondition, Similar_to, Constraint were usedin the indirect change propagation analysis.

Table 5 shows the dependency types used by threeparticipants. There are 19 modules in the PVS v2.0requirements document noted as M1–M19 and 9 mod-ules in the PVS v3.0 noted as M′1–M′9. Module meansa coherent set of functional or nonfunctional require-ments. The analysis results of three participantsare different and there exists overlapping betweenthem. People’s viewpoints and experiences may af-fect the change impact analysis. participant A foundmost requirements impacted because he is familiar

with the business process and system implementa-tion. When A was analysing the change propaga-tion, he considered if the change would happen indesign and code factually. B found the requirementsimpacted from business point of view, so she foundsome requirements whose implementations are notnecessarily to be changed but her findings are helpfulto improve the design. C analysed the change prop-agation from the development point of view. The re-quirements impacted found by C are to be changedin code.

We summarise the change propagation examples ofthe above three dependency types.

� Similar_to exists between many functional re-quirements dealing with the same data informa-tion. If the data information is to be changed,all the related similar functions may be changedtoo. For example, as shown in Figure 3, there isa new requirement that is ‘the system can createa new valuation request from PDF requests froman email account or a file system’ in PVS v3.0.This requirement impacts all the functions deal-ing with the request information in PVS v2.0such as ‘user can view valuation requests man-ually ’ and ‘user can cancel valuation requests’because the user interfaces of these functionsmay need to add the ‘PDF’ link for users tocheck the PDF document.

ViewValuation request

simialr

Search Valuation request

Cancle Valuation request

simialr

Create request from PDF

…………

impact

Change propagate Change propagate

impact

Figure 3: ‘Similar to’ in change propagation

� Constraint exists between non-functional re-quirements and functional requirements. Forexample, Security module includes requirements‘system login’ and ‘only permit users to view/edit/deletedata that they have the correct permission for ’.Security module constrains all the functions whichshould be accessed by users with privileges. Ifsome functions’ privilege constraints are changed,then the security module may need to be modi-fied. For instance (Figure 4), in PVS v2.0, onlythe manager can see and authorise valuation,but in PVS v3.0 the administrator is also per-mitted to see and authorise valuation. So ‘val-uation authorisation by manager ’ and the Se-

7

Table 5: Change propagation analysis

Requirements in PVS v3.0 Participant Requirements module impacted directly Requirements module impacted indirectly

M′1:Auto-processing request fromPDF document (new function)

A M∗6 :Precondition/Require M1:Similar/Similar_toB M∗6 :Precondition/Require M1,M18:Similar/Similar_to,

Precondition/RequireC M∗6 :Precondition/Require

M′2:The Request-related desktopfeatures shall be migrated to theWeb (upgrade)

A M6,M7,M8,M16 M3:Similar/Similar_toB M6

C M8

M′3:Automatically allocate avaluation task to a valuer accordinga set of rules (new function)

A M∗12,M∗7 :Constraint, Precondition/Require

B M6 M17: Precondition

C M7

M′4:The Booking-related desktopfeatures shall be migrated to theWeb (upgrade)

A M7

B M7

C M7

M′5:Valuation report qualityassurance-WEB (new function)

A M17,M6,M8,M11:Similar/Similar_to,Precondition/Require

B M∗8 :Precondition; M∗11:Similar/Similar_to

C M∗11:Precondition/Require

M′6:Valuation report qualityassurance-PDA (new function)

A M18,M17,M11 M19:Satisfies; M6,M7:Similar/Similar_to;

M∗8 :Satisfies, Precondition/Require

B M18,M17 M∗17:Precondition

C M17

M′7:Valuation process qualityassurance (new function)

A M6,M11,M14,M12 M1-M18:Similar/Similar_to,ConstraintB M6,M11

C M6,M11,M8

M′8:The new features shall beintegrated with V1 features through aconfigurable business process engine forease of change in the future (upgrade)

A All the requirementsB All the requirementsC All the requirements

M′9:Upgrade the remaining of thedesktop features to web application(upgrade)

A All the desktop system requirementsB All the desktop system requirementsC All the desktop system requirements

Module with ‘*’ denotes change propagation within the module; Module underlined indicates changes found by one or more participants.The dependency types used in change propagation analysis are listed after modules.

curity module are both impacted by ‘valuationauthorisation by administrator ’.

Security

Valuation Management

Valuation request

management

Valuation authorization

ConstraintConstraint Constraint

SQA Valuation authorization

Impact

Change propagate

Figure 4: ‘Constraint’ in change propagation

� Precondition. In this case, Precondition re-flects the business rule or business process be-tween two requirements. For example (Figure 5),in PVS v2.0, after the valuer submits valuationthrough PDA system, the manager must checkthe valuation quality on the web system man-ually. In PVS v3.0, the quality of valuationshould be automatically checked on the PDAsystem before submission. This change will af-fect the function ‘valuation submission’ on the

PDA system and the quality checking functionon the web system.

PDA submits valuation

Quality checking on

web

Impact

Precondition Change propagation

quality checking on

PDA

Figure 5: ‘Precondition’ in change propagation

In addition, there are some dependency types propa-gating changes only at the requirements level. Thesedependencies are Purpose, Generalise in the P -model. Some dependency types do not propagatechanges. They are Example_for, Test_Case_for,Background, Comments in the P -model andIncrease/Decrease_value_of,Increase/Decrease_cost_of in the D-model.

4.3. Effectiveness of dependency types (RQ3)

Dependency types provide the clue to analyse the changeimpact. For the case study in particular, their effectivenessincludes:

8

1. Dependency types are helpful to find more depen-dencies. Participant A reflected that he never knewthere are so many dependency types in requirements.When he was analysing the change impact before, heusually identified what requirements were impacteddirectly only, but ignored those requirements maybe impacted indirectly. He thought Constraint andSimilar_to were very useful dependency types butnew to him.

2. Dependency types support quality analysis of require-ments. Participant B reflected that dependencieshelped her learn the structure of requirements andrelationships in requirements. Through analysingthe dependency types in requirements, she foundsome quality problems in the requirements document.

3. Dependency types are helpful to identify the key de-pendent functions in the system. Participant C re-flected that dependency types helped her in identi-fying dependent functions. The changes happeningin these modules may impact more modules thanothers. This finding is useful to design and code im-provement.

However, we also found ineffectiveness of dependencytypes in this case study, because some dependency typeshave ambiguous definitions or have very general semantics(cf. Section 4.1). A few dependency types overlap witheach other and are not clearly differentiated. These prob-lems result in the difficulty in dependency identificationand change propagation analysis.

4.4. Factors affecting dependency discovery (RQ4)

The number of dependencies found in PVS v2.0 re-quirements by three participants are listed in Table 6.There exist significant differences among the dependenciesfound by three participants.

Table 6: Dependencies identified per participant

hhhhhhhhhhhhhhDependencies found

ParticipantA B C

Exclusive dependencies found individually 89 69 81Dependencies also found by others 23 11 4Wrong dependencies identified individually 0 2 23Total 112 82 108

We further interviewed participants to explore the pos-sible reasons for the difference and found four main factorsaffecting the discovery of dependencies.

(1) Participant’s experience and understanding about therequirements

Individual experiences and understanding about the re-quirements play an important role in dependency identi-fication. Participant A found most dependencies since he

was the project manager and most familiar with the re-quirements. C also found more than 100 dependencies,but 23 of which are wrong dependencies due to her misun-derstanding of some requirements (the wrong dependen-cies were revealed and confirmed later in interviews andconsensus building).

(2) Analysis process and time spent

The task assigned to the three participants was to anal-yse change propagation in PVS v2.0 requirements usingthe 25 dependency types from the P -model and the D-model. They all first learned the requirements dependencytypes, but the ways they completed the task are slightlydifferent.

Participant A started with v3.0 requirements and iden-tified their initial impacts on v2.0 requirements. He thenidentified dependencies between the initially impacted re-quirements and the rest of v2.0 requirements. B roughlyanalysed the dependencies in v2.0 requirements first, thenanalysed the change propagation and improved the depen-dencies. While C first identified the dependencies in v2.0requirements, and then analysed the change propagation.

The time spent by three participants is shown in Ta-ble 7. The efficiencies (dependency number by time spent)of A and B are higher than C because the change-drivendependency identification process helped them find depen-dencies and requirements impacted faster. C found morethan 100 dependencies but she spent the most time.

Table 7: Time spent per participant

hhhhhhhhhhTime (hr)Participant

A B C

Dependency learning 1.5 0.5 1.5Dependency identification 0.5 1 2Change propagation analysis 1.5 1.5 1Total (hr) 3.5 3 4.5

(3) Participant’s perspective

As shown in Table 6, there are differences among thedependencies found by the three participants. We furtheranalysed the dependency types discovered by the threeparticipants (Figure 6). We found a person’s viewpoint isone main factor affecting the dependencies identified.

Participant A identified the dependencies from bothbusiness and implementation perspectives. Accordingly,he found many dependencies within the types of Similar/Similar_to, Constraint, and Precondition/Requires.Note that Similar/Similar_to exists between similar userinterfaces, Constraint often describes the relationshipsbetween functional and nonfunctional requirements, whilePrecondition/Requires depicts the business process.

Participant B paid more attention to the text represen-tation of the requirements and found many structure andcontent dependencies such as Comments, Similar/Similar_to,and Contradicts. Different from Similar/Similar_to

9

0%

20%

40%

60%

80%

100%

A B CDep

ende

ncy

type

rat

io

ParticipantSimilar/Similar_to Precondition/RequireRefines ConstraintComments Based_onContradicts Satisfies

Figure 6: Dependency types per participant

found by A, Similar/Similar_to dependency types foundby B are mainly similar textual content between multiplerequirement descriptions.

Participant C discovered dependencies from a devel-oper’s point of view. C cared more about how to imple-ment the requirements and accordingly she found manyPrecondition/Requires dependencies. C thought thatthis kind of relationships often reflects the invocations be-tween code modules.

(4) Representation of requirements documentation

Table 8 shows the dependency distribution within eachindividual module and between modules. We comparedthe dependencies found by A, B and C (Figure 7). Afound the most dependencies among modules which re-flect the business process information across the whole sys-tem. This business knowledge is not explicitly expressed inthe requirements which are often isolated items and doc-umented in natural languages. B and C only found someprocess-oriented cross-module business knowledge in thedocument. It is observed in this case study that naturallanguage based requirements work not very well in cap-turing business processes, which may limit the identifica-tion of dependencies. Multi-representation of requirements(e.g., text and process diagram) can help people effectivelyfind dependencies.

5. A New Requirement Dependency Model

In terms of our evaluation experience from the casestudy, the biggest difficulty in discovering dependencies inrequirements was some ambiguous and overlapping defi-nitions of dependency types. Thereafter, based upon theexisting dependency models from the literature (especiallythe two generic models discussed above [24, 9]) as wellas our empirical evaluation, we propose a new dependencymodel to depict the links between different relationships atthe concept level. The new model clearly defines commondependency types to help practitioners identify dependen-cies among requirements.

0

5

10

15

20

25

30

35

40

A B C

Num

ber

of d

epen

denc

y

Participant

Dependency between modules Dependency in individual module

Figure 7: Dependency number per participant

5.1. Requirement Dependency Classification

With reference to the categorisations of the two evalu-ated models (P -model and D-model) and the participants’difference perspectives reflected in the case study, the newconceptual model proposed in this section classifies de-pendencies into six categories, i.e. business, implemen-tation, structure, evolution, value, and cost (as shown inFigure 8). On the top level of this model, these depen-dency categories are further classified into intrinsic de-pendencies and additional dependencies. Intrinsic depen-dencies depict essential interrelated state of requirementsand reflect semantic and structural information of require-ments. This kind of dependency is often related to var-ious software engineering activities and also can be usedto analyse change impact [24]. For example, two require-ments with Precondition dependency [24] may need tobe implemented in one product. Additional dependenciesare the relationships existing for specific software engi-neering activities. For instance, to plan product release,value-related relationships (e.g., Increase_value_of [9])are defined to discover those requirements necessary fora software product. Product release planning may bringadditional dependencies to requirements.

Compared to additional dependencies, intrinsic depen-dencies are more important for software engineers in dis-covering dependencies because they may impact many soft-ware engineering activities such as change impact analysisand project planning. They are also generally helpful toidentify additional dependencies. For example, one addi-tional dependency Increases_cost_of [9] can be deter-mined by one intrinsic dependency Precondition [24].

To identify intrinsic dependencies, we need to anal-yse the source of these dependencies. Intrinsic dependen-cies usually come from business knowledge and require-ments characteristics. Business knowledge includes busi-ness processes and rules which are vital input of softwarerequirements elicitation and analysis. Our previous re-search [21] found that workflow patterns in a business

10

Table 8: Dependencies identified within/between modules

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M17 M18 M19

M1 P(11)

S(12)

P(3)

S(1)

P(1) S(1) P(3)

M2 P(3) P(2) P(2)

C(1)

M3 P(4)

S(7)

P(3) C(1) P(3)

M4 P(1) P(8)

Ct(1)

P(1) P(1) P(5) C(1) P(5)

M5 P(6) C(1) P(2)

M6 P(1)

S(7)

P(1) P(2) C(1) P(1)

M7 P(1) S(1) P(2) C(1)

M8 P(2) P(1)

M9 C(1)

M10 P(2) C(1)

M11 P(1) S(3)

R(13)

C(1) P(1)

M12 C(2) C(2) C(2) P(1)

C(2)

C(1)

R(1)

C(10) C(2)

M13 S(1) C(1)

M14 C(1) B(2)

M15 P(1) S(10)

P(5)

M16 S(3) C(1) P(2)

M17 P(1)

S(36)

P(2)

S(12)

P(1) S(36) St(1) Cm(21) C(1) S(19)

P(5)

P(1) Cm(1)

M18 P(4)

Cm(1)

M19

Dependency types: P:Precondition, S:Similar_to; Ct:Contradicts, C:Constraint, R:Refines, B:Based_on, St:Satisfies, Cm:Comment.Note: the number in parentheses indicates the number of dependencies identified within/between modules.

process model can efficiently help practitioners discover re-quirement dependencies. These dependencies include tem-poral and sequential relationships reflected in a businessprocess, such as Requires [7, 9], And, Temporal [7, 25],Task, Causality [25]. These kinds of dependency are‘business’-related relationships as shown in Figure 8.

Another important source of dependency is characteris-tics of requirements. These characteristics come from spec-ification structure-related, implementation-related, and evo-lution-related requirements (as shown in Figure 8).

Different specification structures may produce variousdependencies among requirements. One general depen-dency is Refined_to [9] which means one requirement isexplained by other more detailed requirement(s). Thistype of dependency often indicates a hierarchical struc-ture of requirements. For another instance, if one re-quirement document template includes background relatedand example related contents, this creates Example_for

and Background [24] dependencies among requirements.This category of dependency are specified such as Refines[24], Refined_to, Generalise [9] in different dependencymodels.

Requirement implementation-related dependencies in-

RequirementDependency

Business

Implementation Structure

Is

IsIs

Intrinsic dependency

Is

Additional dependency

Is

Value CostEvolution

Is Is Is

Impact

Impact

Figure 8: Requirement dependency classification

clude relationships among functional requirements, non-functional requirements and user interface requirements.For example, some requirements may be the precondi-tion of other requirements [24], and implementation ofsome requirements may constrain other requirements’ im-plementation [9]. This category typically includes require-ment dependencies like Constraint, Conflicts [24], and

11

Conflicts_with [9].Requirement evolution creates relationships between

different versions of one requirement. Evolution-relateddependency represents requirement change history. Thistype of relationship includes Replaces, Satisfies, Based_on,Elaborates, Formalises, and Changes_to [24].

Additional dependencies include value and cost cate-gories. Value indicates user’s satisfaction. Value-relateddependency types are Increase/Decrease_value_of [9],Positive_value, Negative_value [17], and CValue [7].The Cost-related dependency types includeIncrease/Decrease_cost_of [9], Positive_cost,Negative_cost [17], and ICost [7]. These two types ofdependency are useful for some specific activities, such asproject planning and product release planning.

5.2. Requirement Dependency Types

The case study reflects that dependency discovery is asubjective process. It is impacted by people’s understand-ing of requirements and relationships to a large extent. Toalleviate this subjectivity, the definitions of dependencytypes need to be very specific, explicit and clear. Themore specific the dependency is, the easier for participantsto discover this relationship.

The conceptual model (shown in Figure 8) depicts anoverall categorisation of requirement dependencies derivedfrom the above discussion on dependency classification.This subsection completes the dependency model with spe-cific but refined dependency types based on the problemsidentified from Pohl’s model [24] and Dahlstedt’s model [9]in the case study and our previous work [21] as well as theanalysis of existing requirement (inter-)dependency typesin the literature. We selectively propose and refine ninedependency types (as shown in Table 9) under the cate-gories of the conceptual model at the initial stage. Thesenine dependency types are defined by 1) removing de-pendency types not common or seldom found in practise(such as Text_case_for and Purpose [24]), 2) clarifyingthe dependency types with confusing or ambiguous def-initions (e.g., Conflicts [24] and Conflicts_with [9]),3) combining and refining some overlapping or alternativedependency types in different models (e.g., Similar [24]and Similar_to [9]), and 4) introducing new dependencytypes (e.g., Be_exception_of).

In addition, to minimise the possible ambiguity, foreach dependency type we specify its relationship directionand suggest software engineering activities where the de-pendency can be used. Such information is not providedin the existing (inter-)dependency models. Table 9 clearlydisplays the categorisation of the nine dependency types,their sources in existing dependency models, and the dif-ferences from other models, in particular the P -model andD-model. The rest of this section describes the defini-tions with examples of these refined dependency types:1) Constrain, 2) Precede, 3) Be_similar_to, 4) Refine,5) Be_exception_of, 6) Conflict, 7) Evolve_into,

8) Increase/Decrease_cost_of, and9) Increase/Decrease_value_of .

(1) Constrain

Definition. One requirement is a constraint of another re-quirement. This kind of dependency can represent cross-cutting relationship among requirements.

Example. ‘system should respond to users in 3 seconds’constrains ‘book search function’ (user searches books us-ing book title or ID).

Category. Business, Implementation.

Direction. if A constrains B, the direction is A → B.

Typical use. architecture design, test case design, require-ment management, and change propagation analysis.

(2) Precede

Definition. If function A precedes function B, A is a pre-condition of B.

Example. Given Requirement A: ‘a client proposes thevaluation request and system checks the quality of request ’and Requirement B: ‘after the quality of request is checked,system allocates the valuation task to a valuer ’, then Aprecedes B.

Category. Business.

Direction. If A is a precondition of B, the direction isA → B.

Typical use. test case design, change propagation analysis.

(3) Be similar to

Definition 1. If two requirements share similar data infor-mation, these two requirements are similar to each other.

Example. Requirement ‘system administrator adds a newbook record ’ is similar to ‘system administrator modifies anold book record ’. Book record in these two requirements isidentical.

Definition 2. If two requirements complete similar tasks,these two requirements are similar to each other.

Example. After a client proposes a property valuation re-quest, one valuer can choose from several options to eval-uate the property, such as ‘desktop valuation’, ‘curbsidevaluation’ or ‘full valuation’. Then these options (require-ments) are similar to each other.

Category. Implementation.

Direction. If A is similar to B, the direction is A ↔ B.

Typical use. architecture design, change propagation anal-ysis.

12

Table 9: Comparison and relations of dependency types between the new model and the previous models

Relation Dependency type in new model Corresponding type in previous models Difference from previous modelsRefinement Constrain Constrain [24] Extension

Precede Precondition [24], Requires [9] ExtensionBe_similar_to Similar [24], Similar_to [9] ExtensionConflict Conflicts [24], Conflicts_with [9] Clearer definition with equivalent meaningIncrease/Decrease_value_of Increase/Decrease_value_of [9] Clearer definition with equivalent meaningIncrease/Decrease_cost_of Increase/Decrease_cost_of [9] Clearer definition with equivalent meaning

Addition Be_exception_of New dependency typeEvolve_into Combine, Replaces, Satisfies, Based_on,

Formalises, Elaborates, Changes_toHeritage Refine Refines [24], Refines_to [9] Definition from previous models

(4) Refine

Definition. One requirement is refined by more specificrequirements.

Example. ‘A valuer submit a valuation report ’ is refined as‘a valuer submits a report through web system’, ‘a valuersubmits a report through PDA’.

Category. Structure.

Direction. If A is refined by B, the direction is B → A.

(5) Be exception of

Definition. One requirement describes the exceptional eventof another requirement.

Example. “A user inputs a null username and system re-minds him to input his correct username” is an exceptionalevent of “a user inputs his username and password andsystem checks validity of his information”.

Category. Business, Implementation.

Direction. If A is an exceptional event to B, the directionis A → B.

Typical use. test case design.

(6) Conflict

Definition. Implementation of one requirement negativelyimpacts another requirement.

Example. Increasing security might negatively impact sys-tem performance.

Category. Implementation.

Direction. If A conflicts with B, the direction is A → B.

Typical use. architecture design.

(7) Evolve into

Definition. If one requirement B is a new version of an-other requirement A, then A evolves into B. This type ofdependency is used to trace and compare different versionsof requirement documents.

Example. “Clients use a desktop PC to upload reports”evolves into “clients use PDA to upload reports”.

Category. Evolution.

Direction. If A evolves into B, the direction is A → B.

Typical use. requirements tracing.

(8) Increase/Decrease cost of

Definition. The implementation of one requirement causesthe increase/decrease of the implementation cost of an-other requirement.

Example. If one requirement states that ‘no response timeshould be longer than 5 seconds’, it is most likely to in-crease the cost of implementing many other requirements.

Category. Cost.

Direction. If A increases/decreases cost of B, the directionis A → B.

Typical use. product releasing planning, project planning.

(9) Increase/Decrease value of

Definition. The implementation of one requirement causesthe increase/decrease of the value to the customer of an-other requirement. Note that ‘value’ here mainly reflectscustomer’s satisfaction.

Example. Users can listen to MP3 when they are browsingphotos in a mobile phone. In this case, ‘users can listen tomp3 ’ increases customer’s satisfaction of ‘users can browsephotos’.

Category. Value.

Direction. If A increases/decreases value of B, the direc-tion is A → B.

Typical use. product releasing planning, project planning.

13

6. Discussion

6.1. Dependency Types for Change Propagation

Based upon the empirical findings from the case study,we propose a group of dependency types which are partic-ularly useful in change propagation analysis. We redefinethe dependency types’ definitions and provide the specificchange patterns. These dependency types can help soft-ware engineers identify changes and they also can be inte-grated with the requirements modelling languages to aidchange analysis in requirements models. We will validatethese dependency types in our future study. We classifiedthe dependency types into two categories:

(1) Dependency types for direct propagation

In the new dependency model, Evolve_into is a genericdependency type for direct change propagation. This de-pendency type can be further specified as several depen-dency types (cf. Table 9) specific to more concrete scenar-ios, which describe the impact extent of the new require-ments on the old requirements.

� Elaborate: The new requirements are the refine-ment of the old requirements and might be the sub-contents of the old requirements. This kind of changemay impact the old requirements’ implementationand result in the modification in requirements docu-ments.

� Replace: The new requirements replace the old re-quirements. The old requirements may be discarded.This kind of change may cause the code redevel-opment and the modification in requirements doc-uments.

� Combine: The new requirement and the old require-ment are combined into one integral requirement.This kind of change may cause the modification in re-quirements document and the old requirement’s coderefactoring.

(2) Dependency types for indirect propagation

Some dependency types in the existing dependencymodels (e.g., P -model and D-model) reflect the struc-ture and the content relationships in requirements suchas Test_case_for and Example_for. These types onlypropagate changes at the requirements level and are notincluded in our dependency type sets. Here we only rede-fine the dependency types that may cause changes at theimplementation level and provide the change patterns.

� Be_similar_to: The data information of one re-quirement overlaps with another requirement.

Change Pattern: Given A is similar to B, when thedata information of A is changed, B’s implementa-tion may be changed as well. For example, when thedata information is changed, user interfaces of func-tions dealing with all this data information are verylikely to be impacted.

� Precede (Precondition): Only after one function iscompleted or one condition is satisfied, another func-tion can be performed. Usually precondition reflectsthe business rule or the logical/sequential relation-ship between tasks.

Change Pattern: Given A precedes B, when A ischanged, B’s implementation is likely to be changed.When the business rule or business process is changed,the related requirements’ implementation may alsobe changed.

� Constrain: The relationships exist between the non-functional requirements and the functional require-ments or between the functional requirements. Thecrosscutting relationship in aspect-oriented require-ments engineering is one kind of this dependency.

Change Pattern: Given A constrains B, A’s changemay lead to the change of B’s implementation; andwhen B is changed, A’s implementation may be changedtoo. To avoid change propagation in a large scope,in many cases, A needs to be implemented in an in-dividual module instead of being embedded in manymodules.

6.2. Limitations of the Case Study

The case study reported in this article is the initialempirical evaluation of the applicability of requirementsdependencies in the community, which may have two ma-jor limitations at this stage:

(1) Small sample size

The group size participating in the case study is rela-tively small. Only three people participated in this casestudy. However, these three participants took representa-tive roles and the case setting is in a real industry project.They possess different backgrounds and experiences suchas project management, design, requirements analysis ordevelopment. Their findings help us learn that people withdifferent backgrounds may have different viewpoints aboutchange propagation analysis. In addition, two participantsare co-authors of this paper. They strictly followed theprocedure in this study. Furthermore, the original goalsof the exercise were to simply use the dependency typesfor identification and change analysis in a real project andconduct an initial evaluation with an exploratory and ex-perience report nature. At this stage, there were no stronghypotheses involved.

(2) Single project

For external validity, we have only evaluated depen-dency types on one project as our first step towards theevaluation and improvement of our new dependency modeland acknowledge its limitation. Although we only con-ducted the case study in one project that might to some ex-tent impact the participants’ findings, this application ap-peared to be fairly complex and the project is representa-

14

tive in real development settings. The system, PVS, com-prises three subsystems: web subsystem, desktop subsys-tem and mobile (PDA) subsystem being connected throughnetworks. This system manipulates and manages a greatamount of data across subsystems and organisations, andhas high security and performance requirements. In addi-tion, the business process in this system is complex. Thereare more than one hundred requirements. The current goalwas to conduct an initial in-depth case analysis for moresystematic evaluation in the near future.

The case study discussed here is the first real-world ap-plicability evaluation of dependency types in both identifi-cation and change propagation analysis. We acknowledgethat the new dependency model and the associated depen-dency types proposed in this article are mainly based onthe existing literature and the findings of this case studywhich needs to be validated. Compared to other existingdependency models, however, we formalise the definitionsof the initial set of dependency types with their explicitdirection and typical use in software engineering. We be-lieve the refined definition of the dependency types canfacilitate the realisation of other empirical studies similarto ours.

7. Conclusions and Future Work

Although the existing requirement dependency litera-ture suggested many dependency models, there still lacksan overall comprehensive understanding about dependen-cies among requirements. This article reports our researchin evaluating and refining the dependencies inherent insoftware requirements. We first conducted a case study toempirically evaluate the 25 dependency types from twogeneric requirement dependency models in an industryproject. As the initial evaluation of the dependency mod-els/types in the community, this study focuses on evalu-ating the usefulness and applicability of these dependencytypes in identification and change propagation analysis.From the analysis of the results, our findings are 1) the def-initions of some dependency types are confusing and diffi-cult to use in practise; 2) some dependency types from lit-erature are not common and seldom found in real projects;3) in existing dependency models, five dependency typespropagate changes, but their definitions need to be clari-fied.

We also found change propagation analysis is affectedby a practitioner’s viewpoint and experiences. The partic-ipant with project management experiences may empha-sise the changes that happen at the business and high-leveldesign level. The participant with requirements engineer-ing experiences pays special attention on the changes atthe level of requirements description and business. While,the participant with development experiences may caremore about the changes happening at the implementationlevel. All their concerns are important for change analy-sis. Therefore, change propagation analysis should involvea wide range of stakeholders.

Based on these findings from the case study as well asour previous research in evaluation and identification ofrequirement dependencies, we propose a new requirementdependency model that aims to depict a clear classifica-tion of requirement dependencies and their interactionswith software engineering activities. Nine specific depen-dency types are suggested in the initial version of the newdependency model which have refined, improved and in-tegrated existing requirement dependencies. We expectother researchers’ suggestions and additions to further im-prove this dependency model.

Dependency identification is also useful to key require-ments elicitation. Our initial case study discovers andprovides a group of dependency types (with change pat-terns) important to change propagation analysis. Thesedependency types can be used not only in the naturallanguage requirements documents, but also in the require-ments models defined by requirements modelling languages.In the future, we will apply our findings to more industryprojects to validate their applicability.

Future work is planned in various directions. First, thedefinitions of dependency types in the new model need tobe improved. Although the model is based on the exist-ing literature and the empirical evaluation of other depen-dency models in one industry project, more examples arestill needed to increase their understandability. Currentlywe are undertaking follow-up empirical evaluation of thenew requirement dependency model proposed in this arti-cle. The follow-up studies focus on the understandabilityand usability of the new model in comparison with theconventional P -model and D-model as well as serve as thereplication of the initial study reported here but with im-proved internal and external validity, e.g., more rigorousdesign, larger sample size, and more projects from differentcountries. The details and results of the follow-up studieswill be reported in the near future.

Next, the representation or modelling method of re-quirement dependencies needs to be explored. A require-ment dependency modelling language can represent differ-ent types, directions and contents of relationships as wellas model the evolution state of relationships during thewhole product lifecycle.

Last but not least, we encourage software engineeringresearchers carry out more empirical studies to evaluatethe existing dependency models, and particularly welcomethe external evaluation of the new dependency model sug-gested in this paper.

Acknowledgments

This work is supported by National ICT Australia whichis funded through the Australian Government’s BackingAustralia’s Ability initiative, in part through the Aus-tralian Research Council. This work is also supported bythe National Natural Science Foundation of China undergrant No. 60803023, No. 60873072, No. 90718042, theNational Basic Research Program (973 program) under

15

grant No. 2007CB310802, the Hi-Tech Research and De-velopment Program of China (863 Program) under grantNo. 2007AA010303

References

[1] P. Abate, R. Di Cosmo, J. Boender, and S. Zacchiroli. Strongdependencies between software components. In Proceedings of3rd International Symposium on Empirical Software Engineer-ing and Measurement (ESEM’09), pages 89–99, Lake BuenaVista, FL, Oct. 2009. IEEE.

[2] N. Aizenbud-Reshef, B. T. Nolan, J. Rubin, and Y. Shaham-Gafni. Model traceability. IBM Systems Journal, 45(3):515–526, 2006.

[3] G. Antoniol, G. Canfora, G. Casazza, A. de Lucia, and E. Merlo.Recovering traceability links between code and documentation.IEEE Transactions on Software Engineering, 28(10):970–983,2002.

[4] R. S. Arnold and S. A. Bohner. Software Change Impact Anal-ysis. Wiley-IEEE Computer Society Press, 1996.

[5] S. A. Bohner. Software change impacts-an evolving perspective.In Proceedings of International Conference on Software Mainte-nance (ICSM’02), pages 263–272, Montreal, Canada, Oct. 2002.IEEE.

[6] P. Carlshamre and B. Regnell. Requirements lifecycle man-agement and release planning in market-driven requirementsengineering processes. In Proceedings of 11th InternationalWorkshop on Database and Expert Systems Applications(DEXA’00), pages 961–965, London, UK, Sept. 2000. IEEEComputer Society.

[7] P. Carlshamre, K. Sandahl, M. Lindvall, B. Regnell, and J. N.och Dag. An industrial survey of requirements interdependen-cies in software product release planning. In Proceedings of 5thIEEE International Symposium on Requirements Engineering(RE’01), pages 84–91, Toronto, Canada, Aug. 2001. IEEE Com-puter Society.

[8] R. Chitchyan and A. Rashid. Tracing requirements interdepen-dency semantics. In Proceedings of Workshop on Early Aspects,Bonn, Germany, Mar. 2006.

[9] A. G. Dahlstedt and A. Persson. Engineering and ManagingSoftware Requirements, chapter Requirements Interdependen-cies: State of the Art and Future Challenges. Springer, 2005.

[10] A. De Lucia, F. Fasano, and R. Oliveto. Traceability man-agement for impact analysis. In Proceedings of Frontiers ofSoftware Maintenance (FoSM’08), pages 21–30, Beijing, China,Sept. 2008. IEEE Computer Society.

[11] A. de Lucia, F. Fasano, R. Oliveto, and G. Tortora. Recoveringtraceability links in software artifact management systems usinginformation retrieval methods. ACM Transactions on SoftwareEngineering and Methodology, 16(4):13:1–13:50, 2007.

[12] A. R. Fasolino and G. Visaggio. Improving software compre-hension through an automated dependency tracer. In Proceed-ings of 7th International Workshop on Program Comprehen-sion (IWPC’99), pages 58–65, Pittsburgh, PA, USA, May 1999.IEEE Computer Society.

[13] M. W. Godfrey and D. M. German. The past, present, and fu-ture of software evolution. In Proceedings of Frontiers of Soft-ware Maintenance (FoSM’08), pages 129–138, Beijing, China,Oct. 2008. IEEE.

[14] G. L. Hamza-Lup, A. Agarwal, R. Shankar, and C. Iskan-der. Component selection strategies based on system require-ments’ dependencies on component attributes. In Proceedingsof 2nd IEEE Annual Systems Conference (SysCon’08), pages1–5, Montreal, Canada, Apr. 2008. IEEE.

[15] J. Hassine, J. Rilling, J. Hewitt, and R. Dssouli. Change im-pact analysis for requirement evolution using use case maps.In Proceedings of 8th International Workshop on Principles ofSoftware Evolution (IWPSE’05), pages 81–90, Lisbon, Portu-gal, Sept. 2005. IEEE Computer Society.

[16] J. H. Hayes, A. Dekhtyar, and S. K. Sundaram. Advanc-ing candidate link generation for requirements tracing: Thestudy of methods. IEEE Transactions on Software Engineering,32(1):4–19, 2006.

[17] J. Karlsson, S. Olsson, and K. Ryan. Improved practical sup-port for large-scale requirements prioritising. Requirements En-gineering, 2(1):51–60, 1997.

[18] S. S. Khan, P. Greenwood, A. Garcia, and A. Rashid. Onthe impact of evolving requirements-architecture dependen-cies: An exploratory study. In Proceedding of 20th Interna-tional Conference on Advanced Information Systems Engineer-ing (CAiSE’08), volume LNCS 5074, pages 243–257, Montpel-lier, France, Jun. 2008. Springer.

[19] S. S. Khan and S. Lock. Concern tracing and change impactanalysis: An exploratory study. In Proceedings of ICSE Work-shop on Aspect-Oriented Requirements Engineering and Archi-tecture Design (EA’09), pages 44–48, Vancouver, Canada, May2009. IEEE Computer Society.

[20] M. Lehman, J. Ramil, P. Wernick, D. Perry, and W. Turski.Metrics and laws of software evolution-the nineties view. InProceedings of 4th International Software Metrics Symposium,pages 20–32, Albuquerque, NM, Nov. 1997. IEEE.

[21] J. Li, R. Jeffery, K. H. Fung, L. Zhu, Q. Wang, H. Zhang,and X. Xu. A business process-driven approach for require-ments dependency analysis. In Proceedings of 10th Interna-tional Conference on Business Process Management (BPM’12),volume LNCS 7481, pages 200–215, Tallinn, Estonia, Sept.2012. Springer.

[22] J. Li, L. Zhu, R. Jeffery, Y. Liu, H. Zhang, Q. Wang, andM. Li. An initial evaluation of requirements dependency typesin change propagation analysis. In Proceedings of 15th Interna-tional Conference on Evaluation and Assessment in SoftwareEngineering (EASE’12), pages 62–71, Ciudad Real, Spain, May2012. IET.

[23] Y. Li, J. Li, Y. Yang, and M. Li. Requirement-centric traceabil-ity for change impact analysis: A case study. In Proceedings ofInternational Conference on Software Process (ICSP’08), vol-ume LNCS 5007, pages 100–111, Leipzig, Germany, May 2008.Springer.

[24] K. Pohl. Process-Centered Requirements Engineering. Ad-vanced Software Development Series. Research Studies Pre,1996.

[25] W. N. Robinson, S. D. Pawlowski, and V. Volkov. Requirementsinteraction management. ACM Computing Surveys, 35(2):132–190, 2003.

[26] D. Sellier, M. Mannion, and J. X. Mansell. Managing require-ments inter-dependency for software product line derivation.Requirements Engineering, 13(4):299–313, 2008.

[27] A. von Knethen and M. Grund. Quatrace: a tool environmentfor (semi-) automatic impact analysis based on traces. In Pro-ceedings of 11th International Conference on Software Main-tenance (ICSM’03), pages 246–255, Amsterdam, Netherlands,Sept. 2003. IEEE Computer Society.

[28] A. von Knethen, B. Paech, F. Kiedaisch, and F. Houdek. Sys-tematic requirements recycling through abstraction and trace-ability. In Proceedings of IEEE Joint International Conferenceon Requirements Engineering (RE’02), pages 273–281, Essen,Germany, Sept. 2002. IEEE Computer Society.

[29] S. Winkler and J. von Pilgrim. A survey of traceability in re-quirements engineering and model-driven development. Soft-ware and System Modeling, 9(4):529–565, 2010.

[30] Y.-Q. Yan, S.-X. Li, and X.-M. Liu. Quantitative analysis for re-quirements evolution’s ripple-effect. In Proceedings of Interna-tional Asia Conference on Informatics in Control, Automationand Robotics (CAR’09), pages 423–427, Bangkok, Thailand,Feb. 2009. IEEE Computer Society.

[31] J. Zhou, D. Pakkala, J. Perala, E. Niemela, J. Riekki, andM. Ylianttila. Dependency-aware service oriented architectureand service composition. In Proceedings of IEEE InternationalConference on Web Services (ICWS’07), pages 1146–1149, SaltLake City, Utah, Jul. 2007. IEEE Computer Society.

16

[32] L. Zhu, M. Staples, and R. Jeffery. Scaling up software architec-ture evaluation processes. In Proceedings of International Con-ference on Software Process (ICSP’08), volume LNCS 5007,pages 112–122, Leipzig, Germany, May 2008. Springer.

[33] L. Zhu, M. Staples, and V. Tosic. On creating industry-wide ref-erence architectures. In Proceedings of 12th International En-terprise Distributed Object Computing Conference (EDOC’08),pages 24–30, Munich, Germany, Sept. 2008. IEEE.

[34] O. Zimmermanna, J. Koehlera, F. Leymannb, R. Polleya, andN. Schuster. Managing architectural decision models with de-pendency relations, integrity constraints, and production rules.Journal of Systems and Software, 82(8):1249–1267, 2009.

A. Dahlstedt and Persson’s Interdependency Model

Dahlstedt and Persson proposed a requirement (inter-)dependency model [9]. This section provides a conciseoverview of the seven (inter-)dependency types suggestedin the D-model (Figure 2). More details can be foundin [9].

A.1. Structural Interdependencies

Structural (inter-)dependency types are organised ina structure where relationships are of a hierarchical aswell as of a cross-structure nature. The following (inter-)dependency types fall into this category.

� Refined_to. A higher-level requirement is refinedby a number of more specific requirements. It isused to describe hierarchical structures, where moredetailed requirements are related to their source re-quirements. In this sense, these requirements pro-vide further explanation, detail or clarification aboutthe source requirement. The source requirement canhence be seen as an abstraction of the detailed re-quirements.

� Changes_to. One requirement changes to anotherrequirement if a new version of that requirement isdeveloped which replaces the old one. It is used todescribe the history of a requirement, i.e., how ithas evolved over time since it enables to relate thedifferent versions of a single requirement.

� Similar_to. One stated requirement is similar to oroverlapping with one or more other requirements. Itdescribes situations where one requirement is similarto or overlapping with another in terms of how it isexpressed or in terms of a similar underlying idea ofwhat the system should be able to perform. It canalso be used to describe similar solutions, from whichone has to be selected to be part of the system.

A.2. Constraining Interdependencies

These (inter)dependencies can be identified in order todescribe how requirements can constrain each other or bedependent on each other, especially if this classification isfurther elaborated with respect to different developmentactivities or decisions. There exist two types within thiscategory.

� Requires. The fulfilment of one requirement de-pends on the fulfilment of another requirement. Itis used to describe that if one requirement is to beincluded into the system, it requires another require-ment to be included as well. It can also be used todescribe hierarchical relations between two require-ments of a stronger nature than refined_to, i.e. notoptional.

� Conflicts_with. A requirement is in conflict withanother requirement if they cannot exist at the sametime or if increasing the satisfaction of one require-ment decreases the satisfaction of another require-ment. It both includes situations were it is impossi-ble to implement both requirements, and situationswhere requirements have a negative influence on eachother’s achievement and a trade-off between the res-olution of the requirements must be made.

A.3. Cost/Value Interdependencies

These (inter-)dependencies are concerned with the costsinvolved in implementing a requirement in relation to thevalue that the fulfilment of that requirement will provideto the perceived customer/user.

� Increase/Decrease_cost_of. If one requirementis chosen for implementation, then the cost of imple-menting another requirement increases or decreases.It is used to relate requirements that somewhat in-fluence the implementation, cost of each other.

� Increase/Decrease_value_of. If one requirementis chosen for implementation, then the value to thecustomer of another requirement increases or decreases.It focuses on the effect relations between require-ments may have on the perceived customer value.

B. Pohl’s Dependency Model

Based on a literature survey in the area of require-ments engineering, Pohl proposed a requirement depen-dency model [24] that includes 18 dependency types whichare grouped into five categories (shown in Figure 1: con-dition, content, documents, evolutionary, and abstraction.For example, document-related dependency types are em-bedded in the structure, content and version relationshipsin the requirements representation. Pohl’s model intro-duces broad and general interdependency types that canexist between any type of trace object used in the require-ments engineering process. To keep it brief, we selectivelyelaborate a few common dependency types below. Moredetailed description and explanation can be found in [24].

� Constraints. A requirement can relate to anotherby being a constraint to the latter. For instance,the requirement “cash withdrawal is limited to $2000daily” is a constraint for the requirement “withdrawcash”.

17

� Refines. One requirement can be a refinement ofanother requirement, providing more detailed descrip-tions for the latter.

� Precondition. Only after one function prescribedby a requirement is finished or one condition de-scribed by it is satisfied that another function pre-scribed by a requirement can be performed. UsuallyPrecondition reflects the business rule or the se-quence relationship between tasks. For instance, therequirement “a customer successfully logged in to thesystem” is a precondition for “a customer withdrawscash from bank account”.

� Satisfies. This type expresses that if one require-ment is implemented in the system, another require-ment is also satisfied in it. For example, the require-ment “when a user quits, all opened documents willbe automatically saved” satisfies the requirement “nounsaved work will be allowed before the editor termi-nates”.

18