Requirements Elicitation: The First Step of Product Requirements Engineering

Editor’s note: the following was written by a guest blogger. If you would like to contribute to the blog, please review the Product Blog contribution guidelines and contact [email protected]

It is needless to say that one of the core skills needed for becoming a professional and valuable product manager is Requirements Engineering.According to IREB CPRE-FL Glossary, Requirements Engineering is a systematic and disciplined approach to the specification and management of product requirements with the following goals:

1. Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards, and managing them systematically.

2. Understanding and documenting the stakeholders’ desires and needs.

3. Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs.

The concept of Requirements Engineering refers to the process of defining,documenting, and managing the requirements of software products. Requirements engineering is a common concept in system engineering and software engineering, which was later discussed and implemented in the Product Management concept. Requirements Engineering includes requirements elicitation, requirements documentation, requirements validation, and requirements management.

Doing these activities precisely, helping product managers to extract the real needs and provide valuable pain-relievers and gain-creators for the end-users. In this blog, we are going to get familiar with the requirements categorization, the first step of product Requirements Engineering, and typical requirements elicitation techniques.

Requirements Categorization

The Kano model is a famous approach to categorize product requirementsbased on stakeholders’ satisfaction. Satisfaction plays a crucial role inrequirements elicitation and product managers should keep it in mind as an important factor during the requirements elicitation process. According to the Kano Model, satisfaction is classified into three categories:

Dissatisfiers: These are basically the properties that the product must have in order to meet customer demands.Satisfiers: These are explicitly demanded product properties.Delighters: Includes properties that stakeholders don’t know anything about them and they are a pleasant and valuable surprise.

What is the Requirements Elicitation

Requirements Elicitation is a core activity of almost all product management processes and approaches which is considering for the elicitation of specific product requirements. In other words, the first step of product Requirements Engineering is to examine the problem space and extract the right and real needs (not the ones we assume are probably needed by users and customers).

Without any exaggeration, the most important phase in software product management is the proper elicitation of the real needs of those who are going to use your product in the future. In order to have a successful elicitation experience, product managers need to know the key sources for doing this activity during their projects. Stakeholders, documents, and current products are three requirement sources that can provide many useful data such as previous experiences, pains, gains, and current functionalities for product managers. Stakeholders are the people who have a direct or indirect influence on the product.

They are fantastic resources for eliciting current pains and also their future desires in regards to the product. Documents are other great sources for eliciting related requirements. Examples of documents are technical documents, marketing documents, business development documents, or other enterprise and market-related documents. that are available for product managers.

Finally, current products or the competitors’ products are valuable requirements sources for product managers in order to elicit dissatisfiers and satisfiers requirements. These types of requirements are the ones that must be fulfilled by the product (dissatisfiers) and also explicitly demanded (satisfiers).

What Are the Requirements Elicitation Techniques

In order to professionally eliciting requirements from related sources, product managers need to use certain techniques based on the product context and its related circumstances. The major reason behind elicitation techniques is gaining product domain knowledge and also determining product requirements and their importance level.

There are many techniques that can help product managers to elicit the real needs and desires of the stakeholders and it is the product manager’s responsibility to choose the compatible and fit for purpose techniques based on the context and circumstances. Some of the requirements elicitation techniques are:

1. Survey Techniques: Using these techniques, product managers are able to gain the required knowledge related to the end-user as-is status, current product experience, the most important pains, and also the domain knowledge. These techniques are very useful when stakeholders can explain requirements explicitly and clearly. Examples of the related techniques include UX qualitative/quantitative interviews and questionnaires.

2. Observation Techniques: Almost all of us as product management practitioners faced with stakeholders that unable to explain their opinions, experiences, and requirements clearly in our previous projects. Whenever you are dealing with these types of stakeholders, it is better to use observation techniques. These techniques help you discover current processes and procedures, pain points, improvement opportunities, and current functionalities. As the product manager is the external observer, he/she is able to identify gaps and opportunities in the current processes and procedures and has a chance to offer a better solution. Examples of the observation techniques are field observation and apprenticing.

3. Creativity Techniques: If you are going to elicit delighting requirements for your product, creativity techniques are the best way for it. These kinds of techniques help product managers to elicit an abstract level of delighting and innovative requirements and consider them as a surprising factor for product end-users. Examples of creativity techniques are Design Thinking (the Problem Space), Design Sprint (the Problem Space), brainstorming, and change of perspective.

The Last Word

There is a famous assumption in software product management which focus on this sentence:

““Users don’t know what they want till they are able to work with the software product.””

This is really scary for product people and business practitioners. This assumption shows us that if people tell the PM that they want or need something, the PM should not 100% sure that this is their real requirements please keep in mind that almost always people try to describe their requirements with the solution-based statements.

Here, there is an important responsibility for the PM to guide them through their current experience and elicit their needs, pains, and desires and determine their requirements types. In this case, the product manager can professionally elicit requirements from key sources including stakeholders, documents, and current products.

Remember that requirements elicitation is not just discussing with stakeholders and write down whatever they say. It is all about negotiating with them, guiding them professionally through their as-is experience, capture what they say, and use our analytical approach in order to remove the irrelevant aspects and also use relevant ones in order to deliver a product that is going to delight them in the future.

Meet the Author

Aidin Ziapour is the IREB Certified Professional for Requirements Engineering. Aidin is a product management expert, enterprise Design Thinking coach, and Design Sprint master who has experience working with several famous corporations and brands as a coach/consultant such as System Group, Axel Springer and Porsche, and Amazing Design People List.