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

February 18, 2023

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.

The CPRE Education Scheme-min

Figure 1. Scheme of CPRE Certification by IREB

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

  • Handbooks for three levels 
  • Syllabus for each separate level 
  • Glossary for RE and RE@Agile aspects 
  • A collection of articles published in different years in the Requirements Engineering Magazine 

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.


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.  


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.

Power of the stakeholder(s)-min

Figure 2. Stakeholder power/requirement's impact grid

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

  • Efforts for the requirement's formulation 
  • The requirement's contribution to the system's overall success 
  • Degree of mutual understanding between stakeholders and developers and among stakeholders. 
  • Availability of reference products that can be studied as examples or partially adopted. 
  • Length of feedback loop on the requirements formulation and troubleshooting. 
  • Type of relationships between the client and the provider. 
  • Need to consider regulatory requirements. 


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 


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. 


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. 


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 


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: 

  • Explicit shared understanding is achieved via thorough requirements identification, documentation, and negotiation. 
  • Implicit shared understanding is based on common knowledge about the project's demands, vision, context, etc. 

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: 

  • Domain-specific expertise; 
  • Availability of domain-specific standards; 
  • Prior experience of successful collaboration between the client and the provider, a cultural and value match;
  • Mutual trust among the project's participants based on awareness and information (not blind); 
  • Existence of product analogs that may be analyzed by project participants. 

Obstacles to shared understanding are as follows: 

  • Relationships between the client and the provider based on mutual distrust. 
  • Regulatory limitations. 
  • Involvement of large and heterogeneous teams. 
  • High staff turnover in the development team. 

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. 


The following tools can support and enhance shared understanding: 

  • Glossaries developed and updated in real-time to avoid mistakes and confusion related to the project's terminology. 
  • Research prototypes of the product used to ensure shared understanding and validation of requirements. 
  • Existing reference products that may also function as a prototype of some sort. 
  • Requirements validation (see Principle #6). 

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


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:

Stakeholder’s desires and needs-min

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 


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.  


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: 

  • If there are any context changes, how will they affect the system's requirements? 
  • What are real-world context requirements relevant to this system? 
  • How can one adequately reflect the real-world requirements in the system requirements? 
  • What context-related conditions should be met to allow the system to function correctly and correspond to real-world requirements? 


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 


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: 

  • Hierarchical intertwining. In large-scale products with multi-level requirements hierarchy, upper-level requirements result in upper-level project solutions, which, in their turn, are implemented in lower-level project solutions, etc.   
  • Technical implementation. Engineering of requirements that cannot be technically implemented is counter-productive, but the implementation likelihood may often be estimated only during the technical solution's evaluation. 
  • Validation. Prototypes, which are requirements check tools, may also serve as partial solutions to the identified problem. 
  • Solution conflict. Different stakeholders may opt for different solutions for a particular problem, voicing contradictory requirements as a result. 

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


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).

Value stream mapping workshop-min

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


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 


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.

Stakeholder’s desires and needs-min

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: 

  • Stakeholders' needs and expectations are adequately covered in the requirements. 
  • Stakeholders have reached a consensus regarding requirements, which means that conflicts are resolved and priorities are set. 
  • Real-world requirements and domain assumptions (Principle #4) are well-grounded; we can expect these assumptions to be realized during the product's deployment and use. 

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

  • Involve the most competent stakeholders
  • Separate the processes of error identification and correction 
  • Engage a multidisciplinary team to perform validation from various perspectives 
  • Iterate the validation at different stages of product development 


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.  


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 


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: 

  • Business process changes 
  • Market changes because of new product launches by competitors 
  • Stakeholder priority changes or flaw identification during requirements validation
  • Technology changes 
  • User feedback 
  • Flawed requirement identification or wrong context-related assumptions 

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

  1. Allow requirements changes to avoid ignoring the requirements evolution. 
  2. Keep requirements stable to keep the cost of product changes reasonable. 


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

Analyze impact-min

Figure 8. Change Control Procedure.

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

  • Impact analysis via evaluation of all possible risks the proposed change may cause. 
  • Authorization of the change. 
  • Control of the change and review of its results. 

Thus, the Change Request should be structured as follows: 

  • List of requirements affected by the change. 
  • The change initiator's role and name. 
  • The project's stage to which the changes relate. 
  • The change's type in terms of what aspect they affect (scope, project's schedule, procedures, design, code, tests, documentation, etc.) 
  • The request's status (e.g., declined, approved, or postponed)
  • Dates of the request's submission and status changes 
  • Description of the change and its impact.   


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 


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. 


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

  • Surveys: interviews and questionnaires 
  • Collaboration: workshops and crowd-based RE 
  • Observations: field research and apprenticeship 
  • Artifact analysis: systems archeology (deriving requirements from existing systems), product/prototype user feedback analysis, requirements re-use. 


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: 

  1. The report should contain the same information that the current system (except for the deleted columns) 
  2. Once the report is opened, only several most important columns should be visible at full width, while others should be condensed to minimal width. 
  3. A condensed column should be available for expansion and condensation by touching its title. 

Principle #9 Systematic and disciplined work 

We can't do without in RE 


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: 

  • Set up your RE process in line with a particular problem and match it with the process used in product development. 
  • Choose the most suitable techniques and practices in compliance with the concrete problem, context, and work environment. 
  • Always analyze the value and efficiency of techniques and practices for a specific project, even if they were efficient in your previous activities. 


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


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


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.

Love the article? Share!

Read More

Explore articles from Artkai - we have lots of stories to tell

Join us to do the best work of your life

Together we advance the human experience through design.

Artkai site

End-to-End Development agency, building digital products that make sense. Represented in USA, UK, Belgium, Switzerland. Main headquarters in Ukraine

© Copyright Artkai 2024. All rights reserved