For simplicity, this paper adopts two broad categories of software, packaged software, and custom software. In general, custom software targets a single customer (or trivially few customers), whether the organization itself or, in the case of contract development, via an outsourcing arraignment. It is produced in or for a single project (Torchiano and Morisio 2004). Packaged software, on the other hand, targets more than a trivial number of customers, which leads to different behaviors in exploring and managing software requirements (Sawyer 2000; Xu and Brinkkemper 2007). Packaged software is
intended to be a “going concern” (as accountants might say it), that is, to have an extended useful life, and is developed over recurring cycles with the intention of long- term maintenance and improvement. As Xu and Brinkkemper (2007) point out, this has implications for the likely level of care taken in architecting the software. Packaged software faces time-to-market pressures (Sawyer 2000; Xu and Brinkkemper 2007), although this may also be true of contracted custom software. More specifically, packaged software organizations are more likely concerned with maintaining schedules than with project costs (Sawyer 2000).
Some of these effects (e.g., differences in requirements management) may depend on the complexity of the developed product instead of on whether the software is packaged or custom; it may be that the greater the complexity of the software, the more likely it is to be productized so that development costs are shared among multiple customers. Some of the observed effects may also be industry-level effects.
Using two small case studies and a review of practitioner and academic literature, (Sawyer 2000) proposed what is probably the most well thought-out list of differences between packaged and custom development (Table 3-1). There are some weaknesses in Sawyer’s (2000) analysis—which should be expected, as Sawyer (2000) refers to these as empirical speculations rather than empirical results—namely the similarities in the sampled teams: all were focused on “small” products or product components (rather than complex systems or networks of products), all were delivering a first-generation product (rather than a new version of an existing product), and two of the three teams studied were in small, isolated settings. Still, Sawyer’s (2000) article is perhaps the most
comprehensive examination of the differences between product and custom development.
Packaged software companies’ emphasis on time constraints rather than cost constraints has already been noted; Sawyer’s (2000) contended this was because packaged software companies tended to be very rich (large and established) or very poor
Table 3-1: Differences Between Packaged and Custom Software (Sawyer, 2000)
Packaged software Custom software
Industry • Time to market
pressures
• Success measures: profit, market share, mind share
• Cost pressures • Success measures:
satisfaction, user acceptance, ROI Software Development • Line positions
• User is distant and less involved
• Process is immature • Somewhat integrated
design and development • Design control via
coordination
• Staff positions
• User is close and more involved
• Process is more mature
• Separated design and development
• Design control via consensus building
Cultural Milieu • Entrepreneurial
• Individualistic
• Bureaucratic • Less individualistic
Teams • Less likely to have
matrix/project structure, more likely to be self-managed • Involved in entire development cycle • More cohesive, motivated, jelled • Opportunities for large financial rewards • Likelier to be small, collocated
• Share a vision of their product(s)
• Matrix managed and project focused • People assigned to multiple projects • Work together as needed • Salary-based
• Grow larger over time and tend to disperse • Rely on formal
specifications/docume nts
(just starting out). Other differences between packaged software and custom software deserve mention as well (Table 3-1). Sawyer (2000) speculated packaged software companies would measure success by profit and market share, while internal or custom development would measure use, satisfaction or return on investment. The software development teams in packaged software organizations were more likely to be central to the organization’s structure and focused on individual skill and individual achievement, and processes are adapted or evolve around an individual’s strengths. In contrast, developers in custom software development, Sawyer (2000) contends, are typically relegated to staff positions where process dominates and development resources are fungible. Developers of packaged software are more likely to be separated from users by intermediaries, more likely to have incentives based on project success, and more likely to be self-organizing (Sawyer 2000).
Despite the arguments of Sawyer (2000), many of these team-level effects may have more to do with the size of the organization than with the type of software being developed, for reasons that will be discussed in the research findings.
Requirements management literature is summarized using both software engineering and information systems perspectives, emphasizing the lack of interactions between the two streams. Requirements processes are described as iterative and parallel. Requirements are related to uncertainty.
Requirements and requirements management exist at an interesting intersection in the literature. The software engineering (SE) side provides a robust literature, with specialized conferences and journals examining specific aspects of requirements engineering, including elicitation, analysis, specification, and validation. However, it does so without typically examining organizational or systemic considerations. In contrast, the IS literature on requirements lacks the strong canonical foundation found in SE literature, and tends to address processes and approaches in a fragmented way (Hassan and Mathiassen Forthcoming)1. External reviews of the whole of requirements
literature provide a basis for categorizing uncertainties revealed through requirements during the software development process.
Collectively, requirements engineering activities, along with integration of requirements engineering activities into project management are considered by this dissertation to constitute “requirements management.”
1 This is perhaps analogous to the state of agile development method in IS literature described by
Baskerville, R., Pries-Heje, J., and Madsen, S. 2011. "Post-agility: What follows a decade of agility?,"
Information and Software Technology (53:5), pp. 543-555., that is, requirements management and requirements construction are something generally understood at a high level but it is difficult to describe current contributions with precision.