In the first two chapters, we have outlined some of the pressures faced by analysts in understanding and dealing with analysis and design problems. Later in the book, we will introduce techniques for analysis and design. Before tackling these techniques, there are several fundamental concepts that need to understood. These concepts form the basic building blocks of any analysts education. This chapter introduces the concepts of system, organisation, information and communication. Those of you with some experience of analysis and design (if not of developing systems, then of reading text books such as this) will have encountered the first two concepts before in other textbooks, possibly covered in superflous detail. The latter concepts are usually implicitly addressed by text-books in this area, but rarely covered in depth.
Our concept of what a system consists of is very much clouded by the way the phrase is most often used in modern language, and our own interpretations of it. You are likely to have an interest in technology and the ways in which technological decisions are incorporated in technological designs - you would not be reading a textbook like this if that where not the case. What examples for system could you come up with? Computer system ? operating system ? database system ? All of these are valid examples for the system concept, as they carry out a task or support an application. However, as an analyst, our understanding of the system concept has to be a little more comprehensive, for the elements of the system that we will need to understand go beyond technical details alone. The Concise Oxford Dictionary (1990) has 12 definitions of system, ranging from a set of connected parts or things, through to the braced staves of a musical score. Of course, within the confines of this book, our attention to the system concept cannot be so broad. While a general definition of system would be useful as a starting point for illustrating the different types of system the analyst has to deal with, it is clear that no generally agreed definition presents itself. Most definitions of system are split into two clear divisions. Objective definitions of system focus on physical systems, like solar systems, technical systems etc, while subjective definitions focus on more ephemeral categorisations like ideas, standards and theories. The Open Systems Group(1988) have attempted to fuse these two viewpoints on the system concept into one general definition. Their definition says that a system is an assembly of parts where:
1. The parts or components are connected together in an organised way.
2. The parts or components are affected by being in the system (and are changed by leaving it).
3. The assembly does something.
4. The assembly has been identified by a person as being of special interest.
This definition deals with subjective and objective definitions of the system concept. An analyst will be primarily concerned with objective instances of systems. After all, the final product of the analysis and design will be a technical definition of a future system. As an analyst, you will need to be aware of the following systems types, as each type of system may be part, or impacted on, by a system development:
Natural Systems: occur naturally in the universe, such as galaxies, ant heaps and bee hives);
Designed Systems: man-made systems, physical (computers, central heating systems, jet engines) as well as abstract (mathematical systems, music systems);
Social and Cultural Systems: formed by human beings coming together, naturally (in families, communities, nations) or deliberately (in clubs, political parties);
Human Activity Systems: systems where human beings are undertaking activities to achieve some purpose (businesses, organisations, pressure group); might include other types of systems (e.g. use designed systems such as computers, or have a company sports club).
Figure 3.1 Your friend, the computer: A subjective system (theory) of weight gain
Although as a systems analyst, our primary interest in the concept of system is going to be concentrated on designed systems, we have to appreciate that those designed systems are components of - or influenced by - other systems. Figure 3.2 shows how a payroll system is utilised within systems that serve as components of other systems. In this example, the payroll system is used by a group responsible for payments. That group of people work within a department with responsibility for handling the accounts of the larger organisation. The organisational system itself will exist within a wider social and wider environment.
Figure 3.2: Systems within systems
The interesting thing about figure 3.2 is not the fact that systems of different types exist within each other, or that some systems are sub-systems of larger systems, but the type of interaction which happens between them. The majority of systems are 'open'. What do we mean by this? Well, basically, this means that systems interact with their environment. A payments group, as well as interacting with the payroll system, will be interacting with an accounts group and the accounts group will be interacting with a number of other organisational groups within the wider environment.
Traditionally, analysts have been primarily concerned with analysing and designing 'hard' systems. Hard systems are the technical systems that are produced during a system development. The functionality of the system is easy to define, and the behaviour of the system is easy to predict. The payroll system in figure 3.2 is an instance of a technical system. 'Soft' systems are more difficult to define and predict, their behaviour is more erratic and difficult to quantify. Human activity systems, like the organisational groups illustrated in figure 3.2, are examples of soft systems. Figure 3.3 illustrates some of the characteristics of hard and soft systems.
Hard system Soft system
"technical" "personal"
precise fuzzy
well-defined ill-defined
quantitative qualitative
easy to predict difficult to predict
Figure 3.3: Characteristics of hard and soft systems
The important thing to remember about both hard systems and soft systems is the level of interaction across systems boundaries. This means that hard systems cannot be analysed in isolation from the soft systems within which they are embedded. Chapter 2 illustrated two case studies where lack of consideration of social issues were contributory factors in the failure of the development projects. In analysing the present system and designing a new system, we need to consider both the hard system that will be the product of the development, and the soft system within which it will be used. Chapter 4 introduces the Soft Systems Method (SSM), which helps us in analysing the soft system by identifying problems and issues within a social context. Chapter 11 will present a framework by which the degree of effort needed to be spent on understanding social complexity on the one hand, or technical complexity on the other, can be decided.
Up until this point in time, the diverse range of interest groups interested in the behaviour of systems have been insular in their studies, concentrating on developing their own individual concept of what system represents, particular to their own discipline. Biologists have concentrated on models that help them understand the behaviour of living organisms, astrophysicists have developed models to help them understand the behaviour of solar systems, black-holes and other heavenly wonders, sociologists have built models to help them understand the working of political and social groups, and computer scientists have built systems models to help them understand the workings of internal computer system functionality and behaviour.
If, as analysts, we need to understand the workings of both 'soft' social systems and 'hard' technical systems, then it would be useful to have a terms of reference for understanding how dynamic systems with interactive parts have to work. General systems theory provides a checklist by which the dynamic interaction of systems (of all types) can be judged. The most important constituent of general systems theory is the formal systems model, see figure 3.4.
Figure 3.4: Formal systems model
According to the formal systems model, a system has the following characteristics:
 | it requires an ongoing purpose, i.e. a reason for existing, and it achieves some transformation or change |
