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 on the solution. We were focused fully on the problem domain.
In Team Skill 2, we described a set of techniques the team can use to understand user needs. These user needs live at the top of our requirements pyramid, representing the most critical information we must understand and driving everything that follows.
In Team Skill 3, we move from the problem space to the solution space, and we focus on defining the system that we can build to address our stakeholders' needs. As we move lower in the pyramid (see Figure 1), the amount of information increases. For example, a significant number of system features may be required to fulfill a single user need. 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, 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 need 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.
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 ahead before moving into the software requirements section of the pyramid, in Team Skill 5, Refining the System Definition. For now, we'll cover organizing requirements information (Chapter 16), defining a vision (Chapter 17), and organizing our team to address the challenge of managing the requirements for the system (Chapter 18).