Scope Is Defined By Specifications

Boundaries of software products are defined by a set of Requirements. The software development team designs, implements, tests, and delivers these Requirements to you. A Requirement is an atomic unit of a software product from the viewpoint of the user. As a rule, Requirements are always correct, unambiguous, verifiable, and traceable. Requirements are numbered and prioritized.

High-level user Requirements are called Features. Up to 10 Features can be defined in any software project, regardless of the project size. Features are defined in the Vision document. The Vision is created before the project commences, and is the basis for the ROM Estimate.

The Vision is developed right after you submit an informal request. Up to 5 hours are spent for developing the Vision by a system analyst, regardless of the project size.

When a ROM Estimate is approved, an Alpha-Specification is created. Upon your approval, the Alpha-Specification becomes a Beta-Specification. When the project begins and the Budget is approved (following a LCO Milestone), the Beta-Specification becomes an effective Specification.

A fully-dressed Specification is called a SRS (Software Requirements Specification) and is compliant with 'Recommended Practices for Software Requirements Specifications'.

The SRS includes a Glossary, , Functional Requirements, and Non-Functional Requirements.

All Functional Requirements are then listed in a requirements attributes spreadsheet, where all necessary attributes for each Requirement are maintained.

Changes to the project scope can be made only by issuing new Specifications through a process called Change Requests. Each Change Request implies that changes will be made to the Budget, Schedule, and Risks.