Why has it been necessary to write so many different, book-length treatises about requirements management on software projects?¹ Is it not possible to develop an approach to handling software requirements that is simple enough to express concisely -- and yet can work with large, complex projects as well as smaller efforts?

At the risk of using a word that disturbs many in the field of software engineering, requirements management is just a process. The more simply this process can be described, the more likely it will be to work in real software organizations. So rather than consider every possible nuance relating to managing software requirements, this article will attempt to express the essence of an approach that can work well on virtually any Agile software development project.² In the appendix, I include a detailed example illustrating the key ideas.

Reduce your backlog size

Most software projects have requirements backlogs that are too big -- often by an order of magnitude. A good rule of thumb is to cut the size of your current backlog to contain no more requirements than could be completed in two releases. How do you know how many requirements can be completed in a release? Just look back at the last release or two and estimate how many requirements were completed! What if your software has not yet been released? There's no better time to prune a backlog of requirements than prior to the first release.

The obvious advantages of a small requirements backlog are myriad. Primarily, a small requirements backlog greatly enhances your responsiveness to customers. It's not hard to understand why. If your backlog is very large right now, do a simple value stream mapping³ to determine how long it would take to complete a requirement from the time it is received from a customer to the time it is reflected in your software (or even the time it takes to understand whether or not it will ever appear in your software). Huge waste is usually evident.

Likewise, if your backlog is very large, how much time is spent (i.e., wasted) managing that backlog? How do you know what is really important in your backlog? A small but meaningful backlog mitigates such issues, and is an essential starting point to any requirements process.

Write requirements effectively

The chief critique against writing requirements simply and succinctly (e.g., as user stories⁴) is that they will lack sufficient richness and detail to be fully understood by the developers, testers, and others who will have to work with them to produce high-quality software. As a consequence, some have advocated more documentation in the form of use cases or other mechanisms to ensure that the requirement is well-understood.

If the development organization represents all requirements as user stories, though, you can potentially avoid additional documentation and overhead. This is why I advocate employing user stories. Further documentation is not necessary: a better way to ensure that requirements are well-understood is through frequent interactions with end users and other stakeholders through substantive demonstrations at the end of each iteration (or sprint). This gives the development organization the opportunity to gain and maintain a first-hand understanding of how the software will be employed.

Estimating the size of requirements

Some teams estimate the size of all of the items in their backlog prior to any development. This, combined with backlogs that are too big, is wasteful. Why do the work of estimation on a requirement that may never be built? Instead, estimate the size of requirements only. On some, and hopefully many projects, this will mean you need only estimate the size of those requirements you plan to build into the next iteration.⁵

For other projects, you may need to estimate the size of requirements that you plan to build over several iterations, or which you can commit to the overall product release ab initio. Consider the following example shown in Figure 1.⁶

Figure 1: Essential and candidate themes in requirements

In planning for a release, it may be wise to decide upfront that particular requirements will certainly be addressed in the upcoming release (essential themes).⁷ In this example, these requirements would be addressed in the first three iterations. This means that the rest of your organization -- sales, marketing, executives, whomever -- can talk about some critical themes that will definitely be addressed in the next release. It is important to note that even for the first three iterations, feedback received during iteration demos may change how these themes actually appear in the completed release.

This approach maintains your organization's flexibility to learn during the development process. As demonstrations of working software take place at the end of each iteration, decisions can be made about which candidate themes would be viewed as most valuable in later iterations.

Back to top

Consider all stakeholder types

It's wrong to think simplistically about the people who pay for the software we produce. When gathering requirements, it's urgently necessary to think of these people as not simply "end users" or even "customers," but from the various vantage points they represent. A four-fold stakeholder categorization is one way to bring these various viewpoints to life:⁸

• Principals are those people who will make the determination to pay for our software to achieve specific business goals, or who are perhaps key influencers in this purchase decision.
• End users are of course the people who will use our software to do a part, or even all, of their job.
• Partners are people who will use our software to help others meet their business goals; e.g., business partners who install, maintain, or deploy our software for a customer. Another example might be a particular customer's IT shop: they perhaps didn't buy our software or don't use it, but they have to get it running so that end users can.
• Insiders are the people we work with in our own organizations who have views about what should be in our software. This could be sales, marketing, executives, corporate, other developers; anyone we work with who has an opinion about what our product should do or how it should be built.

