Study Unit IT2 - Functionality
Copyright Notice:
This material was written and published in Wales by Derek J. Smith (Chartered Engineer). It forms part of a multifile e-learning resource, and subject only to acknowledging Derek J. Smith's rights under international copyright law to be identified as author may be freely downloaded and printed off in single complete copies solely for the purposes of private study and/or review. Commercial exploitation rights are reserved. The remote hyperlinks have been selected for the academic appropriacy of their contents; they were free of offensive and litigious content when selected, and will be periodically checked to have remained so. Copyright © 2001, Derek J. Smith (Chartered Engineer).|
|
ALPHA TESTING - FEB 2001 - This version dated 14:16 16th February 2001
This is the second of nine post-foundation study units making up the INFORMATICS e-learning resource published and supported by Derek J. Smith (Chartered Engineer). For further information, please e-mail me.
Unit Aims and Outcomes: Before a business process can be computerised, it must be seen within its natural context and its structures and functions carefully analysed. This study unit therefore looks at the IT systems procurement processes (a) of boundary setting, and (b) of requirements specification. When you have completed it, you will be able to deploy with enhanced confidence and accuracy the specific skills and vocabulary listed below:
|
Specific Skills |
Vocabulary |
|
1. Represent existing organisational information flow diagrammatically, and use this to set the boundaries of a possible computerisation exercise. |
document flowchart; systems boundary; systems interface |
|
2. State required system functionality to an appropriate level of precision |
audit trail; defaulting; functions vs features; maintenance utilities; reliability; safety critical system; user friendliness |
|
3. State required system reliability |
MTBF; MTTR |
Unit Structure: This unit contains three short lessons, each contributing to the overall unit outcomes, each with its own hyperlinked support material, and each with its own additional reading and tutorial task(s). Here is the learning sequence:
Lesson IT2.1: The Document Flowchart
Lesson IT2.2: Functions and Features
Lesson IT2.1: The Document Flowchart
One of the most useful tools for seeing systems in the broad is the document flowchart. This type of diagram shows how a logically related series of documents - in either hard copy or electronic form - moves from point to point within an organisation, with information being added or extracted along the way. Document flowcharts are thus major sources of insight into how a process might eventually be computerised, and being able to draw them is one of the foundation skills of systems analysis.
Detailed instructions on how to prepare a document flowchart are found in [
click here], but it is worth noting the basic rules because even roughly sketched diagrams can be useful. Here is the sequence of events during their preparation:Note all the departments/locations where items from the document set you are interested in are created, amended, stored, and/or accessed.
Put these locations in time sequence, starting with the earliest
If a location exists more than once, delete all entries after the first
Map the remaining locations out on a large sheet of paper, with different locations separated by vertical dotted lines and clearly named. You will probably need a sheet of A3 paper in landscape mode, drawn into columns 5 to 10 cm wide.
Draw in individual documents using the [example not yet available] symbol. Take care to show these at every location where individual documents (a) arrive or are produced, (b) come to rest for some reason, or (c) leave or are destroyed.
Draw in files of documents using the [example not yet available] symbol. These should be shown at every location where documents are accumulated in sets for some reason. Again, be careful to include both hard copy and electronic versions.
Files need also to be marked with their sort sequence using the [example not yet available] symbol.
Record the movement of information by linking up the document and file symbols with arrows [example not yet available].
Note any information processing which takes place while the information is in motion by adding helpful annotation at appropriate points.
You now have a map of how the information you are interested in moves around one particular subset of the organisation you are interested in. The next step is to consider which element(s) of your system might be automated. This combines two concepts learned about previously [see Lesson FN1.2], namely systems boundary and interface. What you are looking for are bottlenecks and inefficiencies which a computerised replacement system could alleviate. Exercises IT2.1.3 and IT2.1.4 will help you appreciate some of the factors needing to be taken into account when making this decision.
LESSON RATIONALE:
And why does all this matter? Because the document flowchart is probably the single most effort-effective description of business information flow! It shows document and file symbols as resting points for information, and uses arrows and processing symbols to represent actions upon information, and it is these data stores and processes which may or may not be ready for computerisation. No IT project should ever be contemplated without extensive study of the relevant document flowchart.
|
EXERCISES (AND STANDARD STUDY TIMES): Depending on how thoroughly you have been exploring the hyperlinks provided, it has probably taken you less than 30 minutes to read the foregoing text, and now you have to do some real work. Complete the following exercises, taking careful note of the expected study times: |
|
|
IT2.1.1 |
Set up interprofessional links to friendly and knowledgeable IT staff, and obtain technical definitions of the words "system boundary" and "interface". Ask to see the flowcharts for one of the large corporate systems. [30 minutes.] |
|
IT2.1.2 |
Search the "Computer Weekly" web archive for cases of past IT disasters caused by difficulties getting information across systems interfaces. [1 hour.] |
|
IT2.1.3 |
Obtain and study a standard Post Office Recorded Delivery (RD) Slip. What routes do you think are taken by the various portions of this document when used to despatch an RD package from one organisation to another? Start at the desk of the sender and go all the way to the desk of the recipient; and do not forget the delivering postman's signature book, because this is needed in Exercise IT2.1.4. Using the instructions and specimens above, display this information graphically on a document flowchart. [2 hours.] |
|
IT2.1.4 |
Consider how you might computerise the delivering postman's signature book. [1 hour.] |
|
Submitting Exercises for Assessment and Feedback (Fee-Paying Clients Only): Simply e-mail your answer(s) for full tutorial feedback. State each conclusion clearly, and briefly explain how you arrived at it. You may do this one exercise at a time, or all at once. Additional questions may then be asked, and additional tasks given as required. [Submit an Exercise] Please cooperate with this student-tutor exchange, because it will eventually form the basis of your individual student progress record. Do not proceed to Lesson IT2.2 until all the tutorial tasks are completed and signed off. |
|
Lesson IT2.2: Functions and Features
We turn now to the concept of system functionality. In its simplest form, this is the name given to what a system does, and there are only three things to remember. The first is that functionality needs to be thought through in advance, the second is that it needs to be written down, and the third is that in the IT world - if you do not ask for your system to do something when you order it, then it will invariably not do it when it arrives! This lesson shows you a shorthand form of stating what you want. The material is organised under three sub-headings, namely core functions (what you really want done), ancillary functions (what you also want done, but might forget to ask for), and features (how you want your system to be or behave):
Core Functions: These are the things you really want the system for. Thus, maintaining patient records or paying employees are core functions, in just the same way that keeping you warm and dry is the core function of a new topcoat. You need to be specific but concise when stating required functions, as shown in the following bullet point examples (not all from the same system, and deliberately not in any particular order):
* the system must display a screen which looks like Form XYZ. [Where Form XYZ is a document from the existing system.]
* the system must produce a printed report which looks like Report XYZ. [Where Report XYZ is a document from the existing system.]
* the system must maintain a prioritised waiting list in the form of an indexed file of patient records.
* the system must allow 80 characters of free-format annotation on each new record
* the system must maintain records of clinicians' daily availability.
* the system must compare clinicians' daily availability and skills against cases from the waiting list; this process should be carried out daily 14 days in advance.
* the system must allocate the next available appointment slot
* the system must allow all outstanding appointments to be browsed by date and time
* the system must maintain a database of individual patient records going back 18 months from the first day of the current year.
* the system must allow new patient records to be keyed in by any user, but amended and deleted only by approved senior users identified by password
* the system must totally prevent accidental deletion of patient records
* the system must accumulate monthly statistics
* the system must interface automatically with month-end statistics systems
Traps For The Unwary - Derived Data:
As was seen in Lesson IT1.4, all higher-level information take their inputs from the outputs of a variety of lower-level feeder systems.With a typical small system you should expect a core functionality list of about 30 items, and the task of preparing them may take some time. Particular attention will be needed when information is first input (when you need to specify what is being stored and where it came from), and when it is ultimately put to use (when you need to specify what is being extracted, how it is to be laid out, and who is going to get it next).
Ancillary Functions: These are also what the system does, but they are less obvious and thus easier to forget about. The point here is that when specifying a car you could ask for it to have a starter motor, windscreen wipers, locks, ash trays, petrol cap, etc., but you would probably not bother because you would presume they would be included. This considerably prolongs the specification process, but it is well worth putting in the extra effort because ancillary functions actually make all the difference between successful and unsuccessful systems. Some areas where this sort of additional functionality might be useful are in the accumulation and display of performance indicators, the provision of comprehensive on-screen help, error, and warning messages, and the accumulation of management statistics. Where applications are provided to support those who are going to "operate" a system rather than "use" it, they are often referred to as utilities. Here are some examples:
* the system must accumulate and display upon demand its own MTTR and MTBF reliability statistics [see next lesson]
* the system must prompt hesitant users with short help messages
* the system must support inexperienced users with keyword-indexed explanations and examples
* the system must maintain an audit trail
* the system must maintain an access log, and generate clear warnings of attempted access violations
* in the interests of user-friendliness, the system must default as many screen input fields as it logically can.
Key Concept - Defaulting Fields:
Each discrete data item on a computer screen or record is known as a field. When systems "default" fields, they set them to what they predict the user will be inputting. This speeds up input most of the time. With addresses, for example, no typing will be needed most of the time if the address fields are defaulted to the last known address, but the defaulted details can nevertheless be overtyped on the rare occasions that it proves necessary.* the system must produce a daily summary of the number of different transactions, complete with average response times
* the system must force passwords to be changed after a set number of days, and will allow that set number to be varied by approved senior users identified by password.
With a typical small system you should expect an ancillary functionality list of about 20 items. The requirements of the Data Protection Act, 1998 (see Unit IT9) will be particularly troublesome to meet.
Features: These describe how the system is, or what it is like. They are its attributes rather than its functions, as when asking of a car that it be able to do nought-to-sixty in less than six seconds. There are a number of important system features to bear in mind, as follows:
Connectivity: This is a measure of how readily elements of your system will talk electronically to other systems in use within your organisation.
Security: This is a measure of how well-protected a system is against unauthorised access. [There is an entire study unit devoted to this topic later in the programme.]
Auditability: This is a measure of how easy it is for the IT auditors to find out what they want to find out.
User Friendliness: This is a measure of how easy a system is for a novice to use. This feature is enhanced by having comprehensive built-in help facilities and a well-thought out machine-user dialogue.
Reliability: This is a measure of how often (if at all) the system can afford to fail. It is usually expressed as the mathematically derived concepts of mean time between failures (MTBF) and mean time to repair (MTTR). The point is that systems can be made very reliable (and need to be if they are in any way safety critical), but you will end up paying very heavily for that privilege. Further details follow in Lesson IT2.3.
Key Concept - Human Error:
Chris Johnson of the University of Glasgow points out rather ominously that existing theories of IT systems design are poor at designing systems to minimise the potential for human error. Sadly this is too large an issue to be developed here, but interested students are recommended in the first instance to the Johnson paper itself [click here], then to the rest of his website [click here], and then to our own material on the cognitive psychology of error in study unit SU1.Sell-ability:
This is a measure of how marketable a system is. Sell-ability should be designed into a system from the very outset because there is no greater tribute to your professionalism - and no better way of reducing your system's costs - than being able to sell it on to other units facing the same problems.
LESSON RATIONALE:
And why does all this matter? Because there is a lot more to specifying a system's functionality than simply asking it to add 1 and 1. It takes time and no little effort to produce a comprehensive specification, and your proposed system is doomed to failure without it.
|
EXERCISES (AND STANDARD STUDY TIMES): Depending on how thoroughly you have been exploring the hyperlinks provided, it has probably taken you less than 30 minutes to read the foregoing text, and now you have to do some real work. Complete the following exercises, taking careful note of the expected study times: |
|
|
IT2.2.1 |
Get your IT department contact to explain the terms "audit trail" and "safety-critical system". |
|
IT2.2.2 |
Referring back to Exercise 2.1.4, imagine that you have decided to go ahead with computerising the delivering postman's signature book. Draw up your proposed requirements list in bullet point form, keeping related points together and in a reader-friendly sequence. |
|
Submitting Exercises for Assessment and Feedback (Fee-Paying Clients Only): Simply e-mail your answer(s) for full tutorial feedback. State each conclusion clearly, and briefly explain how you arrived at it. You may do this one exercise at a time, or all at once. Additional questions may then be asked, and additional tasks given as required. [Submit an Exercise] Please cooperate with this student-tutor exchange, because it will eventually form the basis of your individual student progress record. Do not proceed to Lesson IT2.3 until all the tutorial tasks are completed and signed off. |
|
Here is some additional vocabulary on the topic of system reliability:
|
Mini Glossary - Reliability |
|
Availability: This is one of several measures of system reliability, and takes into account not only how often a system fails, but how long it takes to put it right again. The statistic is derived from the MTBF and MTTR figures, according to the formula:Availability = (MTBF/(MTBF + MTTR)) x 100 |
|
Burn-In Failures: These are failures which take place very quickly after implementation, and represent undetected weak components. One of the functions of systems and acceptance testing may be regarded as allowing burn-in failures to take place in a pre-operational environment before they are in a position to do real damage. |
|
Burn-Out Failures: These are failures which take place at or about the specified life expectancy of a component. There is no suspicion of inherent weakness in such components, merely that they have finally succumbed to "fair wear and tear". To an extent, burn-out failures can be predicted, and their impact minimised, by preventive maintenance. |
|
Downtime: A period of loss of service. |
|
Fail-Safe Design: This is a design philosophy which sets a failing system to a state which can do minimum harm. A bank's cashpoint machine, for example, should fail to a LOCKED position, a signalling system should fail to RED, braking systems should fail to BRAKES ON, and a medical monitoring system should fail to ALARM SOUNDING. |
|
Failure: A failure is an inability of one of the systems assets to perform within specified tolerance. Failure can be partial or complete, and can arise from design or production error or oversight, or from misuse, or from straightforward wear and tear. Failures are measured by how often they occur, namely their failure rate. Several classes of failure can be identified, including burn-in failures and burn-out failures. |
|
Failure Profile: This is a graphical plot of failure rate against time. The resulting curve is a wide inverted U shape, indicating the period of burn-in and burn-out failures separated by a period of relatively stable operation. In fact, the curve can be divided into four zones. Zones 1 and 4 are the burn-in and burn-out zones. Zone 2 is a period of normal life characterised by few failures, and Zone 3 is a period of additional normal life obtained by keeping the system regularly maintained. Zone 3 has an increasing likelihood of failures but not yet at the burn-out rate. Zone 2 and Zone 3 taken together constitute the "useful working life" of the system. |
|
Failure Rate: Failure rate is how often an asset fails per unit time. The index is referred to by the Greek letter lambda (l). |
|
Fault Tolerance: A measure of how able a system is to continue functioning despite the failure of one or more of its components. |
|
MTBF: This stands for mean time between failures. It is a good reliability measure for systems requiring continuous operation. It is referred to by the letter m, and is calculated by taking the reciprocal of the failure rate. Thus m = 1/l. It is useful to know the MTBF for each system asset. This is because it then becomes possible to schedule routine preventive maintenance. |
|
MTTF: This stands for mean time to failure. It is an alternative measure to MTBF where the item in question is a non-repairable "one-shot" system like a guided missile. The concept is not greatly used in general purpose computing. |
|
MTTR: This stands for mean time to repair, and represents the average time to effect a repair. This statistic is useful because, in conjunction with MTBF, it allows the average availability of a system to be calculated. |
|
Preventive Maintenance: This is the carefully scheduled replacement of intact system components as they approach the burn-out failure zone of the failure profile. |
|
Redundancy: This is the deliberate duplication of a system asset with a view to having automatic back-up should one of the components fails. This allows emergency repair without downtime, but only at the cost of having created a more expensive product to start with. |
|
Reliability : Reliability is "the ability of a product to function successfully, when required, for the period required, in the specified environment." (Robertson, 1971:138.) The reliability of a system made up of many assets, each of which can fail, is made up from the individual failure rates of the components. There are several standard measures of reliability, the most commonly encountered being MTBF, MTTF, and MTTR. |
|
Useful Working Life: (See firstly failure profile.) The period of relatively trouble-free operations after the last of the burn-in failures and before the first of the burn-out failures. |
LESSON RATIONALE: And why does all this matter? Because once completed the functionality list will be used in two important places. Firstly, it forms the cornerstone of the Feasibility Report, an early formal request for system funding (to be covered in Unit IT5), and secondly it is repeated - supported by copious field-level detail of file, record, screen, and report layouts - in the Requirements Specification, the system commissioning document which is produced after funding has been obtained.
|
EXERCISES (AND STANDARD STUDY TIMES): Depending on how thoroughly you have been exploring the hyperlinks provided, it has probably taken you less than 30 minutes to read the foregoing text, and now you have to do some real work. Complete the following exercises, taking careful note of the expected study times: |
|
|
IT2.3.1 |
A system is normally available between 9am and 6pm. It fails at 4pm one afternoon and becomes available again at 10am the day after next. What was the downtime? [5 minutes.] |
|
IT2.3.2 |
At the end of its first operating year, a system has an MTBF of 73 days and an MTTR of 1.5 days. What should you claim its availability as? [5 minutes.] |
|
Submitting Exercises for Assessment and Feedback (Fee-Paying Clients Only): Simply e-mail your answer(s) for full tutorial feedback. State each conclusion clearly, and briefly explain how you arrived at it. You may do this one exercise at a time, or all at once. Additional questions may then be asked, and additional tasks given as required. [Submit an Exercise] Please cooperate with this student-tutor exchange, because it will eventually form the basis of your individual student progress record. Do not proceed until all the tutorial tasks are completed and signed off. |
|
If you have got to this point by mistake, click to return as appropriate:
Otherwise, congratulations!! You have reached the end of Unit IT2 of the INFORMATICS programme. Click to proceed to
Unit IT3, and good luck!
Robertson, A.G. (1971). Quality Control and Reliability. London: Nelson.