Although it is certainly desirable to know exactly how many testable requirements (TRs) there are in a system, practical considerations will usually dictate that the size be estimated. The estimate should include not only the sizing estimate itself, but all the assumptions that underlay the estimate.
Components of an Estimate
Any sizing estimates should include at least four components:
The size estimate:
The actual size estimate.
The assumptions which underlay the estimate. The assumptions are necessary to communicate what is included and not included in the estimate. Errors and misunderstandings are much easier to spot if assumptions are documented.
The requirements decomposition:
The decomposition of requirements that has been accomplished to-date.
The size estimate risk :
The potential that the size estimate could be significantly different from the system being sized. Risk will most often be related to requirements issues which need to be communicated to management.
Process for Estimating System Size Using TRs
Mosaic's standard process for estimating testable requirements is composed of the following steps:
Define system scope and boundaries
-- The scope defines what will and will not included in the project, and encompasses all types of requirements. The boundaries identify where the system to be sized starts and ends.
Identify High Level Requirements (HLRs)
-- High level requirements are the most generalized breakdown of requirements of the system. This level corresponds to major system functions or business processes. These functions are usually known and so this is generally not an estimate, but a known quantity. The list of HLRs are used to create the initial requirements inventory, which becomes the foundation for the overall testable requirements estimate.
Identify/Estimate Intermediate Level Requirements (ILRs)
-- In the actual inventorying process, each of the HLRs are then broken down into intermediate level requirements (ILRs), which often correspond to screens, reports, transactions, etc. The number of ILRs for each HLR is identified or estimated.
Estimate the number of testable requirements (TRs)
-- The ILRs can be further broken down until, after usually 3 or 4 levels, the requirements are testable. Testable requirements (TRs) are precise, unambiguous and no longer divisible. The number of TRs per each HLR is estimated.
Develop Requirements Sizing Matrix
-- Use of a requirements sizing matrix is recommended to document the size estimate. The estimated number of TRs for each high level requirement is documented along with some of the basis for the estimates.
Document Sizing Assumptions
-- Documenting and publishing assumptions provides an opportunity to highlight problem areas early in the life cycle of the project. Assumptions are factors underlying the estimate.