Design for Excellence in the Context of Very Large-scale

Requirements Engineering

Sanja Aaramaa, Samuli Saukkonen, Jarkko Hyysalo, Jouni Similä, Pasi Kuvaja and Markku Oivo

University of Oulu, Department of Information Processing Science, M-Group, P.O. Box 3000 FIN-90014, Oulu, Finland

Keywords: DfX, Very Large-scale Requirements Engineering, ICT.

Abstract: The increasing complexity of software-intensive systems (SIS) has led to a completely new concept: Very

Large-Scale Requirements Engineering (VLSRE), where the sheer number of requirements typically

exceeds 10,000. Design for eXcellence (DfX) principles and their execution have been studied in different

contexts for decades. However, DfX has not been in the focus of the Requirements Engineering (RE)

process, and especially not in the VLSRE context. This paper addresses the DfX topic through an empirical

study of the DfX RE-process and practices in a large global ICT organisation operating in the VLSRE

mode. The result of this study is a conceptual framework that helps to overcome the challenges identified,

leading towards changes in the operational procedures of the DfX RE-process, accommodating the

requirements of very large-scale development. The piloting of the framework has been started in the case

company, and initial feedback has been positive. The findings of this study offer new insights for scholars

and practitioners.

1 INTRODUCTION

Competition is severe in the information and

communications technology (ICT) industry. In order

to beat its competitors, a company should be the first

to bring products to the market, which causes time

pressure for the product life cycle. On the other

hand, the provided systems should meet the desired

quality or “-ilities” in general.

Due to the increasing complexity of software-

intensive systems (SIS), the number of incoming

requests or requirements is increasing (Gorschek and

Wohlin, 2006). Naturally, all requirements cannot be

implemented at once. Requirements need to be

prioritised and the release chosen in which the

selected requirements are finally implemented

(Wohlin and Aurum, 2005). The number of internal

and external stakeholders, resources and technical

constraints needs to be taken into account when

decisions are made on the order of implementing the

requirements (Geer and Ruhe, 2004). Decision-

making is not a trivial task, especially early in the

process, since information available for the decisions

is often abstract and uncertain (Ngo-The and Ruhe,

2005).

The concept of Very Large-Scale Requirements

Engineering (VLSRE) was introduced by (Regnell,

et al., 2008), and the measure used to define the

scale of RE has been set, based on the number of

requirements in a database. In the case of VLSRE,

the number of requirements typically exceeds

10,000. In addition, the very large number of

requirements also implies more involved

stakeholders and connections between requirements

(Regnell et al., 2008).

The requirements inevitably change during the

project, and the requirements are sometimes hard to

predict (Abran, et al., 2004). Managing the changes

and bringing all the necessary views of the internal

and external stakeholders into the final system is a

demanding task for RE and the design process.

Design for eXcellence (DfX) is a means to cope with

this challenge. It is a knowledge-based approach that

drives design to optimise the desired characteristics

of the product and to minimise overall lifetime costs,

including, for example, manufacturing costs (Bralla,

1996). Examples of DfX viewpoints and published

research are assembly (DfA) (Dalgleish, et al.,

2000), environment (DfE) (Cooper, 2004) and

reliability (DfR) (Xuan, et al., 2006).

DfX has been studied from different viewpoints,

such as quality (Booker, 2003), manufacturing

(Mottonen, et al., 2009) and sustainability

(Mottonen, et al., 2010). It has been applied in

various industrial domains, like automotive

196

Aaramaa S., Saukkonen S., Hyysalo J., Similä J., Kuvaja P. and Oivo M..

Design for Excellence in the Context of Very Large-Scale Requirements Engineering.

DOI: 10.5220/0005502101960207

In Proceedings of the 10th International Conference on Software Engineering and Applications (ICSOFT-EA-2015), pages 196-207

ISBN: 978-989-758-114-4

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

(Krumenauer, et al., 2008) and new product

development (Shih-Wen, 2002). Tools have been

developed for DfX (Xie, et al., 2004), and

organisational aspects have been published

(Hyysalo, et al., 2009). However, DfX is not widely

studied from an RE perspective, and especially not

in the VLSRE context.

There are a few articles discussing DfX in RE,

which suggest that DfX is also a tangible way to

manage, coordinate and communicate requirements

in a product development lifecycle, through the

whole development chain. It is very useful, for

example, in requirements prioritisation, as it takes

into account different stakeholders’ views in a

commensurable way. Therefore, DfX can be used to

structure RE activities and practices (Mottonen, et

al., 2009) (Hyysalo, et al., 2009) (Lehto, et al.,

2011).

The aim of this research is threefold. First, the

study provides a rich description of the DfX RE-

process in the context of VLSRE in a large ICT

company. Second, it identifies and analyses the

challenges in the DfX RE-process. Third, as a

conclusion based on empirical data and literature,

this paper proposes a conceptual framework that has

been constructed to overcome the challenges. Thus,

the following research questions have been

formulated:

RQ1: How can a DfX RE-process be organised

effectively in industry?

RQ2: What are the challenges relating to the

DfX RE-process?

By answering these questions, a rich picture of

the DfX RE-process and its challenges can be

obtained in the context of VLSRE. The next step is

to study how to tackle these challenges, which is

done by answering the third research question of a

constructive research nature:

RQ3: How does one construct a framework to

overcome the challenges of the DfX RE-process?

2 RELATED WORK AND KEY

CONCEPTS

In the early 1990s, it was proposed that software

engineering and systems engineering should be

combined into a new discipline: software systems

engineering. The rationale behind the proposal was

that both of the mentioned disciplines address the

creation of a complex SIS (Stephen, et al., 1993). RE

is a branch of systems engineering containing

requirements development and management

(Wiegers, 2003) (Aurum and Wohlin, 2003), where

requirements are formed through a requirements

development process that includes activities related

