• What conclusions can we draw from Tables 3 & 4?

PrintProofObsoleteWnuk.pdf

Home >Computer Science homework help >• What conclusions can we draw from Tables 3 & 4?

2 Obsolete software requirements

3 Krzysztof Wnuk a,⇑, Tony Gorschek b,1, Showayb Zahda c,2 4 a Department of Computer Science, Lund University, Ole Römers väg 3, SE-223 63 Lund, Sweden 5 b School of Computing Software Engineering Research Lab, Blekinge Institute of Technology, SE-371 79 Karlskrona, Sweden 6 c Axis Communications AB, Emdalavägen 14, SE-223 69 Lund, Sweden

1 0 a r t i c l e i n f o

11 Article history: 12 Received 6 January 2012 13 Received in revised form 9 October 2012 14 Accepted 3 December 2012 15 Available online xxxx

16 Keywords: 17 Requirements management 18 Obsolete requirements 19 Survey 20 Empirical study 21

2 2 a b s t r a c t

23Context: Coping with rapid requirements change is crucial for staying competitive in the software busi- 24ness. Frequently changing customer needs and fierce competition are typical drivers of rapid require- 25ments evolution resulting in requirements obsolescence even before project completion. 26Objective: Although the obsolete requirements phenomenon and the implications of not addressing them 27are known, there is a lack of empirical research dedicated to understanding the nature of obsolete soft- 28ware requirements and their role in requirements management. 29Method: In this paper, we report results from an empirical investigation with 219 respondents aimed at 30investigating the phenomenon of obsolete software requirements. 31Results: Our results contain, but are not limited to, defining the phenomenon of obsolete software 32requirements, investigating how they are handled in industry today and their potential impact. 33Conclusion: We conclude that obsolete software requirements constitute a significant challenge for com- 34panies developing software intensive products, in particular in large projects, and that companies rarely 35have processes for handling obsolete software requirements. Further, our results call for future research 36in creating automated methods for obsolete software requirements identification and management, 37methods that could enable efficient obsolete software requirements management in large projects. 38� 2012 Elsevier B.V. All rights reserved.

41 1. Introduction

42 Software, as a business, is a demanding environment where a 43 growing number of users, rapid introduction of new technologies, 44 and fierce competition are inevitable [1–3]. This rapidly changing 45 business environment is challenging traditional Requirements 46 Engineering (RE) approaches [4–6]. The major challenges in this 47 environment are high volatility and quick evolution of require- 48 ments, requirements that often tend to become obsolete even be- 49 fore project completion [1,7–9]. At the same time the product 50 release time is crucial [10–12] for the success of the software prod- 51 ucts, especially in emerging or rapidly changing markets [10]. 52 Coping with rapid requirements change is crucial as time- 53 to-market pressures often make early pre-defined requirements 54 specifications inappropriate almost immediately after their crea- 55 tion [7]. In Market-Driven Requirements Engineering (MDRE), the 56 pace of incoming requirements [2] and requirements change is 57 high. Software companies have to identify which requirements 58 are obsolete or outdated. The rapid identification and handling of

59potentially obsolete requirements is important as large volumes 60of degrading requirements threatens effective requirements man- 61agement. In extreme cases, obsolete requirements could dramati- 62cally extend project timelines, increase the total cost of the 63project or even cause project failure; and even the successful iden- 64tification of the obsolete requirements without handling adds little 65or no product value [13–15]. Thus, the identification, handling, and 66removal of obsolete requirements is crucial. 67The phenomenon of obsolete requirements and the implications 68of not handling them are known [16,13,14,17–20]. At the same 69time, several researchers focused on topics related to the phenom- 70enon of obsolete requirements, e.g. requirements volatility and 71scope creep [21–27]. However, very little research has been per- 72formed into obsolete requirements management or guidelines, 73see e.g. [28–33]. Standards [34,35] do not explicitly mention the 74phenomenon of Obsolete Software Requirements (OSRs). The term 75itself is only partly defined and empirically anchored [17]. 76In this paper, we present the results from an empirical study, 77based on a survey with 219 respondents from different companies. 78The survey investigated the phenomenon of obsolete requirements 79and included, an effort to define the phenomenon based on the 80perceptions of industry practitioners. The study also aimed to col- 81lect data on how obsolete requirements are perceived, how they 82impact industry, and how they are handled in industry today.

⇑ Corresponding author. Tel.: +46 46 222 45 17; fax: +46 46 13 10 21. E-mail addresses: [email protected] (K. Wnuk), [email protected]

(T. Gorschek), [email protected] (S. Zahda). 1 Tel.: +46 455 38 58 17; fax: +46 455 38 50 57. 2 Tel.: +46 46 272 18 00; fax: +46 46 13 61 30.

Information and Software Technology xxx (2012) xxx–xxx

Contents lists available at SciVerse ScienceDirect

Information and Software Technology

journal homepage: www.elsevier.com/locate/infsof

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

83 This paper is structured as follows: Section 2 provides the back- 84 ground and related work, Section 3 describes the research method- 85 ology, Section 4 describes and discusses the results of the study, 86 and Section 5 concludes the paper.

87 2. Background and related work

88 Requirements management, as an integral part of require- 89 ments engineering [9,31], manages the data created in the 90 requirements elicitation and development phases of the project. 91 Requirements management integrates this data into the overall 92 project flow [9] and supports the later lifecycle modification of 93 the requirements [9]. As changes occur during the entire software 94 project lifetime [36], managing changes to the requirements is a 95 major concern of requirements management [29,30] for large 96 software systems. Moreover, in contexts like MDRE, a constant 97 stream of new requirements and change requests is inevitable 98 [2]. Uncontrolled changes to software may cause the cost of the 99 regression testing to exceed 100,000 dollars [9]. Further, the ab-

100 sence of requirements management may sooner or later cause 101 outdated requirements specifications as the information about 102 changes to original requirements is not fed back to the require- 103 ments engineers [9]. Finally, the requirements management pro- 104 cess descriptions in literature seldom consider managing 105 obsolete requirements [29,28]. 106 Scope creep, requirements creep and requirements leakage 107 (also referred to as uncontrolled requirements creep) [21,22] 108 are related to OSRs. DeMarco and Lister identified scope creep 109 as one of the five core risks during the requirements phase 110 and state that the risk is a direct indictment of how require- 111 ments were gathered in the first place [23]. Scope creep has also 112 been mentioned as having a significant impact on risk and risk 113 management in enterprise data warehouse projects [37]. Hous- 114 ton et al. [24] studied software development risk factors and 115 60% of 458 respondents perceived that requirements creep was 116 a problem in their projects. Anthes [38] reported that the top 117 reason for requirements creep in 44% of the cases is a poor def- 118 inition of initial requirements. Scope creep can lead to significant 119 scope reductions as overcommitment challenges are addressed. 120 This, in turn, postpones the implementation of the planned func- 121 tionality and can cause requirements to become obsolete [8] or 122 project failure [22]. 123 Despite its importance as a concept, in relation to managing 124 requirements for software products, the phenomenon of OSRs 125 seems to be underrepresented in literature. To the best of our 126 knowledge, only a handful of articles and books mention the terms 127 obsolete requirements or/and obsolete features. Among the 128 existing evidence, Loesch and Ploederoeder [18] claim that the 129 explosion of the number of variable features and variants in a soft- 130 ware product line context is partially caused by the fact that obso- 131 lete variable features are not removed. Murphy and Rooney [13] 132 stress that requirements have ‘a shelf life’ and suggest that the 133 longer it takes from defining requirements to implementation, 134 the higher the risk of change (this inflexibility is also mentioned 135 by Ruel et al. [39]). Moreover, they state that change makes 136 requirements obsolete, and that obsolete requirements can dra- 137 matically extend project timelines and increase the total cost of 138 the project. Similarly, Stephen et al. [14] list obsolete requirements 139 as one of the symptoms of failure of IT project for the UK govern- 140 ment. While the report does not define obsolete requirements per 141 se, the symptom of failure is ascribed to obsolete requirements 142 caused by the inability to unlock the potential of new technologies 143 by timely adoption. 144 The phenomenon of OSRs has not yet been mentioned by stan- 145 dardization bodies in software engineering. Neither the IEEE 830

146standard [34] nor CMMI (v.1.3) [35] mention obsolete software 147requirements as a phenomenon. Actions, processes and techniques 148are also not suggested in relation to handling the complexity. On 149the other hand, Savolainen et al. [17] propose a classification of 150atomic product line requirements into these categories: non-reus- 151able, mandatory, variable and obsolete. Moreover they propose a 152short definition of obsolete requirements and the process of man- 153aging these requirements for software product lines ‘‘by marking 154them obsolete and hence not available for selection into subse- 155quent systems’’. Mannion et al. [19] propose a category of variable 156requirements called obsolete and suggest dealing with them as de- 157scribed by Savolainen et al. [17]. 158OSRs are related to the concept of requirements volatility. 159SWEBOOK classifies requirements into a number of dimensions 160and one of the them is volatility and stability. SWEBOK mentions 161that some volatile requirements may become obsolete [40]. Kulk 162and Verhoef [25] reported that the maximum requirements vol- 163atility rates depend on size and duration of a project. They pro- 164posed a model that calculates the ‘‘maximum healthy volatility 165ratios’’ for projects. Loconsole and Börstler [27] analyzed require- 166ments volatility by looking at the changes to use case models 167while Takahashi and Kamayachi [41] investigated the relation- 168ship between requirements volatility and defect density. On 169the other hand, Zowghi and Nurmuliani [26] proposed a taxon- 170omy of requirement changes where one of the reasons for 171requirements changes is obsolete functionality, defined as ‘‘func- 172tionality that is no longer required for the current release or has 173no value for the potential users’’. For this paper, we understand 174requirements volatility as a factor that influences requirements 175change but different from requirements obsolescence. OSRs are, 176according to our understanding, any type of requirement (stable, 177small, large, changing) that is not realized or dismissed, but 178which accumulates in the companies’ databases and repositories. 179Requirements obsolescence is defined as a situation where 180volatility becomes outdated and remains in the requirements 181databases [42,43]. 182Looking at previous work, software artifact obsolescence has 183been mentioned in the context of obsolete hardware and electron- 184ics in, for example, military, avionics or other industries. Among 185others, Herald et al. proposed an obsolescence management frame- 186work for system components (in this case hardware, software, and 187constraints) that is mainly concerned with system design and 188evolution phases [20]. While, the framework contains a technology 189roadmapping component, it does not explicitly mention OSRs. 190Merola [15] described the software obsolescence problem in to- 191day’s defense systems of systems (the COTS software components 192level). He stressed that even though the issue has been recognized 193as being of equal gravity to the hardware obsolescence issue, it has 194not reached the same visibility level. Merola outlines some options 195for managing software obsolescence, such as negotiating with the 196vendor to downgrade the software license, using wrappers and 197software application programming interfaces, or performing 198market analysis and surveys of software vendors. 199Due to the limited number of studies in the literature dedicated 200to the OSR phenomenon, we decided to investigate the concept 201utilizing a survey research strategy. We investigated the extent 202to which obsolete software requirements are perceived as a real 203phenomenon and as a real problem in industry. Moreover, we 204investigated how OSRs are identified and managed in practice, 205and what contextual factors influence OSRs.

2063. Research methodology

207This section covers the research questions, the research meth- 208odology, and the data collection methods used in the study.

2 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

209 3.1. Research questions

210 Due to the limited number of related empirical studies identi- 211 fied in relation to OSRs, we decided to focus on understanding 212 the OSR phenomenon and its place in the requirements engineer- 213 ing landscape. Thus, most of the research questions outlined in Ta- 214 ble 1 are existence, descriptive, as well as classification questions 215 [44]. Throughout the research questions, we have used the follow- 216 ing definition of OSRs, based on the literature study and the 217 survey:

218 ‘‘An obsolete software requirement is a software requirement, 219 implemented or not, that is no longer required for the current 220 release or future releases, and which has no value or business goals 221 for the potential customers or users of a software artifact for vari- 222 ous reasons.3’’

223 3.2. Research design

224 A survey was chosen as the main tool to collect empirical data, 225 enabling us to reach a larger number of respondents from geo- 226 graphically diverse locations [45]. Automation of data collection 227 and analysis ensured flexibility and convenience to both research- 228 ers and participants [44,46,47]. 229 The goal of the survey was to elicit as much information from 230 industry practitioners as possible in relation to OSRs. Therefore, 231 we opted for an inclusive approach to catch as many answers as 232 possible. This prompted the use of convenience sampling [47]. 233 The details in relation to survey design and data collection are out- 234 lined below.

235 3.2.1. Survey design 236 The questionnaire was created based on a literature review of 237 relevant topics, such as requirements management, volatility, 238 and requirements traceability (see Section 2). The questions were 239 iteratively developed. Each version of the questionnaire was dis- 240 cussed among the authors and evaluated in relation to how well 241 the questions reflected the research questions and the research 242 goals.

243The questionnaire contained 15 open and close-ended ques- 244tions of different formats, e.g. single choice questions and multiple 245choice questions. In open-ended questions, respondents could pro- 246vide their own answers as well as select a pre-defined answer from 247the list. The answers were analyzed using the open coding method 248[48]. The data analysis was started without a preconceived theory 249in mind. We read all the answers and coded interesting answers by 250assigning them to a category with similar meaning. For close- 251ended questions, we used a Likert scale from 1 to 5, where 1 corre- 252sponds to Not likely and 5 to Very likely [49]. 253The questionnaire was divided into two parts: one related to 254OSRs (9 questions), and one related to demographics (6 questions). 255Table 2 shows the survey questions, with a short description of 256their purpose (2nd column), the list of relevant references (3rd col- 257umn), and a link to the addressed research question (4th column). 258It should be observed that an OSR is defined in this work in the 259context of the current release in order to keep the question fairly 260simple and avoid introducing other complicating aspects. For rea- 261sons of brevity, we do not present the entire survey in the paper. 262However, the complete questionnaire, including the references 263that were used to construct the categories for the answers is avail- 264able online [50].

2653.2.2. Operation (execution of the survey) 266The survey was conducted using a web-survey support website 267called SurveyMonkey [52]. Invitations to participate in the ques- 268tionnaire were sent to the potential audience via:

269� Personal emails—utilizing the contact networks of the authors 270� Social network websites [53]—placing the link to the question- 271naire on the board of SE and RE groups and contacting individ- 272uals from the groups based on their designated titles such as 273senior software engineer, requirements engineer, system ana- 274lyst, and project manager to name a few 275� Mailing lists—requirements engineering and software engineer- 276ing discussion groups [54] 277� Software companies and requirements management tool ven- 278dors [55] 279

280Masters and undergraduate students were excluded as poten- 281tial respondents because their experience was judged insufficient 282to answer the questionnaire. The questionnaire was published 283online on the 3rd of April, 2011 and the data collection phase

Table 1 Research questions.

Research question Aim Example answer

RQ1: Based on empirical data, what would be an appropriate definition of Obsolete Software Requirements (OSR)?

Instead of defining the phenomenon ourselves we base the definition on how the phenomenon is perceived in industry

‘‘An obsolete software requirements is a requirement that has not been included into the scope of the project for the last 5 projects’’

RQ2: What is the impact of the phenomenon of obsolete software requirements on the industry practice?

To investigate to what degree is OSR a serious concern ‘‘Yes it is somehow serious’’

RQ3: Does requirement type affect the likelihood of a software requirement becoming obsolete?

Are there certain types of requirements that become obsolete more often than others? Can these types be identified?

‘‘A market requirement will become obsolete much faster than a legal requirement’’

RQ4: What methods exist, in industry practice, that help to identify obsolete software requirements?

To enact a process to detect, identify or find obsolete software requirements or nominate requirements that risk becoming obsolete

‘‘To read the requirements specification carefully and check if any requirements are obsolete’’

RQ5: When OSRs are identified, how are they typically handled in industry?

In order to identify possible alternatives for OSR handling, we first need to understand how they are handled today

‘‘We should mark found obsolete requirements as obsolete but keep them in the requirements database’’

RQ6: What context factors, such as project size or domain, influence OSRs?

As a step in understanding and devising solutions for handling OSRs, it is important to identify contextual factors that have an influence on the obsolete requirements phenomenon

‘‘OSRs are more common in large projects and for products that are sold to an open market (MDRE context)’’

RQ7: Where in the requirements life cycle should OSRs be handled?

To position requirements obsolescence in the requirements engineering life cycle

‘‘They should be a part of the requirements traceability task’’

3 For reader convenience we present the definition in this section, rather than after presentation of the results. The description of how the definition was derived is available in Section 4.

K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx 3

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

284 ended on the 3rd of May, 2011. In total, approximately 1700 indi- 285 vidual invitations were sent out with 219 completed responses col- 286 lected. The response rate, around 8%, is an expected level [44,45]. 287 The results of the survey are presented in Section 4.

288 3.3. Validity

289 In this section, we discuss the threats to validity in relation to 290 the research design and data collection phases. The four perspec- 291 tives of validity discussed in this section are based on the classifi- 292 cation proposed by Wohlin et al. [56].

293 3.3.1. Construct validity 294 Construct validity concerns the relationship between the obser- 295 vations from the study and the theories behind the research. The 296 phrasing of questions is a threat to construct validity. The authors 297 of this paper and an independent native English speaker and wri- 298 ter–reviewer revised the questionnaire to alleviate this threat. To 299 minimize the risk of misunderstanding or misinterpreting the sur- 300 vey questions, a pilot study was conducted on master students in 301 software engineering. The pilot study clearly indicated that a 302 shorter list of categories is more preferable than a more extensive 303 one. No participant in the pilot study indicated that the require- 304 ments categories in question 3 [50] were hard to understand or va- 305 gue. However, the choice of the categories used in the paper for 306 eliciting information from practitioners remains a threat to con- 307 struct validity. There is always a threat that the categories are 308 too simple, too few, too complex or too many. The choices we 309 made, see Section 4.4, are based on keeping it as simple as possible 310 and were derived after reviewing several classifications and a pilot 311 study. 312 The reader should keep in mind that the data given by respon- 313 dents is not based on any objective measurements and thus its 314 subjectivity affects the interpretation of the results. The mono- 315 operational bias [56] threat to construct validity is addressed by 316 collecting data from more than 200 respondents from 45 countries. 317 Finally, the mono-method bias [56] threat to construct validity was 318 partly addressed by analyzing related publications. While several 319 related publications have been identified (see Section 2), this 320 threat is not fully alleviated and requires further studies. Finally, 321 considering social threats to construct validity it is important to 322 mention the evaluation apprehension threat [56]. The respondents’ 323 anonymity was guaranteed. 324 Some may argue that using the same questionnaire to define 325 the term and to investigate it threatens construct validity. 326 However, the fact that the presented OSR definition is based on 327 over 50% of the answers and that the definition turned out to be 328 independent of the respondents’ roles, the size of the organiza-

329tions, the length of the typical project, the domain and the devel- 330opment methodologies used gives us the basis to state that the 331understanding of the measured phenomenon was rather homoge- 332neous among the respondents (Section 4.2). In addition, we do gain 333one aspect by combining the two, namely the subject’s interpreta- 334tion/understanding of what an obsolete requirement is. We are 335able to identify if respondents disagree, a fact which is essential 336for combining results (several respondents answers) for analysis.

3373.3.2. Conclusion validity 338Conclusion validity is concerned with the ability to draw correct 339conclusions from the study. To address the measures reliability 340threat, the questions used in the study were reviewed by the 341authors of this paper and one external reviewer, a native English 342speaker. The low statistical power threat [56] was addressed by 343using as suitable statistical tests as was possible on the given type 344of data. Before running the tests, we tested if assumptions of the 345statistical tests were not violated. However, since multiple tests 346were conducted on the same data, the risk of type-I error increases 347and using, for example, the Bonferroni correction should be dis- 348cussed here. Since the correction was criticized by a number of 349authors [57,58] it remains an open question if it should be used. 350Therefore, we report the p-values of all performed tests in case 351the readers want to evaluate the results using the Bonferroni cor- 352rection or other adjustment techniques [57]. Finally, the random 353heterogeneity of subjects [56] threat should be mentioned here 354as this aspect was only partly controlled. However, low heteroge- 355neity of subjects allows us to state conclusions of a greater external 356validity.

3573.3.3. Internal validity 358Internal validity threats are related to factors that affect the 359causal relationship between the treatment and the outcome. Re- 360views of the questionnaire and the pilot study addressed the 361instrumentation threat [56] to internal validity. The maturation 362threat to internal validity was alleviated by measuring the time 363needed to participate in the survey in the pilot study (15 min). 364The selection bias threat to internal validity is relevant as non-ran- 365dom sampling was used. Since the respondents were volunteers, 366their performance may vary from the performance of the whole 367population [56]. However, the fact that 219 participants from 45 368countries with different experience and industrial roles answered 369the survey minimizes the effect of this threat. Finally, the level of 370education in development processes and methodologies may have 371impacted the results from the survey. It remains future work to 372investigate whether this factor impacts the results. However, as 373the survey participants are professionals (many of whom work in 374large successful companies) their education might not be the main

Table 2 Mapping between the questionnaire questions and the research questions.

Question Purpose Relevant references RQ

Q1 To derive the definition of Obsolete Software Requirements [17,20,26,15] RQ1 Q2 To investigate the impact of the OSRs on industry practice [13,14] RQ2 Q3 To investigate how likely the various types of requirements would

become obsolete The list of requirements types was derived from analyzing several requirements classifications [42,43]

RQ3

Q4 To investigate the possible ways of identifying OSR in the requirements documents

[18,20] RQ4

Q5 To investigate the possible actions to be taken against obsolete requirements after they are discovered

[18,20] RQ5

Q6 To investigate whether there is a correlation between project size and the effects of OSRs

The classification of different sizes of requirements engineering was adopted from Regnell et al. [51]

RQ6

Q7 To investigate if OSRs are related to the software context [14] RQ6 Q8 To understand where in the requirements life cycle OSRs should

be handled Current standards for requirements engineering and process models [34,35] do not consider obsolete requirements

RQ5, partly RQ7

Q9 To investigate if industry has processes for managing OSR [18,17] RQ5

4 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

375 issue for discussion. What is interesting, however, is that we are 376 investigating the state of current industry practice and not how 377 it might be. Education is a powerful tool, but not the focus of this 378 paper.

379 3.3.4. External validity 380 External validity threats concern the ability to generalize the 381 result of research efforts to industrial practice [56]. The survey 382 research method was selected to assure as many responses as 383 possible, generating more general results [44,59,47] than a qualita- 384 tive interview study. Moreover, the large number of respondents 385 from various countries, contexts, and professions contributes to 386 the generalization of results.

387 4. Results and analysis

388 The survey was answered by 219 respondents. When questions 389 allowed multiple answers, we calculated the results over the total 390 number of answers, not respondents. For questions that used a 391 Likert scale, we present the results using average rating and the 392 percentage received by each answer on the scale. All results are 393 presented in percentage form and complemented by the number 394 of answers or respondents when relevant. The answers given to 395 the open questions were analyzed using the open coding method 396 [48] (Section 3.2.1). Statistical analysis, when relevant, was per- 397 formed using the chi-square test [60], and the complete results 398 from the analysis, including contingency tables for some of the an- 399 swers [61], are listed online.

400 4.1. Demographics

401 Fig. 1 depicts the top 10 respondent countries (out of 45).4 The 402 full list of the countries is available in [62]. The US and the UK

403constitute about 30% of the total respondents and 54% of the respon- 404dents came from Europe. 405Fig. 2 depicts the main roles of the respondents in their organi- 406zations. About one quarter of the respondents (24.9% or 54 respon- 407dents) described their role as requirements engineers, analysts or 408coordinators. The second largest category, Other (with 30 answers), 409include roles such as System Engineers, Software Quality Assurance, 410Process Engineers, and Business Analysts. The third largest category 411was Researchers or Academics (11.5% of all answers). Software Pro- 412ject Managers and Software Architect or Designer roles had the same 413number of respondents (22 each). Twelve respondents declared 414their main role as Software Product Manager, a relatively high num- 415ber since product managers are generally few in an organization. 416This would seem to indicate that middle and senior managers 417overall represented a substantial part of the respondents. 418Fig. 3 gives an overview of the business domain of the respon- 419dents. A total of 32.8% stated the IT or Computer and Software 420Services. The second largest group (12.5%) is Engineering (automo- 421tive, aerospace and energy). These were followed by Telecommuni- 422cation (10.7%) and Consultancy (9.3%). 423Fig. 4 depicts the sizes of the respondents’ organizations. We 424can see that more than half of the respondents work in large com- 425panies (>501 employees). 426Fig. 5 looks at the average duration of a typical project in the 427respondents’ organizations. About half of the respondents (�45%) 428were involved in projects that lasted for less than a year, one quar- 429ter in projects that lasted between 1 and 2 years and one quarter in 430projects typically lasting more than 2 years. 431Fig. 6 investigates the development methodologies and pro- 432cesses used by the respondents. Since this question allowed for 433the possibility of providing multiple answers, the results are based 434on the number of responses. Agile development tops the list of 435answers with approximately a quarter (23.6%). Incremental and 436evolutionary methodology (18.8%) is in second place. Surprisingly, 437waterfall is still common and widely used (17.7%). In the Other 438category, the respondents reported that they mixed several 439methodologies ‘‘combination of agile and incremental’’ or ‘‘it is a

Fig. 1. Top 10 countries among respondents.

4 The actual category names have been changed for readability purposes. The original names are mentioned using italics in the paper and are available in the survey questionnaire [50].

K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx 5

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

