Requirement Gathering Techniques

Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake in
the software system development.
• There are various ways to discover requirements

1. Interviews

 Interviews are strong medium to collect requirements. Organization may

conduct several types of interviews such as:

 Structured (closed) interviews, where every single information to gather is

decided in advance (fixed questions), they follow pattern and matter of

discussion firmly.

Non-structured (open) interviews, where information to gather is not decided

in advance, more flexible and less biased. It is like casual conversation where

in-depth areas are covered.

 Written interviews: Which is like structured interview and same as

questionnaires.

 One-to-one interviews which are held between two persons across the table.

One-to-one interviews require some planning and preparation before the

interview and documentation of findings afterwards

 Group interviews which are held between groups of participants. They help to

uncover any missing requirement as numerous people are involved.

• These interviews work well when everyone is at the same level or has the

same role. Group interviews require more preparation and more

formality to get the information you want from all the participants.

 Advantages:

• Can motivate interviewee to respond freely

• More feedback can be probed.

• Can adapt or reword questions for each individual

• Extra info from body movement and facial expression

 Disadvantages:

• Time consuming

• Require good human relation skills

• Require good interviewing skills

• May be impractical due to location constraints

• The interviewee may not answer/ give appointment.

2. Questionnaires

 A document with pre-defined set of objective questions and respective options

is handed over to all stakeholders to answer, which are collected and compiled.

 It is the technique used to extract information from number of people. This

method can be adopted and used only by an skillful analyst

 Questionnaires can be useful for obtaining limited system requirements details

from users / stakeholders, who have a minor input or are geographically remote.

 The design of the questionnaire (whether off line or web based) and types of

questions are important and can manipulate the answers, so extra care is needed.

 Types of questionnaires

 Open respond based questionnaires.

 Close respond based questionnaires.

 Open respond based questionnaires.

 The objective of this is to gather data about critical features of system

 It does not require any specific response

 It is used to learn opinions and experiences of respondents.

 Respondents can answer the questions in their own words.

 Space is provided under each question for the response.

This type of questionnaire is time consuming.

 It should not be over-used.

 Close respond based questionnaires.

 The objective of this is to collect the factual information of system

 It gives close look about the facts that how the people deal with the

system.

 Respondents just have to choose from a given set of responses.

 The closed questions can be of various types:

• Multiple choice questions: It offers respondents with fixed

alternatives to choose

• Rating scale questions :It is similar to MCQs except the

respondents must rate to their satisfaction

• Rank over scaling questions :It requires respondents to priorities

their responses from high to low or on a percentage basis.

• Dichotomous Questions: These are generally “yes/no” questions.

 Advantages:

• Can send to many hundreds of users at a low cost.

• Cheapest method in fact finding techniques.

• Good for attaining information from people who are concerned with the

usage of the system and who are living in different countries.

• Responses can be tabulated and analyzed quickly.

 Disadvantages:

• Questionnaires can be slow to create.

• Cannot observe and analyze the respondent’s body language

• Number of respondents is low.

• Respondent may not answer all the questions.

3. Observation

 Team of experts visits the client’s organization or workplace. They observe the actual

working of the existing installed systems.

 They observe the workflow at client’s end and how execution problems are deal.

 The team itself draws some conclusions, which aid to form requirements expected from

the software.

 Advantages:

• Reliable data.

• Can see ideas for improving processes or removing unnecessary

activities from the new system.

• Allows work measurement.

• Practical Experience.

 Disadvantages:

• Relatively slow.

• Focused on existing processes rather than the new system processes so

delay in development of the new system.

4. RecordView

The information related to the system is published in the sources like

newspapers, magazines, journals, documents etc.

 This record review helps the analyst to get valuable information about the

system and the organization.

 Records may include written policy manuals, rules and regulations, standard

operating procedures used in the system and forms and reports including

documents about the system.

5. Surveys

 Organization may conduct surveys among various stakeholders by querying

about their expectation and requirements from the upcoming system.

6. Task analysis

 Team of engineers and developers may analyze the operation for which the new

system is required.

 If the client already has some software to perform certain operation, it is studied

and requirements of proposed system are collected.

7. Brainstorming

 An informal debate is held among various stakeholders and all their inputs are recorded

for further requirements analysis.

 Brainstorming can be done either individually or in groups.

 The ideas collected can then be reviewed / analyzed and where relevant included within

the system requirements.

 Ideas can come from what users / stakeholders have seen (eg at software exhibitions), or

experienced to a difference places.

 Advantages:

 Can come up with very innovative ideas and requirements.

 It can be an efficient way for users / stakeholders to define their requirements.

 Disadvantages:

 People can’t easily brainstorm ideas when required to do so.

 Some people find brainstorming much harder than others.

8. Prototyping

 Prototyping is building user interface or prototype without adding detail functionality

for user to interpret the features of intended software product.

 It helps giving better idea of requirements.

 The client is not aware of its own requirements; the developer creates a prototype based

on initially mentioned requirements.

 The prototype is shown to the client and the feedback is noted. The client feedback

serves as an input for requirement gathering.

 Advantages:

 Good for exploring how a particular software function requirement could work.

 It can identify problems with requirements and can improve the quality of

requirements and get the ultimate solution.

 More relevant for the final detailed software selection.

 Disadvantages:

It is less useful for the initial requirements identification for a packaged software

system.

 Prototyping is not really suitable for large applications.

 It can be an expensive technique for identifying requirements.

 Recording outcome:

 When interview results, tabulated questionnaires, and the experience through

personal observation are prepared the analyst is ready to describe the current

system in narrative form.

 With either DFD or System flowchart.

 He also uses :

• Data dictionary

• Process specifications

• Decision tables

• Decision trees

• ERDs

 An analyst always gets facts from documents.

 An existing system can be better understood by examining existing documents,

forms and files.

 This record review can take place at the beginning of the system study or

later in the study for comparison.

 Records may include

• Written policy manuals

• Rules and regulations

• Standard operating procedures used in the organization

• Forms and documents

 The following questions may be useful in analysis of forms:

• Who uses these forms?

• Do they include all necessary information?

• How readable and easy to follow is the form?

• Is it ideal for analysis and interface? Etc.