SEARCH

SEARCH BY CITATION

Abstract

  1. Top of page
  2. Abstract
  3. Introduction
  4. Operational Definitions and Framework
  5. Review of IB and RE Research
  6. Conclusion
  7. Notes
  8. References

This paper provides an overview of the existing research on information behavior (IB) in the practice of software requirements engineering (RE) and the research which, although it does not refer to IB or to RE by name, addresses the concepts and theories of one within the framework of the other. The paper begins with operational definitions of the terms “requirements,” “requirements engineering,” “information behavior,” and “information behavior in requirements engineering” to set the framework for this analysis. A number of authors have written extensively on theories of IB. Similarly, although perhaps less well known to those in the Library and Information Science (LIS) community, many terms exist for the field and practices of software requirements elicitation, documentation and maintenance, herein referred to as RE. Although RE is still a relatively young field, having emerged from computer science and software engineering in only the past 20-30 years, research in the field is diverse and growing. However, little research has taken place specifically on IB in RE. In some cases, research on IB and RE progresses on parallel paths, even utilizing the same terminology, without a recognition of the other community's work. The paper follows the operational definitions with a review of the collective set of literature covering IB in RE and that which reflects IB in RE but does not label it as such. The next section includes a discussion of what the reviewed literature reveals about the state of research and practice in this area, and the paper concludes with suggestions for future research.


Introduction

  1. Top of page
  2. Abstract
  3. Introduction
  4. Operational Definitions and Framework
  5. Review of IB and RE Research
  6. Conclusion
  7. Notes
  8. References

Software requirements engineering (RE) and information behavior (IB) are both complex and often contentious topics, made even more complex when investigated together. The purpose of this overview paper is to provide readers a basic familiarity with each topic and the ways in which research and theory overlap between the two. Generally speaking, there is little research taking place specifically on this overlap, but that limited research is a useful starting point for additional IB research, RE research, and RE practice. This paper begins with operational definitions of the terms “requirements,” “requirements engineering,” “information behavior,” and “information behavior in requirements engineering,” identifies some of the specific ways in which IB is foundational to RE practice, reviews the existing research literature on the topics, both independently and together, and discusses implications and future directions of that research. Rather than focusing on a specific concept of information or a specific type of IB, the goal for this paper is to provide a starting point for a further, more detailed analysis of different theories and practices of IB throughout the software development lifecycle (SDLC) which can be effectively communicated to and utilized by RE practitioners.

Operational Definitions and Framework

  1. Top of page
  2. Abstract
  3. Introduction
  4. Operational Definitions and Framework
  5. Review of IB and RE Research
  6. Conclusion
  7. Notes
  8. References

What are requirements?

Attempting to define the term “requirements” as used within the software development community is much like trying to define the term “information” within the LIS community. Individuals working in software development most likely each have a conceptual understanding of requirements but would find it difficult to provide a succinct definition of the term. Some (Gemino & Wand, 2004, and Sutcliffe, 1996) take a positivist position regarding requirements, conceptualizing them as physical obiects which can be identified, captured, categorized and stored for later use. Others (Alvarez, 2001, Goguen, 1992, and Siddiqi, 1994) regard requirements as more fluid, understanding them as always determined by and emerging from contextual realities. In this constructionist conceptualization, requirements can be documented at best as sets of known possibilities, dependent upon the perspectives and contexts of the potential users of the system.

The latter framework's focus on specific contexts affords a complex, detailed understanding of the system from the points of view of its potential users. The positivist framework, however, provides a simpler conceptualization which more easily allows developers to build a finite, testable, releasable software system. While a reflective individual working in software development might easily understand the constructionist framework, she would likely find its application difficult when trying to balance a project schedule, budget, staff, and fixed delivery date. Therefore, a working definition which more often represents that practitioner's viewpoint describes a requirement as anything an information system must or must not do in order to meet the project stakeholders' stated needs.

Stakeholders are those individuals or groups of people who have an interest in the software under construction. Those interests may range from the financial interest of a corporate CEO or stockholder to the emotional interest of a user of an existing system who seeks relief from the frustrations of the current tool. Requirements Engineers are also stakeholders, since the success or failure of a development project often reflects upon their work.

