An Introduction to Use Cases and Quality Function Deployment: Driving Vision Vertically Through the Project
This chapter is from the book
This chapter is from the book
This chapter is from the book
One good thing about small, one-person software development efforts is that the person with the ideas and the product’s vision is the same person that specs out the product and writes the code. There was a time when I fancied that the big problems in software development were the technical problems; problems that involved specs, design, and code. At some point, my opinion on this started to change as I began to notice that the thorny problems folks encounter in projects are quite frequently people problems. Given that few projects are one-person shows anymore, how do you point a group of people in the same direction, help them envision a problem in the same way, and synchronize and coordinate their efforts toward a common vision? That, it finally occurred to me, was the real problem in software development.
One form of this "people problem" that large projects face is how to move product vision and its associated business drivers, hatched at the senior management/marketing level, vertically downward to the project team level so that the product that is built, tested, and released is true to that original vision and business drivers.
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 drivers1, user requirements, and system requirements (i.e., functional and quality/non-functional requirements of the system’s software and hardware).
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. 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 cases—and their equally low-tech cousins, such as storyboards, XP stories, workflows—have 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 cases—as a means of stating a user’s requirements—are 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.