Business Analysis Training Lesson: What are the Four Main Activities of Requirements Engineering?
This sample lesson is part of a series online Business Analysis Training lessons. To enrol for the COMPLETE IREB® CPRE® Foundation Level Syllabus aligned version of this course, follow the link below:
Business Analysis Training Lesson
Welcome! We will be discussing the Four Main Activities of Requirements Engineering. We will however be covering some fundamental concepts about Requirements Engineering first. So sit tight, and enjoy this free sample lesson.
There are 3 fundamental concepts that you must understand before doing any other study. These concepts are that of: What are Requirements? Who are stakeholders and what is their role in requirements engineering? And thirdly, what is the definition of Requirements Engineering?
Now let’s take each of these fundamental concepts one by one.
What is a requirement?
Let me ask you a few questions first. Is getting a coffee every morning a requirement for you? Perhaps having a laptop that works is a requirement for you? What…Is it a requirement that you are paid every month?
Let’s now have a look at the definition of a requirement in the business context.
“A requirement is a condition or a capability needed by a user to solve a problem or achieve an objective …”
Understanding what a requirement is will help you understand who the stakeholders are.
Who are the Stakeholders?
Stakeholders are people or organizations that has some type of impact on our project. For example, Susie from the Human Resources department can be a stakeholder if we are working on a human resources related system or project. In a similar way, we can have John as a stakeholder if he needs to be consulted about his requirements for the financial aspects (such as salary and bonus calculations) of the Human Resources system.
It is important to identify all the different types of stakeholders early on during your project. It is also important to identify the different types of stakeholders. Some stakeholders are called direct stakeholders. These are the people who will be directly impacted by the system or project we are implementing. They can be users of the system or their role in the organization could be affected with the implementation of the new system. There are also indirect stakeholders who need to know what is going on in our project but may not be directly impacted. These types of stakeholders can include people from related business areas or even external parties that need to be considered. An example of an external stakeholder in the context of the Human Resources system would be the Government Policies around employee rights and regulations.
Therefore in summary we can define a stakeholder of a system as a person or an organisation that has an (direct or indirect) influence on the requirements of the system
Now we are getting to the important question: What is Requirements Engineering then?
Requirements Engineering is defined as a systematic and disciplined approach to the specification and management of requirements with specific goals:
Firstly – knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards and managing them systematically.
Secondly – understanding and documenting the stakeholders desires and needs, then specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholder’s desires and needs.
Now that we have covered the fundamental concepts, lets have a look at the four main activities of requirements engineering.
The four core activities to meet the main goals of requirements engineering is as follows:
- Elicitation – this activity
- Validation and negotiation
Lets have a closer look at each of these core activities.
Core Activity 1: Elicitation
Elicitation is all about engaging with stakeholders to elicit and understand their business needs and requirements. There are various different requirements elicitation techniques, which can be applied. Some of these techniques include: requirements interviews and workshops.
Core Activity 2: Documentation
The documentation activity is all about capturing the requirements in a documented format, which will make clear sense to the business stakeholders as well as the technical teams who may need your document. It is important that your requirements are clear, complete and accurate.
Core Activity 3: Validation & Negotiation
This activity is all about ensuring that what you have documented as requirements is valid and agreed by all stakeholders involved. This activity often involves continuous clear communication and negotiation with stakeholders.
Core Activity 4: Management
This final core activity involves managing any changes that might arise in relation to your requirements. It is vital that the requirements engineer learn to manage requirements in a systematic and transparent way to ensure that changes are tracked efficiently and accurately.
The final concept for you to take note of in this part of your course is the concept of “Constraints”. Constraints are those limitations that have an impact on your requirements activities. Constraints can come in the form of people, business rules, domain or organizational constraints. It is important to also document the relevant constraints that you had to work within when you document your requirements.
Great, you have now mastered the core concepts around requirements, stakeholders and requirements engineering. You also learned about the main activities, which you will perform as a requirements engineer.
This lesson is part of a series online Business Analysis Training lessons. To enroll for the COMPLETE IREB® CPRE® Foundation Level Syllabus aligned version of this course, follow this link: