Process-oriented Requirements Engineering

The implementation and customization of IT systems frequently depends on improving one or multiple business processes. In such scenarios, a traditional, spreadsheet template-based requirements specification falls short of what’s required. Why is this the case?

• Failure to identify conflicts between different requirements.
  Requirements are usually contingent on each other. It’s hard to identify these dependencies and conflicts without a graphical business process definition that puts the requirements in context.

• Setting the focus on systems and tools instead of business goals.
  Requirements engineering meetings can go off the rails when technical stakeholders start arguing about implementation details that influence the technical elegance of the solution, while ignoring their impact on business requirements.

• Lack of guideline through the tasks that the implementation project aims to accomplish.
  When you implement a system to help you reach a specific business goal, the key requirements are firstly those regarding the process the system needs to support. Without a clear mapping from business process to technical requirements, your requirements specification is bound to diverge from the business process definition. This is especially true during lengthy continuous process improvement projects.

By setting current state and future state processes as clear reference points, business process-oriented requirements engineering embraces processes and business goals, preventing you from getting lost in technical implementation details.

This blog post takes a hands-on approach in explaining the advantages of process-oriented requirements engineering, guiding you through the requirements specification of one of our internal engineering processes.

Hands-on process-oriented requirements engineering

Let’s take a look at our approach to re-engineering the translation process of our in-app texts. The process spans a set of highly customized IT systems and requires a smooth handover between developers and translators.

Defining business goals

The overall goals of our process re-engineering efforts are to:

• automate language extraction and integration to the translation management system (save costs),
• move all translation and language polishing tasks from our developers to specialist technical writers and translators (improve product quality),
• provide our translators with better information and tools to create high-quality translations (improve product quality).

Configuring the Signavio Process Editor to optimally support requirements engineering

It only takes a couple of mouse clicks for us to configure our workspace and optimally support our requirements engineering approach.

The dictionary category ‘requirements’ exists by default in our workspace. We create a sub-category for each requirements engineering project we start.

Now, we add custom attributes to the dictionary category.

Each custom attribute reflects a column in a requirements specification table, for example `priority` or `responsibility.`

Later, we will link the requirements to elements in our process diagrams. Each element should reference any number of requirements.

We create a list attribute on element level of type ‘dictionary link’.

We also create a (multi-line) text attribute on task level to document the shortcomings of activities in our current state process in detail.

Our requirements specification journey can now begin!

Identifying the current state process

First, we identify the current state process. To ensure the process represents the actual status quo, we involve all relevant stakeholders and process participants: software engineers, translators and product managers.

Then, we identify and document the process’ shortcomings along with the same group of stakeholders. Our translation process, for example, involved several manual steps to transfer translation files from our code base to our translation management system and back. This was a clear shortcoming.

We will transform such shortcomings into requirements. In the example above, the high-level requirement we can derive is `automate integration with translation management system.`

With the Signavio Process Editor, we can manage the requirements directly at the corresponding process elements.

Deriving requirements from shortcomings of current state process

We specify our requirements based on our business goals and the shortcomings of our current state process.

For each requirement, we add a dictionary and reference it directly at the process step the requirement is affecting.

Specifying the future state process

Based on our requirements specification, we now adjust a copy of the current state process to represent our future state process. The graphical current state process model reveals further possible improvement, as well as technical and organizational implications.

Consequently, we then identify further requirements and adjust some of the requirements we already specified.

In the end, we have a well-defined future state process…

…and a list of requirements that specify exactly what we need to do. We can even export the requirements as a Microsoft Excel® spreadsheet. This means we can generate a traditional requirements specification table in case formalities require it.

We can now create a roadmap and get started with implementing the new process.

Pro Tip: Integrate your requirements specification with your enterprise architecture definition

If you have documented your enterprise application landscape with ArchiMate®, you can make use of the ArchiMate motivation extension to relate the requirements specification to the context of your overall enterprise architecture.

Conclusion: The advantages of process-oriented requirements management

While traditional requirements management focuses on creating a pure system specification, in process-oriented requirements engineering, organizational aspects are a first-class citizen.

Process-oriented requirements engineering helps you to:

• discover dependencies and conflicts between different requirements,
• focus on the aspect that matters most: the business goal,
• align your requirements management approach to the continuous process improvement philosophy.

With the Signavio Process Editor, you can get started with process-oriented requirements management in no time and seamlessly integrate your newly created diagrams into your overall process landscape.

Get started with collaborative process design now and sign up for a free 30-day trial account.