Home / BA / what is Requirements, Types of requirements and what are different elicitation Techniques ?

what is Requirements, Types of requirements and what are different elicitation Techniques ?

what is Requirements:

A Requirement is Basically Need of the client. The Need or Requirement will transform into a solution while taking various shapes and forms as it processes from each stage of SDLC. Requirements serve as a foundation of systems or system components. A requirement comes from various demands or obligations. A property that is essential for a system to perform its functions. Requirements vary in intent and in kinds of property. They can be functions , constraints ,or other than elements that must be present to meet the needs of the intended stakeholders. The Requirement can be described as a condition or capability a customer needs to solve a problem or archive an objective. A Descriptor should always precede requirements like business requirement, functional requirement, user requirement. The Statement provided by the stakeholder to solve a particular business problem or respond to a specific business need is known as Requirement. Once the Requirement has been raised by the stakeholder then the BA will further define, analyze, validate and prioritize the requirement statement as it now included within the BA context of requirements management.

Types of Requirement:

Business Requirement
Stakeholder Requirement
Solution Requirement
Functional Requirement
Non-Functional Requirement
Transition Requirement

Business Requirement:

Business Requirements are high level statements of the goals, objectives or needs of the enterprise.
They describe the reasons why the project has been initiated, the objectives that the project will achieve and the metrics that will be used to measure its success. Business Requirements describe needs of the organization as a whole not as a group or stakeholders within it. They are developed and defined through enterprise analysis. They are high level statements describing what is required from the business perspective.

Stakeholder Requirements:

Stakeholder Requirements are statements of needs of a particular stakeholder or class of stakeholders. They describe needs that a given stakeholder has and how that stakeholder will interact with the solution. They serve as a bridge between the business requirements and the various classes of the solution requirements. They are developed and defined through requirement analysis. As a business analyst we need to guard against the requirement statements at this early stage of the project, which describes how to deliver the requirements.


Requirements of stakeholders:
To build a house with two separate bedrooms.
Houses need to be protected from fire.
Each bedroom needs to have a separate bathroom attached.

Solution Requirements:

Solution Requirements describes the characteristics of the solution that meet the business requirements and stakeholder requirements. They are developed and defined through requirement analysis. They are divided into subcategories when the requirements describe the software solution.
The solution requirements describe how stakeholder wants to implement their stakeholder requirements. It is important to capture all requirements but it is also important to validate and ensure that all stakeholders are in agreement about which requirements are in fact valid.


I want my room to be painted with a pink color in my bedroom.
Every bedroom must have an air conditioning unit implemented.

There are two types of Solution requirements:
Functional requirements.
Non-Functional Requirements.
Functional Requirements:

Functional Requirements describe the behavior and information that the solutions will manage. They describe the capability of the system to be able to perform in terms of behavior or operations, specific information technology applications actions or responses. This solution requirement is about what you want the system to be able to do. This type of solution requirement describes how the solution must behave. In the Agile project it is referred to as a user story.

Non-Functional Requirements:

They capture conditions that do not directly relate to the behavior or functionality of the solution but rather describe the environmental conditions under which the solution must remain effective or qualities that the system must have. They are known as quality or supplementary requirements. These include requirements related to speed ,capacity, security ,availability and the information architecture and presentation to the user interface.

Transition requirement:

Transition requirement describes a requirement that must be placed for a certain phase or period.
It describes the solution must have an order in order to facilitate transition from the current state to the desired future state of the enterprise, but that will not be needed once that transition is completed. They are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined. They typically cover data conversion from existing systems, skill gaps that must be addressed and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation.


Different elicitation Techniques :
* Stakeholder Analysis
* Brainstorming
* Document Analysis
* Reverse Engineering
* Focus Groups
* Observations
* Workshop
* Interview
* Prototyping
* Questionnaire

Stakeholder Analysis:

Stakeholders can include team members, customers, any individual who is impacted by the project or it can be a supplier. Stakeholder analysis is done to identify the stakeholders who will be impacted by the system.


Brainstorming can be done individually or in groups. The ideas collected can then be reviewed, analyzed and where relevant included within the system requirements. This technique is used to generate new ideas and find a solution for a specific issue. The members included for brainstorming can be domain experts, subject matter experts. Multiple ideas and information give you a repository of knowledge and you can choose from different ideas. This session is generally conducted around the table discussion. All participants should be given an equal amount of time to express their ideas. Ideas can come from what users , stakeholders have seen or experienced elsewhere.

Can come up with more innovative ideas and requirements.
It can be a more efficient way for users and stakeholders to define their requirements.