to eliciting, analysing, documenting and validating

requirements (Wiegers, 2003) (Potts, 1995).

The requirements management process focuses

on maintaining the requirements (Aurum and

Wohlin, 2003). Many authors (Wiegers, 2003)

(Maciaszek, 2005) (Lauesen, 2002) emphasise the

nature of change in RE; thus, the requirements

management process is defined as a process of

managing changes to the requirements (Kotonya and

Sommerville, 2003). However, it has also been

claimed that requirements management includes all

RE phases from elicitation to maintenance

(Leffingwell and Widrig, 2003).

It has been pointed out that existing research

efforts that attempt to validate tools or methods used

in RE are based on small- or medium-scale RE.

Consequently, most existing tools or methods are

not applicable in VLSRE (Regnell, et al., 2008).

Since the introduction of VLSRE, research has been

conducted, for example, on aligning the RE and

verification (Sabaliauskaite, et al., 2010), on

organising traceability between requirements, on test

specifications (Leuser and Ott, 2010), on linking

customer wishes to product requirements through

linguistic engineering (Natt och Dag, et al., 2005)

and on requirements scoping (Wnuk, et al., 2009).

Tools and methods have been proposed to tackle the

issues with the large sets of requirements (McZara,

et al., 2014)

DfX is an approach to designing products to

meet desired “-ilities”, taking into account the

product life-cycle and means of ensuring the cost-

effectiveness of the development, delivery and

disposal of the product (Pun, 2006). The roots of

DfX originate in an idea of serving internal

customers regarding manufacturability and value

analysis (Huang, 1996). However, the term “design

for” was first used with assembly (DfA) by

(Boothroyd and Dewhurst, 1983). Design for final

assembly (DfFA) and board assembly (DfBA)

(Mottonen, et al., 2010) are recently introduced

terms, and different “design for” domains have

emerged through the decades. Examples of these are

design for packaging (DfP) (Hemmings, 1974) and

design for supply chain management (DfSM) (Lee

and Billington, 1992). A discipline design for

security (DfSec) regarding the physical security of

facilities was discussed as early as the 1960’s

(Healy, 1968), while design for software security

DfsSec was introduced a few years ago

(Ramachandran, 2011). One of the emerging topics

DesignforExcellenceintheContextofVeryLarge-ScaleRequirementsEngineering

197

of the century is design for e-commerce (DfeC),

while design for serviceability (DfS) is an example

of early considerations. Design for delivery

competence (DfD) as a discipline has not been

discussed, but the aspects of it are related to those

considered for logistics (De Hayes and Robert,

1972) and supply chain management (Lee and

Billington, 1992). One common aspect for the

majority of the mentioned DfX disciplines is that

they are tightly connected with the engineering

(HW) domain. In the case company, comparable to

literature DfX disciplines exist; however, in the case

company, the DfX disciplines have a stake in SW

development too, not just in HW.

Applying DfX principles reduces the time-to-

market, lowers life-cycle costs and increases the

quality of the developed products (Maltzman, et al.,

2005). On the other hand, the purpose of RE is to

provide business value for the company, focusing on

an expected value for different stakeholders (Aurum

and Wohlin, 2007). Further, the quality of the

developed system has been argued to be dependent

on the quality of the development process as a whole

(Strigini, 1996), and on the quality of the

requirements (Ruhe and Saliu, 2005). The needs of

internal customers were first considered in

manufacturing and assembly (Huang, 1996).

A few papers address DfX in the context of

Software Engineering and RE. According to (Lehto,

et al., 2011), DfX is a way to address the needs of

internal customers and manage requirements during

a product development process. Through DfX,

requirements can be treated in equal terms. A study

by (Mottonen, et al., 2009) highlighted the

importance of a dedicated function to manage

requirements from internal customers.

Problem domain, solution domain (Hall, et al.,

2002) and stakeholders (Maciaszek, 2005) are

fundamental concepts in RE. The problem domain is

the bounded part of reality where the problem is

defined. Usually, the realised problem should be

solved by a system or a product (Jacobson, et al.,

1999). The proposed settlement of the challenges of

the problem domain is defined in the solution

domain, where the solution domain is the

developers’ and designers’ sandbox. In both

domains, the language and semantics originate from

the stakeholders, so concepts and entities in domains

are usually unique. The terminology used may be

contradictory within and between the domains.

The stakeholders are people who have a stake in

the system, and they are usually divided into

external and internal stakeholders. The two main

groups of stakeholders are customers and developers

(Maciaszek, 2005). Examples of external

stakeholders are legislators, system users or system

owners on the customer site. Internal stakeholders

are, for example, system designers, engineers and

different specialists. A wider perspective defines a

stakeholder as a group or an individual who is

affected by the achievement of the organisation’s

objectives, or a group or an individual who can

affect them (Freeman, 1984). DfX is a means to

present stakeholder views using company terms

which, in commensurable form, are meaningful to

the systems provider (Hyysalo, et al., 2009) (Lehto,

et al., 2011). Having stakeholder views represented

by various DfX disciplines, representing different

views to product development, could be a means to

form a bridge between the solution and problem

domains.

Operations is usually defined as an

organisational unit responsible for managing and

running the processes, which in turn input into

physical products or systems. Operations includes

production (manufacturing, assembly and testing of

systems and components). It also takes care of

logistics and distribution, and is involved in

decision-making to transform designs into systems

and services. Operations aims to reduce defects and

costs by paring unwanted variability and uncertainty

in product delivery, and still maintaining constant

output and high quality (Dodgson, et al., 2008). The

benefit of coordinating DfX within operations has

already been demonstrated in (Hyysalo, et al., 2009)

and (Lehto, et al., 2011); however, in this paper, the

intention is to go further and describe the DfX RE-

process as part of VLSRE and a framework to

overcome identified challenges.

3 RESEARCH PROCESS

