Gareth Rogers
NeProduct Owner - Requirements Engineer - Solution Designer
Published Work
My experiences from the Telecoms industry
I wrote this article
for the IREB Magazine
while working on a project which was undoubtedly one of the worst examples of how to approach agile development. Self-proclaimed Agile gurus dragging reluctant engineering teams through endless stand-ups, retrospectives and scrums of scrums... It makes the case for the importance of good requirements engineering when forced to defend itself against an interpretation of agile that would rather skip requirements altogether and get on with hacking some code together. Hopefully industry has moved on somewhat from that view, though I'll leave you to make up your own mind on that...
Strategies for building manageable requirements hierarchies in complex problem domains
Requirements splitting comes from the agile playbook and is concerned with techniques to break up large requirements into parts that are small enough to fit within individual development sprints. While this is all very well from the viewpoint of individual requirements, I have often felt that not enough consideration is given to the consequences of such splitting decisions to the set of requirements as a whole, particularly when there is an idea of a requirements hierarchy over a larger scope. Or in other words, it's one area where agile's case-by-case, scenario-based thinking potentially conflicts with a more comprehensive and structured RE approach.
Anyway, this article is my attempt to find a path through this topic, though I warn you it does get quite complicated!
As part of a dissertation (see below) I set out to find some evidence that requirements engineering was still taking place within Agile projects, even if under different guises. There was an idea going round at the time that requirements engineering had become obsolete in the age of Agile, that I rather hoped to disprove!
Dissertation
for MSc
GUIDELINES FOR THE APPLICATION OF REQUIREMENTS ENGINEERING METHODS TO SCALED AGILE SOFTWARE DEVELOPMENT PROJECTS IN COMMERCE AND INDUSTRY.
Not just a catchy title...
RE@Agile Case Study
Submission for the IREB RE@Agile Advanced Level
exam (required to become an assessor). Case Study of how requirements were handled within an Agile project at my employer.
Requirements Engineering is one discipline within the larger field of software engineering. It is concerned with defining what tasks or functions a system should be designed to perform.
In the early years of computing - say 1950/60's - it was fairly clear what we wanted computers to do. This generally involved blowing people up: calculating spacecraft reentry trajectories, getting anti-aircraft guns to hit moving aircraft, developing missile guidance systems and so on. The challenge was building the hardware to do so quickly and reliably enough.
As in 1970/80's the technology improved and in particular as chip production scaled and became more standardized, the emphasis shifted to software to meet the needs of a broader range of applications. The challenge now was to design and build systems with software components that exhibited the same qualities of reliability and adaptability as the hardware. Software engineering was born.
Though most of the effort here was spent getting lower level programming languages and tools to perform basic functions, the term systems analysis also emerged to describe the first steps in the software development process. At this stage it was still fairly clear what
systems were intended to do, as the goal was typically to transform existing, manual processes into automated solutions: think basic account management with interest calculations etc. in banking or calculation of insurance premiums, for example. These processes though needed to be translated into the terminology of data and systems processes and methods such as structured analysis and data-flow diagrams were developed to help to do this in a predictable manner.
Fast forward then to the 1990's/2000's and not only was the complexity of software applications increasing exponentially but entirely new areas of application were emerging: think eCommerce, social media, mobile etc. The problem now became less how to program the machine and more: what should the software achieve exactly? What data should be used to represent a real-world situation, how should that data be input into the system and how should the results be delivered back to people using it?
Around this time the prominence of requirements greatly increased as it was recognised that this was in fact where many projects were going wrong: technical people were getting pretty good at building systems, the problem was that they weren't always building the systems that the business people actually needed!
A role was missing, and the term Business Analyst
was born: someone who could understand the real-world domain, and express the role a software solution should play in it in terms that would unambiguously define the work that developers should then perform. In the field of business analysis the modelling skills of systems analysis were supplemented with softer skills for eliciting and negotiating requirements among diverse groups of stakeholders, resolving conflicts and even discovering new potential solutions as original expectations are challenged and deconstructed.
The term Requirements Engineer emerged a little later and is in my view largely synonymous with Business Analyst, though it is I think useful to emphasise the engineering aspect of this role: as per my potted history here, RE has after all emerged from a long tradition of systems engineering!
Work Experience Highlights
Product Manager at German Telco
Since late 2021 I have been working as a Product Manager for Tech Mahindra at Telefonica O2 Germany.
For further fascinating details please see my CV as pdf (also available auf deutsch) or check out my linked in profile...
Requirements Engineering
Lead at Proagrica
Between 2015 and 2021 I worked as a Requirements Engineer (or Business Analyst, if you prefer) at Proagrica. Proagrica is the part of Reed Business Information
and the RELX Group
dedicated to providing software solutions to the agricultural industry. So we're talking anything from supply chain integration projects for global chemical manufacturers, to data analytics and precision farming solutions, to the farm management systems used by a majority of farms in the UK.
From 2017 I was involved in building a team of requirements engineers with the goal of professionalising the software engineering approach within the organisation. As the business scaled up, the importance of a rigorous approach to requirements, leading to a controlled, agile development life cycle, increased rapidly, together with the complexities of larger individual projects and of managing a growing product portfolio.
We were pretty successful in introducing a lightweight, iterative (and
agile, though I use that term with caution...) development process that fit within planned project engagements, with just enough upfront analysis to provide a sound architectural basis for the implementation. See a case study here.
Other stuff
Kim Lauenroth has long been an advocate of a sort of craftsmanship in software analysis and design that goes beyond the conventional boundaries of software engineering disciplines. On several occasions in conference anterooms and hotel bars he has enthused over the joys of furniture design and how these insights can be applied to software development....
In the Digital Design Manifesto, Kim and fellow authors propose a more holistic approach to software development that considers a much broader definition of stakeholders than usual: the impact of software on society, its sustainability and environmental impact are among the factors that a digital designer would additionally take into account when creating software, apart from usual customer and user requirements.
Kim draws on inspiration from the Bauhaus movement and the way in which different disciplines of arts and craft and engineering were brought together in industrial design in the 20th century.
Interesting stuff....
I have been collaborating with IREB for a number of years, most recently on the RE@Agile syllabus and handbook.
IREB do a pretty good job of spreading the word of professionalized RE internationally. Along with BCS and CBAP they are one of the major, global certification bodies for the discipline.
IREB isn't run to make a profit, and MD Stefan Sturm
works hard to pull together contributions from esteemed colleagues in the RE field including Peter Hruschka, Kim Lauenroth, Markus Meuten and, er... me.
Read this while in the midst of a kind of Kafkaesque to a (so-called) agile organisation, at an employer who shall remain unnamed. Often Bertrand Meyer made me laugh out loud, which is unusual for a book about software development. He writes with a wry sense of humour; also on my part there was a kind of insane relief that someone was finally talking common sense.
Meyer readily acknowledges good, Agile ideas - short, timeboxed iterations; closed window rule; delivering working software, etc. - but is merciless in taking apart the hubris, platitudes and other assorted nonsense that frequently comes with it. Scrum masters, for example, get a tough time! Ultimately, he understands that agile does not fundamentally change the principles of sound software engineering, and does not remove the need for common sense planning and architectural forethought.
If you've ever felt yourself to be on the outside of a cult-like movement of self-proclaimed agile gurus, this book is for you.