1 Introduction

Requirements elicitation, also called requirements gathering, is the process of discovering system problems and solution requirements for a system by gathering knowledge from stakeholders who have a direct or indirect influence on the requirements [1, 2]. Establishing design requirements, sometimes termed problem definition, is one of the most important elements in the design process and applied by many engineering disciplines [3, 4]. A more recent application of the design process is to design the enterprise as an artefact, also called enterprise engineering (EE) [5]. Yet, enterprise design is by no means simple, since enterprises rank amongst the highest in complexity, i.e. level eight on Boulding’s [6] nine-level complexity scale. Even though there may be limits to formal enterprise design due to enterprise complexity, the realisation of strategic intentions and successfully addressing areas of concern do not occur spontaneously/incidentally [7]. Enterprises are intentionally created entities and are created via design when design is defined as: “courses of action aimed at changing existing situations into preferred ones” [8].

Multiple theorists and practitioners address enterprise complexity by developing structured approaches for enterprise design [9]. Similar to the ad hoc evolution of enterprises, EE as a discipline also developed in a fragmented way with enterprise design knowledge mostly encapsulated in several enterprise design approaches [10]. De Vries et al. [9] studied eight different enterprise design/alignment approaches, inductively developing a common framework to represent and compare these approaches. The enterprise evolution contextualisation framework (EECM) indicates that the analysed approaches can be represented by four main components:

  1. 1.

    A belief/paradigm of value creation that the approach offers.

  2. 2.

    Three dimensions that represent the extent of enterprise design/alignment scope.

  3. 3.

    Mechanisms and practices that are used to ensure consistent design/alignment for the intended design/alignment scope.

  4. 4.

    Approach classifiers that represent common patterns of design detected in the existing design approaches.

Based on the belief/paradigm of value creation, a particular approach usually offers various mechanisms and practices to align a certain part of the enterprise as defined by the dimensions [9]. Even though EECM provides a common reference framework to compare existing approaches [11], EECM is neither prescriptive in evaluating the components of an existing approach, nor prescriptive in guiding a theorist/practitioner when he/she develops a new approach. EECM represents the enterprise design/alignment scope, namely the dimensions. The three dimensions include:

  1. 1.

    Design domains that represent abstract sub-systems within the enterprise that should be designed/aligned.

  2. 2.

    Concerns and constraints as emerging concerns/expectations/intentions of different stakeholders within the enterprise design process.

  3. 3.

    Enterprise scope that reflects formal implementation structures that are often used to organise employees within an enterprise as a legal entity, e.g. departments, programmes and projects.

De Vries [12] already critiqued existing approaches for their inconsistent means of defining the first dimension, namely the design domains [12]. Contributing towards the prescriptive knowledge within the EE discipline, this article focuses on the second dimension, i.e. concerns and constraints. As will become evident in this article, the research process itself highlighted the problematic nature of the word concerns and its negative connotation; hence, we have replaced the word concerns with intensions in this article. The study addresses the following questions:

  • What methodologies and techniques are currently available to guide elicitation of intentions and constraints?

  • What techniques/methods are available to clarify concepts associated with intentions and constraints for an existing or new enterprise design approach?

  • What method should be developed to clarify concepts associated with intentions and constraints for an existing enterprise design approach?

  • How useful is the newly developed method?

Using design science research, we develop a method for enterprise intention concepts clarification (MEICC) as the main contribution of this article. The MEICC is primarily a practical contribution, since it is useful to clarify concepts related to intentions and constraints when a new enterprise design approach is designed or when an existing enterprise design approach provides limited guidance on distinguishing between concepts related to intentions and constraints. As an example, MEICC should be useful in the following scenario: An existing approach identifies two different concepts that embody enterprise design intentions, namely areas of concern and requirements. However, the approach provides limited or ambiguous descriptions and examples of areas of concern and requirements. MEICC should be used to iteratively refine, clarify and possibly rephrase the concepts.

The rest of the paper is structured as follows: Section 2 provides additional background on one of the EECM dimensions, namely intentions and constraints, elaborating on how existing approaches within the EE discipline and associated techniques represent this dimension, the deficiencies of existing techniques and the need to provide more guidance by developing the MEICC. The section concludes with some background on an existing EE approach, namely Hoogervorst’s approach, since we use his approach for demonstrating the MEICC. Section 3 presents the research methodology, i.e. design research that was used for developing the MEICC, whereas Sect. 4 presents the constructional parts of the MEICC. Section 5 provides a demonstration of the MEICC when applied to Hoogervorst’s approach, as well as a coding strategy when practitioners use Hoogervorst’s intention-related concepts. We discuss our findings in Sect. 6, concluding on limitations and recommendations for future work.

2 Background

Although many disciplines contribute new knowledge about the nature, behaviour and design of the enterprise [13], EE is an emerging discipline that focuses on the holistic governance and design of the enterprise, aligning the intended functions/objectives of the enterprise with its construction [5, 14]. In general, the term enterprise refers to a business, company, firm, corporation, organisation or institution, i.e. a purposeful social entity of human endeavour [15].

Numerous theoretical approaches exist to guide enterprise design, each based on a particular conceptualisation of the enterprise and its parts [9]. As discussed before, existing enterprise design approaches may be represented by four main components of which three are usually evident [9]:

  1. 1.

    The author(s) of a theoretical approach usually focus on a particular enterprise design-related phenomenon, formulating a belief/paradigm of value creation to address the phenomenon.

  2. 2.

    Approach author(s) may also be explicit in stating their intended design scope via three explicit dimensions, i.e. design domains, concerns and constraints, and enterprise scope.

  3. 3.

    They usually present a number of mechanisms and practices to ensure consistent enterprise design across the intended dimensions.

