There is general agreement that the requirements phase is the foundation upon which the rest of the system development life-cycle is built (Somerville, 1989). Requirements can be divided into different categories – functional and non-functional (IEEE, 1984); also vital and desirable (BSI, 1986). More specific types of requirements may also be identified, including organisational; user interaction; and interface (Denley, 1999). Of concern here are User Requirements (Carlshamre and Karlsson, 1996), because although part of the initial phase of the system development cycle (Newman, 1994), they do not appear to include, explicitly at least, the concept of design problem as such, as referenced here by Hill (although they do not exclude it explicitly either). The omission is important, because Hill is clear, that her models and method are intended to: ’Support diagnosis of specific design problems and reasoning about potential design solutions’ (Section 1.0). The diagnosis of design problems and the reasoning about potential design solutions are performed by designers, as part of their practice, by which design proceeds through iterations of successive cycles of specification and implementation. The question then arises as to what is the relation between user requirements and design problems?
One possible relation is that user requirements and design problems are one and the same thing. That is, there is no difference between them. Although it is not totally clear, Newman (1994) might be understood as taking this view: ’Recognising the need for an artifice, and thus identifying a problem in computer systems design whose solution will meet this need (the initial stage of the engineering design process)’. This view, however, is rejected. Following the HCI Discipline and HCI Design Problem conceptions, in the manner of Hill’s research, a design problem occurs, when actual performance, expressed as Task Quality, User Costs and Computer Costs (see earlier) does not equal (is usually less than) desired performance, expressed in the same way. In contrast, user requirements have no such expression or constraints, even allowing user requirements to conflict.
This difference indicates that user requirements and design problems are not one and the same concept. Rather, it suggests that design problems can be expressed as (potential) user requirements, but not vice versa. Salter appears to agree with this asymmetric relationship, although his terms differ. The Specific Requirements Specification (‘design problem’) is an abstraction over the Client Requirements (‘user requirements’). The Specific Artifact Specification (‘design solution’) is an abstraction over the Artifact. The Client Requirements/Artifact relationship is derived and verified empirically. The Specific Requirements Specification/Specific Artifact Specification is derived and verified formally.
Whatever the terms used, however, the general point for HCI research is that differences between User Requirements and Design Problems need to be both explicit and clear.