Business Requirements vs System Requirements

There is a lot of talk about the need to identify project goals, organization goals and the need to identify business and system requirements. All in order to better understand the expectations of the business (stakeholders) in the context of what is to be done, what the change is about, what is to be the result of the project.

The elements listed above are to be finally detailed with the requirements for the system. Sometimes on the way, business processes appear. Finally, we have a mix of elements from the area of ​​motivation, business and system analysis. What’s more, we have a world of enterprise architecture and a world of business analysis. I do not mention systemic analysis by politeness :-), because regardless of the approach adopted, either classical or agile, the problem also occurs.

Let’s start with the fact that goals and requirements can be described in two ways. We can reach concepts based on BABOK® (Business Analysis Body of Knowledge®) or enterprise architecture, which simplifies the ArchiMate notation.

At BABOK, we have defined goals and a number of types of requirements. From the point of view of the discussed issue, the following are important (definitions are my interpretation):

  • business requirements – define the expectations and results that should be achieved to achieve the goal. They can refer to the entire organization, business area or specific initiative. Business requirements are at the organizational level and do not specify requirements that are specific to a particular group of stakeholders.
  • stakeholder requirements – describe the needs of stakeholders that must be met in order to meet business requirements. They can serve as a bridge between business requirements and solutions.
  • solution (functional) requirements – define the features of a solution that meets the requirements of stakeholders. The requirements defining the solution are divided into functional requirements and non-functional requirements.

In the context of collecting the requirements offered by BABOK, we still have needs (business needs). I use simplified definition of need.

A need is a problem or an opportunity that have to be addressed.

Needs can cause changes by motivating stakeholders to act. Changes can also cause needs by weakening or strengthening the value provided by existing solutions. The need determines, at a high level of abstraction, the requirements related to the realization of a business goal.

Using the BABOK model from Enterprise Architect

Adding a diagram in the Enterprise Architect with requirements elements – BABOK

I get such a picture:

Business requirements and system requirements – BABOK

In practice, organizations are at different levels of maturity. They are not always ready for a complex analysis of requirements. Therefore, I will aggregate business requirements with the requirements of stakeholders.

Business requirements – simplification

Then I use the following definition of business requirements.

A business requirement specifies an object, activity or service that supports the implementation of a business goal of a project or organization. The business requirement is refined by functional and non-functional requirements.

The result is the following model:

Mapping functional requirements to business requirements

Please note that I have combined the functional requirements with business requirements with the trace relationship. It’s intentional action. Wherever I operate within a given layer, I use the realization relationship (eg mapping use cases to requirements). Where I pass between layers, and here I pass between the problem definition layer and the solution layer, I use the trace relationship.

This approach is based on the idea of ​​translation or description of how requirements that belong to different layers are translated in the requirements of another layer. I found this mechanism a couple of years ago with G. Plataniotis, S. d. Kinderen, and HA Proper, “Proceedings of the 17th IEEE International Enterprise Distributed Object Computing Conference (EDOC), 2013 .

Of course, applying the realization relationship, in my opinion, would also be correct.

In the world of enterprise architecture, the situation is quite similar. We have goals and requirements defined in the ArchiMate notation. The requirement is defined as a declaration of the need to be implemented by the architecture (and thus by the organization). The requirements indicate the properties of those elements that are needed to achieve business goals. These goals are implemented by introducing changes to current IT systems or by creating new or changing existing business processes. So here we have expectations for business and system. These requirements are also at the organizational level and do not specify requirements that are specific to a particular group of stakeholders.

Using ArchiMate models defined in Enterprise Architect:

I get (based on the same example as above) the following model:

Business requirements and system requirements – ArchiMate

Requirements are mapped to the realization relationship. I map the functional requirements with the trace relation, which, as in the BABOK-based approach, highlights the transition between the layers.

Finally, the question is whether we can mix the approach, that is, use the requirements of ArchiMate and business requirements with BABOK? Generally yes. I would only suggest defining the definitions of elements and the rules for mapping them. Then the requirements of ArchiMate may specify more business needs and the requirements of BABOK will be closer to the requirements of stakeholders.

To sum up. The specification of broadly understood business requirements can take place both through the approach offered by BABOK and corporate architecture with the motivation perspective at the forefront. In my opinion, breaking down business requirements and stakeholders does not bring tangible benefits. However, it is worth identifying goals, business requirements and detailing them with requirements for the system. Personally, I try to stick to the simplest approach, because strength is not in the possession of many types of elements and in the specification adequate to the solution being built and understandable for stakeholders.

More from my site

  • Requirements Documentation Based on Use Cases Use cases are used to document the functionality of the system and are based on two commonly used concepts: Use case diagrams Specifications of use […]
  • Analyst in Agile Team The role of the analyst and the importance of analysis in many organizations is strengthening and in others it is disappearing. Quite often, where there is an agile approach, the role of […]
  • User Stories vs Requirements When writing any specification of requirements and the product register and sprint register, non-functional requirements should be included in this specification. While the user's […]
  • Levels of Business Architecture and Business Process Modeling In the previous article of Modeling Business processes in the software development process, I described the meaning of modeling business processes. In my opinion, business processes […]
  • Tracking of Relationship Between Requirements An important aspect of requirements management is the ability to trace the relationships between requirements and other artifacts (including other requirements). The ability to track […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top