Professional
Gareth Rogers
NeProduct Owner - Requirements Engineer - Solution Designer
Published Work
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...
With time I have come to believe in the benefits of Agile (or shall we just call it 'iterative development'?) if applied within a sound framework of software engineering and project management common sense.
Incidentally, many of the points I was struggling to express at that time are made, somewhat more effectively, by Bertrand Meyer in his excellent book Agile, the Good, the Hype and the Ugly.
As part of a dissertation 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. Yes, remember that?
It's my impression that industry has pretty much moved on from that idea (not necessarily because of my survey).
Like many bad ideas, no one actually ever admitted to being wrong. It was just a misunderstanding - obviously we didn't actually mean you don't need requirements any more, it's just that they play a different role in the life-cycle, etc.
Whatever.
Dissertation
for MSc
GUIDELINES FOR THE APPLICATION OF REQUIREMENTS ENGINEERING METHODS TO SCALED AGILE SOFTWARE DEVELOPMENT PROJECTS IN COMMERCE AND INDUSTRY.
Catchy title. A tour de force.
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.
Didn't get a particularly high mark, though. One of my fellow assessors was being rather harsh, in my opinion.
Requirements Engineering is a discipline within software development. It is concerned with defining what tasks or functions a system should be designed to perform.
In the early years of computing the problems scientists were posed with involved getting machines to perform complex calculations such as the flight path of rockets or anti-aircraft projectiles. What
was required was fairly clear; how
to program a primitive IBM mainframe using machine code or assembly language to do it was presumably pretty bloody hard.
As computers became faster, systems more complex and programming languages more abstracted from low-level machine instructions, the problem 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?
Round about the 1990's it was recognised that one of the major causes of an increasing number of software project failures was the
requirements: that is, the way the people doing the software development had expressed what exactly the software should be designed to do.
A role was missing, and the term Business Analyst
was born: someone who could understand a 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.
The term Requirements Engineering
emerged a little later. Is it the same thing? My take on that is basically yes, but the term Requirements Engineer has been useful to emphasise the engineering aspect and to avoid confusion with more general market analyst or business consultant type roles.
We're talking engineering skills here: the proper use of analytical tools, models and notations to drive a rigorous software development process.
So now you know.
Work Experience Highlights
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.
For further fascinating details please see my CV as pdf
or check out my linked in profile...
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.