A Crucial Lesson about Requirements
Accelerating User Productivity
Suppose a Salesforce product management team goes to a customer to discuss how to improve user productivity. Several users give the product team feedback on the features they like and don’t like in Salesforce.
A sales manager asks if there’s any way to make notes entry easier for representatives using their mobile devices. The reps write minimal notes because they don’t want to spend time typing them out on their phones. Some users express skepticism about the sales manager’s request.
A Salesforce product manager says they’re looking for that kind of feedback - how to make users productive beyond fixing and tweaking features. She then presents the obligatory Salesforce “Forward-Looking Statements” document and asks if the reps would enter more notes by dictating them via voice-to-text on their phones. The idea sounds great to everyone in the meeting if the voice recognition has enough accuracy.
The users and managers in the meeting realize they could do more with Salesforce by thinking beyond its current features. They discuss how they use Salesforce products rather than features, giving them context for higher-level ideas. The meeting shifts from features to usage and business needs, providing the Salesforce product team feedback to make their products more valuable for the customer.
Think Outside of the Feature Box
The story above exemplifies Dr. Karl Wiegers most important software development lesson from his 50-year career:
A usage-centric approach to requirements and design will meet customer needs better than a feature-centric approach.
Over the last half-century, Dr. Wiegers, a software development expert and author, has discovered that focusing on a solution’s features rather than its usage renders an incomplete and fragmented picture of what the organization needs from the solution. He emphasizes that users think about what they need to accomplish with a solution, not the features they will use.
Dr. Wiegers also points out, “A feature-centric approach also can lead to implementing functionality that goes unused, even if it seemed like a good idea at the time.” For example, users request a feature just in case they need it, then the “case” never happens.
Asking users about their step-by-step workflow renders a clearer picture of their needs. It focuses on what the users do instead of how the solution works, resulting in requirements that better cover the organization’s needs.
Use Cases vs. User Stories
Dr. Wiegers favors use cases for a usage-centric approach because they:
Focus on the user
Organize process flows, including exceptions and alternate paths
Enable prioritization based on the use cases’ business impact
Orient user experience design towards actual workflow
He prefers use cases to user stories based on his experience with disorganized, sometimes conflicting user stories that included implementation details. However, well-organized user stories can provide the use case benefits listed above by specifying what users do with a solution, not how they do it. Ideally, user stories would organize around a process map so stakeholders can visualize the workflows.
The Most Important Lesson
In the article The Most Important Lesson about Software Development from the Past 50 Years, Dr. Weigers explains how the usage-centric approach gets requirements right by better meeting customer needs.
Orienting requirements around usage also supports lesson number 1 from Dr. Wiegers book Software Development Pearls: Lessons from Fifty Years of Software Experience:
If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.
Getting the requirements right usually presents daunting challenges, especially with stakeholders oriented toward solution features rather than what they need to accomplish. The more stakeholders focus on the value of their workflow, the better the requirements will reflect their needs.
Organizing a solution’s requirements around its usage rather than features better fulfills the organization’s needs.
Timeless Pearls of Requirements Wisdom covers five essential requirements lessons from Karl Wiegers’ book Software Development Pearls: Lessons from Fifty Years of Software Experience, including the lesson featured in this article.