Strategic Alignment in Requirements Analysis for Organizational IT An Integrated Approach

Strategic Alignment in Requirements Analysis for Organizational IT: an Integrated ApproachSteven J. BleisteinNational ICT Australia/UNSWSydney, Australia+61 (0)2 8374-5518 Steven.Bleistein@.auKarl CoxNational ICT Australia/UNSWSydney, Australia+61 (0)2 8374-5522Karl.Cox@.auJune VernerNational ICT AustraliaSydney, Australia+61 (0)2 8374-5513June.Verner@.auAbstractWe present an integrated approach to requirements engineering for organizational IT to help ensure IT-business strategy alignment. A single, unified model to enable validation of system requirements against business strategy is proposed. We use VMOST analysis to deconstruct business strategy. We then model strategy using a goal-oriented requirements engineering notation; this is done within the framework for modeling an organization’s business strategy proposed by the Business Rules Group. We use Jackson’s problem frames to represent business model context. Our approach is illustrated via an e-business case study of Seven-Eleven Japan taken from the literature.Categories and Subject DescriptorsD.2.1 Requirements/SpecificationsGeneral TermsManagement, Documentation, Verification. KeywordsRequirements engineering, strategic alignment, goal modeling, problem frames.1.INTRODUCTIONStrategic alignment of IT exists when a business organization’s goals and activities are in harmony with the information systems that support them [1].CIOs have consistently considered alignment of IT with business strategy a top priority [2], and such alignment has been shown to lead to superior business performance [3]. Hence, any requirements for an organization’s IT should be in alignment with its business strategy. It is thus important that requirements analysis capture both an organization’s strategic business objectives and the activities and processes by which those objectives are to be achieved.Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.SAC’05, March 13-17, 2005, Santa Fe, New Mexico, USA.Copyright 2005 ACM 1-58113-964-0/05/0003...$5.00However, business strategy usually falls outside the scope of current requirements engineering approaches. Some approaches highlight organizational aspects of requirements such as dependency relationships among actors in a system [4] or value analysis [5]. Others focus on requirements elicitation without considering explicit and coherent statements of business strategy [6]. While these approaches address important aspects of organizational IT, they do littleto help requirements engineers validate system requirements against the more abstract high-level requirements that represent the business strategy the eventual system is intended to support.We thus propose a requirements engineering approach that unifies the modeling of business strategy with the modelingof system requirements. This unification enables validationof system requirements against objectives of business strategy via explicit linkages within a single model. To achieve this, we enable a requirements engineering goal-modeling technique to encompass strategic scope via application of a recognized framework for modeling business strategy [7]. Goal modeling within this framework is integrated with Problem Frames [8], a requirements engineering problem analysis approach, to represent the contextual properties of the business model. We use VMOST [9], an organizational strategy analysis technique, to deconstruct business strategy as a prelude to modeling.The rest of this paper is organized as follows: Section 2 presents background research. Section 3 discusses a framework for strategy analysis. Section 4 describes our approach. Section 5 presents a proof-of-concept case study. Section 6 provides a discussion and conclusions.2.BACKGROUNDIn this section we present background research. Section 2.1 discusses strategic alignment. Section 2.2 discusses requirements engineering for organizational IT.2.1Strategic AlignmentIn order to develop a requirements engineering approach that helps enable successful alignment between IT and business strategy, we surveyed research that identifies strategic alignment success factors [1, 10-14]. Two major themes recur throughout the literature: (1) the mutual understandingof business strategy between business and IT managers; and (2) incorporation of this understanding into IT planning and2005 ACM Symposium on Applied Computingdevelopment. Based on these themes, researchers recommend a variety of activities to encourage cross-communication and joint planning that include business and IT managers. However, we found no literature that suggests tools or techniques for use in early-stage development activities such as requirements engineering. Our aim is to present an approach that incorporates an explicit understanding of business strategy within requirements engineering activities as a means of ensuring alignment between requirements for a system and the business strategy it is intended to support. 2.2Requirements Engineering (RE) and Organizational ITWhile most RE research focuses on software system specification, some research addresses issues of requirements for various types of enterprise systems. We discuss this research in the following paragraphs.i*, a goal modeling notation for information systems requirements [4], is used to represent organizational intention and dependencies among actors in realizing goals. However, i* mixes goal and task entities, expressing intention or action, with contextual entities, such as actors and resources, in a single model. This mixing tends to clutter models of even simple systems, making it difficult to apply i*to modeling complex intention for large enterprise systems that might include business strategy objectives. Indeed, industrial application of i* has focused on operational systems that do not capture the scope of business strategy at all [15-17]. Other proposed approaches to enterprise modeling focus on operational level requirements, such as the roles and processes of distinct organizational units [18, 19]. These approaches also fail to capture the scope of a coherent business strategy for the whole enterprise.The CREWS “L’Écritoire” tool supports a requirements elicitation methodology that links conceptual models to requirements of information systems [6]. While the methodology has been shown to be effective in discovering high-level, abstract business requirements via interviews with multiple stakeholders, it does not support validation of those requirements against a coherent and explicitly described statement of business strategy.e3-Value, a modeling notation for e-commerce systems, enables validation of requirements in terms of the system’s potential to generate economic value [5]. However, e3-Value has been recognized as ignoring key elements of business value analysis [20, 21]. Moreover, e3-Value misses the crucial point that while value analysis can help identify economic value, it is business strategy that creates it [22, 23].3.STRATEGY ANALYSISThis section presents a framework for strategy analysis in an RE context. Section 3.1 discusses the Organizational Motivation Model proposed by the Business Rules Group [7]. Section 3.2 maps the Motivation Model to the i*goal modeling notation in requirements engineering [4]. Section 3.3 discusses VMOST analysis for deconstructing business strategy as a prelude to modeling it. 3.1Organizational Motivation ModelThe Business Rules Group proposes a conceptual framework for modeling an organization’s business strategy called the Motivation Model (BRG-Model) [7]. The BRG-Model describes the semantics of a goal model of organizational intention or business strategy, shown in Figure 1, without proposing a specific means of representation. The BRG-Model describes the motivation of an organization, in terms of its strategy, with which to align its IT.The BRG-Model provides a framework in which organizational “means” achieve organizational “ends.” Means consist of processes, tasks, and activities and include mission, strategy, and tactic in the BRG-Model. Ends are states (goals) toward which the means are meant to strive. These include vision, goal, and objective.Figure 1. BRG-Model, adapted from [7]Figure 1 illustrates a conceptual framework of the BRG-Model. The organization’s mission is the primary activity performed to achieve a vision, or overall goal state for the organization. Sometimes, an organization’s mission and vision are expressed explicitly a “mission statement.” A strategy is an activity that forms a component of the mission.A strategy achieves an abstract goal, meaning that its achievement is not quantifiably measurable. A goal contributes toward or “amplifies” the vision. A tactic aids in implementing a strategy. A tactic achieves a concrete objective quantifiably, which contributes toward achievement of a goal.3.2Mapping BRG-Model to i*It is interesting to note the parallels between the BRG-Model and i*[4]. i* includes modeling entities equivalent to the conceptual entities in the BRG-Model These conceptual entities thus map easily to i*entities. Figure 2 shows the relationships between entities equivalent to those in the BRG-Model.The BRG-Model entities of mission, strategy, and tactic are each equivalent to an i*task, represented as a hexagon. The BRG-Model vision and goal entities are each types of abstract goals or soft goals in i*,represented as clouds. A BRG-Model objective is an i*hard goal, because each is concrete and measurable (represented as a pill-shape). The arrows from task to goal, from soft goal to soft goal, and hard goal to soft goal indicate a means-end contribution link. The line with a cross mark from task to task indicates a task decomposition link.While i*provides a goal modeling notation for organizational intention, it proposes few semantic rules for constructing goal models, and practically no guidance for organizational analysis. In contrast, the BRG-Model provides a conceptual framework for analyzing and modeling organizational motivation and business strategy, but nomodeling notation.Figure 2. BRG-Model mapped to i* notationWe thus propose making the BRG-Model conceptual framework operational via i*. The BRG-Model on its own normally only serves as a guide to organizational motivation for other types of IT modeling or documentation. The BRG-Model is thus separate and distinct from systems and requirements models. However, it is generally in the mapping from an organizational model to the system model that information is lost and strategic alignment fails. The advantage in applying i* to the BRG-Model is the unification of the business strategy model with the model of system requirements. This unification provides a traceable rationale for validating system requirements against business strategy within a single framework and notation, and avoids having to map from one model to another.In addition, the BRG-Model provides semantic rules for organizational motivation modeling that do not exist in i*, as i*was not originally intended to model complex organizational intention like business strategy. The semantic rules are made apparent when referring to Figure 2. Means contribute to ends, but not the other way around; therefore, i* task entities contribute to soft goal and hard goal entities, but not the reverse as is acceptable in standard i*. In i*, tasks may compose higher-level tasks, just as in the BRG-Model tactics may compose a strategy, which in turn contribute to the composition of mission. Tasks may be decomposed into subtasks. An i*hard goal may contribute to another hard goal, or to a soft goal, just as objective can contribute to a higher-level objective or to a goal in the BRG-Model. However a soft goal may not contribute to a hard goal according to the BRG-Model, even though in standard i* this is acceptable. Thus the BRG-Model’s semantic rules constrain both relationship and entity options more rigorously than standard i*, and provide further analytical guidance for constructing a goal model of business strategy. In this way, the BRG-Model helps reduce complexity for the goal modeler and provide a greater degree of consistency between goal models. 3.3Organizational AnalysisOrganizational intention and business strategy are often expressed informally in written documents such as business plans, or in free flowing language when explained by business managers in interviews or meetings. While the BRG-Model offers a conceptual model of organizational intention and business strategy that can be made operational via i*, the BRG-Model provides little support for analyzing and deconstructing business strategy from text documents or interviews. For this purpose, we propose using VMOST analysis [9]. VMOST stands for vision, mission, objectives, strategy, and tactics. While not specifically intended for use in the BRG-Model, VMOST is a useful way of capturing an organization’s business strategy and what it intends to achieve. It is also has the added value of deconstructing organizational business strategy into components that are nearly equivalent to the entities in the BRG-Model.4.REPRESENTING CONTEXTi* provides a means for representing context within the goal model via contextual entities. These include organizational actors, which represent human roles, and IT resources, and are integrated directly into a goal model to show “strategic dependency relationships” [24]. It is important to note that while these dependency relationships are called “strategic” in i*,the use of the word has nothing to do with business strategy. The meaning in i* refers only to the recognition that achievement of some goals of an information system depend upon actors and IT resources present in the system.In our experience with i*, mixing contextual entities, actors and IT resources,with task and goal entities, expressing action and intention respectively, leads to a degree of clutter in a goal model, even for relatively simple systems. Jackson [8, 25] and the Business Rules Group [7] advocate separation of intentional from contextual concerns. It has also been suggested in previous research that it is better to separate these concerns [26, 27]. While i* uses the word intentional to describe all of the entity types mentioned above, we believe that intentional should refer only to the behavioral properties that the system should guarantee or ensure in the problem domain, i.e., the requirements, in accordance with [8]. Thus intentional entities state only desire (goals) or action (tasks), and should not represent actors or resources as in i*. Besides reduction of diagram clutter, it is important to show separately what is true of a domain regardless of the proposed system [25]; i.e., its context. Intention then allows one to describe independently how a contextual domain will change after implementation of the system. After the system’s implementation, the its requirements description becomes the contextual description of the new reality [25]. We therefore advocate separation of intentional and contextual concerns in our approach. We refrain from using i* contextual entities of actors and resources in goal models. We describe contextual information using context diagrams from Jackson’s Problem Frames [8]. Our approach thus integrates use of goal modeling with Jackson Problem Frames.In previous research, it has been shown to be possible to use goal models to represent the requirement part of a Jackson problem diagram [26-29]. We use goal models to capture all behavioral properties of a system, from high-level strategic business objectives to low-level system requirements, including business goals, strategic objectives, activities, and any other business or system requirements. A goal model helps ensure that the requirements, at lower levels, are in harmony with and provide support for objectives of business strategy at higher levels. Problem diagrams help situate requirements explicitly in the context to which they refer. The integration of a goal model with a progression of Jackson problem diagrams [8] is illustrated in Figure 3 below. The requirement sets RA, RB, RC, down to the requirement set for the machine RM [8],at each level of abstraction, are described as a portion of a larger goal model. The goal model portions represent requirements at a level of abstraction equivalent to that of the context domain, DA, DB, DC, down to the machine, M. By machine we mean the computer system that we build [8]. Each goal refers to specific domains of interest(not shown in Figure 3) within the referred domain, thus maintaining consistency between intentional and contextual parts of the progression. All domains of interest are real-world entities, rather than abstract data types or conceptual entities [8]. The goal model connects requirements at adjacent levels via contribution relationships between sub goals and goals. The sub goals are projections of their super goals, and satisficing of the sub goals guarantees satisficing of the super goals [30] in the same way that satisfaction of RB guarantees satisfaction ofRA [8].Figure 3. Goal Model with Progression of Problems We do not discuss integration of goal models with Jackson problem diagrams any further here. A detailed discussion can be found in [26-29].5.SEVEN-ELEVEN JAPAN CASEWe use a business case of Seven Eleven Japan’s e-business system taken from a number of sources [31-33] to illustrate our approach.5.1Overview of Seven-Eleven Japan’s Strategy Seven-Eleven Japan (SEJ) manages a national network of convenience stores. SEJ generates value by optimizing a supply chain of independently owned business partners that include manufacturers, distributors, third-party logistics providers, and franchise shops. SEJ owns very few physical assets. SEJ’s business strategy relies on ownership and control of information as a means to anticipate consumer purchases store-by-store, item-by-item, hour-by-hour. SEJ’s value proposition to franchise-storeowners is to enable each store to provide its customers with products they want when they want them, thereby increasing sales, lowering inventory costs, lowering scrap costs of unsold goods, and maximizing use of limited floor space. SEJ leverages IT to accomplish its strategic objectives. To better understand customer demand, SEJ actively gathers and analyses purchasing information in real time, and correlates the data with other social and environmental factors, including neighborhood demographics, planned local events like festivals, and the weather. SEJ then uses a precisely tuned just-in-time delivery system to meet store customer demand. It is these activities and their objectives that constitute the higher-level requirements of SEJ’s organizational IT.5.2From VMOST Analysis to Goal ModelBased on the SEJ case literature [31-33], we performed a VMOST analysis of the SEJ’s strategy, structuring the analysis in accordance with the BRG-Model, discussed in Section 3.2. We do not discuss how VMOST analysis is performed here, and refer the reader to [9].We present the resulting analysis in Table 1 below. The left-hand side of this table describes ends, whereas the right-hand side describes means. Each entity is given a unique ID according to its type, of vision, mission, goal, strategy, objective, and tactic, as V, M, G, S, O, and T respectively, and a number. We include an additional entity, assumption, labeled A. An assumption is an i*belief entity (represented as an ellipse shape) used to explain assumptions about other entities when necessary. For each entity, we identify other entities to which it “links”, including both goal contribution, and task composition relationships. Describing these relationships helps determine the position of the entity in the ultimate goal model. Please note that we follow the more rigorous semantic rules governing contribution relationships according to the BRG-Model, discussed in section 3.2, rather than the looser rules of standard i*. Once the contribution relationships are understood, it is simple to map entities from the VMOST analysis in Table 1 to the goal model on the left-hand side of Figure 4, as Table 1 effectively provides instructions for constructing the goal model. Section 5.3 below explores the goal model and its relationship to the context diagrams in progression in Figure 4.5.3Exploring Requirements and ContextWe now describe a part of the SEJ e-business system from business strategy to system requirements via an exploration of the integrated goal model and Jackson context diagrams in Figure 4. We represent the goal model using i* [4], refraining from using contextual entities as discussed in Section 4. The goal model on the left hand side of Figure 4 represents intentional properties of the system, or the requirement [8]. Jackson context diagrams on the right-hand side of Figure 4 describe domain context to which the requirement refers. Note that the entities in the goal model are grouped byTable 1. VMOST Analysis for Seven Eleven Japandashed-line ellipses, RA, RB, RC, etc. The goal entities within the ellipses represent requirements referring to context diagrams in the progression at equivalent levels of abstraction, domain contexts DA, DB, DC, etc. The integration of the goal model and the context diagram at each level in the progression presents a problem diagram for that particular level of abstraction.5.3.1Requirements Set RA and Domain DAThe macro-level business model and strategy is the top-level problem, described by RA and DA. It is here that we bound the RE problem, because it is here that SEJ bounds the problem. SEJ’s vision is to (V1) Be the dominant convenience retailer in a geographic area supplying consumers' everyday needs with great effectiveness based on precise knowledge of customers and their purchase patterns. The mission to (M1) Provide franchise stores with the ability to stock their stores with exactly what their consumers want, when they want it achieves V1.The core strategic goals supporting SEJ’s vision are Enable franchise stores to (G1) reduce lost opportunity/customer, (G2) minimize unsold perishables, (G3) maximize use of limited floor space, (G4) shorten inventory turns, (G5) maintain constant freshness of perishable goods, and (G6) reduce scrap rates. The goals in RA constrain the SEJ System and the Franchise Store in DA, indicated by a dashed line with an arrowhead. Constrain means that the “machine must ensure that the state or behavior of that domain satisfies the requirement” [8]. Interface a describes shared phenomena between the SEJ System and the Franchise Store that specifies how the strategy is implemented, not described in Figure 4. A shared phenomenon is an event or activity shared by two or more participating domains of interest [8], discussed in Section 4. 5.3.2Requirements Set RB and Domain DBIn RB, SEJ has a strategic goal to (G7) Enable franchise stores to stock products that customers want when they want them according to changing needs. G7 contributes to G1-6 in RA. G7 is made operational by strategy (S1) Supply stores with the right product at the right time. S1 also supports M1 in RA. S1 is further decomposed into sub-strategies (S2) Continuously forecast store sales item-by-item, hour-by-hour, and (S3) Support just-in-time delivery for franchise stores. S2 is further supported by (S4) Use predictive model to forecast customer demand with great precision. S3 is further supported by (S5) Coordinate supply chain participants via data network linking them. Strategic goal (G8) Support effective stock order decision-making for each franchise store contributes to G7. G8 is supported by two sub goals, (G9) Aid in identifying sales trends per product by store down to an hourly basis for each store and (G10) Develop a detailed, fine-grained, predictive model of consumer behavior store-by-store, product-by-product, hour-by-hour.Context diagram DB shows five domains, the machine domain SEJ Computer, the Franchise Store,Supplier, Logistics Provider and the Customer. The first four domains are constrained to meet the requirements in RB. The Customer domain however is not constrained, but rather referenced[8] by the requirements, indicated by a dashed line without an arrowhead. This is because a customer has free will and cannot be constrained by software. However, a customer purchases products, and it is customer purchase patterns that are vital to SEJ’s demand planning analysis and supply chain management strategy. Please note that customers are critical to understanding SEJ’s IT requirements problem despiteFigure 4. SEJ Integrated Goal Model and Context Diagramhaving no direct interaction with any machine device in the system. Hence the customer is considered within the scope of our approach.We now describe the shared phenomena of DB. The Franchise Store collects customer profile data and associated purchase data, interface c, which is periodically remitted to SEJ System for analysis, interface b. SEJ’s data analysis yields information on what stock stores need, by when, to meet customer demand. The SEJ System advises Suppliers of how much of what to produce by when, interface d, and arranges shipping with the Logistics Provider, interface g. The Logistics Provider collects goods from the supplier, interface e, and delivers them to the Franchise Store, interface f, according to instructions from the SEJ System, interface g. The SEJ System retrieves the sales and customer data it needs from Franchise Store, interface b.5.3.3Requirements Set RC and Domain DCIn RC, tactical objective (O2) Collect data constantly on customer age and gender and their associated purchases for each store continuously supports G10 in RB. Tactic (T5) POS records customer and related sales data, and remits to store computer supports O2. Note that O2also supports G9 in RB via a correlation relationship indicated in Table 1 and by a dashed line in Figure 4. A correlation refers to a contribution that is not expressly intended [4]. G9is further supported by (G11) Enable shop clerks to display and analyze real-time sales data. RC constrains the domains of interest in DC, decomposed from the Franchise Store of DB. The Franchise Store Computer is a machine domain in DC, and has a critical interface to the SEJ Computer, interface h. DC also shows two devices used inside the Franchise Store, the Graphic-Order-Terminal (GOT)and the Point-of-Sales Register (POS), connected to the Franchise Store Computer, via interfaces i and j respectively. The GOT is a device used to produce visual reports of sales performance data described in G11. The POS is the checkout register that the clerk not only uses to ring up sales but also enter data on customer profiles described in O2 and T5.5.3.4Requirements Set RD and Domain DD Because of space limitations, we do not discuss RD1-DD1. We continue by exploring RD2-DD2. The focus of RD2-DD2 is on the Point of Sales (POS).Tactics (T6) Clerk profiles customer, and (T10) POS collects and delivers purchase pattern data to store computer support T5 in RC. T6 is supported by three subtasks for the Clerk to (T7) assess customer age and gender by sight, (T8) record customer age, and(T9) record customer gender.The tactic (T6) Clerk profiles customer is decomposed into three sub-tactics, T7-9. The clerk is expected to look at the customer and make an assessment whether the customer is male or female, and a rough approximation of age. The POS prompts the Clerk to select the appropriate range for the Customer’s age, followed by selecting gender, prior to concluding the payment transaction. Note that the Clerk domain in RD2 has a letter “B” in the lower-right corner. This indicates that the Customer domain is “biddable,” meaning that we can only bid the clerk to behave according to the requirements, but not necessarily force him to do so. SEJ tries to enforce that the clerk enter the customer data via tactical objective (O3) Require clerks to profile customers to complete transaction. The POS cash drawer will not open and sales cannot complete until the Clerk has entered customer profile information. However, this does not constrain the Clerk, because even if the clerk does enter the data, the clerk may still get lazy or sloppy and enter bogus age and/or gender data either intentionally or inadvertently. After entering the Customer profile into the POS, and the Clerk then processes payment, interface q. T10 is supported by two subtasks (T11) Clerk registers product sales at POS, and (T12) POS register bundle product, sales, and customer profile data and transmit to store computer. Note that assumption (A1) All products must be identified by UPC refers to T10. We assume that clerks checkout products by scanning UPC barcodes or by keying them into the POS when bar scans fail. Referring to context DD2, the Clerk uses the POS, interface q, to process Customer transactions. The Customer takes his Products, interface n, to the Clerk for purchase, interfaces o and p, and then pays for them, interface n. The Clerk scans the Product information via the barcode, interface p.In the case of POS register described above, we understand the requirement (T6) Clerk profiles customer not just in terms of the functionality of the POS register device described by requirements T7-9, but also in terms of the importance of this requirement to the achievement of SEJ’s overall business strategy by tracing the contribution relationships up through RC, RB, and RA. Indeed, if the system fails to meet requirement T6in RD, the system will also fail to meet (O2) Collect data constantly on customer age and gender and their purchases for each store continuously in RC, subsequently fail to meet (G7) Enable franchise stores to stock products that their customers want when they want them according to changing needs in RB, and ultimately fail to meet the strategic requirements in RA. Failing to meet requirements in RA would spell disaster for SEJ, as this would mean failure in its business. The integrated model of system requirements and business strategy in Figure 4 thus enables validation of lower level requirements against the higher-level requirements of business strategy, and helps ensure strategic alignment of organizational IT.6.DISCUSSION AND CONCLUSIONAt the RD-DD level described in Section 5.3.4, we have decomposed requirements down to a low-level, equivalent to the starting point of many requirements engineering problem examples appearing in [8], and indeed like many throughout RE research literature. It is here that we stop, because to continue would simply be to describe a standard requirements engineering exercise. For an example of how one might continue, we refer to the reader to [28].In the SEJ case study, we present the unification of SEJ’s strategy model with a model of its system requirements. We demonstrate how this unified model helps ensure that requirements are in harmony with and provide support for the business strategy. Requirements are aligned top-down from the highest level of business model context, and can be validated against business strategy via upwardly traceable links in the goal model. While we use i* for goal modeling, we depart from standard i* by applying the semantic rules of the BRG-Model, which provide a greater degree of rigor and guidance in constructing goal models of business strategy. We further depart from standard i* by using only goal and task entities in the goal model, refraining from using contextual entities, instead representing these as domains of interest in Jackson context diagrams referenced by the goal model. This separation of concerns helps reduce goal model clutter normally inherent in i*. We use VMOST analysis to deconstruct business strategy as a prelude to goal modeling.。