REFSQ 2011 provided academia and industry the chance to dialogue on how to best solve problems.  The poster session was one way in which the conversations were facilitated.  However, some of the best ideas on how to leverage work done by researchers were brought to light in unscripted conversations which occurred outside of the program–between sessions and over meals or the occasional beverage.   One particular insight discussed in several independent conversations, was the idea that many of the problems practitioners face are social in nature.  This might be one of the biggest disconnects between the focus of much of the research done in requirements engineering and its actual use.   Tools, models, and formal methods are great–and I’m not disputing that research in these areas have provided me as a practitioner great value.  However, when I think about the most challenging, time consuming, and frustrating aspects of my job, they have very little to do with whether I used a particular model or tool.  The problems I usually face cannot be solved using any known tool or modeling method.  No, the biggest problems I most often encounter fall into these general areas:

• Political:  For example, it might be difficult for me to obtain sign off on a particular document or schedule time with subject matter experts.  There might be certain questions which are deemed as “too sensitive” for me to even ask so that I could even complete a particular model.
• Communication:  Message received did not equal message transmitted.  This could be due to language barriers, the political issues, or because I simply did a bad job at communicating.
• The Problem that a system is attempting to solve being solved is poorly understood and articulated even more poorly.   All the models and methods in the world are for nothing if they do not provide some core business benefit.
• User Adoption:  Users will not adopt the system.  They feel hampered by a new system and are reluctant to change.  Some of them may feel as though they are being automated out of a job.  There may be other political factors which influence adoption as well.

I’m not saying that there was no work presented at the conference that helped solve these problems.  In fact, take a look at the conference website to see the work presented on elicitation methods.  For example, there was a great poster by Lauri Scheinholtz and Ilona Wilmont which proposed studying elicitation methods to determine whether a sort of elicitation “pattern” could be developed.  I have also already mentioned some of the other research on the less “formal” aspects of requirements engineering.   And much of the “formal” work does indirectly affect how well I communicate or solve the political problems on my projects.

I suppose that some researchers might counter-argue that the entire reason I have communication problems on my project is because my communication is not leveraging a particular model or using a particular methodology or tool.  Fair enough.  If this is the case, then, in the spirit of Neil’s keynote, we should conduct studies which determine the direct effectiveness of these tools, methods, and models. This way I know which models or tools to adopt that would best suit the particular problem I face on my project.  I could probably be convinced that formal methods, are applicable to solving political problems–in fact I have blogged on this very topic here.   Additionally, the best work isn’t work that is done in a vacuum–but work that is adopted and used to solve problems.  Researchers might benefit from doing a little more work to market their ideas.  One of the running jokes at the conference was that one could respond to every proposal (especially the industry proposals) by saying either “This problem was solved 20 years ago” or “this doesn’t scale”.  The former speaks to the need for the work performed on the research front to be pushed out to industry.  If there are existing solutions to problems I face–why don’t I know about them?

Unfortunately, I did not attend the workshops on Thursday, so perhaps there was some discussion then related to the fuzzy, messy, non-formal part of requirements work.   If not, perhaps one suggestion could be followed based on several discussions I overheard:  As part of the workshops, perhaps someone from industry could bring a problem to be solved, and the entire room attempts to solve it.  This would best leverage all the talent and brains at the conference.

I’d like to close by congratulating all the organizers.  The conference went off without a hitch, and the preparation and execution is much appreciated.  When things run so smoothly, it’s difficult to see all the hard work that is done in the background.  I look forward to see what comes in the next edition of REFSQ, and to more collaboration!