Traditional Methods for Determining Requirements




Traditional Methods for Determining Requirements

Collection of information is at the core of systems analysis. At the outset, you must collect information about the information systems that are currently in use. You need to find out how users would like to improve the current systems and organizational operations with new or replacement information systems. One of the best ways to get this information is to talk to those directly or indirectly involved in the different parts of the organization affected by the possible system changes. Another way is to gather copies of documentation relevant to current systems and business processes. In this chapter, you learn about traditional ways to get information directly from those who have the information you need: interviews and direct observation. You learn about collecting documentation on the current system and organizational operation in the form of written procedures, forms, reports, and other hard copy. These traditional methods of collecting system requirements are listed in Table 5-2.

Interviewing and Listening

Interviewing is one of the primary ways analysts gather information about an information systems project. Early in a project, an analyst may spend a large amount of time interviewing people about their work, the information they use to

TABLE 5-2: Traditional Methods of Collecting System Requirements

Traditional Methods for Determining Requirements

TABLE 5-3: Guidelines for Effective Interviewing

Traditional Methods for Determining Requirements

do it, and the types of information processing that might supplement their work. Others are interviewed to understand organizational direction, policies, and expectations that managers have of the units they supervise. During interviewing, you gather facts, opinions, and speculation and observe body language, emotions, and other signs of what people want and how they assess current systems. Interviewing someone effectively can be done in many ways, and no one method is necessarily better than another. Some guidelines to keep in mind when you interview are summarized in Table 5-3 and are discussed next. First, prepare thoroughly before the interview. Set up an appointment at a time and for a duration that is convenient for the interviewee.

The general nature of the interview should be explained to the interviewee in advance. You may ask the interviewee to think about specific questions or issues, or to review certain documentation to prepare for the interview. Spend some time thinking about what you need to find out, and write down your questions. Do not assume that you can anticipate all possible questions. You want the interview to be natural and, to some degree, you want to direct the interview spontaneously as you discover what expertise the interviewee brings to the session. Prepare an interview guide or checklist so that you know in which sequence to ask your questions and how much time to spend in each area of the interview. The checklist might include some probing questions to ask as follow-up if you receive certain anticipated responses.

You can, to some extent, integrate your interview guide with the notes you take during the interview, as depicted in a sample guide in Figure 5-2. This same guide can serve as an outline for a summary of what you discover during an interview.The first page of the sample interview guide contains a general outline of the interview. Besides basic information on who is being interviewed and when, list major objectives for the interview. These objectives typically cover the most important data you need to collect, a list of issues on which you need to seek agreement (e.g., content for certain system reports), and which areas you need to explore. Also, include reminder notes to yourself on key information about the interviewee (e.g., job history, known positions taken on issues, and role with current system).

This information helps you to be personal, shows that you consider the interviewee important, and may assist in interpreting some answers. Also included is an agenda with approximate time limits for different sections of the interview. You may not follow the time limits precisely, but the schedule helps you cover all areas during the time the interviewee is available. Space is also allotted for general observations that do not fit under specific questions

FIGURE 5-2 A typical interview guide

Traditional Methods for Determining Requirements

and for notes taken during the interview about topics skipped or issues raised that could not be resolved. On subsequent pages, list specific questions. The sample form in Figure 5-2 includes space for taking notes on these questions. Because the interviewee may provide information you were not expecting, you may not follow the guide in sequence. You can, however, check off questions you have asked and write reminders to yourself to return to or skip other questions as the interview takes place.

Choosing Interview Questions You need to decide on the mix and sequence of open-ended and closed-ended questions to use. Open-ended questions are usually used to probe for information when you cannot anticipate all possible responses or when you do not know the precise question to ask. The person being interviewed is encouraged to talk about whatever interests him or her within the general bounds of the question. An example is, “What would you say is the best thing about the information system you currently use to do your job?” or “List the three most frequently used menu

FIGURE 5-2 (continued)

Traditional Methods for Determining Requirements

options.” You must react quickly to answers and determine whether any followup questions are needed for clarification or elaboration. Sometimes body language will suggest that a user has given an incomplete answer or is reluctant to provide certain information. If so, a follow-up question might result in more information. One advantage of open-ended questions is that previously unknown information can surface. You can then continue exploring along unexpected lines of inquiry to reveal even more new information. Open-ended questions also often put the interviewees at ease because they are able to respond in their own words using their own structure. Open-ended questions give interviewees more of a sense of involvement and control in the interview. A major disadvantage of open-ended questions is the length of time it can take for the questions to be answered. They also can be difficult to summarize. Closed-ended questions provide a range of answers from which the interviewee may choose. Here is an example:

Which of the following would you say is the one best thing about the information system you currently use to do your job (pick only one)?

a. Having easy access to all of the data you need

b. The system’s response time

c. The ability to run the system concurrently with other applications

Closed-ended questions work well when the major answers to questions are well known. Another plus is that interviews based on closed-ended questions do not necessarily require a large time commitment—more topics can be covered. Closed-ended questions can also be an easy way to begin an interview and to determine which line of open-ended questions to pursue. You can include an “other” option to encourage the interviewee to add unexpected responses. A major disadvantage of closed-ended questions is that useful information that does not quite fit the defined answers may be overlooked as the respondent tries to make a choice instead of providing his or her best answer. Like objective questions on an examination, closed-ended questions can follow several forms, including these choices:

  • True or false
  • Multiple choice (with only one response or selecting all relevant choices)
  • Rating a response or idea on some scale, say, from bad to good or strongly agree to strongly disagree (each point on the scale should have a clear and consistent meaning to each person, and there is usually a neutral point in the middle of the scale)
  • Ranking items in order of importance

Interview Guidelines First, with either open- or closed-ended questions, do not phrase a question in a way that implies a right or wrong answer. Respondents must feel free to state their true opinions and perspectives and trust that their ideas will be considered. Avoid questions such as “Should the system continue to provide the ability to override the default value, even though most users now do not like the feature?” because such wording predefines a socially acceptable answer. Second, listen carefully to what is being said. Take careful notes or, if possible, record the interview on a tape recorder (be sure to ask permission first!). The answers may contain extremely important information for the project. Also, this may be your only chance to get information from this particular person. If you run out of time and still need more information from the person you are talking to, ask to schedule a follow-up interview.

Third, once the interview is over, go back to your office and key in your notes within forty-eight hours with a word processing program such as Microsoft Word. For numerical data, you can use a spreadsheet program such as Microsoft Excel. If you recorded the interview, use the recording to verify your notes. After forty-eight hours, your memory of the interview will fade quickly. As you type and organize your notes, write down any additional questions that might arise from lapses in your notes or ambiguous information. Separate facts from your opinions and interpretations. Make a list of unclear points that need clarification. Call the person you interviewed and get answers to these new questions. Use the phone call as an opportunity to verify the accuracy of your notes. You may also want to send a written copy of your notes to the person you interviewed to check your notes for accuracy. Finally, make sure to thank the person for his or her time. You may need to talk to your respondent again. If the interviewee will be a user of your system or is involved in some other way in the system’s success, you want to leave a good impression.

Fourth, be careful during the interview not to set expectations about the new or replacement system unless you are sure these features will be part of the delivered system. Let the interviewee know that there are many steps to the project. Many people will have to be interviewed. Choices will have to be made from among many technically possible alternatives. Let respondents know that their ideas will be carefully considered. Because of the repetitive nature of the systems development process, however, it is premature to say now exactly what the ultimate system will or will not do.

Fifth, seek a variety of perspectives from the interviews. Talk to several different people: potential users of the system, users of other systems that might be affected by this new system, managers and superiors, information systems staff, and others. Encourage people to think about current problems and opportunities and what new information services might better serve the organization. You want to understand all possible perspectives so that later you will have information on which to base a recommendation or design decision that everyone can accept.

Directly Observing Users

Interviewing involves getting people to recall and convey information they have about organizational processes and the information systems that support them. People, however, are not always reliable, even when they try to be and say what they think is the truth. As odd as it may sound, people often do not have a completely accurate appreciation of what they do or how they do it, especially when infrequent events, issues from the past, or issues for which people have considerable passion are involved. Because people cannot always be trusted to interpret and report their own actions reliably, you can supplement what people tell you by watching what they do in work situations. For example, one possible view of how a hypothetical manager does her job is that a manager carefully plans her activities, works long and consistently on solving problems, and controls the pace of her work. A manager might tell you that is how she spends her day. Several studies have shown, however, that a manager’s day is actually punctuated by many, many interruptions.