The success of a completed software system is often measured against these stakeholders' stated needs, but needs often cannot be adequately or accurately communicated. Stakeholders may not want to acknowledge their own needs, may not be capable of identifying those needs, or may not be capable of communicating the identified needs to others. Similarly, the interactive process of a stakeholder communicating her identified needs to another person attempting to document those needs may change the need itself, its interpretation by the stakeholder, or the way in which she communicates it. Just as requirements may be understood from both positivist and constructionist perspectives, so too may stakeholders' needs. RE practitioners typically adopt the positivist perspective toward stakeholders' needs for the reasons of simplicity stated above. The common use of these positivist frameworks within rapidly changing, emergent systems development and usage contexts may contribute to the high percentage of projects viewed as failures.

What is RE?

The field of RE includes a variety of roles, practices, tools and methodologies. Terms used to describe the practitioner's role include but are not limited to Requirements Engineer, Requirements Analyst, Business Analyst, Systems Analyst, and Product Manager. As Rubens (2007) points out, titles are not the only things which differ among RE practitioners and practices. The work performed by a requirements professional may differ by his geographic setting, organizational setting, title, and the perceptions of others within and outside his particular area of practice. Rubens states that, “although there is patently overlap with RE, the practice of business analysis includes other activities that appear to be outside the scope of RE” (p. 121). Others in the requirements community put varying levels of emphasis on one's title, often arguing instead that the titles are simply relatively interchangeable labels for a range of tasks and responsibilities (Seilevel, 2007a).

A corresponding disagreement exists regarding which tasks constitute RE and which methods and tools are best suited for the work. RE practitioners frequently refer to a number of popular how-to books on RE, including those by Hooks & Farry (2001), Wiegers (2003, 2006), Gottesdiener (2002), Cockburn (2000), Robertson & Robertson (2006), and Wiley (2000). Additionally, authors have noted the importance of RE within the information system design and development process in a number of different literatures, including project management (Brooks, 1995, Gilb, 1988, and Yourdon, 1999), usability engineering (Mayhew, 1999), user-centered design (Cooper & Reimann, 2003), and new media design (Girard and Stark, 2002). Articles on RE best practices can also be found in industry publications (Young, 2006), conference proceedings (Kwan, Marczak, & Damian, 2007), and academic publications (Groner & Arthur, 2005).

Problems introduced during the requirements phase of a software development project lead to erroneous systems design and implementation, making those problems more costly and time-consuming to fix. For example, one estimate suggests that the cost to fix a defect in an operational software system is 40 to 1,000 times higher than if that defect were discovered during requirements work (Hooks & Farry, 2001, p. 9). In a study of systems development problems in twelve organizations, respondents stated that nearly half (128 out of 268) of the difficulties encountered during software development were requirements problems (Hall, Beecham, & Rainer, 2002). Given the numerous possible areas for difficulty during software development proiects, including such factors as budget, staff capabilities, schedule, new technologies, changing team makeup, and geographic, language and culture differences, RE represents a disproportionately high percentage of the reported problems. The Standish Group's biannual CHAOS report on development success and failure has indicated for many years that requirements problems are key factors in proiect failure. In the initial report, the top three reasons for proiect failure, “Lack of User Input,” “Incomplete Requirements & Specifications,” and “Changing Requirements & Specifications,” were all directly related to poor requirements work (Standish Group, 1994).

The specific tasks of RE practice vary by software development methodology. In more traditional development approaches, such as the waterfall or spiral model, RE takes place early in the proiect timeline. The requirements phase of development ends once a complete set of requirements for the next release of the system has been “baselined,” a process through which the requirements are approved as documented. At that point, software developers begin to design and build the system, based on the fixed set of identified requirements. Changes may be made to the baselined requirements, but only through strict change control procedures. In more recently-introduced development methodologies, such as Agile or Extreme Programming, stakeholders and potential users often work directly with developers to provide requirements as the developers build individual features of the system. In these approaches, requirements may be documented much less formally, if at all. Since the majority of RE practice and research takes place using the more traditional development approaches, the definitions and discussions of RE in this paper reflect those frameworks.

For the purposes of this paper, the term “RE” refers to any and all activities by which the requirements for an information system are communicated, collected, analyzed, documented, disseminated and updated during the overall software development lifecycle (SDLC). As used here, a Requirements Engineer is any person who performs the work of RE. These definitions are used in this paper for their general, inclusive nature. Since practitioners in the field do not agree on any single definition of the field or of the correct title for one working in the field, any attempt to restrict a review of research to such a constrained view would be counterproductive. Instead, this paper seeks to take a wider view of the research on IB within all aspects of RE.

What is IB?

Definitions of and discussions about the term “information behavior” are equally diverse. As used in the Library and Information Science (LIS) community, IB has developed in part from work on information retrieval (IR) and information needs, seeking and use (INSU). Discussions among LIS practitioners and researchers over the applicability of the term “IB” has taken place for years, including perhaps the most public discussion of the proposed use of the term in Pettigrew, Fidel, & Bruce's 2001 ARIST chapter among JESSE listserv participants (JESSE, 1999). Such discussions have more recently resulted in survey monographs, including those by Spink & Cole (2005), in which authors contribute ten different perspectives on the topic, and by Fisher, Erdelez, & McKechnie (2005), which includes 72 specific theories of IB. Even though some of the two books' theories of IB overlap, the variety of perspectives available is substantial.

Given this spectrum of perspectives on the nature of IB, it is difficult to pinpoint a single, overarching definition of the term. As with the term “RE,” the understanding of IB used in this paper is purposefully wide and inclusive. As used here, information behavior includes the ways in which individuals and groups create, identify and express specific needs for, seek and/or encounter, apply, change through their experiences with, and recreate information. Also as with the term “requirement,” a definition of the term “information” is outside the scope of this paper, but the combination of Hj0rland's “subjective/situational” assertion that “something is information when it is informative” (2007, p. 1449) and Wilson's notion that “the totality of human behavior in relation to sources and channels of information, including both active and passive information seeking, and information use” (2000, p. 49) is a useful framework within which to understand information for the purpose of this discussion.

These operational definitions of IB and information are adopted here in order to investigate the many ways in which information is created, communicated, and used within the software development lifecycle (SDLC) in relation to RE. The frameworks and perspectives investigated here are introductory by design, but they touch on core aspects of both IB research and RE practice. It is expected that this introductory approach to fundamental subject areas will make this paper of more immediate use to LIS and software development researchers and practitioners.

What is IB in RE?

What, then, is specifically meant by “IB in RE?” The phrase as used in this paper represents the diverse collection of individual- and group-level information behaviors exhibited by both Requirements Engineers and other project stakeholders in RE practice. For example, Requirements Engineers elicit, collect and help collaboratively generate information about information systems to be developed, in the form of a project's requirements. A project's stakeholders generate and communicate their requirements within varying groups as they define and refine the system's purposes and functionality. Requirements Engineers create artifacts, including diagrams, glossaries of terms, databases of requirements, narrative descriptions of a system's functionality, and traced relationships between and among them all, thus codifying the information about the project. As requirements are elicited and documented, Requirements Engineers use information repositories, both digital and printed, to store and to communicate requirements to those who use them, a process which usually results in additional information-generating and documentation activities. Software developers and testers seek and encounter information from these requirements artifacts as they build and test systems, but they also seek and encounter information outside the codified sources. A project's participants also avoid or ignore requirements information made available specifically to help those participants more effectively do their work.

While this list is a subset of the many ways in which IB takes place within the overall software development process, it reflects the ubiquity of information-related activity in RE and suggests that practitioners may not recognize the ways in which that activity is fundamental to and inherent in their work. The list does not include, and this paper does not address, information behaviors exhibited in other aspects of software development projects, such as project management, database architecture, or user-interface design. This limited framework for investigating IB in RE provides a narrow yet challenging starting point for a future, larger investigation of IB in all aspects of both traditional and more recently-introduced development methodologies.

Given these operational definitions and practical examples, of what specific use are the theories of IB to RE practice? Much RE work in industry takes place without a recognition of, much less a thorough understanding of, the theoretical perspectives on IB underlying the ways in which people generate, capture, share, and use information. An introduction to the theories of IB can offer Requirements Engineers new ways in which to comprehend the often confusing individual and social behaviors encountered in RE work. While these perspectives may not provide Requirements Engineers with the only answer or the best approach to RE challenges and practices, they may spur new ideas which lead to innovative processes, frameworks, or tools to improve RE and the success rates of information systems development projects. We discuss several IB theories which may be especially useful to this end in greater detail below.

Review of IB and RE Research

  1. Top of page
  2. Abstract
  3. Introduction
  4. Operational Definitions and Framework
  5. Review of IB and RE Research
  6. Conclusion
  7. Notes
  8. References

Research on IB in RE

Although the importance of IB in RE seems clear, there has been little research specifically addressing the information behaviors of those involved with RE, whether Requirements Engineers or other project stakeholders. A search of the Library and Information Science Abstracts (LISA) database found no sources which matched the terms “information behavior” and “requirements engineering” and 28 documents which matched the term “requirements engineering,” suggesting that, although researchers may publish work on RE in LIS journals, they do not explicitly associate that research with IB. A search of the journal Requirements Engineering returned no sources for the term “information behavior,” two sources each for the terms “information seeking” and “information use,” and four sources for the term “information needs.”

Alvarez's (2001) study of the ways in which people describe information systems to be replaced by new systems provides an example of a social constructionist view of IB in RE. She explains that “IS development and requirements analysis interviews are events through which social reality is constructed, more importantly, they are power laden processes” (p. 401). Alvarez's focus on the discursive practices within RE and the social construction of reality echo Tuominen, Talja, & Savolainen's (2005) notion of social constructionism as the ways in which “information practices, actors, and technologies are constructed in discourse and conversation” (p. 331). Writing almost a decade earlier, Gougen (1992) posits a similar understanding of the nature of IB in RE:

However, requirements are emergent, in the sense that they do not already exist in the minds of clients or requirements engineers (or anywhere else); instead, they gradually emerge from interactions between requirements engineers and the client organisation. Moreover, requirements are open: they are always subject to change, because organisations and their contexts continually change. Requirements are also local, in that requirements documents must be interpreted in the context of a particular organisation at a particular time…. Moreover, they are contingent, because they are an evolving outcome of an on-going process that builds on prior interactions and documents. (p. 11, emphasis in the original)

Siddiqi (1994) provides an additional example of a social constructionist view on IB in RE. He comments that “assumptions about things like organizations and society invariably become embedded in the requirements method as it is developed,” going so far as to assert that “reality is socially constructed as a result of interactions among participants in the requirements process” (p. 19).

Poltrock, Grudin, Dumais, Fidel, Bruce, & Petjersen (2003) also specifically discuss IB in RE, saying, “This information space is not a coherent collection readily available to the designers; finding and sharing the information needed to define their product is part of a design team's work” (p. 239). The authors go on to explain the different ways in which information retrieval activities in the project took place individually, collaboratively, using a repository, and via interaction with other people (p. 241). Desouza (2003) also describes interpersonal and computer-based IB activities related to RE, focusing specifically on reasons why the computer-based information repositories are less likely to be used in the software development process (p. 100). Finally, Walsh & Shneider (2002) highlight the importance and danger of the uses of RE practices and the resulting artifacts, saying, “Relying on complete requirement analysis may actually contribute to failure because of overconfidence and because of ignoring risks” (section 4, ¶ 1).

Research related to the topic of IB in RE

Although the preceding section shows that authors report very little research specifically on IB in RE, the many perspectives of IB theory can be found, albeit often unstated, in research on RE and information systems development more generally. Research in RE typically takes one of two approaches. In one approach, researchers investigate methodologies and tools to improve the current state of RE practice, often adopting a cognitivist approach to capturing a finite set of existing, agreed-to requirements (Gemino & Wand, 2004, and Sutcliffe, 1996). The other common approach proposes a more social constructionist view of information systems development in which the requirements are emergent from the social context and various interactions within which they are formed (Galal & Paul, 1999, Goguen, 1992, Rose, 2002, and Truex, 1999). This split mirrors differences among IB theorists who take a philosophical realist perspective on IB (e.g., Belkin, 2005, Kuhlthau, 1991, and Taylor, 1968) and those who view information as socially constructed and contextual (e.g., Agre, 1995, Frohmann, 2004, Hjørland, 2007, Talja, Tuominen, & Savoleinen, 2005, and Wilson, 1997).

In the case of Urquhart's 2001 paper, RE practices are cited as potentially useful in IB work, even though she states in the opening sentence that “any relationship between information behaviour analysis and the structured approach to information requirements analysis of conventional systems analysis seems remote” (Section 1). Through her analysis, Urquhart shows that there are important “similarities in the approaches, despite the differing provenance (software engineering and information science)” (Section 9, ¶ 2). Also, even when the literatures of IB and RE may not specifically refer to each other, at times they use strikingly similar terms and concepts. For example, Davidson states that RE “is characterized by ongoing sensemaking among stakeholders” (2002, p. 329), utilizing a term familiar in LIS. Pettigrew, Fidel, and Bruce (2001) offer an important perspective and caveat on the lack of collaborative or cross-discipline work on IB in RE:

Most researchers who study information behavior are not personally interested in the design of systems and services, and they report their studies to the benefit of other researchers in information behavior. This separation between the “human” side and the “system” side of information behavior is not useful if we believe that information systems and services should be designed to support information behavior and that the design of such systems be based on our understanding of this behavior. (p. 64)

The IB concept of communities of practice also applies to RE research and practice. Davenport & Hall (2002) say that a community of practice “denotes the level of the social world at which a particular practice is common and coordinated, at which generic understandings are created and shared, and negotiation is conducted” (p. 172). While this definition reflects the focus and goals of a typical information systems development team, the authors are careful to explain how the two differ:

Communities of practice are not goal driven (unlike teams and projects), nor are they necessarily deadline driven. Freedom from such constraints makes them, in some circumstances, environments that are more hospitable to sharing and synergy than conventional competing organizational subgroups. (p. 182)

Since project teams do not constitute such communities, of what use is the concept to RE work?

Communities of practice are composed by those people who work as Requirements Engineers, both within organizations and outside organizational boundaries. While it is easy to see how RE work involves information related to a current systems development project, IB related to the meta-information about RE work is less explicitly discussed. The information behaviors of Requirements Engineers reflect many reported in the literature about communities of practice, including Irick's (2007) focus on tacit knowledge within a community, Davenport & Hall's concept of a “corpus of cumulated experience which becomes, in itself, a key artifact in community activity” (2002, p. 176), Savolainen's “institutional activity that consists of more or less formal sets of rules concerning, among other things, what should be considered ‘;proper’ information seeking” (2007, p. 125), and Wenger & Snyder's assertion that as communities of practice “generate knowledge, they reinforce and renew themselves” (2000, p. 143).

While these concepts are of great importance to practicing Requirements Engineers, they receive little attention from researchers. As Cheng and Atlee (2007) report, only 10-15% of research in RE is “evaluation-based” (“whose mission is to assess the state of the practice and evaluate proposed advances to the state of the art”), while the remaining research is “solution-based” (“which emphasizes technological advances that make progress towards solving RE problems; such research is often accompanied by proofs-of-concepts or pilot studies that show the potential of the proposed ideas”) (p. 290).

The juxtaposition of current research addressing IB in RE with the current practice of RE suggests that Requirements Engineers employ theoretical frameworks and software tools which seek to meet others' information needs the wrong way. As Poltrock, Grudin, Dumais, Fidel, Bruce, & Petjersen (2003) and Desouza (2003) note, software developers often prefer to seek information from people, not document repositories. The developers prefer the additional context provided during an interpersonal discussion of a requirement, and current RE software tools do not easily support the documentation of a requirement's contextual setting, meaning, or importance. The RE community of practice has built an “institutional circuitry” (Agre, 1995, ¶ 11) which constrains the possible creation, collection and communication of requirements information, and that circuitry does not appear to meet the needs of other key communities. The focus of RE practice and the functionality of RE tools demand greater attention in order to propose useful, not easy, solutions to these information problems.

Analysis of the current state of research

The lack of research specifically addressing IB in RE would seem to suggest that such research is not of interest, of use, or well-received by researchers or practitioners in LIS or software development. As evidenced by Cheng and Atlee's (2007) review, the majority of research published in RE is focused on incremental improvements to established practices, not paradigm-shifting ideas. RE is still a relatively young field, having formed from the only slightly older field of software engineering. As such, it may be that the RE field is too young to be ready to shift – it may still be trying to establish an initial paradigm. Akkermans & Gordij (2006) question whether existing research merits the description “scientific,” given the manner in which it is currently undertaken.

The popularity of instructional, rather than self-reflective, monographs on RE practice further suggests that RE practitioners are interested in reading about what to do, not about principles underlying what they do. Then again, many Requirements Engineers may simply not recognize the value of research and research findings to their day-to-day work. As one RE messageboard respondent stated when commenting on academic information sources, “The majority of what I've seen is: 1) steeped in academic-speak to the point they are essentially unreadable, 2) aimed specifically at other academics and not real-world practitioners, and 3) don't use a lot of examples that I could apply to work I do” (Seilevel, 2007b). Additionally, the work required to achieve an understanding of IB concepts is likely to be more than most Requirements Engineers are willing to undertake, especially if “they perceive that their world is working without it” (Pettigrew, Fidel, & Bruce, 2001, p. 55).

Although research on IB in RE may be sporadic, research on IB certainly is happening within the LIS community, and research on RE is happening within the software engineering community. Even though the two research domains contain similar terminology and provide fertile ground for inquiry, very little crossover is taking place (see Davidson, 2002). Such isolation of research activities constitutes missed opportunities for IB research, RE research, and RE practice. RE's specific focus on the creation, collection, dissemination and management of information within a social context provides a number of opportunities for the investigation of IB theories, from the more cognitivist to the postmodern. IB's wide range of theoretical viewpoints provide RE research with multiple hermeneutics for the investigation of RE practice and theory. Finally, the principles of IB theory offer RE practitioners valuable insights into their own patterns of behavior, their working contexts, and the mangle of practice in which their work creates and is shaped by information and IB (Pickering, 1995).

Conclusion

  1. Top of page
  2. Abstract
  3. Introduction
  4. Operational Definitions and Framework
  5. Review of IB and RE Research
  6. Conclusion
  7. Notes
  8. References

This review shows that, while research is taking place on IB in RE, it remains quite limited. Research in RE primarily addresses technical or technological problems of practice, not the theoretical underpinnings of the field. Research in IB has provided a number of theories of information behavior, but those theories have rarely been used to help understand the field of RE. To date, only a small collection of research exists specifically on the topic of IB in RE. Great opportunity remains for additional work.

Additional work on connecting research and practice is warranted in RE. Practitioners and researchers both recognize the difficulties they face in communicating and addressing questions from the other's community, but neither has been able to make that connection well to date. The general unfamiliarity most Requirements Engineers have with theories of IB might make any attempt to utilize work on IB in RE to bridge research and practice even more difficult. That unfamiliarity, however, would require the bridge to be one of education, rather than one simply of implementation, which could provide a stronger tie between the two communities.

In addition, a careful analysis of RE research to uncover parallels and potential overlap with theories outside of LIS could prove fruitful for research and practice. Given the strong applicability of IB theories to RE practice, particularly when juxtaposed with the dissimilarities between software development and librarianship, one wonders what other fields of study hold similar benefits for understanding and improving RE practice and IB research. Continued research into IB in RE could help identify additional fields of inquiry for IB research and additional theoretical perspectives on RE practice.

Most Requirements Engineers would not say that they practice information behavior or even that they study information for a living. Since most RE research is focused on the current practices of the field, it is not surprising that information behavior is not frequently studied by RE researchers. The RE community certainly welcomes the sort of incremental improvements provided through most RE research, however, further research on IB in RE could provide entirely new viewpoints and paradigms for the field. For example, researchers could investigate the impact on software quality of using databases and documents to manage information which practitioners prefer to share in person, or the ways in which current RE tools could be improved by supporting the behaviors posited by various theories of IB.

Even if the field of RE is still settling on an initial paradigm, the insights afforded by IB theories could help provide a more robust foundation for that paradigm. Given the ubiquity of software in our lives, research which will help Requirements Engineers to improve that software is an important and rewarding focus for IB researchers.

Notes

  1. Top of page
  2. Abstract
  3. Introduction
  4. Operational Definitions and Framework
  5. Review of IB and RE Research
  6. Conclusion
  7. Notes
  8. References

The author would like to thank Dr. Philip Doty for his thoughtful feedback on this work.

