Process One: Define Scope | Requirements Analysis: From Business Views to Architecture


Team-Fly

	Requirements Analysis: From Business Views to Architecture By David C. Hay
	Table of Contents

	Chapter 2. Managing Projects

Process One: Define Scope

The scope of the strategy study should have been the whole enterprise, with definitions also of the scope of each project ("Replace the general ledger system", "Create an e-business", etc.). The definition of that scope, however, may be further refined at the beginning of the requirements analysis project. What is needed now, then, before the requirements analysis process can begin in earnest, is to specify that scope in terms of the Information Architecture's columns :

Data : What things of significance define the scope of the project?
Activities : What activities are to be included in the project?
Organizations : Who will be involved in the activities?
Locations : Where will the activities be addressed?
Timing : Which events are in scope?
Motivation : Which corporate goals and objectives are being addressed.

The strategy study should have listed the basic things of significance to the businesspeople, organizations, products, and so on. The scope should now be defined in terms of which of those broad categories are to be addressed. The strategy study should also have listed, at least in global terms, the functions of the business. The scope statement for a project should at least be articulated in terms of those functions.

Note that figuring out which entity types and functions are included in the project is not as important as defining which are not included. It's better to argue this out now, rather than have some people assuming that things will be part of the project that others believe will not be. This way, if later someone tries to assert that something should be in the scope of the project, it can be pointed out that it was specifically excluded. If you can make a case for including it now, recognize that it will cost the project something.

Be careful to constrain the scope to something that can be done well by relatively few people. If the scope is larger than that, divide it into smaller projects such that each can still be done by a small group . In doing that, however, be sure that the overall architecture is addressed first. Perhaps a data model must be done for a relatively large part of the business, but the detailed analysis will address only portions of it.

There are no rules for drawing these boundaries. You have to rely on experience and common sense.

This process produces a detailed statement of the project's scope.


Team-Fly

Top