By search term

By author
  • Practice
  • Opinions

Mastering Business Requirements


Mastering Business Requirements

Insights for 13 crucial challenges

The transition from problem to solution always gives rise to requirements. In a professional context and at an early stage these usually are business requirements which are derived from strategies and processes. From the outset these business requirements should constructively be put into relation with user and technology requirements.

In a large corporation such as Deutsche Bahn the concerns surrounding business requirements are substantial and thus require particular attention because, all too frequently, it’s insufficient or misunderstood requirements that cause distress in a project.

The context in which business requirements develop in large companies is mostly affected by the following aspects:

  • a great number of business units which have complex business relationships among each other
  • business units that are large enough to exhibit a high level of division of labour and distributed responsibilities
  • a strict regional division and a high number of “mobile” employees
  • a broad distribution of requirements and budgets that result in collaboration being exacerbated by a fierce competition for IT budgets furthered by internal regulations determined by the group management.

Besides operational knowledge and methodical expertise, the right mindset is required to master business requirements in an environment as described above. Promoting such a mindset we as DB Systel, the internal IT partner of Deutsche Bahn, issued a publication to address 13 crucial challenges providing a golden rule to each one of them.

Click on the image to download the brochure

In a problem-based approach we developed problem hypotheses based on interviews, specialist literature and our own consulting experiences and discussed these with corporate units of Deutsche Bahn.

Theoretical points of reference for us were:

  • Horst Rittel / Melvin Webber: Dilemmas in a General Theory of Planning
  • Jamshid Gharajedaghi: Systems Thinking – Managing Chaos and Complexity
  • Chris Rupp: Requirements-Engineering und -management
  • Business Analysis Body of Knowledge V3

Particularly the analysis of the idea of ‘wicked problems’ by Horst Rittel and Melvin Webber was truly helpful to us. In as early as 1973 the two of them framed ten special characteristics of social and cultural difficulties which can be conveniently transferred to actual sociotechnical IT challenges. Because whenever problems cannot be defined conclusively and whenever there are several stakeholder’s perspectives on an issue a merely scientific engineering approach is not expedient.

Besides helping us articulating our golden rules, our analysis led us to the conclusion that the requirements engineering process requires a stronger competence in bridging the gap between technologically excellent and socially successful solutions than can be currently observed. It is for this reason that we from now on support IREB’s Digital Design Initiative to further develop this competence from an integrated business, people and technology perspective.

Comments (4)

  • From: Ertuğrul Yalçın
  • Date: 14. September 2020

Thank you for these detailed elaborations on requirements elicitation, management and analysis processes.

  • From: Yvonne Hughes
  • Date: 17. November 2019

Thank you very much for sharing this article, again - this is very good, not too much to read, well put together. Would be a great support for my role.

  • From: Daniel Galiana
  • Date: 06. November 2019

Nice & useful document; will support our teaching at IBS Academy!
Thank you!

  • From: Miguel Elasmar
  • Date: 05. November 2019

Fantastic document. Thanks for sharing all that hard work into such a compact rule book.

Love it. My regards to your team.

Author's profile
Related Articles
RE for Testers

Why Testers should have a closer look into Requirements Engineering

Read Article
Product Owner in Scrum

State of the discussion: Requirements Engineering and Product Owner in Scrum

Read Article
Toward Better RE

The Main Thing is Keeping the Main Thing
the Main Thing

Read Article