The importance of this kind of categorization may not be immediately evident. This is because too often, we who develop software fail to take into consideration perspectives beyond those of end users or insiders. If a principal is buying your software with a specific purpose in mind (like, "My sales contact told me we could redeploy 20% of our staff if we installed this software."), the software had better be able to deliver on this objective -- perhaps making it more important than the needs of the end user in subsequent sales decisions. Similarly, if your partners are having a tremendously difficult time deploying your software -- even if it is better than a competitor's -- they may recommend competitive software in the future so that they can make a profit. As such, requirements must be considered from this four-fold vantage point, or in some similar manner.

Create a stakeholder goals document

There is one key artifact -- a stakeholder goals document -- that can be developed to keep track of requirements for our Agile software projects. Using the categories just considered, a stakeholder goals document should reflect the business goals of each of the four types of stakeholders described. A simple table of contents for the stakeholder goal document might look like this:

• Project overview -- An overview of what this particular release of software is intended to include, expressed in business rather than technical language.
• Project non-goals -- Key requirements that will definitely not be a part of this release. This helps mitigate the problem of unbounded expectations for a given software release.
• Principal goal satisfiers -- Requirements, stated as user stories, which will meet the business goals of the people who buy or fund our software.⁹
• End user satisfiers -- Requirements, stated as user stories, which will help end users do their work.
• Partner satisfiers -- Requirements, stated as user stories, which will help partners succeed with this release of our software.
• Insider satisfiers -- Requirements, stated as user stories, which will help the people we work with benefit from this release of our software.

A good rule of thumb is to suggest that this stakeholder goals document be no longer than five pages in length. A sample stakeholder goals document is included below.

How to use a stakeholder goals document

The best time to create a stakeholder goals document is at the beginning of a release. But if that's not possible, the best time is "as soon as reasonably possible." As one possibility, in a team using a Scrum Agile approach, a product owner would be an ideal owner for the creation of this document. But fundamentally, regardless of who creates it, the document must reflect the requirements of various stakeholders concerning what they want to see in the forthcoming release, stated in business terms.

Once the stakeholder goals document is created, here's how to apply it to the requirements process. At the end of the first iteration of development, there will be a demonstration and a reflection (or retrospective). In the demonstration, it will be wise to ask questions about what should be in future releases of your software, and why.¹⁰

During the iteration reflection at the end of the first iteration, then, the stakeholder goals document should be consulted and updated. Which goal satisfiers were addressed for principals, end users, partners, and insiders? Which goal satisfiers were uncovered in the iteration demo? In this way, the stakeholder goals document becomes a living part of the team's development process, and goals are continually referred to from a business rather than a technical perspective. Each iteration, the document should be similarly updated. It would be appropriate to completely overhaul the stakeholder goals document at the beginning of the next release.

Back to top

Summary

The following key ideas will allow teams to manage requirements for their software project:

• Maintain a backlog of the appropriate size, perhaps requirements that could be completed in no more than two releases.
• Write requirements as user stories.
• Estimate the size of requirements only when absolutely necessary.
• Differentiate between the various stakeholders who will be interested in your software.
• Document the business goals that will satisfy your stakeholders.
• Update stakeholder goal satisfiers by frequent iteration demonstrations and reflections at the end of each iteration.

You may have many questions, and probably can point out many aspects of this approach where additional information would be helpful. Perhaps this warrants a full book after all. But in the meantime, you surely can get started implementing your own interpretation of these ideas in your requirements and development efforts. Let me know how this works for you in practice.

Back to top

Appendix: Example of a stakeholder goals document for Global Cooling 3.0

Project overview

Global Cooling is a software product that can be sold to:

• Scientific research organizations
• State, local, and national governmental agencies
• Private environmental concerns
• Industries with substantial investments in infrastructure thought to have connections to global warming (e.g. petrochemical and utilities)

Global Cooling Release 3.0 will allow for the aggregation of data from the currently disparate formats within which station monitoring is now conducted using Global Cooling 2.0, and for its reporting and presentation in ways that are actionable. This will require the software product to be tuned for performance to handle high volumes of data, the ability to project possible areas of impact in concert with key climate data (along with the probability of impact), and an open data schema to heighten the possibility of sharing information between governmental and commercial organizations.

In both the United States and Europe, substantial legislation is being drafted that necessitates the production of minimal sets of data by commercial entities that are currently required to perform station monitoring. Japan and India are examples of other countries that are reportedly considering such legislation. At this early juncture, it appears as if the formats that have been proposed in the United States (GC111C) and in Europe (ITIL enhancement FGB12) will be similar in terms of the content that will be required from station monitors, but different enough to put a strain on enterprises that operate in multiple geographies. Global Cooling 3.0 will need to be flexible enough to provide for not only coordination of data in conjunction with these two emerging standards, but also others that may subsequently be brought forth.

Many of the station monitors that are now in place are located in isolated stations where technical support is rarely feasible. As a result, Global Cooling 3.0 will need to be able to accept inbound data in accordance with the current range of station protocols and transmit requests for additional data employing these same protocols.

Project non-goals

While these may be extremely valuable, Global Cooling 3.0:

• Will not include the capacity to incorporate geo-cataclysm readings from sources such as volcanoes, earthquakes, or tsunamis available from some advanced station monitors
• Will not be compatible with the obsolete station monitoring protocols from either the Massachusetts Institute of Technology (MIT) or the University of California at Berkeley
• Will not factor ice loss/gain data in arctic regions into global cooling reports
• Will not attain full feature parity with our prior product Weather Watcher 7.2 or the competitive product CoolWatch 2000

Principal stakeholders

General Situation: There are two primary categories of principal stakeholders that will need to be considered for Global Cooling 3.0. First, governmental agencies will represent the more prominent of the two, as in the United States and Europe more than 60% of station monitoring is performed by these agencies. The key challenge for these clients is the technical level of their in-house IT staffs, given the wide range of software they are called on to manage. As a consequence, the ease with which the application can be deployed and maintained, and data aggregated, will be a primary point of concern. For many governmental agencies, TCP/IP v6 and accessibility requirements (such as US Section 508) are non-negotiables.

Second, direct stakeholders in commercial organizations will be concerned primarily with understanding how to project where difficulties are likely to arise among their physical assets. For example, unanticipated melting ice patterns in the northern reaches of Alaska has caused Metroil Industries to modify their strategy for accessing remote pipelines. If they had been able to project the possible impact of this change, their CEO Roger Pemsky estimated that Metroil would have saved over $85M US.

Goal satisfiers: Principals

Partner stakeholders

General Situation: A wide range of station monitoring specialists and consultants now employ a variety of different tools when called into engagements with governmental and commercial clients. They represent a group well-positioned to influence purchase decisions with their clients for a product like Global Cooling 3.0, and will likely also see the potential value of more comprehensive risk management solutions that might be considered in conjunction with other software we produce such as our Obsolescence Monitoring product and our suite of logistics tooling.

These specialists and consultants are most likely to be enthusiastic adopters of Global Cooling 3.0 only if their ramp-up costs (especially in training and deployment) are minimized.

Goal satisfiers: Partners

End-user stakeholders

General background: Prior releases of Global Cooling have brought about significant usability concerns. While station monitoring, tracking, and reporting has always implied a technically complex set of work tasks, the software has done little to mask this complexity.

In addition, issues have been raised by operators of Global Cooling 2.0 relating to the number of steps required to reboot remote stations, and the time and risk in these activities. When a remote station hangs, it has often resulted in a callout situation for users; and, since there has not been a Web interface provided, this has usually meant that these operators have needed to drive into their offices in order to access the application.

Finally, the recent Global Cooling User Community meeting raised a prioritized list of issues seen by not only operators, but also system administrators, managers, and field users. While there are some specific issues that this group raised in a prioritized manner, more importantly, there was a general request to reduce to overall number of keystrokes and clicks required to drive the application.

Goal satisfiers: End users

Insider sstakeholders

General Background: At present, there are two potentially competing perspectives within our organization as to how a product like Global Cooling 3.0 might fit within our larger software portfolio.

Our internal sales and marketing organization is intrigued with the possibility of enhancing our Obsolescence Monitoring product in favor of developing Global Cooling 3.0. While the decision has been made to fully fund Global Cooling 3.0, the key interest of the sales and marketing teams in their recommendation is worth noting -- Obsolescence Monitoring represents 45% of our current revenues; and, as a result, to the degree that Global Cooling 3.0 can be well-integrated with it, we will heighten the possibility of maintaining and expanding our existing client base.

