About us Process Success stories Innovations Contacts

Welcome, Dear Visitor

Process > Scope Management

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 IEEE 830-1998 'Recommended Practices for Software Requirements Specifications'.

The SRS includes a Glossary, Use Cases, 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.

Last update on Apr 15, 2014 by

Site Map Legal Notes Privacy Policy

© TechnoPark Corp., 2000-2014, rev.local, 0.34sec