We consider requirements engineering as a decision process

For us, requirements engineering is much more than just writing down lists of statements saying “the system shall…”. We consider requirements engineering as an (early) activity in each project that deals with the elaboration of a concept for solving a problem or defining a sustainable innovation. For this purpose, we integrate “traditional” requirements engineering with business analysis, creativity techniques, user experience methods, and early architectural design so that you can make the right design decisions right from the start.

We involve all stakeholders

Of course, the customer is probably the most important stakeholder, as he / she is the one that will pay for a system. However, we also involve all other stakeholders, especially end users and developers, in the requirements process. This is essential for assuring that the desired solution will be both actually accepted by the target group and realizable within the given time and budget.

We integrate business and IT bi-directionally

A software system is no end in itself and is always used to make business. Thus, it is essential that business and IT are perfectly aligned in order to assure that the business goals are achieved. We therefore always derive software requirements from the overall goals of an organization, but we also consider the capabilities of existing IT explicitly in order to either increase reuse or find novel ways to run the business.

We individualize processes and templates

There are many good books and standards on how to do requirements engineering, but we are sure that these approaches will not work as-is in your organization. Individualizing requirements engineering processes and specification templates is essential for making requirements engineering a helpful means and not a burden. Especially in agile development contexts, but also in very rigid ones, the role of requirements engineering must therefore be defined carefully in order to provide actual support for the chosen philosophy.

We deliver value for the project

The main consumers of a requirements specification are the engineers and developers on the development team. In today’s practice, however, requirements specifications are not always valuable for them. Many pages are written, but many issues still remain ambiguous. By using the aforementioned means, we ensure that the requirements provide actual value for each project.