I first learned to program computers in college in 1970. Since then, I’ve performed many roles in software engineering: coder, designer, business analyst (BA), tester, project manager, documentation writer, team manager, process improvement leader, consultant, trainer, and author. Plus, of course, like all of us, I’m a user.
People sometimes ask me, “What’s the most important lesson you’ve learned about software development in all that time?” Here it is, lesson #4 of the 60 lessons in my book Software Development Pearls:
A usage-centric approach to requirements and design will meet customer needs better than a feature-centric approach.
Let me describe why I believe this is such an important principle.
The Feature-Centric Problem
There are several problems with taking a feature- or product-centric approach to requirements elicitation. Asking users questions like “What do you want?” or “What do you want the system to do?” open the door for a flood of random information that’s hard to turn into a satisfactory solution. Focusing on features can lead the team to implement functionality that doesn’t let users do all the things they need to do.
One of my consulting clients held a day-long workshop with about sixty participants to collect ideas for a big new commercial product. They stapled together the output from their six subgroups and called it a requirements specification. But it wasn’t. It was a mishmash of functionality fragments, features, user tasks, data items, business rules, constraints, and quality attributes, all stirred together with no structure or organization. Mixed in with that stew was a lot of extraneous information. Simply asking people to brainstorm what they wanted to see in the new product didn’t produce actionable requirements knowledge.
A feature-centric approach also can lead to implementing functionality that goes unused, even if it seemed like a good idea at the time. Depending on the source you read, 50 to 80 percent of software features are rarely or never used , thereby providing little business value (The Standish Group 2014). I’ve encountered this problem myself. One of my internal corporate customers asked my team to add a new feature to an application his group used. He stressed how necessary the feature was, so we dutifully built in the capability. To the best of our knowledge, though, no one ever used that feature. I would have been skeptical about that customer’s next enhancement request.
Focusing requirements explorations on features contributes to this proliferation of dormant functionality. Soliciting an open-ended list of desired functions from customers simply invites feature bloat. So, how can we avoid those traps?
Putting Usage First
I recommend that BAs shift requirements conversations away from the product itself and toward what users need to do with the product. We change the emphasis from functionality to usage, from the solution to the need. A usage-centric strategy helps the BA and the development team quickly understand the user’s context and objectives. From that knowledge, the BA can better identify what capabilities and characteristics a solution must have, for whom, why, and when.
Usage-centric exploration involves a small, but significant, shift in the questions a BA might ask during elicitation. Rather than asking, “What do you want?” or “What do you want the solution to do?” the BA asks, “What do you need to do with the solution?” The resultant conversation identifies tasks or goals the users need to accomplish with the help of the solution.
Users don’t launch an app to use a particular feature; they launch an app to accomplish an objective. Each time I open my business accounting software, I have some goal in mind. Maybe I want to create an invoice, record a received client payment, reconcile my credit card, or pay a bill. Each such goal is a use case—literally, a case of usage. I open the app and follow a sequence of steps that invokes the functionality needed to accomplish the task. If all goes well, I achieve my objective successfully and close the app: mission accomplished.
I have found use cases to be an effective requirements elicitation tool for several reasons.
User Focus. Use cases are a natural way for users to think about their needs. It’s hard for users to articulate just the right set of functionality for a product, but it’s easy for them to talk about usage scenarios from their daily lives.
Organization. Use cases provide a structured way to organize descriptions of related functionality. A use case template has slots in which you can record information to provide as rich—or as slender—a use case description as your team finds valuable (Wiegers and Beatty 2013). The related functionality includes a description of the most typical or default interaction sequence for the task (the normal flow) and any variations on that typical sequence (alternative flows). The BA will then deduce the functionality the solution must provide so that users can perform those tasks. A proper use case description also identifies error conditions that could arise and defines how the system should handle them (exception flows).
Prioritization. The highest-priority functional requirements are those that enable the highest-priority user tasks. Some use cases will be more frequently used, used by more people. and timelier than others; implement those first. Within a single use case, the normal flow takes top priority, along with its accompanying exceptions. The alternative flows will have lower priorities and often can be implemented later, or perhaps never.
User Experience (UX) Design. Taking the user’s perspective leads to better UX designs. It can provide insights about the limitations of a proposed implementation that you might not get from a product- or feature-centric mindset. An effective UX design facilitates the user’s task flow.
What about User Stories?
Many agile project teams employ user stories as a requirements elicitation and documentation technique. But even a common definition of user story has a product-centric focus: “A user story describes functionality that will be valuable to either a user or purchaser of the system or software” (Cohn 2004). User stories also lack an intrinsic organizational scheme.
One large project collected several thousand user stories from many stakeholders. Some of the stories were incomprehensible; many conflicted with others. Some looked like probable duplicates, and still others were tantalizingly suggestive but incomplete. The project had a big pile of unorganized information of many different kinds, all labeled as user stories. It was hard to tell from the pile which bits of functionality related to user tasks and which stories were just thoughts that people had contributed.
Some of these stories were usage centric; others were not. The stories spanned a wide range of detail, size, and importance. They ranged from “As a user, I want the screen font to be sans-serif so that I can easily read it” to “As a payroll supervisor, I want the system to calculate state unemployment taxes for every state where we have employees so that we can pay the unemployment taxes correctly.” Stories like these don’t address users and their usage, but rather the system’s features and properties.
Amassing a set of isolated functionality fragments requires someone to aggregate them from the bottom up to recognize themes related to user tasks. It’s rather like assembling a jigsaw puzzle by picking up one piece at a time and saying, “I wonder where this piece goes.” I prefer to begin with broad strokes, like identifying user tasks, and then progressively refine and elaborate them into their details. I’m less likely to miss something significant that way, and it’s less work than assembling the whole puzzle one isolated piece at a time.
The Winner: Usage-Centric
Both feature- and usage-centric approaches lead to identifying functional requirements that developers must implement. However, focusing on usage helps ensure that we include all the functionality users need to perform their tasks, while avoiding building excess functionality. The usage-centric perspective enhances usability because developers can thoughtfully integrate each bit of functionality into a task flow or a user objective (Constantine and Lockwood 1999).
I began taking a usage-centric approach to requirements development in 1994. I quickly discovered how focused and efficient it was compared to my previous approach. Even if you take a lean approach, rather than fully populating a rich use case template, usage-centered thinking will lead to solutions that do a superior job of meeting customer needs.
References
- Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
- Constantine, Larry L., and Lucy A.D. Lockwood. 1999. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Reading, MA: Addison-Wesley.
- The Standish Group. 2014. “Exceeding Value.” The Standish Group International, Inc. https://www.standishgroup.com/sample_research_files/Exceeding%20Value_Layout.pdf.
- Wiegers, Karl, and Joy Beatty. 2013. Software Requirements, 3rd Ed. Redmond, WA: Microsoft Press.
Author: Karl Wiegers
Karl Wiegers is Principal Consultant with Process Impact. This article is adapted from his recent book Software Development Pearls. Karl is the author of numerous other books, including Software Requirements Essentials (with Candase Hokanson), The Thoughtless Design of Everyday Things, and Software Requirements, 3rd Edition (with Joy Beatty).