The Road Map

Since we are embarking on a journey to develop quality software ”on time and on budget ”that meets customers' real needs, it may well be helpful to have a map of the territory. This is a difficult challenge in that the variety of people you encounter on this particular journey, and the languages they speak, are quite diverse. Many questions will arise.

• Is this a need or a requirement?

• Is this a nice-to-have or a must-have ?

• Is this a statement of the problem or a statement of the solution?

• Is this a goal of the system or a contractual requirement?

• Do we have to program in Java? Says who?

• Who doesn't like the new system, and where was that person when we visited here before?

In order to navigate successfully through the territory, we'll need to understand where we are at any point in time, whom we are meeting, what language they are speaking, and what information we need from them to complete our journey successfully. Let's start in the "land of the problem."

The Problem Domain

Most successful requirements journeys begin with a trip to the land of the problem. This problem domain is the home of real users and other stakeholders, people whose needs must be addressed in order for us to build the perfect system. This is the home of the people who need the rock or a new sales order entry system or a configuration management system good enough to blow the competition away. In all probability, these people are not like us. Their technical and economic backgrounds are different from ours, they speak in funny acronyms, they go to different parties and drink different beers, they don't wear T-shirts to work, and they have motivations that seem strange and unfathomable. (What, you never liked Star Trek? )

On rare occasions, they are just like us. They are programmers looking for a new tool or system developers who have asked you to develop a portion of the system. In these rare cases, this portion of the journey might be easier, but it might also be more difficult.

Typically, this is not the case, and we are in the land of the alien user . These users have business or technical problems that they need our help to solve.Therefore, it becomes our problem to understand their problems, in their culture and their language, and to build systems that meet their needs. Since this territory can seem a little foggy, we'll represent it as a cloud. This will be a constant reminder to us to make sure we are seeing all the issues in the problem space clearly.

Within the problem domain, we use a set of team skills as our map and compass to understand the problem to be solved . While we are here, we need to gain an understanding of the problem and the needs that must be filled to address this problem.

Stakeholder Needs

It is also our responsibility to understand the needs of users and other stakeholders whose lives will be affected by our solution. As we elicit those needs, we'll stack them in a little pile called stakeholder needs , which we represent as a pyramid.

Moving Toward the Solution Domain

Fortunately, the journey through the problem domain is not necessarily difficult, and the artifacts collected there are not many. However, with even this little bit of data, we will be well provisioned for the part of the journey that we have perhaps been better prepared for: providing a solution to the problem at hand. In this solution space, we focus on defining a solution to the user's problem; this is the realm of computers, programming, operating systems, networks, and processing nodes. Here, we can apply the skills we have learned much more directly.

Features of the System

First, however, it will be helpful to state what we learned in the problem domain and how we intend to resolve those issues via the solution. This is not a very long list and consists of such items as the following.

• "The car will have power windows ."

• "Defect-trending charts will provide a visual means of assessing progress."

• "The program will allow Web-enabled entry of sales orders."

• "An automatic step-and-repeat weld cycle is required."

These are simple descriptions, in the user's language, that we will use as labels to communicate with the user how our system addresses the problem. These labels will become part of our everyday language, and much energy will be spent in defining them, debating them, and prioritizing them. We'll call these descriptions features of the system to be built and will define a feature as

a service provided by the system that fulfills one or more stakeholder needs.

Graphically, we'll represent features as a base for the previous needs pyramid.

Software Requirements

Once we have established the feature set and have gained agreement with the customer, we can move on to defining the more specific requirements we will need to impose on the solution. If we build a system that conforms to those requirements, we can be certain that the system we develop will deliver the features we promised . In turn , since the features address one or more stakeholder needs, we will have addressed those needs directly in the solution.

These more specific requirements are the software requirements . We'll represent them as a block within our pyramid in a manner similar to the features. We also note that these appear pretty far down on the pyramid, and this implies, correctly, that we have much work to do before we get to that level of specificity later in the book.