.png)
Properly interpreting the definitions of goals and the various levels and types of requirements is no easy task. Different sources introduce different nomenclature and interpretations, leading to difficulties in understanding the essence of the problem and correctly applying requirements classification and their alignment with higher-level goals.
Interpreting and linking requirements with business goals and objectives is one of the most crucial aspects of business analysis. However, it's not uncommon for people to confuse business requirements with business goals and objectives. Moreover, requirements of different types are often understood and applied in various, sometimes conflicting ways.
Below, I present my interpretation of the definitions of goals, requirements, and their relationships based on two sources of knowledge - the Business Analysis Body of Knowledge (BABOK®) guide and the International Requirements Engineering Board (IREB) Certified Professional for Requirements Engineering (CPRE) approach
Let's start with definitions.
Clarifying terms
Business goal: A state or condition that an organization is seeking to establish and maintain, usually expressed qualitatively rather than quantitatively. (BABOK)
In other words, a business goal represents the desired long-term outcome or strategic direction that an organization aims to achieve. A business goal can be formulated qualitatively, which means it may not necessarily be precise and measurable, but it reflects a certain aspiration of the organization.
Examples of business goals: increasing sales, improving customer satisfaction, or expanding into new markets.
Business objective: An objective, measurable result to indicate that a business goal has been achieved.
Business objectives are specific, measurable, achievable, relevant, and time-bound (SMART) targets that support the attainment of business goals. Objectives are more concrete and actionable than business goals, as they define the milestones or short-to-medium-term outcomes necessary to realize the broader strategic intent.
Example of a business objective (for a business goal - increasing sales)
Increase revenue from policy sales by 10% by the end of 2024
Business requirement: A representation of goals, objectives and outcomes that describe why a change has been initiated and how success will be assessed. (BABOK)
Business requirements focus on the business goals, objectives, and needs of an organization that shall be achieved by employing a system (or a collection of systems). (IREB)
Generally, business requirements represent the specific needs and capabilities that must be addressed or implemented to fulfill the objectives. They are actionable statements that describe what a solution or change initiative should deliver to meet the business needs.
The BABOK® Guide definition is somewhat general, and it may not be entirely clear at what level to place business requirements - whether at the level of the overall business organization or at the level of a specific change initiative. IREB fills this gap by adding that a requirement, in a certain way, describes the fulfillment of goals through the implementation of a given system (understood as an information system or solution, not just software).
Example of a business requirement (for increasing market sales): enabling the customer to purchase a policy by providing the ability to buy online
Another type of requirement identified in BABOK and IREB is the stakeholder requirement.
Stakeholder requirement: A description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements. (BABOK)
Stakeholder requirements express stakeholders’ desires and needs that shall be satisfied by building a system, seen from the stakeholders’ perspective. (IREB)
Stakeholder requirements are a kind of elaboration of business requirements. It is essential to note that there can be various types of stakeholder requirements, as clearly defined in IREB CPRE, such as user requirements.
Stakeholder requirements are typically relatively straightforward to identify - for example, when a stakeholder plays the role of a user, their requirements may relate to usability or response speed.
However, the challenge arises when attempting to classify legal requirements. These requirements are quite common in certain industries (e.g., the banking or automotive industry) and theoretically could be classified as stakeholder requirements (legislators are considered stakeholders in both BABOK and IREB).
Nevertheless, to describe these specific requirements adequately, another type of requirement, as indicated in IREB but absent in BABOK, can be utilized - namely, domain requirements.
Domain requirements specify required domain properties of a socio-technical or cyber-physical system. (IREB)
Those requirements pertain to the specific characteristics and constraints imposed by the application domain or environment in which the system operates. They reflect the unique capabilities needed to address particular industry sectors or fields. For example, a solution designed for the medical domain would have domain requirements specific to healthcare, such as patient record management, medical terminology integration, and compliance with medical regulations. These requirements are not directly related to the preferences or desires of individual stakeholders but are influenced by the nature of the domain itself.
IREB, therefore, provides a ready mechanism for specifying this type of requirement (which can also be somewhat synonymous with business or technical constraints since they often limit solution possibilities).
Example of a domain requirement: compiance with the General Data Protection Regulation (GDPR). If a customer purchasing an insurance policy online provides us with personal data, we are legally obligated to comply with GDPR regulations.
The next level of requirements pertains to the solution layer. IREB refers to these as system requirements, while BABOK® Guide terms them as solution requirements.
Let's first discuss the IREB approach.
System requirements describe how a system shall work and behave—as observed at the interface between the system and its environment—so that the system satisfies its stakeholders’ desires and needs. In the case of pure software systems, we speak of software requirements. (IREB)
And specific types of system requirements:
Functional requirements concern a result or behavior that shall be provided by a function of a system. This includes requirements for data or the interaction of a system with its environment. (IREB)
Example of a functional requirement: the system allows the user to search for insurance offer
Quality requirements pertain to quality concerns that are not covered by functional requirements — for example, performance, availability, security, or reliability. (IREB)
Example of a quality requirement: the system will be available to users during an average of 99.97% of the day
Constraints are requirements that limit the solution space beyond what is necessary to meet the given functional requirements and quality requirements. (IREB)
Example of a constraint: online policy sales only possible for customers residing in the UK
The BABOK® Guide's approach to describing requirements at the solution level is as follows:
Solution requirement: A capability or quality of a solution that meets the stakeholder requirements. Solution requirements can be divided into two sub-categories: functional requirements and non-functional requirements or quality of service requirements. (BABOK)
It is worth noting that IREB clearly distinguishes between quality requirements and constraints. In BABOK, a constraint is a separate entity, related only indirectly to requirements.
Constraint (business analysis): An influencing factor that cannot be changed, and that places a limit or restriction on a possible solution or solution option (BABOK)
In BABOK, there is another type of requirement known as transition requirements. These requirements describe the activities and features that must be provided when implementing a new solution to ensure that the solution can deliver the expected value. Transition requirements are often referred to as temporary because once they are fulfilled, they are no longer necessary and do not become part of the final solution. To simplify the topic, transition requirements can be seen as the actions needed to achieve a specific state of the solution.
Transition requirement: A requirement that describes the capabilities the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature.
Example of a transition requirement: providing training to users of the new solution or migrating data from the old solution to the new one are examples of transition requirements. These actions are essential during the transition period to ensure the successful adoption and integration of the new solution but are not permanent components of the final solution itself.
It is also worth noting that IREB distinguishes other types of requirements than just those related to solutions. In the IREB dictionary, project and process requirements are indicated - this is a good solution for people seeking a way to handle requirements related to the method of project work execution
Already knowing the nomenclature, similarities and differences in defining terms, let's try to sort it out.
Clarifying the Levels: Organization vs. Change Initiative vs. Solution
To understand the relationships between different types of requirements, it is essential to grasp the context or layer to which they belong. Personally, I distinguish three layers of information: the organizational (business) layer, the change layer, and the solution layer.
The business layer describes the company's goals, strategy, and the way business operations are conducted. In simplified terms, it outlines what the organization is and where it aims to go.
The change initiative layer comes into play when identifying a business need - the need to change the current state of affairs. It describes the modifications necessary to transition the organization from the current state (AS-IS) to the desired future state (TO-BE). These changes should, of course, be aligned with the business goals, necessitating the establishment of traceability.
The solution layer describes the system (understood as a solution meeting specific business needs) from various perspectives. In other words, it outlines how our solution meets the business requirements. From an analyst's standpoint, this description may be presented through functional and non-functional requirements. However, it is vital to consider the feasibility aspect of requirements, which is why IREB defines constraints at the solution level.
Business goals and objectives: These are established at the organization level and are aligned with the company's strategic vision. They provide a direction for the entire organization and guide decision-making processes. Business goals and objectives are set by senior management and are relatively stable over time.
Business requirements: On the other hand, business requirements are defined at the level of specific change initiatives. They address the detailed needs of individual projects or programs aimed at achieving the organization's objectives.
Stakeholder requirements: business requirements are defined at the level of specific change initiatives, may relate to desired behavior or quality attributes and then form the basis for developing solution/system requirements.
System requirements, also known as solution requirements, are defined at the level of a specific solution. They describe the behavior and qualitative characteristics of that particular system.
Domain requirements are an interesting case. Depending on the approach, we can consider them to be at the solution layer or to have a broader scope. Regulations often impose requirements and constraints not only on a specific solution but also on the entire business. Personally, I would treat them as tranversional requirements, impacting various aspects of the organization.
It's also worth mentioning transition requirements. According to the BABOK definition, they pertain to the solution layer. However, I believe they can also extend to the change layer. For example, the need to migrate data to a new solution not only affects that solution but likely also impacts stakeholders using the old solution. Thus, I would consider these requirements to potentially have a tranversional nature.
Conclusion: In conclusion, understanding the distinction between business goals, objectives, and business requirements is critical for successful business analysis. Business goals and objectives provide the strategic direction for an organization, while business requirements facilitate the realization of those objectives through specific change initiatives. By aligning these elements effectively, businesses can ensure that their projects contribute directly to the broader organizational vision, increasing the chances of success and value delivery. Both BABOK® Guide and IREB offer valuable frameworks for approaching requirements engineering, each with its own unique perspective and focus.
Sources:
BABOK® Guide Glossary: International Institute of Business Analysis (IIBA). Version 3.0 https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/glossary
BABOK® Guide, Version 3.0
IREB CPRE Glossary: International Requirements Engineering Board (IREB). CPRE Glossary https://www.ireb.org/en/cpre/glossary/
CPRE Foundation Level - Handbook Version 1.1.0, 2022
コメント