Requirements Volatility in Software Architecture Design: An Exploratory Case Study

Requirements Volatility in Software Architec ture Design: An Exploratory Case Stud y San ja Aar a maa M 3S Facu lty of Inf orm at ion Tech nol ogy and Ele ct rica l Eng in eer ing Uni ve rsity of Ou lu Fin lan d san ja.a aram aa@ oul u.f i San du n D asa nay ake M 3S Facu lty of Inf orm at ion Tech nol ogy and Ele ct rica l Eng in eer ing Uni ve rsity of Ou lu Fin lan d san dun .das anay ake@ oulu .f i Ma rk ku O iv o M 3S Facu lty of Inf orm at ion Tech nol ogy and Ele ct rica l Eng in eer ing Uni ve rsity of Ou lu Fin lan d ma rkku .oiv o@ oulu .fi Joun i Ma rkk ula M 3S Facu lty of Inf orm ati on Techn olo gy and Ele ct rica l Eng in eer ing Uni ve rsity of Ou lu Fin lan d joun i .mark kul a@ou lu .fi Sam ul i S au kkon en M 3S Facu lty of Inf orm ati on Techn olog y and Ele ct rica l Eng in eer ing Uni ve rsity of Oulu Fin lan d sam uli .sauk k onen@ oulu .f i ABSTRACT Requirements volatility is a major issue in software (SW) development, causing problems such as project delays and cost overruns. Even though there is a considerable amount o f research related to requireme nt volatility, the majority of it is inclined toward project management aspects. The relationship between SW architecture design and requirements volatility has not been researched widely, even though changing requirem ents may for example lead to higher defect density d uring testing. An exploratory case stud y was conducted to study how requ irements volatility a ffects SW architecture design. Fifteen semi-structured, thematic interviews were cond ucted in th e case company, which provides th e selection of software products for business customers and consumers. The research revealed the factors, such as requirements un certainty and dynamic b usiness environment, causing requirements volatility in the case com pan y. The study identified th e challenges th at requirements volatility po sed to SW architecture design, including scheduling and architec tural technical debt. I n addition, t his study discusses me ans of mitigating the factors that cause requirements volatility and addressing the challenges posed by requirements volatilit y . SW architects are strongly influenced by requireme nt volatility. Thus understanding th e factors causing requirements volatility as well as means to mitigate the challenges has high industrial relevance. CCS CONCE PTS Software and its eng ineering~Requirements a nalysis, Softwa re and its engineering~Softwa re des ign engineering, So ftw are and its engineering~Software development process m anagement KEYWORDS Requirement management; software architecture 1 INTRODU CTION Requirements changes affect throughout all software (SW) development lifecycle, for example leading to higher defect density in testing phase [ 51 ]. Due to various internal and external factors, changes in individual requ ireme nts o r in sets of requirements are inevitable. The changing nature of requirements in requirem ents engineering (RE) is de noted by requirements volatility . [ 10 ]. Since they are r esponsible for system structure, SW architects are th e stakehold ers th at are gre atly affected by requirements volatility [8], [ 17 ] . SW architecture design p lays a prominent role in SW development, as it acts as the foundation of the SW systems and shap es the fin al outco me. SW architects must make critical decisions based on requ irements [ 24 ]. Making sub- optimal a rchitecture decisions can decrease system quality and cause pro blems later on [ 14 ]. Chan ges in requirements may necessitate the redesign of the SW to accommodate those changes, leading to an unstable SW system [ 26 ]. Correcting system shortcomings after com pleting system development is very complicated and far costlier than identifying and addressing them during initial design [ 51 ]. Existing literature discusses requirements volatility mainly from the project management viewpoint [ 40 ] and it has been studied related to SW maintenance [ 52 ] and coding [ 25 ] . But empirical evidence about requirem ents volatility f rom the SW architects’ viewpoin t and interplay between RE and SW architecture design in industrial environments is not extensively addressed. To provide em pirical insights in to requirements volatil ity from SW architects ’ point of view, an indu strial case stud y was conducted to explore requirements volatility in the context of S W architecture d esign. Fifteen SW architects involved in architecture design were in terviewed for the case, the objective of which was to identify challenges that SW ar chitects face due to req uirements ICSSP’1 7, July 05- 07 , 2017, Paris, France S . Aaramaa et al. volatility and to propose means to address those challenges. The following research questions we re derived from th e objecti ves o f the case. RQ1: What are the factors that cause requirement volatility? RQ 2 : What challeng es does requireme nts volatility pose to SW architecture design? RQ 3 : What are means to a ddress the identified challenges in SW development? This paper is structured as follows. Section 2 outlines related scientific literature. Section 3 describes the research approach. Section 4 provides an overv iew of the software d evelopme nt process in the case company and a nswers RQ1, desc ribing the challenges identified b ased on th e interviews. Section 5 discusses the means to address th e id entified ch allenges, based on existing scientific literature a nd the re searchers’ experience, thereby answering RQ2. Finally, Section 6 discusses conclusions. 2 RELATED WORK RE is a systematic way to elicit, organise and do cument system requirements as well as a process to establish and maintain agreement between a customer and a systems provider [ 32 ]. Many authors emphasise the natu re of change in the RE process [ 59 ] , [ 35 ] , [ 31 ]. In addition, the requirements ma nagement p rocess is defined as a process of ma naging c hanges in the requirements [ 29 ]. Nurmuliani [ 43 ] defines requirements volatility a s ‘ the tendency of requirements to change over time in response to the evolving needs of customers, stakehold ers, the organisation and the wo rk environment’. Requirements volatility may also be defined as a change th at could occur to a requirement [ 53 ]. This is in line with Nurmuliani’s operationalised definition of requirements volatilit y [ 43 ]. Several internal and external factors, such as stakeholder f eedback, technology , the market situation and customer needs, ca n cause changes in requirem ents [ 38 ] . Christel [ 10 ] groups requirem ents elicitation problems into th ree categories: scopin g (information mismatch), understanding (inter - and intra-group) and volatility (requirement ch anges). The major reason for requirem ents volatility is changing user needs [ 48 ] , which primarily lead to changes in individual requirements. Other important factors affecting volatility are conflicting stakeholder views and complexity o f organisation [ 18 ], which lead to changes in the content of forthcoming releases. In addition, problems in understanding and scop ing cause volatility [ 10 ]. Requirement information mismatch is also de noted requirem ent un certainty [ 40 ] , [ 39 ]. Existing literature on requirements volatil ity emphasises management viewpoin t [ 58 ] , [ 45 ] . These studies sought factors causing requirements volatility [ 10 ], its effe cts on projects [ 61 ] and me ans to mitigate th ose effects [1] . In addition, requirements volatilit y has been investiga ted in relati on to S W maintenance [ 52 ] and coding [ 25 ], but not extensively in the context of S W architecture design. In short, requirements volatility is a phenomenon caused by vario us internal and external factors that lead to changes in the single requirements or sets of requirements. Chan ges in the sets of requirements have been claimed to results in more severe con sequences th an those in one requirement [ 16 ]. A pplying a n iterative RE process model has been propo sed as a means to tackle requirements vol atility [ 34 ] . For example, the twin peaks model is an iterative approach in which re quirements a nd sof tware architecture are dev eloped in parallel from the very beginnin g of th e software de velopment lif e cycle [ 44 ]. SW architecture is the foundation th at the SW system is buil t upon. The purpose of designing the SW architecture is to provide a unified vision about the system and improve understanding o f its behaviour. T he architecture, including diagrams, use cases an d semantics, reduces ambiguities and shortens the time it takes for stakeholders to understand the constraints, behaviour, ti ming, layout for instance. Stakeholders involved in SW architecture design must m ake various decisions throughout the SW system life cycle re gards to development, evolution a nd integra tion [ 24 ] . SW architecture design is inherently complex, and complexity i s further increased because the architecture must address various stakeholder concerns [ 55 ] that may conflict with achieving SW system develop ment goals. According to recent empirical studies on SW a rchitecture design decision-making, in industrial environments, SW architects use experience, intuition and other informal approaches rather than using formal too ls and techniques [ 15 ] , [ 57 ]. SW architecture design is co nsidered primarily as th e SW architect’s responsibility [ 13 ]; nevertheless, the active involvement of other stakeholders, such as SW developers, product managers and customers, is crucial for achieving th e better understanding about the criteria the architecture must meet. An important element of the architecture d esign process is recording architecture design ratio nale, as und erstanding the reasons behind a certain architecture design d ecision can be critical during S W s ystem maintenance and evolution [ 56 ] . Architectural technical debt refers to the consequences fac ed late in the SW d evelopme nt process due to sub -optimal architecture decisions and trade-offs [ 33 ] , [ 14 ] . SW teams accumulate architectural technical debt due to their o wn actions and due to external events related to natural software aging and evolution. Even though technical debt related to coding issues can be detected using v arious tools, architecture technical d ebt mostly remains invisible and grows over time. [ 30 ] Factors that contribute to accumulating architectural debt include un certainty about requirements at the beginning of development, the introduction of new requirements during the SW development process, ti me pressure, feature-oriented prioritisation and specification issues with critical architectural requirem ents [ 36 ]. The RE process and SW architecture design are called “twin peaks” and considered equally important [ 37 ] . Since they are closely connected, d ecisions made regarding one can affect the other [ 44 ] . Even though the traditio nal waterfall model leads to freezing requirements before moving in to design and making hard to ch ange architecture decision s, in reality th e changes can occur in both areas and they can affect one another [ 11 ] Non-functional requirements (NFRs) constitute th e majority of stakehold er concerns and greatly in fluence shapin g up the architecture. The interactions between NFRs are among the main factors th at should be taken in to consideration during architecture design, as Requirements Volatility in Software Architecture Design: An Exploratory Case Study ICSSP’17, July 05 -07, 2017 , P aris, France architecture either allow s or pre cludes almost all NFRs of a system [ 12 ]. SW architecture design decisi ons are p rimarily based on A rchitecturally Significant Requireme nts (A SRs), w hich are critical to shaping system architecture [7]. While NFRs take th e large share of ASRs du e to their ability to affect the whole SW system, it can also include functional re quirements. C orrectly identifying and classify ing architecturally significant functional requirements (A SFRs) is also c ritical for an architect to mak e informed decisions [ 41 ] , [ 6]. The modern iterative software development app roaches facilitate close in teraction between requirements and architecture and help mak ing rapid adjustments. 3 RESEA RCH METHOD The research metho d selected for this study was the case study, because the o bjective of the study was to research th e requirements volatilit y in SW arc hitecture d esign in the industrial setting [ 47 ]. The case study method is well suited for the researching real life p henomena in its n atural setting [ 60 ]. Figure 1 depicts the phases of the case study. Figure 1: The utilized case study process. Case context : T he case study w as conducted in a com pany with more th an 900 employees in 2 5 offices worldwide. However, the product developm ent is mainly don e in three countries. The case co mpany is a com prehensive SW solutions provider to b oth private and business customers and SW products for private customers. The SW solutions offered for business custome rs include a number of management tools and company services for the worldwide m arket. In addition , the case company provides various SW produ cts for private customers to b e used on an array of devices, ranging from deskto ps to handhel d mobile devices. The SW development activities in the case company ar e carried out mainly in three countries. In th e case company th ere are th ree parallel bu siness lines: U1, U2 and U3. The units are divided based on their business focus and each unit have their own financial responsibilities. There also is a horizontal b usiness line, U4, which is responsible for providing services that are commonly shared b y other three business u nits. The business lines operate as ind ependent entities and within the bu siness lines, there is a flat hierarchy of tea ms mostly organised based on projects. Along with the busin ess units, a sp ecial unit, U5, consists of technical experts who take company-wide decisions related to technical matters. Ind ividual teams are mostly self-organising and typically consist of four to eight people. While teams are free to operate according to their own agendas, they might have to i nteract and alig n with other teams, depending on th e nature of the project. Some teams have their own architect or scrum master, but this is not the case for every team. Table 1. The details of the interviews. ID Unit Responsibilities The years of experience (in the case company) I1 U1 SW dev./ Architect 18 (17) I2 U1 SW dev. 7 (2) I3 U1 SW dev./ Architect 5 (3) I4 U1 SW dev. 20 (2) I5 U2 SW dev./ Team lead 15 (15) I6 U2 SW dev./ Team lead 20 (20) I7 U2 SW dev./ Architect 14 (8) I8 U3 Program/ Project lead 13 (7) I9 U3 SW dev./ Architect 13 (3) I10 U3 SW dev. 22 (15) I11 U3 SW dev./ Architect 13 (9) I12 U3 SW dev./ Architect 24 (4) I13 U4 SW dev. 15 (5) I14 U4 SW dev. 19 (6) I15 U5 Lead architect 15 (14) Case study design and preparation. An in terview guide, which consisted of th e set of open ended questions grouped into different themes, was prepared to guide the interviews. The interview guid e consisted of the following themes; a general background, SW development process, requirements engineering and SW architecture design, SW architecture design challenges, solutions and expectations. The background qu estions covered the general information such as the experien ce of the interviewee, typical project and team composition as well as company description . The SW d evelopment process theme covered the o verall develop ment life cycle. The rest o f the themes were designed to go into a d eep discussion about requirement engineering an d SW architecture design activities. The final part targeted, the various challenges faced by the interviewees and the possible solutions from their perspectives. A pilot interview was conducted to test the interview guide as well as the interviewers approach. The participant of the pil ot interview had a long history working in indu stry as a SW developer and a SW architect. In add ition, the feedback received fro m the company representatives was also used to improve the interview ICSSP’1 7, July 05- 07 , 2017, Paris, France S . Aaramaa et al. guide. The reviewers o f the questionnaire and the pilot int erview participant did not participate in the actual case study . Data collection . Fifteen semi-structured, them atic [ 20 ] interviews were conducted with SW experts during November and December 20 14 as the primary method of data collection. All the interviewees acted as software ar chitects in their respective teams even though not all of th em are titled as architects (cf. Table 1). The interviewees were selected to represent all five un its in the company’s te chnical o rganisation. Interview ees have di fferent levels of work experience, are a ctive in various projects and are located at three company sites. The experience given in Table 1 reflects the years of experience in SW development in ind ustry. The number without b rackets is about experience in total while the one in brackets is for the years in the case company. Twelve interviews o f 1‒2 h ours in length were conducted by two researchers face to face (F2F) at case company sites, and three interviews of the same duration were conducted via Skype. Interviewees were provided in advance with the list of interview questions, which was used as a guide, and more detailed questions emerged during the interviews. Figure 2: The themes used in the data analysis. Data analysis. The interviews were pro fessionally transcribed and fed in to NVivo, a qualitative data analysis tool, as the starting point of the data analysis. The researchers went through each o f the transcribed interviews and labelled the relevant in formation using a pre-defined set of th em es based on the interview guide. Initially, there were the li mited set o f themes based o n the research q uestions and as th e p roce ss going forward, new themes were emerged and the sub themes were also created. The themes used during the data analysis are shown in Figure 2. The themes are not mutually exclusive and the same data can be labelled with multiple labels belongs to different them es. This case study adapted th e reporting guidelines provided by [ 47 ]. A strict privacy policy w as followed th at described a ll necessary elements o f the case study while protecting th e integrity of th e company and individuals [4] . Interviewees’ identities are protected by, for example, usin g aggregated information instead of presenting in terview excerp ts and by avoidin g use of corresponding IDs in tables. The results are based on the interv iews and publicly a vailable information abo ut the co mpany . The topics represent the aggregated viewpoints of the respondents th roughout the interviews. T he issues mentioned only by a single interviewee have not been included in the results, as th ey were considered not expressing shared understanding among SW architects. At first, an overview of SW d evelopment practices are ou tlined, which helps to understand the developme nt context. This is followed b y the description o f req uirem ents vo latility ch allenges in the case company. 4 SW DEVE LOPMENT PROCE SS SW development practices in the case company are quite in formal and v ary fro m team to team. Ev en thou gh the com pany has a history of experi menting with various lean and agile SW development approaches on the company level, at the moment, there is no company-wide SW development app roach. SW teams are free to select their o wn ap proaches u nless there are specific restrictions such as customer preferences. SW teams tend to create their own approach by selecting and combining various agile and lean practices, including f ollowing sprints, maintaining product backlog and u sing Kanban boards. Although interviewees’ have responsibility for SW architecture design, their involvement in RE is limited to occasionally providing expert opinion. Thus, interviewees’ understa nd ing about RE is not a s extensive as is their knowledge of SW architecture design. 4.1 Requirement s Engineering SW architects are n ot directly involved in customer requirement elicitation an d analysis. In the case company, elicitation is accomplished u sing techniques such as focus groups, beta testers, and direct customer comm unicatio n. Occasionally, customers’ ideas are expressed at so abstract a level th at they can hardly be translated as requirements. On the other hand, it is possible that requirements will be stated as full-scale technical specifications. Customer needs are clarified during th e requ ireme nt a nalysis . The SW product owner (P O) is a link between the SW tea m and product manag ement (PM). The P O h as the responsibility to communicate with the P M to cla rify what m ust be implemented. For the majority of interviewees, the P O is the sole connection point to requirements elicitation an d analysis phases. During th e clarification process, S W archit ec ts are occasionally consulted t o define the technical feasibility of requirements and choose the b est implementation solution. At this phase, requirements volatilit y factors inclu de changing custo mer n eeds and evolving technological understanding. A pro ject management tool (PMT) is the main medium f or documenting requ irements, which u sually are expressed a s features or backlog items. In addition to the primary PMT, legacy and team-specific tools an d sticky notes are u sed to communicate tasks, store customer information and document decis ion rationales. The lev el of details in i nformation on req uirements Requirements Volatility in Software Architecture Design: An Exploratory Case Study ICSSP’17, July 05 -07, 2017 , P aris, France varies d epending on a product and a team. Sometimes, only a feature name is recorded, but at the other extrem e, descriptions include even the contact in form ation of th e relevant technical specialist on the customer side. In the case of private customer products, requirements are created by experts based on a foreseen market. Usually, the creator of a requirement is recorded, but sometimes it is not known w hether the req uirement originated with a custo mer or an internally iden tified techno logy gap. Interviewees related th at they so metimes needed m ore techn ical details o r contextual descriptions to be ab le to choose the best implementation alternative. Big co rporate customers may have strict requ irements about formal documentation to be d elivered to the customer. Interviewees poin ted o ut th at a requirement description is alway s a compromise between level of detail and time available for the task. The PM is responsible f or prioritising requirements, taking into account, for example, company strategies and th e importance of th e customer. The dominant factor when setting requirement priority is the customer: The bigger the customer, the higher th e priority of its requ ireme nts. Even tho ugh some featu res are technically feasible and could contribute improving the product quality in the long run, it may be v ery difficult to say no to features that a custo mer wa nts, especiall y if the customer is big. Other factors taken into account when setting require ment priorities include development cost, feature size, p roduct roadmap, criticality and external audit results, w hich are p ublicly available and used to rank the solution p roviders in the domain . Interviewees were involved in requirement p rioritisation, proposing product improvements and project scoping m eetings. Most interviewees mentioned having faced challenges with changing requirement priorities. As the backlog is upd ated frequently, changing priorities contri bute to requirements volatility. 4.2 Software Archi tecture Des ign Since th e majority of the tea ms follow agile and lean approaches, the design an d impleme ntation are done iteratively, leadin g to a shorter design phase than in the traditional wa terfall approach. The SW architecture design pro cess t ypically starts with backlog review meetings between the team and other relevant stakeholders. The ob jective of these meetings is to reach a consensus what n eeds to be developed to fulfil requirements. While the team is generally repre sented by senio r members during the initial meeting, it is possib le th at th e whole team is involved from the beg inning. Once the basic ASRs are understood, the team creates a design proposal, which is delivered for review. The review is done at different levels, d epending on the scale of th e project or its d ependencies to o ther products. O nce decisions are made, the team is free to begin development and has the flexibility to make minor changes to the design. If th e design must b e altered considerably, th e evaluation of th e alterations is escalated. SW architecture designs and decisions taken during discussions at various levels are recorded using several methods. Even though the interview ees clai med that they have maintained some type of design documentation, attention to documenting design appears to be inadequate. The majority of teams u se tools such as Wiki or PMT in stead of traditional design documents to store their architecture decisions. 5 REQUIREMEN T VOLATILIT Y – ORIGINS AND CHAL LENGES Through data analysis, it was po ssible to identify factors th at cause requirements volatility in the case company as well as the challenges th at re quirements volatility poses to SW architecture design. This sec tion first descri bes the f actors of requirem ent s volatility identified in the c ase company and then the consequences o f requirements volatility. Th us the subsection Error! Reference source not found. answers RQ1 and th e subsection Error! Reference source not fo und. ans wers RQ2 . Quotes from interviews provide insights for collected empirical evidence. Each quote is from a different interview. Ho wever, to protect the in tegrity of the respondents the quotes are not labelled by the respo ndent ID. None of the respondents was a native English speaker. Therefore, it has been nec essary to correct so me minor language errors to ensure a proper message. 5.1 Factors Causin g Require ments Volatility Several factors that contribute to requirements volatil ity were identified in the case company . 5.1.1 Requirement Uncertainty . An important factor for causin g requirements volatility is th e uncertainty of requirements, which is realised for example as inadequate descriptions of backlog it ems. Often, f eatures or backlog items lack d etailed inf ormation; for example, a backlog item may have only a name, but no one knows why the item is th ere. The too l includes a customer acceptance criteria field as part of the requirement description. Most of the time, something is recorded in this field. However, often, th e description is a coup le o f lines of t ext at an abstract le vel. This means th at architects and testers must guess what must be fulfilled. “It [d escription] can be just couple li nes of text and that’s a ll and we need to guess w hat shall we do…. qua lity engineers always complain abou t it because they don’t know how to test because it’s not so clear how it should work.” 5.1.2 Changing User Needs . The case co mpany p rovides multiple SW products for various customer groups and frequently comes across changing customer n eeds. As most of the req uirements for private customer products are decided within the company, corporate customers are th e main source o f requ irements changes. The lo ng-term business relationship between corporate customers and the company makes it difficult to refuse to adapt to changing customer needs. “Well, sin ce we are doing this project with, constantly changing requirements. I don't see much chance for improving the process because we are ju st, ba sically adapting. And not pl anning ahead.” 5.1.3 Dynamic Business Environment. The company op erates in a dynamic busin ess do ma in and must adjust its strategies for accommodating developme nt in that domain to stay ahead o f the ICSSP’1 7, July 05- 07 , 2017, Paris, France S . Aaramaa et al. competition. The severe market situation requires con stant changes in requirement p riorities. A s m ost of the company’s private customer pro ducts runs o n smartphones where the operating systems are h ighly fragmented and subjected to frequent changes, the c ompany has to make f requent change s to their products to accommodate those changes. “This list we see for quarter is something that we can work on. Whatever in future is, at least, that is subject to change b ecause market change, situa tion change and stuff like that. So we wouldn't know.” 5.1.4 Stakeholder Dependencies. The company is structu red along business lines, each o f which ru ns its projects independently. However, sometimes delivering a solution requires coll aboration among teams from different business units. For example, a team that h as developed a mobile application might have to interact with teams th at have d eveloped the same appli cation for different platforms and with teams th at provide server-sid e support for those applications. In this situation, changes in requirements in one unit lead to changes in another one. “When we have external d ependencies on the teams in, especially if they a re another lo cation, it’s sometimes qu ite hard to make sure that everything happens in time. “ 5.1.5 Communication Issues. As the case company h as a glob ally distributed custome r base, multiple development sites and virtual SW teams, it is challenging to communicate requirements. Communication issues may be gin du ring the elicitation and customer negotiation phases. Typically, this is due to the fact th at the terminology and sema ntics differ between cu stomers and developers. These differing domains bring to th e table differe nt terminology and concepts. Later in the process, SW teams may face language barriers and cultu ral diff erences that pose communication c hallenges. Comm unication issues are present, even tho ugh the company has tried several supporting tools and approaches to improve communication both within the co mpany and with customers. “And we often need clarification all th e way from customers…, but we do have this kind of feedback cycle from us to the customers, so that we can find out what exactly is wanted. Because that's really not that clear always.” 5.2 Requirement s Volatility Chal lenges in Software Archit ecture Interviews revealed several ch allenges th at requirements volatility poses to SW architecture design. It should be noted that requirements volatilit y is not th e sole reason for these challenges, bu t requirements volatility is the scope of this study. 5.2.1 Scheduling. Typically, requirement clarif ication take s so much time in the case company that architects receive requirements very late in the project. This causes challenges in scheduling both on the team level and th e organisational level. On the team le vel, the later the architects receive the requirements, the less time they have to design architecture, and some steps must b e omitted. The company creates development plan s quarterly. The aim is t o have two forthcoming quarters p lanned to provide an overall idea about what should be achieved in six months. However, qu arterly plan s are subject to change. Often, when a quarter begins, the schedule applies for only a co uple of weeks, and then the co ntent must be re-planned. The most important reason for schedulin g issues is requirements volatility. In the worst cases, priorities change daily, in which case, architects have no choice but to work on th e item at hand and then take the next one on the backlog li st, which might be different th e next morning. “Actually, we can ’t use Scrum basically b ecause our priorities change all the time, like.. maybe, sometimes d aily so, yeah, we basically get the next item and work on it.” 5.2.2 Synchronisation. Stak eholder dependencies are one f actor causing requirements volatility, which, in turn, causes synchronisation issues. Interviewees noted that som etimes they are unable to d eliver products on time du e to delays in other un its. Beside in ter-unit synchronisation issues, teams in the same business unit but at different development sites have synchronisation challenges caused by lack of physical proximity. Synchronisation needs a nd deve lopment dependencies also influence the tools used. P MT was used for project manag ement, requirement descriptions and bug fixing. These activities require very different to ol functionalities, which are suppo rted only partially. F or example, maintaining th e backlog within a project and following feature development work well, but cro ss-project management, such as moving a fea ture from on e project to another, is not supported. “Probably the most complex thing is that, we need to somehow synchronize the requirements b etween the different teams and, that's wh y, having some leader ship team would be be neficial because they would synch up together what they are gonna do, what resources they have, how they would transfer their sto ries between the teams and et cetera.“ 5.2.3 Architectura l Technical Debt. The company’s require ment prioritisation criteria are strongly bu siness driven, favouring market needs o ver architectural con siderations. Overlooking architectural aspects when prioritising requirements accumulates architectural technical debt. As architects are o verw helmed with volatile requirements, they are n ot necessarily able to find out th e optimal architectural design choices. S pecifically , prio ritising functional requirements o ver NFRs is a major issue, as NFRs are the majority of ASRs, and n eglecting th em leads to s ub -optim al architecture design. “I think the biggest driver usually for getting something prioritized really fast is money. S o if the customer is big enough and the expected in come is big enough, [case company] will run through hoops…, for small er customers even if th e smaller customer is a sking for something th at makes much more sense. So I think that, the primary driver is economic. S o instead of doing feature development, we kind of get overridden by th e [b usiness customer] d eliveries all the time, because that’s where the money comes from.” 5.2.4 Tracing Design Rationale . The intervie wees u nderstand the importance of record ing design rationale while making an architecture decision and tracing back to it during the later stage of the software development process. However, they find it Requirements Volatility in Software Architecture Design: An Exploratory Case Study ICSSP’17, July 05 -07, 2017 , P aris, France difficult to maintain d esign documents, th e most common way o f recording d esign decisions, because they requ ire frequent updates due to the volatile requirements. Even t hough P MT sup ports current need to some extent, there are major issues with ou tdated and unstructured information, broken li nks and inability to trace decision rati onale. Ty pically, PMT is not u sed to store customer- related information, since it is considered too in secure. Thus, there must be some other means to record customer data. “So u sually the reasoning [ behind design decisions] , happens, it’s kind of like corrid or disc ussion where we have a meeting where we talk about it and then we report what we decided to do in the PMT items bu t of course there’s lot o f stu ff tha t we miss, so we do n’t really document the why, we document the what. And of course these discussion s in the meeting, kind of contain the why also but if you are no t in the meeting then that informa tion is not available, usually.” The following Figure 3 summarises the identified factors causing requ irements volatility in the case co mpany as well as th e challenges it poses to S W archite cts during the definition o f SW architecture. Figure 3: Th e factors and challenges causing requ irements volatility. 6 ADDR ESSING RE QUIREMENT VOLATILITY C HALLENG ES This se ction discusses th e requirements volatility challenges in SW architecture design in relation to existing scientific k nowledge and in the light of the empirical d ata gathered from the case company, thereb y answering RQ 3. In general, th ere are t wo main approaches to addressing req uirements volatility challenges: mitigate their causes or find means to manage th eir consequ ences to SW architecture design. Mitigating the causes of requirements volatility. Interviewees provided contradictory opinions abou t h ow much in formation is available to th em. On one hand, it was reported that at the beginning of a project, a significant amount of time is spent negotiating technical feasibility and clarifying actual n eeds, the intended behaviour of the product and dependencies with other features. On th e other hand, it was noted that if the available information is no t too detailed it leaves ro om for creativity and allows discovering the best technical solution. Missing requirements early in the process causes the costliest fixes later in the d evelopme nt process [ 43 ]. The starting poin t for addressing requirement uncertain ty is to evaluate what information is crucial to whom, why and when. This should be stated explicitly in th e information fields p rovided for describing the requirement. Unnecessary default requirement fields should be removed. However, this is not sufficient, since the quality o f th e descriptions d epends on the expertise of the writer. According to interviewees, POs or m arketing personnel d o not have en ough technical understanding about th e product to write detailed requirement description s. In addition, it would be a waste o f time to write an extensive requirement description just to find out later that the requireme nt is not technically feasible. The twin peaks approach where requirements and architecture are developed in parallel could b e used to address this issue [ 44 ]. The impact caused by the lack of technical understanding of the p eople responsible for eliciting requirements can be m itigated through supportive means. On e such way is asking probe questions, t o identify ASRs from softwa re requirement specifications [5] , [6]. Maintaining a strong, mutually beneficial relationship b etwee n the custo me r and the d evelopment team is crucial to successfully managing changing customer needs [ 22 ]. W hile this helps to understand th e customers’ true needs an d derive we ll -d efined requirements from the beginn ing, it also allows d evelopers to communicate the consequences of ac commodating changes rather than blindly accepting them. Approaches to mitigate th e effects of changing customer needs include eliciting gaps in requirem ent changes [ 46 ] and reusing existing requirements to identify the gap between elicited requirements and true user needs [2]. Following shorter development cycles can help address requirement prioritisation issues caused by a dynamic business environment [ 23 ]. However, following short design cyc les can affect project schedulin g and sy nchronisatio n. So it should be carefully considered. As the SW teams in the case company sometimes depend on each other’s work, their req uirements are in terconnected. Therefore, it was alarming to o bserve that identifying the dependencies between the requirements of va rious stakeholders sometimes was m ore w ishful thinking than practice. Managing requirement dependencies is acknowledg ed as a challenging task [9] that may be addressed by supp orting impact analysis [ 58 ] . One approach could b e to establish a product management team across business units that would have overall respon sibility for managing projects that span business units, including resources, scheduling, priorities and such. Introducing advanced collaborative and communication mechanisms can overco me some of the commu nication issues among distributed software te ams [ 3] as well as customer communication issues [ 28 ]. At th e same time, using m ultiple communication media rather than a single communication channel can help avoid misunderstandings caused by cultural and language differences [ 50 ]. In the context of the case company, the person nel responsible for c ustomer c ommunication play a crucial r ole in effective communication. Managing the consequences of requirements volatility. As previous sections have described, there are no d irect causal relationships between on e factor and one consequence, but relationships can be recognised. Therefore, there is no definite ICSSP’1 7, July 05- 07 , 2017, Paris, France S . Aaramaa et al. solution to address each identified con sequence. As scheduling issues appear at th e team level a nd at th e organisational lev el, addressing them must be undertaken at both levels. At the team level, th e situ ation could be improved by, for exam ple, assessing the suitability of th e elicitation techniques used and the adequacy of the requirement information collected. A ccording to Hickey and Da vis, an elicitation technique should b e cho sen based on problem, solution and project domain characteristics as well as known requirements [ 21 ]. On the o rganisational level, one solution could be to include a suff icient bu ff er [ 19 ] for planned releases a s a response to re quirements volatility . According to feedback from interviewees, interaction am ong team members located at various sites is not adequate, despite using various communication tools. W hen it comes to distributed teams, ju st maintaining work co mmunication among team members is insufficient. The performance of distributed teams is affected by networking within the team and trust among members [ 54 ]. Lack o f visibility a mong business units was mentioned constantly d uring interviews as hindering synchronisation among business units. While separations among bu siness u nits may be necessary to organisational management, they cause several negative results in SW architecture design, the main one b eing the possibility of duplication of work, as th e teams ar e not aware o f each other’s work. Considering the amount of human resources and talent in the case company, there are good opportunit ies for knowledge-sharing among engineers. Even though the technology council and company-wide steeri ng group can prevent the large- scale d uplication o f effort, w ork stil l can be d uplicated on the micro-level. Closer interaction among architects in various business lines will facilitate the identification of resources su itable for a given task and , hence, get it d one more efficiently. Sin ce individual business lines evaluate their own performance, collaboration with other bu siness lines might not be high on their agendas. However, in the long run , business li nes and th e company as whole can benefit from a transparent approach. Taking the views of software architects and developers into consideration during the prio ritisa tion p rocess can contribute to reducing architectural technical debt considerably. Since it is the SW archit ects’ respon sibility to recognis e the ASRs that include NFRs and th eir effects on overall SW system architecture, architects are in the b est position to identify fac tors causing d ebt and manage th em to minimize accumulation o f architectural technical debt [ 57 ]. In th e context of iterative SW development, addressing architectural technical debt as a separate backlog item can en sure that it is addressed properly, as oth erwise, the cross- cutting n ature o f NFRs makes it difficult to add ress them pro perly at any given point [ 42 ]. Im proving trac eability across the SW development pro cess is important to understa nd th e implications of changing requireme nts for SW architecture and assessing possible architectural debt [ 27 ] . SW architects sh ould be encouraged to record design rationale by bein g given adequate tools [ 56 ]. In addition, a company-wide methodological approach to recording design rationale and maintaining necessary documentation should improve the quality of documentation and traceability of design rationale. Using the set o f tools, in cluding PM T, Wiki and a version control system, is a good m ove, as it helps m aintain con sistency and makes tool maintenance and support easier. However, to get th e maximum benefit from the tools, it is important to educate engineers and provide necessary train ing. In addition, filling gaps in the existing tool chain or introducing a new tool chain that provides end - to - end tool solutions would help address identified challenges. 7 THREAT S TO VALIDITY According to Yin a construct and external validity as well as reliability are necessary con ditions th at have to be taken into account when conducting case stud ies. Internal validity h as to be considered when conducting exploratory case studies. [ 60 ] Yin suggests using multiple sources of evidence, establishing the chain of events and having key informants to review case study report as tactics for ensuring construct validity in case stud ies. Internal validity can be addressed for example throu gh considering a rival explanation and using logical m od els. In this case study, t hreats to construct validity were mitigated by interview guide reviews done by pro fessors and representatives of th e case co mpany. At the beginnin g of ea ch interview, key terms related to th e study were defined and d iscussed to ensure a common vocabulary among researchers and interviewees. In addition, a p ilot interview was condu cted to get feedback from an expert. The case stu dy results were p resented in the case company in a workshop, where p ractitioners had an opportunity give feedback to the researchers abou t the study results. The case study report was delivered to the case co mpany representatives, including interviewees, an d they were asked point ou t any corrections needed for the report. Threats to internal validity must b e taken into account when studying causal relationships. This study aimed to explore the ch allenges to SW architecture posed by requirements volatility. Since SW development is affected by several other fac tors, too, there is no clear causal relation between requirements volatility and SW architecture challenges. The ex amples of these factors ar e technological changes and company strategies. However, this study addressed requirements volatility only . External validity relates to the generalisability of results. Traditionally, it has been s uggested that the generalisability of results from a single case study is rather p oor. [ 47 ] H owever, the results o f case studies may be extended to other cases that have common characteristics. [ 47 ] Seddon & Scheepers, suggest th at generalisation of results can b e done based on a single case study as lo ng as 1) a sample is carefully anal ysed, 2 ) relevant factors, which are tru e in a sam ple can be argued being true in larger similar context and 3 ) researchers seeking to generalise results discuss their findings in relation to p rior studies. [ 49 ] Considering the con text of the study it is expected that similar finding can be drawn when the following chara cteristics are present: a) glob ally distributed software d evelopment teams, b) a company operating in a dynam ic market, c) a large company structu red as autonomous units and d ) serving a diverse customer base . Threats to external validity were taken into account by co llecting data that Requirements Volatility in Software Architecture Design: An Exploratory Case Study ICSSP’17, July 05 -07, 2017 , P aris, France can be used to characterise the subjects an d case context. Examples of these data are experience o f th e interviewees in their field and in the company , team si zes, organisational structures and roles and the responsibilities related to them. Threats to reliability relate mostly to means of collecting and processing data. These threats were addressed b y the review of th e interview guid e and by agreeing upon a coding scheme prio r to analysis. 8 CONCLU SIONS AND FUT URE WORK This industrial case study was cond ucted to explore the challenges that requireme nts volatility p oses to SW architecture design. Fifteen SW experts involved in SW archit ecture design in various business units were interviewed using a semi-structu red interview as a guide. This study revealed factors causing req uirements volatility as the well as th e challenges posed b y the requirement volatility in the case company, which provides SW solu tions for companies and SW produ cts for consumers in a global market. Th rough the study important challenges th at requirements volatility poses to SW architecture d esign were id entified. Fin ally, th e means to address th e identified challenges were discussed. Som e factors, such as requirem ents un certainty or missing informatio n, the constant change o f priorities and shifting and com peting goals, are recognised as p reventing architects from analysing available options and taking the optim al c ourse of action in complex , real - world scenarios. As discussed, the context in which architecture is designed is very de ma nding, and architects prefer to compromise quality rather than in crease overhead. Ho wever, there is a possibility that the same factors that are considered advantages also affect architecture d esign negatively . Fo r example, even though light-weight d ocumentation is considered an advantage, it can contribute to requirements volatil ity and increase the risk of creating architectural technical debt. As software engineering researchers are increasingl y interested in the “twin p eaks” of the software development: requirements and architecture design. This study p rovided empirical evidence about the relationship between them and how the process changes in one can affect ano ther. The ultimate goal was to understand the complexity of th e development environment and issues the practitioners fa ce daily and thus propose fe asible solutions for industry. This case study p rovides an example f or practitioners how research may help to expose challenges, their reasons and impacts in the company. P ractitioners may consult the results of the case stu dy to id entif y si milarities and differences in their practices. This in turn helps to find improvem ent directions. In future research, another case study will be conducted in a company of different size and in a different domain to investigate whether the same challenges are present there. Cross analysis between the case studies will provide new in sights and help increasing the generalisability of the findings. Based on the results of those case studies, it is p lanned to develop a framework that provides means for practitioners to identify the p resence of challenges p osed by requirement volatility and take n ecessary steps to mitigate the risks. ACKNOWLEDG MENTS This work is funded by ITEA2 and Tek es - The F innish Funding Agency for Innovation, via the MERgE project. REFERENC ES [1] Ahmad, Z., Hussain, M., Rehman, A., Qa m ar, U., and Afzal, M. Impact minimization of requireme nts change in s oftware project through req uirements classification. In Proceedings of the 9th International Conference on Ubiquitous Informatio n Management and Communication ( 2015), 1-5. [2] Ahn, S. and C hong, K. Elicit ing potential req uirements with feature -oriented gap analys is. In Reuse of Off-the-Shelf Components ( 2006 ), Springer Berlin Heidelberg, 427-431. [3] Andres, H. P. A compariso n o f face- to -face and virtual so ftware develop ment teams. Team Performance Management: An Internati onal Journal , 8, 1/2 (2002), 39-48. [4] Andrews, A. A. a nd Pradha n, A. S. Et hical Iss ues in Empir ical So ftware Engineering: The Limits o f Po licy. Empirical Soft ware Engineering , 6, 2 (2001), 105-110. [5] Anish, P. R. , Balasubramania m , B., Cleland- Huang, J., Wiering a, R. , Daneva, M., and Ghaisas, S. Identifying architect urally s ignificant functional requirements. In Procee dings of the 5th Inter national Workshop on T win Peaks of Requirements and Architec ture (TwinPeaks' 15) (P iscataway, NJ 2015), IEEE Press, 3-8. [6] Anish, P. R. , Da neva, M., Cleland- Huang, J., W ieringa, R. J ., and Ghaisas, S. What you ask is what y ou get: Under standing architectura lly s ignificant functional require ments. In Requirements Engineering Conferenc e (RE) 23r d International ( 2015 ), IEEE, 86-95. [7] Bass, L., Cl ements, P., and K azman, R. Software Architecture in Practice . Addison-Wesley P rofessional, New Je rsey, 2012. [8] Bass, L., Nord, R., Wood, W., and Z ubrow, D. Risk themes discovered through architecture e valuations. In Soft ware Ar chitecture, 2007. WICSA '07. The Working IEEE/IFIP Confer ence on ( 2007), IEEE, 44-54. [9] Carlshamre, P., Sandahl, K., Lindvall, M., Regnell, B., and Nattoch Da g, J. An industrial survey of req uirements interdependencies in s oftware product release planning. In P roc. IEEE Int. Conf. on Requirements Engineering (Toronto, Canada 2001), 84 – 91. [10] Christel, M. G. and Kang, K. C. Issues in requirements elicitation . CM U/SEI- 92- TR -12, C arnegie-Mello n University, PITTSBURG H PA, 1992. [ 11 ] Cleland-Huang, J ., Hanmer, R. S., Supakkul, S., and M irakhorli, M. T he Twin Peaks of Requireme nts and Architecture. IEEE Sof tware , 30, 2 (March-April 2013), 24-29. [ 12 ] Clements, Paul, Kaz man, Rick, and Klein, Mark. Evaluating Software Architectures: Methods and Case Studie . Addison-Wes ley Professional, 2001. [ 13 ] Clements, Paul, Kazman, Rick, Klein, Mark, Devesh, Divya, Redd y, Shivani, and Ver ma, Prageti. The Duties, Skills, and Knowledge o f Software Architects. In Proceedings of the Working IEE E/IFIP Conferenc e on Software Architecture ( 2007), IEEE. [ 14 ] Cunningham, W. The WyCash Portfolio Mana gement System. ( 1992), ACM. [ 15 ] Dasanayake, S., M arkkula, J., Aaramaa , S., and Oivo, M. Software Architecture Decision-Making Practices a nd Challenge s: An Indu str ial Case Study. In 24th A ustralasian Soft ware Engineer ing Confer ence (Adelaide 2015 ), TBD. [ 16 ] Firesmith, D. Are Yo ur Req uirements Complete? Journal of object technology , 4, 1 (2005), 27-43. [ 17 ] Fowler, M. Is design dead? In Succi, G. and Marchesi, M., eds., Extreme programming examined . Addiso n-Wesley Lo ngman Publishing Co. I nc., Boston, 2001. [ 18 ] Geer, D. and Ruhe, G. Software release planning: An evolut ionary and iterative approach. Informati on and Software Techn ology , 46 (2004), 243-253. [ 19 ] Gil, N. and Beck man, S. Des ign reuse and buffers in hig h-tec h infrastruct ure development: A stakeholder perspective. Engineering Management, IE EE Transactions on , 54, 3 (2007), 484-497. [ 20 ] Gubrium, J. F. a nd Holste in, J. A. Handbook of Intervie w Research. Contex t & Method . Thousand Oaks : Sage Publications , 2002. ICSSP’1 7, July 05- 07 , 2017, Paris, France S . Aaramaa et al. [ 21 ] Hickey, A. M. and Davis, A. M. Requirements e licitation and elicitatio n technique se lection: model for two knowledge -intensive so ftware develop ment processes. In System Sciences, 2003. Proceedings of the 36th Annual H awaii International Confere nce on IEEE ( 2003 ). [ 22 ] Hintersteiner, J. D. Addressing c hanging customer needs b y adapting design requirements. In Proceeding of ICAD200 0, 1st International Conference on Axiomatic Design ( 2000), 21-23. [ 23 ] Huo, M., Verner, J., Z hu, L., and Babar, M. A . Software quality a nd agile methods. In Compu ter Soft ware and Applications Confere nce, 2004. COMPSAC 2004. Proceedings of the 28th Annua l Internationa ( 2004), IEEE, 520-525. [ 24 ] Jansen, Anton a nd Bosc h, Jan. Software Architec ture as a Set of Architectural Design Dec isions. In Proceedings of 5t h Working IEEE/IFI P Conference on Software Architecture ( 2005), IEEE. [ 25 ] Javed, T., Ma nzil e, M., and Durra ni, Q. S. A St udy to Investig ate the I mpact of Requirements Instab ility on Software Defec ts (2004), 1-7. [ 26 ] Jiang, T . M. and Coyner, M. Software process disturba nces. I ncompsac ( p. 167). IEEE. In Compu ter Software and Applications Conference, 2000. COMPSAC 2000. The 24th Annual Inter national ( 2000 ), 167-168. [ 27 ] Klinger, T., Tarr, P., W agstrom, P., and Williams, C. An enterprise perspective on technica l debt. In Proceedings of the 2nd Workshop on managing tec hnical debt ( 2011), ACM, 35-38. [ 28 ] Korkala, M., Abrahamsso n, P., and Kyllö nen, P. A case s tudy on the impact o f customer communication on defects in agile software develop ment. In Agile Conference, 2006 IEEE ( 2006). [ 29 ] Kotonya, G. and Sommerville, I. Requir ements Engineering - Proce ss and Techniques . J ohn Wiley & Sons Ltd, West Sussex, 2003. [ 30 ] Kruchten, P. , Nord, R. L., and Ozkaya, I. Technical debt: from metaphor to theory and practice. IEEE Software , 29, 6 (2012), 18-21. [ 31 ] Lauesen, S. Software Requirme nents - Styles and Techniques . Addison-Wesley, London, 2002. [ 32 ] Leffingwell, D. and Widrig, D. Managin g Software Requirements: a us e case approach . Pearson Education, Inc., Boston, 2003. [ 33 ] Li, Z., Liang, P., and Avgerio u, P. Architectural debt management in value - oriented architect ing. In Economic s-Driven Soft ware Architecture . Elsevier, Boston, 2014. [ 34 ] Macaulay, L ., Fow ler, C. , Kirby, M., and Hutt, A. US TM: a new approac h to requirements spec ification, Interacting with C omputers (1990), 92 -118. [ 35 ] Maciaszek, L. Requirements Analysis and System Design . Pearson Ed ucation, Harlow, 2005. [ 36 ] Martini, A., Bosch, J ., and Cha udron, M. Architecture technical debt : Understanding causes and a qualitative model . In Soft ware Engineer ing and Advanced A pplications (SEAA), 40th EUROMICRO Confere nce on ( 2014), IEEE, 85-92. [ 37 ] Miller, Ja m es A., Ferrari, Remo, a nd Madhavji, Naz im H. An explorato ry study of arc hitectural e ffects o n requireme nts decis ions. Jour nal of Sy stems and Software , 83, 12 (2010), 2441 – 2455. [ 38 ] Mundlamuri, S. M anaging the Impact of Requirements Volatility . Department of Computing Sc ience, Umeå, Sweden, 200 5. [ 39 ] Na, K . S., Li, X., Simpson, J. T ., and Kim, K . Y. Uncertainty profile a nd software project perfor mance: A cross-national comparison. Journal of System s and Software , 70, 1-2 (2004), 155-163. [ 40 ] Nidumolu, S. R. Standardizatio n, requirements uncertainty and so ftware project performance. Informatio n & Management , 31, 3 (1996), 135-150. [ 41 ] Niu, N., Da X u, L., Cheng, J. R. C., and Niu, Z. Analys is of architecturally significant require ments for ente rprise s ystems. System s Journal, IEEE , 8, 3 (2014), 850-857. [ 42 ] Nord, R . L., Ozkaya, I., Kruchten, P., and Gonzalez-Rojas, M. In se arch of a metric for mana ging a rchitectural technical debt. In Soft ware Architecture (WICSA) and European Confer ence on S oftware Architecture ( ECSA), 2012 Joint Working IEEE/I FIP Conference on ( 2012), 91-100. [ 43 ] Nurmuliani, N., Zowghi, D., and Williams, S. P. Requirements volatilit y and its impact on change effort: Evidence-based research in software development projects. ( 2006). [ 44 ] Nuseibeh, B. Weaving to gether requirements and architect ures. Computer , 34, 3 (2001), 115 - 119. [ 45 ] Pfahl, D. and Lebsa nft, K. Using s imulation to a nalyse t he impact of software requirement volatility on project performance. Informa tion and Software Technology , 42, 14 (2000), 1001-1008. [ 46 ] Rolland, C., Salines, C., and Etien, A. E liciting gaps in requirements c hange. Requirements Engineer ing , 9, 1 (2004), 1-15. [ 47 ] Runeson, P., Höst, M., Rainer, A., and R egnell, B. Cas e Study Res earch in Software Engineering : Guidelines and Exa mples . Wiley, 2012. [ 48 ] Sage, A. P. Systems engineering . John Wiley & Sons, New York, 1992. [ 49 ] Seddon, P. B. and Scheepers, R. Towards the impro ved treat ment o f generalization of k nowledge claims in IS re search: drawing general conclusions from samples. EJIS , 21, 1 (2012), 6-21. [ 50 ] Shachaf, P. C ultural divers ity a nd informatio n and co mmunication techno logy impacts on globa l virtual teams: An exploratory study. Information & Management , 45, 2 (2008), 131-142. [ 51 ] Singh, M. P. and Vyas, R . Requirements Volatility in s oftware deve lopment process. Inter national Journal of Soft Com puting , 2, 4 (2012), 259-264. [ 52 ] Stark, G. E., Oman, P., Skillicor n, A., and Am eele, A. An e xamination of the effects o f req uirements c hanges on softwa re maintenance re leases. Journal of Software Maintenance: Research and Practice , 11, 5 (1999), 293-309. [ 53 ] Stephenson, Z., Attwood, K., and McDermid, J . Product -Line Models to Address Requirements Uncerta inty, Volatility and Risk. In Relating Relati ng Software Requirements and Architectures . Springer Ber lin Heidelberg, 2011. [ 54 ] Strigini, L. Limiting the Da ngers o f Intuitive Decision M aking. IEEE Software , 13 (1996), 101-103. [ 55 ] Systems a nd software engineering — Arc hitecture des cription. ISO/IEC/IEEE 42010:2011(E) (2011 ). [ 56 ] Tang, A., Babar, M. A., Gorton, I., and Han, J . A survey of architecture des ign rationale. Journal of systems and software , 79, 12 (2006), 1792-1804. [ 57 ] van Heesch, U. an d Avgeriou, P. Mature architecting - a survey about t he reasoning process of professional architects. In 9th Working IEE E/IFIP Conference on Software Architecture ( 2011), 260 – 269. [ 58 ] Wang, J., Li , J., Wang, Q., Zh ang, H., and Wang, H. A Si mulation Approac h for Impact Analysis of R equirement Vo latility Considering De pendenc y Change. I n Requirements Engineering: Foundation for Software Quality . Springer Berlin Heidelberg, 2012. [ 59 ] Wiegers, Karl E. Soft ware Engineer ing . Microsoft Press , Redmond, Washington, 2003. [ 60 ] Yin, R. K. C ase Study Research: Design and Methods . SAGE Publications, 2008. [ 61 ] Zowghi, D. and Nurmuliani, N. A st udy of the i mpact of require ments volatility on so ftware project performance. In S oftware Engineering Confer ence, 2002. 9th Asia-Pacific ( 2002), 3-11.