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.
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 DomainMost 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.
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
Moving Toward the Solution DomainFortunately, 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 SystemFirst, 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.
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
Software Requirements
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. |