Information Technology Reference
In-Depth Information
interpretation of the requirements. A sign-off by itself does not affect the
probability of a change being requested after sign-off.
Sign-offs are useful in other ways. A sign-off is a milestone in a project
and also signals the achievement of that milestone. A customer thinks
before signing off, especially when he or she realizes that everything post
sign-off is under change control. For the same reason, the user may be
reluctant to commit, delaying the sign-off interminably, refusing to commit.
Sometimes the sign-off is left to a signing authority who may not have
been involved directly with the requirements at any level of detail. Insisting
on high-level sign-offs for requirements only causes delays. One must
assume that there is a larger business contract under which the require-
ments work is being done, and the sign-offs at the requirements level
could easily be left to those who have been involved in working out the
requirements. This will also reduce avoidable delays. Sign-off authority
must, however, be determined at the start of the project.
Requirements and Development
Conventional wisdom, as espoused in the waterfall model, dictates that
design and development should follow requirements; it is sometimes more
practical to start design and development before the requirements are
complete. Starting work without waiting for completion of the entire
requirements can be a real schedule saver. Of course, it requires identifying
what is definitely going to be required, and taking a calculated risk. There
are many structural elements, such as online help, error messages, log-
ins, and even some processing flows that can be similar across applications,
that the team might have built earlier. There is risk involved in this
approach; yet when schedules are tight, it is something that must be
considered. The trade-off is between the time saved and the costs of
throwing away or reworking some of the work done preemptively.
Revisiting Requirements
Requirements, and the assumptions underlying them, should be revisited
periodically. There is a fear that revisiting requirements will only lead to
changes. The way to address this is to make the customer understand
that the work being done is according to the signed-off requirements. The
revisiting is to give the customers an opportunity to revalidate the require-
ments and trigger change control, with all the costs involved. Even if
genuine changes in requirements are called for, this would still be cheaper
than going ahead and building a product that does will meet customer
needs.
