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.
The figure above shows all potential clarification patterns that can occur when dividing the requirement lifecycle (= timeline, horizontal arrow) in four equal parts. This is the smallest number of parts that allows a reasonable discussion of suspiciousness with managers while still being small enough to systematically depict all (24 = 16) potential patterns. The black curved arrow shows a potential exemplary trajectory. When the exemplary trajectory is above the time line, this means that there is predominance of other communication in this time slice, when the trajectory is below the time line, the time slice is dominated by clarification. For each time slice, the grey area depicts which type of communication is dominating and the figure shows all possible combinations.
Whether one of these potential patterns is suspicious or not depends on the specific development process. The case study presented in our paper suggests that a predominance of clarification in the second half of the lifetime is indicative, but other project cultures and development processes might differ and this threshold might require fine tuning.
For me, this concludes a stream of research I started during my postdoc at UVic in which I explored together with Daniela Damian and in collaboration with Jane Cleland-Huang and Remko Helms the extent to which developer communication can be automatically analyzed to understand the status of their shared understanding. Now that I am satisfied with observable patterns of clarifying requirements continuously, I am starting to get really curious in understanding why certain patterns occur. I am specifically looking forward to apply this to cross-organizational development networks and software ecosystems.
Eric Knauss, Daniela Damian, Jane Cleland-Huang, and Remko Helms. Patterns of continuous requirements clarification. Requirements Engineering Journal, 2014.
Abstract: In software projects involving large and often distributed teams, requirements evolve through the collaboration of many stakeholders, supported by online tools such as mailing lists, bug tracking systems, or online discussion forums. In this collaboration, requirements typically evolve from initial ideas, through clarification, to the implementation of a stable requirement. Deviations from this expected course might indicate requirements that are poorly understood, need further negotiation, or better alignment with project goals. If not addressed timely, such problems can surface late in the development cycle with negative consequences such as rework, missed schedules, or overrun budget. This paper presents an approach that provides project managers’ with timely awareness of such requirements-related risks, based on automatic analysis of stakeholders’ online requirements communication. We describe a clarification classifier that automatically analyzes requirements communication in a project and detects clarification events, a catalogue of clarification patterns, and a pattern matcher that suggests communication patterns based on our pattern catalogue. Our approach has been empirically constructed and evaluated in a case study in the IBM Rational Team Concert (RTC) project. We discuss the applicability of our approach in other projects as well as avenues for extending our pattern catalogue towards a theory of clarification patterns.
Keywords: requirements clarification patterns · distributed requirements engineering · communication of requirements