Domain Understanding is the Key to Successful System Development

Abstract

Developers all too often are in a hurry to start software design and construction and, as a result, have an unfortunate tendency to overlook, to their cost, the very significant advantages offered by developing a prior and adequate understanding of the surrounding application domain. There is an alternative, but one that is still not taken nearly as seriously as it should be. Most practising engineers, be they civil, aeronautical, electrical, chemical, maritime or whatever, would accept without argument that a clear, concise and unambiguous understanding of a development project’s specific application domain is an essential precursor to successful systems development. A civil engineer, tasked with constructing a hydro-electric dam across a river, would concentrate initially on investigating the geology of the area, drilling test cores, determining the river’s flow characteristics, checking the seismic history and so on, before starting any serious work on specification and design. Similarly, designers of continental shelf oil drilling platforms spend a lot of their time carefully characterising local weather/storm patterns and the wave/swell dynamics of the surrounding ocean before starting to specify in any detail the requisite platform and rig. This process of domain exploration and characterisation, prior to detailed specification and design, is a central, generic activity that is taken very much for granted in all traditional engineering construction disciplines. So, given the ever increasing centrality of software as the system component that mediates the bulk of the functionality, performance, safety and reliability in so many contemporary systems, it is remarkable indeed that the roles and utility of this initial domain modelling process, alluded to above, are generally so poorly understood and manifestly underutilised by the software development community. I may well be biased, given my background as a systems designer (computers, airborne radars, robotics, medical imaging. etc.) but I must confess that I still find it extremely disconcerting to talk to professional software developers who really do not seem to understand or appreciate what domain modelling involves, nor want to recognise its very specific importance in effective requirements engineering and risk management. Consequently, for this particular Viewpoints column, I want to offer a few off-the-cuff comments on the nature and importance, to software and systems developers, of an adequate degree of domain understanding, usually represented via some form of domain modelling (or, less frequently, domain engineering). For present purposes, I shall make no distinction between the terms domain modelling and domain engineering, assuming them, to all intents and purposes, to mean fundamentally the same Requirements Eng (2002) 7:172–175 Ownership and Copyright 2002 Springer-Verlag London Limited Requirements Engineering