Categorizing and managing difficulties in interorganizational requirements engineering

(1)

INOM

EXAMENSARBETE INDUSTRIELL EKONOMI,

AVANCERAD NIVÅ, 30 HP ,

STOCKHOLM SVERIGE 2020

Categorizing and managing

difficulties in interorganizational

requirements engineering

SAMUEL ANDRÉN

(2)

(3)

Categorizing and managing difficulties in

interorganizational requirements

engineering

by

Samuel Andrén

Master of Science Thesis TRITA-ITM-EX 2020:136 KTH Industrial Engineering and Management

Industrial Management SE-100 44 STOCKHOLM

(4)

Kategorisering och hantering av svårigheter

inom interorganisatoriskt kravarbete

av

Samuel Andrén

Examensarbete TRITA-ITM-EX 2020:136 KTH Industriell teknik och management

Industriell ekonomi och organisation SE-100 44 STOCKHOLM

(5)

Master of Science Thesis TRITA-ITM-EX 2020:136

Categorizing and managing difficulties in interorganizational requirements engineering

Samuel Andrén

Approved

2020-05-13 Examiner Pernilla Ulfvengren Supervisor Lars Uppvall

Commissioner

Scania CV

Contact person

Magnus Bleckert

Abstract

As globalisation is now a reality for most large organizations, and the competition for most businesses moving faster and becoming tougher, there is a need for engineering projects to deliver results faster in a more complex environment than ever, but also for companies to collaborate to utilize a wider array of competencies and to reach new markets with their products. This case study analyses which difficulties arise in interorganizational requirements engineering, and what organizations can do to alleviate the effects of those difficulties, as well as suggest which actions are most effective to focus on. The conclusion of this study is that the difficulties can be divided into three categories, namely interpersonal, structural and processual. Each category concerns a different set of people and require different actions for increased effectiveness. For the interpersonal category, prioritized efforts should be to establish a shared vocabulary and use techniques to build shared contextual understanding. For structural difficulties, evaluating management and control structures and the implementation of the project’s strategy should be prioritized. In the processual category, codifying existing processes to enable improvements, defining information artefacts and aligning information flows should be of high priority.

Key-words

Requirements Engineering, Interorganizational collaboration, Collaboration Engineering, Global Software Development, Process Definition, Agile, Requirements Documentation, Communication in Interorganizational Contexts

(6)

Examensarbete TRITA-ITM-EX 2020:136 Kategorisering och hantering av svårigheter

inom interorganisatoriskt kravarbete

Samuel Andrén

Godkänt

2020-05-13 Examinator Pernilla Ulfvengren Handledare Lars Uppvall

Uppdragsgivare

Scania CV

Kontaktperson

Magnus Bleckert

Sammanfattning

Globaliseringens effekter är idag en verklighet för de flesta stora organisationer, och konkurrensen för företag blir hårdare och förändrar sig allt snabbare. Därför blir det allt viktigare för utvecklingsprojekt att anpassa sig till en allt mer komplex miljö och leverera resultat snabbare än tidigare, men också att samarbeta mer med andra företag för att såväl utnyttja bredare kompetens som att nå nya marknader. Den här studien undersöker utmaningarna i interorganisatoriskt kravställningsarbete, vad företag kan göra för att möta de utmaningarna, såväl som att föreslå vilka handlingar som ger mest effekt för ett bättre kravställningsarbete. Slutsatsen av studien är att utmaningarna kan delas in i tre kategorier, nämligen personorienterade, strukturella och processorienterade. Varje kategori rör en viss mängd deltagare i projektet och kräver olika handlingar för ökad effektivitet. För att minska utmaningar i den personorienterade kategorin bör ett projekt prioritera att använda tekniker för att skapa ett gemensamt språkbruk och att använda tekniker för att bygga upp gemensam kontextuell förståelse. För strukturella utmaningar bör det prioriteras att utvärdera styrnings- och kontrollstrukturer, samt hur projektets strategi har implementerats och förankrats bland deltagarna. I den processorienterade kategorin bör det prioriteras att kodifiera existerande processer för att möjliggöra förbättringsarbete, definiera informationsartefakter och att försäkra sig om att informationsflöden är i linje med varandra mellan företagen, så att rätt information möts vid rätt tillfällen.

Nyckelord

Requirements Engineering, Interorganizational collaboration, Collaboration Engineering, Global Software Development, Process Definition, Agile, Requirements Documentation, Communication in Interorganizational Contexts

(7)

(8)

Foreword

Upon completion of this thesis, there are some people who deserve a special mention for their contribution to or role in relation to the work. Of course a big thank you to family and friends who have supported when the task seemed insurmountable, or helped by discussing some idea for a few minutes. A special thank you to those who listened as I presented some idea I had, explained it for a few minutes without adequately explaining the background. Although often perhaps perceived as me just talking about a topic you had no clear grasp of, the chance to formulate some ideas out loud for a few minutes led to that formulation that eventually ended up in this paper. Magnus Bleckert and Lars Uppvall both deserve a big thank you for your patience and support. But above all else, the author of the twin thesis to this one, Erik Lindström, thank you for a challenging collaboration that I believe ultimately led to both of us having greater insights into the project we investigated.

Samuel Andrén Solna, 2020-05-12

(12)

1. Introduction

In the last decades globalisation and partnerships across cultures and borders has become an ever more common phenomenon. Despite of the availability of digital communication, the geographical distance and cultural differences makes it more difficult to collaborate in global projects, as building mutual understanding and trust is easier in physical meetings _{(Denstadli, Julsrud, and Hjorthol} 2012). These challenges become more important as global projects increase in frequency and scope, while companies also have to manage a faster and more competitive business climate _(Aaltonen, Jaakko, and Tuomas 2008) _{. It’s becoming more important to deliver projects on time and quickly,} but the complexity of the environment and of the projects makes the risk of delays larger and provides new challenges of culture, communication and geographical distance. More and more technical systems are also becoming increasingly interconnected with human-centred activities, making social considerations an extra layer of complexity to be considered for engineering projects (Cohen, Rossmann, and Bernhardt 2014; Rettig 2007) _{. In a global environment with increased} complexity in the business environment, companies are becoming exceedingly reliant on partnerships with other companies to share knowledge and technical competence, spread development costs over a larger number of units, as well as for building stronger brands _(Henderson et al. 2014) _{. However, realizing the benefits of such partnerships also requires overcoming some} significant challenges.