| there are measures of performance (quantitative or qualitative), so that it can be shown that system is effective, and which can be used as a basis for measuring efficiency |
| there is some mechanism for control or regulation, and a decision-making process (characteristics of which are illustrated in figure 3.5). |
| it has sub-systems or components, arranged in a hierarchy |
| there is interaction between sub-systems |
| it exists as part of a wider system or environment with which it interacts |
| it has a boundary which encloses the area that the regulating mechanism has under control (characteristics of which are illustrated in figure 3.6). |
| it has resources of its own, under the control of the regulating mechanism |
| system has some expectation of continuity, and can be expected to recover from disturbances |
The type of control exerted over the system can be adaptive or non-adaptive (see figure 3.5). Adaptive control modifies a variable, process or system depending on its own effects or inputs. A reference state is needed, in order to compare actual results with the reference state. Positive feedback or negative feedback may be used to increase or decrease any discrepancies between the actual results and the reference state, respectively. Non-adaptive control produces a response in advance of a discrepency between the future actual results and a reference state. An external intervention will be made, often in accordance with pre-set control laws or algorithms.
Adaptive control Non-adaptive control
feed-back feed-forward
closed loop open loop
Figure 3.5: Types of control or regulation
Figure 3.6 shows the criteria used for judging whether a component is within the system boundary, or part of the external environment.
Part of system if Part of environment if
component/subsystem component/subsystem
controlled by system interacts with system
component/subsystem strongly component/subsystem influences
influenced by system system
Figure 3.6: System-enviroment boundary
So, the formal systems model gives us a checklist with which we can compare our models of the social system (and the technical system) to see whether they are complete systems. Models of systems generated through SSM (chapter 4) and the technical viewpoints on design (chapters 7-9) should be checked against the formal systems model to make sure that they are suitably rigorous models for design. As we introduce the modelling techniques in later chapters, you should try to attempt to identify the elements of the modelling techniques that cover each particular characteristic of the formal systems model.
In figure 3.1, we illustrated the fact that an organisation is an instance of a human-activity system. An organisation will also conform to the formal systems model, having an on-going purpose, some measure of performance, and so on. It is also a soft system, as many of the issues that are important to its on-going continuity are difficult to identify, the workings of the system are often fuzzy and difficult to understand, and the needs of the organisation are difficult to predict, as often they are tied up with personal needs, and political manuevering within interest groups. We will discuss some of the methods used in order to analyse organisational complexity in chapter 4.
When you start working within organisations, you will start to appreciate that each organisation has its own 'way of doing things'. Many organisations are often proud of often peculiar organisational traits that distinguish them from other groups or organisations, and will often tell you so. Such traits include:
| Rituals and procedures: The way in which work is carried out, and the manner in which the group indoctrinate new group members is particular to that organisation/group. |
| Dress Codes: The accepted standard of dress is particular to that organisation/group. |
| Shared Beliefs: A work philosophy is particular to that organisation/group. |
Such traits are determinants of the norms of an organisational culture. Norms describe the accepted format of behaviour within an organisation. Roles are socially contructed contracts for expectations of behaviour, and values are expectations for forms for expression of behaviour within an organisation (Davies & Ledington, 1991). Roles will be assigned within sub-systems of the organisation, and will determine the type of tasks being carried out. We will return to the importance of norms to our understanding of a organisational culture in chapter 5.
Ignorance of social issues can often lead to the failure of a system development, but misinterpretation of the social issues within a organisation can also often lead to disaster. As analysts, you will be concerned with improving the effectiveness and efficiency of the current system. The efficiency of new systems has long been the concern of analysts and designers. Reductions in the time needed to carry out tasks and improvements in the use of resources will often only have minor impacts on the organisation, as the tasks carried out within the area of interest, and the roles involved in carrying out such tasks will not be adversely affected. Dealing with efficiency is largely a technical issue, with the technical system handling tasks that are easily computable, repetitative and time-consuming to do manually. Improving the effectiveness of work practices is a different matter, because the manner in which work is carried out, and resources allocated, will be affected. Care needs to be taken to ensure that organisational norms are not adversely impacted. Improving the effectiveness of a system requires close attention to social issues.
When we think of computer based systems, we often equate information with the computer, ie. a computer stores, manages, and manipulates information. In an area where the systems being developed can be given the generalisable label of information technology, then such a misunderstanding is believable. Information and computers should not be so easily equated (Liebenau & Backhouse, 1990). Information requires interpretation (ie it needs to mean something to the individual using it). While computers are useful tools for getting access to information, they do not store or manage it. Computers are simply dumb pieces of technology that store and distribute data, which can be used as information by a user. Designers manage information by determining how it can be accessed, and users turn data into information by interpretation.
The manner in which data (or signs) is interpreted is important to the analyst/designer, as the process of interpretation depends on a number of social and work related factors. The analyst needs to be aware of these factors in order to make sure that mis-interpretation doesn't take place. The manner in which data is managed and presented to the user needs to be properly managed.
The process of interpreting a sign is influenced by a range of factors, so the same sign (e.g. word) may have different meaning for two people looking at it - Figure 3.7 gives an example.
Figure 3.7: Same sign, different meaning
To summarise the important characteristics of information:
| Information cannot exist independently of the receiving person who gives it meaning and acts upon it. The Carling Black Label advert is data, rather than information. |
| Acting upon information includes analysis or at least interpretation of information by people. How a person interprets data is influenced by variable factors such as their knowledge, experience, or current emotional state. One set of data, such as the Carling Black Label advert, may therefore contain different information for different people. |
| It is therefore important to be aware of differences between data and information:
information is data arranged in a meaningful way for some purpose. Signs can be distinguished into icons and symbols. |
| Icon: a referentially isomorphic sign which maps onto object or event in a non-arbitrary fashion - this means that all important characteristics of the object, and the relationships between them, are represented in the icon. Icons should therefore be highly recognisable to people familiar with the objects that they represent. Photographs and circuit diagrams are examples of icons. A special case of an icon is an index, which relates the sign to what it signifies by referring to its intensity (blackness of a cloud indicates severity of rain to be expected). |
| Signs and symbols: referentially arbitrary: sign has loose connection to its referent, often depending on social, legal etc. conventions (red traffic light). Since not all characteristics of the "original" have to be preserved, signs can be very powerful in terms of expression (e.g. one word or picture can communicate a a wealth of meaning.) Human means of communication have evolved from pictorial representations - icons - (cave paintings, hieroglyphs) to the symbolic representations - words which we use today. The relationship between a sign and what it stands for has to be learned, and the meaning of the sign can be highly dependent on a person's culture (see Section 5.Y) and the context (see Section 5.X) in which it is used. |
Communication is the process through which information is transmitted, and involves at least two parties. The process can be described as a set of activities, involving
| a sender (S) with intentions to convey; |
| a medium or channel or medium for carrying signals; |
| a receiver (R) who has the ability to interpret those |
signals.
Figure 3.8: Sender, transmission channel, receiver
The theory of communication was formulated by Claude Shannon[1] Effective communication takes place when there is a high degree of correspondence between the sender's intentions and the receiver's interpretation. The ultimate "test for success" of an act of communication is whether the sender receives the intended response (or feedback) from the receiver. If response is not immediate, intermediate feedback is necessary.
If no response occurs, or the sender cannot understand the response from the receiver, we have a communication breakdown. When a communication breakdown occurs, systematic investigation of the communication process and all elements involved is necessary: the breakdown could be due to the intentions, the channel or medium, the signal or the receiver and its ability to interpret. (We will explore these ideas more closely in Chapter 5.) Communication breakdowns in an organisation can, therefore, occur even if the hardware is functioning. In modern organisations, information technology has become the most important channel of communication. We must analyse communication needs of an organisation carefully, and design technology which supports effective communications. The process of design also needs to take account of the most appropriate way to communicate information between parties connected to the system development.
Figure 3.9: Breakdowns in the communication process
Figure 3.9 illustrates an event with which many of you should be able to identify with, the failure of two parties to communicate effectively. Using Shannon's theory of communication, both parties should continue to communicate until the sender receives the intended feedback from the reciever. The tourist should thank the officer, saying that he understands the directions given. However, the thought bubbles, representing the mental models of the participants show that there are suitably large differences in the policeman's perception of the route and that of the tourists, to suggest that understanding may be a timely and difficult process to achieve.
One way to solve the dilemma outlined in figure 3.9 is for one of the parties in the communication process to have a travel map. By having a physical representation of the route that the tourist needed to take, then the communication process would be more successful. As long as both parties understand the mapping conventions used in the diagrams then the both parties would come to an understanding sooner.
Trying to give directions to someone passing through your own neighbourhood is a difficult task. Most of you will have been in the policeman's shoes at one point or another, and wished you had a map in order to give detailed directions. The communication process between analysts and user representatives is another area that is often fraught with difficulty. Both parties bring different skills and abilities to the communication process. Analysts are likely to have different backgrounds and communication skills to those of the user population they come into contact with. Analysts will often have to bridge this comunicational incompatibility through the use of abstract and concrete representations of the system as shared communication vehicles.
Abstract representations of analysis and design present a limited view of the system, that of its underlying structure, functionality and dynamics. The techniques you will be introduced to in the later chapters of this book are examples of abstract representations of systems. Historically, many of the structured analysis and design methodologies have used these when communicating aspects of design to user representatives. The requirements of the system (the tasks that the client organisation wanted the information system to do) would be developed into a representation of the system, and the user representative would be required to inspect the diagrams and say whether they conformed to what the client organisation required. The abstract representations presented a map of the system. However, there are fundamental problems with this approach:
" It is not surprising that users find the formal methods of representing proposed designs ... hard to understand and cannot relate them to their experience of the task. On the other hand, the technical specialists find that verbal descriptions and written requirements lack the precision which they feel they need as a basis of design "(Harker, 1988)
Researchers have pointed out that there is a need for a 'joint procurement interface' (Potts, 1988) between analyst/designers and user representatives. Users need something a little more tangible than abstract representations in order to be able to communicate their needs or pertinent issues to analyst/designers. Prototypes are increasingly becoming important tools for communication between the analyst and the user representative.
The boundaries between analysis, design and implementation are becoming increasingly blurred. One of the catalysts in this change is the increasing power of software based tools. Prototypes are being used as a communicational tool (encouraging closer relationships between users and analyst/designers) and also as a representation of the specification for the system, so they sit very easily on the fence between analysis and design. We are going to discuss the uses of prototypes here, rather than in a postscript to this book. This should be construed as being a reflection of the increasing importance of prototypes to analysis and design:
" Looked at from the perspective of user-centred design, it has to be said that the tendency has been to allow the technology to drive decision-making, particularly when there is a great deal of time pressure. One of the features to emerge from prototyping is a much clearer sense of the user's priorities, which enables them to seperate issues that are highly significant in their impact from those issues which tend to dominate popular discussion while having no significant long-term implication". (Eason & Harker, 1988)
" The idea of a software prototype as a way of accurately obtaining the user requirements has many advocates and has, in certain circumstances, proved extremely successful. Sometimes the prototype may not only be used to help capture and refine the user requirements but may actually be used as the specification itself."(Fitzgerald, 1988)
Prototypes can have many characteristics and many possible uses. Amongst a host of possible applications, they can be used to gather requirements, to present demonstrations, to design user interfaces (Shneiderman,1992;Sutcliffe,1988) and to act as pilot studies in order to assess the viabilities of new designs. (User interface design deals with a mixture of design and implementation issues, and has developed into a discipline all of its own during the last few years. Rather than deal with such an important issue by giving it token and desultory coverage within a chapter, we've listed readers on these issues in the further reading section.)
The quotes that initiated this section illustrate two areas of importance, these being the role of prototyping as a medium of communication between users and developers, and as a form of specification. The connections with encouraging participation with user representatives are important, as a prototype is the one product of a development process that the users may come into contact with on a regular basis.
If we consider the first area of importance, then the rationale for the use of prototyping approaches is connected with the limitation of diagrammatic representations as communication vehicles. The inherent problem with any document-based representation is that it remains an abstract representation of what the users want (Fitzgerald, 1988). Because it lacks detail, or any characteristics of the real system it represents, it will be difficult for the user to relate to the real world via the representation. Prototypes are useful because they provide access to the tacit knowledge of the user (Polyani, 1966). Tacit knowledge is information that is hard to express, and even harder to represent in a formal representation, but remains crucial to the way workers carry out tasks, including the carrying out of tasks through computer-based systems. When you are collecting information as part of the SSM study, and analyse the current system, you will, in all probability, be talking to potential users about the skills used and decisions made in carrying out a task. It is quite likely that the potential user will describe decisions and actions in very cursory detail. Tacit information is included in the actions that users carry out automatically. Because they don't think about these actions, they find it hard to describe what they are doing. Nevertheless, this information is important if we are to understand the opportunities and constraints that exist within a particular environment.
Prototypes allow you - the analyst - to access tacit information because the prototype, even if it is limited in detail, is not an abstract representation. The user can visualise how the system looks and feels, may be able to interact with the prototype and see if they can carry out tasks, and because they have a tangible rather than an abstract object, they will find it easier to assess and criticise the representation being presented and suggest improvements.
The second important characteristic of prototypes is that, in some circumstances, they can act as the specification of the system. By validating the design through testing of the prototype, it should be possible to use the resulting prototype as a basis for the specification. The design information incorporated within the prototype can be formally programmed into the final delivery of the product. Such an approach has its detractors, especially in the software engineering community, as there may be problem situations where the level of uncertainty is so high that as soon as a design is formally expressed and verified, it is already out of date. In these situations, the prototype may be the only specification, as it is the only representation that is open to immediate change. The lack of a formal model, some feel, may damage the robustness and maintenability of the final system. Others would argue that the system itself will be operating in an unstable organisational environment, and would have to change anyway, so the idea of a stable and verifiable design is fundamentally incorrect.
This section closes with an overview of the different types of prototyping approaches, and descriptions of their relative strengths and weaknesses. We will outline how they can be combined with analysis and design techniques in chapter 11.
Pilot Studies
Pilot studies are prototypes carried out out in the initial stages of a project. The main role that pilot studies fill is to help the development team see if a particular design is tenable, by simulating the constraints under which the final system is to be used. Pilot studies are effectively simulations, and are useful for informing future design as well as analysis.The fact that Pilot Studies are removed from the life-cycle of the main project makes them particularly useful for technically complex developments, eg. those incorporating safety or security issues, where the size of the development might mitigate against the possibility of correcting problems by going back and changing the requirements (Harker, 1988).
Parallel Prototyping
Parallel prototyping is characterised by two seperate system developments, running in parellel. One of the developments is the main system, the other a prototype. Both work from the same set of requirements. The prototype rarely informs the progress of the main development, and mainly serves as a training vehicle, to inform the users of emergent functionality. As an example, parallel developments are often used on military and commercial aviation projects. While the main application is being developed, aircraft simulators are developed in parallel to train pilots with the new system.
Simulations
The distinction between simulations and prototypes is really quite small. For large applications it will probably be necessary to simulate part of the system (usually functionality) in order to give the user the opportunity to comment on the system (Harker,1988). A simulation is when part of the functionality of a system is 'jury-rigged' to produce the expected output, without doing the associated processing as defined in the design specification.
Demonstrations
Demonstrations are potentially the easiest forms of prototype to create, but also possibly the least useful. A demonstration is basically a prototype of screen-based information, and can be useful for showing interface layout. The user can look at the screens, but is unable to interact with them. Demonstrations can be useful for generating comments, but as most of the functionality is missing, or simulated, their effectiveness in gathering requirements is limited. There are close relationships between demonstrations and 'horizontal' prototypes. Horizontal prototypes are prototypes where the user-interface has been implemented, but the functionality is missing, or simulated.
'Throw away' prototyping
Throw away prototypes are 'one-shot' prototypes used to gather requirements for a new system, or to be used as a demonstration vehicle. Once Prototypes are used by representative groups of users to test the requirements of the system, the results of the prototyping are fed back into the analysis and design of the system development, and the prototype is discarded.
Iterative Prototyping
The major distinction between throw-away and Iterative prototypes is that the latter gradually expand and grow as users iterative through requirements reviews. Because of the fact that many aspects of the requirements and design are reflected in the evolving prototype, they are often used to record the specification of the system, and the prototype itself could end up being incorporated in the end-product.
The more attentive reader will have noticed that all four of the concepts we have introduced in this chapter are inter-related. Some of the relations between these concepts are illustrated in figure 3.10.
Figure 3.10: The inter-relation between concepts
The diagram illustrates that the concept of organisation is relevent to our study of the concept of system, as the organsation, as a soft system, will interact with the hard systems that we create through systems analysis and design. The concept of organisation is also relevent to our study of the concept of communication - and the concepts of information - as acceptable channels of communication - and the relevance of information - will be determined by organisational norms. Information is transmitted from sender to receiver; communication takes place, and also the relevance of the information we need is dependent on the types of system we study. The final link in the puzzle is that models or representations of the system can inform the communication process.
In this chapter we have introduced the concept of the system, and we have shown how a number of systems (other than the technical systems we design) exist. We illustrated the difference between hard and soft systems, and presented an example of how a hard system and a soft system are interlinked. We have also introduced general systems theory and illustrated the necessary components of the formal systems model. The second concept to be introduced within this chapter was the organisation. We showed how an organisation often has a culture that determines how the organisation works and what constitutes acceptable practice. The third concept to be introduced was information. We illustrated how the treatment of information by analysts needs to go beyond the structuring of information for computer-based systems. We have shown how interpretation of information is important when considering computer-based information. Finally, we introduced a categorisation of the types of information used, a categorisation that will be expanded in chapter 5. The fourth, and final, concept we introduced was that of commmunication. Shannon's theory of communication was introduced, and the effective elements of communication; sender, channel and receiver were detailed. We then went on to illustrate ways in which the communication medium can be improved, with the use of shared representation mediums, particularly prototypes.
Kolb, D, Rubin, I. M. & Osland, J. (1991): Organisational Behaviour: an experential approach. London:Prentice Hall.
An interesting and easy to read text showing the manner in which organisations work. The main body of the text is made up of individual case studies, illustrating the broad-range of organisational behaviours.
Systems Behaviour (1981). 3rd Edition. Ed. Open Systems Group. Paul Chapman Publishing. London: Paul Chapman Publishing.
A compact reader on systems theory and its applications. Contains essays by the founders of modern system thinking - Geoffrey Vickers, Peter Checkland, Ludwig von Bertalanffy - introducing the fundamental concepts of system thinking. The remainder of the book demonstrates applications of system thinking to a wide range of disciplines: medicine, biological sciences, social science, economics, organisations, ecology engineering and design.
Lantz, K.E. (1986) The Prototyping methodology, Prentice-Hall.
Although the book is fairly old for a text covering this issue, Lantz presents an interesting overview of the ways in which prototyping can be used. Later chapters on the use of prototyping tools are particularly relevant.
Shneiderman, B. (1992) Designing the User Interface: Strategies for Effective Human-Computer Interaction, Second Edition, Addison-Wesley.
Sutcliffe, A.(1988) Human-Computer Interface Design, Macmillan publishing.
Both books cover user interface design issues very well. Sneiderman's book is a particularly entertaining read, outlining the do's and don'ts of interface design. Sutcliffe's book, in comparison, is a more nuts-and-bolts effort, and goes into more depth in describing the use of techniques. His chapter on user psychology is especially good.
Davies, L & Ledington, P. (1991) 'Information in Action: Soft Systems Methodology', Macmillan Publishing.
Fitzgerald, G. (1988): Information Systems Development for Changing Environments: Flexibility Analysis, in Information Technology for Organisational Systems, H.J. Bullinger et al (Eds.), Esevier Science Publishers, North-Holland.
Harker, S.D. (1988): The Use of Prototyping and Simulation in the Development of Large-Scale Applications, The Computer Journal, Vol 31, No.5.
Liebenau, J. & Backhouse, J. (1990) 'Understanding Information: an introduction. Macmillan Publishing.
Polanyi, M. ' (1966) The Tacit Dimension ' Routledge & Kegan Paul.
Potts, C. (1988) The Other Interface: Specifying and Visualising Computer Systems in Working with Computers: theory versus outcome, van der Veer, G.C, Green, T.R.G, Hoc, J-M & Murray, D.M. (eds), (pp. 145-177), Academic Press.
Concise Oxford Dictionary (1990) Oxford University Press.