The Language Gap

If you've ever been in a room where both upper management/marketing types and technical geeks are present at the same time, you know there is often a language gap. While one is talking about the need to grow revenue for this and that customer segment, the other is saying, "Just tell me what to build!!"

A way to understand this problem is by applying Karl Wiegers' levels of requirements types. In his article, "10 Requirements Traps to Avoid," Karl Wiegers argues that a fair amount of confusion comes about in projects because of the failure to recognize the existence of "several types of requirements, all legitimate and all necessary." To paraphrase, these requirements types are business drivers^[1], user requirements, and system requirements (i.e., functional and quality/non-functional requirements of the system's software and hardware).

^[1] Wiegers (1999) actually uses the term "business requirements," but I've found this term has a different meaning for some people than what I think Wiegers intends: for some it is akin to business rules used in databases (i.e., a business requirement describes some real-world constraint on the business). I now use the term business drivers as a substitute for business requirements as most people clearly connect with this ("What is driving this project?").

Business drivers emanate from the point of view of the developing organization and provide a clear sense of why a project is being undertaken and the value the product will provide. User requirements, on the other hand, reflect the point of view of the user, describing what the user requires in terms of tasks or goals to be accomplished.^[2] Finally, system requirements represent the product from the point of view of the system itself and what is required of its software and hardware to support the user's requirements.

^[2] No distinction will be made here between users and customers, though it is an important distinction of which to be aware. When customer and user are not one and the same, meeting the customer's requirements is a necessary, but not sufficient goal, for unhappy users will likely sour future sales. Gauss and Weinberg (1989) illustrate this point with toy sales: if either the parent (the paying customer) or the child (the user) is dissatisfied, a toy will not succeed in the market place. For a software example of this, in the oil and gas industry, IT departments are often customers for, but typically not users of, products designed for oil and gas exploration. In such cases, there is a win-win situation that must be achieved of meeting the customer's requirements while also meeting the requirements of the user. QFD can be a useful tool for helping identify which of a host of product features or designs best provides a win-win situation for customer and user alike.

This transition in focus from business to user to system is illustrated in Figure 1.1, which shows a simplified form of Wiegers' requirements levels.

Figure 1.1. Wiegers' levels of requirements illustrate the transition in focus in a software project from thinking about the business, to the user, to the system.

Beyond a classification of requirements types, the hierarchy of Figure 1.1 is also a good model for understanding the communication gap that exists vertically in projects. It's not that upper management is wrong when they talk in "biz" speak or that technical geeks are wrong when they just want someone to tell them the component interface to implement. It is just that each is dealing with different requirement types of the project, "all legitimate and all necessary."

Use casesand their equally low-tech cousins, such as storyboards, XP stories, workflowshave helped with this problem by providing a lingua franca for at least the user requirements that are understandable by upper management, marketing types and technical geeks alike. Looking at Figure 1.1, we see that use casesas a means of stating a user's requirementsare in a pivotal position in the hierarchy, serving as a vertical bridge on the transition down from the sometimes lofty and vague business perspective to the sometimes very "down in the weeds" detail of the system perspective. But sometimes more is needed to help manage this transition from business to user to system. That's where Quality Function Deployment (QFD) can come in.