Requirements engineering is the practice of collecting, handling and developing requirements for engineering projects. It is an important part in the creation of advanced systems, software and services, and the objectives include correctly understanding the needs of the stakeholders involved in a project, as well as fully defining and aligning the project scope _{(Sommerville 2011). It is the most} communication intensive part of a project, especially in the early phases when significant parts of the project or system might be undefined _{(Zowghi 2002). Poorly executed requirements engineering is} also commonly blamed for the failure of projects, such as failing to deliver on time and on budget, but also failing to meet the needs of the customer or end-users _{(Fricker, Grau, and Zwingli 2015). A} reason for requirements engineering having such a large impact on the outcome of a project is that it sets the direction of the project at an early stage and thus some errors may be amplified through the project’s development.

The combined challenges of the increasing complexity in global and interorganizational projects with the existing challenges of requirements engineering means that organizations entering collaborative engineering projects could reap some major benefits from ensuring that their requirements engineering processes are adapted to the new environment. With increasing prevalence of collaborative projects including requirements engineering and knowledge of the impact of those processes on a project’s success, interorganizational and global requirements engineering has been a

(13)

hot area of research in recent years _{(Ambreen et al. 2018). However, despite of that there are still} few recommendations on how to adapt existing processes to an interorganizational context. In an interorganizational project there may be different challenges - political, geographical, organizational or communicative - as well as limitations on how to face those challenges. Given that premise, this study poses the question of how to better manage and prioritize between different actions to create a more effective and efficient requirements engineering process.

1.1. Purpose

The aim of this study is to identify what causes interorganizational requirements to become inefficient and ineffective, and to suggest what measures or focus areas an interorganizational project should prioritize in its efforts to increase the efficiency and effectiveness of its requirements engineering.

1.2. Research questions

The main research question for this study is

What actions should be prioritized to increase the effectiveness in interorganizational requirements engineering?

To answer that question the following sub-questions will be investigated.

1. What are the difficulties that arise in interorganizational requirements engineering?

2. In which ways can the difficulties that arise in interorganizational requirements engineering be addressed?

3. What actions can be expected to be most effective when addressing multiple difficulties that arise in interorganizational requirements engineering?

1.3. Delimitation

This study does not consider the full life-cycle of requirements engineering. Instead the focus of the requirements engineering is on the early stages of the life-cycle of a system, in the initial phases of defining the system and its business context. The reasons for this delimitation are two-fold, the first being that for time reasons it is not practical to consider the entire life-cycle of a complex business system because the life-cycle is too long. The second reason is that the first stages of the development project has the largest impact on defining the purpose and scope of the system, and

(14)

that is also when the perceived complexity of the system is the highest, before the interdependencies and processes have been fully modelled for the project.

1.4. Disposition

● The second chapter contains a review of existing literature in the field of requirements engineering. The area is defined, and types of requirements along with processes, activities and techniques are explained. The ways of documentation are described, followed by a review of communication, culture, types of distances and contexts in requirements engineering. Finally, the areas of collaboration engineering and process definition are explored.

● The third chapter _{describes the method used for this study. The research design is} described, along with more detailed descriptions of the data collection and analysis. Finally, aspects of research quality are discussed and motivated.

● The fourth chapter _{provides a context for the case study. It provides a background to the} company at which the case study has been done and some description of the inherent difficulties of the collaboration that is at the centre of this study. Then the processes and roles that have been most central to the study are explained.

● The fifth chapter explains the findings of the study in more detail, providing a broad view of what occurs in the project that has been studied.

● The sixth chapter _{sets the findings from the fifth chapter into the context of the theory} from the second chapter, discussing how the findings of this study relates to existing literature. It highlights some themes from the case study and finishes with a section on the aggregated effects of the findings.

● The seventh chapter concludes the study by answering the research questions based on the discussion in the sixth chapter. That is followed by a discussion of some implications of the result, and finally some recommendations for future research are provided.

(15)

2. Literature review

This chapter begins by explaining the definition and purpose for requirements engineering, followed by defining what a requirement can be and what types of requirements exists. Then some definitions of processes and activities are given to help the reader understand the context of both the research field and how it is used in practice. The next subchapter concerns documentation in traditional requirements engineering and how it is challenged by lightweight documentation techniques. The following two subchapters describes how socio-technical context and distances affects requirements engineering in a global and interorganizational settings and the final subchapter concerns collaboration engineering and the studied impact of process definition in interorganizational contexts.

2.1. Requirements engineering

Requirements engineering is an interdisciplinary function concerned with eliciting, developing, analyzing, verifying, validating, communicating documenting and managing requirements. Its purpose is to create a set of requirements that refers to some system, software or service, and which enables mutual understanding between stakeholders, is validated against real-world needs, is possible to implement and which provides a frame of reference for verifying designs and solutions _(IEEE 2018)_{. The tools and knowledge of requirements engineering can be applied for business analysis,} project management, systems engineering, socio-technical systems and several other areas concerned with understanding and solving real world problems (IIBA 2015). It is a particularly important part of software engineering, as defining the scope and purpose of projects in software development has proven particularly difficult, and software projects have traditionally been vulnerable to delays or failing as a result of poorly executed requirements related activities _{(Rubinstein 2007). Errors caused} by poor requirements engineering in the early stage of a project life cycle, relative to errors caused later in the development of a system, have a larger impact on the budget and time scale of a project. The reason for this is that it sets the course of the project at the earliest phase, and any major errors at that point are amplified through the process _{(Bennaceur et al. 2019; Nuseibeh and Easterbrook} 2000).

Properly defined and clear requirements is one of the most influential factors in determining a project’s success _{(Najjar and Al-Sarayreh 2015). This entails not only understanding the needs of} intended end-users or customers, but aligning all stakeholders’ understanding of the scope and goal of the project and making sure that it is aligned with the goals of the organization. Enabling executive support for IT and making sure that the IT department properly understands the business

(16)

needs are ranked among the most important aspects for successful IT initiatives _{(Luftman, Papp,} and Brier 1999) _{. Thus, requirements engineering is not only tasked with recording how a system will} be used, but an equally important part is communication with strategy owners and management (Fricker, Grau, and Zwingli 2015).

2.2. Types of requirements

The term requirement is often not used consistently and is used to describe a broad range of related things. It can include abstract, high-level user requirements, as well as detailed definitions of system functions. It is also common that the term is used without differentiating between stakeholder needs, stakeholder requirements and system requirements _{(Sommerville 2011). These terms suggest} significantly different levels of development and can almost be considered hierarchical. First stakeholder needs are gathered, then they are refined and evolved before they can be considered valid stakeholder requirements, which should then serve as the basis for the development of system requirements. Initial needs may lack definition, analysis, consistency and feasibility, and it is not until a set of stakeholder requirements have been defined that a system requirement can be properly developed _{(IEEE 2018). Although requirements most commonly refer to features or constraints on} the product itself, there can also be requirements on the development process itself. Requirements are typically divided up into two primary categories. Functional requirements, which describe what services a system should provide, and non-functional requirements, which should set constraints on the services of the system _{(IEEE 2014). In practice it can be difficult to draw a line between the} functional and non-functional requirements, neither is such a separation necessarily desirable as a slightly blurry line can help create a holistic system understanding _{(Eckhardt and Vogelsang 2016).} The type of requirements that can be categorized as non-functional can be product related, concerning things like usability, efficiency, dependability or security, or organizational, concerning things like environmental, operational and developmental factors, or external requirements, such as regulatory or ethical considerations, as shown in figure 1 _{(Sommerville 2011).}

(17)

Figure 1. A taxonomy of types of requirements that can be categorized as non-functional. Adapted from Sommerville (2011).

A common problem with the formulation of non-functional requirements is that they are vague, too general or untestable in an objective manner. Requirements, functional or not, should be formulated in a testable way, preferably quantitatively _{(Sommerville 2011). A functional requirement should be} verifiable as an isolated feature whereas a non-functional requirement should be verifiable at system level. To support the understanding and interpretation of requirements for stakeholders with another domain of expertise it is generally advised to add contextual information, such as classification of priority, origin, verification method and the underlying rationale. As the overall goal of the requirement is to help other stakeholders in the development process understand what needs to be developed, the traceability for validation is advised to bridge the gap between the source of the requirement and the developer (IEEE 2014).

Figure 2. A taxonomy of types of system requirements and examples of what fits into the respective categories. Beyond the system requirements there are also project and process requirements to be considered.

(18)

Non-functional requirements have often been considered more difficult to identify, formulate and analyse. In recent years it has also been the most researched area in requirements engineering, along with global and interorganizational applications _{(Ambreen et al. 2018). It has been argued that what} is categorized as non-functional could just as well be formulated as functional requirements and that the distinction is unnecessary, or at least overused _{(Eckhardt and Vogelsang 2016). The issue of} properly identifying or categorizing requirements as functional or not is not a new one. Glinz ₍₂₀₀₇₎ states that while there is consensus on what constitutes a functional requirement, there is a lack of consensus on what the definition of a non-functional requirement is and proposes as a definition that system requirements should be made up of functional requirements as well as attributes of or constraints on a system, with a subdivision of attributes of the system consisting of performance requirements and specific quality requirements, as shown in figure 2. As systems become closer connected with humans, there may also be a need to include value-based requirements, which could function as a constraint on a system but also might prove challenging to express in technical terms (Thew and Sutcliffe 2018) _{. Eckhardt et al. (2016) argues that there are significant benefits to making} less of a differentiation between functional and non-functional requirements, as the latter often has been tested separately, not been given properties like testability, and in general given less attention by engineers.

It is important that a requirement is loose enough so that the solution isn’t predefined. Requirement statements should not be about the system itself, but rather refer to the environment in which it resides, as that is what the system will have to be measured against. In a sense this is analogous to the notion that requirements should not define the design of a product, just set limitations or dictate desired behaviour to its external environment _{(P. Zave 1995; Sommerville 2011). Zave and Jackson} (1997) states that the requirements engineer should describe the environment without the presence of the system, and the environment with the system present, in order to fully understand the systems desired specification. In order to achieve this level of understanding they assert that the engineer should produce three sets of descriptions. Firstly, a description of the domain where the system should reside. Secondly, a set of requirements of what the users, customers and other relevant stakeholders need when the system is in place. Thirdly, with the first two descriptions in mind the engineer should create a description of what the system needs to do in order to fulfill the needs of stakeholders in the domain. The emphasis of Zave and Jackson _{(1997) is that the requirements} engineer cannot understand the requirements set upon a system without understanding all these areas properly.

2.3. Processes, activities and techniques

According to the standard for requirements engineering for software and systems, defined by IEEE (2018)_{, there are three principal processes in requirements engineering. Firstly, the business or} mission analysis process, which aims to define the opportunity or problem, the solution space, and

(19)

the potential solution classes. Secondly, the stakeholder needs and requirements definition process, which aims to identify stakeholders involved with the system throughout its life cycle and their needs. Thirdly, the system requirements definition process, which aims to transform the defined stakeholder requirements into technical system requirements for implementation. Each of these principal processes exist to identify or define a separate set of requirements. There are a number of activities that are used to develop each of these sets. The terminology for these activities is not unified across the field, and thus depending on the source the emphasis, description and categorization differs slightly. To exemplify the differences between different sources, Nuseibeh and Easterbrook _{(2000) lists five main activities, namely elicitation of requirements, modelling and} analysis, communicating requirements, agreeing on requirements and evolving requirements, whereas Bennaceuer et al. _{(2019) substitutes the last three for validation and verification, and} management and evolution. Meanwhile, Sommerville (2011) divides this into three major activities, requirement elicitation, requirement specification and requirement validation, done at different levels of technicality. However, despite of the differing terminology and categorization, the underlying purpose, techniques and final deliverables are largely shared. Some of these activities are discussed more below.

The stakeholder needs and requirements definition process should result in identified stakeholders, documentation of their needs, constraints on the system, defined critical performance measures, agreement from stakeholders that their needs are reflected in the requirements and traceability, among other things. The system requirements definition process should result in a defined system description, including interfaces, functions and boundaries, defined system requirements and design constraints, critical performance measures, as well as traceability of system requirements _(IEEE 2018)_{. Descriptions of requirements engineering processes can be easily interpreted as waterfall} processes, with a finished deliverable marking the end of a phase of the full requirements process. However, several authors point out that the requirements process is iterative and, although more intense at the beginning of a project, stretches throughout the life-cycle of a system _{(Nuseibeh and} Easterbrook 2000; IEEE 2014; Sommerville 2011)_.

2.3.1. Requirement elicitation

Requirements elicitation is concerned with identifying requirements and collecting them in a structured manner. Common techniques used for this include interviews, creating scenarios for the system usage, building prototypes to better understand the system, and making observations of the processes and stakeholders that the system is meant to support. Eliciting requirements is difficult for a number of reasons. Stakeholders often have difficulty articulating what it is they need a system, software or service to do. Related to that is the fact that they express requirements with implicit knowledge of their own work or organizational context, and thus failing to highlight some things that is important to them, while also making it difficult for the requirements engineer to fully

(20)

understand the requirement. As requirements are collected from different stakeholder groups it is common to find both similar and conflicting requirements, but the fact that they might express their requirements differently, with different perspectives of usage or context in mind, can make it difficult to identify both conflicts and similarities in the requirements set (Sommerville 2011). Emergent properties are requirements that appear as a result of other requirements being combined or architectural choices. Such properties tend to be difficult to identify, yet need to be acknowledged as an important source of potential requirements, as the result of them can be non-functional requirements that might affect a lot of components in a system (Johnson 2006).

All techniques used for elicitation are not equal or interchangeable. In a large survey by Fricker et al. (2015) of software engineering projects that included a requirements engineering phase, some techniques that seemed to be correlated with successful results of the requirements process could be singled out. Creating scenarios of system use, clarifying the business case for the system and having stakeholder workshops all contributed to building a clear set of requirements and shared understanding of the system. Additionally, successful projects tended to use a greater variation of elicitation techniques and built up a larger amount of requirements, creating a more diverse range of inputs to understand the stakeholders of the system as well as specifying the system to a greater degree. Another survey by Davis et al. _{(2006) found interviews to be one of the most effective} techniques to elicit requirements as it is both easy to implement and yields good results. Interestingly, that survey found analyst experience to have little effect on the elicitation results. Because requirements engineering is at the intersection of social science and technology, it is perhaps not surprising that common problems concern the transfer of knowledge from client or stakeholder to the requirements engineer. A categorization of elicitation issues, based on a literature review, included that natural language was unsuited for expressing technical requirements, stakeholders’ inability to adequately express business needs, and human aspects that preclude knowledge transfer between clients and analysts. Out of a total of nine categories, these three share that they are centred on communication and appear during direct communication between client and analyst. Creating conditions to avoid one of these issues thus can help alleviate the other issues as well _{(Davey and Parker 2015).}

2.3.2. Requirement analysis

Another important activity is the analysis of elicited requirements. The methods used for this include modelling, verbal discussion, and specification and reformulation of the requirements. The purpose is to gain a deeper understanding of the requirements, identifying and resolving conflicts between them, and to create a more formal specification, including in regard to the boundaries of the system, software or service as well as the interactions with its organizational and operational environment (IEEE 2014) _{. Creating models, rudimentary prototypes or other visualisations is encouraged within} this phase, as it illustrates the requirements in new ways and tends to broaden the understanding for

(21)

the requirements engineers, as well as highlight where information is lacking. This also helps by setting a functional baseline, that forms a common understanding of what the system could do, thus aiding as in any following discussions regarding what other behaviour would be desired from the system (IEEE 2018). There are a lot of different models that can be used depending on what type of information need to be highlighted and oftentimes several models are created. A concern at this stage is that the models need to be consistent with one another, which might require internal verification _{(Bennaceur et al. 2019). An important part of this phase is in regard to negotiation of} conflicting demands between stakeholders, and it is often required to make prioritizations between conflicting requirements. This tends to be difficult without adequate knowledge, and thus it is generally advised to resolve these types of conflicts as soon as possible in the process, and if possible, involve the source of the requirement. Although this is advised, it is also noted that this tends to be difficult due to lack of information at early stages in the process (IEEE 2014).

2.3.3. Requirement validation

The validation of requirements should ensure that the requirement has been properly understood and that it is still adequately met after being analysed, reformulated, and merged with other requirements, ultimately ensuring that the right product is being conceived. The validation should be done in such a manner that it is assured that the original needs of the stakeholders or other original requirements are being considered. It is also important to note that this should not be confused with internal verification, which aims to ensure that the requirements set does not include inconsistencies or conflicting requirements, and rather something that should be considered part of the analysis (IEEE 2018) . Prototypes or models are useful techniques to communicate between engineers and stakeholders in order to validate requirements. Although language specification has benefits of potentially being very specific, the use of prototypes tends to decrease the volatility of a requirement, meaning that the probability of future changes decreases by creating a strong mutual understanding between stakeholders of different domains (IEEE 2014). As stated in previous sections, a requirement should always be testable. In conjunction with formulating a requirement, the test of the requirement should also be designed. This has proven to increase the likelihood of identifying poorly or wrongly formulated requirements, and proves useful during validation activities (Sommerville 2011) . Validation of non-functional requirements tends to be more challenging, both because it is more likely that there is no individual stakeholder that can be considered its origin, but more importantly because it more often is difficult to decompose it to such a level that it can be tested in a quantitative manner. However, difficulties in identifying techniques for validating requirements is often an indicator of poorly elicited or specified requirements that needs reformulation _{(IEEE 2014).}

(22)

2.3.4. Requirement management

Requirements continue to change during the life cycle of a product. Although the volatility of requirements can be minimized with good elicitation, analysis and validation, there will always be factors that force changes. These factors can be stakeholders’ needs or expectations changing, failure in eliciting existing requirements, failing to consolidate conflicting requirements in a manner that adequately fits all stakeholders, or changes in business or technical environment _{(IEEE 2018). The} more diverse the set of stakeholders are, the more likely it is that there will be conflicting requirements and forced compromises, which eventually tend to lead to changes being needed after the implementation _{(Sommerville 2011). It is important to identify what the cause of the} requirements change is, as some requirements change is inherently good whereas others might be unwanted or could be avoided. It can be classified as two types of change, either essential or accidental. The essential change is inherently good and should be embraced, as it is changes that is inherently unavoidable for the requirements engineer. It includes changes in the market demand, external environment or organizational policy, and developers and users gaining a better understanding of the system and thus making more informed decisions and statements. The accidental change should be avoided, especially anticipated and pre-empted. It is changes that appear as a result of vague product vision and strategy, poor evaluation of project purpose and business case. Additionally, it includes changes that appear due to low stakeholder involvement, insufficiently specified and analysed requirements, and unidentified project dependencies _{(Bano et al. 2012).}

2.4. Documentation in requirements engineering

Corresponding with the principal processes of requirements engineering described in chapter 2.3, the standard for requirements engineering for software and systems prescribes that three requirements specifications should be created, with an optional fourth one for complex software systems. These specifications are hierarchical but should contain the same information viewed from different angles and aimed at different stakeholders. Firstly, the business requirements specification, which should include the organizational goals and objectives, the business model and how the proposed system relates to them. Secondly, the stakeholder requirements specification, which should describe how the stakeholders will use the system and, in the context of the business requirements specification, how it supports the business goals. Thirdly, a system requirements specification should identify the technical requirements for the system, with the purpose of describing how the system should interact with its external environment. And optionally, a software requirements specification for complex software products _{(IEEE 2018). Although the standard prescribes these specifications,} it is also noted that they don’t need to be organized as physical documentations, but rather as information logically organized and available in this manner. For software requirements specifications there is an additional standard, IEEE Std 830-1998, with extensive guidelines on what

(23)

should be included, but despite its rigorous nature it is meant to be adapted to the project and organizational context rather than be used as is _{(IEEE 1998). Similar to the standard for} requirements engineering, the Software Engineering Body of Knowledge advice to create several levels of documentation, namely a system definition, a set of system requirements as well as a set of software requirements _{(IEEE 2014).}

Requirements are most often written in natural language. However, some standardised format is generally used as it decreases the risk of errors or misinterpretation significantly. There are many different models for the semantic construction of the requirement that help avoid language that can be misconstrued _{(Sommerville 2011). In terms of quality of the requirements set, reasonable size of} the set, the overall state of readability and conformance to text structures, as well as the correct degree of specificity, is explained as indicators of the quality _{(IEEE 2014). Although each of the sets} of requirements serve different purposes and provide different angles to help different stakeholders understand the requirements set upon a system, this can work poorly in practice. A study by Ellis-Braithwaite et al. _{(2017) finds that different requirement sets often contain the same} information, even the same wording between user requirements and system requirements with little or no added information. This causes a limited motivation to refer to the requirements and lowers the quality of all the requirements sets. Additionally, extensive documentation for software requirements quickly becomes outdated when frequent requirements change occur. High levels of business uncertainty brings with it an increased risk of requirements volatility, that can quickly make previous documentation outdated _{(Sommerville 2011). Therefore, when there is a high probability of} changing requirements, lightweight documentation can be preferred, as long as there is sufficient central documentation to coordinate efforts.

To address these problems, working with agile methods have become more prevalent, especially in software engineering, but also in general engineering projects. There are several schools of how to work in an agile manner, but the key characteristics for agile methods generally include working in short development cycles, frequent deliveries, encouraging adapting to changing requirements, promoting face-to-face interaction over written documentation as well as re-evaluating which requirements or tasks to prioritise frequently _{(Meyer 2014). It is advised to have frequent interaction} with customers and other key stakeholders, especially in regard to deliveries in order to continuously realign efforts and tasks with the current requirements. The agile mindset has been viewed as a challenger to traditional requirements engineering, and developers and engineers have had a willingness to embrace the agile method as it perceived as more constructive to actively build something rather than spending time defining requirements (Kassab 2014). That is not to say that they are methods that are completely different, on the contrary there are elements that are shared completely, such as validation techniques. One reason that agile techniques has become popular is that developers have embraced it as a preferred way of working, but it has also helped address some frequent problems within projects, especially in software engineering and related to poor requirements engineering _{(Davey and Parker 2015). The developer is meant to have a close}

(24)

connection and feedback from the customer continuously while features are being implemented. Organizations and software projects that manage to enable an effective feedback thereby manages to avoid major changes of delivered features. The key to achieving this is to have many small deliverables with early validation rather than a few large deliverables. However, for large projects there is a risk to be considered with that approach, namely that early architectural choices become necessary to change as requirements change, which can add significant amounts to the project costs (Cao and Ramesh 2008)_.

