Requirement Gathering Techniques.

Before starting with techniques of gathering requirements, let us understand what is Requirement and its types.

What is Requirement?

- A capability that an intended product/software must possess to satisfy the         customers need, objective and goals. Requirement is ‘What’ system should         do (functioning of the system), ‘When’ it should perform those functions and       ‘How’ the system should behave i.e. what and how system should behave in        different conditions.

- A key component of any business project which provides objective ways to         measure the project’s success. 

Types of Requirements:

• Business Requirement: 

- A High-level requirement defining the business’s objectives, goals and vision. 

- Providing the scope of a business need or problem that needs to be addressed    through a specific activity or project.

- Must be defined clearly at high-level.

• Functional Requirement: 

- A detailed breakdown of the Business Requirements explaining how the              system outcome of a project will operate to meet the specified business              requirements.

- It is basically the series of steps that different users will take in the new             system.

• Technical/ Non-functional Requirement:  

-  Pertains to the technical aspects that your system must fulfill, such as                 performance-related issues, reliability issues, and availability issues. 

- Also called as service level requirements or quality of service (QoS)                    requirements.

You can also categorize requirements as:

• Conscious Requirements: stakeholder knows the requirement.

• Unconscious Requirements: stakeholder knows the requirements and thinks it    is obvious and need not have to explicitly mention it. 

• Undreamed requirements: stakeholders does not ask for, either because they think they are not possible or they are new ideas that have occurred to them.

Techniques to Gather Requirements:

When it comes to business requirements gathering, various techniques are available and each technique has its own merits and demerits. Commonly used techniques are:

1 Questionnaires

Questionnaires are much more informal, and they are good tools to gather requirements from stakeholders (dozens/hundreds/ or thousands of people) across geographical areas or those who will have only minor input into the overall requirements. It has a series of questions which helps eliciting information from users. 

Survey- is one of the types of questionnaire. It insists the users to choose from the given options i.e. YES/NO, Agree/Disagree or ratings. A well designed survey gives a significant amount of focused data in a short period of time. It should not be utilized for prioritizing of requirements or features.

 

2 Interviews

One of the commonly used techniques where you have zero chances to satisfy the stakeholders and users’ needs if you do not know their expectations and goals. You also have to understand the perspective of every interviewee, in order to properly address and weigh their inputs. Good Listening skills is the key to get the best results by using this technique.

3 Focus Group & Workshops

A focus group is actually gathering of people who are customers or users representatives for a product to gain its feedback about opportunities, needs, and problems to determine requirements or it can be collected to refine and validate the already elicited requirements. It reveals a wealth of detailed information and deep insight.

Workshops are popularly known as JAD or joint application design and can be efficient for gathering requirements. These are more organized and structured than a brainstorming session where the involved parties get together to document requirements. A workshop with two analysts is more effective than one in which one works as a facilitator and the other scribes the work together.

4 Observation

It covers the study of users in its natural habitat i.e. you work with the user as Shadow. By watching users, a process flow, pain points, awkward steps and opportunities can be determined by an analyst for improvement. Observation can either be passive or active.

• Passive observation- provides better feedback to refine requirements 

• Active observation- works best for obtaining an understanding over an existing   business process.

5 Document Analysis- studying Documentation

Evaluating the documentation of a present system can assist when making AS-IS process documents and also when driving the gap analysis for scoping of the migration projects. Chunks of information are mostly buried in present documents that assist you in putting questions as a part of validating the requirement completeness.

As per the ‘BABoK (Business Analyst Body of Knowledge)’, additional techniques are: 

1 Interface Analysis

Interface for any software product will either be human or machine. It is an elicitation technique that helps to identify interfaces between solutions/applications to determine the requirements for ensuring that the components interact with one another effectively i.e. requirements needed to integrate software into its new environment.

2 Prototyping

Prototyping can be very helpful at gathering feedback. It comprises of collecting the requirements and building a prototype. It gives an idea to the user about how their system will work and look like and based on the feedback received you can improve the system by adding/amending the requirements on iterative basis until users finalizes it.

3 Brainstorming

It is utilized in requirements elicitation to gather good number of ideas from a group of people. It is used in identifying all possible solutions to problems and simplifies the detail of opportunities. In short, it is all about:

• Idea generation and

• Idea reduction and voting

4 Reverse Engineering

When you do not have the documentation available with you for an existing project then you review the source code to figure out what actually is happening and is called ‘Reverse Engineering’. It will not determine what thing(s) went wrong with the system and what a system must do.

Conclusion: 

You cannot use a single technique to gather the requirements for a project. It is always a combination of multiple techniques. Therefore the usefulness of a technique is determined by its need and the kind of advantages it offers in a particular project.

Asshima Cheetal is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, She actively contributes to the areas of Technology and Information Security. She can be contacted at:aashima.cheetal@spluspl.com