The research process is shown in Figure 1, and the

research was conducted following the case study

process steps defined in (Runeson and Höst, 2009).

The case is a holistic case study, and the case

company is a large business-to-business operating

enterprise. This company is a typical enterprise in its

market sector, which provides software intensive

systems and services for a global market. The case

company operates in the ICT sector, and has

successfully followed DfX principles for over a

decade. An overall RE-process in the case company

consists of several processes, in which the number of

requirements related to systems and services clearly

exceeds the definition of VLSRE (Regnell, et al.,

2008). The case concerns the DfX RE-process,

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

198

which is one of those processes. The purpose of the

DfX RE-process is to define requirements

concerning a large group of internal and external

stakeholders.

Figure 1: Research process (Runeson and Höst, 2009).

In the design phase, the objectives of the case and

research questions were determined; and the

theoretical background, research methods and

sources were chosen. The preparation phase

included questionnaire development, decisions on

who should be interviewed and agreement on

procedures and schedules. During the collection

phase, the data was gathered via 20 qualitative

interviews (first-degree data), archived materials and

literature (third-degree data). The interviews were

transcribed and analysed first by the DfX discipline,

and then cross-analysed based on themes like

organisational aspects and processes.

3.1 Case Design and Data Collection

The data gathered and analysed in this case study

originates from three main sources: 1) archived

material provided by the case company in advance

and by the interviewees, 2) interview recordings and

transcriptions and 3) scientific literature. The case

company delivered background material in advance

for the researchers to familiarise themselves with the

company’s DfX organisation and practices before

the interview questionnaire was prepared. The

interviewees also provided some clarifying examples

on the topics discussed during the interview. The

examples of the provided company material are

process descriptions, organisational charts and

design principles. The duration of the case study was

five months from the first workshop until the final

report was delivered to the case company. During

that time, weekly meetings were held and at least

one representative from the case company

participated in each meeting. This provided a good

opportunity for the researchers to discuss in quick

cycles any unclear issues encountered during the

case. Weekly meetings were also recorded and

transcribed, and this material was used on need

bases to support the analysis and writing of the

report.

The richest information about the DfX RE-

process was gained through 20 qualitative, semi-

structured and thematic interviews (Gubrium and

Holstein, 2002) in the case company (Table 1). The

themes discussed were RE concepts used in the

company, types of requirements, stakeholder aspects

and utilised tools. The interviewees where located in

two countries and in five different sites, and were

confident in the researchers, since the researchers

worked under a non-disclosure agreement and

ensured that the gathered data was always handled

anonymously. The first version of the questionnaire

was updated based on the first four interviews. The

changes were minor; few words were changed, and

examples and two small questions were added. The

questionnaire was sent in advance to the

interviewees so they could prepare themselves for

the interview and finish the interview within the

given time limits. The interviews were face to face,

except for two interviews (one over the phone and

one in a video meeting). They were completed in

one month and the average duration of each

interview was a bit over one hour. The interviews

were conducted on the case company’s premises to

save the interviewees’ time and make participation

as easy as possible for the interviewees. All

interviews were recorded and transcribed. Two or

three interviewers were assigned for each interview,

and one of them did the first summary. The purpose

of the summaries was to condense the main points of

each answer, to be checked by the interviewees. The

summaries did not contain any conclusions or

interpretations by the researchers.

Table 1: Interview summary.

Int. Role Durat./ Exec.

1 DfS manager 70 min/ F2F

2 DfS team member 79 min/ F2F

3 DfP manager 88 min/ F2F

4 DfFA manager 51 min/ F2F

5 DfE manager 72 min/ F2F

6 Testing technology expert 70 min/ F2F

7 Product line expert 96 min/ F2F

8 DfeC manager 61 min/ F2F

9 DfSM manager 55 min/ F2F

10 DfR manager 88 min/ F2F

11 DfBA manager 59 min/ F2F

12 DfD manager 66 min/ F2F

13 DfsSec manager 55 min/ Phone

14 DfsSec team member 60 min/ F2F

15 DfD RE-process 35 min/ F2F

16 DfX RE-process expert 65 min/ Video

17 DfD SW expert 61 min/ F2F

18 DfD SW member 34 min/ F2F

19 Product development process expert 79 min/ F2F

20 Head of DfX managers 120 min/ F2F

3.2 Analysis and Validity Procedures

The interviews were grouped by the DfX discipline,

DesignforExcellenceintheContextofVeryLarge-ScaleRequirementsEngineering

199

and the data was used to describe each discipline.

For each discipline, the flow of requirements, that is,

the input and output data, was determined, its

stakeholders were identified and the SW-related

issues were recorded. The challenges in each

discipline were identified and solutions were

proposed. The interview data was cross analysed by

re-grouping the interviews based on for example

processes, research, platforms and product life-cycle

phases.

The analysis involved comparing the empirical

evidence with the existing literature and archival

data provided by the case company and by the

interviewees. Finally, the common denominators

across all disciplines were identified, for example,

on requirements, communication, organisation, DfX

concept and tools. The major and minor challenges

were listed for each topic, and solution ideas were

proposed.

The recorded and transcribed interviews

provided rich authentic data. The interview

transcriptions and first summaries were emailed to

the interviewees within two weeks, and the

interviewees were asked to validate the data within

one week. Four interviewees made minor comments,

such as explaining the abbreviations. Otherwise, the

interviewees replied that the gathered information

was correct.

After that, the data was analysed based on the

DfX disciplines, and then, the analyses were sent to

the interviewees. They were given one week to

validate, comment and correct the analyses. None of

the interviewees commented on the content.

The case report for the company was written

based on the analysis of the interview data, material

provided by interviewees, company materials and

literature. The results were presented in a seminar

organised in the case company. This seminar was

recorded and transcribed to capture the feedback that

was analysed to validate the results.

4 RESULTS AND ANALYSIS

4.1 DfX RE-process

In the case company, the DfX concept is divided

into disciplines according to knowledge and

technology platforms. Examples of the disciplines

are design for assembly and design for

serviceability. The platforms include a product or a

system, and process expertise. Operations’ platforms

are Manufacturing, Sourcing and Delivery. The

disciplines are led by the DfX managers, and the

head of the DfX managers has the responsibility for

the overall concept. Close co-operation between

different DfX disciplines is required to manage

common issues, and the co-operation is organised

thorough efficient networking. In the case company,

the DfX concept runs the DfX RE-process to

produce requirements concerning their views on the

products and their development process, in order to

cover the views of external stakeholders the

disciplines represent.

Operations aims to maintain platforms, for

example, by keeping a list of recommended

components and ensuring standardised

manufacturing, delivery and sourcing processes.

DfX stresses the optimised use of products and

platforms, as well as the implementation of best

practices, for example, in sourcing, services and

environmental management. In order to achieve the

efficiency goals, both the Operations and product

creation processes must be managed effectively. In

principle, DfX has the same goals, but has a wider

scope, taking into account the whole product life-

cycle and the customers’ costs.

Traditionally, DfX has been considered to be an

R&D-driven design approach. In contrast, our

industrial case differs significantly; the DfX

principles are applied by Operations’ DfX capability

management to the DfX RE-process. During the

DfX RE-process, the SIS are not designed, but

requirements are set for the design, development,

delivery, maintenance, service and disposal of SIS.

Another difference is that the problem domain

and solution domain must be looked at in a new

light, since DfX management operates and

influences in both domains. In the case company, the

DfX capability management organisation has a

global responsibility for running the DfX RE-

process. The DfX management organisation elicits,

for example, the raw requirements and constraints,

and identifies challenges, for instance, in the SIS

(through testing), development and delivery

processes. However, the DfX teams within each

discipline analyse the elicited data to look for

solutions to the identified problems. This is clearly a

solution domain issue.

In the analysis phase, the feasibility of the

requirements is analysed, taking into account, for

example, the available resources, risks and costs

from an Operations’ point of view. The business

evaluation is done to convince product managers in

a requirements negotiation phase and to affect the

requirements prioritisation. The analysed data is

written down as guidelines or well-formed

requirements that ought to be followed or

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

200

implemented in the product design, feature

specification and product creation processes. Many

of the DfX requirements are constraints from the

product creation, maintenance and delivery process

viewpoints. The well-formed requirements and

guidelines are globally reviewed to validate that the

needs of the relevant stakeholders are formulated as

requirements, or that their viewpoints have been

taken into account in the guidelines. During the

global review, the goals of the DfX disciplines are

agreed-upon, and they are explained in the DfX

feasibility study. DfX management operates in the

solution domain, as well as via dedicated DfX

advocates, who ensure that the minor modifications

are taken into account when the program plan is

created, and that plan, in general, is in line with

Operations’ goals. The DfX advocates are also

responsible for seeing that DfX requirements are

implemented and maintained based upon agreed-on

platform specifications. The number of requirements

is immense, and to choose the set of requirements

that will be implemented by program releases, the

requirements need to be prioritised. In this task, the

internal stakeholders’ requirements are often

overlooked in comparison to the (paying) customers’

requirements. The guidelines are used to influence

the decisions made in the product creation process.

Those well-formed requirements that need to be

further analysed, taking into account SIS content on

the large scope, are fed into feature specification.

The results of the feature specification are stored in a

database as feature proposals that are used in the

product creation process. Figure 2 illustrates the

studied DfX RE-process.

Figure 2: The simplified illustration of the common parts

of the DfX RE-process.

4.2 Identified Challenges

Based on the interviews, the common challenges for

all disciplines were divided under the DfX RE-

process phases and some other general themes. It is

possible that some of the themes overlap, and

common issues are presented. The fundamental

reasons behind the challenges are traced and

discussed in relation to the literature, and

recommendations are provided to address the

identified challenges.

Requirements elicitation and analysis. One of

the widely acknowledged challenges in RE is that

requirements tend to be unclear and incomplete at

the beginning of the process. This issue is also

denoted as ambiguity in the literature (Paasivaara

and Lassenius, 2004). One way to address the

challenge is to establish a practice to systematically

gather stakeholder requests in a commensurable

form. The DfX RE-process is a way to gather

requirements from platforms, and communicate

those to the SW development process. However, it

was noted that the rationale behind the requirements

is often missing, which leaves room for

improvement in the requirement analysis and

documentation. Argumentation regarding risk

management has been discussed in (Heindl and

Biffl, 2006). It is suggested that the rationale is a

mandatory part of a requirement description.

Requirements prioritisation. The DfX RE-

process provides input program requirements, which

are included in a program plan. Development in

programs is done in releases, implementing a subset

of requirements in each release. Requirements are

prioritised by program teams; however, in a VLSRE

context, DfX managers do not have visibility of the

prioritisation criteria and process. Practical

challenges in requirements prioritisation are

discussed in (Lehtola, et al., 2004). The QUPER

model has been suggested in (Svensson, et al., 2008)

to support release planning with regard to quality

requirements. Prioritisation criteria should be

created to support the aspired added values of both

internal and external stakeholders. The interviews

revealed the fact that DfX disciplines face

challenges in creating a winning argumentation from

a business view to achieve high priorities for DfX

requirements. Literature acknowledges this dilemma

