9 Principles of Requirements Engineering Philosophy: A Business Analyst’s Guide

Hi everyone, my name is Volodymyr Sklyar; I am a Business Analyst (BA) at Artkai tasked with pre-sales, discovery work, project requirement formulation, and internal process optimization. I would like to discuss the International Requirements Engineering Board's (IREB) materials related to the requirements engineering (RE) principles and procedures in this article. Let's touch upon the IREB's stance on the RE, mastering which can enhance any business analyst's professional level regardless of whether you plan to apply for an IREB certificate or not. 

Introduction to IREB 

There's hardly any business analyst ignorant of the IIBA certification on BABOK proficiency. However, much fewer analysts consider certification by IREB – an entity offering the Certified Professional for Requirements Engineering (IREB) certificate since 2006. This means that not all BAs familiarize themselves with relevant RE documentation. 

CPRE includes three levels (Fig. 1): Foundation, Advanced, and Expert assigned to business analysts on two aspects: RE@Agile (RE methods used in Agile) and RE as such.

Figure 1. Scheme of CPRE Certification by IREB

The IREB materials are constructed around the CPRE certification levels, with their structure covering: 

Here I discuss not all IREB documents but only a fragment of the Handbook for the CPRE Foundation Level according to the IREB Standard, namely its Chapter 2, "Fundamental Principles of Requirements Engineering," covering the general principles of RE. I believe it's exactly what a BA should consider every time in the decision-making process; these principles may serve as a roadmap, or compass, of BAs' professional activities. Moreover, RE principles universally apply to all tasks, activities, and business analysis practices. 

After that, I analyze the principle, so the discussion is structured as follows: principle's definition >> review of instruments for its practical application >> use cases illustrating the principle. 

Principle #1 Value Orientation

Requirements are a means to an end, not an end in itself.

EXPLANATION 

The requirement's value is its benefit, or degree of contribution it makes to create a successful product (I'll use the term' product' from now on to denote a software product, which is synonymous to software) and reduce the risk of costly errors that result in extensive revisions or critical use problems, minus the cost of the requirement's identification, validation, documenting, and management. The value may also be estimated in terms of the requirement's ability to reduce development and operational costs. 

This way, RE should maintain the balance between the benefits of requirements management and the process's overall cost. Saving costs on RE increases future risks, but the cost-saving effect of RE is indirect and escapes precise estimation. In general, optimal RE expenditures depend on the project's type and risks stakeholders are ready to tolerate. The higher the tolerated risk, the less effort is required for requirements formulation, and vice versa.  

PRACTICAL USE TOOLS 

Each requirement's importance can be evaluated from the viewpoint of its impact on the product (or the impact of this requirement's omission) and its perceived value for stakeholders. This way, we get a 2x2 grid (Fig. 2). This grid helps position the requirements and determine whether the project needs a business analyst. A simple typical product may do without requirements writing overall.

Figure 2. Stakeholder power/requirement's impact grid

When evaluating the requirement's impact, you should consider the following impact factors: 

USE CASE

One of the projects for Artkai's client on which I worked offered the following use case for this principle. We had a relatively picky client without a clear vision of their future product and with poorly formulated product management processes. Our team tried to develop the product's initial requirements and design its UI to get quicker approval and speed up the development process. 

The ordered system was large-scale and complex, so we collected the requirements via lengthy interviews and discussions, produced demos, received new inputs and insights from stakeholders, revised what was done, and moved on to the next demo; the work went on this way for several months. 

At some stage, the process lost value for the client, as the multi-iteration process of the future products' feature discussion did not move them closer to the product's creation. Though we worked on all revisions in line with the client's wishes and implemented all minor details, the client left one day.

This case is a vivid illustration of work on the requirements for the requirements' sake without ongoing monitoring of their value. The team should have evaluated the impact and importance of every requirement, concentrating on the most critical ones. Otherwise, the client did not feel the progress and did not see the outcome of their investment in terms of the project's progression. Another takeaway for our team was the counter-productivity of following the client's non-effective processes.  

Principle #2 Stakeholders 

RE is about satisfying the stakeholders' desires and needs 

EXPLANATION 

This principle seems not to require extended explanations as all business analysis and project management canons emphasize the significance and necessity of working with stakeholders. The latter are the source of project requirements, and besides that, RE is impossible without engaging the right people in relevant roles. 

PRACTICAL USE TOOLS 

The main tool for this principle's implementation is the well-known "Power-Interest" or "Power-Influence" grid. You can create personas for the grid's fields with several closely related stakeholders, which is also a famous RE tool. Another option is to combine the stakeholder grid with the "stakeholder power – requirement's impact" grid described in the previous section. 

A stakeholder grid should be present in every project. If a business analyst is assigned to a project without a stakeholder grid, it should become their top-priority task. 

USE CASE

Many cases can illustrate the importance of collaboration between developers and stakeholders as a project's success prerequisite. Let's get back to the case I discussed in principle #1: one more mistake of our team was neglect of the stakeholders' power and interest. That's why all expectations voiced by the client's representatives were processed and implemented equally, without appropriate prioritization. 

Principle #3 Shared Understanding

Successful systems development is impossible without a common basis 

EXPLANATION 

Since the project's development involves a team of programmers and stakeholders on the client's side, an optimal situation presupposes that all project participants are on the same page with understanding the problems being resolved and the requirements resulting from those problems. This understanding comes in two forms: 

To optimize resources spent on the formation of shared understanding, you should concentrate on the most relevant aspects (most of which are context-grounded, see principle #4). Besides, you should strike a balance between using explicit and implicit understanding. This becomes possible if you analyze the so-called enablers and obstacles of shared understanding.

Enablers include: 

Obstacles to shared understanding are as follows: 

The higher the risk and impact of flawed shared understanding and the higher the enablers' dominance over obstacles, the more you can rely on implicit shared understanding. And vice versa, the fewer enables and the more obstacles you face, the higher the risk of misunderstanding in terms of project requirements. In this case, you need to specify and validate all requirements explicitly. 

PRACTICAL USE TOOLS 

The following tools can support and enhance shared understanding: 

Using all these tools is beneficial with short feedback loop cycles, which reduces the risk of confusion or misunderstanding. 

USE CASE

It's noteworthy that important requirements may still be lost even in the context of excellent shared understanding if they skip the team's attention overall. There are many sad stories on this subject. IREB, for instance, suggests the following comic:

Figure 3. Examples of correct and incorrect shared understanding.

This example suggests a particular degree of shared understanding, implicit and explicit. However, along with it, the team has an incorrect shared understanding regarding the swing's material, while the branch's strength requirement is omitted altogether. The latter requirement should have been prioritized instead of an irrelevant shared understanding of the requirement to attach a swing to a tree branch. 

Principle #4 Context

Systems cannot be understood in isolation 

EXPLANATION 

IREB uses the following diagram to explain the concept of context:

Figure 4. System, context, and scope.

Context is a part of the product's environment that affects its understanding and shapes its requirements. The system's context is located between the system and context boundaries. The latter separates the system's context from irrelevant domain elements that don't need to be considered in the requirements development process. 

The system boundary divides the system itself and its surrounding context, thus scoping it from the viewpoint of implementation and deployment. Since the system boundary may be vague at the project's onset, the RE's task is to specify it and determine the project's scope and external system's interfaces in its context. 

However, it's not enough to consider only requirements within the system boundary and external interfaces for several reasons. First, contextual changes within the project's scope can affect the requirements. For instance, when we talk about business process automation, it may be changed for better adaptation. In other words, the context may change, thus affecting the project's scope and requirements. 

Second, the context may contain real-world phenomena and objects, which the system should monitor and control for requirements adaptation. 

Third, some requirements may depend on physical objects, and the product corresponds to them only if the requirements for these objects are met. For example, any monitoring and control system will work correctly only if physical equipment is functional. 

This way, a business analyst should balance excessive detailing of irrelevant context and risks of omitting important contextual details affecting the requirements.  

PRACTICAL USE TOOLS 

The main tool for context analysis and system boundary estimation is the context diagram. Figure 5 is an example of such a diagram's use in a library management system.

Figure 5. Context diagram in a library management system

A handy addition to the context diagram may be a high-level questionnaire that considers not only the system's boundaries and interfaces but also the following context-related questions: 

USE CASE

Let's consider a case using the diagram in Figure 5. This context diagram presents a solution regardless of whether specific functions are carried out online or offline. This relates, for instance, to the book supplier, which may be both in paper-based and digital formats. Business processes can change within the system; for instance, the illustrated system doesn't stipulate the peculiarities of the electronic document supply procedure. 

To take proper account of this aspect, for example, one may find it appropriate to divide the book database into two parts regarding the digital and paper-based book formats. This change will introduce a change to the system's context and, respectively, to its requirements. 

Principle #5 Problem, requirement, solution 

An inevitably intertwined triple 

EXPLANATION 

Any situation in which people are dissatisfied with what they do may be considered an emerging problem. To avoid this problem, you can create a socio-technical system; otherwise, the problem may be resolved non-digitally. It's vital to consider the solution's requirements so that it can resolve the problem efficiently. There's no sense in specifying the requirements if there's no problem or its solution is not planned for development.

There are many ways the problems, requirements, and solutions intertwine with one another: 

However, regardless of the mutual connection between problems, requirements, and solutions, the RE's primary task is to separate requirements from solutions. 

PRACTICAL USE TOOLS 

Here, you may apply tools for separating requirements from solutions, such as the context diagram considered in Principle #4. You may also use the Value Stream Mapping technique (see Fig. 6).

Figure 6. Value Stream Map for a car sale solution.

USE CASE

An assumption that the problem's solution will necessarily be digital is not always correct. A handy practice for separating solutions from requirements is a Value Stream Map diagram provided in Figure 6. Here, the solution includes three stages: a test drive, a car purchase contract, and the car's delivery to the client. Each of these stages covers a set of activities that may be realized online and offline. 

Principle #6 Validation 

Non-validated requirements are useless 

EXPLANATION 

Once the product is created and deployed, it should satisfy the stakeholders' needs and expectations. However, performing such a check at the end of the development process is very risky. Requirements validation should start at the very beginning, at the stage of their identification and documentation, to control the risk of stakeholder dissatisfaction. The IREB's view of the validation process is depicted in Figure 7.

Figure 7. Requirements validation process.

Overall, validation is understood as a process of ensuring that the component (system, product, or its part) meets the stakeholders' needs. In terms of RE, validation is a process of confirming the documented requirements' match with the stakeholders' needs; in other words, it's a confirmation of correct requirements documentation. Validation is an essential part of RE since requirements specification becomes valuable only after its validation.  

IREB recommends the following criteria for effective requirements validation: 

When validating the product's requirements, you also need to take the following aspects into account: 

PRACTICAL USE TOOLS 

IREB classifies methods of requirements validation into three categories: review techniques, sample development, and exploratory techniques. The first two categories are static, which means they are performed regardless of the software's operation. The third technique is dynamic, as it focuses on the product's behavior during operation. 

Review techniques may be formal and informal. Informal review presupposes sending the document for reviewer analysis; the review process, terms, criteria, and comment processing take place in a free form. This method works well with the documents' intermediate versions, while the final release of requirements specification requires a formal review. 

Formal reviews follow more ordered review procedures. There are two types of formal review: walkthrough and inspections. Walkthrough review presupposes that the specification's author explains the document's essence to the audience step by step during an interactive meeting. The review participants can give comments, identify flaws, and suggest alternative options. This approach is more suitable for the project's early stages to discuss specific concepts' viability or pass the specifications to another party. Besides, walkthrough reviews can be part and parcel of sprints. 

Inspection review is done under a moderator's supervision, other inspectors take part in the process, and the document's author is a listener in this procedure, required to give clarifications and comments if needed. The requirements specification is done to check its compliance with previously negotiated goals and criteria, standards, regulatory standards, and quality aspects. The inspection's outcomes should be documented. This validation form may be used to decide whether to transition to the next phase of the product's development iteration. 

During sample development, the project team tries to create program artifacts (e.g., design, code, architecture, test cases, guides, etc.) based on the documented requirements. Since the product is yet non-functional, this procedure also belongs to static validation. It's possible to identify errors, requirements' fuzziness, omissions, disagreements, etc., in the course of sample development. 

Exploratory techniques combine prototyping, A/B testing, and alpha and beta testing.  

USE CASE

I believe that many colleagues have faced a situation when requirements validation is insufficiently prioritized in the course of project development and during sprints. Formally, PMs and BAs keep in contact with developers and ask about the requirements' clarity, getting an affirmative response. However, in reality, the requirements could be neglected by the team altogether. As a result, the efficiency of development degrades if nobody can set a bug and a feature apart. 

A sound way out of this situation is regular requirements refining/grooming, which should become part and parcel of sprints. These sessions can be held in the "3 amigos" format, where the business analyst, the developer, and the tester take part. 

Principle #7 Evolution 

Changing requirements are no accident, but the normal case 

EXPLANATION 

Every technical system evolves. Business requirements and technical opportunities are constantly changing. Consequently, requirements that should meet specific project needs, support the business, and address technical capabilities, also evolve, while non-changing projects gradually lose their value. 

Requirements can change in the process, upon other requirements' identification, during the product's development, or even when it's in use. Reasons causing changes in the requirements include: 

This way, requirements development urges business analysts to strike a balance between two seemingly contradictory activities: 

PRACTICAL USE TOOLS 

The major tool for implementing changes in the requirements is the Change Control process (see Fig. 8). It's documented via a Change Request.

Figure 8. Change Control Procedure.

When controlling changes, you should focus on three main aspects: 

Thus, the Change Request should be structured as follows: 

USE CASE

As a rule, the described procedure of change management covers all possible cases, but it's pretty bureaucratic and costly. I'd like to illustrate how controlling changes can be adjusted to current project needs. 

During one of the projects' design stages, our team repeatedly received requests for the product's functional additions while its development estimate was not yet finalized. This way, the introduction of changes touched upon requirements refining and their consistency analysis. The impact analysis was shorter, as there was no need to change the design, with only additions required to the existing solution, and development was not yet initiated. As a result, change management turned into a log with the client's request documentation. This approach formally reduced the number of needed activities per the company's change management procedure, while some resources were saved without quality compromises. 

Principle #8 Innovation 

More of the same is not enough 

EXPLANATION 

Giving your client exactly what they want means a lost opportunity to do things better than they used to. That's why it's not enough only to identify the stakeholder's wishes when you're gathering requirements. Fine-tuned RE processes are based on innovations and go beyond the scope of stakeholders' input. This approach not only satisfies stakeholders but also makes them excited and happy. At the same time, it's vital to strike a balance and avoid the trap of arrogance and blind faith that developers always know better than the clients. 

On the one hand, RE forms innovative systems and strives for new functions and usability. On the other hand, RE forms a general picture, helping you identify disruptive ways to perform the needed functions together with stakeholders, thus implementing large-scale innovation in the project. 

PRACTICAL USE TOOLS 

Instruments for implementing innovation are requirements identification techniques. They are well-known, but it's noteworthy that IREB prioritizes the use of: 

USE CASE

IREB offers a typical case for review of this principle, so I'll consider it here. An insurance company wants to update its reporting system for the agents. The most widely used report is a spreadsheet with numerous columns, much larger than the screen size of agents' laptops, so it requires constant scrolling back and forth. Besides, the company plans to substitute laptops with tablets. The stakeholders thus want to allow agents to scale the report with the help of additional control tabs. 

If a business analyst starts asking additional questions, they may discover that only a small part of the spreadsheet's columns is used every time, while the rest of the columns are referred to only in rare cases or can be removed from the report altogether, as the company plans to update the reporting rules. 

Besides, using control gestures when operating the tablet's sensor screen instead of control tabs may significantly simplify the report's scaling operations. This way, the innovation requirements for this report may be documented as follows: 

Principle #9 Systematic and disciplined work 

We can't do without in RE 

EXPLANATION 

RE is not as much of an art as it's a technical discipline requiring systems thinking and systematic activities. However, there is no universal RE process; neither is there a one-size-fits-all RE toolkit that would work equally well in each concrete situation or at least in most situations. That's why IREB has formulated the following recommendations for a systematic RE approach: 

PRACTICAL USE TOOLS 

Since this principle is a general, senior-level one, it encompasses all instruments discussed in the previous sections. 

USE CASE

Similarly, this rule applies to all cases described in the previous sections. 

Conclusions 

IREB releases top-quality materials, with each page containing valuable information about the best RE practices and business analysis. 

For me, the most interesting insight from the aforementioned principles' overview was that our work involves a great degree of balance and optimization, as these 9 principles require keeping to 9 respective types of balance. Thus, I will add a wrap-up that besides using the relevant RE instruments, a professional BA should maintain balance. 

9 Types of Balance 

Principle #1 

Value orientation – balance between the benefit of requirements' availability and the cost of the RE process. 

Principle #2

Stakeholders – balance between influential and interested stakeholders  

Principle #3 

Shared understanding – balance between using explicit (requirements documentation-based) and implicit (common knowledge-based) shared understanding by all project participants 

Principle #4 

Context – balance between excessive detailing of irrelevant context and the risk of losing important contextual details affecting the requirements 

Principle #5 

Problem, requirement, solution – balance between separating requirements and solutions and the intertwining of problems, requirements, and solutions 

Principle #6 

Validation – balance between the benefit of requirement flaws' identification via validation and the cost of validation 

Principle #7 

Evolution – balance between requirements evolution and stability 

Principle #8 

Innovation – balance between implementing innovations and conservatism 

Principle #9 

Systemic and disciplined work – systemic use of all identified types of balance 

These principles are a helpful guide in my everyday work, and maybe, they will be of value and help to some of my readers.