The Community Blog for Business Analysts

Praveen Udupa
Praveen Udupa

Stakeholder Requirement: Clarified

This is in continuation of my earlier post on Business Requirement. If you have not read that post, I recommend you take a few minutes to study that first before continuing with this post.

In this post, let's discuss Stakeholder Requirement. Some people refer to this as User Requirement, but BABOK's nomenclature is Stakeholder Requirement. Understandably so, because a User (i.e. End User of the solution) is just one type of a Stakeholder. Other Stakeholders, not necessarily Users of the solution, may also have needs that they need satisfied by the solution. 

Stakeholder Requirement describes how a given stakeholder would like to interact with the solution, in the context of a business requirement. 

Let's observe a few points from the above definition of a Stakeholder Requirement:

1.   We already know that Business Requirements must not include the solution. We have discussed this in my previous post. But while defining Stakeholder Requirements, the solution approach must be selected. How else would the stakeholders describe how they would like to interact with the solution?

2.   If the solution approach changes, the Stakeholder Requirements also change (but the Business Requirements do not change)

3.   In the hierarchy of Requirements, Business Requirements are at the top, immediately followed by Stakeholder Requirements. Every Business Requirement gets decomposed into its constituent Stakeholder Requirements. Stated the other way, one or more Stakeholder Requirements trace into one Business Requirement.

4.   Stakeholder Requirements are not at a level of detail for the implementation team to design and develop the solution.


Let’s take an example to understand this better. In my previous post, we had discussed the example of an Insurance Company whose Business Requirement was Ability To Collect Premium Remotely. In order to meet this Business Requirement, there are several solutions possible:

  1. First obvious solution: enable internet and mobile payment
  2. Enable direct debit from the customer’s bank account
  3. Partner with one or more banks and enable the banks to collect the premium
  4. Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
  5. Establish several satellite premium collection centers

Suppose we select the internet solution, i.e. the insurance company builds a website where customers make premium payments. The following would be some of the Stakeholder Requirements:

Customer: Ability for a Customer to view a list of all policies where premium is due

Customer: Ability for a Customer to make a payment for policy where premium is due

Admin: Ability for the Admin to update the list of policies where premium is due for all customers

Stakeholder Requirements form the basis for defining Solution Requirements. One might ask why bother defining Stakeholder Requirements at all, if it is not useful for the implementation team to design the solution. The reason is simple: A top down structured approach will ensure that the requirements coverage is close to 100%, and the probability of missing out on requirements is very low. Besides this, this approach helps minimize scope creep. I will write more about this in subsequent blogs.

This entry was published on May 06, 2016 / Praveen Udupa. Posted in Requirements Analysis (BABOK KA) , Functional Specifications, Business Analysis. Bookmark the Permalink or E-mail it to a friend.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC