Defining the scope of a system involves defining-
- Product scope: “the collection of functional and nonfunctional requirements that will be included in the final system”
- Project scope: the work that is to be completed, personnel involved, and the timelines
The SDLC firmly places “defining the scope” of the project as a successor to the “requirements gathering” stage.
If requirements are gathered after establishing the scope, it leads to “requirements creep”, which must be prevented, as-
- This is a specific type of “scope creep” which indicates flaws and loopholes in the requirements-gathering phase.
Getting the first step wrong gives the project a shaky foundation, and will lead to the development of an unstable product which is prone to errors and security faults - It is impossible to seamlessly integrate new requirements into a project once it is past the scope-defining stage.
It leads to confusion, misinterpretation of priorities, and leads to a project which is not bound by any controls. Security loopholes naturally creep into such software. - Changing the requirements leads to changing the scope.
It a step back in the SDLC and can lead to recursive mini-loops of the SDLC – with no way out, and no end in sight.
The budget for resources and the timelines get completely messed up.
It creates frustration and stress for the personnel involved and is indicative of weak project management and leadership.
A secure and functional software is not an outcome of such an environment.