440 mix of incremental, agile and others’’. Other respondents used ‘‘V- 441 Model’’, ‘‘SLIM’’, ‘‘CMMI Level 3’’, ‘‘CMMI Level 5’’ or had their own 442 tailored methodology ‘‘created for each company by blending 443 methods/processes’’. 444 Fig. 7 investigates the type of requirements engineering the 445 respondents are involved in. Since this question also allowed mul- 446 tiple answers, the results are calculated based on the total number 447 of responses. Bespoke or Contract driven requirements engineering

448received 44.2% of all the answers. Market-driven requirements engi- 449neering received 29.5%, while Open source only 5.1%. Outsourced 450projects appeared in 19.9% of the answers. Six answers were given 451to the Other category. Two respondents suggested none of the fol- 452lowing. One was working with ‘‘normal flow, requirements from 453product owner or developers’’, one with ‘‘builds’’ one mainly with 454infrastructure projects, and one with ‘‘large SAP implementation 455projects in a client organization’’.

Fig. 2. Main role of respondents.

Fig. 3. Types of business domains of respondents.

6 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

456 4.2. Defining obsolete requirements (RQ1)

457 Defining the term Obsolete Software Requirement (OSR) is cen- 458 tral to the understanding of the phenomenon. The categories used 459 in this question were inspired by the definitions of OSR found in 460 literature (Section 2), and are defined in the context of the current 461 release (Section 3.2.1). Fig. 8 depicts the answers from all respon- 462 dents. Since the question allows multiple answers, the results are 463 calculated for all the answers, not the respondents. The primary

464answer selected (29.9%) defines OSR as ‘‘no longer required for the 465current release for various reasons’’. This result is in line with the 466definition of obsolete functionality provided by Zowghi and Nur- 467muliani [26]. The definition of an OSR as a requirement that: 468‘‘has no value for the potential users in the current release’’ received 46921% if the responses. This category is similar to the definition of ob- 470solete software applications provided by Merola [15], as applica- 471tions are taken off the market due to decrease in product 472popularity or other market factors.

Fig. 4. Size of respondents’ organization.

Fig. 5. Average duration of typical projects from our respondents.

K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx 7

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

473 A total of 33 responses (7.7%) were in the Other category. Of 474 these, 8 respondents (�25%) suggested that an OSR is not necessar- 475 ily confined to the current release, but it also goes to future re- 476 leases. Respondents stressed that an OSR is a requirement that 477 has lost its business goal or value. Other interesting definitions in- 478 cluded: ‘‘an OSR is a requirement that evolved in concept but not in

479documentation’’, ‘‘an OSR will be implemented but will not be 480tested’’, and ‘‘carved by the IT to showcase technical capabilities 481to the end user’’. 482As a result, the following definition of an OSR was formulated:

483‘‘An obsolete software requirement is a software requirement 484(implemented or not) that is no longer required for the current

Fig. 6. Development processes and methodologies.

Fig. 7. Types of requirements engineering.

8 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

485 release or future releases and, for various reasons, has little or no 486 business value for the potential customers or users of a software 487 product.’’

488 We performed statistical analyses to investigate whether there 489 were relationships between the selected definition of OSRs and the 490 respondents’ roles, the size of organizations and the development 491 methodologies used. Overall, the relationships were statistically 492 insignificant due to violations of the chi-square test assumptions 493 (some alternative answers had too few respondents, see Table 494 A.2 in [61]). However, significant results could be observed (using 495 the chi-square test) between the top five methodologies (Fig. 6) 496 and and the results for choice of OSR definition (p-value 0.011, Ta- 497 ble A.2a in [61]). Respondents that reported using a Rational Unified 498 Process (RUP) methodology less frequently selected the definition 499 of OSRs as no longer required for the current release (31.3% of all 500 answers compared to over 50%) or never implemented in the prod- 501 uct (34.4% of all answers compared to over 40%) than respondents 502 that reported utilizing any of the remaining four methodologies. 503 Moreover, the RUP respondents provided more answers in the 504 Other category and indicated that OSRs can be ‘‘a requirement that 505 evolved in concept but not in documentation’’ or ‘‘an abstract 506 requirement to showcase the technical capability to the end user’’. 507 Finally, only three RUP respondents defined OSR as a requirement 508 that is rejected for inclusion in the current release, while about 20% 509 of the respondents that selected the other top four methodologies 510 selected this answer. This would seem to indicate that the per- 511 ceived definition of an OSR for respondents using the RUP method- 512 ology is more stable than that for respondents using other 513 methodologies. 514 Since the RUP methodology considers iterative development 515 with continuous risk analysis as a core component of the method 516 [63], we can assume that the risk of keeping never used or imple- 517 mented requirements in the projects is lower. Moreover, the 518 majority of the RUP respondents also reported working on bespoke 519 or contract-driven projects, where the number of changes after the 520 contract is signed is limited and usually extensively negotiated. 521 Thus it appears to be possible that the RUP respondents could avoid 522 rejected or refused requirements and could manage to achieve

523more precise and stable agreements with their customers [63] 524which in turn could result in fewer OSRs. 525Reviewing the top five methodologies, the most popular answer 526was no longer required for the current release. Interestingly, 527among the respondents working with agile, incremental or evolu- 528tionary methodologies, the fourth most popular answer was never 529used or implemented in the product. 530In contrast, respondents who worked with waterfall, prototyp- 531ing or RUP methodologies have the same order of popularity of an- 532swers. The definition of an OSR as a was never used or implemented 533in the product requirement was the second most popular answer 534while the option is duplicated/redundant in the current release was 535the third most popular answer. The possible interpretation of these 536results is that agile and incremental methodologies less frequently 537experience OSRs as never used or implemented but experience 538more OSRs as duplicated requirements and requirements with no 539value for the potential users. 540Further analysis reveals that the definition of OSRs is not signif- 541icantly related to the size of the companies, the length of the typ- 542ical project, or the domain (p-values in all cases greater than 0.05). 543Domain and project length could be seen as qualifiers of OSRs. For 544example, projects running over long periods could suffer increased 545requirements creep [8]. However, this would most probably not be 546visible in the definition of OSRs, but rather in the impact of OSRs, 547which is investigated in the next section.

5484.3. The potential impact of OSRs (RQ2)

549When queried about the potential impact of OSRs on their 550product development efforts a total of 84.3% of all respondents 551considered OSR to be Serious or Somehow serious (Fig. 9). This 552indicates that among the majority of our respondents OSRs seems 553to have a substantial impact on product development. Our result 554confirms previous experiences. (See, e.g., Murphy and Rooney 555[13], Stephen et al. [14] and Loesch and Ploederoeder [18].) For 5566% of the respondents OSRs are a Very serious issue, while 10% 557(21 respondents) deemed OSR a Trivial matter. 558To further decompose and test context variables, e.g., company 559size, respondents’ roles and development methodologies, we

Fig. 8. Respondents’ definition of an OSR.

K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx 9

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

560 performed chi-square tests (Table A.1 in [61]) between the context 561 variables and the degree to which OSRs were considered having a 562 substantial impact. The tests resulted in p-values greater than 0.05, 563 which indicates that no statistically significant relationships be- 564 tween the analyzed factors could be seen. We can, however, ascer- 565 tain that a clear majority of the respondents deemed the 566 phenomenon of OSRs a relevant factor to be taken into consider- 567 ation in development efforts. 568 Of the 21 (10%) respondents who considered OSRs to be Trivial, 569 approximately 58% worked with requirements or in project man- 570 agement roles. This would seem to indicate that those respondents, 571 contrary to those in software development roles, have less diffi- 572 culty in managing OSRs. An analysis of the answers to question- 573 naire question 9 ([61] and Section 4.9) revealed that 10 574 respondents who considered OSRs to be Trivial also confirmed hav- 575 ing a process for managing OSRs. Thus, it appears to be a logical 576 conclusion that the negative influence of OSRs on product develop- 577 ment could be alleviated by designing and introducing an appro- 578 priate process of managing OSRs. More about the current 579 processes discovered among our respondents can be found in Sec- 580 tion 4.9. 581 Further analysis of the respondents who considered OSRs as 582 Trivial indicated that more than 80% of them worked for large com- 583 panies with >101 employees. Since large companies often use more 584 complex process models [64], in contrast to small companies 585 which might have budget constraints to prevent hiring highly 586 quality professionals and whose processes are typically informal 587 and rather immature [65], we could assume that the issue of man- 588 aging OSRs could have been already addressed in these cases. 589 Further analysis of the Trivial group indicated that almost half of 590 them (47.6%) worked in the IT or computer and software services do- 591 main, In the service domain, the main focus of requirements engi- 592 neering is to identify the services that match system requirements 593 [66]. In the case of insufficient alignment of new requirements 594 with the current system, product development may simply select 595 a new, more suitable, service. This, in turn, might imply that the 596 OSRs are discarded by replacing the old service with the new 597 one. Further, the typical product lifetime for IT systems is usually 598 shorter than for engineering-focused long-lead time products 599 [67] (such as those in the aerospace industry), which in turn could 600 minimize the number of old and legacy requirements that have to 601 be managed. The possible interpretation of our analysis is that

602OSRs are less critical in IT and service oriented domains. Although 603this is a possible and plausible explanation, further investigation is 604needed to reach a conclusion. 605Among the respondents who considered OSRs Very serious (13 606respondents), the majority (53.8%) worked in large companies 607and used agile, ad hoc, or incremental methodologies (61.6%). This 608result seems to indicate that OSRs are also relevant for agile devel- 609opment and not reserved for only more traditional approaches like 610waterfall. Ramesh et al. [4] pointed out after Boehm [68] that 611quickly evolving requirements that often become obsolete even 612before project completion significantly challenge traditional 613(waterfall) requirements engineering processes. Murphy and Roo- 614ney [13] stressed that the traditional requirements process seri- 615ously contributes to the creation of obsolete requirements by 616creating a ‘‘latency between the time the requirements are cap- 617tured and implemented’’. This latency should be lower in agile pro- 618jects, characterized by shorter iterations and greater delivery 619frequency. This might indicate that either the latency is present 620in agile projects as well, or that latency is not the primary determi- 621nant of OSRs. It should be observed that 69.2% of the respondents 622who considered OSRs as Very serious reported having no process for 623handling OSRs. This could indicate why OSRs were considered a 624Very serious problem. 625The cumulative cross tabulation analysis of the respondents 626who considered OSRs Somehow serious, Serious or Very serious (total 627196 respondents, 89%) confirmed the severe impact of OSRs on 628large market-driven and outsourced projects (Section 4.7.2). More- 629over, 76.8% of those respondents reported that they had no process, 630method, or tool for handling OSRs. In addition, 72.3% of respon- 631dents who considered OSRs Somehow serious, Serious or Very serious 632used manual methods to identify OSRs. It is also interesting to ob- 633serve that the were only small differences between answers fron 634respondents who declared the following: Agile software develop- 635ment or Incremental or evolutionary development methodologies, 636and Waterfall development. Respondents using Waterfall develop- 637ment (and considered OSRs Serious or Somehow serious or Very seri- 638ous) were somewhat more prone to dismiss the impact of OSRs 639compared to respondents using Agile software development or Incre- 640mental or evolutionary development methodologies. This would 641seem to indicate that, because waterfall-like processes usually re- 642strict late or unanticipated changes and focus on extensive docu- 643mentation [69,7,70], the impact of OSRs in those processes could 644be minimized. However, it says nothing about the extent that the 645realized features were useful or usable for the customers. Some 646waterfall projects may not have perceived OSRs to be a major issue 647for the project, but they might be for the product per se. That is, 648implementing an outdated feature might not be a perceived as a 649problem in a project. At the product level, where the overall value 650of the product for the customer should be maximized through the 651selection of the right features to implement and best alternative 652investment should be considered, another feature could be imple- 653mented instead of the outdated one. This is a classical case of per- 654spective being a part of the value consideration as described by 655Gorschek and Davis [71]. 656The type of requirements engineering context factor (Fig. 7) 657only minimally influenced the overall results for this questionnaire 658question. Respondents who reported to work with Bespoke or con- 659tract driven requirements engineering graded OSRs slightly less seri- 660ous than respondents who reported working with MDRE. This 661seems to indicate that OSRs are a problem in both contract driven 662(where renegotiation is possible [2]) and market-driven (where 663time to market is dominant [2]) projects. However, the difference 664could also indicate that there is a somewhat alleviating factor in 665contract-based development. That is, contract based development 666aims at delivering features and quality in relation to stated con- 667tract, thus getting paid for a requirement even if it is out of date

Fig. 9. Impact of OSRs on industry practice.

10 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

668 at delivery time. In an MDRE context, however, the product might 669 fail to sell if the requirements are not fulfilled and the features out 670 of date [2].

671 4.4. Requirements types and OSRs (RQ3)