In terms of the third component, mechanisms and practices, De Vries et al. [9] identified a not-exhaustive list of nine categories of mechanisms and practices. Yet, a theoretical approach seldom encapsulates all nine categories. One of the categories, i.e. methodology, often features within an enterprise design approach. A methodology stipulates a systematic design process for designing/aligning the enterprise as an artefact across the enterprise dimensions. The methodology should ensure that relevant enterprise intentions and constraints are addressed within the design domains of the enterprise.

2.1 Existing approaches within related disciplines

Since EE is still an emerging discipline [5], focusing on designing the enterprise as an artefact, it draws on other existing mature disciplines that also involve the design of artefacts, such as systems engineering [16, 17] and software engineering [13]. Within their design processes, mature disciplines have already developed methodologies to ensure that the initial design intentions are systematically translated into structural components of the artefact.

Within the systems engineering discipline, three main methodologies exist, namely the V-model, incremental and hybrid methodologies [17]. Within software engineering, multiple methodologies exist to reduce the semantic gap between software systems as artefacts and their operational environment, such as ASPIRE, SIKOSA, TROPOS and i* [18, 19].

2.2 Existing methodologies and techniques within related disciplines

Existing methodologies provide guidance on the process for eliciting design intentions, i.e. facilitating various activities to elicit, model and manage intentions. In terms of modelling, the i* framework, [20], provides a means to trace design intentions as goals throughout the artefact design process and up to the phase where constructional alternatives are defined and compared [19, 21]. Yet, Horkoff and Yu [19] believe that the reliability of goal-oriented requirements engineering depends on a number of factors such as various interpretations of goal model syntax, measurement choices for goal satisfaction and the level of participation of the user. Since the initial elicitation of enterprise intentions/concerns is still exploratory in nature, high-level, abstract and hard-to-measure [22] automated procedures associated with goal modelling analysis are often difficult. Horkoff and Yu [22, 23] suggest an alternative procedure for these initial phases, encouraging stakeholder involvement and model improvement via iteration. Horkoff and Yu developed a systematic and interactive analysis procedure for eliciting and evaluating goals during enterprise modelling using i* [23]. Their procedure involved multiple stakeholders to express their viewpoints, allowing multiple iterations and discussions to refine the goal models, alternative constructional solutions, also evaluating the alternative constructs. Although the models intend to represent the intentions/goals for constructing a part of the enterprise as an artefact, Horkoff and Yu do not demarcate the enterprise into design domains and their methodology does not focus on the holistic design of the entire enterprise.

Existing methodologies differ in how they classify concepts related to design intentions. The agile systems engineering methodology classifies intentions as functional/stakeholder requirements to specify system functions and other requirements (e.g. operational, logistics, usability, user interface, maintainability, certification, project and constraints) [17], whereas CORE (capability-oriented requirements engineering) refers to system capabilities, rather than system functions [24]. Horkoff and Yu [22] acknowledge two types of design intentions, namely soft goals and goals. Although we should expect that existing methodologies use similar concepts, but with different interpretations, the authors of such methodologies do not always provide sufficient descriptions and examples to clarify and distinguish between the concepts.

2.3 Existing approaches, methodologies and techniques within enterprise engineering

Within the EE discipline, design team members also clarify their understanding via conceptual models and design specifications to represent design intentions within design domains [9]. De Vries argued that design domains should be defined in a more consistent way to reduce ambiguity during design [12]. Similar to other design-related disciplines, EE researchers also acknowledge the need to address various stakeholder intentions [25] (see Chapter 21 of TOGAF 9.1) that need be explicit [7, 26] and constantly examined and monitored [27]. The Open Group indicates that multiple documents may be useful for extracting stakeholder intentions. Zachman [28] indicates that multiple intentions for different stakeholders need to be addressed during enterprise design. Although the Zachman framework provides some concepts related to intentions, associated with different stakeholders, such as motivation types, business end, system end, technology and tool end [28], it offers little methodological guidance to translate the concepts into enterprise constructions [29]. Smith [30] offers a methodology that includes a strategising phase to state concepts associated with design intentions, including mission, vision, strategies tactics, goals and objectives, with some guidance on principles (see p 65 of [31]), but with little guidance on clarifying other intention-related concepts (see p 47 of [32] and p 17 of [31]).

Giachetti [13] provides a generic approach for enterprise systems design. Although he provides some methodological guidance on eliciting design intentions, advocating traceability of identified design intentions, there is no indication of how the design intentions should be addressed within certain enterprise design domains or constructs. He identifies a number of intention-related concepts, indicating that “a distinction is made between goals, objectives, requirements and constraints”, also differentiating between functional and non-functional requirements. Furthermore, he suggests that a number of techniques are used to elicit design intentions, including data-gathering techniques (documents, interviews, observations, questionnaires and workshops), problem analyses (using cause-and-effect analyses and causal loop analyses), stakeholder analyses and requirements analysis. In clarifying intention-related concepts, Giachetti [13] provides some guidance on how the concepts vision, goal and objective should form a hierarchy, providing some guidance on how to state an objective. In terms of the concept functional requirement, Giachetti [13] suggests that the SMART (Specific, Measurable, Attainable, Realistic and Time-bound) criteria are used. For the concept non-functional requirement, he provides a number of examples, such as reliability, performance and sustainability. In terms of constraints, Giachetti [13] indicates that constraints are “restrictions on other requirements” originating from reasons such as physical limitations of resources and environmental regulatory rules.

2.4 Need to reduce ambiguity when eliciting enterprise intentions

A key criterion for defining design intentions is that they need to be unambiguous, understandable and verifiable [17]. Emphasising the need to reduce ambiguity during the process of requirements elicitation, ambiguity in communication is regarded as a major obstacle [1, 33]. Since human beings participate as design team members, they need to formulate a common understanding of the design domains that need to be constructed, as well as the design intentions that need to be addressed. Within the EE discipline, we believe that a consistent representation of design intentions should reduce ambiguity. In Sect. 3, we suggest that a new method (i.e. the MEICC) is required to distinguish between different kinds of design intentions prior to extracting and modelling design intentions for an enterprise. Our suggested method incorporates the use of a codebook and applies natural language to clarify intention-related concepts. We reduce ambiguity by avoiding plurality (see [34]), also preventing lexical, syntactic, semantic, pragmatic ambiguity and vagueness (see [35]).

In Sect. 3, we suggest that the newly developed MEICC should be useful to clarify intention-related concepts for an existing or new enterprise design approach and we motivate our choice to demonstrate its use, using Hoogervorst’s [7] approach. The next section provides some background on Hoogervorst’s approach.

2.5 Hoogervorst’s iterative approach

Hoogervorst [7, 14, 15] acknowledges that an enterprise is a morphogenic, dynamic, sociocultural system that will only exist/survive if it is capable of reacting to contingencies concerning, for example consumers, competitors, weather (especially agricultural enterprises) and economics. The enterprise as a system should have sufficient variety or regulating ability to address the variety it faces [15, 36]. Traditional approaches reduce or attenuate enterprise variety through rules, regulations and management directives, which create rigidity and the inability to properly respond to the variety they face [15]. In contrast, Hoogervorst [15] suggests a different approach to deal with variety, namely to increase the enterprise regulating variety. He presents an iterative approach that guides and converts design intentions into enterprise constructions within different design domains.

Hoogervorst’s approach provides a multidisciplinary inquisitive approach with relevant stakeholders, starting with the strategic context. As indicated in Fig. 1, strategic contexts have to indicate certain areas of concern (alternatively defined as performance areas), whereas detail requirements are defined to deal with the areas of concern. Since requirements and areas of concern need to be addressed in design domains, it is possible to formulate design principles that will address the areas of concern if enterprise designers apply the design principles to one or more design domains. Although enterprise design encapsulates elicitation of detailed requirements, Hoogervorst [7] focuses more on formulating design principles that are primarily used to ensure unity and integration across the implemented design domains of the enterprise.

Fig. 1
figure 1

Iterative enterprise design approach, based on Hoogervorst [7]

Full size image

Following Hoogervorst’s guidance to involve multiple team members, Van der Meulen [37] experimented with the iterative approach, but indicated that additional guidance was required when translating design intentions into enterprise constructions within design domains. Following Gauss and Weinberg’s advice [38] to clarify words and concepts, reducing interpretation ambiguity, Van der Meulen [37] argued that a codebook was required to define and distinguish between concepts associated with Hoogervorst’s iterative approach. As indicated in Fig. 1, two categories of concepts exist, namely design domains and design intentions. Design domains (e.g. organisation, ICT, infrastructure and human skills and know-how) are abstract or real areas for which design activities are required, whereas design intentions (i.e. design principles, areas of concern, requirements and functions) provide functional or constructional guidance for creating/changing the construction of design domains.

Van der Meulen [37] experimented with Hoogervorst’s [14] demarcated design domains, but experienced difficulties during the process of sense-making when his design team applied emerging design principles to the main design domains. Based on his suggestion to use the basic system design process to redefine design domains in a more consistent way [37], a subsequent study suggested a new set of design domains [12]. The newly demarcated design domains are already reflected in Fig. 1. Hoogervorst’s [7] initial framework included an additional design domain, called the business domain. Yet, since the business domain represents functions of the enterprise, rather than its construction [12], Fig. 1 presents functions as design intentions.

The study in [12] highlights multiple concurrent design cycles that exist between using systems and object systems in an enterprise [12]. We provide a short definition for each design domain and typical models or modelling languages that are used to represent the particular design domain. The interested reader is referred to [12] for additional elaboration on typical design cycles that are associated with different design domains.

2.5.1 Organisation domain

The organisation domain encapsulates actor roles, implemented by human beings, that form relationships due to their interactions and communications when they perform production acts [39]. Dietz [39] suggests aspect models that represent the essence of enterprise operation in a coherent, comprehensive, consistent and concise way.

2.5.2 ICT domain

The ICT domain incorporates software applications, databases and ICT hardware [39]. Different representations are used to communicate ICT designs, such as unified modelling language (UML) models [40] and wireframing models [41].

2.5.3 Infrastructure domain

Infrastructure entails facilities and other non-ICT technologies that support actor roles and their production acts. Enterprises within different industries may require different representations of infrastructure, based on the type of production acts that should be supported. The educational industry, for instance, may apply web-based 3D interactive campus models to visualise learning facilities.

2.5.4 Human skills and know-how domain

Human skills and know-how constitutes human abilities and skills required when executing production acts, as well as coordination acts. Skills and know-how are often represented in curricula vitae.

Although it was necessary to clarify the definition for the main enterprise design domains as distinguished from design intentions, this article primarily focuses on a method (i.e. MEICC) to clarify concepts that are related to design intentions.

3 Research methodology

The study forms part of an existing project that applies design science research (DSR), where existing concepts within the EE discipline exist, but require further clarification. DSR is a research methodology that is developed from the design science knowledge area. Whereas design science reflects on design as a topic of investigation to explore almost any design-related subject, DSR uses design as a method for investigation [42], aiming to create “solutions to specific classes of relevant problems by using a rigorous construction and evaluation process” [43]. Simon [8] differentiates design science from other paradigms as follows: “Whereas natural sciences and social sciences try to understand reality, design science attempts to create things that serve human purposes”. Hevner et al. [44] state a key differentiator between routine design and DSR, namely that DSR contributes to the “archival knowledge base of foundations and methodologies”. The fundamental principle of DSR is that “knowledge and understanding of a design problem and its solution are acquired in the building and application of an artefact” [44]. Knowledge and action form a cycle, in which knowledge is used to create works, and works are evaluated to build knowledge [45]. March and Smith [46] identified four design artefacts that are produced by information system-related DSR, i.e. constructs, models, methods and instantiations.

