TABLE OF CONTENTS This chapter begins with the definition of the problem or situation and runs through to the completion of requirements. As you will see, there are many problems with employing the traditional system life cycle, including the following.
Seldom attaining the goal of 100% requirements
The myth that there will be no changes once requirements are signed off
The belief that users support the change
The reliance on king and queen bees, senior users, for information
In the traditional method of requirements analysis, you gather information about user needs. You ask what process and IT problems they have. You ask them what they want. Sometimes, and probably often, you are met with a blank stare. Some people tell you what you want to hear so that you will leave. Then you return to your desk and write up the requirements. After it has been documented, you review it with them, make some changes, and get signoffs. A search for a software package or software design follows. Later it is discovered that there were many hidden requirements. New ones keep coming up all the time. But you did everything by the book.
What went wrong? The first problem is one of assumptions. The assumptions from the scenario in the preceding paragraph include the following.
The users are willing and ready for change.
The users have an idea of what they want.
Most of the user problems can be fixed by IT and a system.
Time and time again,...
