familiarity with other systems.
An information systems request from a customer is a request for help. The customer has a business problem and believes that information technology can assist in the solution. Usually the customer has only identified a symptom of the real problem, not the problem's root causes. Work with the customer, identifying root causes and developing opportunities to solve real business problems. Don't just satisfy a request to slap a bandage on a symptom.
Use the interview process to identify assumptions, constraints, and obstacles. Previous analytical work will have given you a basis for this. For reference, develop a high level design for a system "in a vacuum" before ever talking to the user. The interview process can then be used to tweak the design, uncover unique aspects of the problem space and discuss priorities.
Step 6: Utilize Prototyping.
Prototyping is most useful in user education and risk reduction. It is not a requirements definition technique, although it may be used to clarify expectations. Where a model does not exist for a system, where theoretical knowledge is unobtainable or where the environment within which the system must operate cannot be observed, the analyst, in conjunction with the customer, may utilize an iterative approach to requirements definition.
Prototyping can reduce the risk of building the wrong system. It can be a means of converting poorly understood requirements into well-understood requirements-educating both users and developers in the process. Prototyping can be effective in requirements definition, and let me emphasize this, only when people can articulate fuzzy (that is, poorly understood) requirements. Prototyping has the potential to clarify that fuzziness.
Know that prototypes are likely to miss the mark. Expect failures and throwaways. After all, you are sailing in uncharted waters. If the requirements were obvious, you wouldn't need a prototype.
Software tools are available for building prototypes and mock ups quickly and relatively inexpensively, supposedly precluding expensive systems development fiascoes. However, I'll offer two cautionary notes regarding prototyping.
First, prototyping doesn't guarantee delivery. Recently I worked with a software firm that introduced a prototype at an industry conference. Customers went wild. This system, new and unique, would revolutionize a whole segment of their business.
The software firm budgeted one year and $1 million to turn the prototype into a working system. They booked orders against that schedule. Three years and almost $4 million later, they still had not delivered a satisfactory system. They could develop the prototype, but lacked the system development methodologies and processes to build it.
Second, to re-emphasize, resist the trend to use prototyping as a substitute for business knowledge, analysis of existing systems, and analysis of the business environment and user interviews. Prototyping is a fall back position, not the answer in and of itself.
Own the Process
To be consistently successful, the project team must assume ownership of the requirements definition process. You cannot be the customer of the process--requirements are not a product supplied by someone else. Take responsibility for the quality and completeness of requirements.
The NASA onboard shuttle project, the first software development organization to reach CMM Level 5, considers a request to change requirements as a nonconformance-- an opportunity to analyze the process, improve it, and reduce changes in the future.
The Capability Maturity Model (CMM) identifies Requirements Management as a Level 2 Key Process Area. Are requirements identification taking place in your organization before requirement management begins? Contrast this with the iterative NASA requirements management process:
- identify need
- examine options
- develop solution
- define requirements
- produce requirements specification
- assess technical and resource impact
- determine acceptability, implementation ability, testability