When discussing epistemological perspectives of design science research (DSR), i.e. perspectives on producing “true” knowledge via DSR, Niehaves [47] argues in favour of epistemological diversity and to establish constructive pluralism within DSR. Although the seven guidelines provided by Hevner et al. [44] on conducting research and evaluating knowledge within DSR follow a rather implicit positivist epistemology, Niehaves [47] mapped the seven principles of Klein and Myers [48] for interpretive field studies to five of the seven guidelines of Hevner et al. [44] to demonstrate the possibility of an interpretivist stance when conducting DSR. Even though the seven guidelines offered some guidance on DSR, Peffers et al. [49] believe that different genres have developed within the DSR community, characterising genres in terms of their focus, research process, role of theory and evaluation. As an example, the IS design theory genre of Gregor and Jones [50] focuses on the presentation of design theories and their conceptual-oriented evaluation. In contrast, the DSR methodology genre of Peffers et al. [51] focuses on applicable artefact development and its evaluation that should be outcome oriented and practical.

Following the DSR methodology genre of Peffers et al. [51], this study focuses on the development of an artefact, i.e. we suggest that a new method (i.e. MEICC) is developed as an artefact. Methods define processes or guidance on how to solve problems, ranging from mathematical algorithms to informal, textual descriptions of “best practice” [46]. In accordance with Gregor and Hevner’s [52] knowledge contribution framework, our newly developed MEICC can be considered as an improvement study, since a known problem is addressed.

3.1 The design science research design cycle

Referring to the DSR phases of Peffers et al. [51], this article addresses the first four phases of the DSR cycle as follows:

3.1.1 Identify a problem

EE researchers already acknowledge the need to address various stakeholder intentions [25] that need be explicit [7, 26] and need to be constantly examined and monitored [27]. The Open Group [25] indicates that multiple documents may be useful for extracting stakeholder intentions, and Giachetti [13] proposes various means of data-gathering to elicit design intentions. We believe that existing EE approaches need additional rigour in clarifying and classifying the emerging design intentions, prior to the iterative extraction and translation of intentions into enterprise design specifications.

3.1.2 Define objectives of solution

We suggest that a method for enterprise intention concepts clarification (MEICC) is developed to reduce ambiguity, distinguishing between design intention-related concepts for an existing or new enterprise design approach.

3.1.3 Design and develop

Prior to designing the MEICC, we considered different techniques that would address MEICC’s solution objectives. In Sect. 3.2, we elaborate on the different techniques that could be considered in addressing the solution objectives for MEICC, motivating the use of a codebook. The study applied principles of reducing ambiguity [34, 35] and principles of codebook design [53] to construct the MEICC, a method that uses a codebook to refine concepts related to design intentions in terms of a code label, condensed definition, full definition, example, what it is not, how to state and cues for coding.

3.1.4 Demonstrate

Hoogervorst [7] presents an approach that is focused on design, i.e. eliciting intentions, translating intentions into design principles that would guide future designs within design domains. Similar to other existing EE approaches, Hoogervorst [7] provides some guidance in further classifying design intentions. Yet, Van der Meulen [37] experimented with Hoogervorst’s iterative approach, but indicated that additional guidance was required to clarify the concepts. Although Van der Meulen [37] already used a codebook to distinguish between intention-related concepts associated with Hoogervorst’s approach, he only involved a single participant to validate his codebook. We also use Hoogervorst’s approach to demonstrate the newly developed MEICC, but involve multiple participants with several iterations of code refinement.

Although we only discussed the first four phases of the DSR cycle, we elaborate on future work in Sect. 6 of this article.

3.2 Different techniques for addressing the solution objectives

Different techniques can be considered to address the main solution objectives for the MEICC. This section elaborates on three possible techniques and the rationale for using two of the techniques during the development of the MEICC.

3.2.1 Conceptual models and ontologies

Conceptual models were initially used to provide a pictorial representation of several ideas as to increase understanding and communication of a system or domain amongst different stakeholders within the information system discipline [54]. An example of a conceptual model is shown in Fig. 1, used to represent concepts associated with the iterative enterprise design approach of Hoogervorst. Although conceptual modelling was initially focused on defining user requirements for information systems on different levels [55, 56], conceptual models also provide a common understanding amongst stakeholders within many different areas, ranging from enterprise strategic management, service sciences and technology-enhanced learning [57]. Yet, conceptual modelling techniques are also criticised, since many of the techniques lack adequate specification semantics for the terminology of the underlying models, leading to inconsistent interpretations and uses of knowledge [58]. Ontologies are useful to overcome these issues, since ontologies describe a set of things associated with a particular theory or system of thought [59]. Ontologies can be applied to articulate and reason about the contents of a conceptual model [60], describing the structure and behaviour of the modelled domain [61]. Even though Verdonck et al.’s [62] empirical research indicated that ontology-based conceptual modelling (OBCM) increases the quality of the conceptual models when modelling advanced concepts of a domain, research subjects had to receive training in OBCM modelling “over a period of several months”. Within the context of this study, we believe that a conceptual model, as shown in Fig. 1, provides some understanding of the concepts associated with an existing enterprise design approach. Thus, similar to what Guizzardi et al. [63] did, it is possible remove possible ambiguity and conceptual overlap of concepts by starting with the existing concepts promulgated in an enterprise design approach and develop an ontology from the existing concepts that is grounded in the unified foundational ontology (UFO). Since participants of the ontology development team need to be well trained in OBCM, we did not incorporate OBCM when developing the MEICC. In Sect. 6.2, we still acknowledge the value of using OBCM and suggest future research to experiment with OBCM as a means to clarify design intention-related concepts associated with an enterprise design approach.