672 The respondents were asked to choose what types of require- 673 ments were most likely to become obsolete (Likert scale, 1 = Not 674 likely, and 5 = Very likely). We reviewed several classification 675 schemes before choosing the categories. The classification pro- 676 posed by Aurum and Wohlin [72] and SWEBOOK [73] inspired us 677 to have functional and quality requirements types as well as to in- 678 clude sources of requirements into categories. The examples of 679 requirements related to government legislations in banking pro- 680 vided by SWEBOOK [73] and the change to government policy or reg- 681 ulation trigger mentioned by McGee and Greer [43] inspired us to 682 include requirements related to standards, laws and regulations. 683 The scope of the requirement dimension suggested by SWEBOOK 684 inspired us to include requirements related to third party compo- 685 nents e.g. COTS and requirements related to design and architecture 686 categories. 687 The analysis of the reasons of requirements changes presented 688 by Nurmuliani et al. [74] inspired us to add incorrect requirements 689 (mentioned as one of the reasons for requirements changes by 690 Nurmuliani et al.), ambiguous and inconsistent requirements cate- 691 gories. Both Harker et al. [42] and McGee and Greer [43] focused on 692 the changing nature of software requirements. The enduring 693 requirements type suggested by Harker et al. [42] inspired us to in- 694 clude requirements about the company’s organization and policies 695 category. The changing requirements category inspired us to include 696 functional requirements originated from customers, functional 697 requirements originated from end users and functional requirements 698 originated from developers categories. The customer hardware 699 change trigger of requirements changes listed by McGee and Greer 700 [43] inspired us to include hardware related requirements category. 701 The classification of software project requirements knowledge pre- 702 sented by Shan et al. [75] was reviewed but not used while creating 703 the categories. 704 According to the results depicted in Fig. 10, OSRs seem to belong 705 to the categories of Incorrect or misunderstood requirements (mean 706 3.88), Inconsistent requirements (mean 3.74), or Ambiguous 707 requirements (mean 3.72). While several studies focused on the 708 problem of inconsistencies between requirements, e.g., by

709proposing techniques to identify and remove inconsistencies 710[76], decomposing a requirements specification into a structure 711of ‘‘viewpoints’’ [77], or distributing development of specifications 712from multiple views [78], they did not study inconsistent require- 713ments as a potential source of OSRs. From a becoming obsolete 714standpoint, the level and quality of specification should not matter 715per se. However, if the lack of quality of a requirement’s specifica- 716tion is seen as an indicator of a lack of investment in the analysis 717and specification of the requirement, several possible scenarios 718could emerge. For example, practitioners in industry might have 719a gut feeling that certain requirements will become OSRs and thus, 720are not worth the effort. Another possibility is that OSRs are harder 721(require more effort and knowledge) to specify than other require- 722ments types, although, it could just as well indicate that most 723requirements are specified badly and thus are also OSRs. Further 724investigation is needed to investigate the potential reasons for 725the results achieved. The only thing we can say for certain is that 726requirements becoming obsolete seem to suffer from inadequacies 727in terms of correctness, consistency, and ambiguous specification. 728Interestingly, requirements from domain experts were consid- 729ered less likely to become obsolete than requirements from cus- 730tomers, end users, and developers respectively. One explanation 731could be that domain experts possess the knowledge and experi- 732ence of the domain, and thus their requirements may be less likely 733to change [79]. On the other hand, since the customers are the 734main source of software requirements and the main source of eco- 735nomic benefits to the company, their requirements are crucial to 736the success of any software project [80]. This implies that this cat- 737egory must be kept up to date and thus be less likely to become ob- 738solete. Another possible explanation could be that customer 739requirements are not as well or unambiguously specified as inter- 740nal requirements [80,29], resulting in a tendency of those require- 741ments to become obsolete faster or more frequently. 742Obsolescence of customer requirements, rather than internal 743requirements from domain experts, is confirmed by Wnuk et al. 744[8]. They reported that stakeholder priority dictates removal and 745postponement of the requirements realization, and domain experts 746are often part of the prioritization of all requirements. On the other 747hand, Kabbedijk et al. [81] reported that change requests from 748external customers are more likely to be accepted than change 749requests from internal customers. This might imply that some 750customer requirements are handled as change requests instead of 751as requirements input to development projects. In both cases, the

Fig. 10. Types of OSRs likely to become obsolete.

K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx 11

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

752 authors reported high requirements volatility, which is in line with 753 the study by Zowghi and Nurmuliani [26] who related obsolete 754 requirements related to requirements volatility. 755 According to our respondents, requirements related to stan- 756 dards, laws and regulations are the least likely to become obsolete, 757 which seems logical, as the lifetime of legislation and standards is 758 often long in comparison to customer requirements. Furthermore, 759 the low average score for the Requirements related to third party 760 components e.g. COTS (even lower than for the requirements related 761 to the company’s organization and policies) also seems to be logi- 762 cal, especially in relation to the results for RQ2 (Section 4.3) where 763 almost half of the respondents who considered OSRs to be Trivial 764 worked with IT or Computer and software services domain. We as- 765 sume, after Bano and Ikram [66], that COTS are used in the soft- 766 ware service domain. The results for the respondents who 767 worked with Outsourced projects (question 15 in [50]) are in accor- 768 dance with the overall results. 769 The differences between the respondents who worked with 770 Outsourced, MDRE and Bespoke or contract driven requirements engi- 771 neering projects in relation to the degree of obsolescence of COTS 772 requirements are subtle. This may suggest that other aspects not 773 investigated in this study could influence the results. Although 774 OSRs do not appear to be related to the main challenges of COTS 775 systems, i.e., the mismatch between the set of capabilities offered 776 by COTS products and the system requirements [82], the nature 777 of the COTS selection process, (e.g. many possible systems to con- 778 sider and possible frequent changes of the entire COTS solution), 779 may help to avoid OSRs. 780 Further analysis of the influence of the context factors indicates 781 that the respondents’ domains, company size, and methodologies 782 have minimal impact on the results. Not surprising, more respon- 783 dents who worked with projects running over longer time spans 784 graded Functional requirements originated from end users as Very 785 likely to become obsolete than respondents who worked with short 786 projects (8.7% of respondents who worked with projects <1 year 787 and 25.7% respondents who worked with projects >1 year). One 788 explanation could be that long projects, if deprived of direct and 789 frequent communication with their customers and exposed to rap- 790 idly changing market situations, can face the risk of working on 791 requirements that are obsolete from the users’ point of view. This 792 interpretation is to some extent supported by the results from RQ7 793 (Table 4) where the respondents graded MDRE contexts (character- 794 ized by limited possibilities to directly contact the end users and 795 continuously arriving requirements [2]) or Outsourced projects 796 (where communication is often done across time zones and large 797 distances [83]) as more affected by OSRs than bespoke contexts. 798 The success of Market-driven projects primarily depends on the 799 market response to the proposed products [2], which if released 800 with obsolete functionality, may simply be required by customers. 801 Thus, we believe that it is important to further investigate addi- 802 tional factors that could render Functional requirements originated 803 from end users obsolete.

804 4.5. Methods to identify OSRs (RQ4)

805 More than 50% of the answers pointed out that manual ways of 806 discovering OSRs are currently the primary method (Fig. 11). At the 807 same time, the context factors such as the different methodologies, 808 types of RE, length of the projects, roles of respondents and the do- 809 main that respondents worked in did not significantly affect the 810 top answer for this question. A total of 13.29% of all answers indi- 811 cated the presence of a predefined ‘‘obsolete’’ status. Furthermore, 812 11.19% of all answers (32 answers) were given to the category I 813 never found them or I never thought of finding them. Finally, less than 814 10% of all answers (24 answers) indicated the existence of any sort 815 of automation to identify OSRs.

816In the Other category, seven respondents mentioned that OSRs 817could be identified ‘‘by execution of test cases based on require- 818ments’’ or ‘‘during regression testing cycles’’. Further, three an- 819swers suggested ‘‘using requirements traceability matrix while 820testing the software’’ while three answers suggested improved 821communication ‘‘by discussion of user stories with stakeholders’’. 822Finally, one respondent suggested that goal-oriented requirements 823engineering makes ‘‘finding OSRs trivial’’. 824The answers from respondents who indicated using automated 825ways of discovering OSRs provided some names for the automated 826techniques, e.g., ‘‘customized system based on JIRA that takes OSRs 827into account by using special view filters’’, ‘‘traceability using 828DOORs to analyze for orphan and to track and status obsolete 829requirements’’, or ‘‘a tool called Aligned Elements to detect any 830inconsistencies including not implemented requirements’’. This 831would indicate that some tool support is present. However, tool 832efficiency and effectiveness was not part of this study. 833Further analysis indicated that the majority of respondents 834using tools of some sort worked with companies with >501 835employees (62%). This seems reasonable as large companies usu- 836ally have more money for tool support [65], and can even request 837especially tailored software from the requirements management 838tool vendors. The fact that automated methods to identify OSRs 839are rare among the smaller companies calls for further research 840into lightweight and inexpensive methods of OSR identification 841that can more easily be adapted in those companies. Furthermore, 842as both smaller and larger companies fall short in automation and 843assuming that larger companies can invest more money into edu- 844cation, this is probably not due to education either. 845More than half (15) of the respondents from the automated 846group also indicated that they identify OSRs manually. One expla- 847nation could be that automated methods are used together with 848manual methods, e.g., after the respondents manually mark 849requirements as obsolete or perform other preliminary analysis 850that enables automated sorting. Searching, tagging or filtering 851capabilities in their requirements management tools are most 852likely dominant and seen as automated in relation to OSRs, but this 853task is done in an ad hoc manner and not integrated with their 854requirements management process. Thus the ‘‘level of automation’’ 855needs further investigation. 856The reasonably high number of answers given to the category I 857never found them or I never thought of finding them is intriguing and 858needs further investigation. Thirty respondents from this group 859(93.8%) also indicated having no process for managing OSRs. This 860seems logical as the inability to find OSRs could be related to the 861lack of processes for managing OSRs. Further, the majority of the 862respondents that indicated never finding OSRs worked with pro- 863jects shorter than 12 months, and one fourth of them indicated 864having an ad hoc process for managing requirements. The rela- 865tively short project times were not an indication of OSRs not being 866an issue as >80% of these same respondents indicated OSRs as 867being a Serious or Very serious issue. The absence of a defined and 868repeatable process might be a better indicator for not identifying 869OSRs in this case. In addition, waterfall was represented in more 870than 11% of the cases, while only about 6% worked in an agile 871manner. 872Neither organizational size nor development methodology were 873statistically significant factors in terms of how OSRs were 874discovered or identified (Table A.5 in [61]). However, a statistically 875significant relationship was identified in relation to the top five 876methodologies and how OSRs were identified (chi-square test 877p < 0.004, Table A.5a in [61]). This result could be explained by 878the following: (1) respondents who worked with waterfall 879methodology admitted more often to never finding OSRs (11%) 880than respondents who worked with agile methodologies (3.8%), 881(2) more respondents who worked with RUP methodology (34%)

12 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

882 selected the option I have a predefined status called obsolete than 883 respondents who worked with agile methodology (10%). Looking 884 further, we could also see that the majority of the respondents 885 who worked with RUP or Prototyping methodologies also worked 886 with companies with >201 employees. This would seem to indicate 887 that within the two mentioned methodologies it is possible to 888 implement tool support for identification of OSRs. It is worth men- 889 tioning that a statistically significant relationship was also 890 achieved between the top five methodologies and the results for 891 choice of OSR definition (p-value 0.011, Table A.2a in [61]) and Sec- 892 tion 4.3. The results suggest that the respondents who worked with 893 the RUP methodology may have a different opinion about the def- 894 inition of OSRs and more frequently use a predefined status called 895 obsolete to identify OSRs. 896 Looking at the types of requirements engineering used, the re- 897 sults showed that the respondents who work with Bespoke or con- 898 tract driven requirements engineering did not use predefined 899 categories for OSRs; it was not part of their standard procedure 900 to sort out OSRs. This seems to be logical as the majority of the 901 respondent who admitted to never finding OSRs worked with be- 902 spoke or contract-driven projects. Finally, only one respondent 903 mentioned automatic methods of finding OSRs. 904 For the context factor of project length, longer projects have 905 more automated ways of identifying OSRs (the difference is about 906 5%) than shorter projects. This seems reasonable as longer projects 907 usually invest more into project infrastructure and project man- 908 agement tools and processes. However, a large part of the longer 909 projects respondents also indicated manual methods of identifying 910 OSRs (about 60% for projects >1 year). In comparison, subjects 911 typically working in shorter projects used more tool supported 912 automated methods (about 52% for projects <1 year). Thus the 913 respondents working in longer projects did see the point of, and 914 did try to, identify OSRs to a larger extent than the ones working 915 in shorter duration projects, although manual methods dominated. 916 The analysis of the influence of the respondents’ roles on the 917 results revealed only minimal differences. Among the interesting 918 differences, project and product managers respondents gave no 919 answers in the I never found them category. This may indicate that 920 they always find OSRs. Further, the management roles had the 921 highest score for manual identification of OSRs. This result might 922 indicate that management is, to some extent, more aware of the 923 need for finding OSRs which may severely impede the project 924 efforts. However, tool support is often lacking.

9254.6. Handling of identified obsolete software requirements (RQ5)

926More than 60% of the answers (results for multiple answer 927questions are calculated based on all the answers) indicated that 928the respondents kept the OSRs but assigned them a status called 929‘‘obsolete’’ (see Fig. 12). This might indicate that OSRs are a useful 930source of information about the history of the software product for 931both requirements analyst and software development roles. More- 932over, 21.9% of all answers (66) suggested moving OSRs into a sep- 933arated section in requirements documents. These views were the 934most popular among the respondents regardless of their role, 935methodology, domain, size, project length and context. One could 936interpret this response as indicating that the most suitable way 937to manage identified OSRs is to classify them as obsolete, supplying 938rationale, and move them into a separated section or document or 939SRS. However, maintaining traceability links between OSRs and 940other requirements could prove work intensive, especially if end- 941to-end traceability is required [64]. Regnell et al. [51] discuss scal- 942able methods for managing requirements information where effec- 943tive grouping of requirements e.g., placing semantically similar 944requirements in the same module, could enable more efficient 945maintenance of large structures of requirements (although OSRs 946were not mentioned specifically). 947Looking at the answers given the Other category, two answers 948suggested informing the stakeholders about assigning a require- 949ment an obsolete status. Furthermore, two respondents suggested 950to ‘‘hide and tag requirements that are obsolete using require- 951ments management tools’’. Interestingly, one respondent ques- 952tioned ‘‘why would you spend time in on dealing with not 953needed things’’. Since this person worked with a very small com- 954pany with about 20 employees, we assume that the problem of 955overloaded database with legacy requirements is not known to this 956person. Finally, the other answers in this category mostly sug- 957gested keeping OSRs and optionally writing the justification. 958Most of the answers in the Other category (�6%, 20 answers) 959suggested either removing OSRs, or keeping them, but moving 960them to a separated section or module in the database. Only �9% 961of answers (26) suggested deleting the OSRs from the require- 962ments database or document. This suggests that most respondents 963think OSRs should be stored for reference and traceability reasons. 964However, keeping OSRs appears to be inconsistent with recom- 965mended practice for reducing the complexity of large and very 966large projects [51,84], and handling information overload as high-

Fig. 11. Methods used to identify OSRs.

K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx 13

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

967 lighted by Regnell et al. [51]. The desired behavior in large and very 968 large projects would seem to indicate the removal of unnecessary 969 requirements to decrease the complexity of the requirements 970 structure and traceability links. One possible avenue for further 971 investigation is to evaluate the value of keeping OSRs. 972 Of the group who opted for OSRs deletion upon identification, 973 the majority of the answers came from respondents who worked 974 with large companies (>501 employees, 77%) and long projects 975 (>12 months, 53.9%). Moreover, a majority of these respondents 976 considered OSRs to be Serious or Somehow serious (Section 4.3). 977 On the contrary, respondents that worked in smaller companies 978 opted to keep OSRs. 979 Analysis revealed a lack of statistically significant relationships 980 between the answers for this question (Fig. 12) and and the 981 respondents’ roles, domains, organizational size and, methodolo- 982 gies used (Table A.6 in [61]). However, some indications could be 983 observed. Respondents working in the engineering domain seemed 984 to prefer the deletion of OSRs compared to respondents from other 985 domains. One possible explanation could be that since the projects 986 in the engineering domain are highly regulated, and often require 987 end-to-end traceability [64], keeping OSRs in the scope could clut- 988 ter the focus threatening to impede requirements and project man- 989 agement activities. 990 Type of requirements engineering factor turned out to have a 991 minimal impact on the results regarding this question. However, 992 one observation worth mentioning is that more support was given 993 to the option of removing OSRs among the respondents who 994 worked with Bespoke or contract driven requirements engineering 995 (12.3%) than respondents who worked in MDRE (9.2% of answers). 996 This appears to be logical as, in bespoke projects, obsolete require- 997 ments could be discarded after the contract is fulfilled. In market- 998 driven projects they could be kept and later used during the 999 requirements consolidation task, where new incoming require-

1000 ments could be examined against already implemented or ana- 1001 lyzed requirements which include OSRs [85].

1002 4.7. Context factors and obsolete software requirements (RQ6 and 1003 RQ7)

1004 4.7.1. Obsolete software requirements and project size 1005 The respondents were asked to indicate to what extent the phe- 1006 nomenon of OSRs would potentially (negatively) impact a project,

1007and whether project size had anything to do with the likelihood of 1008negative impact. The respondents used a Likert scale from 1 (Not 1009likely impact) to 5 (a Very likely impact). The results are presented 1010in Tables 3 and 4 below. The size classification is graded in relation 1011to number of requirements and interdependencies, inspired by 1012Regnell et al. [51]. 1013Column 7 in Table 3 presents the average rating for each project 1014size. We see that the larger the project, the more likely there will 1015be a negative effect from OSRs. Looking at Table 3 for Small-scale 1016requirements projects, most respondents deemed OSR impact as 1017Not likely (35.3%) or Somewhat likely (35.8%). However, moving 1018up just one category to Medium-scale requirements projects with 1019hundreds of requirements, the respondents indicated the impact 1020as being Likely (41.5%). The trend continues with More than likely 1021(32.7) for Large-scale requirements projects, and Very likely for Very 1022large-scale requirements projects (38.9%). The results confirm the 1023viewpoint of Herald et al. [20] who listed OSRs as one of the risks 1024in large integrated systems. 1025One interesting observation is that the results could be seen as 1026potentially contradictory to the results from questionnaire ques- 1027tion 2 (Section 4.3) where the respondents who worked in larger 1028companies (over 100 employees) graded the overall impact of OSRs 1029slightly lower than respondents from smaller companies. However, 1030since large companies often have large databases of requirements 1031[51] and often run projects with several thousands of requirements 1032[86], this would suggest that there are other factors that influence 1033the impact of OSRs. 1034When it comes to the influence of methodology used by our 1035respondents, we report that the respondents who used Agile soft- 1036ware development methodology primarily graded OSRs as only 1037Likely to affect Large-scale requirements projects, while respondents 1038who used Waterfall methodology primarily graded the impact of 1039OSRs as More likely. Interestingly, this result seems to contradict 1040the results for RQ2 (Section 4.3), where the majority of respon- 1041dents who considered OSRs Very serious worked in large companies 1042and used agile or incremental methodologies. This might indicate 1043that the size of the project is not more dominant than the size of 1044the company, and the methodology used. This requires further 1045investigation. 1046The respondents who worked with bespoke or contract driven 1047requirements engineering primarily graded the effect of OSRs on 1048Large-scale requirements projects as Likely. On the contrary, the

Fig. 12. Methods used to manage identified OSRs.

14 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

1049 respondents who worked with Market-driven projects primarily 1050 graded the impact of OSRs on Large-scale requirements projects as 1051 Very Likely. This result confirms the results for RQ2 (Section 4.3) 1052 where OSRs were also graded less serious by respondents who 1053 worked in bespoke contexts. Finally, for the Very large-scale 1054 requirements projects our respondents primarily graded the impact 1055 of OSRs as Very likely regardless of context factors.

1056 4.7.2. Obsolete software requirements and project types 1057 The respondents were also asked to rate how likely it was that 1058 OSRs affected various project types (on a scale from 1 to 5, where 1 1059 is Not likely, and 5 is Very likely). The results for the average rating 1060 (column 7 in Table 4) indicate that Outsourced projects are the most 1061 likely to be affected by OSRs (average rating 3.43). One possible 1062 explanation for this result could be the inherited difficulties of fre- 1063 quent and direct communication with customers and end users in 1064 Outsourced projects. Moreover, as communication in Outsourced 1065 projects often needs to be done across time zones and large dis- 1066 tances [83,87], the risk of requirements misunderstanding in- 1067 creases, and as we have seen (Section 4.4), inadequately specified 1068 requirements run a higher risk of becoming OSRs. 1069 The high average rating for the Market-driven projects (average 1070 scope 3.19) can be explained by the inherited characteristics of 1071 the MDRE context where it is crucial to follow the market and cus- 1072 tomer needs and the direct communication with the customer may 1073 be limited [2]. This in turn can result in frequent scope changes [8] 1074 that may render requirements obsolete. Finally, it is worth 1075 mentioning that the gap between the Market-driven projects and 1076 Bespoke projects (average score 2.78) is wider than between 1077 Outsourced (average scope 3.43) and Market-driven projects 1078 (average score 3.19). One possible explanation could be that both 1079 Market-driven projects and Outsourced projects suffer similar diffi- 1080 culties in directly interacting with the end users or customers 1081 [2,83] and thus the risk of requirements becoming obsolete could 1082 be higher. 1083 The results for all the categories and scales are presented in col- 1084 umns 2–6 in Table 4. Our respondents primarily graded the impact 1085 of OSRs on Market-driven projects and Outsourced projects as Likely 1086 and only Somehow likely for Bespoke projects. Interestingly, the an- 1087 swer Very likely did not receive top scores for any of the three types 1088 of projects. This would seem to indicate that the ‘‘project type’’ fac- 1089 tor is less dominant in relation to OSRs than the ‘‘size’’ of the pro- 1090 ject discussed earlier in this section. 1091 Since the statistical analysis between the results from the ques- 1092 tion and the context variables revealed no significant relationships, 1093 we performed descriptive analysis of the results. The respondents 1094 who indicated having a managerial role (32.7%) primarily graded 1095 the impact of OSRs on the Market-driven projects as More than

1096likely, while the requirements analysts primarily graded this 1097impact as only Likely. Similar to this result are the results for 1098RQ2 (Section 4.3) where the managers primarily considered OSRs 1099as Serious while requirements analysts predominantly considered 1100it Somehow serious. The comparison is, however, not straight for- 1101ward as in case of RQ2 where respondents were grading all types 1102of requirements projects, not only Bespoke projects. Finally, the 1103opinions of software development and management roles are 1104aligned when grading the impact of OSRs on bespoke projects 1105(the majority of the respondents from both roles graded the impact 1106as Somehow likely). 1107In relation to project duration, interestingly, respondents who 1108worked with smaller companies (<200 employees) more often 1109graded the effect of OSRs on Bespoke projects, Market-driven projects 1110or Outsourced projects as Likely or even Very likely. The majority of 1111the respondents who worked for companies with >201 employees 1112selected the Somehow likely answer for the Bespoke projects and 1113Market-driven projects. This result confirms the previous analysis 1114(Section 4.7.1) by indicating that size is not the only factor that im- 1115pacts the seriousness of OSRs. It can also be speculated that the 1116phenomenon of OSRs might be clearer in smaller organizations 1117where less specialization makes outdated requirements more 1118‘‘everybody’s concern’’, while in larger organizations, with high 1119specialization, the view of ‘‘not my job’’ might play a factor [64].

11204.8. Where in the requirements life cycle should OSRs be handled (RQ7)

1121The results for this question are presented in Fig. 13 as percent- 1122ages of the total number of answers (717) since the question al- 1123lowed multiple answers. The list of phases (or processes) in the 1124requirements engineering lifecycle was inspired by Nurmuliani 1125and Zowghi [26]. According to our respondents OSRs should first 1126be handled during Requirements analysis, Requirements validation 1127and Requirements changes phases (each with about 14% of the an- 1128swers). This result is, to some extent in line with the study by Mur- 1129phy and Rooney [13], SWEBOK [40], and Nurmuliani and Zowghi 1130[26] who report that change leads to volatility, and volatility in 1131its turn leads to obsolescence. However, less than 5% of the survey 1132respondents indicate that OSRs should be managed as a part of 1133chandling requirements volatility seems to support a distinction 1134between volatility and the phenomenon of OSRs as such. That is, 1135volatility may be related to OSRs; however, it needs to be handled 1136continuously during analysis and validation as a part of change 1137management in general. 1138The high numbers of answers given to Requirements analysis 1139(14.5%) and Requirements specification (9.2%) phases confirm the 1140suggestions made by Savolainen et al. [17] to manage OSRs in 1141the requirements analysis phases. The low score in the Require-

Table 3 OSRs effect on project size (215/219 respondents).

(1) Not likely (2) Some-what likely (3) Likely (4) More than likely (5) Very likely Rating average

Small-scale (�10 of req.) 35.3% (76) 35.8% (77) 13.5% (29) 7.0% (15) 8.4% (18) 2.17 Medium-scale (�100 of req.) 9% (19) 31.6% (67) 41.5% (88) 16.0% (34) 1.9% (4) 2.70 Large-scale (�1000 of req.) 3.8% (8) 17.1% (36) 31.3% (66) 32.7% (69) 15.2% (32) 3.38 Very large-scale (>10,000 of req.) 8.1% (17) 12.8% (27) 16.6% (35) 23.7% (50) 38.9% (82) 3.73

Table 4 How likely OSRs affect various project types (215/219 respondents).

(1) Not likely (2) Some-what likely (3) Likely (4) More than likely (5) Very likely Rating average

