One of the first things you'll need to understand when defining your software product line is the amount of commonality that the products share, and the ways in which they vary – that is, you'll need to define the scope of the (potential) software product line. A scope definition effectively defines the production capability you're trying to achieve. It describes the set of products that you're willing to build – more precisely, the set that you're willing to build the production capability to build – and the set you are not. In other words, it describes the products that are in and the ones that are out.

Setting the scope appropriately is an important first step. If the scope is too broad (includes too many products) then the parts they have in common will either have to be hopelessly generic or only used in a tiny fraction of the products. If the scope is too narrow then the software product line may not meet its full potential and never recoup the cost of setting up the production capability.

The scope definition is not a static thing; indeed, it grows, becomes refined, and evolves as the software product line matures. The description can (and should) start out fairly vague: In a software product line of office support systems, for example, systems with room schedulers and appointment calendars are in, whereas systems with flight simulators and medical imagers are out. By refining the descriptions of what's in, you can come up with a fairly comprehensive list of products, or features that the products might have in various combinations.

It's also not necessary that the scope definition be ultimately precise. I think of healthy scope definitions as a “doughnut” in the conceptual space of all possible products. The hole of the doughnut represents systems that are “in,” systems that your production capability is tuned to be able to produce. The space outside the doughnut represents the multitude of systems in the universal product space that you are not willing to build. The doughnut itself represents the set of systems that you might be willing to build if the circumstances were right. For example, you might not have any better business opportunities at the time. Or, the system might represent a future area of growth, and you would like to “drive” your product line into that area.