0740-7459/07/$31.00 © 2007 IEEE
Published by the IEEE Computer Society
Guest Editor's Introduction: Stakeholders in Requirements Engineering
To build a useful system, we need to know its requirements; to know its requirements, we need to know the stakeholders' desires and needs. The term stakeholder
generalizes the traditional notion of customer
in requirements engineering to all parties involved in a system's requirements (see the sidebar " What Is a Stakeholder?
"). The growing attention being paid to stakeholders' needs and desires reflects the growing importance of requirements engineering (RE) in software and systems development.
"Understanding the Stakeholders' Desires and Needs" was also the theme of the 14th IEEE International Requirements Engineering Conference. 1
From the RE '06 conference and its theme, the idea for this special issue emerged. We invited authors of RE '06 papers that specifically dealt with stakeholder issues to submit a practice-oriented view of their work. After a round of IEEE Software
peer review, we chose two of these submissions for this issue. We also solicited contributions in a public call for papers and chose two of these submissions after review. In addition, the issue contains a technical opinion piece on stakeholders in global RE and a Point-Counterpoint debate.
Identifying the stakeholders
Stakeholder identification precedes any other RE activity: we must first determine who they are and how important they are.
Suppose we want to elicit and document a software system's requirements. To identify the relevant stakeholder roles, we look for persons or organizations who
• have an active interest in the system because they'll actually use it or are directly involved in processes that the system will change;
• must manage, introduce, operate, or maintain the system after its deployment;
• are involved in developing the system as an architect, developer, tester, quality engineer, or project manager;
• are responsible for the business or process that the system supports or automates;
• have a financial interest (for example, they've ordered the system, paid for it, or are responsible for its sale);
• constrain the system as regulators; or
• are negatively affected by the system (so-called negative stakeholders).
Not all stakeholders are equally important, so we must prioritize the identified stakeholder roles—for example, into critical, major, and minor. We typically base prioritization on assessing the risk we incur by ignoring or neglecting a stakeholder:
• If neglect might kill the project or render the system useless, the stakeholder's role is critical.
• If neglect would have a significant negative impact on the system, the stakeholder has a major role.
• If neglect would have marginal impact on the system, the stakeholder's role is minor.
Finally, we must select representative individuals or groups from the identified and prioritized stakeholder roles with whom we can elicit and validate system requirements.
"Stakeholders in Global Requirements Engineering: Lessons Learned from Practice," by Daniela Damian, highlights the problem of dealing with stakeholders in globally distributed settings, which is increasingly the case with the rise of global software engineering. She identifies the challenges that go beyond what traditional projects face and recommends ways to cope. Her article also points to RE '07, whose theme will be "Understanding Requirements in the Global Economy." The conference will take place in October in Delhi, India.
To support active stakeholder participation in the RE process, we need a platform for stakeholder communication. Wikis are a well-known lightweight concept for supporting collaboration among distributed persons. Björn Decker, Eric Ras, Jörg Rech, Pascal Jaubert, and Marco Rieth explore the use of wikis for stakeholder collaboration in "Wiki-Based Stakeholder Participation in Requirements Engineering." They see wikis as a more powerful method than email and office tools but less expensive and easier to use than full-fledged collaboration or requirements management tools.
A software project isn't only a chance for stakeholders to get what they need or desire. Some stakeholders might also be negatively affected. Hence, a good RE process must manage the risks arising from negative project perceptions of or impacts to stakeholders. In "Stakeholder Risk Assessment: An Outcome-Based Approach," Richard W. Woolridge, Denise J. McManus, and Joanne E. Hale present an outcome-based model for assessing stakeholder risks that identifies deficits between expected and desired stakeholder impact and perceptions. These deficits are a valuable source for identifying requirements risks and corresponding mitigation plans.
Because stakeholders are situated in their working environment, eliciting their needs directly at work would be advantageous instead of doing so in the sterile atmosphere of a meeting room. In "Determining Stakeholder Needs in the Workplace: How Mobile Technologies Can Help," the authors Neil Maiden, Norbert Seyff, Paul Grünbacher, Omo Otojare, and Karl Mitteregger discuss eliciting and validating requirements using mobile requirements tools for PDAs. They report results from studies and present lessons learned.
When describing requirements, stakeholders often have different interpretations of the terms they use to describe their problem domain; this phenomenon is called terminological interference. Nan Niu and Steve Easter-brook deal with this problem in "So You Think You Know Others' Goals? A Repertory Grid Study." They present a technique to detect terminological interference in the ways that stakeholders express nonfunctional requirements, using Kelly's Repertory Grid Technique to analyze and compare stakeholders' beliefs. They demonstrate their technique in a pilot study for a nonprofit organization.
In the Point-Counterpoint discussion, Ian Alexander and Kent Beck argue whether developers must give stakeholders what they desire. Yes, satisfying stakeholders' desires is crucial for product success. No, this leads to gold-plating and lets developers run away from their responsibility for the product. Read the Point-Counterpoint discussion for more pros and cons.
We hope the ideas and experiences described here will help you deal with stakeholder issues in your own projects more effectively and successfully. The texts in the " Further Reading
" sidebar might also be useful. We also hope this special issue will stimulate further research and technology transfer on the topic of stakeholder management in RE.
is a full professor of informatics at the University of Zurich. He chairs the steering committee of the IEEE International Requirements Engineering Conference and was program chair of RE '06. His interests include requirements and software engineering, in particular modeling and validation, and software engineering education. He received his Dr. rer. nat. from RWTH Aachen University. Contact him at the Dept. of Informatics, Univ. of Zurich, Binzmühlestrasse 14, 8050 Zurich, Switzerland; email@example.com.
Roel J. Wieringa
is a full professor of information systems at the University of Twente. His research interests include value-based requirements engineering and business-IT alignment. He received his PhD in computer science from the Free University Amsterdam. He also served as a program chair and steering committee chair of the IEEE International RE Conference. Contact him at the Dept. of Computer Science, Faculty of Electrical Eng., Mathematics and Computer Science, Univ. of Twente, PO Box 217, 7500 AE Enschede, Netherlands; firstname.lastname@example.org.