Managers work in a fragmented manner, focusing on a problem or a communication for only a short time before they are interrupted by phone calls or visits from subordinates and other managers. An information system designed to fit the work environment described by our hypothetical manager would not effectively support the actual work environment in which that manager finds herself. As another example, consider the difference between what another employee might tell you about how much he uses electronic mail and how much electronic mail use you might discover through more objective means. An employee might tell you he is swamped with e-mail messages and spends a significant proportion of time responding to e-mail messages. However, if you were able to check electronic mail records, you might find that this employee receives only three e-mail messages per day on average and that the most messages he has ever received during one eight-hour period is ten. In this case, you were able to obtain an accurate behavioral measure of how much e-mail this employee copes with, without having to watch him read his e-mail.

The intent behind obtaining system records and direct observation is the same, however, and that is to obtain more firsthand and objective measures of employee interaction with information systems. In some cases, behavioral measures will more accurately reflect reality than what employees themselves believe. In other cases, the behavioral information will substantiate what employees have told you directly. Although observation and obtaining objective measures are desirable ways to collect pertinent information, such methods are not always possible in real organizational settings. Thus, these methods are not totally unbiased, just as no one data-gathering method is unbiased. For example, observation can cause people to change their normal operating behavior.

Employees who know they are being observed may be nervous and make more mistakes than normal. On the other hand, employees under observation may follow exact procedures more carefully than they typically do. They may work faster or slower than normal. Because observation typically cannot be continuous, you receive only a snapshot image of the person or task you observe. Such a view may not include important events or activities. Due to time constraints, you observe for only a limited time, a limited number of people, and a limited number of sites. Observation yields only a small segment of data from a possibly vast variety of data sources. Exactly which people or sites to observe is a difficult selection problem. You want to pick both typical and atypical people and sites and observe during normal and abnormal conditions and times to receive the richest possible data from observation.

Analyzing Procedures and Other Documents

As previously noted, interviewing people who use a system every day or who have an interest in a system is an effective way to gather information about current and future systems. Observing current system users is a more direct way of seeing how an existing system operates. Both interviewing and observing have limitations. Methods for determining system requirements can be enhanced by examining system and organizational documentation to discover more details about current systems and the organization they support. We discuss several important types of documents that are useful in understanding system requirements, but our discussion is not necessarily exhaustive. In addition to the few specific documents we mention, other important documents need to be located and considered, including organizational mission statements, business plans, organization charts, business policy manuals, job descriptions, internal and external correspondence, and reports from prior organizational studies.

What can the analysis of documents tell you about the requirements for a new system? In documents you can find information about:

  • Problems with existing systems (e.g., missing information or redundant steps)
  • Opportunities to meet new needs if only certain information or information processing were available (e.g., analysis of sales based on customer type)
  • Organizational direction that can influence information system requirements (e.g., trying to link customers and suppliers more closely to the organization)
  • Titles and names of key individuals who have an interest in relevant existing systems (e.g., the name of a sales manager who has led a study of buying behavior of key customers)
  • Values of the organization or individuals who can help determine priorities for different capabilities desired by different users (e.g., maintaining market share even if it means lower short-term profits)
  • Special information-processing circumstances that occur irregularly that may not be identified by any other requirements determination technique (e.g., special handling needed for a few large-volume customers who require use of customized customer ordering procedures)
  • The reason why current systems are designed as they are, which can suggest features left out of current software that may now be feasible and desirable (e.g., data about a customer’s purchase of competitors’ products not available when the current system was designed; these data now available from several sources)
  • Data, rules for processing data, and principles by which the organization operates that must be enforced by the information system (e.g., each customer assigned exactly one sales department staff member as primary contact if customer has any questions)

One type of useful document is a written work procedure for an individual or a work group. The procedure describes how a particular job or task is performed, including data and information used and created in the process of performing the job. For example, the procedure shown in Figure 5-3 includes data (list of features and advantages, drawings, inventor name, and witness names) required to prepare an invention disclosure. It also indicates that besides the inventor, the vice president for research, the department head, and the dean must review the material and that a witness is required for any filing of an invention disclosure. These insights clearly affect what data must be kept, to whom information must be sent, and the rules that govern valid forms.

 

Procedures are not trouble-free sources of information, however. Sometimes your analysis of several written procedures reveals a duplication of effort in two or more jobs. You should call such duplication to the attention of management as an issue to be resolved before system design can proceed. That is, it may be necessary to redesign the organization before the redesign of an information system can achieve its full benefits. Another problem you may encounter is a missing procedure. Again, it is not your job to create a document for a missing procedure—that is up to management. A third and common problem happens when the procedure is out of date, which you may realize in your interview of the person responsible for performing the task described in the procedure.

Once again, the decision to rewrite the procedure so that it matches reality is made by management, but you may make suggestions based upon your understanding of the organization. A fourth problem often encountered is that the formal procedures may contradict information you collected from interviews, questionnaires, and observation about how the organization operates and what information is required. As in the other cases, resolution rests with management. All of these problems illustrate the difference between formal systems and informal systems. A formal system is one an organization has documented; an informal system is the way in which the organization actually works. Informal systems develop because of inadequacies of formal procedures and individual work habits, preferences, and resistance to control. It is important to understand both formal and informal systems because each provides insight into information requirements and what is necessary to convert from present to future systems.

A second type of document useful to systems analysts is a business form, illustrated in Figure 5-4. Forms are used for all types of business functions, from recording an order to acknowledging the payment of a bill to indicating what goods have been shipped. Forms are important for understanding a system because they explicitly indicate what data flow in or out of a system. In the sample invoice form in Figure 5-4, we see space for data such as invoice number, the “bill to” address, the quantity of items ordered, their descriptions, rates, and amounts. A printed form may correspond to a computer display that the system will generate for someone to enter and maintain data or to display data to online users. The most useful forms contain actual organizational data that allow you to determine the data characteristics actually used by the application. The ways in which people use forms change over time, and data that were needed when a form was designed may no longer be required.

A third type of useful document is a report generated by current systems. As the primary output for some types of systems, a report enables you to work backward from the information on the report to the data that must have been necessary to generate it. Figure 5-5 presents an example of a common financial accounting report, the statement of cash flows. You analyze such reports to determine which data need to be captured over what time period and what manipulation of these raw data is necessary to produce each field on the report. If the current system is computer based, a fourth set of useful documents is one that describes the current information systems—how they were designed and how they work. Several different types of documents fit this description, everything from flowcharts to data dictionaries to user manuals. An analyst who has access to such documents is fortunate because many in-house-developed information systems lack complete documentation. Analysis of organizational documents and observation, along with interviewing and distributing questionnaires, are the methods used most for gathering system requirements. Table 5-4 (page 137) summarizes the comparative features of observation and analysis of organizational documents.

FIGURE 5-4 An example of a business form—an invoice form for QuickBooks. Source: http://jnk.btobsource.com/NASApp/enduser/products/product_detail.jsp?pc13050M#. Reprinted with permission.

Traditional Methods for Determining Requirements

 

 

 

 



Frequently Asked Questions

+
Ans: In the last chapter, you read how Pine Valley Furniture’s management began the WebStore project—to sell furniture products over the Internet. view more..
+
Ans: Whether traditional or modern, the methods for determining system requirements that you have read about in this chapter apply to any requirements determination effort, regardless of its motivation. view more..
+
Ans: Even though we called interviews, questionnaires, observation, and document analysis traditional methods for determining a system’s requirements, all of these methods are still used by analysts to collect important information. view more..
+
Ans: Collection of information is at the core of systems analysis. view more..
+
Ans: Even though we called interviews, questionnaires, observation, and document analysis traditional methods for determining a system’s requirements, all of these methods are still used by analysts to collect important information. view more..
+
Ans: Whether traditional or modern, the methods for determining system requirements that you have read about in this chapter apply to any requirements determination effort, regardless of its motivation. view more..
+
Ans: Process modeling involves graphically representing the processes, or actions, that capture, manipulate, store, and distribute data between a system and its environment and among components within a system. view more..
+
Ans: Data-flow diagrams are versatile diagramming tools. view more..
+
Ans: Sofware engineering syllabus The course of the program is designed in an exceedingly manner that it covers all the aspects of software system engineering needed for higher understanding of the scholars. The delivery methodology of the program is usually schoolroom lectures Associate in Nursing sensible laboratory sessions beside seminars and internships being an integral a part of the course. BE/B.Tech software system Engineering give students data of evaluating the correct codes and software system for specific tasks. view more..
+
Ans: The first published model of software development process was derived from more general system engineering processes. Because of the cascade from one phase to another, this model is known as the waterfall model or software life cycle. The principal stages of the model map onto fundamental development activities: view more..
+
Ans: System prototyping performs the analysis, design, and implementation phases concurrently in order to quickly develop a simplified version of the proposed system and give it to the users for evaluation and feedback. view more..
+
Ans: Software is defined as collection of data, programs, procedures, associated documentaion and rules. which does not have any mass, volume and colour. software does not wear out,get tired or degrade over a long period of time view more..



Recommended Posts:


Rating - 3/5
539 views

Advertisements