Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question – how do we gather implicit requirements?
Johanna’s Experience
Johanna describes the process of installing updated drivers for an all-in-one scanner/fax/printer. The installation process did not live up to her expectations. It took too long, caused additional inconveniences for her, and when she was done, the user interface was inconsistent with her other applications. In short, her expectations, her implicit requirements, were not satisfied.
How Could This Happen?
When we prioritize the requirements for, and creation of a new product, we focus our effort on the most important elements. We may even exclude everything but the most important requirements. We spend time and money on those things that create the most value for our customers (or at least maximize our sales).
Even with a Kano Analysis driven prioritization approach, we start with must-be requirements, then surprise-and-delight, and eventually more-is-better requirements. We may never get to “implicit requirements.” Even if we have the time to get to them – we may not have identified them.
This could have been avoided, and we don’t need a magic wand to identify implicit requirements.
Interaction Design Will Help
An approach to software development that uses interaction design is much more likely to identify implicit requirements. Like user experience disciplines (UX), interaction design focuses on the users. The interaction design approach starts with identifying the typical users, represented as personas, and documents and prioritizes their personal goals. This user-centric approach would probably identify the personal goals that would guide software designers to prioritize a consistent interface and pain-free installation. This approach is a powerful way to design products that don’t suck.
We could also use an approach that melds interaction design with traditional requirements approaches.
Making Traditional Requirements Work
The biggest challenge in addressing implicit requirements is identifying them. Once we identify them, we can conciously prioritize them. Prioritization is a function of ROI, but ROI requires user adoption (or purchase). Bad user experiences create bad marketing, prevent repeat business, and prevent future sales. This is the mechanism by which we prioritie them, once we identify them.
Eliciting Implicit Requirements
One way to identify these requirements is through observation. By observing users of the product (or a competitor’s product), we can get a perspective on how users interact with the product. This is also known as ethnographic research. We may still miss requirements – the competitor’s product may not push on the pain points that would fail to live up to expectations. Or they may identify pain points in the competitive product that present opportunities for us.
We can combine this observation with the use of prototypes. Prototypes can be used to document requirements, and they can even be used as the first iteration of an incremental delivery. More importantly, they can be used as a tool for gathering requirements.
Prototypes Uncover Overlooked Implicit Requirements
Prototypes simulate the product. Interacting with the prototype simulates interactions with the product. If we’ve done something wrong, or are about to do something wrong, a prototype will help us uncover it. We need to get feedback from the users (or people who match our target personas) about how the prototype meets and fails to meet their expectations. Other requirements gathering techniques can help us define the explicit requirements, and then interacting with the prototype will help us identify the implicit requirements.
Conclusion
Implicit requirements are real. And we have ways to uncover them. We can use interaction design as our approach. Or we can use traditional requirements techniques, and elicit the implicit requirements through prototyping and observation.
We usually create storyboard screens using a tool in Visio (stpBA storyboarding). This approach has saved us a lot of time and rework as we are in a better position to get a clear understanding of the customers requirements (including implicit) at an early stage.
Our customers usually independently review the storyboard screens and provide us useful feedback which was lacking prior to using this approach. However I’m sure that by observing the customers interacting with the storyboards we could also get a far better understanding of the implicit requirements.