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.

Figure 1: Examples of the six Clarification Patterns. Red: clarification comments, blue: other comments (i.e. coordination). Left column: indecisive, middle column: rather good, right column: problematic

We offer to discuss these patterns and facilitate a discussion of the usefulness of such analysis in other projects that are similar (or not) to the IBM RTC project. In a collaboration, we could in particular investigate where requirements-related communication appears and how this knowledge helps to identify risks.

Further information about this project

I gave talks on this topic at CSER’12 Spring meeting and VIATeC Software Management Roundtable. Both presentations lead to great discussions, wonderful feedback, and ongoing collaborations in this exciting field. Also, we published (or are about to publish) the following scientific papers on this topic.

  1. Eric Knauss and Daniela Damian. Patterns of Requirements related Communication. In Björn Regnell and Daniela Damian, editors, Proceedings of Requirements Engineering: Foundation for Software Quality (REFSQ’12), Empirical Fair, Essen, Germany, 2012. Poster
  2. Eric Knauss, Daniela Damian, Germán Poo-Caamaño, and Jane Cleland-Huang. Detecting and Classifying Patterns of Requirements Clarifications. Proceedings of 20th International Requirements Engineering Conference (RE’12), Chicago, Illinois, USA, 2012, to appear.

I am very excited about this research and looking forward for any feedback. Please do not hesitate to contact me for further discussion.

Acknowledgements

I thank the IBM RTC team members who provided clarifications on our dataset when needed. This work has profited from invaluable feedback. For this I thank the SEGAL Lab members, Cliff McCollum, and the participants of the VIATeC Software Management Roundtable.

Advertisements

7 thoughts on “What are we supposed to do again?

  1. Hi Eric,

    Really interesting stuff !

    Here is some food for thought:
    (1) It would be really nice to study this further with respect to project success further down the line. For example, can you show that a project (or module) is delivered late (or is more defective) if you see a certain type or set of pattern(s)?
    If so, could you build an predictive model, or early warning system, that helps to avoid these situations in future?
    (2) Further of interest would be a qualitative study to investigate the root causes of these patterns, e.g. for pattern b) Procrastination: what was the cause to procrastinate?

    • Nico, thank you for the feedback. That is basically the line of thought I am currently following. But, as always, things are not simple. It might be that 2) is the prerequisite for 1). Also, I think that too many other factors influence project success. Perhaps build status or acceptance testing might be better candidates for analyzing the impact on this work.

      Currently, I try to get feedback from software managers on the usefulness of these patterns and their visualization. First feedback indicates that this new perspective on requirements is useful, but whether a specific pattern (e.g. indifferent) indicates a healthy or unhealthy discussion, depends on the context. Of course, managers are aware about the context. Therefore, I still think that the visualizations are useful, if presented in a timely manner.

      As a researcher, I am very curious about the context and I am excited to investigate which contextual parameters define, whether a clarification pattern is dangerous or not. Any input on this matter is welcome! I would also love to help anyone who plans to investigate similar effects.

  2. Pingback: MSR’12 Summary | Eric's blog

  3. Pingback: SecReq: Security Requirements Elicitation | Eric's blog

  4. Pingback: Planning for next show: RE’12 | Eric's blog

  5. Pingback: How can clarification patterns help developing software? | Eric's blog

  6. Pingback: Patterns of Continuous Requirements Clarification | Eric Knauss

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s