In any business analysis, requirements that describe the needs or problems of the stakeholders in achieving or supporting their goals — whether related to organizational or operational concerns — are stakeholder requirements.
Just as stakeholder needs and business needs look alike, stakeholder requirements look an awful lot like business requirements. Stakeholder requirements define decisions about business needs, goals, and objectives — just as business requirements do — but from the perspective of the stakeholders and their role in the business.
Stakeholder requirements are often just called business requirements because they are business requirements for a particular stakeholder. However, calling them business requirements may lead you to fail to isolate the true business requirements for the enterprise, which may result in your not identifying critical project or solution objectives in the process.
You can see that stakeholder requirements, being the layer of requirements between the business and solution requirements, relate to both contexts. On one hand, stakeholder requirements define what functions the stakeholder performs (or will perform in the future) and what he’s responsible for. On the other hand, stakeholder requirements are also related to the solution:
After the problem and potential solution become clear, they define each stakeholder’s potential interaction(s) with a solution, including the solution objectives, success, and acceptance criteria from the perspective of the stakeholder.
How to use stakeholder analysis to identify stakeholder requirements in business analysis
Prior to or during the elicitation and identification of stakeholder requirements, you perform stakeholder analysis in order to identify the stakeholders and understand their different characteristics.
Information captured during stakeholder analysis may include the organizational positioning of a stakeholder and his level of influence and attitude (either within the business in general or with respect to the solution); his readiness for change; and his interest in the outcome of the project and solution.
Stakeholder analysis information, together with the stakeholder requirements, provides a starting point for designing or modifying the solution, especially any automation aspects of the solution. Get stakeholders to clarify which of their requirements are, in fact, suggestions and which conditions or capabilities are so important that their needs wouldn’t possibly be met without them; stakeholders must identify what is truly required for a successful solution.
The information gathered during the stakeholder analysis is also often called stakeholder requirements. In fact, the word requirements becomes the catch-all term for any information gathered during the business analysis process, which is why working on requirements is challenging and can trip up even the best of analysts.
How to address conflict between stakeholder requirements in business analysis
Different stakeholders can provide different objectives and success or acceptance criteria for the same solution! As a result, stakeholders may identify individual requirements that unintentionally conflict when viewed in light of the overarching business objectives. Stakeholders have individual goals and objectives, but they still must collaborate to meet common business goals and drive the business. They sometimes lose sight of this fact, and it’s your job to remind them.
Sometimes what’s best for the business overall may not be best for stakeholders individually, so you must influence stakeholders’ understanding so they can come to consensus on requirements. Solving these conflicts provides opportunities for innovation, improvement, and business benefit.
You create solutions from the requirements of many people, which means you may sometimes have to consider trade-offs and evaluate which stakeholder gets the most benefit or suffers the most risk.
To do this task, you and your team need to understand all the important factors while defining the business/stakeholder needs but before deciding which of these needs merit being bumped up to a requirement. Otherwise, several consequences may occur:
Stakeholders may feel as though they didn’t have a say in the plans or priorities; if they feel you weren’t listening, going forward, they may raise concerns later in the process than is helpful and may not buy in to important decisions.
If stakeholders aren’t ready for impacts in their domain, they may end up lacking features or funding they need to transition.
Team members may feel frustrated and overloaded at having to accommodate new requirements as they pop up, leading to missed deliverables, deadline or staffing challenges, and lack of time to plan or manage communications.