References

  1. Top of page
  2. Abstract
  3. Introduction
  4. Operational Definitions and Framework
  5. Review of IB and RE Research
  6. Conclusion
  7. Notes
  8. References
  • Agre, Philip E. (1995). Institutional circuitry: Thinking about the forms and uses of information. Information, Technology and Libraries, 14 (4), 225230.
  • Akkermans, H. & Gordij, J. (2006). What is this science called requirements engineering? in MartinGlinz and RobynLutz (Eds.), Proceedings of the 14th IEEE international requirements engineering conference (RE'06) (pp. 266271). Los Alamitos, CA: IEEE Computer Society.
  • Alvarez, Rosio. (2001). ”It was a great system:” Face-work and the discursive construction of technology during information systems development. Information Technology & People, 14 (4), 385405.
  • Belkin, Nicholas J. (2005). Anomalous state of knowledge. in KarenFisher, SandaErdelez, & Lynne (E.F.)McKechnie (Eds.), Theories of information behavior (pp. 4448). Medford, NJ: Information Today.
  • Brooks, Frederick P. (1995). The mythical man-month: Essays on software engineering. Boston: Addison-Wesley.
  • Cheng, B. H., & Atlee, J. M. (2007). Research directions in requirements engineering. in Lionel C.Briand & Alexander L.Wolf (Eds.), 2007 future of software engineering (May 23–25, 2007). International conference on software engineering (pp. 285303). Washington, DC: IEEE Computer Society.
  • Cockburn, Alistair. (2000). Writing effective use cases. Boston: Addison-Wesley.
  • Cooper, Alan, & Reimann, Robert. (2003). About face 2.0: The essentials of interaction design. Indianapolis: Wiley.
  • Davenport, Elisabeth, & Hall, Hazel. (2002). Organizational knowledge and communities of practice. in BlaiseCronin (Ed.), Annual review of information science and technology (Vol. 36, pp. 171227). Medford, NJ: Information Today.
  • Davidson, Elizabeth J. (2002). Technology frames and framing: A socio-cognitive investigation of requirements determination. MIS Quarterly, 26 (4), 329358.
  • Desouza, Kevin C. (2003). Barriers to effective use of knowledge management systems in software engineering. Communications of the ACM, 46 (1), 99101.
  • Fisher, Karen E., Erdelez, Sanda, & McKechnie, Lynne (E.F.). (Eds.). (2005). Theories of information behavior. Medford, NJ: Information Today.
  • Galal, G. H., & Paul, R. J. (1999). A qualitative scenario approach to managing evolving requirements. Requirements Engineering, 4 (2), 92102.
  • Gemino, Andrew, & Wand, Yair. (2004). A framework for empirical evaluation of conceptual modeling techniques. Requirements Engineering, 9 (4), 248260.
  • Gilb, Tom. (1988). Principles of software engineering management. Harlow, England: Addison-Wesley.
  • Girard, Monique, & Stark, David. (2002). Distributing intelligence and organizing diversity in new-media projects. Environment and Planning A, 34 (11), 19271949.
  • Goguen, Jospeh A. (1992). Requirements engineering as the reconciliation of technical and social issues. Tech report. Cambridge, UK: Centre for Requirements and Foundations, Oxford University Computing Lab.
  • Gottesdiener, Ellen. (2002). Requirements by collaboration: Workshops for defining needs. Boston: Addison-Wesley.
  • Groner, Markus K., & Arthur, James D. (2005). An operational model for structuring the requirements generation process. Requirements Engineering, 10 (1), 4562.
  • Hall, T., Beecham, S., & Rainer, A. (2002). Requirements problems in twelve software companies: An empirical analysis. IEE Proceedings – Software, 149 (5), 153160.
  • Hj0rland, Birger. (2007). Information: Objective or subjective/situational? Journal of the American Society for Information Science and Technology, 58 (10), 14481456.
  • Hooks, Ivy F., & Farry, Kristin A. (2001). Customer-centered products: Creating successful products through smart requirements management. New York: AMACOM.
  • Irick, Michael L. (2007). Managing tacit knowledge in organizations. Journal of Knowledge Management Practice, 8 (3). Retrieved 11/26/2007 from http://www.tlainc.com/articl139.htm.
  • JESSE. Listserv discussion on information behavior, December 1999. Retrieved 11/26/2007 from http://listserv.utk.edu/cgi-bin/wa?A1=ind9912&L=iesse.
  • Kuhlthau, Carol C[ollier]. (1991). Inside the search process: Information seeking from the user's perspective. Journal of the American Society for Information Science, 42 (5), 361371.
  • Kwan, Irwin, Marczak, Sabrina, & Damian, Daniela. (2007). Viewing project collaborators who work on interrelated requirements. in AlistairSutcliffe and PankajJalote (Eds.), Proceedings of the 15th IEEE international requirements engineering conference (RE 2007) (p. 369370). Los Alamitos, CA: Conference Publishing Services.
  • Mayhew, Deborah J. (1999). The usability engineering lifecycle: A practitioner's handbook for user interface design. San Francisco: Morgan Kaufmann.
  • Pettigrew, Karen, Fidel, Raya, & Bruce, Harry. (2001). Conceptual frameworks in information behavior. in Martha E.Williams (Ed.), Annual Review of Information Science and Technology (vol. 35, pp. 4378). Medford, NJ: Information Today.
  • Pickering, Andrew. (1995). The mangle of practice: Time, agency, & science. Chicago: University of Chicago.
  • Poltrock, S., Grudin, J., Dumais, S., Fidel, R., Bruce, H., & Pejtersen, A. M. (2003). Information seeking and sharing in design teams. In Proceedings of the 2003 international ACM SiGGROUP Conference on Supporting Group Work (pp. 239247). New York: ACM Press.
  • Robertson, Suzanne, & Robertson, James. (2006). Mastering the requirements process. Upper Saddle River, NJ: Addison-Wesley.
  • Rose, Jeremy. (2002). Interaction, transformation and information systems development – an extended application of soft systems methodology. Information Technology & People, 15 (3), 242268.
  • Rubens, Jason. (2007). Business analysis and requirements engineering: The same, only different? Requirements Engineering, 12 (2), 121123.
  • Savolainen, Reijo. (2007). Information behavior and information practice: Reviewing the ”umbrella concepts” of information seeking studies. Library Quarterly, 77 (2), 109132.
  • Seilevel. (2007a). Messageboard discussion on requirements professionals' titles, July 2007. Retrieved 11/26/2007 from http://requirements.seilevel.com/messageboard/showthread.php?t=607.
  • Seilevel. (2007b). Messageboard discussion on the use of academic sources of requirements information, September 2007. Retrieved 11/29/2007 from http://requirements.seilevel.com/messageboard/showthread.php?t=668.
  • Siddiqi, Jawed. (1994). Challenging universal truths of requirements engineering. IEEE Software, 11 (2), 1819.
  • Spink, Amanda, & Cole, Charles, Eds. (2005). New directions in human information behavior. Berlin: Springer.
  • Standish Group. (1994). CHAOS report. Retrieved 11/27/2007 from http://www.standishgroup.com/sample research/chaos 1994 2.php.
  • Sutcliffe, Alistair. (1996). A conceptual framework for requirements engineering. Requirements Engineering, 1 (3), 170189.
  • Talja, Sanna, Tuominen, Kimmo, & Savolainen, Reijo. (2005). ”Isms” in information science: Constructivism, collectivism, and constructionism. Journal of Documentation, 61 (1), 79101.
  • Taylor, Robert S. (1968). Question-negotiation and information seeking in libraries. College & Research Libraries, 29 (3), 178194.
  • Truex, Duane P., Baskerville, Richard, & Klein, Heinz. (1999). Growing systems in emergent organizations. Communications of the ACM, 42 (8), 117123.
  • Tuominen, Kimmo, Talja, Sanna, & Savolainen, Reijo. (2005). The social constructionist viewpoint on informational practices. in KarenFisher, SandaErdelez, & Lynne (E.F.)McKechnie (Eds.), Theories of information behavior (pp. 328333). Medford, NJ: Information Today.
  • Urquhart, Christine. (2001). Bridging information requirements and information needs assessment: Do scenarios and vignettes provide a link? Information Research, 6 (2). Retrieved 11/26/2007 from http://InformationR.net/ir/6-2/paper102.html.
  • Walsh, Kenneth R., & Schneider, Helmut. (2002). The role of motivation and risk behaviour in software development success. Information Research, 7 (3). Retrieved 11/26/2007 from http://InformationR.net/ir/7-3/paper129.html.
  • Wenger, Etienne C., & Snyder, William M. (2000). Communities of practice: The organizational frontier. Harvard Business Review, 78 (1), 139145.
  • Wiegers, Karl Eugene. (2003). Software requirements: Practical techniques for gathering and managing requirements throughout the product development cycle (2nd ed.). Redmond, WA: Microsoft Press.
  • Wiegers, Karl Eugene. (2006). More about software requirements: Thorny issues and practical advice. Redmond, WA: Microsoft Press.
  • Wiley, Bill. (2000). Essential system requirements: A practical guide to event-driven methods. Reading, MA: Addison-Wesley.
  • Wilson, Tom D. (1997). Information behavior: An interdisciplinary perspective. Information Processing and Management, 33 (4), 55172.
  • Wilson, Tom D. (2000). Human information behavior. Informing Science, 3 (2), 4956.
  • Young, Ralph R. (2006). Twelve requirements basics for project success. CrossTalk, 19 (12), 48.
  • Yourdon, Edward. (1999). Death march: The complete software developer's guide to surviving ”mission impossible”projects. Upper Saddle River, NJ: Prentice Hall.