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:
- First obvious solution: enable internet and mobile payment
- Enable direct debit from the customer’s bank account
- Partner with one or more banks and enable the banks to collect the premium
- Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
- 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.