1、 1 Requirements Phase The chances of a product being developed on time and within budget are somewhat slim unless the members of the software development team agree on what the software product will do. The first step in achieving this unanimity is to analyze the clients current situation as precise
2、ly as possible. For example, it is inadequate to say, “ They need a computer-aided design system because they claim their manual design system, there is lousy. “ Unless the development team knows exactly what is wrong with the current manual system, there is a high probability that aspects of the ne
3、w computerized system will be equally “lousy. “ Similarly, if a personal computer manufacturer is contemplating development of a new operating system, the first step is to evaluate the firms current operating system and analyze carefully exactly why it is unsatisfactory. To take an extreme example,
4、it is vital to know whether the problem exists only in the mind of the sales manager, who blames the operating system for poor sales, or whether users of the operating system are thoroughly disenchanted with its functionality and reliability. Only after a clear picture of the present situation has b
5、een gained can the team attempt to answer the critical question, What must the new product be able to do? The process of answering this question is carried out during the requirements phase. A commonly held misconception is that , during the requirements phase, the developers must determine what sof
6、tware the client wants. On the contrary, the real objective of the requirements phase is to determine what software the client needs. The problem is that many clients do not know what they need. Furthermore, even a client who has a good idea of what is needed may have difficulty in accurately convey
7、ing these ideas to the developers, because most clients are less computer literate than the members of the development team. To elicit the clients needs, the members of the requirements team must be familiar with the application domain, that is, the general area in which the proposed software produc
8、t is to be used. For example, it is not easy to ask meaningful questions of a banker or a nurse without first acquiring some familiarity with banking or nursing. Therefore, one of the initial tasks of each member of the requirements analysis team is to acquire familiarity with the application domain
9、 unless he or she already has experience in that general area. It is particularly important to use correct terminology when communicating with the client and potential users of the target software. After all, it is hard to be taken seriously by a person working in a specific domain unless the interv
10、iewer uses the nomenclature appropriate for that domain. More important, use of an inappropriate word may lead to a misunderstanding, eventually resulting in a faulty product being delivered. The same problem can arise if the members of the requirements team do not understand the subtleties of the t
11、erminology of the domain. One way to solve the problem with terminology is to build a glossary. The initial entries are inserted while the team learns the application domain. Then the glossary is updated whenever the members of the requirements team encounter new terminology. Not only does such a gl
12、ossary reduce confusion between client and developers, it also is useful in lessening misunderstandings between members of the development team. Once the requirements team have acquired familiarity with the domain, the next step is for them to start to determine the clients needs, that is, requireme
13、nts elicitation. Elicitation technique as follows: 2 1. Interviews. The members of the requirements team meet with members of the client organization until they are convinced that they have elicited all relevant information from the client and future users of the product. There are two basic types o
14、f interview, structured and unstructured. In a structured interview, specific, preplanned, close-ended questions are posed. In an unstructured interview, open-ended questions are asked, to encourage the person being interviewed to speak out. Some of these facts might not have come to light had the i
15、nterview been more structured. At the same time, it is not a good idea if the interview is too unstructured. Therefore, questions should be posed in such a way as to encourage the person being interviewed to give wide-ranging answers but within the context of the information needed by the interviewe
16、r. Conducting a good interview is not always easy. First, the interviewer must be familiar with the application domain. Second, there is no point in interviewing a member of the client organization if the interviewer already has made up his or her mind regarding the clients needs. No matter what he
17、or she previously has been told or learned by other means, the interviewer must approach every interview with the intention of listening carefully to what the person being interviewed has to say while firmly suppressing any preconceived notions regarding the client company or the needs of the client
18、s and potential uses of the software product to be built. 2. Scenarios. A scenario is a way a user might utilize the target product to accomplish some objective. A scenario can be depicted in a number of ways. One technique is simply to list the actions comprising the scenario .Another technique is
19、to set up a storyboard, a series of diagrams depicting the sequence of events. They can demonstrate the behavior of the product in a way that is comprehensible to the user. This can result in additional requirements coming to light, as in the weight-loss planner example. Because scenarios can be und
20、erstood by users, the utilization of scenarios can ensure that the client and users play an active role throughout the requirements analysis process. After all, the aim of the requirements analysis phase is to elicit the real needs of the client, and the only source of this information is the client
21、 and the users. Scenarios(or more precisely, use cases) play an important role in object-oriented analysis. 3. To send a questionnaire to the relevant members of the client organization. This technique is useful when the opinions of, say, hundreds of individuals need to be determined. Furthermore, a
22、 carefully thought-out written answer may be more accurate than an immediate verbal response to a question posed by an interviewer. However, an unstructured interview conducted by a methodical interviewer who listens carefully and poses questions that expand on initial responses usually yields far b
23、etter information than a thoughtfully worded questionnaire. Because questionnaires are preplanned, there is no way that a question can be posed in response to an answer. 4. To examine the various forms used by the client. For example, a form in a print shop might reflect press number, paper roll siz
24、e, humidity, ink temperature, paper tension, and so on. The various fields in this form shed light on the flow of print jobs and the relative importance of the steps in the printing process. Other documents, such as operating procedures and job descriptions, also can be powerful tools for 3 finding
25、out exactly what is done and how. Such comprehensive information regarding how the client currently does business can be extraordinarily helpful in determining the clients needs. Therefore, careful perusal of client documentation should never be overlooked as a source of information that can lead to
26、 an accurate assessment of the clients needs. 5. To set up videotape cameras within the workplace to record (with the prior written permission of those being observed) exactly what is being done. One difficulty of this technique is that it can take a long time to analyze the tapes. In general, one o
27、r more members of the requirements analysis team has to spend an hour playing back the tape for every hour that the cameras record. This time is in addition to what is needed to assess what was observed. More seriously, this technique has been known to backfire badly because employees may view the c
28、ameras as an unwarranted invasion of privacy. It is important that the requirements analysis team have the full cooperation of all employees； it can be extremely difficult to obtain the necessary information if people feel threatened or harassed. The possible risks should be considered carefully bef
29、ore introducing cameras or, for that matter, taking any other action that has the potential to anger employees. An initial set of requirements has been elicited, the next step is to refine them, a process called requirements analysis. The members of the requirements team discuss the list of requirem
30、ents with the various individuals interviewed to determine if anything has been omitted. Then, because the most accurate and powerful requirements analysis technique is rapid prototyping, a rapid prototype is built. A rapid prototype is hastily built software that exhibits the key functionality of t
31、he target product. The client and intended users of the product now experiment with the rapid prototype, while members of the development team watch and take notes. Based on their hands-on experience, users tell the developers how the rapid prototype satisfies their needs and, more important, identi
32、fy the areas that need improvement. The developers change the rapid prototype until both sides are convinced that the needs of the client are accurately encapsulated in the rapid prototype. The rapid prototype then is used as the basis for drawing up the specifications. An important aspect of the ra
33、pid prototyping model is embodied in the word rapid. The whole idea is to build the prototype as quickly as possible. After all, the purpose of the rapid prototype is to provide the client with an understanding of the product, and the sooner, the better. It does not matter if the rapid prototype har
34、dly works, if it crashes every few minutes, or if the screen layouts are less than perfect. The purpose of the rapid prototype is to enable the client and the developers to agree as quickly as possible on what the product is to do. Therefore, any imperfections in the rapid prototype may be ignored,
35、provided they do not seriously impair the functionality of the rapid prototype and thereby give a misleading impression of how the product will behave. One difficulty with rapid prototyping is that the ease with which changes generally can be made to a rapid prototype may encourage the client to req
36、uest all sorts of major changes to the delivered operational-quality version of the product. Furthermore, the client may expect the changes to be implemented as rapidly as changes to the rapid prototype. A related challenge is having to explain to the client that the rapid prototype is not of operational quality and the client will have to wait for the operational-quality version, even though the rapid prototype appears to do everything needed. Before rapid prototyping is used, it is