(DeLain and O'Meara, 2004). There are different

types of requirements, like business and product

requirements (Lauesen, 2002); therefore, stakeholder

views, and consequently their requirements, often

conflict (van Lamsweerde, et al., 1998), for

example, in usability and security. It is suggested

DesignforExcellenceintheContextofVeryLarge-ScaleRequirementsEngineering

201

that practical support for business argumentation

is created, including requirement categorisation,

to enhance analysis and prioritisation tasks.

Requirements validation. The DfX RE-process

produces companywide guidelines to be utilised in

product design and development. The case company

has established a global review process for

guidelines; however, reviews are not always

conducted. The company should decide on which

levels reviews are really needed, and then

practices should be harmonised. Literature on

design reviews should provide scientific

suggestions for the situation.

Requirements negotiation and communication.

During the interviews, it was observed that DfX

requirements should be taken into account early in

the product development process. This is due to the

nature of the DfX requirements, which are often

constraints in nature, and based on standards or

regulations. However, the DfX concept in the case

company’s VLSRE context does not have the means

or authority to get its requirements accepted at the

right levels. This means, if the guidelines are not

taken into account when making strategic decisions,

their influence in the programs cannot be ensured.

Therefore, the DfX requirements are often

overlooked by the product management (PM)

due to short term business impact goals. Heavy

lobbying is done to affect requirement priorities;

however, such an activity cannot be seen as a

successful strategy in the long run. It is also noted

that missing requirements early in the process is one

of the costliest changes to fix later on in the process

(Nurmuliani, et al., 2006).

Requirements documentation and tools.

Requirement management and communication in the

case company is largely document based, even

though tools are available. By document based, it is

meant that (for example) guidelines are Word

documents, which are then stored in the company

databases. During the programs, the requirements

are recorded in excel sheets, which are updated

according to changing priorities. Some issues were

identified regarding the documentation and the tools.

Employees often consider a document based process

to be laborious; thus, important updates and

revisions of documents are easily neglected. This

leads to the challenges related to poor and

inadequate documentation (Herbsleb and Moitra,

2001). A shared understanding about requirements

and proper documentation may be achieved through

training, adequate templates and improving

visibility. It was learned that there are several tools

that are utilised for requirements management. The

DfX RE-process has its own tools and databases,

while the PM has its own and product programs

utilising yet another set of tools. One example is that

some product teams use legacy tools, while others

use the one chosen as a global company tool. The

utilised tools, their implementation or usage cause

challenges. If the tools do not match the needs of

their users, many manual actions are needed

between process steps, or when communicating

between the processes. For example, in one tool, the

export functionality does not provide output, which

could be uploaded to the next process as such. There

are several studies pointing out tool related issues,

for example, (Herbsleb and Moitra, 2001), (Ebert

and De Neve, 2001), (Braun, 2003), (Maznevski and

Chudoba, 2000) and (Herbsleb, et al., 2001). It is

suggested that a unified database for diverse

requirements be established. To reduce the

number of documents in the process, an

electronic idea feeder (unifying information

channel), which supports the variety of

requirements and large attachments provided by

customers, should be developed. The

documentation created during the DfX RE-process is

a common documentation style, since it covers a

large group of internal stakeholders and platform

expertise.

Processes and practices in general. Different

teams have customised the defined global processes,

practices and tools fitting their specific needs.

However, in the VLSRE context, the processes have

synchronisation points, or they may be seen as the

consecutive phases of product development. In these

situations, tailored ways cause challenges. Similar

issues have been reported in, for example,

(Paasivaara and Lassenius, 2004) and (Battin, et al.,

2001). The common practices and ways of

working should be agreed upon and maintained.

The DfX process is systematically managed

throughout the disciplines; however, the

synchronisation with other processes is diversified.

Organisation and roles. The company has

experienced several significant organisational

changes over the past few years. Due to these

constant changes, the roles and responsibilities are

not clearly defined, and some of the positions have

not been filled. Aspects of organisational issues have

been discussed in, for example, (Herbsleb, et al.,

2001), (Gray, 1989) and (Tiikkaja, 2002). It is

suggested that the roles and responsibilities be

defined. This is a time consuming task, which

requires various kinds of expertise from the

company, but should pay back the effort through

well organised VLSRE.

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

202

4.3 Framework for the VLSRE

In the context of VLSRE, the requirements are not

developed and managed through one RE-process,

but several connected processes. The DfX RE-

process presented in this paper is one of those

processes. It provides requirements, for example, for

the feature specification process. The experience

gained from industry co-operation indicates that

other internal and external stakeholders run their

own RE-processes. The outputs of the stakeholder

specific RE-processes vary from full requirement

specifications to the high level description of a

market need. The developed VLSRE framework

includes identified internal and external

stakeholders, defines their (RE) processes and

establishes a unified information channel for

requests. In addition, it identifies the “receiver”

processes and their needs regarding the

information provided by stakeholder specific

(RE) processes. The framework suggests that the

requirement data structure should have two

major parts: a) basic data common for all types

of requests and stakeholders and b) categorised

data depending on the receivers’ information

needs. The unified information channel enables the

gathering of data systematically from all sources. It

also provides a commensurable form for

documenting request data, and thus, enhances

decision-making and prioritisation. See Figure 3.

Figure 3: The simplified illustration of the VLSRE

framework.

The developed framework addresses some of the

identified challenges in the VLSRE context. The

framework acknowledges different stakeholders and

their needs for products and their development

process. The interviewees mentioned that getting the

product programs to “buy” the DfX requirements is

currently the most time-consuming activity. To

create a “winning” reasoning for DfX requirements,

which usually aim for internal savings, is a hard task

when compared with customer requirements, in

which case the rationale is shown via sales figures.

The framework suggests a structured data content

for different types of requests based on their

receivers’ information needs. The structured data

content is intended to support, for example, creating

a cost-value argumentation and reasoning behind

requests. The framework identifies receivers at

several organisational levels, providing an

opportunity to choose a proper receiver for each

different type of request. This addresses the

identified challenge to get guidelines accepted by the

proper authority. Related to the challenge of

different incompatible tools, it suggests establishing

a unified interface for all types of requirements from

all data sources. The idea of the framework is to

