Requirements value chains: stakeholder management and requirements engineering in software ecosystems

(1)

Zurich Open Repository and Archive University of Zurich Main Library Strickhofstrasse 39 CH-8057 Zurich www.zora.uzh.ch Year: 2010

Requirements value chains: stakeholder management and requirements

engineering in software ecosystems

Fricker, S

Abstract: [Context motivation] Market-oriented development involves the collaboration of many stake-holders that do not necessarily directly interact with a given development project but still influence its results. These stakeholders are part of the requirements value chain for the concerned software product. [Question/problem] Understanding the structure and functioning of requirements value chains is essen-tial for effective stakeholder management and requirements engineering within the software product’s ecosystem. [Principal ideas/results] The paper explores and exemplifies fundamental concepts that are needed to characterize and reason about requirements value chains. [Contribution] This characterization is used to describe the relevant knowledge landscape and to suggest research avenues for understanding the principles needed for managing requirements-based stakeholder collaboration.

DOI: https://doi.org/10.1007/978-3-642-14192-8_7

Posted at the Zurich Open Repository and Archive, University of Zurich ZORA URL: https://doi.org/10.5167/uzh-43243

Conference or Workshop Item Accepted Version

Originally published at:

Fricker, S (2010). Requirements value chains: stakeholder management and requirements engineering in software ecosystems. In: REFSQ 2010: 16th International Working Conference on Requirements Engineering: Foundation for Software Quality, Essen, Germany, 30 June 2010 - 2 July 2010, 60-66. DOI: https://doi.org/10.1007/978-3-642-14192-8_7

(2)

University of Zurich

Zurich Open Repository and Archive

Winterthurerstr. 190 CH-8057 Zurich http://www.zora.uzh.ch

Year: 2010

Requirements value chains: stakeholder management and

requirements engineering in software ecosystems

Fricker, S

Fricker, S (2010). Requirements value chains: stakeholder management and requirements engineering in software ecosystems. In: Paech, B; Rolland, C. Requirements Engineering: Foundation for Software Quality. Heidelberg, Germany, 60-66.

Postprint available at: http://www.zora.uzh.ch

Posted at the Zurich Open Repository and Archive, University of Zurich. http://www.zora.uzh.ch

Postprint available at: http://www.zora.uzh.ch

Posted at the Zurich Open Repository and Archive, University of Zurich. http://www.zora.uzh.ch

(3)

Requirements value chains: stakeholder management and

requirements engineering in software ecosystems

Abstract

[Context & motivation] Market-oriented development involves the collaboration of many stakeholders that do not necessarily directly interact with a given development project but still influence its results. These stakeholders are part of the requirements value chain for the concerned software product. [Question/problem] Understanding the structure and functioning of requirements value chains is essential for effective stakeholder management and requirements engineering within the software product's ecosystem. [Principal ideas/results] The paper explores and exemplifies fundamental concepts that are needed to characterize and reason about requirements value chains. [Contribution] This characterization is used to describe the relevant knowledge landscape and to suggest research avenues for understanding the principles needed for managing requirements-based stakeholder collaboration.

(4)

R. Wieringa and A. Persson (Eds.): REFSQ 2010, LNCS 6182, pp. 60–66, 2010. © Springer-Verlag Berlin Heidelberg 2010

Requirements Value Chains: Stakeholder Management

and Requirements Engineering in Software Ecosystems

Samuel Fricker

University of Zurich, Department of Informatics Binzmuehlestrasse 14, 8057 Zurich, Switzerland

[email protected]

Abstract. [Context & motivation] Market-oriented development involves the collaboration of many stakeholders that do not necessarily directly interact with a given development project but still influence its results. These stakeholders are part of the requirements value chain for the concerned software product.

[Question/problem] Understanding the structure and functioning of requiments value chains is essential for effective stakeholder management and re-quirements engineering within the software product’s ecosystem. [Principal

ideas/results] The paper explores and exemplifies fundamental concepts that are needed to characterize and reason about requirements value chains.

[Contribution] This characterization is used to describe the relevant knowledge landscape and to suggest research avenues for understanding the principles needed for managing requirements-based stakeholder collaboration.

Keywords: Requirements value chain; Software ecosystems; Requirements ne-gotiation; Vision.

1 Introduction

Much requirements engineering research has focused on engineering requirements of a system with few easily accessible stakeholders [1]. This model of stakeholder in-volvement is adequate for many bespoke situations, but is too simplistic for market-driven software development [2, 3], where collaboration among stakeholders is a central concern [4]. Here, a possibly large number of anonymous and distributed users of current product versions provide feedback from product use and state new requirements. Developers state requirements that emerge from attempts to balance customer satisfaction and development feasibility. Marketing and management departments define development scope. Other roles pursue further objectives.

