Business Analysis Training Lesson: What are the sources of Requirements Elicitation and who are the Stakeholders?
This lesson is part of a series online Business Analysis Training lessons. To enrol for the IREB® CPRE® Foundation Level Syllabus aligned version of this course, follow this link:
ENROL NOW
Business Analysis Training Lesson
Welcome! We will be discussing the What are the sources of Requirements Elicitation and who are the Stakeholders?
What is Requirements Elicitation?
Let’s first look at what does requirements elicitation mean? Requirements elicitation is when a requirements engineer finds out what the requirements are for a new system or business initiative. In most cases, requirements elicitation involves understanding, discussing with stakeholders, researching and analyzing current systems and processes to get a view of what the requirements are for the new system or business initiative.
Three kinds of requirements sources
There are 3 different kinds of requirements sources that a requirements engineer can tap into when planning their requirements elicitation activities. These are:
- Stakeholders
- Documents
- Systems
Stakeholders
Stakeholders are people or organizations that influence the requirements for a new system or business initiative. Their influence can be a direct or indirect influence. Examples of stakeholders are: business users of the existing system, business managers who manage the current system, software developers, customers of the organization you are implementing the system for or government or regulators. There are countless examples of the different types of stakeholders that could play a part in a new system implementation or project.
Documents
Documents can take the form of any material that exist that could assist the requirements engineer in understanding what the requirements could be for the new system or project. Document examples could include: government legislation, compliance rules, organizational policies that must be adhered to or even just existing procedural manuals that could assist the requirements engineer in understanding more about what requirements exist for the new system or project.
Systems in operation
Often a new project is looking at replacing or improving a current system. The current system can be a huge help to the requirements engineer and key stakeholders in their work to define the requirements through the elicitation process. The existing system should always be considered in requirements elicitation activities whenever it is available and accessible to the requirements engineer. It can potentially contain a wealth a requirements, which must be included for the new system too.
Stakeholders are in most projects the most important source of requirements but also the most variable source to manage. We will now look at some aspects for the requirements engineer to consider when using the source: Stakeholders.
Why are stakeholders such an important part of requirements elicitation activities?
The stakeholders are the people who will be impacted in some way by the new solution or initiative that is being worked on and therefore they have a right to participate in what and how the new solution or initiative will be delivered. The higher the impact the new solution or initiative will have, the more involved the stakeholders should be when eliciting the requirements.
Let’s have a look at the following metaphor:
Consider the nice comfortable car you drive to work every day. If you used this car every day to get to and from work, would you like to have a say in the process of replacing or changing the car? Of course you would! You would be quite upset if other people decided on your behalf that your car is being changed to a bicycle because it works out cheaper, wouldn’t you? At the same time, you wouldn’t want to start driving a bus to work just because others believe that you can pick up more people along the way?
This is a very simple but clear metaphor of explaining why it is essential to involve the people in the organization who will be affected by the change you are planning to implement. And this is essentially why you must ensure you have the right stakeholders involved during the requirements elicitation process.
Consequences
Consequences of not involving the appropriate stakeholders during the requirements elicitation process could include high costs to the project in the form of change requests later down the track. This can cause a lot of negative repercussions and ultimately to the failure of the new system or initiative.
Stakeholder Matrix
A Requirements Engineer or Business Analyst should create a comprehensive Stakeholder Matrix early on in the requirements elicitation process. This stakeholder matrix should outline the following:
Who is each stakeholder in the organization?
- Stakeholder Role: This includes not only their name and role but also which part of the organization they are from.
- Availability & Location: The stakeholder matrix should also show the geographic availability of a particular stakeholder, their relevance or level of impact and their expertise.
- Influence: It is also essential to list the stakeholder’s goals and interest in the project to be in a position to rate them in terms of power & influence in relation to the project.
Stakeholder Engagement during the requirements elicitation process
It is important to continuously monitor and engage your requirements stakeholders during the elicitation stage and in fact the complete duration of the project. By continuously updating and keeping your stakeholders fully engaged could turn stakeholders from being simply affected by the project change into active collaborators and supporters of the project. If you don’t pay your stakeholders enough attention they may end up being negative about your project and therefore hinder progress.
Other reasons why you should look after your stakeholders well
People may be satisfied with their current legacy system and not see why it is important to change. They could potentially be afraid of the changes that will follow the implementation of a new system and fear that their roles might be negatively impacted. As the requirements engineer you get the opportunity to work with these stakeholders from early on during the project and should work hard at communicating the benefits the new planned initiative will bring and this way help to engage the stakeholders effectively. Often people are afraid of things that they don’t understand and therefore if you are able to explain to them what the change is all about and how it could benefit them or the organization.
Communication Structure
When you start to work on larger projects with many stakeholders involved, it is a great idea to establish some formal processes within the project around how requirements related communication should take place between the project team and the stakeholders. Here are some roles and responsibilities for the requirements engineer:
Responsibilities of the Requirements Engineer
As the requirements engineer you speak the language of the stakeholders and become familiar with their domain or subject matter area. You are responsible to document the stakeholder’s requirements appropriately and build a relationship with the stakeholders. You are also responsible to facilitate opportunities for the stakeholders to provide input and feedback around what functional and qualitative requirements they have for the new system or initiative.
Responsibilities of the Stakeholders
The main responsibilities of the stakeholders are to provide you with their requirements, support you in understanding their subject matter area, make timely decisions as well as support the activities around prioritization of requirements. A good supportive stakeholder will provide the requirements engineer with timely feedback and communicate requirements as they occur by following the agreed change management process.
Requirements elicitation centres on eliciting information from various different sources in order for the requirements engineer to have a complete picture of what the true requirements are for the new system or project initiative. One of the most important sources is the stakeholder and it is important for the requirements engineer to manage and build strong stakeholder relationships during the requirements elicitation phase of the project.
This lesson is part of a series online Business Analysis Training lessons. To enroll for the IREB® CPRE® Foundation Level Syllabus aligned version of this course, follow this link:
