Patterns of Continuous Requirements Clarification

I am extremely happy thatĀ Springer’s Requirements Engineering Journal has published our systematic analysis of requirements clarification patterns by which we extend our previous work on clarification patterns. Continue reading


How can clarification patterns help developing software?

One of the most intense and enjoyable events last year was the Ready-set-transfer panel (or: show) at Requirements Engineering Conference. I had the pleasure to present my work on the V:issue:lizer and to argue why I think it was ready for transfer into industry. The following video* (1:46 min) was part of my pitch on why the V:issue:lizer is relevant for software development:

So how can the V:issue:lizer help in this situation? Let’s first look on the visualization of the clarification trajectory derived from the discussion in the video (see a transcript in the making of section below). Continue reading

V:Issue:lizer: Exploring Clarification in Online Communication Over Time

In this post, I describe the V:Issue:lizer tool (the transcription of the video follows below). V:issue:lizer supports managers in their decision making process by analyzing

  • analyze stakeholder communication
  • analyze communication problems
  • identify domain and project experts.

Here is a preprint of our ICSE2013 Formal Tool Demonstration.

Continue reading

Planning for next show: RE’12


Last week I booked my flight and hotel for RE conference in Chicago. Apparently, there is lots of interest in the conference: Most recommended hotels are already booked out. I guess this indicates that we are going to witness a great event with many participants. The preliminary program indicates that our talk onĀ Detecting and Classifying Patterns of Requirements Clarifications is the last research talk of the conference at 11:30am on Friday.

What are we supposed to do again?

Patterns of Requirements Clarification in Software Projects

For ages, requirements engineering research focused on creating good documentation. This focus seems to contradict observations that can be made in everyday software projects:

  • Even perfect documentation needs to be read (and interpreted) by team members in order to establish a shared understanding of the requirements in the team, let alone the speed at which it gets obsolete.
  • Quite a few organizations do very well without comprehensive requirements documentation – especially in the field of agile software development.
  • Team members do in fact have extensive knowledge of the requirements and they often communicate it through informal or online discussions, as well as in project artifact repositories.

In a recent study of the project repository data in the large and distributed IBM RTC project, we studied online requirements-related communication and were able to identify 6 reoccurring patterns in these discussions (see Figure 1). Some of these patterns can be indicative of problematic requirements and thus useful to managers in diagnosing the health of the requirements development in their project. Continue reading