It is worth noting that although the processes differ between agile methods and a waterfall approach to projects, the criteria for good requirements remain the same, and the importance of successfully obtaining good requirements is equally important _{(Davey and Parker 2015). As agile methods rely on} intensive interaction between the customer and the developer, in development projects where that level of direct communication is difficult to achieve, that approach increases prevalence of requirements that are inaccurately communicated _{(Cao and Ramesh 2008). However, using lighter} forms of documentation for requirements, such as user stories, even in projects that are unable to fully adopt agile development methods has still proven useful. The benefits can include ease of use to development teams that are familiar with the format, whereas the drawbacks are that the format fails to communicate sufficient contextual information _{(Kassab 2014). It may also be that certain} requirements are more difficult to express as light weight documentation. Non-functional properties of a system are sometimes overlooked, as it can be difficult to express it in a sufficiently precise manner _{(Bennaceur et al. 2019).}

More extensive documentation, provided that it is correct and not outdated, is more trustworthy if it is passed on to stakeholders who do not already share an understanding of the context. As described in chapter 2.2, Zave and Jackson _{(1997) states that the requirements engineer need to create artefacts} describing the properties of the domain, what should be true in the domain after implementing the system and, based on those artefacts, a description of the system itself. When working with lightweight documentation or agile methods, it is typical that the properties of the domain without the system is assumed to be understood or communicated without formal documentation. That has proven to be effective by success of agile methods _{(Meyer 2014), but as the domain becomes too} complex, the number of stakeholders increases and the amount of possible contact between those stakeholders decrease, much of the prerequisites for that success becomes challenged.

2.5. Communication

and

culture

in

requirements

engineering

In the last decades there has been a tendency within requirements engineering research to become more focused on the softer aspects, like politics and stakeholders’ feelings, rather than just focusing

(25)

on the technical. Cohen et al. _{(2014) argues that as technical systems become more connected with} society at large, it is no longer enough to focus on the technical aspects of the system, but rather it is needed to have a more holistic view in each system’s design, by also considering the social context of the system. Similarly, Bennaceur et al. (2019) states that close communication and mutual understanding of stakeholders is paramount for properly capturing requirements that lie hidden in tacit knowledge and other hidden needs, as well as for uncovering biases among the stakeholders. Soft issues have traditionally not been included sufficiently in the requirements process, which can be both a missed opportunity for better requirements and a potential cause of lack of strategic alignment between departments _{(Thew and Sutcliffe 2008). This becomes especially important when} entering the realm of interorganizational requirements engineering, when confronted with several social contexts of a system that might differ in significant ways. This forces a more holistic consideration of organizations, putting more emphasis on creating alignment of direction, and handling matters of power and politics. Milne and Maiden _{(2011) argues that these factors have} often been overlooked during requirements engineering and that the requirements engineer should question whether the stakeholders share the same objective. It is not uncommon that stakeholders, be it managers, end-users or the engineers, wishes to stay away from these terms to avoid confrontation, but if they are not ignored it is possible to create better end results _{(Milne and} Maiden 2011)_.

Because requirements engineering is very communication intensive, geographical distance has an aggravating effect. The geographical distance also makes coordination more difficult, and all this is additionally hampered if time difference is a factor. When there are several contexts that need to be considered during elicitation, the amount of requirements tend to increase quite significantly. In the early phases of a project a lot of knowledge tend to remain tacit and is difficult to communicate (Zowghi 2002) _{. An effect of that is that if there is a lot of discrepancy between the contexts of} different stakeholders, as is more likely in interorganizational projects, the difficulty of communication is amplified. This is a prominent in projects with a global span, but it can become an equally important issue even between departments within the same company and city, let alone building, if the culture between departments differ too much.

Several researchers lift the issue of a language barrier between contexts, noting that even if the spoken language is the same the specifics of the domain or even the language of an individual makes misinterpretations likely. Zave and Jackson _{(1997) exemplifies the impact of this by comparing the} implication of a requirement where a single word, a “student” who enrolls in a class, is interpreted in two different ways. The essence of the example is that either everyone who enrolls in the class becomes a student or only persons who are already students can enroll and depending on the interpretation the implementation will differ significantly. They argue that the most primitive terms need unambiguous definitions. Thus, including a glossary with requirements is advised to decrease the amount of misinterpretations (Sommerville 2011). Mighetti and Hadad (2016) states that because every application domain has a slightly different terminology, and the differences between domains

(26)

increase as geographical and cultural distance increases, using a domain specific lexicon will help mitigate a lot of issues with communication, domain knowledge, and ambiguity and imprecision of specifications.

2.6. Distance and contexts in interorganizational settings

The understanding of the domain both without the system and with it, as described as a prerequisite for fully understood requirements by Zave and Jackson _{(1997), becomes an extra challenge when} there are additional domains and the inherent complexity increases. In order to bridge the distance between business units, locations, development teams or other stakeholders, identifying what differs is advised _{(Elizabeth Bjarnason and Sharp 2017). A difference in domain knowledge can be called} cognitive distance, and is undoubtedly important, but psychological distance, meaning the perceived effort of communication, can be equally important. Bjarnason and Sharp _{(2017) provide a taxonomy} of eight different types of distance. Apart from cognitive and psychological distance, geographical, temporal, organizational and various distances related to artefacts. Some of these, such as geographical, are more difficult to address than others, so if cognitive or psychological distance is perceived as high, efforts to improve communication might be better focused there. Ali and Lai (2017) identify four categories of issues that arise in global requirements engineering. Firstly, inconsistent use of vocabulary between development locations, causing misinterpretation of requirements. Although this has been addressed by other studies and methods have been suggested to diminish the effect, they argue the issue remains to some degree. Secondly, difficulty in knowledge transfer between collaborating stakeholders at different locations due to geographical distance, language difference or other factors. Despite readily available digital communication, there is less seamless knowledge transfer. Especially informal communication becomes much harder for geographically stakeholders _{(Al-Fataftah and Issa 2012). Thirdly, using different standards for} requirements documentation in different locations. When documents are passed between locations and the format is not agreed upon, information that might be considered important by one part might not be included, and the time and effort handling the documentation increases. Finally, requirements validation becomes significantly more difficult, as geography, language, culture and time zones makes it difficult to validate in another context. Interestingly, the first and third of these appear to be possible to address to some degree with relatively simple tools. A study by Nicolás et al. (2018) provides a taxonomy of the problems that most occur in global software engineering. Knowledge sharing and communication problems are described as key issues, along with problems with process definition.

