|
Business
Requirements Analysis: an Historical Perspective
Budgets and resources are tight, time pressures are ever present,
and the business is demanding changes, enhancements and new services
like never before. It should probably be no surprise then that
some shops are still not devoting time to doing analysis under
the misguided perception that short-cutting this activity will
speed up the development effort and save costs. As the accompanying
graph depicts, the end results are quite the opposite. This is
the trap that most organizations fell into in the 70's and early
80's. Not defining the business and system requirements up-front
resulted in significant costs in subsequent Software Development
Life-cycle (SDLC) phases. The reason for this, we now know, is
that the analysis activity was simply shifted into these other
phases of the SDLC resulting in additional effort and rework.
Things are discovered during design, during coding, or during
testing that should have been addressed during analysis. This
results in lost time, increased effort (because of the ripple
effect of the changes required) and increased cost. A further
cost is borne dealing with changes to requirements during maintenance
and enhancement activities where companies currently spend an
average of seventy-seven percent of a department's budget.
If we don't have time to do it right the first time, when do we
have the time to fix it?
Devoting so much time to analysis that it interferes with the
product delivery isn't the answer either.
In this highly competitive world the IT group must respond better
& faster, otherwise our Users will look to other providers.
In today's world, you need a method that captures the Users requirements,
quickly, accurately and completely - one that provides a flexible,
yet structured approach to producing a high quality specification,
consistently.
CONTACT US
1-800-209-3616
Copyright © 1999 The Information
Architecture Group and
The Information Architecture Group, Inc. All Rights Reserved
|
|