Fact-Finding Methods

Now that you understand the categories of system requirements, scalability, and TCO, the next step is to begin collecting the information through various fact-findings techniques, including interviews, document review, observation, surveys and questionnaires, sampling, and research.

Ø Although software can help you to gather and analyze facts, no program actually performs fact-finding for you. 

Ø First you must identify the information you need. Typically, you begin by asking a series of questions such as these:

Þ What business functions are supported by the current system?

Þ What strategic objectives and business requirements must be supported by the new system?

Þ What are the benefits and TCO pf the proposed system?

Þ What transactions will the system process?

Þ What information do users and mangers need from the system?

Þ Must the new system interface with legacy system?

Þ What procedures could be eliminated by business process reengineering?

Þ What security issues exist?

Þ What risks are acceptable?

Þ What budget and timetable constraints will affect system development?

Ø To obtain answers to these questions, you develop a fact-finding plan, which can involve another series of questions (who, what, where, when, and how) or use a more structured approach such as the Zachman Framework.

Ø Either way, you will develop a strategy, carry out fact-finding techniques, document the results, and prepare a system requirements document, which is presented to management.

Who, What, Where, When, How, and Why?

         Fact-finding involves answers to five familiar questions: who, what, where, when, and how. For each of those questions you also must ask another very important question: why.

Some examples of these questions are:

1.Who? Who perform s each of the procedures within the system? Why? Are the correct people performing the activity? Could other people perform the task more effectively?
2.What? What is being done? What procedures are being followed? Why is that process necessary? Often, procedures are followed for many years and no one knows why. You should question why a procedure is being followed at all.
3.Where? Where are operations being performed? Why? Where could they be performed? Could they be performed more efficiently elsewhere?
4.When? When is a procedure performed? Why is it performed at this time? Is this the best time?
5.How? How is a procedure performed? Why is it performed in that manner? Could it be performed better, more efficiently, or less expensively in some other manner?

Interviews

Ø System analysts spend a great deal of time talking with people, both inside and outside the IT department.

Ø Much more of that time is spent conducting interviews, which are the most common fact-finding technique.

An interview is a planned meeting during which you obtain information form another person.

Ø You must have the skills needed to plan, conduct, and document interviews successfully.

Ø After you identify the information you need, you begin the interviewing process, which consists the following seven steps in each interview:

1. Determine the people to interview.
2. Establish objectives for the interview.
3. Develop interview questions.
4. Prepare for the interview.
5. Conduct the interview.
6. Document the interview.
7. Evaluate the interview

Step 1: Determine the People to Interview

• To get an accurate picture, you must select the right people to interview and ask them the right question.
• During the preliminary investigation, you talked mainly to middle managers or department heads, now, during the system analysis phase, you might need to interview people from all levels of the organization.
• Should you interview several people at the same time? Group interviews can save time and provide an opportunity to observe interaction among the participants.

Step 2: Establish Objectives for the Interview

• After deciding on the people to interview, you must establish objectives for the session. You should determine the general areas to be discussed, and then list the facts you want to gather.

       

Step 3: Develop Interview Questions

• Creating a standard list of interview questions helps to keep you on track and avoid unnecessary tangents. 
• The interview should consist of several different kinds of questions: open-ended, close-ended, or question with a range of responses. When you phrase your questions, you should avoid leading question that suggest or favor a particular reply.
• For example, rather than asking, “What advantages do you see in the proposed system?” you might ask, “do you see any advantages in the proposed system?” 
• The questions can be classified into three groups:  open-ended, closed-ended and range-of-response questions.

OPEN-ENDED QUESTIONS. Open-ended questions encourage spontaneous and unstructured responses. Such questions are useful when you want to understand a larger process or draw out interviewee’s opinion, attitudes, or suggestions. Here are some examples of open-ended questions: what are users saying about the new system? How is this task performed? Why do you perform task that way? How are the checks reconciled? What would you like to have in the new billing system? Also, you can use an open-ended to probe further by asking: is there anything else you can tell me about this topic?

CLOSED-ENDED QUESTIONS. Closed-ended questions limit or restrict the response. You use closed-ended questions when you want information that is more specific or when you need to verify facts. Examples of closed-ended question include the following: how many personal computers do you have in this department? Do you review the reports before they are sent out? How many hours of training does a clerk receive? Is the calculation procedure described in the manual? How many customers ordered product from the Web site last month?

      

RANGE–OF-RESPONSE QUESTION. Range-of-questions are closed-ended questions that ask the person to evaluate something by providing limited answer to specific responses or on numeric scale. This method makes it easier to tabulated the answers and interpret the results. Range-of-response question might include these: on a scale of 1 to 10, with 1 the lowest and 10 the highest, how effective was your training? How would you rate the severity of the problem: low, medium, or high? Is the system shutdown something that occurs never, sometimes, often usually, or always?

Step 4: Prepare for the interview

• After setting the objectives and developing the questions, you must prepare for the interview.
• Careful preparation is essential because an interview is an important meeting and not just a casual chat.
• When you schedule the interview, suggest a specific day and time and let the interviewee know how long you expect the meeting to last.
• It is also a good idea to send an e-mail or place a reminder to call the day before the interview.
• You should send a list of topics to an interviewee several days before the meeting, especially when detailed information is needed, so the person can prepare for the interview and minimize the need for a follow-up meeting.
• If you have questions about documents, ask the interviewee to have sample available at the meeting. Your advance memo should include a list of the documents you want to discuss, if you know what they are. Otherwise, you can make a general request for documents.

       

Step 5: Conduct the Interview

• During the interview, ask question in the order in which you prepared them, and give the interviewee sufficient time to provide thoughtful answers.
• Establishing a good rapport with the interviewee is important, especially if this is your first meeting.
• If the other person feels comfortable at ease, you probably will receive more complete and candid answers.
• Your primary responsibility during an interview is to listen carefully to the answers. Analysts sometimes hear only what they expect to hear.You must concentrate on what is said and notice any nonverbal communication that takes place. This process is called engaged listening.
• After asking questions, allow the person enough time to think about the question and arrive at an answer.
• When you finish asking your questions, summarize the main points covered in the interview and explain the next course of action.
• When you conclude the interview, thank the person and encourage him or her to contact you with any question or additional comments.
• After an interview, you should summarize the session and seek a confirmation from the other person. By stating your understanding of the discussion, the interviewee can respond and correct you, if        necessary.
• For example, you can say, “if I understand you correctly, you are saying that…” and then reiterate the information given by the interviewee.

 Step 6: Document the Interview

• Although taking notes during an interview has both advantages and disadvantages, the accepted view is that note taking should be kept to a minimum. Although you should write down a few notes to jog your memory after the interview, you should avoid writing everything that is said.
• Too much writing distracts the other person and makes it harder to establish a good rapport.
• After conducting the interview, you must record the information quickly. You should set aside time right after the meeting to record the facts and evaluate the information. For that reason, try not to schedule back-to-back interviews.
• Studies have shown that 50 percent of a conversation is forgotten within 30 minutes.
• You, therefore, should use your notes to record the facts immediately so you will not forget them. You can summarize the facts by preparing a narrative describing what took place or by recording the answer you received next each question o your prepared question list.
• Tape recorders are effective tools for an interview; however, many people feel uncomfortable when recorders are present.
• After the interview, send a memo/letter to the interviewee expressing your appreciation for his or her time and cooperation. In the memo, you should note the date, time, location, purpose of the interview, and the main points you discussed so the interviewee has a written summary and can offer additions or corrections.

Step 7: Evaluate the Interview

• In addition to recording the facts obtained in an interview, try to identify any possible biases.
• For example, an interviewee who tries to protects his or her own area or function might give incomplete answer or refrain from volunteering information. Or, an interviewee with strong opinions about the current or future system might distort the facts.
• Some interviewees might answer your questions in attempt to be helpful even though they do not have the necessary experience to provide accurate information.

Other Fact-Finding Techniques

   System analysts may use other fact-finding techniques, including document review, observation, questionnaires and surveys, sampling, and research. Such techniques are used before interviewing begins to obtain a good overview and to help develop better interview questions.

Document Review

• Document review can help you understand how the current system is supposed to work. 
• Remember that system documentation sometimes is out of date. Forms can change or be discontinued, and documented procedures often are modified or eliminated.
• You should obtain copies of actual forms and operating documents currently in used.
• You also should review blank copies of forms, as well as samples of actual completed forms. You usually can obtain document samples during interviews with the people who perform that procedure.

Observation

• The observation of current operating procedures is another fact-finding technique.
• Seeing the system in action gives you additional perspective and a better understanding of system procedures.
• Personal observation also allows you to verify statements made in interviews and determine whether procedures really operate as they described.
• Through observation, you might discover that neither the system documentation nor the interview statements are accurate.

Questionnaires and Surveys

• In project where it is desirable to obtain input from a large number of people, a questionnaire can be valuable tool.
• A questionnaire, also called a survey, is a document containing a number of standard questions that can be sent to many individuals.
• Questionnaires can be used to obtain information about a wide range of topics, including workloads, reports received, volumes of transaction handled, job duties, difficulties, and opinions of how the job could be performed better or more efficiently.
• When designing a questionnaire, the most important rule of all is to make sure that your questions collect the right data in a form that you can use to further your fact-finding. Here are some additional ideas to keep in mind when designing your questionnaire:

• Keep the questionnaire brief and user-friendly.
• Provide clear instruction that will answer all anticipated questions.
• Arrange the questions in logical order, going from simple to more complex topics.
• Phrase questions to avoid misunderstanding; use simple terms and wording.
• Try not to lead the response or use questions that give clues to expected answers.
• Limit the use of questions that can raise concerns about job security or other negative issues.
• Include a section at the end of the questionnaire for general comments.
• Test the questionnaire whenever possible on a small test group before finalizing it and distributing to large group.

A questionnaire can be traditional paper form, or you can create a fill-in form and collect data on the internet or a company intranet.

Sampling

• When studying in an information system, you should collect examples of actual documents using a process called sampling.
• The samples might include records, reports, operational logs, data entry documents, complaint summaries, work request, and various types of forms.
• Sampling techniques include systematic sampling, stratified sampling, and random sampling.
• The main objective of a sample is to ensure that it represents the overall population accurately.
• If you are analyzing inventory transactions, for example, you should select a sample of transaction that are typical of actual inventory operations and do not include unusual or unrelated examples.
• To be useful, a sample must be large enough to provide a fair representation of the overall data.

Research

• Research is another important fact-finding technique.
• Your research can include the Internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments.
• In addition, you can attend professional meetings, seminars, and discussions with other IT professionals, which can be very helpful in problem solving.

The Need of Documentation in Analysis Phase

• Keeping accurate records of interviews, facts, ideas, and observations is essential to successful systems development.
• The ability to manage information is the mark of a successful system analyst and an important skill for all IT professionals.

The Need for Recording the Facts

• As you gather information, the importance of a single item can be overlooked or complex system details can be forgotten.
• The basic rule is to write it down. You should document your work according to the following principles:
• Record information as soon as you obtain it.
• Use the simplest recording method possible.
• Record your findings in such a way they can be understood by someone else.
• Organize your documentation so related material is located easily.
• Often system analysts use special forms for describing a system, recording interviews, and summarizing documents. 

One type of documentation is narrative list with simple statements about what are occurring, apparent problems, and suggestions for improvement. Other forms of documentation include data flow diagrams, flow charts, sample forms, and screen captures.

Stakeholders- the Source of System Requirements

Ø The primary source of information for functional system requirements is from the various stakeholders of the new system. 

Ø Stakeholders are all the people who have an interest in the successful implementation of the system. 

Ø Generally, stakeholders are categorized into three groups:  users, clients and technical staff.

User stakeholders

Ø  User stakeholders are those who actually use the system in a daily basis.  User roles – that is, types of system users – should be identified in two dimensions: horizontally and vertically.

Horizontal user roles. The analyst must look for the information flow across departments or functions (i.e.  Inventory system may affect different department like receiving, warehousing, sales and manufacturing).

Vertical user roles. The analyst must look for the information needs of clerical staff, middle management and of senior executives.  Generally, vertical user roles include:

1.   business operations users.  These are the people who use the system to perform the day-to-day operations of an organization.  These operations are called transactions – a piece of work done in an organization such as “enter an order”.

2.   query users.  A person who needs current information from the system.  This person may be the same person as to the business operations user or someone else.  A query is a request for information.

3.   management users.  These are people who are responsible for seeing that the company is performing its daily procedures efficiently and effectively.  They need statistics and summary information from a system.

4.   executive users.  A person interested in strategic issues, as well as the daily issues.  They typically want information from the system so that they can compare overall improvements in resource utilization.

Client stakeholders

Ø  A client stakeholder is a person or group who is providing the funding for the project. 

Ø  In many cases, the client is the same group as the executive users.  However, the clients may also be a separate group or people, such as a board of trustees or executives in a parent company. 

Ø  The client or a direct representative on a steering or oversight committee also usually maintains ongoing approval and release of funds.

Technical stakeholders

Ø  The technical staffs are the people who ensure that the system operates in the computing environment of the organization.

Ø  It is the source of technical requirements. 

Ø  These people provide guidance in such areas as programming language, computer platforms, and other equipment.

Understanding System Requirements

System requirements are the functions that the new system must perform or it is a definition of specifications for functions to be provided by the system. 

Ø One of the activities during the planning phase is to identify the scope where the analyst identifies a set of system capabilities. 

Ø During the analysis, the analyst defines and describes those capabilities into detailed system requirements. 

Ø Generally a system requirement is divided into two categories:  functional and technical requirements.

Functional requirement

Ø Functional system requirement describes a function or process that the system must support – that is, business uses to which the system will be put.  They derive directly from the capabilities identified during planning.  For example if you are developing a payroll system, the required business uses might include functions like:

§  write paychecks

§  calculate commission amounts

§  calculate payroll taxes

