Define System Scope

Since system size is a measure of the magnitude of all components of a system that are within the current scope, the system scope should be documented in the project plan before the system size is estimated.  The scope statement defines what the project will and will not include, in enough detail to clearly communicate to all participants.

The scope must be a complete definition encompassing all types of requirements:

The external business requirements are generally the most obvious requirements and for which the definition of scope is the easiest.

The system design may imply requirements that are not specified.  For example, the design of a client/server system may have the need for a fire wall between data moving in and out of the environment.  This may add the need for user exits or other components integrated with the data propagation software.

Other components are often implied but not clearly defined, such as, performance, interfaces, operations and implementation.  These components should be included if they are within the scope of the system being sized.  If there is any question regarding whether something is included, it should be assumed to be within the scope of the sizing (refer to Document Assumptions) until the system scope specifically excludes it.

Clarify System Boundaries

In addition to the scope, it is important that the system boundaries are clearly understood before the system size is estimated.  The boundaries identify where the system to be sized starts and ends.  The sizing should include everything for which  the team is responsible.  Items or areas that will be excluded should be clearly stated.

There are two primary reasons to exclude something from the sizing:

The component is another team's responsibility.  For example, a business to business system may provide a standard format for suppliers to interface with their systems.  The interface components that provide the standard interface would be in scope, but the supplier interfaces may be excluded.

The component is assumed to be already implemented.  For example, if the system will use standard reusable components, such as standard date routines or file access routines that will not be modified, then these may be excluded from the scope while the new interfaces to these routines may be in scope.