The Strategy oriented Alignment in Requirements Engineering (SOARE) approach
Introduction
Process description
Example
Further reading
Introduction
“Requirements engineering is the branch of software engineering concerned with the real-world goals for functions of and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior and to their evolution over time and across software families” (Zave, 1997). This definition first highlights the importance of “real-world goals” that motivate the development of a software system. These represent the ‘why’ as well as the ‘what’ of a system. The second part refers to “precise specifications”. These provide the basis for analyzing requirements, validating that they are indeed what stakeholders want, defining what designers have to build, and verifying that they have done so correctly upon delivery. Finally, the definition refers to specifications about “evolution over time and across software families”, emphasizing the reality of a changing world and the need to reuse partial specifications, as engineers often do in other branches of engineering (Nuseibeh and Easterbrook, 2000). In requirements engineering the most approaches in e-business focus on “precise specifications” and tend to treat “real world goals” as peripheral issue. For the harmony of the e-business system this is a bottleneck on the strategy that is intended to support (Bleistein, Aurum et al., 2004). The SOARE approach is developed to align requirements with the business strategies that the e-business systems have to support.
Background
In the paper of Bleistein et al.( Bleistein, Aurum et al., 2004) they describing their point of view on requirements engineering with an approach that fits the best in their opinion. Bleistein experienced that neither of them accent on the understanding of the alignment between the business strategy and requirements engineering for an e-business system that intended to support this strategy. Due to this experience the SOARE approach is developed on the basis of the following points that encountered in their research.
Strategic Alignment
Research has shown that strategic alignment between business and IT have proven
that this has a positive impact on the business performance (Chan et al, 1997).
The aim in the SOARE approach is to incorporate explicit understanding of the
business strategy in requirements engineering activities as a means to ensure
alignment between requirements for e-business systems and the business strategies
that has to be supported.
Requirements Engineering and e-Business Systems
Goal Modelling, Business Objectives and Strategy
The aim of the SOARE approach is to represent business strategy in a requirements
engineering context. The SOARE approach achieve this by using Goal-oriented
Requirements Language (GRL) notation (Liu and Yu, 2001; University of Toronto,
2003).
Pattern Based Approaches for e-Business Systems
These approaches focus primarily on architectural design, usability, and software
solutions. While these approaches give general guidance on problem analysis,
the objective of the patterns they propose tend to be “precise software specification,”
rather than identifying recurring “real-world goals,” such as objectives of
business strategy (Bleistein, Aurum et al., 2004).
Origins
As mentioned in the chapter before most requirements engineering approaches for e-business systems focus on “precise specifications” and aspects of software design rather than the strategies that supports the e-business systems. The SOARE approach for e-business systems aligns the requirements with the business strategies these systems are intended to support. The SOARE approach developed via review and analysis of literature in requirements engineering, strategic alignment, models for e-business, and business strategy. The SOARE approach developed by Bleistein et al. (2004) as a suggestion for linking strategic business objectives to requirements in early-stage development of complex systems. Strategy oriented requirements engineering approach has to include the following (Bleistein, Aurum et al., 2004):
1. Identification of business objectives within strategic scope.
2. Traceable linkages between high-level strategic objectives and low-level
system requirements.
3. Inclusion of explicit statements of business strategy.
Process description
In this chapter, the process deliverable diagram is described. A process deliverable diagram consists of two parts. On the left side the activities are describes and which steps have to be taken to get the deliverables or also called the concepts on the right side. In figure 1 the PDD of the SOARE approach is shown. First of all you need to identify the different objectives that derived from business and business model by business plans, annual reports, and published executive interview, as well as stakeholder interviews with executives. This process also contains identifying the flows of money, product, and information from business model.When this process is finished the next step includes a decomposition of the business model into modular atomic e-business models. These modular models describing the business. Then you need to identify the unique strategy for competitive advantage from the overall understanding of the business strategy. With this information it is possible to design two goal models. One model is the goal model for best practice. Because requirements for best practice are recurring it is only necessary to develop the related goal model pattern once. In the future, it may be reused. The second model is the goal model for competitive advantage. Defining the business strategy should yield major strategic objectives. These can be represented as goals in the goal model. It is necessary to decompose the strategic objectives into tactical objectives, or sub goals that support the strategic objectives.
After developing the model of best practice and the model of strategy for competitive advantage they must be integrated from two models into one combined goal model.
When this is done it is possible to refine the integrated goal model down to system requirements. This last step consists of analyzing the functional and non-functional requirements from the goal model.
The approach crosses three stages. Each stage contains its own (sub) activities. Each of those activities is described in the table below.
Activity table
| Activity | Sub activity | Description |
| Identify business objectives | Identify objectives | Different OBJECTIVES derived from BUSINESS MODEL by business plans, annual reports, and published executive interview, as well as stakeholder interviews with executives. |
| Identify flows | Identify the FLOWS of money, product, and information from BUSINESS MODEL | |
| Link strategic objectives and system requirements | Decomposition business model | Decomposition into modular ATOMIC e-business MODELS. These modular models describe recurring patterns of BEST PRACTICE. |
| Identify strategy for competitive advantage | Identify the unique STRATEGY FOR COMPETITIVE ADVANTAGE from the overall understanding of the BUSINESS STRATEGY. | |
| Develop model for best practice | Develop the GOAL MODEL OF BEST PRACTICE. Because REQUIREMENTS for best practice are recurring. It is only necessary to develop the related goal model pattern once. In the future, it may be reused. | |
| Develop goal model for competitive advantage | Defining the business strategy should yield major STRAGTEGIC OBJECTIVES. These can be represented as GOALS in the GOAL MODEL. It is necessary to decompose the STRATEGIC OBJECTIVES into tactical objectives, or sub goals that support the strategic objectives. | |
| Identify requirements | Create goal model | The model of BEST PRACTICE and the model of STRATEGY FOR COMPETITIVE ADVANTAGE ought to mutually support and reinforce each other. In integrating the two models, the requirements engineer may encounter inconsistencies in the models derived. It may be necessary to re-iterate activities to resolve these. |
| Analyze system requirements | Through analysis, it is possible to refine the integrated GOAL MODEL down to SYSTEM REQUIREMENTS. By analyzing the functional and non-functional requirements. |
Table 1. Activity table with description of activities from PDD.
As already said in the description of the process, the activities result in a deliverable or a concept. The concepts are connected to other concepts in the PDD by associations, aggregations and generalizations. Also the multiplicity of the connected concepts has been addressed. In table 2 the concepts are clarified by a definition.
Concept table
| Concept | Description |
| BUSINESS MODEL | A business model is a description of the value a company offers to one or several segments of customers and the architecture of the firm and its network of partners for creating, marketing and delivering this value and relationship capital, in order to generate profitable and sustainable revenue streams (Osterwalder, 2002). |
| ATOMIC MODEL | The models are “atomic” because they represent basic business models that are modular, meaning that the atomic models can be assembled in different combinations to provide complete coverage for modeling e-business initiatives of all scopes and complexities (Weill and Vitale, 2001). |
| GOAL MODEL | A representation of the strategic objectives of a business ought to contain models of both best practice and strategy for competitive advantage (Bleistein, Aurum et al., 2004) |
| COMPETITIVE ADVANTAGE GOAL MODEL | Strategy for competitive advantage concerns what a company does differently
from its rivals in processes, use of resources, and use of technology in
order to provide advantage for itself over its rivals. Strategy for competitive
advantage ought to be unique, and non-recurring among rival firms (Porter,
|
| BEST PRACTICE GOAL MODEL | Performing activities and using technology according to known best practices. Best practice is about how companies do, or should do, things in the same best way (Porter, 1996). |
| REQUIREMENT | Requirements engineering is concerned with the real-world goals for functions of and constraints on software systems, as well as the relationship of these factors to precise specifications of software behavior (Zave, 1997). |
Table 2. Table of concepts
Example
In this section an example of the SOARE approach is given. Bleistein using the SEJ (Seven eleven Japan) case study for validating the SOARE approach (Bleistein, Cox et al., 2004). This paper describing a short summary of the seven steps that are taken in the SOARE approach and which deliverables are used within the approach.
Activity 1: Understanding the business strategy.
The SEJ case study is about a national franchise of independently owned convenience stores. SEJ is positioned in the middle of the value network that includes suppliers, franchise shops and with the objective to maximize the products sold to end customers. This information is needed for activity 2.
SEJ’s strategy leverages IT to accomplish its strategic objectives, and gain advantage over its competitors. SEJ’s IT system enables franchisees to predict customer purchasing behavior, store-by-store, item-by-item, hour-by-hour, effectively enabling management of a supply chain of business partners to stock stores just-in-time according to changing customer demand. This information is used for activity 4.
Activity 2: Decomposition of the business model.
In this activity the business model is decomposed into atomic models. This atomic model containing description of the business of SEJ that are mentioned in activity 1.
Activity 3: Develop goal model for best practice.
From the atomic model there are a number of critical success factors, core competencies and required IT infrastructure. These recurring requirements are used to model a goal model for best practice.
The main strategy as mentioned in activity 1 is maximizing sales. This is done by strategic business objectives. Detailed objectives are described in the real case study (Bleistein, Cox et al, 2004).
Activity 5: Develop goal model for competitive advantage.
Based on understanding the business strategy in Activity 1 and identify the strategic business objectives for competitive advantage in activity 4 it is possible to develop a goal model for competitive advantage.
Activity 6: Create goal model.
After developing the best practice goal model and the goal model for competitive advantage the goal models have to be integrated in each other. The contribution links show how the goal models reinforce each other. Activity 7: Analyze system requirements.
The goal model with the integrated goal model for best practice and goal model for competitive advantage showing the lower-level entities that representing the lower-level requirements that are upwardly traceable to higher-level business objectives. The higher-level strategic objectives are refined down to lower level requirements. In this way, the goal model ensures that lower-level requirements provide support for and are in harmony with strategic objectives of the higher level SEJ’s business.
Further reading
[Bleistein, Aurum et al., 2004]
Bleistein, S.J., Aurum, A., Cox, K., Ray, P. (2004). Strategy-oriented alignment in requirements engineering: linking business strategy to requirements of e-business systems using the SOARE approach. Journal of Research and Practice in Information Technology, 36(4), 259–276.
[Bleistein, Cox et al, 2004]
Bleistein, S.J., Cox, K. and Verner, J(2004). Modeling Business Strategy
in E-Business Systems Requirements Engineering. Springer Berlin /
Heidelberg, 617-628.
[Bleistein et al., 2005]
Bleistein, S.J., Cox, K., Verner, J., Phalp, K.T. (2005). Requirements
engineering for e-business advantage. Requirements Engineering,
- (1), 4-16.
[Bleistein et al., 2006]
Bleistein, S.J., Cox, K., Verner, J., Phalp, K.T. (2006). B-SCP: A
requirements analysis framework for validating strategic alignment of
organizational IT based on strategy, context, and process. Information
and software technology, 48 (9), 846-868.
[Chan et al., 1997]
Chan, Y., Huff, S., Barclay, D. and Copeland, D. (1997). Business
strategic orientation: Information systems strategic orientation and
strategic alignment. Information Systems Research, 8: 125–150.
[Lui and Yu, 2001]
Liu, L. and Yu, E. (2001). From requirements to architectural design –
Using goals and scenarios. ICSE-2001 (STRAW 2001). Toronto, Canada.
[Nuseibeh and Easterbook, 2000]
Nuseibeh, B. and Easterbook, S. M. (2000). Requirements engineering: a
roadmap. Proceedings of the International Conference on Software
Engineering (ICSE 2000). Limerick, Ireland, ACM Press.
[Osterwalder, 2002]
Osterwalder, A., Pigneur, Y. (2002). An e-Business Model Ontology for
Modeling e-Business. Bled Electronic Commerce Conference, Bled, June
- -19, 2002.
[Porter, 1996]
Porter, M. (1996). What is strategy? Harvard Business Review, 74: 61–78.
[Sondhi., 1999]
Sondhi, R. (1999) Total Strategy, Airworthy Publications International
Ltd.
[University of Toronto, 2003]
University of Toronto (2003). Goal-oriented Requirements language.
Retrieved April 12, 2007, from http://www.cs.toronto.edu/km/GRL
[Weerd, Brinkkemper et al, 2006]
Weerd, I. van de, Brinkkemper, S., Nieuwenhuis, R., Versendaal, J.,
Bijlsma, L. (2006). On the Creation of a Reference Framework for Software
Product Management: Validation and Tool Support. Proceedings of the 1st
International Workshop on Product Management, Minneapolis/St. Paul,
Minnesota, USA, 3-12.
[Weerd, Versendaal et al., 2006]
Weerd, I. van de, Versendaal, J., Brinkkemper, S. (2006). A product
software knowledge infrastructure for situational capability maturation:
Vision and case studies in product management. Proceedings of the Twelfth
Working Conference on Requirements Engineering: Foundation for Software
Quality (REFSQ'06), Luxembourg, 97-112.
[Weill and Vitale, 2001]
Weill, P. and Vitale, M. (2001). Place to Space: Moving to eBusiness
Models, Boston, Harvard Business School. Publishing Corporation.
[Zave, 1997]
Zave, P. (1997). Classification efforts in requirements engineering. ACM
Computing Surveys.
|
|