, University of Zurich
, University of Twente
Pages: pp. 18-20
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 or user 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.
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
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:
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.
In everyday life, a stakeholder is a person or group that has an interest or share in a business or enterprise (originally, it meant the holder of the bets in a game). In RE, the term appeared in the '90s when it became apparent that the then-used terms "client," "customer," and "user" were too specific. The 1990 IEEE Standard Glossary of Software Engineering Terminology had not yet listed it. 1 The first definition we're aware of appeared in 1993 in a paper by Linda Macaulay. 2 Based on Ian Mitroff's work, 3 Macaulay defined stakeholders as "all those who have a stake in the change being considered, those who stand to gain from it, and those who stand to lose." Today, we define the term as follows:
A stakeholder is a person or organization who influences a system's requirements or who is impacted by that system.
Frequently, roles are used instead of individuals. Typical stakeholder roles in an average software project are, for example, end user, project sponsor or client, architect, developer, tester, quality engineer, project manager, product manager, operator, and maintainer.
Meanwhile, the term stakeholder is also used in other fields for a person or organization that has an interest in the outcome of, or is impacted by, a project, service, or decision.ReferencesIEEE Std. 610.12-1990, Standard Glossary of Software Engineering Terminology,IEEE Press,1990.L.Macaulay"Requirements Capture as a Cooperative Activity,"Proc. 1st IEEE Int'l Symp. Requirements Eng.,IEEE CS Press,1993,pp. 174–181.I.I.MitroffStakeholders of the Organizational Mind,Jossey-Bass,1983.