top of page
Writer's pictureKevin Gupta

Stakeholder vs Functional (solution) requirements


There is a strong confusion in the industry as to what is a stakeholder requirement and what is a functional requirement?


Having worked in many industries, I have come across not one, but many stakeholders who struggle to understand the difference. More importantly, some analysts too struggle to understand the difference.


This post hopefully provides clarity on the difference between the two requirement classifications.


Why the confusion?

  1. Willingness to learn or the lack of understanding of what stakeholder and functional requirement actually mean and the purpose they serve;

  2. In most cases, business analysts who are business focused are making an attempt to write functional (solution) requirements (or vice versa) without proper guidance (see the difference between 'Business, Functional, Technical, and System Analyst');

  3. Not enough experience in writing quality requirements;

  4. Most likely the organisation or the mentors are not experienced enough to support detailed and quality requirements; and

  5. Project estimates don't support functional requirements (building on point 4 above).


How many requirement classifications are there?


As per BABOK v3, there are 4 types of requirements (also known as requirement classifications):


  1. Business requirements (Note: many people confuse business requirements with stakeholder requirements. We will explain the difference in our next post)

  2. Stakeholder requirements

  3. Solution requirements that are broken down in two:

    1. Functional requirements (also see: Functional requirements vs System design)

    2. Non-functional requirements (we will explain these in our next post)

  4. Transition requirements


As per BABOK v3, these requirements serve different purposes, and have different meaning. Here is a quick excerpt:


  1. Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.

  2. Functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.


Are they written in different documents?


In most cases, and depending on complexity of the project:

  1. Stakeholder requirements:

    1. Waterfall (or traditional) projects: are written in a Stakeholder Requirement Document (SRD), you may also hear the term 'User requirements'

    2. Agile projects: are written in user story format with a high-level acceptance criteria (or just a description - but this is not detailed to define a solution); and

  2. Functional requirements:

    1. Waterfall (or traditional) projects: are written in a Functional requirement document (FRD) in a traditional project.

    2. Agile projects: Functional requirements can be written in a user story format with detailed acceptance criteria.


So, what is the actual difference?


We have put together a comparison table to assist you understand the difference. Leave a comment below if you would like more details.



The BA Practice specialises in providing ECBA, CCBA, and CBAP courses, and prepare you for the exam. Book your business analysis course with us today.

1 comment

1 Comment


marcel.meerstetter
Nov 28

Thank you for the explanations in this blog. I wish I had come across it sooner. You mention the mistake of confusing Business und Stakeholder Requirements. Does the blog article to this topic already exist? I could not find any but I would be interested in reading it

Like
bottom of page