Stakeholders and their relationships are a central concern of software ecosystems, where stakeholder collaboration is organized in two value chains [5]. The

require-ments value chain applies to inception, elaboration, and planning of software, starting with business and application ideas and ending with an agreed detailed set of re-quirements for implementation. It is concerned of discovering, communicating, and matching interests of direct and indirect stakeholders with functionality and quality properties of the software to be developed [6]. Stakeholders need to be known and differentiated [7, 8] and conflicting perspectives and goals resolved [9, 10].

(5)

Requirements Value Chains 61

Concluded development of the software allows transiting from the requirements value chain to the supply chain [5]. The supply chain applies to the execution phase in the software lifecycle. It is concerned of the production, distribution, selection, com-position, and operation of the software to make it available to end users [11-13]. Hence, the supply chain is concerned of satisfying the needs discovered and aligned in the requirements value chain by delivering the results from development and providing services based thereon in a profitable and sustainable manner [14].

The requirements value chain is little understood so far beyond project stakeholder management and goal modeling. It is unclear which requirements communication, collaboration, and decision-making principles lead to efficient, value-creating and sustainable alignment of interests between interdependent stakeholders across soft-ware projects and products. Industry cases from large-scale process development [15, 16], inter-company collaboration [17], and global software engineering [18, 19] show that bringing transparency into the requirements value chain is important. Proper stakeholder collaboration leads to accepted products and innovation [20].

This paper uses fundamental concepts from negotiation [21] to explore these facets of requirements value chains. The result provides a basis to reflect on research needed for an improved understanding of value creation and of collaboration, hence for better managing the political and strategic context of requirements engineering [22].

The paper is structured as follows. Section 2 explores requirements value chains from structural and dynamic perspectives and exemplifies. Section 3 discusses emerg-ing research issues. Section 4 summarizes and concludes.

2 Requirements Value Chains

2.1 A Negotiation-Based View of Requirements Value Chains

Negotiation is an inherent part of decision-making between stakeholders [21]. This view emphasizes the social and political aspects of requirements engineering and assumes interest in collaboration and value creation. It has successfully been applied in project requirements engineering [23]. Value-creating negotiations require proposal and exploration of alternatives for matching stakeholders’ interests to find win-win agreements worth more in total than if each party would act on its own.

A win-win negotiation process can be characterized as follows [21]. Two or more

stakeholders get in contact with each other, share their positions in terms of interests and expectations, seek alternatives, and get to an agreement. Negotiations can be about alignment of interests or sharing of scarce resources. Negotiations are

small-scale if they just affect the negotiators, or large-scale if they involve a myriad of players and issues in the so-called secondary, hidden negotiation table.

Social Structure: Stakeholders and Relationships. Social structure relates to stake-holders, someone or a group of individuals who gains or loses something as a result of a software project [7], and their relationships. Stakeholders embody direct or indirect viewpoints towards the software [8]. Direct viewpoints concern software operation and include the product’s user. Indirect viewpoints influence software success indirectly and include development execution, financing, and regulation.

(6)

62 S. Fricker

Orderer-contractor, group membership, and delegation relationships connect stake-holders. Orderer-contractor relationships connect two layers in the requirements value chain with each other [24]. Group membership groups stakeholders with similar inter-ests, same goals, or interdependencies [25]. Delegation relationships point from a principal stakeholder to an agent [21]. Agents are employed when they have more negotiation expertise than the primary stakeholder, deeper domain knowledge, or a network and special influence that enables rapid achievement of effective agreements.

A central stakeholder in the requirements value chain of a software product is the

product manager [3] that coordinates large-scale negotiations by performing require-ments management, roadmapping, and release planning. Concerned company-internal

stakeholders include senior managers that supervise the organization, marketing and sales that interface to customers, development that implements the product, produc-tion that makes the product available to the supply chain, service and support that enable effective use of the product, and controlling that measures product perform-ance. Company-external stakeholders include market intelligence and those of the supply chain: users, customers, channels, suppliers, and competitors.

Information Structure: Interests and Agreements. Interest are objectives pursued by stakeholders [21]. They are often related to the stakeholder’s role in the ecosystem. Company management pursues business goals. Customers profit from benefits generated by the software, and users from functionality, reliability, usability, and efficiency the software. Development is interested in solution design and technology.

An agreement is a settling between stakeholders that results from successful nego-tiation and enables collaboration of the concerned stakeholders. Agreements are a form of conflict resolution. They describe how selected interests of the negotiation partners contribute to each other when specifying interest alignment, and plans for resource use when specifying allocation of scarce resources.

Documents and data stores are used to capture positions and agreements in product management. Positions of users are captured as needs and support cases, of customers as market requirements, of research and development as ideas, and of product man-agement as product vision. Product requirements are used for triage and preparing negotiations with key stakeholders. Resulting agreements are documented with prod-uct strategies, roadmaps, and release plans. Development is contracted with imple-mentation proposals and requirements specifications.

Dynamics: Requirements Value Chain Evolution. Requirements value chains evolve when stakeholders enter or leave the software ecosystem, specialize and become members of groups, and establish relationships. Active integration may involve application for a given role. Passive involvement happens through personal interests, traits and relationships that make the person attractive for being integrated.

People acquire group membership if they pursue the same goals as other group members, if they are interdependent with other members, if they interact with other members, or if they share a set of norms [26]. Group enrolment is active or passive. The constitution of groups influences negotiation tactics and methods [25].

Software product management establishes and maintains a software ecosystem by managing stakeholders and studying and aligning their interests. With requirements triage a product manager decides about relevance of stakeholders and interests.

(7)

Contracting involves the selection of development teams and suppliers. Budgeting and release planning further constrains stakeholder involvement.

2.2 Example of a Requirement Value Chain

Examples of requirements value chains have been published [15, 16, 18, 19, 25], mostly characterized ad-hoc. Figure 1 shows an interpretation of one of them using the notation introduced in [16]. It describes an institutionalized requirements value chain that was developed in a large-scale requirements engineering process develop-ment effort [15]. Process developdevelop-ment defined the social network and requiredevelop-ments engineering artifacts by identifying roles (circles in Figure 1), their responsibilities with respect to the company’s product and technology portfolio, and documentation to capture agreements between the roles (arrows in Figure 1). Process development left open the concrete interests to be pursued and aligned.

Fig. 1. Multi-project development case (abbreviations in[15])

Analysis of the requirements value chain in Figure 1 raises questions regarding ef-ficiency and completeness of the developed process. Software usability, if a concern for the company’s products, requires alignment of user interests with the software team leader’s (SW-TL) intentions over four specifications. The effort needed could be significantly reduced and the quality of the alignment improved by introducing more direct collaboration with selected users. The requirements value chain excludes rela-tionships to production and suppliers, which could connect development to the supply chain and would allow considering requirements that affect product cost, hence a substantial part of the economic success. Company resources, finally are considered mere implementation resources. No link points from product management to devel-opment that would allow gathering innovative ideas [20].

3 Research Issues

Conceptualizing software product stakeholders as a requirements value chain can bring transparency into how the software ecosystem affects product inception. Research in this area can provide the fundaments for reasoning on efficiency and effectiveness of requirements engineering strategy and of innovation.

(8)

64 S. Fricker

Requirements value chain analysis can allow understanding power of given stake-holders, process performance, and ecosystem maturity. Social network theory [27] provides concepts and models for determining stakeholder power and influence and for evaluating structural strengths and weaknesses of the stakeholder network. Group

theory [26] gives insights into group effectiveness and the development of specialized roles. Negotiation theory [21] provides decision-making knowledge.

Stakeholders need to be managed in the software ecosystem to evolve a value chain. Partners need to be identified, relationships established, stakeholder interac-tions monitored, and changes in requirements value chain controlled. Partner

identifi-cation may be addressed by directories or by recommendation systems. Established social networks provide such capabilities, but have not been used for such purposes in requirements engineering yet. Groups, besides negotiation tactic selection [25], can also play a role for partner and peer identification. Group management addresses group lifecycle, performance, and partnering with other groups. Relationships need to

be established to allow partners to start negotiations. Factors like trust and distance affect the quality of such relationships. Value chain management, opposed to passive emergence of a chain, involves proactive value chain composition, structuring, and change to provide value and perspectives to its members and to ensure sustainability of the software ecosystem.

Information spread in the requirements value chain needs to be managed. The choice of interest elicitation, expectation setting, and decision documentation ap-proaches can have effects on the transparency and performance of the value chain.

Computer-supported collaborative work [28], traceability, and audit trails can con-tribute to understanding effective information sharing and management. Social

network technologies may give unprecedented support for requirements engineering. Requirements value chain structure can affect innovation, requirements engineer-ing performance and software success. Negotiations permit local alignment of interest, but may not be effective for global alignment. Distance, feed-forward and feedback affect the overall alignment of stakeholder interests and intentions in the value chain and the motivation of stakeholders to collaborate. A new management role may be needed, responsible for value chain structure and policies, for guiding stakeholder behavior, and for controlling progress and success of interest alignment.

4 Summary and Conclusions

This paper proposed a fresh view on stakeholder involvement in requirements engi-neering. It has introduced and exemplified the concept of requirements value chains where requirements emerge from and propagate with inter-stakeholder collaboration. The resulting view on stakeholder management and requirements engineering, which we recommend to address with negotiation principles, can provide insights for man-aging the political and strategic aspects of requirements engineering beyond the hori-zon of a development project. Characteristic for a vision on our field, a lot of research remains for illuminating our understanding.

