Requirements Gathering Techniques Term Paper

Abstract

Since the system analysis stage of any Information Systems development is required in the process of solving a company’s problems, it is vital to gather the system requirements and business requirements of the existing system and the proposed new system. This paper describes the techniques of gathering requirements for creating information systems for a company; detailing the advantages and disadvantages of each method, and where they are applicable. In essence, companies should adopt the following techniques: interviews, observations, questionnaires, examining documentation, and Joint Application Design(JAD). However, a joint interview is seen as the most appropriate method because it has a strategic business implication to the stakeholders about time and information system functionality.

Introduction

Managers and business organizations invest in information technology and systems because such strategies provide real economic value to the business. The decision to implement or sustain an information system presumes that the profits on this investment will be higher than that of other assets. In this light, a proper information system that meets the organizational requirements should be developed following the core activities of system development: system analysis, system design, programming, testing, conversion, and maintenance.

In this paper, we look at the techniques of gathering requirements; which is one of the activities in the system analysis stage, preceded by the feasibility study. More so, to be able to have an effective information system plan, a company must have a clear understanding of its long-term and short-term information requirements through the incorporation of appropriate methods in determining these requirements. These methods include interviews, questionnaires, observations, document analysis, prototyping, and JAD. Thus, the following sections describe these techniques relative to their appropriate usage and recommend joint interviews as a reliable option for gathering stakeholders’ needs.

Requirements Gathering Techniques

Interviews

This is the most commonly used and generally the most useful fact-finding technique. Interviews are techniques whereby the system analyst collects information from individuals or groups through face-to-face interaction. Sommerville asserts that an interview could be formal or informal. Through this process, the requirement engineering team asks questions to stakeholders about the system they use or develop.

There are several objectives to using interviewing, these include finding facts, verifying facts, clarifying facts, getting end-user involved, identifying requirements, and gathering ideas and opinions. However, using this method requires good communication skills from the interviewer to deal with interviewees who possess different values, priorities, opinions, motivations, and personalities.

In light of this, interviews can be categorized as structured or unstructured. These types of interviews can be used to determine the critical success factors (CSF) of an organization in order to build information systems that deliver information based on the CSFs. In structured interviews; the interviewer provides a specific set of questions to ask the interviewee. For instance, what would influence you? and what will it look like? Depending on the response from the stakeholder, the system analyst will direct questions to obtain clarifications. Alternatively, the unstructured interviews are carried out with only a common objective in mind and with few specific questions. The interviewer approaches the interviewee to provide a structure and direction to the interview. It regularly uses focus but it has the advantage of being flexible.

Interviews mostly rely on the types of questions being asked. The questions can be closed-ended, open-ended, or probing according to the desired response. Closed-ended questions are characterized by the restriction of answers to specific choices. For instance, an answer can be a Yes or No for a question asking for the need for system changeover. For the open-ended questions, the interviewee can respond in any way that he/she seems appropriate. To get more information from the stakeholders, probing questions may be incorporated; the questions contain the terms why, what, who, and so on.

In general, the following are the advantages of using interviews as the technique of gathering requirements:

1. It is an easy method that can be carried out with minimal preparations.
2. Gives the analyst an opportunity to inspire the interviewee to respond freely and openly to questions, thus enhancing the quality of the requirements data.
3. Interviews allow the interviewer to explore more feedback from the interviewee, giving much detail on the old and new information systems.
4. The analyst is privileged to observe the nonverbal communication from the interviewee. This helps in the clarification of the data collected.
5. Interviews permit the system analyst to adapt or reward questions for each individual.

On the other hand, the disadvantages of incorporating interviews in requirements elicitation and analysis are as follows:

1. Interviews are a very time-consuming and costly approach for gathering requirements especially in projects with a large number of stakeholders.
2. The accomplishment of an interview is extremely reliant on the interviewer’s relation skills.
3. Sometimes the interview may be impractical due to the location.

Questionnaires

Questionnaires or surveys are usually administered electronically or on paper although they can be carried out in person (like structured interviews), over the phone, or even on removable disks or websites. A questionnaire is a list of questions, directed at soliciting the requirements of the stakeholders.

This method commonly incorporates closed-ended questions, more than can be successfully applied in an interview, and at times contain open-ended questions as well. In addition, Elliot and Starkings state, “Questionnaires should not involve open-ended questioning. They should be carefully structured to elicit concise and detailed data or information, which in turn must be documented” (p. 68).

Therefore, the ability to create effective questionnaires is a competence that grows with practice and experience. Since the questions are written, they must be extremely clear in meaning and logical in nature. For example, closed-ended questions can be something like this:

How often do you scan your computer for virus threats?

• Frequently (at least once per week)
• Sometimes (from one to three times per month)
• Hardly at all (once per month or less)
• Never

Which operating system do you prefer?

• Windows
• Linux
• MacOS
• Other

From this, an analyst can be able to gather and document the data collected from the questionnaire. Thus the advantages of using questionnaires are:

1. They take less time to complete unlike the interviews which are structured to get the same information.
2. Information can be gathered from many stakeholders in a relatively short time and it is less biased in the result interpretation.
3. It is a good tool to collect statistical preference facts about an information system of a company.
4. Questionnaires require a minimal scheduling effort in discovering the users’ requirements.

However, questionnaires present some disadvantages as a fact-finding technique. These are:

1. The questionnaires are generally less rich in information content than interviews since they provide no direct means to ask follow-up questions. They do not provide the chance to judge the correctness of the responses.
2. Effective surveys require well-trained and skilled personnel to develop.
3. It reflects the analyst’s preconceived ideas and assumptions of the questionnaire designer.

Observations

People are not at all times very dependable informants, even when they try to be trustworthy and enlighten what they believe is the fact. Since people cannot always be trusted to reliably interpret and report their actions, what people tell can be supplemented by watching what they do or obtaining comparatively objective measures of how people behave in work situations. In light of this, Sommerville asserts that observation is one of the most efficient methods for understanding information systems requirements. With this, it is likely to either participate in or watch a person perform activities to learn about the system.

This technique is mainly useful when the validity of data collected through other methods is in question or when the complexity of certain aspects of the system prevents a clear explanation by the end-user.

For example, checking the electronic mail records of an employee may be able to tell you how much he uses electronic mail. An employee might tell you that he is overwhelmed with e-mail messages and that he spends a lot of time responding to those messages. However, if you check electronic mail records, you might find that the employee receives few messages. Another example might be the information obtained from a manager. A manager might tell you that she works for a long and she is careful with a tight schedule in controlling the pace of work. Nevertheless, you can find that the manager’s day is actually punctuated by many interruptions including phone calls and visits.

In general, the advantages of using observations are:

1. The data obtained is highly dependable, since the system analyst performs the observation.
2. The system analyst is able to see precisely what is being done.
3. It is a relatively inexpensive technique as compared to other methods of requirements solicitation.
4. Observations allow the system analyst to do some work measurements.

The disadvantages of observations are:

1. People usually feel uncomfortable when being observed and so many behave strangely. Thus the analyst may still not get the true representation of the system.
2. Activities may take place at an inappropriate time, thus inconveniencing the analyst.
3. The task being observed may involve some interruptions.
4. Some tasks may be performed differently from the way they are observed.

Examining Documentations

Observing users can be enhanced by examining system and organizational documentation to realize more details about current information systems and the organization these systems support. When analyzing a company’s documentation it is important to think about the nature of such documentation, for example, whether the information is in date or out of date, and the integrity of the rules that developed the documentation. It is also important to know that documentation is mainly an indication of what should be happening and not necessarily what is happening in a company.

The types of documents that can be observed include organizational mission statements, business plans, organization charts, business policy manuals, and job descriptions.

The information that can be obtained from these documents includes problems with the existing system, opportunities to new needs if certain procedures were available, the reason why current systems are designed as they are, and the rules for processing data. In this view, the advantages that can be realized through document analysis are:

1. This technique provides wide exposure to all aspects of the current system.
2. More accurate information involving the current system is obtained in relation to the procedures used to build the system.
3. It takes much less time to obtain and examine the documents as compared to questionnaires.
4. The expenses incurred are minimal as compared to interviews and questionnaires.