People cannot easily Brainstorm ideas when required to do so.
Multiple duplicate ideas given.

Rules for brainstorming:

Time limit should be performed.
Identify the participants in advance. One should include 6-8 members for the session.
The agenda should be clear to the participants.
Once we received all the information, remove the duplicates and combine the ideas.
Document Analysis:

We may have documents about your current system which could provide some of the input for the new system requirements. Such documents, if it exists, could include interface details , user manuals and software vendor manuals.


Could be a lot of information and easy to transfer to a new system requirements document.
Existing documents can be used to compare current and future processes. Existing documents can be used as a base for future analysis.


Existing documents may be old and out of date.
This is a time consuming process.
Existing documents might not be updated.
Resources worked on the existing documents might not be available to provide information.
Reverse Engineering:
In this situation where the software for an existing system has little or outdated documents and it is necessary to understand the system actually does, in this elicitation technique that can extract implemented requirements from the software code. They are of two types:
Black box reverse engineering
White box reverse engineering
Black Box Reverse engineering:
Studying the product without examining its inner structure and functions.
White Box Reverse engineering:
Inner working of the system/product are studied.
Focus Groups:
By Focus group, we can get information about the product, service from a group. Focus includes subject matter expert. The objective of this group is to discuss the topic and provide information. A moderator manages this session. A focus group has 6-12 attendances. It is necessary to invite twice as many individuals to avoid no shows. If the topics are new we need to include experts .
Individuals with similar characteristics.
Caution: Differing perspectives will not be shared.
Possible Solution: conduct separate sessions for different Homogeneous groups.
Individuals with diverse backgrounds, perspectives.
Cautions: Individuals may self censor if not comfortable with others background resulting in low data collections.
Observations is to understand the activity, task, tools used, and events performed by others.
The observer will get a practical insight into the work.
Improvement areas can be easily identified.

Participants might get disturbed.
Relatively slow, focused on existing systems rather than the new system processes.
Active Observation:
In this Observation is to ask questions and try to attempt the work that other persons are doing.
Passive Observations:
This is a silent Observation. Sit with others, just observe what they do in their process, do not interpret them. We need to wait until the entire process gets completed before asking questions.
Workshops can comprise 6-10 or more users/stakeholders, working together to identify the requirements.
Workshops tend to be in a defined duration, rather than outcome and may need to be briefly repeated in order to clarify or obtain further details.
Faster than group interviews to gather requirements .
More preparation is needed. Running or facility workshops requires more skill, and needs an extra IT person to record details and requirements.
JAD(Joint Application Development):
JAD technique is an extended, facilitated workshop. It involves collaboration between stakeholders and the system analysts to identify needs or requirements in a concentrated and focused effort.
Documentation is completed within hours and is provided quickly back to participants for review.
We can get on the spot confirmation on requirements.
Consensus can be achieved as issues and questions are asked in the presence of all the stakeholders.
Stakeholders not available during the session.
Workshop motive cannot be achieved if there are a lack of participants.
Success rate depends on experts of the facilitator.
Interviews of users and stakeholders are important in creating software.
We need to know the expectations and goals of users and stakeholders to satiate them.
Listening is a good quality of Interviewers to gather more information about the requirement .
In this method the interviewer directly questions the stakeholders to obtain information, it’s like one to one interview.
If the interviewer has a predefined set of questions it is called structured interview.
If the interviewer does not have any particular format or specific questions it is called an unstructured interview.
Open ended questions are used to provide detailed information.
Closed ended questions can be answered in Yes or No to get the confirmation on answers.

Interactive discussion with stakeholders is an opportunity to explore or clarify topics in more detail.
Time is required to plan and conduct interviews. Commitment is required from all the participants.
Prototyping is used to identify missing or unspecified requirements. In this technique, frequent demos are given to the client by creating the prototypes so that client can get an idea of how the product will look like. Describe the process using diagrams. Prototypes can be used to create a mock-up of sites. Stakeholders can provide feedback early. Gives a visual representation of the product. This is a highly complex and time-consuming process.
Questionnaire has set of questions is given to stakeholders to quantify their thoughts. Types of Questions and designs of Questionnaire are important and can influence the answers and so care is needed.
Can send to many hundreds of users at low cost. Getting input from users who are from a long distance.
Questionnaire can be slow to create. We may not get response from many users in filling the questionnaire is often a low priority.

About S Arun

Check Also

What is BRD? How is it different from SRS?

BRD stands for Business Requirements Document, whereas SRS stands for Software Requirements Specification. Both documents …

Leave a Reply

Watch Dragon ball super