Chapter 8 Analysing user requirements
Tools of analysis
The tools of analysis are not complex. They consist of list, structure charts, grid charts and flowcharts.
Lists
Objectives, decisions, data etc, need to be recorded. If each such item is a separate entity (is no item is a subclass of any other), a simple list of the items and their attributes is adequate. The items of data on the Clerical Document Specification provide an example. Where one item in a list can be divided into several items at a lower level of detail, it is necessary to show this in some form of structure.
Structure charts
Probably the best known representation of a structure is the ‘family tree’, as used in the organization chart. Where the structure is very complex, or where there are many items at one level, a structured list provides a more convenient and compact format. Having divided the factor we are considering into its component parts we now need a means of systematically comparing each part with each other part. The appropriate tool is the grid chart.
Grid Charts
Grid charts were examined in the last chapter as an aid to fact-finding. Their use in analyzing facts is now indicated.
A grid chart consists essentially of two lists, one enter vertically, the other horizontally, with the intersecting squares showing the relationship. Different sets of facts are entered, and different codes used to show different relationships. Thus the grid chart can assist in moving from one complex set of factors to the next.
Flow charts
A flowchart caters fro both parts of the analysis process. It divides a procedure into its parts and shows the logical relationships between the pats. It can also show relationships between steps in a procedure and the date used by, or produced by, the procedure. A flowchart can be analysis in detail, with each symbol being queried ( ‘How does the operation document, or file contribute to system objectives?’)
Steps in Analysis
The logical steps in analysis are shown. In outline, in figure.
At each step it is necessary to:
-identify the relevant facts, and establish the relationships between them:
-compare that set of facts with the set at each adjoining step and establish the relationships between the fact in these sets.
Objectives results
Analysis starts with the objectives of the system. Before considering details such as data or procedures, a list of the results of the system needs to be rigorously compared with a list of the stated objectives. If there is no discrepancy, then either there is no point in continuing g the investigation or the objectives have not been properly formulated. An example of such a combination is shown
| SALES ORDER PROCESSING SYSTEM | |
| OBJECTIVES | RESULTS |
| 1.Fulfil customer orders for spares 80% in 48 hours 95% in 7 days 99% in 10 weeks No order to be outstanding > 6 months | 65% in 48 hours 80% in 7 days 94% in 10 weeks 3 orders outstanding > 6 months |
| 2.Provide re-order information within maximum 1 hour of re-order point being reached | 30% next day average 2 ½ hours |
| 3.Provide purchasing department with supplier performance record by Wednesday of following week | Currently 2 weeks late |
| 4.Provide sales Manager sales trend graphs not later than following Tuesday | Currently 1 week late |
Results/actions
If the investigation is to continue, similar lists need to be drawn up comparing the results with the actions which cause those results. The actions may be clerical processes, in which case they are within the scope of the systems analysts, or they may be physical processes which fall outside that scope. In either case, if there is reason to suspect that the source of dissatisfaction lies in any of these processes, a case needs to be made to management for an investigation by appropriately qualified staff.
Actions/instructions
Action other than accidental ones, occur as a result of instructions. The same list of actions now needs to be compared with a list of the instructions which give rise to those actions. The instructions may emanate from a data processing function or from management. They may be ambiguous, indecipherable, mutually contradictory, late or may never arrive at all. If incorrect actions are taken as a result of some fault in the instructions, this needs to be followed up and the faults identified. It is worth nothing that there are often several different views of a system given to the systems analyst, e.g.:
- what the manager thinks is done;
- what the operator thinks the manager wants done;
- what the manager tells the operator to do;
- what the instructions say should be done;
- what the operator thinks the systems analyst wants to know.
Actions/notification
If the data held is to be accurate, there must be a feedback of each action completed into the data processing system (which need not of course be computer-based). The notification may be for individual actions, or for the total number of a given action taking place per our, day or week. It may be done on paper, by word of mouth, or be some mechanical or electronic means. In order to be sure that this is being carried out accurately, it is necessary to compare the actions taken with a representative sample of the notifications of those actins as received by the data processing system.
Instructions/decisions
If the instructions derive routinely from the data processing system them it is time to start examining the processes. If the instructions come from management, there is a need to compare the instructions which reach the action point with the decisions taken by management, to ensure that there is no failure in communication. Again, tow lists should be all that is necessary for rigorous and effective comparison to be made.
Decisions/information
Decisions are taken on the basis of information. Not all the information that a manager uses fro a given decision comes from a data processing system. It may come from specialist adviser’s external sources, or the manager’s own files or memory.
Information/data and data/procedures
Information is data organized in meaningful from. The various items or information required now need to be compared with the items of data available. The source of such data my be outside the system (from suppliers, customers, government departments, etc) or from within the system, in the from of notifications. The data may be input on each occasion or may be stored as master data within the system.
The formal comparison is carried out using an Input/Output grid cart. A separate grid is drawn up fro each individual output.
Some of the items required as output may be identical to items already is the system, while some may be produced a s result of some procedure acting on one or more items in the system. These different categories will become apparent as a result of the comparison made on the input/output grid.
Analyzing the procedures
The main check to be done on any procedures developed at this stage is to see that no unnecessary steps are included. The method consists simply of questioning what is achieved by each procedure.
A comparison also needs to be made between the procedures required to produce routine outputs and those required to produce management information, particularly with regard to frequency. If the system is to be computer-based, effort has to be devoted to identifying the procedures suited to computerization, and those to be handled manually.
Analyzing the organization structure
As part of all the above steps the systems analyst will be considering the appropriateness of the current organization structure, but at some stage this question must be tackled specifically. Initially the analyst must take a conceptual approach, treating the organization as though new, and asks the questions ‘why does the department exist? Why does the application exist? What is its purpose? Is it fulfilling that purpose efficiently?’ then the activities of each department must be examined carefully. The analyst must look for unnecessary or redundant functions, duplication of responsibilities, and too much or too little communication, complaints from people who deal with the department, high absenteeism, and frequent, heavy overtime. These are all indicative of a need for changes.
Statistical analysis
Statistical techniques should be used whenever applicable, e.g. to determine sample sizes, to classify data into useful, logical groupings, to isolate the important/significant from the irrelevant, to compare relative values, and to illustrate and compare trends and rates of change. This quantitative information will assist in the design of the computer system as well as pinpoint problem areas at the analysis stage.
Chapter 9 Logical system Definition
Design Obejectivies
At an early stage in defining a new system, the systems analyst must have clear understanding of the objectives which the design is aiming to fulfill. Theses objectives must b established by management and included in the terms of reference fro the project. There is usually more than one way of achieving a desired set of results. The acceptable design is likely to be a compromise between a number of factors; particularly, cost, reliability, accuracy, security, control, integration, expansibility, availability, and acceptability.
Cost
Cost is associated with the two activities of development and operation. Development comprises all the stages from initial design to successful implementation. Operation includes data preparation, processing, and handling of output and consumables (particularly paper).
Reliability
This includes the robustness of the design, availability of alternative computing facilities in the event of breakdown, and the provision of sufficient equipment and staff to b handle peak loads (whether seasonal or cyclical).
Accuracy
The level of accuracy needs to be appropriate to the purpose. For instance, the accounts of an individual customer will probably be kept to the nearest penny, whereas the monthly sales fro a region may only be required to the nearest $1000. for each defined level a balance needs to be achieved between avoidance of error and the cost of avoiding the errors.
Security
There are many aspects to security, but the ones which particularly concern the systems analyst are confidentiality, privacy, and security of data.
Confidentiality
Some information, vital to the success of a firm, could cause severe damage if it reached the hands of competitors. The system has to ensure that only authorized staffs have access to such information.
Privacy
This concerns information about the individual employee or members of the employee’s family. If the personnel file or the payroll file if held on the computer, the design of the system must guard against any unauthorized access to the information.
Data security
If the data held on computer files is incorrect, then the system objectives cannot be achieved. Measures are needed to guard against alteration or destruction of data, whether accidental or intentional.
Control
The system would give management the facility to exercise effective control over the activities of the organization. One way is the provision of relevant and timely information, particularly by extracting the important information from the mass of available but less important information: this is the principle of ‘exception reporting’, able to produce ad hoc reports. Another essential approach is routing control of goods and monies handled.
Integration
The different systems which make use of any item of information may be designed at different points in time: there is a need for consistent documentation, regardless of who is doing the design.
Expansibility
Any system needs to be able to cope with seasonal or cyclical variations in volume. Estimates need to be made of volume tends, and there has to be provision fro handling whatever load the trends predict fro the expected life of the system.
Availability
It is the responsibility of the systems analyst to ensure that all the resources required to make the system work are available at the planed implementation time. These can include buildings, hardware, software, stationery, computer operations staff and procedure manuals, as well as the fully tested and working system.
Acceptability
A system which the analyst believes to be perfect is certain to fail unless it has the support of the user departments and management, as well as the support of programming and computer operations.
Outline design of outputs and inputs
During analysis, conclusions should have been reached on the content, frequency and urgency of outputs, both fro information required by management and fro routine documents, such as pay slips, advice notes, invoices. The analysis should also have shown the relationships between the individual items on each output and the items available as inputs to the system. Where the item to be output is different from the item available as input, the analysis should also have identified the logical steps required to produce the one from the other.
The output reports and input documents should be documented in terms of data content and approximate layout it is not necessary to define the method of presentation (eg visual display messages or printed lines). It is possible to work back from the output contents, through the system, to the inputs required. This is done by determining which output data items are derived by calculation or by logical deduction; all other items can temporarily be considered to be input to the system. These input items can then be broken down into those which require fresh input every time, as part of input transaction documents, and those which it is more appropriate to store on file because they are historical or relatively static. For example, in designing a sales invoicing system, one might begin by listing the data items required on the invoice eg:
n invoice number;
n date;
n order number;
n customer number;
n customer address;
n product number;
n product description;
n quantity delivered;
n price;
n value;
n VAT rate;
n VAT amount
n Total value;
n Total weight.
If the user agreed with this content, the analyst might then examine the system in terms of what input to the system would cause an invoice to be produced (ie a delivery note) and what date items would be needed on this delivery note. Clearly certain data items on the output invoice are derived.
The next step is to examine the remaining data and to decide which needs to be freshly input each item and which can be stored on file. In this example, customer address,, product description, price, and VAT rate are clearly static data items which could be stored. The customer address would then be identified via the customer code and the product description, price and VAT rate via the product number. In other words the system begins to look like this:
PROCESSING REQUIREMENTS
Once THE outputs, inputs and stored data have been definer, it is necessary to decide what procedures ar required to process the inputs, keep the records up-to-date and produce the outputs. There are two major areas fro concern here: firstly, which procedures should be handled by the computer and which b human beings; and secondly, what type of computer processing required.
Partitioning into computer and manual subsystems
This is one of the major problem areas for the systems analyst-deciding which parts of the system can/should be computerized – and is one in which judgement and experience are important. One essential point is that the systems analyst should not set out to ‘put everything on the computer’; this is not feasible in most instances, because complex, open systems require human interaction.
Batch or on-line processing
The decision about the nature of processing in the system will be influenced by a large number of factors, including response time, frequency, data volumes, hardware constraints(especially for data collection), security requirements, and cost.
Response time
Response time refers to the maximum acceptable time interval between a request for information and its receipt by a user. There are not many system which require immediate response after full processing of input data; a day and sometimes even a week is perfectly adequate in most cases. But for those systems which require fast response, some type of on-line system is required.
Frequency
Frequency refers to how often the users require to retrieve information from the computer system. This may be at regular or varying intervals, but is not usually time –critical. For systems which require up-to-date information about the state of a file , again the file will need to be updated in on-line mode.
Data volumes
One of the factors which will greatly affect the cost of an on-line system is the volume of data at specific points in time. For example, if sales orders are entered on-line, the n the system must be able to cope with the peak loading which may be seasonal. The order entry load in the weeks before Christmas for a mail order company may require a system fro that period which is much larger than is needed for the rest of the year.
Hardware constraints
One of the major constraints on the type of processing is of course hardware availability in the organization. Data which cannot be easily keyed in cannot be handled easily in an on-line transaction processing system. Usually, data collection facilities are the limiting factor in the decision whether to go on-line.
Security requirements
The security requirements of a system can have a significant impact on the nature of processing in the proposed system. Security is more expensive and more difficult to achieve in an on-line system. This makes severe demands on the system designer.
Cost
Finally, cost can be an inhibiting factor. Usually the cost of on-line processing cannot be justified in simple comparison with the previous system.
User system specification
Interactive Nature of logical and Physical design
No comments:
Post a Comment