concerned with technology are isolated from the mainstream of the business enterprises they serve, they cannot hope to meet customer requirements.
Step 2: Obtain Theoretical Business Knowledge.
In Rethinking Systems Analysis and Design, Jerry Weinberg talks about the time it takes a novice to amass knowledge comparable to that of an entry level graduate student in that field. The period is somewhere between one and three months. Most analysts are unwilling to invest even a fraction of this time on mastering the basics of the business discipline they are supposed to support.
You can't develop outstanding inventory management systems if you don't know inventory management. Accounts payable systems development requires accounting knowledge.
Do not assume that your customers/users possess this theoretical knowledge. W. Edwards Deming said, "Experience teaches nothing unless studied with the aid of theory," but it is not unusual to encounter the absence of even basic theoretical knowledge about critical business functions in users. As an example, I worked with a client who managed finished goods inventory for an $800 million multi-plant packaging manufacturer. He joined the company right out of high school, worked on the loading dock, had been promoted internally to his current position. He had never taken one class in inventory management theory. How could he start to understand, let alone define, the advanced capabilities that new systems could provide?
How do you obtain this knowledge? Previously, this could require a great deal of time in the company library. Now, it's all available online. Remember, people write about problems and failures as much as successes. Take the chance to profit from someone else's mistakes.
Step 3: Study Existing Systems.
Use existing systems as a starting point in developing requirements. Analyze the existing system, but also examine other systems. These may include systems with which you have previously worked, those available from vendors, or those used by competitors. The best analysts can spot similarities between systems used for disparate business purposes and extrapolate their features to the existing environment. For every feature offered by a vendor, ask yourself, "What requirement prompted this feature? Do we have this requirement; if not, why not?" These questions can be a tremendous help.
Step 4: Analyze the Using Environment.
The most logical and complete method of obtaining requirements is from a detailed analysis of the environment within which the system will be used. Observation, and--even better--actual working experience in this environment is invaluable if the analyst is armed with sufficient business knowledge, theoretical understanding of the business functions, and familiarity with existing systems. Without this background, you wouldn't know what to look for.
In Software Quality Professional, Alan Davis states, "Observing potential users in their natural environment. . .has resulted in significantly more accurate perceptions of the problem space than asking users what they do." Davis calls this ethno methodological studies. If systems analysts spend more than half of their time in the IT department, they aren't doing their jobs.
Leave your desk, get out, and work with your customers in their environment. If you don't understand how a system is to be used, you have no business building it.
Step 5: Interview Customers and Users.
The junior analyst begins defining requirements by asking the user what is wanted. Sadly, analysis typically stops at this point.
Requirements definition interviews are not about "asking" customers what they want. These interviews should be a two-way exchange of information used to mutually define problems and opportunities for information technology application within a business function. Discuss problems with users. Clarify issues observed in the environment. Make suggestions and observations based on theoretical knowledge and