align stakeholder specific (RE) process outputs so

that they correspond to the needs of the receiver

organisation. Thus, the framework addresses the

challenge of request/requirement documentation as

well. Currently, the picture of VLSRE practices

based on empirical evidence is scarce, and the

framework gives a high level view about the case in

a large ICT organisation. To form a richer view,

further in depth studies on VLSRE practices must be

conducted.

5 CONCLUSIONS AND FUTURE

WORK

Answer to RQ1: How can a DfX RE-process be

organised effectively in industry? The general RE-

process phases (Sommerville and Sawyer, 2004)

were identified in the DfX RE-process; however, the

case company is a large organisation and its

processes are not as simple as those presented in the

literature. Thus, requirements development and

management are actually a series of parallel and

continuous processes that are managed by several

different organisational units. Another difference is

that in the case company, the global responsibility of

the DfX RE-process resides in Operations’ DfX

management organisation, instead of R&D.

Answer to RQ2: What are the challenges

relating to the DfX RE-process? The challenges

related to the DfX RE-process in a VLSRE context

were identified as discussed in the previous chapter.

The identified issues and challenges do not differ

significantly from earlier published research, but the

magnitude of the issues grows exponentially when

the challenges are considered in small-scale RE

versus VLSRE. For example, time from customer

negotiations and request initiation to actual

implementation often take years. During that time

information regards customer agreement and initial

request is used and processed by various experts,

and several decisions are made on system

DesignforExcellenceintheContextofVeryLarge-ScaleRequirementsEngineering

203

development and releases. In addition employees

change for number of reasons. Thus, it is, for

example, impossible to manually update the

dependencies between requirements, and trace the

requirements back to their original stakeholders, etc.

(Leuser and Ott, 2010). Furthermore, the

documentation should contain all relevant

information for the later phases, from the very

beginning, and it must be well organised, since there

are many handovers along the development process,

and contacting people in other time zones causes

delays in processing requests.

Answer to RQ3: How to construct a framework

to overcome the challenges of DfX RE-process? The

DfX requirements can be divided into two main

types: guidelines that ought to be followed during

product creation process, and well-formed

requirements that should be either implemented in

the product creation process or further analysed

during the feature specification. The DfX disciplines

are not the only stakeholders that feed requests, for

example, into the feature specification. The data

from all sources should be systematically gathered

and fed into later phases in a commensurable form,

to enable efficient decision-making and

prioritisation. The developed VLSRE framework

addresses several identified challenges.

5.1 Evaluation of the Validity

There are four aspects of validity that need to be

considered (Runeson and Höst, 2009): construct

validity, internal validity, external validity and

reliability. The threat to the construct validity in this

case study relates to the questionnaire. The construct

validity was mainly addressed by careful review to

ensure a good and common understanding of the

questionnaire. Four researchers created the

questionnaire, taking into account the objectives of

the case. The questionnaire was reviewed by four

other researchers, and four pilot interviews were

done to test the questionnaire. The internal validity

is not relevant to this case, since it relates to

conclusions made of causal relationships, and the

threats to the external validity relate to the

generalisation of the results. The objective of this

case study was to describe the DfX RE-process in a

large ICT company, reveal the challenges in it, and

propose a conceptual framework to tackle the

identified challenges. In general, case studies

provide low possibilities to generalise results

(Runeson and Höst, 2009); however, the results

could possibly be analytically generalised to another

large ICT company applying DfX principles. The

generalisability of results is promoted by the typical

characteristics of the case company; representative

DfX disciplines, ordinary RE-process phases and

utilised tools for instance. More studies are needed

to generalise the results to other domains.

The reliability issues related to the data and

analysis depend on the researchers. The question is:

If other researchers conduct a similar study, would

the results be the same? The threats to the reliability

have been addressed in this case, so that the results

have been derived at least by two researchers,

usually by three, and the results have been reviewed

by six other researchers. In this case, the data

collection and analysis procedures have been

clearly defined and maintained. The interviews

were carried out by at least two researchers, and the

interviews were recorded and transcribed by

professionals. One of the interviewers wrote a

summary of the interviews based on notes, which

were taken during the interview, and transcription

data. The summaries and the initial analyses were

reviewed by the interviewees, but the corrections

were minor, like the explanations of the

abbreviations. Another threat to the reliability is

that the interviewees described their subjective

viewpoints about the discussed issues. This issue

was addressed by interviewing 20 employees, who

represented different organisational units, different

DfX disciplines and all product life-cycle phases. It

was also noted that saturation was achieved,

meaning that the more interviews we conducted, the

fewer new findings came up. The validity of the

results was also addressed using data triangulation,

and taking into account the feedback received from

the company. To conclude, during this case study,

the validity issues were properly addressed.

5.2 Implications for Practice and

Research

The created framework has been further developed

in the co-operation between the researchers and the

case company representatives. Piloting the

framework and new practices relating to it have just

begun. The framework has been well accepted by

the managers in the company; in other words, it has

passed a weak market test (Kasanen, et al., 1993). In

addition, the received feedback from the experts has

been positive. The results of the study have already

led to changes in the case company’s DfX RE-

process, and further studies have been initiated.

The competition in the ICT domain is severe,

and organisations must continuously aim for internal

efficiency and seek innovative practices to gain

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

204

business advantages (Helo, 2004). The results of the

study also bring value to other large organisations in

the ICT sector, but the applicability of the results to

other industrial domains needs to be further studied.

The results here should encourage other

organisations in all industrial domains to study their

RE practices and design processes to determine how

they can apply DfX principles.

Even though DfX has been successfully utilised

in industry for decades, especially in manufacturing,

the DfX principles have not been addressed from the

RE-process viewpoint, and definitely not in a

VLSRE context. Therefore, the academic world

benefits from the new insights that the results

provide. The conducted case study also opens up

new directions for future work, since all relevant

stakeholders who process requests need to be

identified, as well as their information needs. Tools

and methods applicable in VLSRE to assist

requirements engineers need to be developed.

ACKNOWLEDGEMENTS

This research was financially supported by Tekes –

the Finnish Funding Agency for Innovation and

ITEA2 – Information Technology for European

Advancement. The authors are grateful for the case

company representatives for their time and effort.

REFERENCES

Abran, A., Moore, J. W., Bourque, P. and Dupuis, R. eds.,

2004. SWEBOK: Guide to the software engineering

body of knowledge. s.l. IEEE Computer Society.

Aurum, A. and Wohlin, C., 2003. The fundamental nature

of requirements engineering activities as a decision

making process. Information and Software

Technology, 45, pp. 945-954.

Aurum, A. and Wohlin, C., 2007. A value-based approach

in requirements engineering: Explaining some of the

fundamental concepts. s.l., Springer. Berlin

Heidelberg, pp. 109-115.

Battin, R., Crocker, R., Kreidler, J. and Subramanian, K.,

2001. Leveraging resources in global software

development.

Booker, J. D., 2003. Industrial practice in designing for

quality. International Journal of Quality and

Reliability Management, 20(3), pp. 288-303.

Boothroyd, G. and Dewhurst, P., 1983. Design for

assembly: A designer's handbook. Boothroyd

Dewhurst Inc. Wakefield, Rhode Island.

Bralla, J. G., 1996. Design for eXcellence. s.l. McGraw-

Hill.

Braun, P., 2003. Metamodel-based integration of tools.

Helsinki, Finland, s.n.

Cooper, J. S., 2004. Design analysis of PEMFC bipolar

plates considering stack manufacturing and

environmental impact. Journal of Power Sources, pp.

152-169.

Dalgleish, G. F., Jared, G. E. M. and Swift, K. G., 2000.

Design for assembly: Influencing the design process.

Journal of Engineering Design, 11(1), pp. 17-29.

De Hayes, D. W. and Robert, R. T., 1972. Guidelines for

management. Business Horizons, 15(3), pp. 7-46.

DeLain, L. and O'Meara, E., 2004. Building a business

case for revenue management. Journal of Revenue &

Pricing Management, 2, p. 368-377.

Dodgson, M., Gann, D. and Salter, A., 2008. The

management of technological innovation. Completely

revised and updated. Oxford University Press. New

York.

Ebert, C. and De Neve, P., 2001. Surviving global

software development. s.l., IEEE Software, pp. 62-69.

Freeman, R., 1984. Strategic management: A stakeholder

approach. Pitman. Boston, MA.

Geer, D. and Ruhe, G., 2004. Software release planning:

An evolutionary and iterative approach. Information

and Software Technology, 46, pp. 243-253.

Gorschek, T. and Wohlin, C., 2006. Requirements

abstraction model. Requirements Engineering Journal,

11, pp. 79-101.

Gray, B., 1989. Collaborating: Finding common ground

for multiparty problems. Jossey-Bass. San Francisco.

Gubrium, J. F. and Holstein, J. A., 2002. Handbook of

interview research. Context & method. s.l. Sage

Publications. Thousand Oaks.

Hall, J. G., Jackson, M., Laney, R., Nuseibeh, B., and

Rapanotti, L., 2002. Relating software requirements

and architectures using problem frames.

s.l., s.n.

Healy, R. J., 1968. Design for security. s.l. Wiley.

Heindl, M. and Biffl, S., 2006. Risk management with

enhanced tracing of requirements rationale in highly

distributed projects. ACM, New York, p. 20–26.

Helo, P., 2004. Managing agility and productivity in the

electronics industry. Industrial Management & Data

Systems, 104(7), pp. 567-577.

Hemmings, K. R., 1974. Commercial-vehicle cabs:

Design for packaging, access and visibility. s.l., s.n.,

pp. 345-356.

Herbsleb, J., Mockus, A., Finholt, T. and Grinter, R.,

2001. An empirical study of global software

development: Distance and speed. Toronto, Canada,

s.n., pp. 81-90.

Herbsleb, J. and Moitra, D., 2001. Global software

development. s.l., s.n., pp. 16-20.

Huang, G., 1996. Design for X: Concurrent engineering

imperatives. Chapman and Hall. London, 1

edition.

Hyysalo, J. et al., 2009. A new way to organise DFX in a

large organization. Springer-Verlag. Oulu, Berlin,

Heidelberg, pp. 274-288.

Jacobson, I., Booch, F. and Rumbaugh, J., 1999. The

unified software development process. Addison-

Wesley. Reading, MA.

DesignforExcellenceintheContextofVeryLarge-ScaleRequirementsEngineering

205

Kasanen, E., Lukka, K. and Siitonen, A., 1993. The

constructive approach in management accounting

research. Journal of Management Accounting

Research, 5, p. 243-264.

Kotonya, G. and Sommerville, I., 2003. Requirements

engineering - Process and techniques. John Wiley &

Sons Ltd. West Sussex.

Krumenauer, F. Z., Matayoshi, C. T., da Silva, I. B., Filho,

M. S., and Batalha, G. F., 2008. Concurrent

engineering and DFMA approaches on the

development of automotive panels and doors. Journal

of Achievements in Materials and Manufacturing

Engineering, 31(2), pp. 690-698.

Lauesen, S., 2002. Software requirements - Styles and

techniques. Addison-Wesley. London.

Lee, H. L. and Billington, C., 1992. Managing supply

chain inventory: Pitfalls and opportunities. Sloan

Management Review, 33(3), pp. 65-73.

Leffingwell, D. and Widrig, D., 2003. Managing software

requirements: A use case approach. Pearson

Education, Inc. Boston.

Lehto, J., Härkönen, J., Haapasalo, H., Belt, P., Möttönen,

M. and Kuvaja, P., 2011. Benefits of DfX in

requirements engineering. Technology and Investment,

2(1), pp. 27-37.

Lehtola, L., Kauppinen, M. and Kujala, S., 2004.

Requirements prioritization challenges in practice.

s.l., Springer , p. 497-508.

Leuser, J. and Ott, D., 2010. Tackling semi-automatic

trace recovery for large specifications. s.l., LNCS, pp.

203-217.

Maciaszek, L., 2005. Requirements analysis and system

design. Pearson Education. Harlow.

Maltzman, R., Rembis, K. M., Donisi, M., Farley, M.,

Sanchez, R. C., and Ho, A. Y., 2005. Design for

networks - Ultimate design for x. Bell Labs Technical

Journal, 9(4), pp. pp. 5-23.

Maznevski, M. and Chudoba, K., 2000. Bridging space

over time: Global virtual team dynamics and

effectiveness. Organization Science, 11(5), pp. 473-

492.

McZara, J., Sarkani, S., Holzer, T. and Eveleigh, T., 2014.

Software requirements prioritization and selection

using linguistic tools and constraint solvers—A

controlled experiment. Empirical Software

Engineering, 8. Springer. US, pp. 1-41.

Möttönen, M., Belt, P., Härkönen, J., Haapasalo, H. and

Kuvaja, P., 2010. Applying design for sustainability in

an ICT company. International Journal of Sustainable

Economy, 2(2), pp. 180-193.

Möttönen, M., Härkönen, J., Belt, P., Haapasalo, H. and

Similä, J., 2009. Managerial view on design for

manufacturing. Industrial Management and Data

Systems, 109(6), pp. 859 - 872.

Natt och Dag, J., Regnell, B., Gervasi, V. and

Brinkkemper, S., 2005. A linguistic-engineering

approach to large-scale requirements management.

IEEE Software, Jan.-Feb., 22(1), pp. 32-39.

Ngo-The, A. and Ruhe, G., 2005. Decision support in

requirements engineering. In: Engineering and

Managing Software Requirements. Springer. New

York, NY, 1

edition. pp. 267-286.

Nurmuliani, N., Zowghi, D. and Williams, S. P., 2006.

Requirements volatility and its impact on change

effort: Evidence-based research in software

development projects. s.l., s.n.

Paasivaara, M. and Lassenius, C., 2004. Collaboration

practices in global inter-organizational software

development projects. Software Process Improvement

and Practice, 8, pp. 183-199.

Potts, C., 1995. Invented requirements and imagined

customers: Requirements engineering for off-the-shelf

software. s.l., s.n.

Pun, K., 2006. Determinants of environmentally

responsible operations: A review. International

Journal of Quality and Reliability Management, 23(3),

pp. 279-297.

Ramachandran, M., 2011. Software security engineering:

Design and applications. Nova Science Publishers Inc.

Commack, NY.

Regnell, B., Svensson, R. and Wnuk, K., 2008. Can we

beat the complexity of very large-scale requirements

engineering? In: B. Paech & C. Rolland, eds.

Requirements Engineering: Foundation for Software

Quality. Springer. Heidelberg, pp. 123-128.

Ruhe, G. and Saliu, M., 2005. The art and science of

software release planning. Software, 22, pp. 47-53.

Runeson, P. and Höst, M., 2009. Guidelines for

conducting and reporting case study method in

software engineering. Empirical Software

Engineering, 14(22), pp. 131-164.

Sabaliauskaite, G., Loconsole, A., Engström, E. U.,

Unterkalmsteiner, M., Regnell, B., Runeson, P. and

Feldt, R., 2010. Challenges in aligning requirements

engineering and verification in a large-scale

industrial context. s.l., Springer, pp. 218-142.

Shih-Wen, H., 2002. Concurrent design method for

developing a new product. International Journal of

Industrial Ergonomics, pp. 41-55.

Sommerville, I. and Sawyer, P., 2004. Requirements

engineering. A good practice guide. Wiley & Sons.

Chichester, West Sussex.

Stephen, J., Andriole, J. and Freeman, P., 1993. Software

systems engineering - The case for a new discipline.

Software Engineering Journal, p. 15.

Strigini, L., 1996. Limiting the dangers of intuitive

decision making. IEEE Software, 13, pp. 101-103.

Svensson, R. B., Olsson, T. and Regnell, B., 2008.

Introducing support for release planning of quality

requirements — An industrial evaluation of the

QUPER model. Washington, IEEE Computer Society,

pp. 18-26.

Tiikkaja, M., 2002. Experience report: Case: COTS SW

component acquisition and management process, s.l.:

Minttu project.

van Lamsweerde, A., Darimont, R. and Letier, E., 1998.

Managing conflicts in goal-driven requirements

engineering. 24(11), pp. 908-926.

Wiegers, K., 2003. Software requirements. Microsoft

Press. Redmond (Washington), 2

edition.

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

206

Wnuk, K., Regnell, B. and Karlsson, L., 2009. What

happened to our features? Visualization and

understanding of scope change dynamics in a large-

scale industrial setting. Atlanta, GA, s.n., pp. 89-98.

Wohlin, C. and Aurum, A., 2005. What is important when

deciding to include software requirements in a project

or release? International Symposium on Empirical

Software Engineering, pp. 246-255.

Xie, S. Q., Tu, P. L. and Zhou, Z. D., 2004. Internet-based

DFX for rapid and economical tool/mould-making.

International Journal of Advanced Manufacturing

Technology, pp. 821-829.

Xuan, X., Singh, A. D. and Chatterjee, A., 2006. Lifetime

prediction and Design-for-Reliability of IC

interconnections with electromigration induced

degradation in the presence of manufacturing defects.

Journal of Electronic Testing, 22(4-6), pp. 471-482.

DesignforExcellenceintheContextofVeryLarge-ScaleRequirementsEngineering

207