Knowledge sharing and communication are part of a recurring theme when studying interorganizational and global requirements engineering. The impact of these issues include increased time consumption and incomplete requirements set as a result of missed requirements _(E. Bjarnason, Wnuk, and Regnell 2011) _{. The time consumption increases especially when the}

(27)

requirements have to be redone because the requirements don’t have sufficient quality or aren’t accepted when they should be verified or validated. Missed requirements occur when there are communication gaps between stakeholders. The risk of this is higher at early stages of a project, when processes haven’t been fully implemented. The probability of this is also significantly higher at certain hand-over points, where the documentation and overall communication must contain all the information that has previously been aggregated about a requirement in order to ensure that it is properly understood and developed _{(E. Bjarnason, Wnuk, and Regnell 2011). The issues with the} difficulty of communication and knowledge sharing are not new, and they have been addressed before, and tools exist that are meant to counteract those challenges. The importance and impact of them are enlarged as the distance between locations and organizations increases, but despite of there existing tools, in the interorganizational or global context the dependencies between sites and subsequent need for technical coordination is a culprit that is difficult to manage (Herbsleb 2007).

2.7. Collaboration engineering and process definition

In a study of projects between Siemens and other companies that had involved requirements engineering, Berenbach _{(2006) provides a taxonomy of the most common sources of severe} problems in the requirements processes. Interestingly, this study lifts management and organizational factors as more influential than issues with elicitation or cultural misunderstandings. Among the most common factors were multiple of unclear chains of command and lack of clear leadership. This is somewhat echoed by Damian _{(2007), who states that a prerequisite to achieve} effective distributed requirements engineering is to define an organizational structure with clear communication responsibilities and thus a clear chain of command. Additionally, having peer-to-peer links between the different locations across all levels of the collaboration and at least synchronizing processes between the locations and have frequent iterations of work to enable frequent alignment _{(Damian 2007). It is also worth noting that accepting that managing while} participating in collaborations, one must be prepared to impose decisions upon oneself as well as others, but the willingness to do so is often lacking _{(Thomson and Perry 2006).}

In order to make it clear where the ownership of processes and responsibilities lie within contexts with complex structures, modelling tasks and roles and thus formalising them can be used _(Strens and Dobson 1994) _{. Sommerville et al. (2009) as well as Strens and Dobson (1994), argue in favor of} modeling responsibilities, especially when there are different systems owned by different actors. Developing structures to handle joint decision making is a necessity for successful collaborations, as is having a clear purpose and goal for which the collaboration is done. These things, along with clearly defined roles and responsibilities, are frequently cited among the most important enablers, or inhibitors if lacking, for successful collaboration. Because there is often an unwillingness to adjust one's own system, removing any ambiguity or clarity regarding responsibility by using some formal modeling can make integration between systems a lot easier. However, this can be a tedious task in

(28)

complex environments, and the formality of strict models may not stay well aligned with the often changing dynamics of interorganizational collaborations. An extensive review of such collaborations revealed that the dynamics of the collaborations often changed over time. The dynamics changed in terms of the characteristics, for instance how decisions were made, or by the number of people that were involved, and as chain reactions as other parts of the collaboration changed _(Majchrzak, Jarvenpaa, and Bagherzadeh 2015) _{. This fluent dynamic of such collaborations makes very strict} models difficult to maintain. However, the intended impact of responsibility modeling is to make sure that the processes are well defined and that there is no ambiguity of ownership of requirements or otherwise.

A relatively new area of research is collaboration engineering, a design approach for reusable processes and technology for collaboration. De Vreede and Briggs _{(2005) describe the collaboration} engineering way of thinking as consisting of four abstraction layers, namely the process layer, the pattern layer, the thinkLets layer and the phenomenon layer. The first of these layers is concerned with identifying _what _{the group that is working with collaboration means to do. This entails} understanding the problem, developing alternative solutions, evaluating alternatives, choosing feasible alternatives and making a plan, among others. Notably, this layer does not cover how these things are done, rather that is what the next abstraction layer covers. The pattern layer is concerned with _how _{the group can move through a process of collaborative work. The group can either} generate or reduce the number of concepts being considered, clarify the already considered concepts, organize concepts by relationships between them, evaluate concepts in relation to certain criteria, and build consensus among stakeholders or group members _{(Briggs et al. 2006). All of these} six activities are ways of creating or developing a broader or deeper understanding of the phenomenon. The third abstraction layer, the thinkLets layer, should provide building blocks - called thinkLets - of repeatable smaller activities that can be applied for the group to approach the larger parts of the second abstraction layer. The fourth abstraction layer is not hierarchical, but rather the theoretical underpinning that should form the foundation of the creation of each thinkLet _(de Vreede and Briggs 2005) _{. The idea with collaboration engineering is to identify which recurring} problems a collaborating group encounters, and therefore implement a solution to those problems. Another way of stating this is to provide processes that can be applied to help a group gradually improve its effectiveness when encountering the same problem _{(Briggs et al. 2006). This is not only} true for the practitioners taking on engineering challenges or hands on tasks, but is just as true for managing the collaboration _{(Thomson and Perry 2006).}