3.2.2 Focus group discussions

Giachetti [13] suggests that requirement workshops are used for requirements elicitation, since “they can be designed to encourage consensus concerning the requirements for a particular system capability or feature”. He lists several benefits, including its: (1) Involvement of stakeholders across organisational boundaries; (2) Interactive, dynamic and cooperative nature; and (3) Ability to provide structure to the capturing and analysis of requirements. Yet, Giachetti [13] provides limited guidance on structuring a requirements workshop, indicating that a joint requirements planning (JRP) workshop is often used to elicit requirements for information system development. Krueger and Casey [64] refer to a more generic form of workshop, namely focus group discussions that are used to perform data-gathering on a particular topic in a structured way. The format of a focus group discussion is similar to that of a requirement workshop, and we believe the guidelines presented by Krueger and Casey’s [64] would also be applicable when it is used to distinguish between different design intention-related concepts in a participative way. In Sect. 4.2, we indicate how we incorporated Krueger and Casey’s [64] guidelines into the MEICC, partially addressing the main solution objectives for the MEICC, i.e. reducing ambiguity when systematic and participatory focus group discussions are used to iteratively distinguish and refine design intention-related concepts of an enterprise design approach.

3.2.3 Using a codebook

Guest et al. [53] believe that the codebook is one of the most critical components of thematic analysis. Similar to grounded theory, thematic analysis is used to interpret free flowing text, moving beyond counting explicit words or phrases and “focus on identifying and describing both implicit and explicit ideas within data”. Since multiple analysts may be involved when analysing multiple documents, Guest et al. [53] use a codebook to ensure consistent interpretation of text, monitoring and improving interpretation consistency by assessing the level of intercoder agreement. Codebook development is a discrete analysis step within thematic analysis, where the “observed meaning in the text is systematically sorted into categories, types and relationships of meaning” [53]. The codebook thus assists in clarifying the meaning of an identified theme, defining the identified theme as a code within a codebook. Based on various different studies in different settings over many years, MacQueen et al. [65] indicated that a code definition needs to be clarified using: (1) code label; (2) short definition; (3) full definition; (4) when to use; (5) when not to use; and (6) an example. The rigour of the codebook increases if the code definitions are refined in an iterative way, resolving interpretation discrepancies, until acceptable level of intercoder agreement is obtained [53]. We believe that a codebook and its iterative refinement could be useful to incorporate within the MEIC. Partially addressing the main solution objectives for the MEICC, i.e. reducing ambiguity when distinguishing between different design intention-related concepts, we believe that a codebook can be used to define, refine and document the design intention-related concepts, removing possible interpretation discrepancies that may exist amongst different design team participants until intercoder agreement is obtained.

The next section elaborates on the newly developed MEICC and how we incorporated focus group discussions and a codebook within the structural components of the MEICC.

4 Method for enterprise intension clarification

The design of MEICC is based on the principle that ambiguity should be reduced by following a systematic, iterative and participatory process on refining design intention-related concepts that are associated with an existing or new enterprise design approach. Using natural language as a means of documenting and communicating the design intention-related concepts via a codebook, we suggest that the codebook designer should follow two main iterations of codebook refinement.

4.1 First iteration

The purpose of the first iteration is to assess whether the existing intention-related concepts, associated with a selected enterprise design approach, provide sufficient clarity and distinction when concepts are applied during documental coding.

4.1.1 Before coding

Prior to coding, the codebook designer needs to construct or obtain the following inputs:

  • An initial codebook should be constructed by the codebook designer, referring back to the initial definitions about intention-related concepts that are provided by the author(s) of a chosen enterprise design approach. The codebook designer should refine intention-related concepts as to avoid plurality [34], preventing lexical, syntactic, semantic, pragmatic ambiguity and vagueness [35]. Based on Guest et al.’s [53] guidance on codebook design, every intention-related concept should be defined in terms of a code label, condensed definition, full definition, example, what it is not, how to state and cues that may be useful during coding.

  • A narrative that incorporates intention-related concepts should be obtained, such as minutes of a management meeting for a selected enterprise.

  • A sample of participants should be selected for the coding exercise. The participants should have some knowledge about the industry of the selected enterprise.

4.1.2 During coding

The codebook designer has to start the coding session by introducing a selected enterprise design approach to the participants. Then, participants need to use the codebook and narrative to perform content coding. The codebook designer should not over-explain the intention-related concepts. Rather, the participants should perform coding, using the codebook on face value. Since the codebook designer should gain an understanding about the reasons for coding deviations, he/she should ensure that:

  • Participants are encouraged to request clarification from the codebook designer for fragments in the narrative that are difficult/problematic to code.

  • A participative approach is followed to allow for real-time identification of problems regarding the codebook. Any adaptations to the codebook should be communicated to all participants while coding proceeds.

  • Field notes are used to track feedback from participants on problematic textual fragments in the narrative, as well as the changes that were communicated to participants regarding codebook changes.

  • Participants submit their coding results to the codebook designer once they have completed the coding exercise.

4.1.3 After coding

After the participative session, the codebook designer has to analyse the coding results to identify coding inconsistencies and reflect on possible reasons for inconsistencies. The main deliverable of the first iteration is an updated codebook, based on the participant feedback and the coding results.

4.2 Second iteration

For the second iteration, a focus group should be used to obtain feedback on the updated codebook. As reported by Krueger and Casey [64], focus groups provide an opportunity to obtain rich data from a small and diverse group of people familiar with the study. A focus group would be a suitable instrument to perform formative evaluation of the updated codebook, since the number of participants is limited and differences in coding results are discussed in more depth.

4.2.1 Before coding