(9)

References

1. Cheng, B., Atlee, J.: Research Directions in Requirements Engineering. In: Future of Software Engineering (FOSE 2007). IEEE Computer Society, Los Alamitos (2007) 2. Regnell, B., Brinkkemper, S.: Market-Driven Requirements Engineering for Software

Products. In: Aurum, A., Wohlin, C. (eds.) Engineering and Managing Software Require-ments, pp. 287–308. Springer, Heidelberg (2005)

3. Ebert, C.: Software Product Management. Crosstalk 22, 15–19 (2009)

4. Karlsson, L., Dahlstedt, Å., Regnell, B., Natt Och Dag, J., Persson, A.: Requirements engineering challenges in market-driven software development - An interview study with practitioners. Information and Software Technology 49, 588–604 (2007)

5. Messerschmitt, D., Szyperski, C.: Software Ecosystem: Understanding an Indispensable Technology and Industry. The MIT Press, London (2003)

6. Yu, E.: Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering. In: IEEE Intl. Symp. on Requirements Engineering, Annapolis MD, USA (1997)

7. Alexander, I., Robertson, S.: Understanding Project Sociology by Modeling Stakeholders. IEEE Software 21, 23–27 (2004)

8. Kotonya, G., Sommerville, I.: Requirements Engineering with Viewpoints. Software Engineering Journal 11, 5–18 (1996)

9. van Lamsweerde, A., Darimont, R., Letier, E.: Managing Conflicts in Goal-Driven Requirements Engineering. IEEE Transactions on Software Engineering 24, 908–926 (1998)

10. Easterbrook, S., Nuseibeh, B.: Using ViewPoints for Inconsistency Management. Software Engineering Journal 11, 31–43 (1996)

11. Jansen, S., Brinkkemper, S., Finkelstein, A.: Providing Transparency in the Business of Software: A Modeling Technique for Software Supply Networks. Virtual Enterprises and Collaborative Networks (2007)

12. Lauesen, S.: COTS Tenders and Integration Requirements. Requirements Engineering 11, 111–122 (2006)

13. Rayport, J., Sviokla, J.: Exploiting the Virtual Value Chain. Harvard Business Review 73, 75–85 (1995)

14. Gordijn, J., Yu, E., van der Raadt, B.: e-Service Design Using i* and e3value Modeling. IEEE Software 23, 26–33 (2006)

15. Paech, B., Dörr, J., Koehler, M.: Improving Requirements Engineering Communication in Multiproject Environments. IEEE Software 22, 40–47 (2005)

16. Fricker, S.: Specification and Analysis of Requirements Negotiation Strategy in Software Ecosystems. In: Intl. Workshop on Software Ecosystems, Falls Church, VA, USA (2009) 17. Müller, D., Herbst, J., Hammori, M., Reichert, M.: IT Support for Release Management

Processes in the Automotive Industry. In: Dustdar, S., Fiadeiro, J.L., Sheth, A.P. (eds.) BPM 2006. LNCS, vol. 4102, pp. 368–377. Springer, Heidelberg (2006)

18. Damian, D., Zowghi, D.: RE Challenges in Multi-Site Software Development Organisations. Requirements Engineering 8, 149–160 (2003)

19. Damian, D.: Stakeholders in Global Requirements Engineering: Lessons Learned from Practice. IEEE Software 24, 21–27 (2007)

20. Gorschek, T., Fricker, S., Palm, K., Kunsman, S.: A Lightweight Innovation Process for Software-Intensive Product Development. IEEE Software (2010)

21. Thompson, L.: The Mind and Heart of the Negotiator. Prentice-Hall, Englewood Cliffs (2004)

(10)

66 S. Fricker

22. Bergman, M., King, J.L., Kyytinen, K.: Large-Scale Requirements Analysis Revisited: The Need for Understanding the Political Ecology of Requirements Engineering. Requirements Engineering 7, 152–171 (2002)

23. Grünbacher, P., Seyff, N.: Requirements Negotiation. In: Aurum, A., Wohlin, C. (eds.) Engineering and Managing Software Requirements, pp. 143–162. Springer, Heidelberg (2005)

24. Fricker, S., Gorschek, T., Byman, C., Schmidle, A.: Handshaking with Implementation Proposals: Negotiating Requirements Understanding. IEEE Software 27, 72–80 (2010) 25. Fricker, S., Grünbacher, P.: Negotiation Constellations - Method Selection Framework for

Requirements Negotiation. In: Working Conference on Requirements Engineering: Foun-dation for Software Quality, Montpellier, France (2008)

26. Johnson, D., Johnson, F.: Joining Together: Group Theory and Group Skills. Pearson, London (2009)

27. Wasserman, S., Faust, K.: Social Network Analysis, Cambridge (2009)