By Urs Koepfli (ERNI Switzerland)
In the digital age, generating ideas has never been easier. Bringing them to life in a user-friendly manner is harder. In the course of time, I see requirements engineering taking on a new set of challenges. With digital products becoming more sophisticated and development cycles faster, aligned adaptable requirements are vital.
What requirements engineering (RE) stands for today
From what I have experienced in recent years, the era of conventional, heavy documentation and rigid RE processes is over. Modern RE requires collaboration between cross-functional teams, with an ability to match the developing needs of the stakeholders, and strong traceability over the lifecycle of the requirements. All this is especially crucial in a regulated or high-stakes environment where misunderstandings or incompleteness in the requirements may cause expensive setbacks. Throughout my work, one key transformation has become clear: RE now needs to scale and integrate 5 seamlessly into agile development environments without sacrificing the detail or compliance needed in regulated industries. In this lead article, I would like to point out what the recent issue of .experience will handle in more detail: how organisations are dealing with today’s challenges and developing RE practices to support their operational goals in increasingly complex systems.
For whom do we engineer requirements?
In nearly every project I’ve worked on, it’s been clear that there’s never just one ‘customer’. There are users, buyers, maintainers, regulators and developers, and they all have their valid perspectives. Taking all of them into account creates complexity. And this is where RE steps into the scene, bringing structure to the complexity.
Stakeholder management, in my view, goes far beyond ticking boxes and collecting sign-offs. It’s about actively discovering what matters to each stakeholder and translating those insights into a shared direction. It is about identifying all legitimate voices in the process, learning what they are aiming for and ultimately generating a common direction that guides development. From the field technician working in the rain (or any other weather conditions), wearing gloves and trying to compress a full location on an app; to the Governance, Risk and Compliance Officer who is responsible for protecting information in terms of GDPR; every one of them matters, and all provide critical information that decides future success.
In one of the projects I was part of, the shift in the role of requirements engineering became particularly clear. Initially, the team expected RE to simply collect and document the requirements. But as we progressed, it became evident that our real value lay elsewhere. Acting as the customer’s voice within the solution team, we helped translate vague expectations into tangible priorities. Together with developers, designers and business stakeholders, we worked out what should actually be built – not just what was technically possible, but what would truly bring value and be usable in the customer’s real context. That’s when I realised: requirements engineers are no longer gatekeepers of specifications. They are facilitators of shared understanding and direction.
“It’s not about building what the customer says they want – it’s about understanding their true goals and helping to find and implement the best solution.”
RE is the bridge between business intent and technical realisation. It translates abstract ideas into structured inputs for development. And in agile teams especially, RE ensures that rapid iterations don’t lose sight of the overall view. Perhaps most importantly, it helps teams make better decisions early when change is still affordable and the impact high.
In more agile situations, RE changes from a very heavy lift at the front to more continuous collaboration as the work transitions from documentation into general continuous interaction and information sharing with stakeholders. Also, the capabilities of tools evolve – from AI-assisted analysis of regulatory texts to a collaborative prototyping platform always with the one goal in mind – to ensure that the team is building the right solution.
The first 100 hours – Laying a solid foundation
From my experience at ERNI, I’ve seen again and again how the first days of a project determine its overall success. One case comes to mind where this became very clear. We were working together with a customer in the infrastructure sector, and the task seemed straightforward at first glance: deliver a mobile app for field technicians to document maintenance activities on site.
The customer expressed a clear idea of what they wanted, at least on the surface. A sleek interface, fast performance and seamless backend integration. But during the initial discussions, our requirements engineering team dived deeper. We conducted field visits, spoke directly with the technicians and tried to understand how and where the app would be used. What we discovered changed almost everything.
Most of the technicians worked outdoors, year-round, often in cold and wet conditions. They wore gloves, operated in low-light environments, and had minimal time to navigate complex menus. This was not covered in the original briefing. Had we rushed into development based only on the initial specifications, we would have built something technically sound but practically unusable. In fact, a previous attempt by another vendor had failed for precisely this reason. The UI simply didn’t work in real-world conditions.
This experience reinforced a principle we hold in our projects: you need to build the right foundation early. Or, as I often say:
“If you’re building a four-storey house, you need a different foundation than for a garden shed.”
That project succeeded not because we followed a checklist, but because we took the time to listen, observe and question before building. That, to me, is the essence of requirements engineering done right.
The future of requirements engineering
RE as a discipline hasn’t changed at its core – but its context certainly has. It will no longer be a phase – it will be a continuous, iterative activity that keeps pace with product development. In agile environments and while leveraging DevOps pipelines, requirements will evolve in real time and therefore will need tools and practices to effectively accommodate continuous refinement, stakeholder consent and traceability. As system complexity increases (particularly in regulated domains such as MedTech and automotive), RE will shift further towards formalised models and Model-Based Systems Engineering (MBSE) to manage the interdependencies. Visual models will reduce communication overhead across business, technical and compliance teams.
Future RE will not only be about technical specifications and functional scope but also more broadly about understanding user needs, outlining business objectives and delivering value.
Agile ways of working, the proliferation of tools, and especially AI are reshaping the ‘how’ of RE. But the ‘why’ remains the same: building shared understanding. A frequent question we hear is whether AI will replace RE professionals. ‘Replace’ is not the right term; a more proper one would be ‘augment’. If AI can summarise lengthy compliance documents or create draft user stories in a speedier manner, why not use it? Yet one thing AI cannot replace is the human judgment of balancing business objectives, user needs and technical realities. This remains the job of requirements engineers, now and into the future.
Conclusion
Requirements engineering is no longer just about specifications; it’s about a shared vision. It represents the foundation for agile, scalable and human-centric software. Today, RE is less of a defined set of roles, and more about flexible collaboration. It is increasingly a function that embeds not just a process, but a way of thinking into product teams.
To read more about how AI will augment and assist the role of requirements engineers, read also our previous article How business analysts and requirements engineers can make the most of AI tools – ERNI.
