The Keynote at today’s REFSQ 2011 conference, delivered by Neil Maiden, ought to inspire, or revolutionize the entire requirements research industry.  Here are some key figures which requirements practitioners and researchers alike ought to be aware of:

• According to one estimation, over the past 15-20 years, over 600 papers on requirements engineering have been published, including hundreds of separate discrete authors.
• Over 300 delegates have attended each of the dozens of conferences such as REFSQ have been attended.
• And check this out: Perhaps as much as 100 Million Euros (approximately 150 million dollars) have been spent on requirements engineering research.

Neil asked a very intuitive, yet provocative question:  “What have we bought for 100 Million Euros”?  This is money spent by the taxpayers of the EU, US, as well as various other corporations who have funded requirements research.  Some of the seemingly obvious answers to what this money has bought practitioners–Use Case specifications, traceability, user stories, and various notations for data flow diagrams and UML–turn out to have their genesis in disciplines other than requirements engineering, such as the computer sciences or other separately-funded projects not within the sphere of requirements engineering, so it makes little sense to use the specifications developed for Use Cases or Data Flow diagrams  as justification for the buckets of cash contributed for requirements engineering research.

I thought about the projects I had worked on.  If my stakeholders spent 150 Million dollars on any project and had to even ask the question “what has it bought me?” I would probably be fired from and never be asked to return to the project–maybe I would even be blackballed from the entire requirements industry and would have to change careers (perhaps as a requirements researcher).  In this vein, Neil challenges requirements researchers to determine how their projects benefit industry.  Requirements researchers, he argues, should practice what they preach and attempt to apply the software development methodology to their own research methodologies in order to solve problems relevant to industry. Neil’s interest in analogical reasoning permeated the presentation, as evidenced by his didactic comparison between actual software development projects and requirements engineering research:

Neil used the image above to illustrate that requirements engineering researchers fail to practice what they preach–researchers tend to actually get stuck in what would be analogous to the “Design” and “Build” phase without really testing whether their results had any measurable effects on requirements practices.  Moreover, requirements engineering researchers use a waterfall research methodology in a world where most requirements work is actually done in an agile environment.  Neil’s observation can be summarized as: “Most Requirements Results do not directly inform requirements practice“.  In other words, Requirements Engineering researchers fail to validate or test their findings in the industry.  Therefore, I felt inspired to share the following insights from Neil’s talk, namely:

1. Requirements Engineering researchers should be the product managers of their ideas and ensure the adoption of their ideas, in the same way that a requirements product manager is responsible for the adoption of the software they deploy.
2. The funding model for Requirements Engineering research is problematic, in that it rewards pure research without ensuring that any business objectives or ROI is achieved.
3. Requirements Engineering researchers are not incentivized according to how well their ideas are adopted in the industry.  This speaks to a disconnect between research and industry, in that industry is measured according to how well the systems they specify are adopted.

The problems seem to be symptomatic to how requirements engineering research projects are funded. More specifically:

• Funding is granted to researchers without consideration to the business objective it might meet or the ROI it might achieve
• The ROI a research project might achieve is not required to be validated at the conclusion of the research–meaning a researcher can engage in a study without showing that the results of the research actually achieved a measurable objective
• Researchers are not incentivized based on how well they can help a business achieve a business objective, but based on how well they can write grant proposals.

These all speak to a fundamental issue with requirements engineering research–namely, that the way in which research is funded and encouraged seems to be disconnected from its practical value.  The goal of the REFSQ conference is to bridge that gap and encourage more participation from researchers in solving practical problems.  I hope to be an agent for this sort of revolution that Neil advocates tomorrow when I present ArgonDigital’s poster, which aims to engage researchers to solve a problem many practitioners face.  More specifically, we want to determine how to solve the problem of creating requirements which need to be understood by stakeholders with varying degees of linguistic ability in the language in which the requirements specification is written.  After all, the goal of a research institution is, or ought to be, to develop ideas, tools, and practices which solve problems practitioners face.  Therefore, I look forward to partnering with some enthusiastic researchers!  In the meantime, if you wish to help Neil transform the way in which requirements research is conducted by making it more relevant to practitioners like you and me, contact him at N.A.M.Maiden@city.ac.uk