ore than half the cost of the development of complex computer-based information systems (IS) is attributable to decisions made in the upstream port ion of the software d e v e l o p m e n t process; namely , requirements specification and design . There is growing recognition that research on how teams actually go about making requirement determinations and design decisions can provide valuable insights for improving the quality and productivity of large-scale c o m p u t e r b a s e d IS development efforts [9, 12, 23]. Traditional models of group dynamics, group decision making, and group development are not rich enough to thoroughly explain the real-world complexities faced by software design teams. Most of this research was performed on tasks that were shorter, less complex and did not require the extensive integration of knowledge domains that characterizes software systems design [9, 12]. Knowledge is the raw material of software design teams. For complex projects, knowledge from multiple technical and functional domains is a necessity . Ideally, a software design team is staffed so that both the levels and the distribution of knowledge within the team match those required for the successful completion of the project. Because of knowledge shortfalls such as the thin spread of application domain knowledge in most organizations, however, this is seldom the case . In general, individual team members do not have all of the knowledge required for the project and must acquire additional information before accomplishing productive work. The sources of this information can be relevant documentation, formal training sessions, the results of trial-and-error behavior, and other team members. Group meetings are an important environment for learning, since they allow team members to share information and learn about other domains relevant to their work. Productive design activities need to revolve around the integration of the various knowledge domains. This integration leads to shared models of the problem under consideration and potential solutions. A software design team seldom starts its life with shared models of the system to be built. Instead, these models develop over time as team members learn from one another about the expected behavior of the application and the computational structures required to produce this behavior. This means that team members need to be speaking the same language (or, at least, dialects whose semantics are similar enough to facilitate communication and understanding) in order to share knowledge about the system. Knowledge acquisition, knowledge sharing, and knowledge integration a r e significant, t ime-consuming activities that precede the development of a design document. The purpose of this article is to examine how these activities unfolded over time inside an actual software design team. Two related questions with respect to this team will be resolved: 1) How do the group members acquire, share, and integrate project-relevant knowledge? 2) Do the levels of participation in these activities differ across team members? The f ind ings r epo r t ed h e r e challenge some of the conventional wisdom and common practices of managing software design teams. An initial caveat is that the design team studied here worked in a research and development environment where knowledge acquisition, sharing, and integration activities are accentuated. However, to varying degrees, these activities characterize most software projects . A better understanding of the role and process of knowledge acquisition, sharing, and integration in software design has very real implications for managing large software projects, particularly in the areas of planning, staffing, and training.