The codebook designer uses the following guidelines of Krueger and Casey [64] to plan for a focus group discussion:

  1. 1.

    Group size. The group should be conducted with 4–12 people, led by a skilled moderator [64]. The group has to be small enough for everyone to have an opportunity to share insights, but also large enough to provide diversity of perceptions. If a topic is complicated, 10–12 participants are risky and may produce trivial results. Also, when time is limited (90 min), the size of the group should be restricted [64].

  2. 2.

    Time. Focus group sessions are typically 2 h long [64].

  3. 3.

    Questioning route. Krueger and Casey [64] present practical guidance regarding the sequence of questions (e.g. general to specific), phrasing of questions (using open-ended questions, keeping questions simple) and revising questions if clarification is required.

  4. 4.

    Sampling. Random sampling is of limited value in focus group research, since the intent of a focus group is to understand and provide insights—not to generalise [64].

  5. 5.

    Analysis. Data can be captured in different forms as the basis for analysis, e.g. transcripts, abbreviated transcripts, notes and memory [64]. Note-based analysis relies on field notes and is audio recorded as a backup to clarify confusing aspects contained in the notes [64].

4.2.2 During Coding

Similar to the first iteration, focus group participants need to use the updated codebook to re-code the same narrative that was used during the first iteration. The main intent of the second iteration is to obtain feedback from the participants, adapting the codebook until participants’ coding results become consistent. Thus, multiple sessions of coding and feedback may be required.

4.3 Presenting the coding strategy

The main output of the MEICC is a coding strategy that may be used in combination with the selected EE approach. Whereas the first two iterations of MEICC experimented with a preliminary codebook, with the intent to refine the codebook based on the inconsistencies of the coding results, the last part of MEICC presents a coding strategy that should be useful to an enterprise designer when he/she extracts and classifies enterprise intentions for a particular enterprise design scope. We suggest that the coding strategy consists of coding conditions, a refined codebook and a coding method.

4.3.1 Coding conditions

One of the main conditions for coding is that coders receive training on good coding practices, such as guarding against over-interpretation of documental text [66]. The enterprise designer should provide guidance in defining the scope and purpose of coding, since the coding results may differ drastically based on its predefined scope and purpose. As an example, one enterprise designer may only be interested in identifying design intentions related to an enterprise-wide scope, whereas another enterprise designer may be interested in identifying design intentions that are applicable to a specific department within the enterprise.

4.3.2 Refined codebook

The refined codebook provides formal definitions for concepts of a selected EE design approach. The codebook needs to provide additional guidance to reduce intercoder inconsistencies when the codebook is used to code documental text. The multiple coding iterations (e.g. first iteration discussed in Sect. 4.1 and second iteration discussed in Sect. 4.2) will indicate that some coding limitations exist, since it may be difficult to identify certain design intention-related concepts via documental coding alone. The refined codebook has to emphasise these limitations, highlighting concepts that cannot be identified via documental coding alone, e.g. using the phrase ╟Not to be used for documental text coding╢.

4.3.3 Coding method

The coding method should provide a method to coders to ensure that the coding process produces consistent coding results. The multiple coding iterations of MEICC (e.g. first iteration discussed in Sect. 4.1 and second iteration discussed in Sect. 4.2) may indicate a practical sequence of coding, e.g. some codes may belong to an aggregate coding family. Thus, it may be easier to identify the code families first and then the sub-codes. The coding method should include standards for tagging text, e.g. using underline for fragments that comply with the definition of a particular concept, and using superscript notation to associate a fragment with one instance of a concept, e.g. qualityI1 and quantityI2.

5 Demonstration

Applying the MEICC to Hoogervorst’s approach, this section presents the coding feedback for the first iteration in Sect. 5.1, followed by the coding feedback for the second iteration in Sect. 5.2. Section 5.3 concludes with a coding strategy that may be used by enterprise designers that adopt Hoogervorst’s approach at their enterprise.

5.1 First iteration and results

5.1.1 Before coding

  • For the initial codebook, the codebook designer extracted intention-related concepts presented by Hoogervorst [7, 14], as well as the codebook that was developed by Van Der Meulen [37], clarifying some of the codes to reduce ambiguity. For each code, the codebook designer also referred to examples from a fictitious tertiary education institution, rather than reusing the agricultural industry examples provided by Van Der Meulen [37]. The selected coding participants all graduated from a tertiary education institution; hence, they would have some knowledge about its primary activities.

  • An existing narrative was adapted to represent the minutes of a departmental meeting at a fictitious tertiary education institution.

  • A sample of 36 participants were involved in the coding exercise.

5.1.2 During coding

The codebook designer first introduced Hoogervorst’s iterative approach to participants, as presented in Fig. 2, broadly distinguishing between design domains and design intentions. The codebook designer then applied all the guidelines presented in Sect. 4.1.2 to facilitate the coding process. Table 1 summarises the clarification that was required and the subsequent adaptations that were made to the codebook. The adaptations were communicated immediately to all 36 participants while they were busy with coding.

Fig. 2
figure 2

Method of enterprise intention concepts clarification (MEICC)

Full size image
Table 1 Feedback during participation to adapt the codebook
Full size table

5.1.3 After coding

Participants had to submit their coding results to the codebook designer for further analysis. The codebook designer analysed the coding results to determine if participants coded the text in accordance with the intended code meanings, tabling possible reasons for inappropriate coding in Table 2.

Table 2 Incorrect way of coding and codebook adaptations
Full size table

The suggested improvements were incorporated in an updated codebook in preparation for a second iteration of experimentation and feedback.

5.2 Second iteration and results

For the second iteration, each focus group participant received a handout of the updated codebook (detailed code definitions for different design intention-related concepts) as well as a narrative that encapsulates the fictitious minutes of a departmental meeting used for the first iteration.

5.2.1 Before coding

