Requirements: Knowledge and Understanding

[photo by Henkster]

Writing good requirements is more than just about following a set of rules. You can capture knowledge about your goals and your product with a set of well crafted requirements. But to truly write good requirements, you have to gain a level of understanding that surpasses knowledge. Insight springs from understanding, and insight leads to great requirements and ultimately great products.

Knowledge and Understanding

Holly Buchanan recently wrote a thought-provoking article about knowledge and understanding at Future Now. In her article, she tells us the story of how a Toyota engineer “got in the heads” of users by logging tons of hours driving a minivan all over the US. Her article stresses the importance of understanding users when it comes to persona development. And she’s right. It got us to thinking about the importance of knowledge and understanding from a broader perspective as well.

In other words, you can’t just know the facts; you must be able to interpret them.

I believe that in order to go from knowledge to understanding, one must have real-world insight into one’s customers. You have to dig deeper, ask better questions, and yes, put yourself directly into your customers’ shoes.

Holly Buckanan

Holly gets to the crux of things with that quote. Interpretation of knowledge is what leads to insights, and therefore understanding. This is critical to developing the right interactions for your products – but it is also critical to developing the right products.

Knowledge is something you can be taught. You can gather knowledge, someone can pass knowledge on to you. Someone who understands something can even pass along their insights – but when you receive them, they are merely additional knowledge. When you elicit requirements, you are really just collecting knowledge. There are many tips you can apply when interviewing to gather requirements, and you can even focus on making sure you interview the right people. All of this helps you to get the right knowledge, but it is still only knowledge.

Knowledge can also come from lateral thinking processes, like associative thinking.

Understanding, however requires more than just associations. Understanding requires incorporating contextual information into your data, and generalizing and abstracting from the data you have to form concepts, ideas and principles. Neither associations nor gathered data alone can get you to understanding.

Associative Thinking

Apparently, one of the impacts of (or descriptions of) autism is that people afflicted with autism think primarily in terms of associations. This very interesting article by Temple Grandin – a mildly autistic professor, Thinking the Way Animals Do, highlights the inadequacy of associations alone in achieving understanding.

People with autism and animals both think by making visual associations. These associations are like snapshots of events and tend to be very specific. For example, a horse might fear bearded men when it sees one in the barn, but bearded men might be tolerated in the riding arena.

Temple Grandin, PhD

We added a yellow Labrador to our family a couple years ago, and we took Scout to a trainer once a week for several months. As any dog owner will tell you, the trainer was there to teach us, not him. She made a very interesting statement at the time. She told us that dogs are great at making specific associations, but miserably bad at generalizing. Her example was that teaching Scout to sit in the living room when we have food would not help him to know to sit (with the same command) when we’re walking outside at night and he’s on a leash. Scout has no reason to associate the desire to sit with the command “sit” – he has to process many inputs, and makes a compound association, not a general one.

Her advice has proven out to be true over and over again. We taught Scout to not chew on the edge of his dog bed. He didn’t chew on that spot again after we said “No!” But he moved to a new spot 6 inches away and started chewing. We said “No!” again, and he moved again. This lasted for about an hour, as he gradually learned that chewing on any part of his dog bed was unacceptable. He couldn’t generalize that dog bed chewing was bad – he had to build up a list of don’t chew on this part of the dog bed and don’t chew on this part either, until we had the whole bed covered. He doesn’t chew on it at all, now.

With purely associative thinking, Scout didn’t develop an understanding – he only gained knowledge.

Context As a Framework

When we talk about best practices for defining requirements and managing them, we regularly refer back to the notion of structured requirements.

In earlier articles, we’ve pointed out that this technique helps primarily because it helps answer the question “Why?” “Why” becomes the context in which we make decisions. Throughout the software creation team, there are several roles with different perspectives.

Requirements Documents – One Man’s Trash

Different members of the team rely on different levels of decomposition of the problem to make their individual work (the “What”) actionable (the “How”).

We had a client who is facing a multi-national IT initiative, designed to support the sales process globally and regionally. In our role, we have to deliver requirements. To define those requirements, we have to understand our customer’s needs. Our challenge is to gain insights and understanding. If we just interview people and ask “what do you need?” they will give us knowledge, and we’ll capture it.

From that point forward, each person on the team has the opportunity to understand their work in the context of the requirements – but we are at risk, if the knowledge we capture in the requirements is incorrect or inadequate. To reduce the risk of making those mistakes, we have to gain understanding.

One thing I did was review McKinsey’s latest research on how the Indian economy is evolving. Their report proposes a (likely) view of how market forces and individual behaviors have shifted and are likely to shift. Understanding those market dynamics helps us validate or model a proposed growth rate for sales of a particular product in that market. This expectation, combined with an understanding of which sales-models work best in India helps us prioritize Indian requirements relative to those of other regions. This level of understanding helps us impart better knowledge to the rest of the team.

McKinsey’s report describes trends. We can generalize and gain insights into behavior (and likely behavior) from them and apply to the context of our particular analysis. And we can hypothesize and model financial forecasts based on their research – and that data impacts prioritization discussions. Ultimately, we will end up with better requirements, and better products.

A great way to organize this type of “contextual exploration” is through the use of concept maps. Each concept map provides a way for you to relate information that you’ve discovered with decisions you’re making. You create associations. This technique is usually applied to brainstorming, but it is even more powerful when documenting free-form associations of ideas.

Conclusion

Understanding of any topic comes from combining knowledge with context via associative thinking. We gain knowledge empirically. We gain context through organization of information. We apply associative thinking to interrelate that knowledge into a web of (scoped) understanding. Then, by gaining knowledge that is relevant to but not necessarily part of our scope, we can develop associations to what we already know, thereby improving our understanding.

This understanding leads to better decisions, better prioritization, better requirements. And ultimately, better software.