When you are eliciting system requirements, focus on what functions the system should perform, what data is required to support those functions, and how important the quality requirements – performance, reliability, usability and flexibility – are likely to be.
If the system you are planning is primarily intended to solve operational problems (high cost, high error rates, unresponsiveness, customer complaints...), you should spend some time getting familiar with the current operation, focusing on those people who actually experience the problem (as opposed to those to whom the problem or its symptoms are reported). This approach was systematic in the early days of information processing and was called “Analyzing the Current System.” (One of the additional advantages of analyzing the current system was that it allowed the project team to learn about the business while doing something productive. Project teams today usually have to meet the expectation that they already know the basics of the business.)
There is less emphasis on the current system today, especially if the motivation for the system you want to build is to take advantage of technology to exploit a new opportunity. In that case, you want to focus on finding people who have a vision of what could be done, preferably in a group setting, where creative ideas are likely to flow.
Interviewing is by far the most common technique used in reviewing a present system. It relies heavily on such active listening skills as open-ended questions, appropriate words and phrases, acceptance cues, and restatement at both the direct and emotional level. Used properly, silence can also be effective. 1
The most widespread group technique is probably Joint Application Design. JAD was developed in the early 1980s to overcome some of the difficulties caused by the more classic approaches to requirements analysis. 2
The technique itself consists of gathering highly competent users (about ten) for a two- to four-day workshop to discuss, conceptualize, and analyze. IS personnel are present, mainly to listen, to record what is being said, and to document the users’ contributions. The workshop is led by an independent person to whom neither the users nor the IS personnel report. The role of the leader is twofold: to elicit decisions by consensus and compromise rather than by fiat or majority vote and to keep the meeting on track so that the system to be built is the one that is discussed.
A particularly effective way of documenting what is being said is to create a prototype of the application on the fly. When you hear a user express an idea, it is particularly effective to be able to say, “Is this what you mean?” as you illustrate a screen layout, mouse clicks or navigation paths on a computer (projected on a large screen for everybody to see). The group can then react, critique, and build on what is shown.
There are a couple of traps you need to avoid with group techniques. The first is called “groupthink” and consists in the group losing its critical sense and going along with absurd or unworkable ides – partly because it is difficult for a group member to appear to be the only one who is against some idea. The other danger is related: a group may become overenthusiastic and push for “gold-plating,” features and functions that look nice but serve no useful function – or not useful enough to be worth the cost. Don Gause and Gerald Weinberg have written an excellent and thought-provoking book on the subject. 3
Finally, if the system you are planning is going to be used by outsiders (consumers, customers, suppliers, the general public) you need to devise a way to make their voices heard, for example by surveys or focus groups.
- 瀏覽次數：1297