We applied the guidelines stipulated in Sect. 4.2 as follows:

  1. 1.

    Group size. Since multiple focus group discussions were not possible, we invited 11 participants to participate in the focus group discussion, of which 7 invitees attended the discussion. The diversity of the group was reflected in gender (male:female, 3:4) race (white:coloured:black:Indian, 3:2:1:1) and industry background (public, private, manufacturing and services sectors). The second iteration was divided into two sessions. At the end of the first session, 3 participants left due to other commitments. The number of participants for the second session was thus reduced to 4 participants, still representing different genders (male:female, 1:3) race (white:coloured:Indian, 2:1:1) and industry background (public, private, manufacturing and services sectors).

  2. 2.

    Time. We conducted a 2-h session, divided into two coding and feedback sessions with a short break between sessions.

  3. 3.

    Questioning route. The codebook designer applied the guidelines of Krueger and Casey [64] regarding the sequence of questions, phrasing of questions and revising questions if clarification was required. The intent was to understand the source of inconsistent coding amongst the participants.

  4. 4.

    Sampling. From the initial set of 36 participants, we invited 11 participants that requested clarification on the codebook during the first iteration of coding. All participants were busy with postgraduate studies.

  5. 5.

    Analysis. Since note-based analysis is sufficient when the purpose of the study is narrowly defined [64], we applied note-based analysis for the study.

5.2.2 During Coding

For the first session, focus group participants were requested to read the updated codebook and provide feedback on the clarity of the codebook and the code qualifiers (i.e. condensed definition, full definition, example, what it is not, how to state, and cues for each code). The feedback from the first session is presented in Table 3, as well as the adaptations that were made to the codebook prior to the second session.

Table 3 Feedback during first participation session to adapt the codebook
Full size table

At the end of the first session, 3 participants left due to other commitments. The number of participants for the second session was thus reduced to 4 participants and the codebook designer (moderator). The reduction in participants facilitated coding comparisons and discussions on coding differences.

5.2.3 Results for first coding and feedback session

Next, we present the results of the two coding and feedback sessions.

5.2.4 Results for second coding and feedback session

For the second session, an incremental coding strategy was applied. The intent was to incrementally refine the codebook until participants’ coding results were consistent. Thus, the narrative (departmental minutes) was divided into sections, and all participants had to individually code the same section within the document. Once a section has been coded, each participant had to report on their coding results, i.e. association of textual fragments with specified codes in the codebook. Coding differences were discussed, and the codebook was adapted accordingly. Four subsequent sections were coded. For the first section that had to be coded, participants followed a concurrent coding strategy, i.e. identifying both areas of concern, prescriptors and prescriptor sub-codes. For the second coding section, participants followed an iterative coding strategy, i.e. first identifying the areas of concern in the section and then identified prescriptors and associated sub-codes. Table 4 presents the results of the different coding strategies, additional feedback and codebook adaptations.

Table 4 Feedback during second participation session to adapt the codebook
Full size table

At the end of the coding session, participants had an opportunity to reflect on the coding exercise in general. Participants agreed that domain specialists had to be involved to improve the quality of coding. One participant suggested that design intention identification and validation should be done during a collaborative session. The facilitator of the session should use the distinctions made in the codebook to guide elicitation and refinement of performance areas and prescriptors.

5.3 Presenting the coding strategy

The results of the two iterations were beneficial in assessing the practical use of existing concepts related to design intentions. The results indicated that the codebook required additional clarity and refinement to distinguish between design intentions. In this section, we present the suggested updates in terms of a coding strategy that consists of three parts: (1) coding conditions, (2) the updated codebook and (3) a coding method.

5.3.1 Coding conditions

The enterprise designer should provide additional background and training on Hoogervorst’s [7] iterative approach, referring to Fig. 1 to explain the relationships that tacitly exist between concepts.

5.3.2 Refined codebook

The refined codebook (see Table 5) provides formal definitions for concepts that are useful when applying the design approach of Hoogervorst [7]. The refined codebook also provides additional guidance to reduce intercoder inconsistencies when the codebook is used to code documental text.

Table 5 Refined codebook
Full size table

5.3.3 Coding method

The following systematic and iterative process should be followed during coding:

  1. 1.

    Since not all intention-related concepts can be clearly distinguished from documental text alone, coders should use all codes except those ones highlighted for exclusion via the phrase: ╟Not to be used for documental text coding╢.

  2. 2.

    Read a paragraph of the document, and then, identify one or more performance area(s) in Bold face set fragments that comply with the definition of performance area. Tag quotes with the same superscript identifier if the text refers to the same performance area, e.g. quality of assessmentA1 and the evaluation qualityA1. Follow additional guidance provided in the codebook on sub-codes for performance area(s).

  3. 3.

    Read the paragraph for a second time and identify prescriptors, in Bolditalic face set fragments that comply with the definition for prescriptor. Tag quotes with the same superscript identifier if the text refers to the same prescriptor, e.g. the moduleengineering designC1should incorporate more formative assessmentP1−C1 and ModulesC2 should include more formative assessmentP1−C2. Follow additional guidance provided in the codebook on sub-codes for prescriptor(s).

6 Discussion and future work

Requirements elicitation is one of the most important phases in the design process and applied by many engineering disciplines. Enterprise Engineering (EE) is an emerging discipline that applies the design process to design the enterprise as an artefact [5]. Since multiple theorists and practitioners have developed structured approaches to address enterprise complexity [9], the EE discipline developed in a fragmented way with enterprise design knowledge mostly encapsulated in several enterprise design approaches [10]. De Vries et al. [9] studied eight different enterprise design/alignment approaches, inductively developing a common framework to represent and compare these approaches in terms of four main components. One of the components represents the scope of enterprise design/alignment in terms of three dimensions: (1) design domains, (2) intentions and constraints, and (3) enterprise scope. De Vries [12] criticised existing approaches for their inconsistent means of defining the first dimension, namely the design domains and already provided guidance on demarcating design domains in a more consistent way.

Focusing on the second dimension, i.e. intentions and constraints, a key criterion for defining design intentions and constraints is that intentions need to be defined in an unambiguous, understandable and verifiable way [17]. Within the EE discipline, we believe that a consistent representation of design intentions should reduce ambiguity. The study subsequently suggested a new method (i.e. the MEICC) with the main solution objective of reducing ambiguity, distinguishing between design intention-related concepts for an existing or new enterprise design approach.

We evaluated three different techniques for addressing the main solution objective of MEICC: (1) ontology-based conceptual modelling (OBCM), (2) focus group discussions and (3) using a codebook. Since OBCM requires extensive training, it was not incorporated during the development of MEICC. Regarding focus group discussions, we incorporated Krueger and Casey’s [64] guidelines to reduce ambiguity when systematic and participatory focus group discussions are used to iteratively distinguish and refine design intention-related concepts of an enterprise design approach. A codebook was incorporated to define, refine and document the design intention-related concepts, removing possible interpretation discrepancies that may exist amongst different design team participants until intercoder agreement is obtained.

Since Van der Meulen [37] already used a codebook to distinguish between intention-related concepts associated with Hoogervorst’s [7] approach, we also demonstrated the MEICC using Hoogervorst’s approach. Whereas Van der Meulen [37] involved a single participant to validate his codebook, we improved the rigour of the codebook, following an iterative approach for codebook refinement, while involving multiple participants. A coding strategy (including coding conditions, a refined codebook and a coding method), developed for Hoogervorst’s approach via MEICC, was delivered as a secondary contribution.

6.1 Limitations of the study

We acknowledge possible epistemological diversity of DSR presented by Niehaves [47]. Following the DSR methodology genre in this study, as identified by Peffers et al. [49], we argue that this study demonstrates both a positivist and interpretive stance towards knowledge development and evaluation. This study illustrates our positivist stance, since the main objective is to produce objective and practical knowledge in the form of a method artefact, the MEICC, as the main knowledge contribution. Yet, our interpretive stance is reflected in demonstrating the MEICC. Within our interpretive epistemological position, we believe that the subjects that participated in the demonstration of the MEICC had an influence on the coding strategy that was developed for Hoogervorst’s approach. We concur that the participants’ understanding and interpretation of Hoogervorst’s intention-related concepts also had an influence on the clarification of concepts and the construction of a coding strategy for Hoogervorst’s approach. If a different group of participants were involved during the demonstration of the MEICC, a different coding strategy may have resulted.

Peffers et al.’s [49] DSR methodology genre focuses on the development of an applicable artefact, indicating that its evaluation should be outcome oriented and practical. Based on inductive analysis of existing design science process elements from various disciplines, Peffers et al. [51] synthesised six possible phases for DSR: (1) Problem identification and motivation; (2) Objectives of a solution; (3) Design and development; (4) Demonstration; (5) Evaluation; and (6) Communication. Although Peffers et al. [51] indicate that the demonstration phase may be sufficient to evaluate an artefact, a separate evaluation phase may add additional rigour depending on the nature of the problem. Section 3.1 indicates that this study applied the first four phases defined by Peffers et al. [51]. In the subsequent paragraphs, we present possible limitations of the study, especially in terms of phase five, i.e. the evaluation phase.

The positivist may reason that the main limitation of the study is that the artefact’s utility, quality and efficacy should be evaluated more rigorously (see Hevner et al.’s [44] third guideline on design evaluation). Yet, Hevner et al. [44] primarily provide guidance on evaluating an IT artefact, indicating that the IT artefact can be evaluated in terms of “functionality, completeness, consistency, accuracy, performance, reliability, usability, fit within the organisation and other relevant quality attributes”. Some of the stated measures may also be applicable to a non-IT artefact, such as the MEICC. Evaluating the MEICC in terms of completeness and usability will provide additional credibility to the practitioner.

The main limitation of the study may also be argued from an interpretive stance, indicating that evaluation of the artefact needs to acknowledge the social setting of the evaluation environment and incorporate more iteration. Niehaves [47] suggests that two of the seven principles for interpretive field studies (see Klein and Myers [48]) are useful to guide the demonstration and evaluation phases of DSR. The principle of hermeneutic cycle indicates that human understanding depends on continuous iteration. Niehaves [47] suggests that additional completeness criteria need to be specified and used to guide the number of evaluation iterations. The principle of contextualisation indicates that the evaluation findings need to stipulate the social setting of the research and evaluation environment [47]. In addition, the study needs to indicate whether the findings are in some way applicable to other situations, also specifying additional criteria for these situations.

6.2 Future work

The limitations of the study indicate that future work is required to further evaluate the MEICC. Applying the principle of hermeneutic cycle, we suggest at least two additional evaluation iterations.

The first iteration should focus on completeness and usability measures, when the resulting coding strategy of Hoogervorst’s approach, developed via the MEICC, is evaluated within a real-world context. A study is underway to apply the coding strategy partially at a real-world enterprise where Hoogervorst’s approach has been adopted in practice. During enterprise design workshops, the enterprise designer will be applying the clarified concepts, stipulated in the refined codebook that forms part of the coding strategy. The enterprise designer will be reflecting on the completeness and usability of the refined codebook. Although we excluded ontology-based conceptual modelling (OBCM) as a means to clarify design intention-related concepts within MEICC, the evaluation feedback may indicate that we also experiment with OBCM.

For the second evaluation iteration, we suggest that the MEICC is evaluated for a different enterprise design approach, such as TOGAF, developed by the Open Group (see [25]). According to the principle of contextualisation, this iteration will be useful to discover additional criteria for using the MEICC when it is demonstrated within the TOGAF context.