UndefinedScope

The scope of a system is poorly defined or undefined

Description

The scope of a system is poorly defined or undefined. A system requires vision (see LackOfVision). Based on this vision, there should be a well-defined scope, a boundary for the system giving a clear description of what is in scope and what is not.

Discussion

The problem of changing scope is addressed in FeatureCreep; here we deal with the problem of defining scope. Many of the old problems of defining scope of the system have been solved with use of UseCases to capture how users want to interact with the system; this interaction defines the system boundary for each particular way the system is to be used. Even with the advent of UseCases, there remain problems of scope owing to confusion over the multiple systems that may be addressed in a project (Business, System under development, various subsystems, etc.).

Prevention, Amelioration, Cure

Traditional

Define the scope of the system by defining how a user will interact with the system, as in ScenariosDefineProblem. For the initial planning, prioritisation and rough estimation, it is sufficient to define a goal, a class of user that owns the goal (an Actor) and a brief outline of the functionality. It may be of use to list other human roles or external systems that need to be involved to achieve the goal. For a better definition of the system boundary, the scripts that outline the progress of the various scenarios that may occur when attempting to achieve this goal should be given. These should be from the perspective of the user, and describe how he wants to use the system and what the system should do in response.

Modern

UseCases are still frequently used to define the system boundary and capture use requirements. XP uses a specific variant, the UserStory. This is tailored to list the ImpliedRequirements for purposes of prioritisation and estimation.