To remain competitive and innovative, organizations today must respond faster than ever to increasingly complex marketplace and customer pressures. Business Agility coupled with Lean practices like DevOps certainly aid in navigating today’s challenges through alignment of an organization’s strategy, people, processes and technologies. However, age-old questions remain irrespective of the chosen development methodology: how do we translate our business objectives into distinct improvements in our technology and products?
How do we know we have tracked that information in appropriate detail and organizational scheme without hampering progress?
The answers lie in your requirements engineering (RE) approach, which includes the following elements: requirements and traceability architecture, the selected RM (requirements management) tool, how changes to those requirements are managed, requirements reviews, statusing and versioning, among others. With an RE approach in place, every product development team must then make decisions regarding three considerations – whether done so explicitly or implicitly. They are:
- Have you elicited every detail that the customer expects for this release/iteration/build/push of the product?
- Are all perspectives of the requirements captured in order to achieve consensus and common understanding?
- Do the requirements contain a sufficient level of quality to proceed with subsequent product development activities?
Knowing the Unknown
Former U.S. Defense Secretary Donald Rumsfeld famously quipped in a 2002 press briefing:
“… As we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don’t know we don’t know… it is the latter category that tend to be the difficult ones.”
Though intended for the intelligence community, this statement has just as much significance for requirements engineering, and indeed for product development in general. A primary objective of business analysis and RE is to close any and all gaps between a product development team (the people actually building the system, such as hardware and software engineers), and the business stakeholders (the people paying for, using, or demanding the system itself). Those gaps inevitably include exploring unknown terrain, even to the customer. While elicitation techniques vary widely, from JAD sessions and job shadowing to system decomposition and prototyping, one useful analytical tool for ensuring we have met customer expectations is the Kano model. In its simplest application, we can leverage the Kano model to consider three types of customer expectations, and the impact of increased investment has on customer satisfaction for those three types of expectations: delighters, satisfiers, and basic expectations (also called “dissatisfiers”).
Courtesy mindtheproduct.com
While newcomers naturally gravitate toward the delighters and satisfiers of the Kano model because we can delight customers with less effort at the margin, it is actually the basic expectations that represent the most risk from a requirements perspective. These “unknown unknowns” typically exemplify subconscious knowledge in the minds of a system’s stakeholders; basic factors therefore won’t be stated explicitly but instead elicited only through carefully-crafted techniques such as field observation and competitor analysis. Examples here include nonfunctional requirements such as safety, security, and privacy concerns. Without investing in both the elicitation and implementation of these system characteristics, we risk a disproportionate drop in customer satisfaction, or worse: product failure or rejection, loss of market share, or even lawsuits. Leveraging the Kano model can help mitigate such risks.
Next up – The Requirements Challenge: Representing all Sides (Part 2 of 3)
Cody May is Principal Business Analyst at SQS USA.