In order to enable efficient collaborations, alignment of processes between the collaborating companies is key. In order to achieve that alignment four key steps should be taken, namely process standardisation, knowledge sharing, alignment of existing processes and elimination of waste in the joint development cycles _{(Evans and Jukes 2000). These steps build upon each other, where process} standardisation is a company internal necessity to have a baseline for knowledge sharing and subsequent process alignment. However, even when having created a baseline for process

(29)

standardisation and alignment, in the context of collaborative relationships the interpersonal relationships that make up that collaboration can’t be ignored. When the collaborative effort is done by a heterogeneous team, the potential value created increases, but so does the need for clarifying interpretations of tasks and clarifying interpretations (Bittner and Leimeister 2013). Interorganizational work is also perceived as more valuable to both companies if there is collaborative value creation rather than just information exchange, as it unlocks the potential for a greater array of input to the creative process _{(Moss Kanter 1994).}

(30)

3. Method

This chapter describes the methods used in this study. First the research design is described and motivated. Then the data collection is detailed, followed by a description of the data analysis. Finally, it is described what measures have been taken to assure the quality of the research.

3.1. Research design

Part of the reason for this being a difficult area of research is the inherent intricacies of the social context of the problem. Experiments or surveys designed to investigate some specific phenomenon observed in this context would risk excluding or dimishing aspects not conceived during the design (Yazan 2015; Blomkvist and Hallin 2015) . Thus, to capture the complexity inherent to the topic, it was deemed that a qualitative or survey study would not be recommendable for this topic. Therefore, this report is based on a case study, divided into three phases. The first phase consisted of observations and interactions with the persons most central to the case project. The purpose of this phase was to understand the context of the project, create an initial map of stakeholders as well as identify which stakeholders would be suitable to interview. The second phase consisted of interviews within the team working with requirements along with reviewing internal documents explaining the history of the project and ongoing initiatives. The purpose of this phase was to map the existing processes and subsequently identify what issues existed within those processes as well as enable the formulation of hypotheses of the reasons for those issues. The third phase consisted of a second round of interviews with a broader set of stakeholders as well as more focused questions to challenge the research questions and theory. The purpose of this phase was to gain deeper insights regarding the work of the teams involved with the requirements process in order to test the hypotheses formulated in the previous phase. The phases are illustrated in figure 3.

(31)

Figure 3. The phases of the study. The blue items contain the primary activities included in each phase, and the green items contain the purpose of each phase.

Due to the context of the project and the project itself both being quite complex, it was not possible to at the beginning of the research identify applicable theory. Through the first phase a number of possible theoretical frameworks were identified, and abductively the suitable theoretical scope was decided as the issues and context was identified in phase two. Based on that scope the theory was expanded before and during the third phase.

The study was conducted at Scania Commercial Vehicles (Scania CV) at the headquarters in Södertälje, Sweden, during the spring of 2019. The context for the study was within the R&D department, within the context of a project concerned with facilitating collaboration between Scania and MAN. The case being investigated was the requirements engineering for an IT system meant to support an emerging business function. Because requirements engineering is a human-centric activity, a qualitative approach was taken to capture the inherent intricacies of human collaboration that can affect the efficacy of the requirements engineering process _{(Sommerville 2011). Thus, in} terms of the perspectives of industrial management, this study considers the dynamics of the individual level, and letting that inform the processes and dynamics of the functional level, while letting the industrial level primarily provide the context for the study (Blomkvist and Hallin 2015). This thesis has been written in parallel with a thesis by another student, Erik Lindström. The two theses are based on the same case study but concerns separate topics and serves to in conjunction inform the company from different angles. The case for the company served to answer three questions. Firstly, what inefficacies or bottlenecks are there in the requirements process? Secondly, how well are the elicited requirements preserved through the requirements process? And thirdly, are the right requirements collected and preserved through by the requirements process? Thus, the data collection has been done collaboratively for the two theses, and the students have also collaborated with reviewing the source material after it was collected. However, the literature review, analysis and subsequent writing of the reports have been done separately. Therefore, similarities between the two reports are to be expected, but the purpose of each report is separate and each report can be read

Categorizing and managing difficulties in interorganizational requirements engineering

Categorizing and managing

difficulties in interorganizational

requirements engineering

SAMUEL ANDRÉN

Categorizing and managing difficulties in

interorganizational requirements

engineering

by

Samuel Andrén

Kategorisering och hantering av svårigheter

inom interorganisatoriskt kravarbete

av

Samuel Andrén

Table of contents

Foreword

​1.​ Introduction

​1.1.​ Purpose

​1.2.​ Research questions

​1.3.​ Delimitation

​1.4.​ Disposition

​2.​ Literature review

​2.1.​ Requirements engineering

​2.2.​ Types of requirements

​2.3.​ Processes, activities and techniques

​2.3.1.​ Requirement elicitation

​2.3.2.​ Requirement analysis

​2.3.3.​ Requirement validation

​2.3.4.​ Requirement management

​2.4.​ Documentation in requirements engineering

​2.5.​ Communication

and

culture

in

requirements

engineering

​2.6.​ Distance and contexts in interorganizational settings

​2.7.​ Collaboration engineering and process definition

​3.​ Method

​3.1.​ Research design

1. Introduction

1.1. Purpose

1.2. Research questions

1.3. Delimitation

1.4. Disposition

2. Literature review

2.1. Requirements engineering

2.2. Types of requirements

2.3. Processes, activities and techniques

2.3.1. Requirement elicitation

2.3.2. Requirement analysis

2.3.3. Requirement validation

2.3.4. Requirement management

2.4. Documentation in requirements engineering

2.5. Communication

2.6. Distance and contexts in interorganizational settings

2.7. Collaboration engineering and process definition

3. Method

3.1. Research design