Building tools to help software developers communicate effectively requires a deep understanding of their communication dynamics. To date we do not have good comprehension of why developers talk to each other as a result of some events in the life of their projects, and not of others. This lack of knowledge makes it difficult to design useful communication models and support systems.

Goal models have been found to be useful for supporting the decision making process in the early requirements phase. Through measuring contribution degrees of low-level decisions to the fulfilment of high-level quality goals and combining them with priority statements, it is possible to compare alternative solutions of the requirements problem against each other. But where do contribution measures come from and what is the right way to combine them in order to do such analysis? In this paper we describe how full application of the Analytic Hierarchy Process (AHP) can be used to quantitatively assess contribution relationships in goal models based on stakeholder input and how we can reason about the result in order to make informed decisions. An exploratory experiment shows that the proposed procedure is feasible and offers evidence that the resulting goal model is useful for guiding a decision. It also shows that situation-specific characteristics of the requirements problem at hand may influence stakeholder input in a variety of ways, a phenomenon that may need to be studied further in the context of eliciting such models.

Every bug has a story behind it. The people that discover and resolve it need to coordinate, to get information from documents, tools, or other people, and to navigate through issues of accountability, ownership, and organizational structure. This paper reports on a field study of coordination activities around bug fixing that used a combination of case study research and a survey of software professionals. Results show that the histories of even simple bugs are strongly dependent on social, organizational, and technical knowledge that cannot be solely extracted through automation of electronic repositories, and that such automation provides incomplete and often erroneous accounts of coordination. The paper uses rich bug histories and survey results to identify common bug fixing coordination patterns and to provide implications for tool designers and researchers of coordination in software development.

Replications play an important role in verifying empirical results. In this paper, we discuss our experiences performing a literal replication of a human subjects experiment that examined the relationship between a simple test for consistent use of mental models, and success in an introductory programming course. We encountered many difficulties in achieving comparability with the original experiment, due to a series of apparently minor differences in context. Based on this experience, we discuss the relative merits of replication, and suggest that, for some human subjects studies, literal replication may not be the the most effective strategy for validating the results of previous studies.

If designers of modelling languages want their creations to be used in real software projects, the communication qualities of their languages need to be evaluated, and their proposals must evolve as a result of these evaluations. A key quality of communication artifacts is their comprehensibility. We present a flexible framework to evaluate the comprehensibility of model representations that is grounded on the underlying theory of the language to be evaluated, and on theoretical frameworks in cognitive science.

Small companies form a large part of the software industry, but have mostly been overlooked by the requirements engineering research community. We know very little about the techniques these companies use to elicit and track requirements and about their contexts of operations. This paper presents preliminary results from an ongoing exploratory case study of requirements management in seven small companies, which found that (a) successful small companies exhibit a huge diversity of requirements practices that work well enough for their contexts; (b) these companies display strong cultural cohesion; (c) the principal of the company tends to retain control of the requirements processes long after other tasks have been delegated; and (d) the evidence rejects the simplistic view of a current "software crisis", as requirements errors for these companies, though problematic, are rarely catastrophic. We develop a number of hypotheses to explain these findings.

The use of viewpoints has long been proposed as a technique to structure evolving requirements models. In theory, viewpoints should provide better stakeholder traceability, and the ability to discover important requirements by comparing viewpoints. However, this theory has never been tested empirically. This paper reports on an exploratory case study of a key hypothesis of the viewpoints theory, namely that by creating separate viewpoint models to represent different stakeholder contributions, and explicitly merging them, important hidden requirements can be discovered. The case study compared two modelling teams using the i* notation to capture requirements for new Web-based counselling services for a large charitable organisation. One team used viewpoints; the other did not. The conclusions include that viewpoint merging improves the understanding of the problem domain, but is very time consuming. The process of merging was more important than the merged product. The study also indicates a need for better model management tools, as both teams encountered difficulty in managing large, evolving models.

Anchoring and adjustment is a form of cognitive bias that affects judgments under uncertainty. If given an initial answer, the respondent seems to use this as an 'anchor', adjusting it to reach a more plausible answer, even if the anchor is obviously incorrect. The adjustment is frequently insufficient and so the final answer is biased. In this paper, we report a study to investigate the effects of this phenomenon on software estimation processes. The results show that anchoring and adjustment does occur in software estimation, and can significantly change the resulting estimates, no matter what estimation technique is used. The results also suggest that, considering the magnitude of this bias, software estimators tend to be too confident of their own estimations.