Information Systems Analysis & Modelling

It requires you to develop an information system

model for a system of your own choice. The aim is to get you to apply many of the system analysis and

modelling techniques discussed and illustrated in lectures and tutorials to a real, or at least realistic, case of

non-trivial but still reasonable and do-able complexity.

Choosing your system

As stated in the Introduction, the choice of which system to analyse and model is up to you. However, here

are some rough guidelines to assist you in your choice:

1 Try to choose a system for an area or application about which you know a considerable amount or

about which you are in a position to find out what you need to know. Examples might be a system

related to your current work (if you are presently employed) or previous work experience, a hobby or

interest that you have, or perhaps a system that you or a colleague or friend needs. My experience

in running earlier versions of this course shows unambiguously that this assignment will work best

(and you will learn the most from it) if you choose to analyse and develop a model for a system that

relates to the “real” world in some way, rather than one that is completely fictional and invented

entirely “within your own head”.

2 Try to choose a system of a reasonable size and level of complexity. This will probably be hard to

judge initially, but it is generally better to choose a system that is more likely to turn out to be too big

or complex rather than one that may turn out to be too small or simple. The reason for this is that, if

your choice does turn out to be too big or complex, you can always reduce the scope of your

intended system or choose to model only part of it. On the other hand, if your choice turns out to be

too simple and small to form a useful assignment exercise, it is generally harder to expand it to make

it more suitable as a worthwhile learning experience as well as the basis for an acceptable

assignment submission. Although we won’t discuss these metrics until mid-way through the course

(so they will be less useful to you at the beginning), one useful indicator of size and complexity of a

project is the number of entities in its data model. If this turns out to be somewhere around 6-8 for

your project then you probably have a suitably sized system for this assignment, although these

numbers should definitely not be treated as hard limits. However, if the number of entities in your

data model is significantly fewer than 6 then the model is probably too small and simple to be a

useful learning exercise; and if it is many more than 8 then it is probably starting to get too large to

feasibly tackle. Another indicator is the number of levels you find yourself going down to in your DFD

hierarchy. If this is more than two for the first few processes you decompose, and there are more

than about seven processes on your level 0 diagram, then your chosen system is highly likely to be

too big and you may have to reduce its scope or simply leave parts of the model incomplete.

Your tasks and deliverables

Your second assignment deliverable is a mid-project progress report. This is to be provided digitally via

Wattle and carries a weighting of 10% of the total project mark. In fact, calling this deliverable a “progress

report” is somewhat misleading since it is not to be a formal report describing what progress you have made

to date but is rather to show what progress you have made by providing all of the (no doubt unfinished,

incomplete, draft and still developing) analysis work that you have done on the project so far. And again, like

the first deliverable, what you provide here will form the basis on which you will build the relevant sections of

your final assignment deliverable (see below).

The third and final deliverable for this assignment, worth the remaining 85% of the total project mark, is a

report (submitted digitally via Wattle) containing the following:

1. An Introduction that describes the overall background and rationale for the system you have chosen

to model. In writing this Introduction you should assume that your reader has little or no knowledge

of the application area and system with which you are dealing and this Introduction should therefore

take your reader to a point where she/he has enough information to fully understand all the material

that follows. This will, of course, be based on what you provided for the first project deliverable (see

above).

2. A section describing the scope, functions, constraints, and any other relevant features that apply to

the system you have chosen to model. Be careful, in writing this as well as the following section, to

avoid focussing on matters that are primarily technical. Remember that it is analysis you are

supposed to be doing, not design or implementation, and this is largely a business-oriented activity

dealing with what the system should be doing rather than how it is eventually going to do it.

3. A section presenting the detailed user requirements that form the basis for your model of the system.

While it is not always possible, generally the best projects are those that have real potential users

(other than you!) for the system you are analysing and modelling and with whom you need to interact

to develop the list of detailed system user requirements.

4. A section documenting the actual models you have constructed. This is to include process, logic and

data models. The process model is to be constructed using the DFD technique and should, at least

for several processes, extend all the way down to a primitive DFD together with its associated logic

model. The data model is to be constructed using the ER diagramming technique. You are also to

provide a data dictionary in which the meanings of all the important terms in your model are

explained.

5. A section in which you provide either a UML version of your system model or a “Soft” analysis of the

context in which your system development would take place, whichever is more appropriate for the