Second, the CTO's office believes that Global Cooling 3.0 should be the first step toward employing the new architectural paradigm that will serve as the basis for our software engineering efforts over the next five years. Ideally, if Global Cooling 3.0 can interact with Obsolescence Monitoring and our logistics tooling, while being built-out employing our new architectural paradigm, the CTO's strategic direction will more likely be realized.

Goal satisfiers: Insiders

Back to top

Notes

1. Karl Wiegers, for example, has written two. See Karl Wiegers, Software Requirements, 2^nd ed. (Redmond, WA, Microsoft, 2003), and Karl Wiegers, More About Software Requirements (Redmond, WA, Microsoft, 2006). A few other representative examples include Stephen Withall, Software Requirements Patterns (Redmond, WA, Microsoft, 2007); Ellen Gottesdiener, Requirements by Collaboration (Boston, Addison-Wesley, 2002); Suzanne Robertson and James Robertson, Mastering the Requirements Process (Upper Saddle River, NJ, Addison-Wesley, 2006); Dean Leffingwell and Don Widrig, Managing Software Requirements (Boston, Addison-Wesley, 2003).
2. Regardless of what the issue is, almost any concept is harder to apply on very large projects. Still, consider the ideas covered in this article as a framework for "getting from requirements to something useful," as Bittner and Spence put it in Use Case Modeling (Boston, Addison Wesley, 2003).
3. Value stream mapping as it relates to software engineering is discussed in Mary Poppendieck and Tom Poppendieck, Lean Software Development (Upper Saddle River, NJ, Addison-Wesley, 2003); Mary Poppendieck and Tom Poppendieck, Implementing Lean Software Development (Upper Saddle River, NJ, Addison-Wesley, 2007); and Peter Middleton and James Sutton, Lean Software Strategies (New York, Productivity, 2005).
4. The preeminent resource on user stories is Mike Cohn, User Stories Applied (Boston, Addison-Wesley, 2004). Note particularly Mike's discussion of "pics" where large or complex requirements are in view.
5. Planning poker is an excellent way to estimate the size of user stories. See Mike Cohn, Agile Estimating and Planning (Upper Saddle River, NJ, Prentice-Hall www.planningpoker.com.
6. This example is adapted from one provided by Mike Cohn in Agile Estimating and Planning.
7. A theme can be thought of as a related set of requirements, perhaps similar to an epic, but clearly distinct from line items. It could be large; for example, encompassing more than one epic. A theme is meaningful primarily from a stakeholder, rather than from a developer, perspective. Don't be surprised if, in addition to training your own development organization to think in business terms rather than purely technical terms, you have to also train many of your stakeholders to do so! We've spent so many years accepting their ideas in only technical terms, some of this may come as a shock.
8. These categories are articulated in detail in Carl Kessler and John Sweitzer, Outside-in Software Development (Upper Saddle River, NJ, IBM Press/Pearson, 2008).
9. As can be seen in the sample stakeholder goals document below, goal satisfiers do not map as neatly to user stories as this suggests. The stakeholder goals document has one fundamental purpose: to express what various stakeholders need in business terms as opposed to technical terms. While user stories share this same orientation, the difference you might observe in the sample stakeholder goals document is that some of the goal satisfiers are better thought of as epics (collections of user stories), while some could map directly to user stories. While it is important to decompose any epics to user stories in the execution of a particular iteration, in practice, a stakeholder goals document need not necessarily decompose epics in this way. For clarity on user stories and epics, see Mike Cohn's User Stories Applied.
10. An excellent approach to how to track this feedback over time can be found at http://tynerblain.com/blog/2007/10/25/stakeholder-value-matrix/. A number of other entries on the Tyner Blain blog provide valuable additional context and perspective.
11. Note that stakeholder goals can be either as granular as user stories or as large as epics, and will be decomposed appropriately in the planning meeting that begins each iteration.
12. Note that this is essentially the same goal satisfier as the fifth listed for end users. This captures not only the fact that there are various interested stakeholders, but potentially, different aspects of the problem to consider.

Resources

• A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
  
  
• Global Rational User Group Community
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Reduce your backlog size
• Consider all stakeholder types
• Summary
• Appendix: Example of a stakeholder goals document for Global Cooling 3.0
• Notes
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers