Software applications are designed to perform one or more functions. These functions are sometimes simple, like utilities designed to repair errors on a hard drive; other times, these functions can be complex and numerous, such as computer algebra systems that perform symbolic manipulations, plot 2D and 3D curves, and solve equations. It is obvious that the latter example may have hundreds of discrete functions. A large team of programmers may develop such an application. Even if it is postulated that each discrete function is developed by one programmer-which in and of itself is unlikely-the combination of these various functions into a coherent whole requires management of the programming resources to not only ensure consistency (e.g., coding style) but also to build common libraries of code to unify the various functions. Even though in the former example, the entire application is built around its key function-repairing hard drive errors-even a function such as this can be broken down into smaller functions, which must be separately managed in order to create a unified product.

The interaction between the software and the user, or the user interface, is composed of several components: the building blocks ("controls"), like buttons, textinput boxes, and menus; the orchestration or flow of the user's interaction with the software; and the posture or state of the application and how the user perceives his or her interaction with the software. A manager might define requirements of how the screen is to be physically constructed. For a graphical environment, this includes the placement of controls onscreen as well as the window layout. For a command-line environment, this consists of the command structure used to drive the interface. In managing the physical requirements of the user interface, the designer or manager must consider how the requirements fit together into a software experience that flows and is, for the first time as well as experienced user, as painless as possible (Cooper, 128). Minimal consideration to how the various components of the interface (the requirements) fit together results in a disjointed experience for the user, who is forced to relearn the usage of the application in the context of different pans of the software.

The software, no matter how simple or complex, must fit into the underlying operating system in a way that uses resources in the most efficient ways possible. Careful consideration must be given to the specifics - the memory allocation methods, the Application Programming Interface (API) included with the operating system (if any). System requirements must be considered enough to permit the program to run efficiently and with as little overhead as possible, but not so much that it inhibits the design process.

The preceding three categories of requirements are especially important for the manager to consider when porting software to run on another operating system. It is tempting to port the software package over to the destination operating system with as few changes as possible, in accordance with the theory that users appreciate the similarity the new version will have to the old version. Since the old version was carefully managed in its functionality, interface, and system requirements (as described previously), wouldn't the new version also benefit from the same management? The answer, sadly, is no. The major platforms that software developers target are similar enough for a straight port to be tempting, but distinct enough that a successful straight port is inappropriate. Although the functionality of the application may remain similar to the old version, users prefer applications native to their preferred platform applications that contain user-interface components and a flow native to their platform-and that work efficiently with their platform (Cooper, 122). Additionally, the fine-tuning of system efficiency requirements that worked so well on the original platform must be altered for new platforms. Thus, the clear initial definition and continued revision of requirements is essential to producing a product that not only works properly in the target environment, but also "feels" native (in the perspective of the user) to that environment.

From a consumer-oriented perspective, one can look at the process of software development as a dichotomy of the developers' requirements and the consumers' requirements. One can postulate that the failure of some software products is due to the lack of agreement between the requirements of the developers and the consumers. Consumers often have specific functionality requirements but vague technical requirements. They want their word-processing software to be able to spell- and grammar-check documents and to be able to format documents professionally. Technically, however, they just want the software to "work." They don't care if the application has memory leaks, or if it makes inefficient use of system resources; they simply care that it doesn't affect their normal operation of the software.

Contrastingly, developers are more concerned with the technical requirements of the application: that it runs on a system with 16 MB of memory, that it manages resources efficiently, and that the application's documents are small and efficient. Although these technical requirements are without a doubt important to the development of the application, they are of diminished value in the eyes of the customer.