Technical requirement

Ø Technical system requirement describes an operating environment of performance objective relating to hardware and software of the organization.  These technical requirements are often expressed as specific objectives that the system must attain.  For example in developing a payroll system:

§  the system must run in a client-server environment with Windows Vista

§  must have one-half second response time on all screens

§  must be able to support 100 terminals at once

System Requirements Checklist

Ø During requirements modeling systems developers must identify and describe all system requirements. System requirements serve as benchmark to measure the overall acceptability of the finished system.

Ø Based on whether a system requirement is technical or functional, analyst should also consider outputs, inputs, processes, performance, and controls requirements.

Ø Typical examples of system requirements for outputs, inputs, processes, performance, and controls are:

Outputs

Þ    The Web site must report online volume statistics every four hours, and hourly during peak periods.

Þ    The inventory system must produce a daily report showing the part number, description, quantity on hand, quantity allocated, quantity available, and unit cost of all sorted by part number.

Þ    The contact management system must generate a daily reminder list for all sales reps.

Þ    The purchasing system must provide suppliers with up-to-date specifications.

Þ    The sales tracking system must produce a daily fast-moving-item report, listing all products that exceed the forecasted sales volume grouped by style, color, size, and reorder status.

Þ    The customer analysis system must produce a quarterly report that identifies changes in ordering patterns or trends with statistical comparisons to the previous four quarters.

Inputs

Þ    Manufacturing employees must swipe their ID cards into online data collection terminal that record labor cost and calculate production efficiency.

Þ    The department head must enter overtime hours on a separate screen.

Þ    Students’ grades must be entered on machine –scannable forms prepared by the instructor.

Þ    Each input form must include date, time, product code, customer number, and quantity

Þ    Data entry screens must be uniform, except for background color, which can be changed by the user.

Þ    A data entry person at the medical group must input patient services into the billing system.

Processes

Þ    The student records system must calculate the GPA at the end of each semester.

Þ    As the final step in year-end processing, the payroll system must update employee salaries, bonuses, and benefits and produce tax data required by the IRS.

Þ    The warehouse distribution system must analyze daily orders and create a routining pattern for delivery trucks that maximizes efficiency and reduces unnecessary mileage.

Þ    The human resources system must interface properly with the existing payroll system.

Þ    The video rental system must not execute new rental transactions for customers who have overdue tapes.

Þ    The prescription system must automatically generate an insurance claim form.

Performance

Þ       The system must support 25 users online simultaneously.

Þ       Response time must not exceed four seconds.

Þ       The system must be operational seven days a week, 365 days a year.

Þ       The accounts receivable system must prepare customer statements by the third business day of the following month.

Þ       The student records system must produce class lists within five hours after the end of registration.

Þ       The online inventory control system must flag all low-stock items within one hour after the quantity falls below a predetermined minimum.

Controls

Þ       The system must provide log-on security at the opening system level and at the application level.

Þ       An employee record must be added, changed, or deleted only by a member of the human resources department.

Þ       The system must maintain separate levels of security for users and the system administrator.

Þ       All transactions must have audit trials.

Þ       The manager of the sales department must approve orders that exceed a customer’s credit limit.

Þ       The system must create error log files that include the error type, description and time.

Future Growth, Cost and Benefits

In addition to the system requirements, systems analysts must consider scalability, which determines how a system will handle future growth and demand, and the total cost of ownership, which includes all future operational and support costs.

Scalability

Ø Scalability refers to a system’s ability to handle increased business volume and transaction in the future. Because it will have a longer useful life, a scalable system offers a better return on the initial investment.

Ø To evaluate scalability, you need information about projected future volume for all outputs, inputs, and processes.

For example, for a Web-based order processing system, you would need to know the estimated number of online customers, the periods of peak online activity, the number and types of data items required for each transaction, and the method of accessing and updating customer files.

Ø Transactions volume has a significant impact on operating cost. Volume can change dramatically if a company expands or enters a new line of business. For example, a new internet-based marketing effort might require an additional server and 24-hour technical support.

Ø Data storage also is an important scalability issue. You need to determine how much data storage is required currently and predict future needs based on system activity and growth. You also must consider data retention requirements and determine whether data can be deleted or achieved on specific timetable.

Total Cost of Ownership

Ø In addition to direct cost, system developers must identify and document indirect expenses that contribute to the total cost of ownership (TCO).

Ø TCO is especially important if the development team is assessing several alternatives.

Ø After considering the indirect costs, which are not always apparent, a system that seems inexpensive initially might actually turn out to be the most costly choice.

Ø One problem is that cost estimates tend to understate indirect cost such as user support and downtime productivity losses. Even if accurate figures are unavailable, systems analysts should try to identify indirect costs and include them in TCO estimates.