ArgonDigital - enterprise automation experts

Share This Post

Live from RE’13: Neil Maiden’s Keynote, Creativity, and the State of Requirements Research

It’s no secret that I’m a fan of Neil Maiden’s work, and this is the second conference keynote address I’ve had the pleasure to listen to.   He always manages to shake things up in good ways within the requirements engineering community.  I won’t go into all the details, but there were three primary themes in his Keynote Address, most of which I agree with.

It’s impossible to not think about design when defining requirements, and requirements researchers should focus more closely on design

Neil pointed to studies which demonstrate that as soon as a stakeholder, analyst, or developer begins to think about a requirement, their focus shifts nearly immediately to design.  Furthermore, the types of problems companies tend to throw the most money at and hire the most experts on tend to be design problems.  We tend to think of requirements and design as activities which tend to happen separately, and focus our efforts and development processes around keeping the problems distinct.  This distinction is artificial (even though it is important to stay focused on the business problem being solved, and we should try to spend more energy and effort up front working on design. As Neil put it, (paraphrasing an architect whose name slips me at this time), “We should not strive to build what someone asks for, we should strive to build what they never even thought to ask for.”

Requirements Engineering research used to be (circa 1993) focused very much on requirements, but has shifted more towards a focus on Agile, solving design problems, and business analysis.

He used a great PowerPoint animation to demonstrate the focus of requirements over the course of the past 20 years.  Sometime around the early 2000’s Agile became a focus, and is likely here to stick around for a long while.  Likewise, activities related to business analysis is actually fairly new to requirements research community (within the past 10 years).  This points to a need for more collaboration between researchers focused solely on requirements engineering and business analysts/designers.  Indeed, I’ve seen indications at this conference that in many organizations, there is an artificial distinction between BAs and requirements engineers.  In fact, in some cases, BAs don’t exist at all in organizations.

Requirements Practitioners Need to Take More Risks and Incorporate More Creativity into Their Elicitation

This was really the “meat” of the presentation.  As BAs, we do not incorporate enough creative approaches in order to find solutions to business problems. Some techniques that we might incorporate into our sessions which can promote creativity and discover solutions which we never thought possible.  The best example Neil discussed was around the building of the new airport in Belfast, in which the designers of the airport needed to think about how to reduce noise, pollution, and traffic around the airport.    However; they were faced with certain constraints with designing a solution, one of which being Belfast’s unpredictable weather.   Part of the process to come with a solution involved Neil’s team asking the stakeholders what would be possible if they removed this constraint.  Doing this forced the designers to think about the airport in a new way, encouraging innovation and flow of ideas that would have never previously been considered.  Neil encouraged the use of techniques like finding analogous problems to the one you are attempting to design for, and using that analogy to uncover solutions which might be applicable.

Overall, the talk was very encouraging and inspiring and made me think about how we can better incorporate creativity throughout the requirements sessions.  There should be ways to do this even in organizations which resist it.  Personally, I have been able to covertly work in creativity in the requirements process through games, toys, or even opening up stakeholders to ideas that they did not think possible by providing them with a safe environment.   I will probably write more on this in a future blog post.  Meanwhile, if you ever get a chance to see Neil speak, please do so.

By the way, our models tutorial yesterday was officially a success!  We received some of the best feedback ratings we have ever received for teaching it, and some of the sharpest increases between our pre-tests and post-tests!  We are both incredibly happy with the results and it bodes well for more similar experiences.

Tchau for now from Rio! I’m off to attend the RE Interactive session!

Live from RE’13: Neil Maiden’s Keynote, Creativity, and the State of Requirements Research

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage