Hard methods, not only named so in IS design, are not called hard as opposed to easy, but in contrast to soft. Indeed as a friend of mine, Felix Hong, who spent most of his career in hard sciences (medical research), said when he later engaged in the less concrete topic of creativity: ‘Only when I got interested in creativity, I have found out that the soft is the really hard…’
What I wanted to say by this is that the hard methods introduced here are relatively easy to understand. The reason they are called ‘hard methods’ is that there is a symbolism that is standardised, i.e. every sign used in the various diagrams has a definite meaning and there is no ambiguity i.e. interpretation is not an issue. What is perhaps a little tricky is doing a good job using hard methods: although there are not many element types that you can use and the relationships are also fairly trivial, there can be an enormous volume of those elements that you need to describe.
We will cover three hard methods in detail; I will not describe these here. There are the data-flow diagram (DFD), the entity-relationship diagram (ERD), and the state-transition diagram (STD). Here I describe a few other methods that complement these three. Most of them are, at least in principle, very easy to understand and the ones that are really complex are the project management tools – these, however, are not specific to IS/ICT design and even at an introductory level would take a full MOOC (Massive Open Online Course). On the other hand, many of you will be familiar with these due to working on projects.
Data dictionaries correspond to meta-data from the “databases” topic. They describe what the data is about, how it should be interpreted, and what units are used for them (if any). Although it is possible to create an information system without data dictionaries, it is very dangerous: once the creator is not around nobody will know what really means what. It is useful – in addition to the technical explanations, data dictionaries also contain common-sense descriptions (usually in the form of comments).
Process specifications are to processes what data dictionaries are for the data. They describe the requirements of what the particular processes should exactly do, what inputs they need, what outputs they produce and how they convert the inputs into the outputs. Even a single process may have a very complex specification. As in the case of data dictionaries, it is useful to have comments on the processes in everyday language.
Flowcharts are widely used in many areas, not only in IS/ICT design, whenever you need to describe the logical steps of a process. Many of you will probably be familiar with some variants and there are many of them. This is the main source of difficulty about flowcharts: there are many diverse formalisms and these do not necessarily translate to one another. The good news is that there are numerous online tools that you can try to play with. Additionally, at least two of the hard methods I describe in detail, DFD and STD, can be considered to be flowcharts. However, the most important role of flowcharts is to use them together with the process specifications as without these simple graphical representations of the processes the specifications may be very difficult to understand.
Finally, there are the programme structures; these are the most technical aspect as they are not telling you what the particular information system does but rather how it is programmed. Unless you are in a technical IS/ICT job, you will probably never see one of these. A business analyst, whose job is to figure out what sort of IS/ICT would be useful for a particular organisation or a problem, would only be able to read it. These programme structures also depend on the logic of programming and they change as new programming languages or software-making solutions evolve.
© University of Strathclyde