Information Technology Reference
In-Depth Information
upgrade is scheduled only once a year. Users who want their changes
implemented must begin by understanding the release schedules in place.
Calculating backward from the release date and allowing for development,
QA, and UAT, it often does not leave much time for the requirements
step. New requirements get incorporated into new releases, by which time
more new requirements might have emerged. Thus a continuous catch-
up goes on.
Requirements and QA
QA activities often derive from the formal requirements specifications. The
requirements form an important input to QA. They are used to drive test
plans and test design. This is an accepted, normal process.
The larger issue is that the QA group is a stakeholder in the project,
yet is often ignored during the requirements development stage. This leads
to situations where the requirements committed to result in onerous testing
burdens. Development techniques that draw out requirements by prepar-
ing test cases for them have an advantage on this.
The need to involve QA personnel during the early requirements stage
is an important example of why stakeholder coverage should be as
complete as possible.
Uncertainty in Requirements
As previously discussed, requirements are never complete. Even to the
extent that they can be said to be complete for a particular phase, there
may be, in the minds of the business user, some uncertainty associated
with what has been agreed to. If the requirements are uncertain, then it
is quite likely that change requests will arise to reduce that uncertainty.
One way of handling such uncertainty is to provide for a contingency in
the budget allocated. This will benefit both the customers and the devel-
opers. It allows both to accommodate “missing” requirements or unantic-
ipated complexity without having to, perhaps, go through a funding
process. This use of contingency should remain under the change control
process.
How large this contingency allocation could be is a function of the
uncertainty that exists. Experience suggests that it should be reasonably
large, if circumstances permit. Estimation of software development and
delivery costs is still an art rather than a science. The r eason why
contingency is sometimes kept low is because the mainline estimates are
well buffered for handling the uncertainty. That, although common prac-
tice, is a less advisable practice than providing proper estimates and then
Search WWH ::




Custom Search