However, the drawbacks of this technique are:

1. The information richness is quite low since most of the company’s documents are old. The current requirements can be compromised.
2. This method is potentially biased by which documents were kept or because documents were not created for the purpose at hand.

Prototyping

Prototyping is a repetitive practice involving analysts and users in which a miniature or a test version of an information system is built and rebuilt according to user feedback. Prototyping preceded by interviews and collecting documentation, allows the analyst to quickly convert basic requirements into a working, though a limited version of the desired information system. The prototype will be then viewed and experienced by the user, thus generating new requirements.

For example, in the first interviews, a stakeholder might have said that he wanted all significant products billing information on a single computer display form, such as the customer’s name and address, the product record, and the inventory history. Once the same user sees how jammed and confusing such a design would be in the prototype, he might change his mind and opt for a presentation in which the information is organized on different screens. This calls for a redesign of the system, hence prototyping.

The advantages that can be realized through this approach are:

1. Systems requirements are better captured as the system is being developed.
2. It solves the communication problems that may have existed between users and analysts in making sure that the requirements are specific as possible.
3. It involves the user in analysis and design, and thus captures requirements in concrete, rather than verbal or abstract.

On the other hand, the drawbacks of this technique are:

1. Prototypes are mainly developed as stand-alone systems hence ignoring sharing of data and systems interactions.
2. The prototype may be presumed as efficient by the initial user but other users may find it difficult to adapt.
3. There is a trend to avoid outlining formal documentation due to the changing requirements. This may delay the overall system development.

Joint Application Design (JAD)

The main purpose of JAD is to combine users, analysts, and managers involved in the current system analysis. In this regard, JAD is similar to a group interview. However, a JAD follows a specific structure of roles and agenda that is different from a group interview. In essence, JAD involves cooperation between stakeholders and system analysts to elicit needs in an intensive and structured effort.

The sessions involved in JAD are usually conducted in a location other than the working place; this is to keep participants away from any distractions to concentrate on system analysis. In addition, typical participants in this session that lasts from four hours to an entire week may include JAD session leaders, Systems Analysts, Managers, Facilitators, Sponsors, IS staff, and Vendors. Thus the advantages of using this technique are:

1. JAD allows for concurrent elicitation and merging of large amounts of data.
2. The information of high quality is produced within a short period since the participants are focused on analysis.
3. Disagreements are settled down with the help of the facilitator.
4. It provides multiple viewpoints or rather scenarios that provide a framework for discovering conflicts in the requirements suggested by different stakeholders.

The drawbacks of JAD may include the following:

1. Extensive planning and scheduling effort are required to have an effective session.
2. All participants are required to employ a significant commitment of time and effort.
3. The technique requires well-trained employees for facilitation and recording.

Conclusion

The general conclusion that can be derived from this discussion is that a company needs to have a clear understanding of its long-term and short-term information requirements through the incorporation of appropriate methods in determining these requirements. The methods that can be used in gathering requirements include interviews, questionnaires, observations, examining documentation and JAD. From this analysis, any method chosen depends on the way the system is planned and conceived. However, joint interviews are presented as the most suitable technique, since it depicts the corporate business image of the company in line with the budget and time. Other modern techniques such as JAD and prototyping are gaining superiority due to object orientation.

References

1. Elliot, G., and Starkings, S, Business Information Technology: Systems, Theory and Practice, Pearson Education, Essex, 1998.
2. Hoffer, J.A., J.F. George, and J.S. Valacich, Modern Systems Analysis & Design, Prentice Hall, New Jersey, 2002.
3. Laudon, K.C, and J.P, Laudon, Management Information Systems: Managing the Digital Firm, Prentice Hall, New Jersey, 2006.
4. Oregon, Requirements Gathering Techniques, 2001.
5. Sommerville, I., Software Engineering, Addison Wesley, New Jersey, 2004.
6. Schmuller, J.., Teach Yourself UML in 24 Hours, Sams, Indianapolis, 2004.
7. Zhu, Z, Requirements Determination and Requirements Structuring, 2003. Web.