The following example illustrates some of the issues associated with sizing using testable requirements.  Assume that there are no other types of requirements (e.g., performance, operational, etc.)

How Many Testable Requirements Does It Take To Validate a Date?

The Requirements

The date routine must accept a date in ddmmyyyy format and confirm that it is a valid date between the years 1940 and 2500.

Testable Requirements Count:

TR
#
Date
Attribute
Lower
Bound
Upper
Bound
Requirement
Logic
1
month
1
12
must be numeric
2
year
1940
2500
must be numeric
3
day
1
31
If month=1
4
day
1
28
If month=2 and year not divisible by 4
5
day
1
29
If month=2 and year divisible by 400
6
day
1
28
If month=2 and year divisible by 100 but not divisible by 400
7
day
1
29
If month=2 and year divisible by 4 but not divisible by 100 or 400
8
day
1
31
If month=3
9
day
1
30
If month=4
10
day
1
31
If month=5
11
day
1
30
If month=6
12
day
1
31
If month=7
13
day
1
31
If month=8
14
day
1
30
If month=9
15
day
1
31
If month=10
16
day
1
30
If month=11
17
day
1
31
If month=12

Therefore a date in ddmmyyyy format must meet 17 testable requirements.

Other Testable Requirements Associated With The Date Routine:

A program validating the date, must include at least two more testable requirements:

TR
#
Requirement
Action
Requirement
Logic
18
Return valid return code
If valid date
19
Return invalid return code
If invalid date

Thus the size of the routine is 19 if only one invalid return code is required.

If there is a need for a unique error code for each potential error, then there are 17 more testable requirements associated with each individual date edit requirement and more if all error conditions in combination must be identified.