In Team Skill 1, we developed the skills that focus the team on analyzing the problem. In so doing, we came to fully understand the problem being solved before we invested any serious effort in the solution. We were focused fully on the problem domain.
| The amount of information we must manage increases rapidly as we move lower on the pyramid. |
In Team Skill 2, we described a set of techniques the team can use to understand user needs and features proposed for the system. These user needs and features live at the top of our requirements pyramid, representing the most critical information we must understand and driving everything that follows . In so doing, we made a subtle shift in our thinking: we moved from the problem domain to the solution domain as we started to focus on understanding a set of features we can deploy to address our stakeholders' needs (Figure 1).
Figure 1. Features in the requirements pyramid
In Team Skill 3, we'll continue to focus on the features we identified earlier. We must also start to provide additional specificity to further define system behavior; thus, the amount of information we must manage increases.
In addition, the team must now also be concerned with a variety of other issues that are unique to the solution space but that were of little concern in the problem domain. For example, if we are developing a software product for sale to the user, we must concern ourselves with packaging, installation, and licensing considerations, each of which may be unique to the solution we are providing. If we are developing a system to address an in-house IS/IT need, we may have to concern ourselves with the requirements for deployment and maintenance, which were of little or no concern to a user not currently using such a system. These considerations may also impose requirements on the system we are about to build, even though they did not arise directly as a stated stakeholder need.
However, we must still remain at a fairly high level of abstraction, for if we sink too far into detail too quickly, we will not be able to "see the forest for the trees." In addition, it's important to pause for a second and to take the time to organize the requirements information before moving into the software requirements section of the pyramid. Thus, we'll describe some basic building blocks in Chapter 14, A Use-Case Primer, and we'll cover organization in Chapter 15, Organizing Requirements Information. We'll explore the importance of creating a shared vision of a project in Chapter 16, The Vision Document. Finally, in Chapter 17, Product Management, we'll describe all the other work necessary to convert the software we've developed into a product or system that someone might actually want to buy or deploy.
![Managing Software Requirements[c] A Use Case Approach](/icons/blank_book.jpg "Managing Software Requirements[c] A Use Case Approach"){kind=icon}