For me, the highlight of Day 2 of REFSQ 2011 was the “Empirical Fair” poster session. In keeping with the theme of the Keynote address, researchers from academia and industry practitioners participated in an informal “matchmaking” session/presentation. The session allowed requirements engineers to share problems that required help from academic researchers, and researchers to work with industry to mine data for use in their own projects. I had an opportunity to share Seilevel’s own research idea with other participants in the conference, and I am grateful for the feedback I received, which will help us refine our topic and hopefully work to solve problems of crossing linguistic boundaries for requirements stakeholders. Thank you everyone who stopped by to speak with me! The best news, though, is that it preliminarily appears that the session was a success for both camps. I’ve received some follow up comments which indicate that Seilevel may be able to partner up with some researchers, both for our project and to help out others. More on that as it develops, but as a preview, here is the poster we submitted. That’s yours truly standing there with the far away look in his eyes:
I witnessed a lot of energetic dialog between the research and industry communities, as well as some commitments for the two sides to collaborate on projects. Unfortunately, I did not have an opportunity to speak with all of the poster presenters in detail, but all of them indicated that some research will lead to promising developments in requirements practice. Here are just a few of the highlights:
What Do User Stories Tell us about the Business Value? I spoke with Zora in person about her poster and attended her presentation. Throughout the conference, she touched on two themes: First, how does Agile requirements practice differ from Agile requirements literature? Second, what are the effects of implementing requirements engineering methodologies on business value? I think this approach mirrors or extends many of the ideas in Neil’s keynote address, and it was refreshing to see this alignment occur during the conference.
Interested in Improving Your Requirements Engineering Process? Try Requirements Patterns! Anyone who has worked with requirements for long enough begins to face deja vu after several projects. We typically see projects attempt to solve the same problems again and again. Why not leverage the work already done in order to keep from making the same mistakes? There is a pretty special place in Seilevel’s heart for Patterns, especially if they can lead to requirements reuse. This is why I was excited to talk to Xavier about a tool he is developing, PABRE, which can help discover patterns in requirements based on the repetition of certain lexical structures. I look forward to hearing more about PABRE in the future.
Intercultural Requirements Engineering for Software-Development: Culture and Its Impact on Requirements Negotiation. This was one of the presentations which focused less on how requirements are documented and more on the social and political nature of the requirements gathering process. There is indeed an intuition that culture affects the way requirements practitioners do their job, and negotiating or prioritizing requirements can be much more challenging and time-consuming if there are cultural boundaries. Leveraging studies in the social sciences and work in negotiation, Benedikt (whom I spoke with at the conference) and his coauthors intend to determine the effect of culture on negotiating requirements. An added benefit is that we learn about the cultural factors involved in negotiation so that we improve or tailor negotiation to make it more efficient.
I hear that the REFSQ organizing committee will be posting the pictures of each poster online, so check back on their website. Additionally, I would like to encourage everyone who reads this blog–especially requirements practitioners–to take just a few moments and read through the proposals above. Determine whether your organization has any data to contribute to their research. The proposals are only one or two pages each and in the end will solve some of the problems you face on projects!