Bespoke projects 14.4% (31) 32.1% (69) 26% (56) 16.3% (35) 11.2% (24) 2.78 Market-driven projects 6.5% (14) 20% (43) 35.8% (77) 23.3% (50) 14.4% (31) 3.19 Outsourced projects 2.3% (5) 16.4% (35) 35.7% (76) 27.2% (58) 18.3% (39) 3.43

K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx 15

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

1142 ments elicitation phase answer (6.42% of all answers) contradicts 1143 the viewpoint of Merola [15] who suggested managing obsolete 1144 software by continuous and timely market tracking and market 1145 trend change identification. This might seem to indicate that our 1146 respondents have difficulties understanding how OSRs could be 1147 managed, for example by finding and dismissing OSRs faster due 1148 to continuous elicitation depending on the accepted definition of 1149 OSRs. 1150 Respondents working with Agile software development method- 1151 ologies preferred to handle OSRs as a part of the Requirements 1152 changes phase, while respondents working in a Waterfall manner 1153 preferred the Requirements validation phase. This seems logical, 1154 as a part of agile methodology is to embrace change [4], while 1155 waterfall philosophy sees OSRs as something to be ‘‘handled’’ more 1156 formally in a development step (focusing on the specification and 1157 validation phases) [30]. 1158 Type of requirements engineering context (Fig. 7) did not seem 1159 to significantly influence answers for this question. Requirements 1160 analysis, validation, and changes phases seemed to be dominant 1161 for MDRE and Bespoke or contract driven requirements engineering 1162 alike. However, looking at company size and project duration, 1163 respondents from larger companies with longer projects focused 1164 on handling OSRs in specific phases, i.e., analysis and validation. 1165 This result seems reasonable as large projects usually require more 1166 extensive requirements analysis due to, e.g., the larger number of 1167 stakeholders involved and possible higher complexity of the sys- 1168 tem to be developed [51,64,84]. 1169 Looking at the answers given in the Other category, four 1170 answers suggested that OSRs should be managed in all phases of 1171 software lifecycle: one answer suggested all requirements 1172 management phases and one suggested quality assurance. Further 1173 investigation is needed.

1174 4.9. Existing processes and practices regarding managing OSRs (RQ5)

1175 When queried about the existing processes and practices for 1176 managing OSRs, 73.6% of all respondents (159) indicated that their 1177 requirements engineering process does not take OSRs into consid- 1178 eration. This result can be interpreted as clear evidence of a lack of 1179 methods regarding OSRs in industry and confirms the need for 1180 developing methods for managing OSRs. At the same time, some 1181 processes for managing OSRs do exist, as indicated by 26.4% (57)

1182of our respondents. The list of processes and methods used by 1183our respondents include:

1184� Reviews of requirements and requirements specifications (19 1185respondents) 1186� Using tools and ‘‘marking requirements as obsolete’’ (6 1187respondents) 1188� Requirements traceability (6 respondents) 1189� Discussing and prioritizing requirements with customers in an 1190agile context (4 respondents) 1191� ‘‘Mark obsolete requirements as obsolete’’ (4 respondents)— 1192these respondents did not indicate if using a tool or not. 1193� During the requirements management process by identifying 1194OSRs (3 respondents) 1195� Moving OSRs into a separated section in the SRS (3 respondents) 1196� Through a change management process (2 respondents) 1197� During the requirements analysis process (1 respondent) 1198� Having a proprietary process (1 respondent) 1199

1200The identified ‘‘categories’’ of processes and methods above 1201provide further support for previous results from the survey. For 1202example, the process of managing OSRs by requirements reviews 1203overlaps the most popular way to identify OSRs (Fig. 11, Section 12044.5), as indicated by our respondents. This would seem to indicate 1205that manually reviewing requirements is dominant. Whether or 1206not this is sufficient is another question which needs to be investi- 1207gated further. The results confirm what was reported in Section 12084.5, that automated methods for identification and management 1209of OSRs are rare. Therefore, further research on scalable automatic 1210methods for identification and management of OSRs is needed. 1211Some respondents provided names or descriptions of processes 1212and methods used for managing OSRs. Those reported include:

1213� Projective analysis through modeling—Considered as a promising 1214approach to study the complexity pertaining to systems of sys- 1215tems [88], it requires a skilled ‘‘process modeler’’ to seamlessly 1216use the modeling paradigm. If and how the method could be 1217applied for smaller projects, and particularly for identification 1218and management of OSRs remains an open question. Also, the 1219technique is used during the requirements analysis phase 1220which has been considered a good phase for management of 1221OSRs by our respondents (Fig. 13).

Fig. 13. Requirements lifecycle stages for addressing OSRs.

16 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

1222 � Hierarchical requirements’ tables—Specifying requirements on 1223 different abstraction levels is one of the fundamental tech- 1224 niques of requirements engineering that helps various stake- 1225 holders to understand requirements better [29]. Considered as 1226 one of the requirements specification techniques, this could 1227 be promising according to our respondents (Fig. 13). This 1228 method could be used to control OSRs to a certain degree as 1229 an overview of the requirements can be achieved, to some 1230 extent, through abstraction [80]. However, given large numbers 1231 of requirements, scalability of the method could be a problem. 1232 � Project governance—Support project control activities consider- 1233 ing the environment in which project management is per- 1234 formed [89]. By having greater time scope than ordinary 1235 project management, project governance could, according to 1236 our interpretation, be supportive in the task of continuous iden- 1237 tification and management of OSRs. 1238 � Requirements tracking with risk management—Although we con- 1239 sider tracking and risk management [29] as separated activities, 1240 combining them for the purpose of managing OSRs is an inter- 1241 esting alternative potential. In particular, the role of risk man- 1242 agement in identification and management of OSRs should be 1243 further investigated, as the software risk management literature 1244 does not appear to mention OSRs as one of the software risks 1245 [90]. 1246 � Requirements-based test plans—Aligning requirements with ver- 1247 ification, although challenging, could be considered critical in 1248 assuring that the developed software fulfills customers’ needs. 1249 Creating test plans based on requirements that are up-to-date 1250 and properly reflect changing customer needs is considered a 1251 best practice in software projects [91]. OSRs may create mis- 1252 matches and problems with alignment between requirements 1253 and test cases. The discovery of a test result that was correct, 1254 however presently wrong, can indicate that a requirement has 1255 become obsolete. We are, however, uncertain to what degree 1256 the practice ofwriting test plans based on requirements could 1257 help in identification and management of OSRs. The fact that 1258 test plans are based on requirements is, to us, independent of 1259 the fact that these requirements may simply be obsolete. 1260 � Commenting out obsolete code and updating requirements docu- 1261 ments accordingly—This technique of managing OSRs could be 1262 considered promising and should help to keep the requirements 1263 aligned with the newest version of the code. However, the 1264 technique seems to only consider implemented requirements 1265 that could be directly traced to the code level. Given the fact 1266 that many requirements (especially quality requirements) are 1267 cross-cutting and require implementation in several places 1268 [29] in the source code, an OSR may become even more cross 1269 cutting than before. In our opinion, it could be challenging to 1270 correctly map changes in the code to changes in requirements. 1271 Thus, mapping change in the code to changes in requirements 1272 could be part of a solution; however, it lacks the possibility to 1273 identify and remove OSRs prior to implementation. 1274 � Using requirements validation techniques to identify if require- 1275 ments are no longer needed—Validating requirements is funda- 1276 mental for assuring that the customer needs were properly 1277 and correctly understood by the development organization 1278 [29]. In our opinion, this technique should be used together 1279 with customers who can confirm if the requirements are 1280 relevant. Our respondents also would like OSRs to be managed 1281 during requirements validation phase (Fig. 13). However, if 1282 requirements reviews are conducted in isolation from ‘‘custom- 1283 ers’’ by e.g., requirements analysts, they could have difficulties 1284 in identifying which requirements are, or are about to become, 1285 obsolete. This is further aggravated if the development 1286 organization operates in a MDRE context.

1287

1288Looking at the context factors of organizational size, develop- 1289ment methodology, and respondent role, although no statistically 1290significant correlations could be observed, some interesting points 1291warrant mentioning. Respondents from smaller companies (<50 1292employees) to a larger degree had explicit practices for handling 1293OSRs as compared to respondents from larger companies. This 1294seems reasonable when looking at the methods for managing 1295OSRs provided, where manual review methods were most fre- 1296quent. Quispire et al. [65] mentioned that processes used in small 1297software enterprises are often manually based and less 1298automated. 1299Respondents who worked with MDRE projects (Fig. 7) reported 1300having processes that take OSRs into consideration (34.3%), more 1301often than respondents who worked with Bespoke or contract dri- 1302ven requirements engineering (26.5%) or Outsourced projects 1303(15.8%) respectively (almost significant results with a p-value of 13040.059, Table A.8a in [61]). One possible explanation for this could 1305be high and constant requirements influx in MDRE contexts 1306[2,51], combined with frequent changes to requirements dictated 1307by rapidly changing market situations. This in turn is resulting in 1308more requirements becoming obsolete, forcing the use of methods 1309to manage OSRs. 1310Further statistical tests (Table A.8 in [61]) indicated a statistical 1311significance between the roles of respondents and the existence of 1312processes to manage OSRs (p = 0.0012). There was also a moderate 1313association (Cramer’s V = 0.345) between the respondents’ roles 1314and the existence of requirements engineering processes that take 1315OSRs into account. From the cross-tabulation table between the 1316respondents’ roles and the existence of OSRs handling process (Ta- 1317ble A.9 in [61]) we can see that the respondents who worked in 1318management positions (project and product managers) were more 1319likely to utilize OSRs handling method compared to respondents 1320who worked in software development roles, as developers. 1321Further, the presence of a method or process that considers 1322OSRs seems to decrease the negative impact of OSRs among our 1323respondents, as 50% of the respondents who deemed OSRs Trivial 1324confirmed having a process of managing OSRs (Section 4.3). More- 1325over, as requirements engineers as well as product and project 1326managers usually work more with requirements engineering re- 1327lated tasks than software development roles, it appears to be logi- 1328cal that more methods of managing OSRs are reported among the 1329management roles.

13304.10. Summary of results

1331The results from the study are summarized in the following 1332points:

1333� Our respondents defined an OSR (RQ1) as: ‘‘a software require- 1334ment (implemented or not) that is no longer required for the 1335current release or future releases, and it has no or little business 1336value for the potential customers or users of a software arti- 1337fact.’’ This definition seems to be homogeneous among our 1338respondents (with a small exception for the respondents who 1339used RUP methodologies). 1340� OSRs constitute a significant challenge for companies develop- 1341ing software intensive products, with the possible exception 1342of companies involved in the service domain. The phenomenon 1343of OSRs is considered serious by 84.3% of our respondents 1344(RQ2). At the same time 73.6% of our respondents reported hav- 1345ing no process for handling obsolete software requirements 1346(RQ5). 1347� Requirements related to standards and laws are the least likely 1348to become obsolete, while inconsistent and ambiguous require- 1349ments are the most likely to become obsolete (RQ3). Moreover,

K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx 17

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

1350 requirements originating from domain experts were less likely 1351 to become obsolete than requirements originating from cus- 1352 tomers or (internal) developers. 1353 � OSRs identification is predominantly a manual activity, and less 1354 than 10% of the respondents reported having any automated 1355 functionality. They also confirmed that automatic identification 1356 of OSR is difficult which suggests research opportunities in cre- 1357 ating automated methods for OSR identification and manage- 1358 ment (RQ4). 1359 � The identified OSRs should, according to more than 60% of the 1360 survey answers, be kept in the requirements document or the 1361 database, but tagged as obsolete. Deleting OSRs is not a desired 1362 behavior (RQ5). Most respondents opted for keeping the OSRs 1363 for purposes of reference and traceability, which seems to indi- 1364 cate that the identification of OSRs is not the only action, but a 1365 wish to potentially use the OSRs to minimize repeated work 1366 (e.g. specifying new requirements that are the same or similar 1367 to already identified OSRs). This is especially relevant in the 1368 MDRE context where ‘‘good ideas’’ can resurface as proposed 1369 by, for example internal developers. 1370 � Although there exist some methods and tool support for the 1371 identification and handling of OSRs, a clear majority of the 1372 respondents indicated no use of methods or tools to support 1373 them. Rather, ad hoc and manual process seemed to dominate 1374 (RQ5). Moreover, even when the identification of OSRs was 1375 deemed central (e.g., for respondents working in longer dura- 1376 tion projects), only some tool support and automation was pres- 1377 ent (mostly for bespoke projects), but even here manual 1378 processes and routines dominated (Section 4.5). 1379 � Project managers and product managers indicate that they 1380 always find OSRs in their work (Section 4.5), even if many of 1381 the respondents do not actively look for them. 1382 � OSRs are more likely to affect Large-scale requirements and Very 1383 large-scale requirements projects (RQ6). Larger projects (hun- 1384 dreds of requirements) tend to have larger issues related to 1385 the presence of OSRs, and there seems to be a correlation 1386 between impact severity and project size (amount of require- 1387 ments). OSRs seem to have a somewhat larger impact on pro- 1388 jects in a MDRE context as compared to bespoke or contract 1389 driven development (Section 4.7.2). However, for very-large 1390 projects (over 10,000 requirements) all respondents, indepen- 1391 dent of context factors, agree that the potential impact of OSRs 1392 was substantial. 1393 � According to the respondents, OSRs should first of all be han- 1394 dled during the Requirements analysis and Requirements valida- 1395 tion phases (RQ7). At the same time, less than 5% of the 1396 answers indicate that OSRs should be managed as a part of 1397 requirements volatility handling which supports the distinction 1398 between volatility and the phenomenon of OSRs as such. 1399 Finally, our respondents suggested that Requirements elicitation 1400 is not the best phase to manage OSRs. 1401 � Latency may not be the main determinant of OSRs becoming a 1402 problem. Rather, the results point to the lack of methods and 1403 routines for actively handling OSRs as a central determinant. 1404 This would imply that claimed low latency development mod- 1405 els, like agile, has and can have problems with OSRs. 1406

1407 5. Conclusions and further work

1408 Although the phenomenon of obsolete software requirements 1409 and its negative effects on project timelines and the outcomes have 1410 been reported in a number of publications [9,13–15,7], little empir- 1411 ical evidence exists that explicitly and exhaustively investigates 1412 the phenomenon of OSRs. 1413 In this paper, we report results from a survey conducted among 1414 219 respondents from 45 countries exploring the phenomenon of

1415OSRs by: (1) eliciting a definition of OSRs as seen by practitioners 1416in industry, (2) exploring ways to identify and manage OSRs in 1417requirements documents and databases, (3) investigating the po- 1418tential impact of OSRs, (4) exploring effects of project context fac- 1419tors on OSRs, and (5) defining what types of requirements are most 1420likely to become obsolete. 1421Our results clearly indicate that OSRs are a significant challenge 1422for companies developing software systems—OSRs were consid- 1423ered serious by 84.3% of our respondents. Moreover, a clear major- 1424ity of the respondents indicated no use of methods or tools to 1425support identification and handling OSRs, and only 10% of our 1426respondents reported having automated support. This indicates 1427that there is a need for developing automated methods or tools 1428to support practitioners in the identification and management of 1429OSRs. These proposed methods need to have effective mechanisms 1430for storing requirements tagged as OSRs, enabling the use of the 1431body of OSRs as decision support for future requirements and their 1432analysis. This could potentially enable automated regression anal- 1433ysis of active requirements, continuously identifying candidates for 1434OSRs, and flagging them for analysis. 1435Although manually managing OSRs is currently the dominant 1436procedure, which could be sufficient in small projects, research ef- 1437fort should be directed towards developing scalable methods for 1438managing OSRs—methods that scale to a reality that is often char- 1439acterized by large numbers of requirements and a continuous and 1440substantial influx of new requirements. The reality facing many 1441product development organizations developing software intensive 1442systems today is that OSRs are a problem, and as the amount and 1443complexity of software increases so will the impact of OSRs.

1444References

1445[1] M. DeBellis, C. Haapala, User-centric software engineering, IEEE Exp. 10 (1) 1446(1995) 34–41, http://dx.doi.org/10.1109/64.391959. 1447[2] B. Regnell, S. Brinkkemper, Market-driven requirements engineering for 1448software products, in: A. Aurum, C. Wohlin (Eds.), Engineering and Managing 1449Software Requirements, Springer, Berlin Heidelberg, 2005, pp. 287–308. 1450[3] T. Gorschek, S. Fricker, K. Palm, S. Kunsman, A lightweight innovation process 1451for software-intensive product development, IEEE Softw. 27 (1) (2010) 37–45, 1452http://dx.doi.org/10.1109/MS.2009.164. 1453[4] B. Ramesh, L. Cao, R. Baskerville, Agile requirements engineering practices and 1454challenges: an empirical study, Inf. Syst. J. 20 (5) (2010) 449–480. 1455[5] T. Gorschek, M. Svahnberg, A. Borg, A. Loconsole, J. Börstler, K. Sandahl, M. 1456Eriksson, A controlled empirical evaluation of a requirements abstraction 1457model, Inf. Softw. Technol. 49 (2007) 790–805, http://dx.doi.org/10.1016/ 1458j.infsof.2006.09.003. 1459[6] T. Gorschek, P. Garre, S.B.M. Larsson, C. Wohlin, Industry evaluation of the 1460requirements abstraction model, Requir. Eng. 12 (2007) 163–190, http:// 1461dx.doi.org/10.1007/s00766-007-0047-z. <http://dl.acm.org/citation.cfm?id= 14621391227.1391230>. 1463[7] L. Cao, B. Ramesh, Agile requirements engineering practices: an empirical 1464study, IEEE Softw. 25 (1) (2008) 60–67, http://dx.doi.org/10.1109/MS.2008.1. 1465[8] K. Wnuk, B. Regnell, L. Karlsson, What happened to our features? Visualization 1466and understanding of scope change dynamics in a large-scale industrial 1467setting, in: 17th IEEE International Requirements Engineering Conference, RE 1468’09, 2009, pp. 89–98. http://dx.doi.org/10.1109/RE.2009.32. 1469[9] C. Hood, S. Wiedemann, S. Fichtinger, U. Pautz, Requirements Management The 1470Interface Between Requirements Development and All Other Systems 1471Engineering Processes, Springer, Berlin, 2008, http://dx.doi.org/10.1007/978- 14723-540-68476-3. 1473[10] J. Chen, R. Reilly, G. Lynn, The impacts of speed-to-market on new product 1474success: the moderating effects of uncertainty, IEEE Trans. Eng. Manag. 52 (2) 1475(2005) 199–212, http://dx.doi.org/10.1109/TEM.2005.844926. 1476[11] C. Wohlin, M. Xie, M. Ahlgren, Reducing time to market through optimization 1477with respect to soft factors, in: Proceedings of 1995 IEEE Annual International 1478Engineering Management Conference, Global Engineering Management: 1479Emerging Trends in the Asia Pacific, 1995, pp. 116–121. http://dx.doi.org/ 148010.1109/IEMC.1995.523919. 1481[12] P. Sawyer, Packaged software: challenges for re, in: Proceedings of the Sixth 1482International Workshop on Requirements Engineering: Foundations of 1483Software Quality (REFSQ 2000), 2000, pp. 137–142. 1484[13] D. Murphy, D. Rooney, Investing in agile: aligning agile initiatives with 1485enterprise goals, Cutter IT J. 19 (2) (2006) 6–13. 1486[14] J. Stephen, J. Page, J. Myers, A. Brown, D. Watson, I. Magee, System Error Fixing 1487the Flaws in Government It, Tech. Rep. 6480524, Institute for Government, 1488London, 2011.

18 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

1489 [15] L. Merola, The cots software obsolescence threat, in: Fifth International 1490 Conference on Commercial-off-the-Shelf (COTS)-Based Software Systems, 1491 2006, p. 7. http://dx.doi.org/10.1109/ICCBSS.2006.29. 1492 [16] C. Hood, S. Wiedemann, S. Fichtinger, U. Pautz, Requirements Management: 1493 The Interface Between Requirements Development and All Other Systems 1494 Engineering Processes, Springer-Verlag, Berlin, 2008. 1495 [17] J. Savolainen, I. Oliver, M. Mannion, H. Zuo, Transitioning from product line 1496 requirements to product line architecture, in: 29th Annual International 1497 Computer Software and Applications Conference, COMPSAC, vols. 1 and 2, 1498 2005, pp. 186–195. http://dx.doi.org/10.1109/COMPSAC.2005.160. 1499 [18] F. Loesch, E. Ploederoeder, Restructuring variability in software product lines 1500 using concept analysis of product configurations, in: 11th European 1501 Conference on Software Maintenance and Reengineering, CSMR ’07, 2007, 1502 pp. 159–170. http://dx.doi.org/10.1109/CSMR.2007.40. 1503 [19] M. Mannion, O. Lewis, H. Kaindl, G. Montroni, J. Wheadon, Representing 1504 requirements on generic software in an application family model, in: 1505 Proceedings of the 6th International Conerence on Software Reuse: Advances 1506 in Software Reusability, Springer-Verlag, London, UK, 2000, pp. 153–169. 1507 <http://dl.acm.org/citation.cfm?id=645546.656064>. 1508 [20] T. Herald, D. Verma, C. Lubert, R. Cloutier, An obsolescence management 1509 framework for system baseline evolution perspectives through the system life 1510 cycle, Syst. Eng. 12 (2009) 1–20, http://dx.doi.org/10.1002/sys.v12:1. <http:// 1511 dl.acm.org/citation.cfm?id=1507335.1507337>. 1512 [21] S. Robertson, J. Robertson, Mastering the Requirements Process, ACM Press/ 1513 Addison-Wesley Publishing Co., New York, NY, USA, 1999. 1514 [22] C. Iacovou, A. Dexter, Turning around runaway information technology 1515 projects, IEEE Eng. Manag. Rev. 32 (4) (2004) 97–112, http://dx.doi.org/ 1516 10.1109/EMR.2004.25141. 1517 [23] T. DeMarco, T. Lister, Risk management during requirements, IEEE Softw. 20 1518 (5) (2003) 99–101. 1519 [24] D.X. Houston, G.T. Mackulak, J.S. Collofello, St ochastic simulation of risk factor 1520 potential effects for software development risk management, J. Syst. Softw. 59 1521 (3) (2001) 247–257, http://dx.doi.org/10.1016/S0164-1212(01)00066-8. 1522 <http://www.sciencedirect.com/science/article/pii/S0164121201000668>. 1523 [25] G.P. Kulk, C. Verhoef, Quantifying requirements volatility effects, Sci. Comput. 1524 Program. 72 (3) (2008) 136–175, http://dx.doi.org/10.1016/ 1525 j.scico.2008.04.003. 1526 [26] D. Zowghi, N. Nurmuliani, A study of the impact of requirements volatility on 1527 software project performance, in: Asia-Pacific Software Engineering 1528 Conference, vol. 3, 2002. http://doi.ieeecomputersociety.org/10.1109/ 1529 APSection 2002.1182970. 1530 [27] A. Loconsole, J. Borstler, An industrial case study on requirements volatility 1531 measures, in: Asia-Pacific Software Engineering Conference, 2005, pp. 1–8. 1532 <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1607159>. 1533 [28] K.E. Wiegers, Software Requirements, second ed., Microsoft Press, Redmond, 1534 WA, USA, 2003. 1535 [29] S. Lauesen, Software Requirements – Styles and Techniques, Addison-Wesley, 1536 2002. 1537 [30] G. Kotonya, I. Sommerville, Requirements Engineering, John Wiley & Sons, 1538 1998. 1539 [31] I. Sommerville, P. Sawyer, Requirements Engineering: A Good Practice Guide, 1540 John Wiley & Sons, 1997. 1541 [32] A. Lamsweerde, Requirements Engineering: From System Goals to UML 1542 Models to Software Specifications, John Wiley, 2009. 1543 [33] A. Aurum, C. Wohlin, Engineering and Managing Software Requirements, 1544 Springer-Verlag, New York, Inc., Secaucus, NJ, USA, 2005. 1545 [34] IEEE, IEEE Recommended Practice for Software Requirements Specifications, 1546 830-1998. <http://standards.ieee.org/findstds/standard/830-1998.html> 1547 (September 1997). 1548 [35] S.E. Institute, Capability Maturity Model Integration (CMMI), Version 1.3. 1549 <http://www.sei.cmu.edu/cmmi/solutions/info-center.cfm> (last visited, 1550 December 2011). 1551 [36] C. Hood, S. Wiedemann, S. Fichtinger, U. Pautz, Change management interface, 1552 in: Requirements Management, Springer, Berlin Heidelberg, 2008, pp. 175– 1553 191. 1554 [37] I. Legodi, M.-L. Barry, The current challenges and status of risk management in 1555 enterprise data warehouse projects in south africa, in: Technology 1556 Management for Global Economic Growth (PICMET), Proceedings of PICMET 1557 ’10, 2010, pp. 1–5. 1558 [38] G. Anthes, No more creeps! Are you a victim of creeping user requirements?, 1559 Computerworld 28 (18) (1994) 107–110 1560 [39] H. Ruel, T. Bondarouk, S. Smink, The waterfall approach and requirement 1561 uncertainty: an in-depth case study of an enterprise systems implementation 1562 at a major airline company, Int. J. Technol. Proj. Manage. (USA) 1 (2) (2010/04/) 1563 43–60 (waterfall approach; requirement uncertainty; enterprise systems 1564 implementation; major airline company; project management). http:// 1565 dx.doi.org/10.4018/jitpm.2010040103. 1566 [40] Software Engineering Body of Knowledge (SWEBOK), Angela Burgess, EUA, 1567 2004. <http://www.swebok.org/>. 1568 [41] M. Takahashi, Y. Kamayachi, An empirical study of a model for program error 1569 prediction, IEEE Trans. Softw. Eng. 15 (1989) 82–86. http://dx.doi.org/http:// 1570 doi.ieeecomputersociety.org/10.1109/32.21729.. 1571 [42] S. Harker, K. Eason, J. Dobson, The change and evolution of requirements as a 1572 challenge to the practice of software engineering, in: Proceedings of IEEE 1573 International Symposium on Requirements Engineering, 1993, pp. 266–272. 1574 http://dx.doi.org/10.1109/ISRE.1993.324847.

1575[43] S. McGee, D. Greer, A software requirements change source taxonomy, in: 1576Fourth International Conference on Software Engineering Advances, ICSEA ’09, 15772009, pp. 51–58. http://dx.doi.org/10.1109/ICSEA.2009.17. 1578[44] S. Easterbrook, J. Singer, M.-A. Storey, D. Damian, Selecting empirical methods 1579for software engineering research, in: F. Shull, J. Singer, D.I.K. Sjberg (Eds.), 1580Guide to Advanced Empirical Software Engineering, Springer, London, 2008, 1581pp. 285–311. 1582[45] J. Singer, S.E. Sim, T.C. Lethbridge, Software engineering data collection for field 1583studies, in: F. Shull, J. Singer, D.I.K. Sjberg (Eds.), Guide to Advanced Empirical 1584Software Engineering, Springer, London, 2008, pp. 9–34. 1585[46] C. Dawson, Projects in Computing and Information Systems: A Student’s 1586Guide, Addison Wesley, 2005. 1587[47] R.A.P.L.M. Rea, Designing and Conducting Survey Research: A Comprehensive 1588Guide, Jossey-Bass, San Francisco, CA, 94103-1741, 1005. 1589[48] A. Strauss, J. Corbin, Basics of Qualitative Research: Grounded Theory 1590Procedures and Techniques, Sage Publications, Newbury Park, California, 1990. 1591[49] Wikipedia, Likert Scale. <http://en.wikipedia.org/wiki/Likert_scale> (last 1592visited, December 2011). 1593[50] K. Wnuk, The Survey Questionnaire, <http://fileadmin.cs.lth.se/serg/ 1594ExperimentPackages/Obsolete/AppendixB_SurveyQuestions.pdf> (last visited 1595December 2011). 1596[51] B. Regnell, R.B. Svensson, K. Wnuk, Can we beat the complexity of very large- 1597scale requirements engineering?, in: Proceedings of the 14th International 1598Conference on Requirements Engineering: Foundation for Software Quality, 1599REFSQ ’08, Springer-Verlag, Berlin, Heidelberg, 2008, pp 123–128. 1600[52] S. Monkey, Survey Monkey Webpage. <http://www.surveymonkey.net> (last 1601visited December 2011). 1602[53] Linkedin, The Linkedin. <http://www.linkedin.com/> (last visited, December 16032011). 1604[54] K. Wnuk, The Full List of Mailing Lists. <http://fileadmin.cs.lth.se/serg/ 1605ExperimentPackages/Obsolete/ListOfDiscussionGroups.pdf> (last visited 1606December 2011). 1607[55] K. Wnuk, The Full List of Tool Vendors. <http://fileadmin.cs.lth.se/serg/ 1608ExperimentPackages/Obsolete/ListOfVendors.pdf> (last visited December 16092011). 1610[56] C. Wohlin, P. Runeson, M. Höst, M.C. Ohlsson, B. Regnell, A. Wesslén, 1611Experimentation in Software Engineering: An Introduction, Kluwer Academic 1612Publishers, Norwell, MA, USA, 2000. 1613[57] A. Arcuri, L. Briand, A practical guide for using statistical tests to assess 1614randomized algorithms in software engineering, in: Proceeding of the 33rd 1615International Conference on Software Engineering, ICSE ’11, ACM, New York, 1616NY, USA, 2011, pp. 1–10, http://dx.doi.org/10.1145/1985793.1985795. 1617[58] S. Nakagawa, A farewell to Bonferroni: the problems of low statistical power 1618and publication bias, Behav. Ecol. 15 (6) (2004) 1044–1045. 1619[59] T.C. Lethbridge, S.E. Sim, J. Singer, Studying software engineers: data collection 1620techniques for software field studies, Empirical Softw. Eng. 10 (2005) 311–341, 1621http://dx.doi.org/10.1007/s10664-005-1290-x. 1622[60] S. Siegel, N.J. Castellan, Nonparametric Statistics for the Behavioral Sciences, 1623second ed., McGraw-Hill, 1998. 1624[61] K. Wnuk, The Appendix with Analysis. <http://fileadmin.cs.lth.se/serg/ 1625ExperimentPackages/Obsolete/AppendixA_Analysis.pdf> (last visited 1626December 2011). 1627[62] K. Wnuk, The Full List of Countries. <http:// www.fileadmin.cs.lth.se/serg/ 1628ExperimentPackages/Obsolete/COUNTRIES.pdf> (last visited December 2011). 1629[63] IBM, The Description of the Method. <http://www-01.ibm.com/software/ 1630awdtools/rup/> (last visited December 2011). 1631[64] B. Berenbach, D.J. Paulish, J. Kazmeier, A. Rudorfer, Software & Systems 1632Requirements Engineering: In Practice, Pearson Education Inc., 2009. 1633[65] A. Quispe, M. Marques, L. Silvestre, S. Ochoa, R. Robbes, Requirements 1634engineering practices in very small software enterprises: a diagnostic study, 1635in: 2010 XXIX International Conference of the Chilean Computer Science 1636Society (SCCC), 2010, pp. 81–87. http://dx.doi.org/10.1109/SCCC.2010.35. 1637[66] M. Bano, N. Ikram, Issues and challenges of requirement engineering in service 1638oriented software development, in: Fifth International Conference on Software 1639Engineering Advances (ICSEA), 2010, pp. 64–69. http://dx.doi.org/10.1109/ 1640ICSEA.2010.17. 1641[67] M. Kossmann, A. Gillies, M. Odeh, S. Watts, Ontology-driven requirements 1642engineering with reference to the aerospace industry, in: Second International 1643Conference on the Applications of Digital Information and Web Technologies, 16442009. ICADIWT ’09, pp. 95–103. http://dx.doi.org/10.1109/ 1645ICADIWT.2009.5273953. 1646[68] B. Boehm, Requirements that handle IKIWISI, COTS, and rapid change, 1647Computer 33 (7) (2000) 99–102, http://dx.doi.org/10.1109/2.869384. 1648[69] I. Sommerville, Software Engineering, Addison–Wesley, 2007. 1649[70] W. Curtis, H. Krasner, V. Shen, N. Iscoe, On building software process models 1650under the lamppost, in: Proceedings of the 9th International Conference on 1651Software Engineering (ICSE 1987), 1987, pp. 96–103. 1652[71] T. Gorschek, A.M. Davis, Requirements engineering: in search of the dependent 1653variables, Inf. Softw. Technol. 50 (2008) 67–75, http://dx.doi.org/10.1016/ 1654j.infsof.2007.10.003. <http://dl.acm.org/citation.cfm?id=1324618.1324710>. 1655[72] A. Aurum, C. Wohlin, Requirements engineering: setting the context, in: A. 1656Aurum, C. Wohlin (Eds.), Engineering and Managing Software Requirements, 1657Springer, Berlin Heidelberg, 2005, pp. 1–15, http://dx.doi.org/10.1007/3-540- 165828244-0_1. 1659[73] P. Bourque, R. Dupuis, Guide to the Software Engineering Body of Knowledge 16602004 Version, SWEBOK.

K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx 19

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001

1661 [74] N. Nurmuliani, D. Zowghi, S. Powell, Analysis of requirements volatility during 1662 software development life cycle, in: Proceedings of Australian, Software 1663 Engineering Conference, 2004, pp. 28–37. http://dx.doi.org/10.1109/ASWEC. 1664 2004.1290455. 1665 [75] X. Shan, G. Jiang, T. Huang, The study on knowledge transfer of software 1666 project requirements, in: 2010 International Conference on Biomedical 1667 Engineering and Computer Science (ICBECS), 2010, pp. 1–4. http://dx.doi.org/ 1668 10.1109/ICBECS.2010.5462314. 1669 [76] W.N. Robinson, S.D. Pawlowski, Managing requirements inconsistency with 1670 development goal monitors, IEEE Trans. Softw. Eng. 25 (6) (1999) 816–835. 1671 [77] A. Russo, B. Nuseibeh, J. Kramer, Restructuring requirements specifications for 1672 inconsistency analysis: a case study, in: Third Intl Conf. Requirements 1673 Engineering, IEEE CS Press, Los Alamitos, Calif, IEEE Computer Society Press, 1674 1998, pp. 51–60. 1675 [78] A.C.W. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, B. Nuseibeh, Inconsistency 1676 handling in multiperspective specifications, IEEE Trans. Softw. Eng. 20 (8) 1677 (1994) 569–578, http://dx.doi.org/10.1109/32.310667. 1678 [79] S. Easterbrook, What is requirements engineering? July 2004. <http:// 1679 www.cs.toronto.edu/sme/papers/2004/FoRE-chapter01-v7.pdf>. 1680 [80] T. Gorschek, C. Wohlin, Requirements abstraction model, Requir. Eng. 11 1681 (2005) 79–101, http://dx.doi.org/10.1007/s00766-005-0020-7. <http:// 1682 dl.acm.org/citation.cfm?id=1107677.1107682>. 1683 [81] J. Kabbedijk, B.R.K. Wnuk, S. Brinkkemper, What decision characteristics 1684 influence decision making in market-driven large-scale software product line 1685 development? in: Product Line Requirements Engineering and Quality, 2010, 1686 pp. 42–53. 1687 [82] R. Kohl, Changes in the requirements engineering processes for cots-based 1688 systems, in: IEEE International Conference on Requirements Engineering, 1689 2001, p. 0271. http://dx.doi.org/10.1109/ISRE.2001.948575. 1690 [83] H. Holmstrom, E.O. Conchuir, P.J. Agerfalk, B. Fitzgerald, Global software 1691 development challenges: a case study on temporal, geographical and socio-

1692cultural distance, in: International Conference on Global Software Engineering, 1693ICGSE ’06, 2006, pp. 3–11. http://dx.doi.org/10.1109/ICGSE.2006.261210. 1694[84] S. Buhne, G. Halmans, K. Pohl, M. Weber, H. Kleinwechter, T. Wierczoch, 1695Defining requirements at different levels of abstraction, in: Proceedings of 169612th IEEE International, Requirements Engineering Conference, 2004, pp. 346– 1697347. http://dx.doi.org/10.1109/ICRE.2004.1335694. 1698[85] J. Natt Och Dag, T. Thelin, B. Regnell, An experiment on linguistic tool support 1699for consolidation of requirements from multiple sources in market-driven 1700product development, Empirical Softw. Eng. 11 (2006) 303–329, http:// 1701dx.doi.org/10.1007/s10664-006-6405-5. <http://dl.acm.org/citation.cfm?id= 17021120556.1120562>. 1703[86] S. Konrad, M. Gall, Requirements engineering in the development of large- 1704scale systems, in: Proceedings of the 2008 16th IEEE International 1705Requirements Engineering Conference, RE ’08, IEEE Computer Society, 1706Washington, DC, USA, 2008, pp. 217–222, http://dx.doi.org/10.1109/ 1707RE.2008.31. 1708[87] D. Šmite, C. Wohlin, T. Gorschek, R. Feldt, Empirical evidence in global software 1709engineering: a systematic review, Empirical Softw. Eng. 15 (2010) 91–118, 1710http://dx.doi.org/10.1007/s10664-009-9123-y. 1711[88] W. Anderson, P.J. Boxer, L. Brownsword, An examination of a Structural 1712Modeling Risk Probe Technique, Tech. Rep. CMU/SEI-2006-SR-017, Software 1713Engineering Institute, Carnegie Mellon University, 2008. 1714[89] M. Bekker, H. Steyn, The impact of project governance principles on project 1715performance, in: Management of Engineering Technology, 2008. PICMET 2008. 1716Portland International Conference on, 2008, pp. 1324–1330. http://dx.doi.org/ 171710.1109/PICMET.2008.4599744. 1718[90] B. Boehm, Software risk management: principles and practices, Software, IEEE 17198 (1) (1991) 32–41, http://dx.doi.org/10.1109/52.62930. 1720[91] K. Pohl, Requirements Engineering: Fundamentals, Principles, and Techniques, 1721first ed., Springer Publishing Company, Incorporated, 2010.

1722

20 K. Wnuk et al. / Information and Software Technology xxx (2012) xxx–xxx

INFSOF 5305 No. of Pages 21, Model 5G

20 December 2012

Please cite this article in press as: K. Wnuk et al., Obsolete software requirements, Inform. Softw. Technol. (2012), http://dx.doi.org/10.1016/ j.infsof.2012.12.001