Management Information Systems Discussion
giggles.desmoin
Ch10ManagementInformationSystems.pdf
CHAPTER
1 Systems analysis
LEARNING OUTCOMES
After reading this chapter, you will be able to:
■ define the importance of conducting the analysis phase to the overall success of the system;
■ choose appropriate techniques for analysing users’ requirements for an information system;
■ construct appropriate textual descriptions and diagrams to assist in summarising the requirements as an input to the design phase.
MANAGEMENT ISSUES
Careful systems analysis must be conducted on each BIS project to ensure that the system meets the needs of the business and its users. From a managerial perspective, this chapter addresses the following questions:
■ Which different aspects of the system must be summarised in the requirements document?
■ Which diagramming tools are appropriate to summarise the operation of the existing and proposed systems?
CHAPTER AT A GLANCE
MAIN TOPICS
■ Identifying the requirements 350
■ Documenting the findings 359
■ Systems analysis – an evaluation 383
■ Software tools for systems analysis 384
FOCUS ON . . .
■ Requirements determination in a lean or agile environment 358
■ Soft systems methodology 379
CASE STUDIES
10.1 IFD drawing – a student records system 362
10.2 ABC case study 384
CHAPTER
1 CHAPTER
10
M10_BOCI6455_05_SE_C10.indd 349 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT350
Once it has been determined that it is desirable to proceed with the acquisition of a new BIS, it is necessary to determine the system requirements before any design or development work takes place. Systems analysis is about finding out what the new system is to do, rather than how. There are two basic components to the analysis process:
■ Fact-finding. An exercise needs to take place where all prospective users of the new system should contribute to determining requirements;
■ Documentation. Detailed systems design follows the analysis stage and it needs to be based on unambiguous documentation and diagrams from the analysis stage.
Systems analysis involves the investigation of the business and user requirements of an information system. Fact-finding techniques are used to ascertain the user’s needs and these are summarised using a range of diagramming methods.
Factors that will influence the use of fact-finding techniques and documentation tools will include:
■ The result of the ‘make-or-buy decision’. Made during the feasibility stage, a ‘make’ decision where bespoke software is developed will need more detailed analysis than a ‘buy’ decision where packaged software is purchased off-the-shelf, especially when the results of the analysis process are fed into the design stage.
■ Application complexity. A very complex system or one where there are linkages to other systems will need very careful analysis to define system and subsystem boundaries, and this will lead to use of more formal techniques when compared with a simple or standalone application.
■ User versus corporate development. User development does not lend itself to extensive use of formal analysis tools. However, basic analysis is required and there are certain analysis tools that user developers can use that increase the probability of success. Similarly, where application development by IS/IT professionals occurs there will be a need for a more formal approach, especially where systems cut across functional boundaries.
Any errors in systems development that occur during the analysis phase will cost far more to correct than errors that occur in subsequent stages. It is therefore essential that maximum thought and effort be put into the analysis process if unanticipated costs are not to arise in the later stages of development.
INTRODUCTION
Systems analysis
The investigation of the business and user requirements of an information system. Fact-finding techniques are used to ascertain the user’s needs and these are summarised using a requirements specification and a range of diagramming methods.
The emphasis in this section will be on those methods typically used during the traditional systems development lifecycle approach to software development. However, it is recognised that lean and agile approaches to software development will focus on techniques that are particularly relevant to those methods. Therefore, these will be commented on later in the chapter in a ‘Focus on’ section.
The main purpose of the requirements determination phase of a systems development project is to identify those user requirements that need to be incorporated into the design of the new information system and that the requirements identified ‘really’ meet the users’ needs. Therefore, the first task in analysis is to conduct a fact-finding exercise so that the information systems requirements can be determined. Unfortunately, as identified by Shi et al. (1996) and by Browne and Rogich (2001), there are a number of reasons why this is very difficult for many organisations:
■ user limitations in terms of their ability to express correct requirements;
IDENTIFYING THE REQUIREMENTS
M10_BOCI6455_05_SE_C10.indd 350 30/09/14 7:21 AM
351ChaPter 10 SYSTEMS ANALYSIS
■ lack of user awareness of what can be achieved with an information system (both in terms of under- and over-estimating an information system’s capabilities;
■ different interpretation of software requirements by different users; ■ existence of biases amongst users so that requirements are identified on the basis of
attitude, personality or environment rather than real business needs; ■ requirements may overlap organisational boundaries (e.g. between different functional
areas of the business) such that conflicts occur when identifying requirements; ■ information requirements are varied and complex and this can lead to difficulties in
structuring requirements so that they can be properly analysed; ■ communication issues can result because of the complex web of interactions that exists
between different users.
Nonetheless, while the task of requirements determination may be difficult, it must still be undertaken if the developed system is to have those features that the users and the organisation actually need. The methods an organisation uses in the analysis phase will depend, at least in part, on two factors:
■ Levels of decision making involved. A new information system will be under consideration either to resolve a problem or to create an opportunity. In either case, the objective is to improve the quality of information available to allow better decision making. The type of system under consideration may include a transaction processing system, a management information system, a decision support system, a combination of these or some other categorisation of system (Chapter 6). So, for example, an information system that is purely geared towards the needs of management will require a different approach to fact-finding (for example, using one-to-one interviews with senior managers) from one that mainly involves transaction processing (for example, using observation of the existing process).
■ Scope of functional area. A new information system may serve the needs of one functional business area (e.g. the HRM function), or it may cut across many functional areas. An information system that is restricted in scope may be faced with fewer of the problems that can affect new systems designed to meet the needs of many different areas. As before, the techniques of fact-finding may be similar, but how they are used and the findings presented may be radically different. Organisational culture, structure and decision-making processes will all have a part to play in selling the systems solution to all the affected parties.
Regardless of the scope and organisational levels involved, the objective of the fact- finding task is to gather sufficient information about the business processes under consideration so that a design can be constructed which will then provide the blueprint for the system build phase. We will now turn to a consideration of a number of fact- finding methods.
Although it might be thought that finding out the requirements for a system is straightforward, this is far from the case. Dissatisfaction with information systems is often due to the requirements for the information system being wrongly interpreted. Figure 10.1 shows an oft-quoted example of how a user’s requirements for a swing might be interpreted, not only at the requirements analysis stage but throughout the project.
As noted by Browne and Rogich (2001), the most popular strategy likely to be adopted by an analyst is to use structured interviews with the people who will use the new system and to identify the procedures they follow in performing their tasks and also to identify the information they need to perform them. A successful requirements determination exercise
Interviewing
M10_BOCI6455_05_SE_C10.indd 351 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT352
Figure 10.1 Varying interpretations of a user’s requirements at different stages in a project
What the users’ manager specified
The requirements specification The design
First delivery Final delivery after ‘fixing’
What the users really wanted
will require the analyst to elicit from the users both their understanding of the current business environment and current information needs and flows and also a visualisation of the preferred future organisational environment and information needs. The difficulties associated with this have already been indicated above.
During interviewing, a range of staff are interviewed using structured techniques to identify features and problems of the current system and required features of the future system.
Success with this method involves careful planning, proper conduct of the interviews themselves and, finally, accurate recording of the interview findings. We can expand each of these to provide more detail.
Planning
■ Clear objectives need to be set to identify what needs to be achieved at the end of the interviewing process.
■ Interview subjects must also be carefully selected so that the information gained will be relevant to the system being developed. For example, there may be little use in interviewing all the shopfloor workers in a manufacturing company if the system being developed is an executive information system (EIS) to assist with decision making at senior levels within the business. There may still be some merit in interviewing certain key personnel involved in operational decision making, since data produced may be useful in the proposed EIS.
■ Customers should be involved in analysis if the use of a system affects them directly. For example, a customer of a phone-based ordering system or a telephone bank may well give an insight into problems of an existing system.
■ The topics the interview is to cover need to be clearly identified and the place where interviews are to take place must be determined.
■ Finally, it is necessary to plan how the interviews are to be conducted and the types of questions to be used.
Analysis technique – interviewing
Recommended practice: a range of staff are interviewed using structured techniques to identify features and problems of the current system and required features of the future system.
M10_BOCI6455_05_SE_C10.indd 352 30/09/14 7:21 AM
353ChaPter 10 SYSTEMS ANALYSIS
Conduct
■ The interviewer must establish a control framework for the interview. This will include the use of summarising to check the points being made and appropriate verbal and non- verbal signals to assist the flow of the interview.
■ Interviewers must be good listeners. This is especially important when dealing with complex business processes which are the object of the systems development project.
■ The interviewer must select a mix of open and closed questions which will elicit maximum information retrieval.
■ Finally, the interview must be structured in an organised way. There are three main approaches to structuring an interview. The first is the ‘pyramid structure’, where the interview begins with a series of specific questions and during the course of the interview moves towards general ones. The second is the ‘funnel structure’, where the interviewer begins with general questions and during the course of the interview concentrates increasingly on specific ones. The third approach is the ‘diamond structure’, where the interview begins with specific questions, moves towards general questions in the middle of the interview and back towards specific questions at the end.
Regardless of which approach is taken, it will still be necessary to document carefully the findings of the interview.
Interviews should use a mixture of open and closed questions. Open questions are not restricted to a limited range of answers such as Yes/No (closed questions). They are asked to elicit opinions or ideas for the new system or identify commonly held views among staff. Open questions are not typically used for quantitative analysis, but can be used to identify a common problem.
Closed questions have a restricted choice of answers such as Yes/No or a range of opinions on a scale from ‘strongly agree’ to ‘strongly disagree’ (Likert scale). This approach is useful for quantitative analysis of results.
Recording
During the course of the interview, the interviewer will need to make notes to record the findings. It may also be useful to draw diagrams to illustrate the processes being discussed. Some interviewers like to use a tape recorder to be sure that no points are missed. Whichever methods are used, the requirement is to record three main attributes of the system under consideration:
■ Business processes. A business process exists when an input of some kind (raw materials, for example) is transformed in some way so that an output is produced for use elsewhere in the business.
■ Data. Data will be acquired and processed and information produced as a con-sequence of carrying out business processes. Data must be analysed so that data acquisition, processing needs and information requirements can be encapsulated in the new information system.
■ Information flows. Functional business areas do not exist in isolation from each other and neither do different business processes within the same business function. It is necessary, therefore, to identify how data and information within one business process are necessary for other business processes to operate effectively.
We will look at some relevant tools and techniques which help to record the findings later in this chapter.
As an information-gathering tool, interviews have a number of advantages and disadvantages. On the positive side they include:
■ the ability to gather detailed information through a two-way dialogue; ■ the ability for candid, honest responses to be made;
Open questions
Not restricted to a limited range of answers such as Yes/No (closed questions). Asked to elicit opinions or ideas for the new system or identify commonly held views amongst staff. Open questions are not typically used for quantitative analysis, but can be used to identify a common problem.
Closed questions
Closed questions have a restricted choice of answers such as Yes/No or a range of opinions a scale from ‘strongly agree’ to ‘strongly disagree’ (Likert scale). Approach is useful for quantitative analysis results.
M10_BOCI6455_05_SE_C10.indd 353 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT354
■ an open, spontaneous process which can lead to valuable insights, especially when open questions are used;
■ responses that can easily be quantified, especially when closed questions are used; ■ being one of the best methods for gathering qualitative data such as opinions, and
subjective descriptions of activities and problems.
On the negative side, however, the following points can be made:
■ The analyst’s findings may be coloured by his or her perceptions of how other, similar, business operations work. Interviewers need to be especially skilled if this is to be avoided.
■ The development of a new information system may represent a threat through the risk of deskilling, redundancy or perceived inability to cope with change. Interviewees may, therefore, not cooperate with the interview process, either by not taking part or by giving vague and incomplete replies.
■ The interviewee may tell the analyst what he or she thinks should happen rather than what actually happens.
■ An interview at lower organisational levels may not yield as much information as some other methods if staff in this area are not capable of articulating with sufficient clarity.
On balance, interviewing is an essential part of the information-gathering process. For maximum benefit, interviewing should be used in conjunction with other techniques, and we will turn to these now.
Analysis techniques – questionnaires
Used to obtain a range of opinion on requirements by targeting a range of staff. They are open to misinterpretation unless carefully designed. They should consist of open and closed questions.
Questionnaires are used to obtain a range of opinion on requirements by targeting a range of staff. They are open to misinterpretation unless carefully designed. They should consist of both open and closed questions.
Questionnaires can be a useful addition to the analyst’s armoury, but are not in themselves enough to gather sufficient information for the later stages of the systems development process. That said, questionnaires can be very useful when used with other fact-finding methods, either to confirm the findings obtained elsewhere or to open up possible further areas for investigation. Typically, they are used before more detailed questions by interview.
Successful questionnaires have a number of characteristics:
■ The questions will be framed by the analyst with a clear view of the information that is to be obtained from the completed questionnaires.
■ The target audience must be carefully considered – a questionnaire designed for clerical or operational personnel should not contain questions that are not relevant to their level of work.
■ The questionnaire should only contain branching (e.g. ‘if the answer to Question 3 was ‘No’, then go to Question 8’) if it is absolutely necessary – multiple branches create confusion and may lead to unusable responses.
■ Questions should be simple and unambiguous so that the respondent does not have to guess what the analyst means.
■ Multiple-choice, Likert-scale-type questions make the questionnaire easier to fill in and allow the results to be analysed more efficiently.
■ The questionnaire should contain the required return date and name of the person to whom the questionnaire should be returned.
Questionnaires
M10_BOCI6455_05_SE_C10.indd 354 30/09/14 7:21 AM
355ChaPter 10 SYSTEMS ANALYSIS
Difficulties that can be encountered with questionnaires include:
■ the inability of respondents to go back to the analyst to seek clarification about what a question means;
■ difficulty in collating qualitative information, especially if the questionnaire contains open-ended questions;
■ the inability to use verbal and non-verbal signals from the respondent as a sign to ask other or different questions;
■ low response rates – these can be lower than 20 to 25 per cent when sent to other organisations or customers, which means that a large sample size is needed if the results are to carry any weight. Response rate is not such a problem with internal staff.
By contrast, the questionnaire process also has a number of benefits:
■ When large numbers of people such as customers or suppliers need to be consulted, a carefully worded questionnaire is more efficient and less expensive than carrying out large numbers of interviews.
■ Questionnaires can be used to check results found by using other fact-finding methods. ■ The use of standardised questions can help codify the findings more succinctly than
other tools.
In summary, questionnaires can have a useful role to play in certain circumstances, but they should not be used as the sole data-gathering method.
Documentation reviews target information about existing systems, such as user guides or requirements specifications, together with paper or on-screen forms used to collect information, such as sales order forms. They are vital for collecting detail about data and processes that may not be recalled in questionnaires and interviews.
All organisations have at least some kind of documentation that relates to some or all of the business operations carried out. A documentation review can be carried out at a number of different stages in the analysis process. If carried out at the beginning of a requirements analysis exercise, it will help provide the analyst with some background information relating to the area under consideration. It may also help the analyst construct a framework for the remainder of the exercise, and enable interviews to be conducted in a more effective way since the analyst has some idea of current business practices and procedures. If document review is carried out later, it can be used to cross-check the actual business operations with what is supposed to happen. The kinds of documentation and records that can be reviewed include the following:
■ instruction manuals and procedure manuals which show how specific tasks are supposed to be performed;
■ requirements specifications and user guides from previous systems; ■ job descriptions relating to particular staff functions which may help identify who
should be doing what; ■ strategic plans both for the organisation as a whole and the functional areas in particular,
which can provide valuable background data for establishing broad functional objectives.
While documentation review can provide a very useful underpinning for other fact-finding tasks, there are still a number of problems:
■ There can be a large quantity of data for an analyst to process. This is especially true in large organisations and it may take the analyst a long time to identify the documentation that is useful and that which can be ignored.
Documentation review
Analysis technique – documentation review
Uses information on existing systems such as user guides, or requirements specifications together with paper or on-screen forms used to collect information such as sales order forms.
M10_BOCI6455_05_SE_C10.indd 355 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT356
■ Documentation is often out of date. If there is an old computerised system, it is quite possible that the documentation has not been changed for years, even though the system may have changed considerably over that period. The same can be said for the documentation of activities and procedures.
Observation
Useful for identifying inefficiencies in an existing way of working either with a computer- based or a manual information system. Involves timing how long particular operations take and observing the method used to perform them.
Observation is useful for identifying inefficiencies in an existing way of working, with either a computer-based or a manual information system. It involves timing how long particular operations take and observing the method used to perform them. It can be time-consuming and the staff who are observed may not behave normally.
This fact-finding method involves the analyst in directly observing business activities taking place so that they can see what is actually taking place rather than looking at documentation which states what should be taking place. One of the benefits of observation is that the analyst can see directly how something is done, rather than relying on verbal or written communication which may colour the facts or be the subject of misinterpretation by the analyst. Other benefits include:
■ the ability to see how documents and records are actually handled and processed; ■ observation may give a greater insight into actual business operations than simple paper
documentation; ■ identification of particular operations that take a long time; ■ the opportunity to see how different processes interact with each other, thus giving the
analyst a dynamic rather than a static view of the business situation under investigation.
On the downside, there are a number of difficulties associated with the observation technique:
■ It is an extremely time-consuming exercise and therefore needs to be done as a supplementary rather than a principal fact-finding method.
■ While observation allows an organisation to be dynamically assessed, it still does not allow attitudes and belief systems to be assessed. This can be a very important issue if the proposed information system is likely to encounter resistance to change among the workforce.
■ Finally, there is the issue of the ‘Hawthorne effect’, where people tend to behave differently when they are being observed, thus reducing the value of the information being obtained. Of course, for the analyst, the problem is in determining whether those being observed are behaving differently or not!
This last effect was first noticed in the Hawthorne plant of Western Electrics in the United States. Here, it was noted that production increased, not as a con-sequence of actual changes in working conditions introduced by the plant’s management, but because management demonstrated an interest in improving staff working conditions.
Despite these difficulties, it is desirable for the analyst to conduct at least some observation to ensure that no aspect of the system being investigated is overlooked.
Observation
Brainstorming
Brainstorming uses interaction within a group of staff to generate new ideas and discuss existing problems. It is the least structured of the fact- finding techniques.
Brainstorming uses interaction within a group of staff to generate new ideas and discuss existing problems. It is the least structured of the fact-finding techniques.
This is the final fact-finding technique we will consider. The methods we have looked at so far are either passive or conducted on a one-to-one basis, or both. The brainstorming
Brainstorming
M10_BOCI6455_05_SE_C10.indd 356 30/09/14 7:21 AM
357ChaPter 10 SYSTEMS ANALYSIS
method involves a number of participants and is an active approach to information gathering. While the other methods allow for many different views to be expressed, those methods do not allow different persons’ perceptions of the business processes and systems needs to be considered simultaneously. Brainstorming allows multiple views and opinions to be brought forward at the same time. If the proposed system’s user community participates actively, it is more likely that an accurate view of current business processes and information systems needs will be reached.
Brainstorming sessions require careful planning by the analyst. Factors to consider include:
■ which persons to involve and from which functional business areas; ■ how many people to involve in the session – too few and insufficient data may be
gathered; too many and the session may be too difficult to handle; ■ terms of reference for the session – there may need to be more than one session to
identify clearly areas of agreement and those that need further discussion; ■ management involvement – a session for shopfloor workers, for example, may be far
less successful if management personnel are involved than if they are not. It would be appropriate, however, for management groups to have their own brainstorming session so that tactical and strategic issues can be tackled rather than simply operational ones.
The main benefit of the brainstorming approach is that, through the dynamics of group interaction, progress is more likely to be made than from a simple static approach to information gathering. Brainstorming sessions, if they are handled properly, can result in the productive sharing of ideas and perceptions, while at the same time cultural factors, attitudes and belief systems can be more readily assessed. Also, when the outcomes are positive ones, a momentum for change is built among those who will be direct users of the new information system. Change management is therefore more easily facilitated.
The main danger of the approach is that in the hands of an inexperienced analyst, there is a risk that the sessions may descend into chaos because of poor structure, bad planning, poor control or a combination of all three.
However, if used properly, this fact-finding method can generate the desired results more quickly than any other information-gathering method. Even so, it still needs to be supplemented by one or more of the other methods discussed above.
Yeates and Wakefield (2004) explain how structured brainstorming can be used to identify different options for a new system. This technique involves the following stages:
■ invite ideas which are written by individuals on separate sheets of paper or called out spontaneously and then noted on a whiteboard;
■ identify similarities between ideas and rationalise the options by choosing those which are most popular;
■ analyse the remaining options in detail, by evaluating their strengths and weaknesses.
It is important when brainstorming is undertaken that a facilitator be used to explain that a range of ideas is sought with input from everyone. Each participant should be able to contribute without fear of judgement by other members. When such an atmosphere is created, this can lead to ‘out-of-box’ or free thinking which may generate ideas of new ways of working.
Brainstorming and more structured group techniques can be used throughout the development lifecycle. Brainstorming is an important technique in re-engineering a business, since it can identify new ways of approaching processes. Taylor (1995) suggests that once new business processes have been established through analysis, they should be sanity-checked by performing a ‘talk-through, walk-through and run-through’. Here, the design team will describe the proposed business process and in the talk-through stage will elaborate on different business scenarios using cards to describe the process objects and the services they provide to other process objects. Once the model has been adjusted, the
M10_BOCI6455_05_SE_C10.indd 357 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT358
walk-through stage involves more detail in the scenario and the design team will role-play the services the processes provide. The final run-through stage is a quality check in which no on-the-spot debugging occurs – just the interactions between the objects are described.
Once the analyst has completed the requirements investigation, it will be necessary to document the findings so that a proposal can be put forward for the next stage of the project. Some of the documentation tools discussed below may be used at the same time as the fact-finding process. For example, information flow diagrams may be used by the analyst to check with the end-user that points have been properly understood.
Research has shown that new ideas and recall are improved by the use of pictures, which tend to prompt thought better than text. This point is well made by Buzan and Buzan (2010), who describe a technique known as ‘mindmapping’ to record information and promote brainstorming. Mindmaps are a spontaneous means of recording information which are ideally applied to systems analysis, since they can be used to record information direct from user dialogues or summarise information after collection.
Another graphical technique which is useful to the system analyst is the ‘rich picture’. The rich picture is an element of the soft systems methodology described later in this chapter.
Pictures and brainstorming
REQUIREMENTS DETERMINATION IN A LEAN OR AGILE ENVIRONMENT FOCUS ON…
As indicated earlier (in Chapter 7), the traditional waterfall approach to software development is by no means the only valid approach to software development, as the increasing adoption of lean and agile approaches bears witness. In the traditional waterfall model, requirements analysis results in a systems specification and a catalogue of user requirements which is then converted into a design specification. However, the emphasis in an agile development environment is on the frequent delivery of software products and the daily involvement of end-users in the software development process. Agile methodologies place an emphasis on delivering working code and downplay the importance of formal processes. It is suggested, therefore, that the software development process can adapt and react promptly to changes that occur in user requirements.
Lindstrom and Jeffries (2004) identify a number of reasons for failed information systems projects. Those relating to requirements determination include:
■ requirements that are not clearly communicated; ■ requirements that do not solve business problems; ■ requirements that change prior to completion of the project.
There is also a tendency for stakeholders to ask for everything to be included in the software, regardless of how much it might be used, thus increasing development costs and maintenance budgets. He also claims that by trying to identify all the requirements up-front, the opportunity to develop and implement the most valuable and high-priority requirements is forgone, thus increasing the payback period for the system.
The requirements determination emphasis with agile methods is, therefore, on the frequent delivery of rapidly implementable software products, where a requirement can be built in a single product release iteration of two to four weeks (depending on the chosen methodology). Critics will claim that this approach results in impossible-to-estimate project costs since the entire project cannot be costed up front (the assumption being that requirements will evolve in response to frequent delivery of software products). However, proponents of agile methods point out that it is better for the customer to be able to call
M10_BOCI6455_05_SE_C10.indd 358 30/09/14 7:21 AM
359ChaPter 10 SYSTEMS ANALYSIS
a halt once they have enough of what they need, rather than to embark on a lengthy development project only to discover that user requirements have changed in such a way that the delivery system is no longer fit for purpose.
In this section we will concentrate on three main diagramming tools: information flow diagrams (IFDs), dataflow diagrams (DFDs) and entity relationship diagrams (ERDs). These techniques are used by professional IS/IT personnel, partly as documentation tools and partly as checking tools with the user community. It is important, therefore, for non- IS/IT personnel to understand the fundamentals behind these diagramming tools so that communication between functional personnel and IS/IT experts is enhanced. Furthermore, tools such as ERDs can be applied by end-users to assist them in developing their own personal or departmental applications. As well as these tools, the requirements specification will also contain a text description of what the functions of the software will be. We will consider this first, and then consider the documentation tools.
DOCUMENTING THE FINDINGS
Requirements specification
The main output from the systems analysis stage. Its main focus is a description of what all the functions of the software will be.
The requirements specification is the main output from the systems analysis stage. Its main focus is a description of what all the functions of the software will be. These must be defined in great detail to ensure that when the specification is passed on to the designers, the system is what the users require. This will help prevent the problem referred to in Figure 10.1.
The scope of the requirements specification will include:
■ Data capture – when, where and how often. The detailed data requirements will be specified using entity relationship diagrams and stored in a data dictionary. Dataflow diagrams will indicate the data stores required.
■ Preferred data capture methods – this may include use of keyboard entry, bar codes, OCR, etc. (it could be argued that this is a design point, but it may be a key user requirement that a particular capture method be used).
■ Functional requirements – what operations the software must be able to perform. For example, for the maps in a geographic information system, the functional requirements would specify: the ability to zoom in and out, pan using scroll-bars and the facility to change the features and labels overlaid on the map.
■ User interface layout – users will want access to particular functions in a single screen, so the requirements specification will define the main screens of an application. Detailed layout will be decided as part of prototyping and detailed design.
■ Output requirements – this will include such things as enquiry screens, regular standard and ad hoc reports and interfaces to other systems.
One approach to documenting requirements is illustrated by the ‘requirements catalogue’ specified in SSADM (discussed in Chapter 7). Figure 10.2 illustrates a typical requirements catalogue entry.
The purpose of the requirements catalogue is to act as the repository of all requirements information. It can be used from the initiation stage when early thoughts are being gathered about the possible requirements, through to the design stage when user requirements may still be emerging (especially in such areas as system navigation and performance requirements).
The requirements specification
M10_BOCI6455_05_SE_C10.indd 359 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT360
There are three main aspects that need to be documented, usually from a user perspective:
■ Functional requirements – consist of requirements that perform the activities that run the business. Examples include updating master files, enquiring against data on file, producing reports and communicating with other systems.
■ Non-functional requirements – define the performance levels of the business functions to be supported. Examples include online response times, turn-round time for batch processing, security, backup and recovery.
■ Quantification of requirements – refers to the need for a measure of quality if the benefits are to be properly evaluated. Examples might include reducing customer complaints by 75 per cent, reducing the value of unsold stock by 85%, or increasing online sales by 25 per cent.
Figure 10.2 Example of a requirements catalogue entry
Source Credit Control Clerk
Owner Credit Control Manager
Requirement ID 5.9
Priority High
Functional Requirements Link Sales Order Processing system in with accounting package so that online credit checking is an automatic process when new orders are being processed.
Non-functional requirements
Response Time Target Value
Within 10 seconds Acceptable range
Within 20 seconds CommentsDescription
Service Hours 08:30 to 18:00 Monday to Friday
Availability 97.5% Above 92.5%
Benefits Will speed up order processing and enable account handlers to spend more time collecting cash rather than continually switching between computer systems when processing orders.
Comments / suggested solutions Either provide a function key to perform the credit check function, or make it an automatic process when an order is entered. Do not allow order to be confirmed if credit check is failed.
Related documents Required System DFD, process box 5.9
Related requirements 3.2. Improve cash collection process – more accurate sales ledger data 4.9. Reduce number of bad debts – link to improved aged debtors report
Resolution 3.2. Improve cash collection process – more accurate sales ledger data 4.9. Reduce number of bad debts – link to improved aged debtors report
REQUIREMENTS CATALOGUE ENTRY
M10_BOCI6455_05_SE_C10.indd 360 30/09/14 7:21 AM
361ChaPter 10 SYSTEMS ANALYSIS
Each entry in the requirements catalogue would typically consist of an A4 sheet that contains the details outlined above. Other elements such as requirements originator, date and links to other formal documentation would be included.
When reviewing the contents of a requirements catalogue, it is desirable to prioritise requirements so that the development effort concentrates on the most important features of the new system. For example, it is possible to categorise user requirements into three: the A list, the B list and the C list (or Priority 1 to 3). The A list should comprise all those requirements that the proposed system must support and without which it would not function. For example, an accounting system that does not produce customer statements may be seriously deficient. The B list would contain those requirements that are very desirable but are not vital to the successful operation of the system. For example, it may be very desirable for a sales order processing system to produce a list of all customers who have not placed an order for the last six months, but it is not essential. The C list would contain those things that are nice to have (the ‘bells and whistles’) but are neither essential nor very desirable. It might be nice in a stock control system, for example, if a screen ‘buzzed’ at the user if a certain combination of factors were present. However, this would not be classified as essential.
The requirements catalogue can be used to prioritise the ‘very desirables’ and the ‘bells and whistles’ so that at the design stage most attention can be paid to those items that are perceived as having the highest priority. It may be, however, that if a low-priority item is seen to be very easy to implement, and a higher-priority item less so, the lower-priority item would be included in the development in preference.
It may be that in the case of a ‘very desirable but hard to implement’ feature, a simpler item might be included as an imperfect substitute. This would be more readily apparent at the design stage and it may be necessary to revisit the requirements catalogue at this point and consult the functional personnel again.
The information flow diagram (IFD) is one of the simplest tools used to document findings from the requirements determination process. It is used for a number of purposes:
■ to document the main flows of information around the organisation; ■ for the analyst to check that they have understood those flows and that none has been
omitted; ■ for the analyst to use during the fact-finding process itself as an accurate and efficient
way to document findings as they are identified; ■ as a high-level (not detailed) tool to document information flows within the organisation
as a whole or a lower-level tool to document an individual functional area of the business.
The information flow diagram is a simple diagram showing how information is routed between different parts of an organisation. It has an information focus rather than a process focus.
An information flow diagram has three components, shown in Figure 10.3. The ellipse in the diagram represents a source of information, which then flows to a destination location. In a high-level diagram, the source or destination would be a department or specific functional area of the business such as sales, accounting or manufacturing. In a lower-level (more detailed) diagram, one might refer to subfunctions such as accounts receivable, credit control or payroll (as you would normally find in an accounts department). The name of the source or destination should appear inside the ellipse. The source or destination is sometimes referred to as an ‘internal’ or ‘external entity’ according to whether it lies inside or outside the system boundary. The term ‘entity’ is used frequently when constructing entity relationship diagrams, and entities are described more fully later.
Information flow diagrams
Information flow diagram (IFD)
A simple diagram showing how information is routed between different parts of an organisation. It has an information focus rather than a process focus.
M10_BOCI6455_05_SE_C10.indd 361 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT362
The information flow, as represented by the arrowhead line, shows a flow of information from a source location to a destination. In an IFD the line should always be annotated with a brief description of the information flow. So, for example, if a sales department sends a customer’s order details to the accounts department for credit checking, the resulting flow might look like Figure 10.4.
Sources or destinations lying within the system’s boundary imply that this information will be used directly by the system. The concept of the system boundary is explained further in Case Study 10.1. This detailed example illustrates how an IFD could be used in practice.
Figure 10.3 Information flow diagrams – the basic building blocks
Source or destination
Information flow
Systems boundary
Figure 10.4 An illustration of a simple information flow
Customer order details AccountsSales
Suppose that a university wished to move from a manual, paper- based student records system to one that was computerised. The analyst would need to create a clear picture of the required information flows to help the system designer with the blueprint for the proposed system. We include some sample narrative to demonstrate the possible result of an interview between the analyst and the head of admissions.
When a student enrols for the first time, they are required to fill in a form which has the following details:
■ forename; ■ surname; ■ date; ■ local authority; ■ home address;
■ term-time address; ■ home telephone number; ■ term-time telephone number; ■ sex; ■ course code; ■ course description; ■ module code (for each module being studied); ■ module description (as above).
When the forms have been completed, they are passed to the student information centre. A series of actions follows:
■ The student information centre (SIC) allocates the student a unique code number which stays with the student until they complete their studies.
IFD drawing – a student records system
CASE STUDY 10.1
M10_BOCI6455_05_SE_C10.indd 362 30/09/14 7:21 AM
363ChaPter 10 SYSTEMS ANALYSIS
The result of your efforts should look something like this:
Step 1 (information generators) ■ STUDENT ■ SIC ■ FINANCE ■ DEPARTMENT
Step 2 (information destinations) ■ STUDENT ■ SIC ■ LEA ■ TUTOR ■ LIBRARY ■ STUDENTS’ UNION
Step 3 (information flows) ■ Student’s personal and course information ■ LEA list ■ Invoices ■ Students on course ■ Class list ■ Enrolment form ■ List of all new students (times two)
Step 4 (adding sources and destinations to the information flows)
■ The SIC creates a card index of the student’s details down to and including course description, plus the new student code number.
■ The SIC also creates a list of all students belonging to each local education authority (LEA).
■ The SIC sends the LEA list to the finance department, which then invoices the LEAs for the tuition fees relating to the students from their area.
■ The SIC creates a study record card (SRC), giving the student details and the modules being studied.
■ The SIC groups the SRCs by course and for each course sorts the cards into student name order; the SRCs for each course are then sent to the department that runs that course.
■ Each department will take the SRCs for its courses and produce a number of class lists, based around the modules that the student is studying, which are then passed to the relevant module leaders.
■ The SIC will issue the student with an enrolment form which the student can use to obtain a library card.
■ Finally, the SIC will pass a list of all new students to the library and the students’ union so that the library can issue students with library cards and the students’ union can issue students with their NUS cards.’
It is necessary to translate the above into a series of information flows and also define the systems boundary (i.e. the line that separates what is in the system under consideration from what is outside it).
In order to be successful in drawing IFDs, it is helpful to follow a few simple steps, since an attempt to draw a diagram from scratch may prove a little tricky:
Step 1 List all the sources of information for the system under consideration (in other words, places where information is generated).
Step 2 List all the destinations (receivers) of informa- tion for the system under consideration.
Step 3 Make a simple list of all the information flows.
Step 4 For each of the information flows identified in Step 3, add the source and destination that relate to it.
Step 5 Draw the IFD from your list that you produced from 3 and 4.
Tips 1. When you have gained experience in doing this, Steps 1
and 2 can be ignored and Steps 3 and 4 can be combined.
2. An information source/destination can appear more than once on an IFD – it can help to eliminate lots of crossed lines (and crossed lines are best avoided since the annotations can look rather jumbled).
3. Use A4 paper, or larger, in landscape mode.
Generator Flow Destination
STUDENT Student’s personal and course information
SIC
SIC LEA list FINANCE
FINANCE Invoices LEA
SIC Students on course DEPARTMENT
DEPARTMENT Class list TUTOR
SIC Enrolment form STUDENT
SIC List of all new students (1)
LIBRARY
SIC List of all students (2) STUDENTS’ UNION
STUDENTS’ NUS card STUDENTUNION
LIBRARY Library card STUDENT
Step 5 (the completed diagram) It is almost certain that if you were to attempt this diagram your results would not be exactly the same. However, provided that all the flows are represented correctly and there are no crossed lines, the result will be perfectly acceptable. Also, note that the student appears twice on the diagram. This is not just because the student is important ➨
M10_BOCI6455_05_SE_C10.indd 363 30/09/14 7:21 AM
364 Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT
union may be able to use an interface file from the student record system to generate NUS cards automatically; but, as with the library, that system would lie outside the scope of the area under consideration. Therefore, we will place the students’ union outside the system boundary.
■ It is reasonable to assume that the tutor is only to receive outputs from the system rather than carry out any processing of the data; it is reasonable, then, for the tutor to lie outside the system boundary.
■ Finally, the local education authority is physically external to the university as well as not being part of the university itself; the LEA should, therefore, lie outside the system boundary.
We can see the result of this analysis in the final IFD, with the system boundary included (Figure 10.6).
You will observe that there are three different types of information flow:
■ the first crosses the system boundary from outside with its destination inside the boundary – it is thus an input to the system from the external environment;
■ the second lies entirely within the system boundary and is, therefore, an output from one area in the system which then forms the input to another;
■ the third begins inside the system boundary and its destination lies outside – it is, therefore, an output from the system into its external environment.
What we have now is a diagram that clearly identifies the context for the systems development under consideration. The diagram can be used by the analyst to check with the prospective system users that all areas have been covered. It also helps the user community build a picture of how a
(which of course they are!), but because it helps avoid crossed lines (Figure 10.5).
What remains now is to consider the systems boundary. If this manual information system were to be replaced by a new computer-based information system, it would be necessary to identify what would be within the systems boundary and what would be external to the system and, hence, outside the system boundary. For the purposes of this example, we will make some assumptions:
■ Students are external to the system – they provide information as an input to the system and receive outputs from the system but are not themselves part of it – students will, therefore, be outside the system boundary.
■ The student information centre is clearly central to the whole system and, therefore, is an integral part of the system under consideration – the SIC will lie inside the system boundary.
■ The finance area needs a further assumption to be made. Let us assume that the finance area operates a computer-based information system for its accounting records and that the proposed system is to interface directly with it; in this case, it would make sense to include the finance area inside the system boundary.
■ Similarly, suppose that the library operates its own computerised lending system. In the new system, it may wish to use an interface between the student records system and its own system for setting up new students’ details. Since the library system is a separate one and does not require development itself, we will place the library outside the system boundary.
■ As with the library, we need to make an assumption about the students’ union information systems. The students’
Figure 10.5 A simple, high-level IFD, excluding the system boundary
SICStudent Finance Student
and course details
Students by LEA
Department LEA
Invoices
Tutor
Class lists
Students’ union
Library
Student
Library card
NUS card
Enrolment form
Students on course
List of new students
List of new students
M10_BOCI6455_05_SE_C10.indd 364 30/09/14 7:21 AM
365ChaPter 10 SYSTEMS ANALYSIS
new computer system should help to make the processes more efficient. Two separate IFDs are often drawn:
1. System ‘as-is’ to identify inefficiencies in the existing system.
2. New proposed system to rectify these problems.
What is required is further work to identify the business processes and data needs for the proposed system and this is where the following tools come in.
Source: Simon Hickie, course notes
Figure 10.6 The completed IFD, including the system boundary
SICStudent Finance Student
and course details
Students by LEA
Department LEA
Invoices
Tutor
Class lists
Students’ union
Library
Student
Library card
NUS card
Enrolment form
Students on course
List of new students
List of new students
Systems boundary
Context diagrams
Simplified diagrams that are useful for specifying the boundaries and scope of the system. They can be readily produced after the information flow diagram since they are a simplified version of the IFD showing the external entities.
Context diagrams are simplified diagrams that are useful for specifying the boundaries and scope of the system. They can be readily produced after the information flow diagram since they are a simplified version of the IFD showing the external entities. They show these types of flow:
1. Flow crosses the system boundary from outside with its destination inside the boundary – it is thus an input to the system from the external environment.
2. Flow begins inside the system boundary and its destination lies outside – it is, therefore, an output from the system into its external environment.
The internal flows which lie entirely within the system boundary are not shown. Context diagrams provide a useful summary for embarking on dataflow diagrams and entity relationship diagrams, since they show the main entities. The main elements of a context diagram are:
■ a circle representing the system to be investigated; ■ ellipses (or boxes) representing external entities; ■ information flows.
Context diagrams
M10_BOCI6455_05_SE_C10.indd 365 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT366
Figure 10.7 shows a context diagram for the student loan system described in Case Study 10.1.
Figure 10.7 Context diagram for the student loan system described in Case Study 10.1
Student records system
Students’ unionLibrary LEA
Student Tutor
Invoices
Li st
o f n
ew
st ud
en ts
details
Student and course
C la
ss lis
ts
E nrolm
ent form
Library and NUS card C
la ss
li st
s
Dataflow diagrams (DFDs)
Define the different processes in a system and the information that forms the input and output of the processes. They may be drawn at different levels. Level 0 provides an overview of the system with levels 1 and 2 providing progressively more detail.
Dataflow diagrams (DFDs) define the different processes in a system and the information that forms the input and output to the processes. They provide a process focus to a system. They may be drawn at different levels: level 0 provides an overview of the system with levels 1 and 2 providing increasing detail.
Dataflow diagrams of different types are one of the mainstays of many systems analysis and design methodologies. SSADM, for example, makes extensive use of DFDs, not only to document things as they are at the moment but also to document the required system. Whether the latter is really of any value is debatable. How-ever, as a tool to document processes, data or information flows and the relationships between them for an existing system (computerised or paper-based), they are extremely valuable.
Dataflow diagrams build on IFDs by adding two new symbols as well as subtly redefining others.
The diagram conventions in Figure 10.8 are those that are in most common use in Europe. Differing methodologies adopt different symbols for some items (such as a circle for a process), as you will see in some of the supplementary texts for this chapter.
Explanations of symbols
■ Sources and sinks – an information source is one which provides data for a process and is outside the system boundary. A sink lies outside the system boundary and is a receiver of information. There is a clear distinction between the use of this symbol in the DFD
Dataflow diagrams
M10_BOCI6455_05_SE_C10.indd 366 30/09/14 7:21 AM
367ChaPter 10 SYSTEMS ANALYSIS
and in the IFD that we looked at before, in that the symbol should not appear inside the system boundary.
■ Processes – convert data into either usable information or data in a different form for use in another process. The data that enter a process can come either from a datastore (see below) or from an external source.
■ Datastores – a datastore can either provide data as input to a process or receive data that have been output from a process. The amount of time that data would spend in a datastore can vary from a very short time (e.g. fractions of seconds in the case of some work files) to much longer periods (e.g. months or years in the case of master files).
■ Dataflows – a dataflow describes the exchange of information and data between datastores and processes and between processes and sources or sinks. Note that in this context we are using ‘data’ in a broad sense (to include information) rather than in the narrow sense used earlier (in Part 1 of the book).
■ Systems boundary – remains the same as for an IFD. It indicates the boundary between what lies inside the system under consideration and what lies outside.
Drawing dataflow diagrams
It is unfortunate that many texts actually contain errors in the DFD examples used. This is mainly through having ‘illegal’ information flows. In a well-constructed diagram, you will note the following:
■ Data do not flow directly between processes – the data that enter a process will come either from a source or from a datastore, they cannot exist in a vacuum!
■ Data do not flow directly between datastores – there must be an intervening process that takes the input data and converts them into a new form and outputs them to either a datastore or a sink.
■ Data do not flow directly from a datastore to a sink, or from a source to a data-store – there must be an intervening process.
To draw a basic high-level DFD, there are five steps required:
1. Identify and list all processes which take place in the system under consideration. A process is an event where an input of some kind, from either a source or a datastore, is transformed into an output (the output being either to a sink or to a datastore).
Figure 10.8 Symbols used in data flow diagrams
An external source or sink
An information flow
A process
A datastore
The information system boundary
M10_BOCI6455_05_SE_C10.indd 367 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT368
2. Identify all the datastores which you think exist in the system under consideration. A datastore will exist wherever a set of facts needs to be stored about persons, places, things or events.
3. For each process identified in Step 1, identify where the information used in the process comes from (this can be from a source or a datastore or both) and identify the output(s) from that process (which can be an information flow to a sink or to a datastore or to both).
4. Draw a ‘mini-DFD’ for each single process, showing the process box and any relevant sources, sinks or datastores.
5. Link the mini-DFDs to form a single diagram, using the datastores to link the processes together.
To help you to construct a diagram, the following tips are useful:
■ use A4 paper in landscape orientation; ■ aim to have no more than about six or seven processes on a page (ten maximum); ■ include the same datastores, sources and sinks more than once if required (to eliminate
crossed lines or to make the flows clearer).
Before working through the student records example introduced in the previous section, it is necessary to introduce the concept of ‘levelling’ in DFDs. For anything other than a very small system with a handful of processes, it would be almost impossible to draw a single diagram with all the processes on it. It is necessary, therefore, to begin with a high-level diagram with just the broadest processes defined. Examples of high-level processes might be ‘process customer orders’, ‘pay suppliers’ or ‘manufacture products’. Needless to say, each of the processes described can be broken down further until all the fundamental processes which make up the system are identified. It is usual to allow up to three or four levels of increasing detail to be identified. If there are any more levels of detail than this, it suggests that the system is too large to consider in one development and that it should be split into smaller, discrete subsystems capable of separate development.
To illustrate the levelling concept and also to demonstrate how process boxes should be used, we will take the simple example of checking a customer order. At Level 1, the process box will appear as in Figure 10.9.
It is desirable to split this process up into smaller components. As an example, suppose the following are identified:
■ check customer credit limit – can the customer pay for the goods? ■ perform stock check – to see whether the desired goods are in stock; ■ create sales order – this may be a special order form that is needed for each order;
Figure 10.9 An example of a Level 1 process in a DFD
SALES1
Process customer
order
Process description
Place where process
performed Process number
M10_BOCI6455_05_SE_C10.indd 368 30/09/14 7:21 AM
369ChaPter 10 SYSTEMS ANALYSIS
■ send order to warehouse – the warehouse will need to pick the stock ready for delivery; ■ dispatch customer order; ■ invoice customer.
This will give us six new processes to record at the next level. The process box for the first Level 2 process would be similar to this (Figure 10.10).
Note that the process number is 1.1. This indicates that the process has been decomposed from the higher-level process numbered 1. Subsequent processes would be numbered 1.2, 1.3, 1.4, and so on. Also note that the process name begins with a verb. The choice of verb helps indicate more clearly the type of process that is being performed.
Suppose now that we still need to decompose the new process 1.1 further. For example, the credit check process may involve these steps:
■ calculate order value; ■ identify current balance; ■ produce credit check result.
We need to present the new processes as Level 3 processes, since they have been decomposed from the higher Level 2 process. The first of these would be represented as in Figure 10.11.
The new processes would be numbered 1.1.1, 1.1.2 and 1.1.3. This approach to numbering allows each of the low-level processes to be easily associated with the higher- level process that generated it. Thus, for example, processes 3.2.1, 3.2.2 and 3.2.3 could be tracked back to process 3.2, and thence to process 3.
We will now return to the student enrolment example. We will concentrate on producing a Level 1 diagram for this procedure, although it will be clear that the example is a somewhat simplified one.
The first task is to identify all the processes which exist. Looking back to Figure 10.6, we can identify the following:
1. allocate unique student code; 2. create student card index; 3. create LEA list;
Figure 10.10 An example of a Level 2 process in a DFD
SALES1.1
Check customer credit limit
Figure 10.11 An example of a Level 3 process in a DFD
SALES1.1.1
Calculate order value
M10_BOCI6455_05_SE_C10.indd 369 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT370
4. invoice LEA; 5. create student record card; 6. create class list; 7. issue enrolment form; 8. issue new students list.
Step 2 requires us to identify all the datastores which might exist. Our example reveals the following:
■ student card index; ■ LEA list; ■ student record card; ■ class list; ■ new students list.
Step 3 requires us to construct a ‘mini-DFD’ for each of the eight processes identified above. We will restrict ourselves to the first three (see Figures 10.12, 10.13 and 10.14).
You will see from these figures that each of the processes we have considered has generated an output which forms an input to the next process. In the full diagram in Figure 10.15 you will see the complete picture, including all processes, datastores, sources and sinks. In this diagram, you will notice that the datastore ‘card index file’ appears more than once. This does not mean that there are two separate datastores with the same name, but that we have included it for a second time to make the diagram easier to draw. If we did not do this, there would have been either crossed lines or at least very tortuous ones. A system boundary is also included and you will note that sources and sinks lie outside the system boundary, while processes and datastores are inside. Many of the dataflows are inside the boundary, but you see where flows also cross the system boundary.
The final point to note is that a dataflow diagram is time-independent. This means that we are not trying to show the sequence in which things happen, but rather to show all the things that happen.
Figure 10.12 Mini-DFD for process 1
SIC1
Allocate unique
student code
Updated forms1
Student details
Student
Student details
M10_BOCI6455_05_SE_C10.indd 370 30/09/14 7:21 AM
371ChaPter 10 SYSTEMS ANALYSIS
Figure 10.13 Mini-DFD for process 2
SIC2
Create student
card index
Card index file2
New student card
Student details
Updates forms1
Figure 10.14 Mini-DFD for process 3
SIC2
Create student
card index
LEA lists3
Student and LEA details
Student details
Card index file2
The benefits to an organisation of constructing a dataflow diagram can be summed up in the following ‘three Cs’:
■ Communication. A picture paints a thousand words and DFDs are no exception. A diagram can be used by an analyst to communicate to end-users the analyst’s understanding of the area under consideration. This is likely to be more successful than what Ed Yourdon describes as the ‘Victorian novel’ approach to writing specification reports.
■ Completeness. A DFD can be scrutinised by functional area personnel to check that the analyst has gained a complete picture of the business area being investigated. If anything is missing or the analyst has misinterpreted anything, this will be clearer to the user if there is a diagram than if purely textual tools are used.
M10_BOCI6455_05_SE_C10.indd 371 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT372
Figure 10.15 Completed DFD for the student record system
LEAInvoices
Tutor
Student and course details
Student details
SIC1
Allocate unique
student code
Updated forms1
Student details
Student
Students’ details
SIC2
Create student
card index
Card index file2
New student card
New SRC
Study record cards4
SIC5
Create study record
card
SIC3
Create LEA lists
Student and LEA details
Student and LEA details
Class list
Card index file2
LEA lists3
Student details
Finance4
Invoice LEAs
SIC8
Issue new student
lists
SIC7
Issue enrolment
form
Student details
Student details
Student
Students union
LibraryStudent names
Student names
Enrolment form
Department6
Create class lists
■ Consistency. A DFD will represent the results of the fact-finding exercise conducted by the analyst. For the DFD to be constructed at all, the analyst will need to compare the fact-finding results from all the areas investigated and look for linkages between them. If the same processes are portrayed differently by different people, then the DFD will be hard to construct. In such an event, this will be a catalyst for the analyst to return to the fact-finding task, perhaps using brainstorming to get to the real facts.
Entity relationship diagrams (ERDs)
Provide a data-focused view of the main data objects or entities within a system such as a person, place or object and the relationships between them. It is a high-level view and does not consider the detailed attributes or characteristics of an object such as a person’s name or address.
Entity relationship diagrams (ERDs) provide a data-focused view of the main data objects or entities within a system such as a person, place or object and the relationships between them. It is a high-level view and does not consider the detailed attributes or characteristics of an object such as a person’s name or address.
In dealing with entity relationship diagrams, we must bear in mind that we are beginning to move away from the analysis stage of the systems development lifecycle towards the design stage. This is because we are beginning to think about how data are represented and how different sets of data relate to each other. For this chapter, we will concentrate on the fundamentals of entity relationships as they exist within a particular business situation, rather than on the detail of database design which follows directly from using this tool. Database design will be covered in much more detail later (in Chapter 11) where a technique called data normalisation will also be covered.
In any business situation, data (whether paper-based or computerised) are processed to produce information to assist in the decision-making processes within that business area. Processes may change over time and new ones be created to provide new or different information, but very often the types of data that underpin this remain relatively unchanged.
Entity relationship diagrams (ERDs)
M10_BOCI6455_05_SE_C10.indd 372 30/09/14 7:21 AM
373ChaPter 10 SYSTEMS ANALYSIS
Sometimes, data requirements change to allow new processes to be created. For example, a supermarket that moves to an electronic system from a manual one will generate new data in the form of sales of specific products at specific times and in specific quantities. The data can then be linked to automated stock ordering systems and the like.
In order to produce good-quality information, two things are needed above all others. These are:
■ accurate data; ■ correct processing.
If data are inaccurate, correct processing will only result in the production of incorrect information. If data are accurate, but faults exist in the processing, the information will still be incorrect. However, in the second case, the capability exists for producing correct information if the processing is adjusted. With faulty data, it may not be so easy to rectify the situation.
In the analysis context, we need to engage in fact-finding activities that reveal the data that underlie all the relevant business processes, so that they can be captured and stored correctly and then processed to produce the required information. This process will reveal details of certain entities which exist within the business. One of the most useful methods that can be used here is the review of records and documentation (for example, order forms, stock control cards, customer files and so on).
An entity can be defined as facts about a person, place, thing or event about which we need to capture and store data. To take the example of a sales department, it would need to know facts about customers, orders, products and stock availability.
The essential symbols used in ERDs are very straightforward (Figure 10.16). Note that additional symbols are used in some notations, but they are not necessary for the detail of analysis conducted in this chapter.
There are a number of possible relationships between entities.
One-to-one relationships
For each occurrence of entity A there is one and only one occurrence of entity B. For example, let us assume that a lecturer may teach on only one module, and that
module may be taught by only one lecturer (an unlikely situation) (Figure 10.17).
Entity
An object such as a person, place, thing or event about which we need to capture and store data. An entity forms a data set about a particular object.
Figure 10.16 Essential symbols in an entity relationship diagram
Customer An ENTITY (name always in box)
A relationship between entities (one-to-many illustrated)
Figure 10.17 A one-to-one relationship
Lecturer Module Teaches
Is taught by
M10_BOCI6455_05_SE_C10.indd 373 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT374
In Figure 10.17, we have added some additional information. This shows the nature of the relationship between the two entities. This information on the relation-ship is added to the line between the two entities. The relationship can be described in two ways according to which entity we refer to first. The relationships are:
■ lecturer teaches module; ■ module is taught by lecturer.
The practice of describing the relationship on the line is recommended since it helps others interpret the ERD more readily. However, the nature of the relationship is omitted on some subsequent diagrams for the sake of clarity.
One-to-many relationships
For each occurrence of entity A, there may be zero, one or many occurrences of entity B. For example, a lecturer belongs to a single division, but that division may contain many lecturers (it may, of course, have no staff at all if it has only just been created or if all the staff decided to leave) (Figure 10.18).
Many-to-many relationships
For each occurrence of entity A, there may be zero, one or many occurrences of entity B, and for each occurrence of entity B there may be zero, one or many occurrences of entity A.
For example, a course module may be taken by zero, one or many students and a student may take zero, one or many course modules (Figure 10.19).
Unfortunately, especially in database design, many-to-many relationships can cause certain difficulties. Therefore, they are usually ‘resolved’ into two one-to-many relationships through the creation of a ‘linking’ entity. The decomposition is shown in Figure 10.20. The linking entity will contain an item of data from each of the other entities which allows the link to be made.
The following example shows a simple ERD which illustrates each of the above possibilities in more detail.
Suppose that a nation has a professional hockey league, comprising 16 clubs. Each club may only play in this one league. Each club may employ a number of professional players (although it is also possible for a team to consist completely of amateurs). Each professional player may only be contracted to one club at a time and may also experience periods of unemployment between contracts. Professional players are also eligible to play for their
Figure 10.18 A one-to-many relationship
Division Lecturer Contains
Belongs to
Figure 10.19 A many-to-many relationship
Module Student Is taken by
Takes
M10_BOCI6455_05_SE_C10.indd 374 30/09/14 7:21 AM
375ChaPter 10 SYSTEMS ANALYSIS
national team, but any one player may only ever play for one national team. Finally, suppose that professionals may have a number of sponsors and that each sponsor may sponsor a number of players.
If we inspect the previous paragraph, we can identify the following entities:
league; club; professional; national team; sponsor.
Our first-cut ERD is shown in Figure 10.21. The only obvious difficulty here is the many-to-many relationship between professional
player and sponsor. We can resolve this by introducing a linking entity which contains something common to both an individual player and their sponsor. This can be seen in the next ERD of Figure 10.22.
Figure 10.20 A many-to-many relationship decomposed into two one-to-many relationships
Module StudentStudent/ module
Figure 10.21 First ERD for the professional hockey example
League Club
National team SponsorProfessional
player
Figure 10.22 Final ERD for the professional hockey example
League Club
National team
Sponsorship agreement
Professional player
Sponsor
M10_BOCI6455_05_SE_C10.indd 375 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT376
We have introduced the linking entity I to resolve the many-to-many relationship. Thus, any one player may have many sponsorship agreements, but any one sponsor agreement will belong to one player and to one sponsor.
This example was pretty straightforward. Others will be less so and it is therefore time to go back to our student records example from earlier in the chapter. In fact, we have already started the process of thinking about entities because the earlier DFD section required us to think about datastores – somewhere we store data, in other words a possible entity! Faced with a more complex set of possible relationships, it is useful to adopt a more structured approach to constructing ERDs.
There are six steps that can be helpful in producing an ERD, especially when one lacks experience in drawing them:
1. Identify all those things about which it is necessary to store data, such as customers and orders.
2. For each entity, identify specific data that need to be stored. In the case of a customer, for example, name, address and telephone number are all necessary.
3. Construct a cross-reference matrix of all possible relationships between pairs of entities and identify where a relationship actually exists. To do this, it is very helpful to identify some item of data which is common to the pair of entities under consideration.
4. Draw a basic ERD showing all the possible relationships, but not yet the degree of the relationship.
5. On the basic ERD, inspect each relationship and amend it to show whether it is a one- to-one, one-to-many or many-to-many relationship.
6. Resolve any many-to-many relationships by introducing an appropriate linking entity.
Step 1: Identify the entities
By going back to the student record example and the DFD in Figure 10.15, it is possible to identify some possible candidate entities. The difficulty here is that the kind of documentation generated from the process obscures what we really need to hold data about. For example, there is a datastore called card index file. This is hardly helpful! What really needs to be done is to ask the question: ‘What things do we need to store data about?’ This may yield something rather different from the entities we thought we had before. As a starting point, we will begin with the following entities:
students; courses; LEAs; departments; modules.
Step 2: Identify specific data for each entity
Each entity will be taken in turn, and a number of data attributes suggested.
STUDENTS name; home address; sex; local education authority name; local education authority code; course code;
M10_BOCI6455_05_SE_C10.indd 376 30/09/14 7:21 AM
377ChaPter 10 SYSTEMS ANALYSIS
term-time address; date of birth; next of kin; modules taken.
COURSES course code; course description; department; course leader.
LEAs name.
LEA CODE address; contact name; telephone number; fax number.
DEPARTMENT department name; department location; office number; head of department.
MODULES module code; module leader; department; semester run; owning department.
Step 3: Construct cross-reference matrix
This part of the process helps novice analysts identify where relationships exist between entities. It is necessary to identify where there is a common data attribute between pairs of entities, so indicating that a probable relationship exists between them. This is the hardest part of the whole exercise. The essence is to ask the question: ‘For any occurrence of entity A, are there (now or likely to be in the future) any occurrences of B that relate to it?’ For example, is it likely that for a customer some orders exist that relate to it?
The cross-reference matrix in Figure 10.23 allows each pair of possible relationships to be examined for a link. In the cross-reference diagram, it is only necessary to identify each possible pair of relationships once. Also, there is no need to examine a relationship that an entity might have to itself. As a result, we are only interested in examining ten possible pairs of relationship for this small, five-entity example.
Steps 4 and 5: Construct first-cut ERD and add degree of relationship
Steps 4 and 5 will be combined, since there is nothing to be gained here from making separate diagrams. However, when drawing the diagram for Case Study 10.2, it would be wise to split the tasks as suggested.
The diagram in Figure 10.24 is almost correct, but there is still the question of the many- to-many relationship to resolve, so we must move to the final step.
M10_BOCI6455_05_SE_C10.indd 377 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT378
Step 6: Resolve any many-to-many relationships
The many-to-many relationship about which we should be concerned is the one between students and modules. A student may enrol for many modules and any modules may be taken by many students. However, what we need to represent is the ability of students to enrol for as many or as few modules as required without causing complications in either the student entity or the module entity. The many-to-many relationship is therefore resolved by introducing a linking entity which will have one occurrence for each module that one student takes and for the whole student population. So if there were 100 students each studying 8 modules, the new linking entity would contain 800 records. The final diagram is in Figure 10.25.
By working through the student record system example, we have moved from the process of identifying what the data requirements are for the system under consideration (the analysis part) and have made substantial progress on how a database might be constructed to hold the required data (which is a design task). This exercise is far from complete, however, as database design involves more than just looking at entity relationships. The detailed database design aspects will therefore be covered later (in Chapter 11) where all aspects of system design are considered.
Figure 10.23 Cross-reference matrix for student records system
YNYY
YYN
NN
N
Module
Student
Course
LEA
Department
M od
ul e
S tu
de nt
C ou
rs e
LE A
D ep
ar tm
en t
Figure 10.24 Student record system ERD – with many-to-many relationship
LEA
Department
StudentModule
Course
M10_BOCI6455_05_SE_C10.indd 378 30/09/14 7:21 AM
379ChaPter 10 SYSTEMS ANALYSIS
Figure 10.25 Final student record system ERD – with many-to-many relationships decomposed
LEAStudent
Department
Student/ModuleModule
Course/Module
Course
Soft systems methodology
A methodology that emphasises the human involvement in systems and models their behaviour as part of systems analysis in a way that is understandable by non-technical experts.
Human activity system
Human activity system are non-tangible systems where human beings are undertaking some activities that achieve some purpose’.
SOFT SYSTEMS METHODOLOGYFOCUS ON…
Soft systems methodology is a methodology that emphasises the human involvement in systems and models their behaviour as part of systems analysis in a way that is understandable by non-technical experts.
This methodology has its origins in Peter Checkland’s attempt to adapt systems theory into a methodology which can be applied to any particular problem situation (Checkland, 1999). From an information systems development perspective, it is argued that systems analysts often apply their tools and techniques to problems that are not well defined. In addition, it is also argued that since human beings form an integral part of the world of systems development, a systems development methodology must embrace all the people who have a part to play in the development process (users, IS/IT professionals, managers, etc.). Since these people may have conflicting objectives, perceptions and attitudes, we are essentially dealing with the problems caused by the unpredictability of human activity systems.
Human activity systems are non-tangible systems where human beings are undertaking some activities that achieve some purpose.
Proponents of soft systems methodology (SSM) claim, therefore, that true understanding of complex problem situations (and in our case this means information systems development) is more likely if ‘soft systems’ methods are used rather than formal ‘hard systems’ techniques. This is not to say that ‘hard’ methods do not have a place. Rather, it is to suggest that the more traditional tools and techniques will have a greater chance of being used effectively if they are placed within a soft systems perspective.
Soft systems methodology has seven stages. They should be regarded as a framework rather than a prescription of a series of steps that should be followed slavishly.
Stage 1: The problem situation: unstructured
This stage is concerned with finding out as much as possible about the problem situation from as many different affected people as possible. Many different views about the problem
M10_BOCI6455_05_SE_C10.indd 379 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT380
will surface and it is important to bring out as many of them as possible. The structure of the problem in terms of physical layout, reporting structure, and formal and informal communication channels will also be explored.
A soft systems investigator will often find that there is a vagueness about the problem situation being investigated and what needs to be done. There can also be a lack of structure to the problem and the situation that surrounds it.
Stage 2: The problem situation: expressed
The previous stage was concerned with gathering an informal picture of the problem situation. This stage documents these findings. While there is no prescribed method for doing this, a technique that is commonly used is the drawing of ‘rich pictures’. A rich picture can show the processes involved in the problem under consideration and how they relate to each other. The elements which can be included are the clients of the system (internal and external), the tasks being performed, the environment within which the system operates, the owners of the ‘problem’ and areas of conflict that are known to exist.
Rich pictures can act as an aid to discussion, between problem owner and problem solver or between analysts and users, or both. From a rich picture it then becomes possible to extract problem themes, which in turn provide a basis for further understanding of the problem situation. An example of a rich picture is shown in Figure 10.26. Such a diagram can be used in systems analysis to indicate the flows of information, the needs of staff and how the physical environment – in this case the office layout – affects the current way of working. This summary of the existing situation provides a valuable context for systems analysis and design.
Stage 3: Root definitions of relevant systems
Checkland (1999) describes a root definition as a ‘concise, tightly constructed description of a human activity system which states what the system is’.
A root definition is created using the CATWOE checklist technique. CATWOE is an acronym that contains the following elements:
■ Clients or customers – the person(s) who benefit, or are affected by or suffer from the outputs of the system and its activities that are under consideration.
■ Actors – those who carry out the activities within the system. ■ Transformation – the changes that take place either within or because of the system (this
lies at the heart of the root definition). ■ Weltanschauung or Worldview – this refers to how the system is viewed from an explicit
viewpoint; sometimes this term is described as assumptions made about the system. ■ Owner – the person(s) to whom the system is answerable: the sponsor, controller or
someone who could cause the system to cease. ■ Environment – that which surrounds and influences the operation of the system but
which has no control over it.
The main use of the root definition is to clarify the situation so that it can be summed up in a clear, concise statement. An example of a root definition for a university might be:
To provide students with the maximum opportunity for self-development, while at the same time safeguarding academic standards and allowing the university to operate within its budgetary constraints.
An alternative root definition might be:
A system to maximise revenue and the prestige of academic staff!
If there are many different viewpoints to be represented, it is possible that a number of different root definitions may be constructed. These in turn will provide a basis for further discussion, so that a single agreed root definition can be produced. A single root definition that is hard to produce is indicative of sharp divisions between the CATWOE elements. From
M10_BOCI6455_05_SE_C10.indd 380 30/09/14 7:21 AM
381ChaPter 10 SYSTEMS ANALYSIS
an information systems development perspective, if it is not possible to agree on a single root definition, then the systems development process is likely to be fraught with difficulties.
Stage 4: Building conceptual models
A conceptual model is a logical model of the key activities and processes that must be carried out in order to satisfy the root definition produced in Stage 3. It is, therefore, a representation of what must be done rather than what is currently done.
Conceptual models can be shown on a simple diagram where activities and the links between them can be shown. Figure 10.27 shows a simple conceptual model of a student records system.
Where several alternative root definitions have been produced, it is usual to draw a conceptual model for each one. Successive iterations through the alternative models can then lead to an agreed root definition and conceptual model. When this has happened, it is possible to move on to the next stage.
Figure 10.26 An example of a rich picture for an estate agency showing the needs and responsibilities of different staff
BACK OFFICE
FRONT OFFICE
MANAGER
Big picture – branch profitability
Are targets achieved? What are our conversion rates?
NEGOTIATOR
Customer details
Busy – info at fingertips. Spends all time on phone
Sales = commission
WINDOW DISPLAY
FINANCIAL ADVISER
Sells insurance and mortgages. Needs customer
and property details
BRANCH ADMINISTRATOR
Printer
Customer
Quick sale
Property details
M10_BOCI6455_05_SE_C10.indd 381 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT382
Stage 5: Comparing conceptual models with reality
Different alternative conceptual models that represent what should happen can be compared with the reality of what actually happens, as represented by the rich picture produced in Stage 2.
The purpose of this step is not to alter the conceptual models so that they fit more closely with what happens in reality. Instead, it is to enable the participants in the problem situation to gain an insight into the situation and the possible ways in which the change to reality can take place.
Stage 6: Assessing feasible and desirable changes
From the output of Stage 5, an analysis of the proposed changes can be made and proposals for change drawn up for those that are considered feasible and desirable. Such changes may relate to information systems, but there is no restriction on the type or scope of the change.
Stage 7: Action to improve the problem situation
It is perhaps here that the application of the model is most evident. SSM does not describe methods for implementing solutions – that lies outside the scope of the methodology. What it does do is to provide a framework through which problem situations can be understood. In fact, there is no reason that SSM should not be used as a tool for assisting the implementation of the required solution – the steps can be repeated, but this time the problem situation under consideration is the implementation of the required solution. This in turn may throw up alternative methods such as SSADM or rapid applications development (in Chapter 7) as the best approach to information systems development. Indeed, SSM has often been used as a ‘front end’ to more traditional structured development methodologies.
Figure 10.27 Conceptual models – a simple example
Update module details
Module leader Student
Local education authority
Student
Module leader
Create class list
Create student record
Enrol student
Create enrolment
form
Create LEA
invoice
M10_BOCI6455_05_SE_C10.indd 382 30/09/14 7:21 AM
383ChaPter 10 SYSTEMS ANALYSIS
Any systems development project will be confronted by issues such as system size, complexity and acquisition method. These factors affect the choice of fact-finding and documentation tools. It is appropriate, therefore, to consider three alternative acquisition methods and review fact-finding and documentation needs for each.
SYSTEMS ANALYSIS – AN EVALUATION
Bespoke software, which can be developed either internally or by a third party, presents the greatest scope for using the full range of analysis tools. Complex systems will require that the analyst gain a very clear and precise understanding of the business processes that take place, and all the tools at the analyst’s disposal may need to be used. A combination of interviewing, documentation review and observation will yield much of the information that is needed, but if the system is a large one with many users, questionnaires may also need to be used. Brainstorming will be valuable, especially when linkages between different processes and subsystems are being investigated.
Complex projects will also require the use of all of the documentation tools we have discussed. Needless to say, the resulting diagrams will be more detailed and extensive than the ones given as examples in this chapter.
Bespoke development
Even though there is no requirement to produce something from which the system designer can produce a blueprint for the build stage, it is still necessary to gain a clear understanding of user requirements before a package is considered. Therefore, the fact-finding process will still be undertaken, but will be geared towards gaining an understanding of the features a package must support and those that are only desirable.
One benefit of deciding to purchase a package is that a number of candidate packages can be initially selected and used by the analyst as a means of identifying real user needs. It is possible, for example, for a selected group of users to review the features of a small number of packages with a view to compiling an appropriate requirements catalogue. Also, when users actually have an opportunity to experiment with a package, the analyst can gain a much greater insight into what the users’ real requirements are.
For the analyst, it may still be useful to construct information flow and dataflow diagrams to help ensure that the package that is finally selected will support the required linkages, both between processes in the business area under consideration and to other business areas (from sales to accounts, for example). It will also be useful for the analyst to construct an entity relationship diagram to be sure that the packaged software will support the data requirements of the organisation.
Purchasing packages off-the-shelf
The situation here is somewhat different from the previous two acquisition methods. The end-user will have a clear idea of what the system is required to do. Also, it is less likely that the system will need to have linkages to other applications. The emphasis for the user, therefore, should be on identifying the data and processing requirements clearly so that they can be reviewed by others in the organisation, and an application can be produced which
User applications development
M10_BOCI6455_05_SE_C10.indd 383 30/09/14 7:21 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT384
Software tools are available to assist in the analysis phase. These usually focus on the diagramming rather than the enquiry stage, so much of the skill remains with the analyst in interpreting the users’ requirements before producing meaningful diagrams showing the information flows and processes.
An important issue in using software tools to help the analyst is the degree to which the diagrams used to summarise processes can be converted easily into the system design and then into the final system. Traditionally, there have been separate tools for the analyst, designer and programmer. Since there is a strong overlap with the design phase, we will defer the examination of these tools until later (see Chapter 11, which has a section on computer-aided software engineering or CASE tools). Integrated CASE tools are intended to bridge the gap between analysis, design and programming.
SOFTWARE TOOLS FOR SYSTEMS ANALYSIS
Background The following scenario is typical of many companies in the retail/wholesale business. A number of information flows exist both internally within the organisation and also with people outside. This case study is used for exercises on in-formation flow diagrams (IFDs), dataflow diagrams (DFDs) and entity relationship diagrams (ERDs).
The exercise continues in Chapter 11 when the reader is asked to produce a detailed database design based on the entity relationship diagram produced and the paper form examples.
ABC case study information Andy’s Bonsai Company (ABC) specialises in selling bonsai kits by mail order. The kits are made up of a number of ele- ments, including soil, plant pots and seeds. Other products such as mini-garden tools are also sold.
Customers place orders by telephone or by mailing an order slip which is printed as part of an ABC advert. Customers pay by cheque, credit card or debit card.
When an order is received by ABC, it is directed to a sales clerk. Each sales clerk has responsibility for a particular geographic region. The sales clerk will enter the details of the order onto a preprinted three-part order form. One part is retained by the sales clerk, one copy together with the payment is sent to the accounts department and the other is sent to the warehouse (on confirmation of the customer’s creditworthiness).
On receipt of the customer orders and payment details, the accounts department ensures that the customer’s payment is valid. If the payment is satisfactory, the department will inform the sales department and the order may proceed. An unsatisfactory payment situation is also communicated to the sales department, which then informs the customer of the problem.
ABC case study
CASE STUDY 10.2
delivers good-quality information. Of the techniques discussed, the most relevant is the entity relationship diagram. By concentrating on data and how they are to be captured and represented, the user increases the probability that the data will be correct, while the use of fourth-generation language tools will help maximise the probability that the processing will also be correct.
Many user-developed applications suffer from poor database design and, as a consequence, the processing requirements are much more complex and prone to error. By taking care to consider carefully the relationships between the relevant data items, the probability of obtaining successful user-developed applications is increased.
M10_BOCI6455_05_SE_C10.indd 384 30/09/14 7:21 AM
385ChaPter 10 SYSTEMS ANALYSIS
dispatched. The warehouse also needs to keep track of the amount of product in stock and, when stock levels are low, it sends a manufacturing order to the manufacturing department.
The warehouse keeps a manual card-index system of stock and raw materials held together with copies of the customer orders. When an order is dispatched to the customer, the relevant order form is marked as having been
CUSTOMER ORDER FORM CUSTOMER NO.: C234792 CUSTOMER ADDRESS: 26 Vicarage Drive Thorndyke West Yorkshire WF24 7PL CODE DESCRIPTION: 1983 MINI-OAk 0184 MINI-MAPLE 2984 MINI gARDEN TOOLS (STAINLESS) 3775 MINI WATERINg CAN (COPPER) PAYMENT TYPE
PRICE: 19.95 24.50 29.95 17.50 Cheque
QTY: 2 2 1 1 ORDER VALUE
ORDER NO.: 4214 DATE ORDERED: 29 March 1999
TELEPHONE NO.: 01482 7374
VALUE: 39.90 49.00 29.95 17.50 136.35
WAREHOUSE CARD INDEx
LOCATION PRODUCT CODE PRODUCT DESCRIPTION START TRANSACTION QTY QTY: 37 25 28 23 25 215 10 150 60
J82 4151 MINI-ASH DATE
2/6/99 4/6/99 9/6/99 17/6/99
CARD NO.: 19
SIgNATURE
RON JEFF LUCY ERIC
MANUFACTURING ORDER FORM
MANUFACTURINg ORDER NO. PRODUCT CODE PRODUCT DESCRIPTION QUANTITY ORDERED DATE ORDERED DATE REQUIRED DATE DELIVERED SIgNATURE
7210 4151 MINI-ASH 50 3/6/99 13/6/99 17/6/99 BERYL
PURCHASE ORDER FORM
SUPPLIER NO.: S165 SUPPLIER ADDRESS: 14 Wyke Trading Estate Heckwhistle West Yorkshire WF9 5JJ
PURCHASE ORDER NO. 214 DATE ORDERED 29 March 1999
TELEPHONE NO. 01637 7346
CODE 23 69 84 75
DESCRIPTION OAk CHIPPINgS 2’ POTS SILVER SAND MINI WATERINg CAN (STAINLESS)
QTY 30.00 0.03 1.77 4.56 ORDER VALUE
VALUE 25 1000 10 20
PRICE 750.00 300.00 17.70 91.20 1158.90
➨
M10_BOCI6455_05_SE_C10.indd 385 30/09/14 7:21 AM
386 Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT
The manufacturing department is responsible for ordering materials from various suppliers and then packaging them into products for sale to the customer. A three-part purchase order is made out: one part is sent to the supplier, one part is retained by the manufacturing department and the third part is sent to the accounts department. The accounts department holds copies of purchase orders for future matching with delivery notes and invoices. When the supplier delivers the ordered items, together with a delivery note, a check is made to ensure that the delivery matches the order. The supplier will send an invoice to the accounts department on confirmation that the delivery is correct so that payment can be made.
QUESTIONS
1. Using the ABC case study, produce an information flow diagram for the company by following the steps given earlier in the chapter. Does the diagram
tell you anything about ABC’s operations which may need some attention (such as missing or superfluous information flows)?
2. Using the ABC case study and the information flow diagram that you drew in answer to Question 1, produce a simple Level 1 dataflow diagram for the company by following the steps given earlier in the chapter. Compare your answer with that by one of your colleagues. Are the diagrams the same? If not, is it possible to say which is correct? If not, why not?
3. Using the ABC case study, including the sample forms included below the main text, construct an entity relationship diagram for the company. Make sure that you do a cross-reference matrix before attempting to draw the diagram. When you have drawn your first-cut diagram, check for many-to- many relationships and eliminate any that you find by using the appropriate technique described earlier in the chapter.
Stage summary: systems analysis Purpose: Define the features and other requirements of the information system Key activities: Requirements capture (interviews, questionnaires, etc.) diagramming Inputs: User’s opinions, system documentation, observation Outputs: Requirements specification
1. The analysis phase of systems development is aimed at identifying what the new system will do.
2. Analysis will identify the business processes which will be assisted by the software, the functions of the software and the data requirements.
3. The results of the analysis phase are summarised as a requirements specification which forms the input to the design phase, which will define how the system will operate.
4. Fact-finding techniques used at the analysis stage include:
■ questionnaires; ■ interviews; ■ observation; ■ documentation review; ■ brainstorming.
5. The results from the fact-finding exercise are summarised in a requirements specification and using different diagrams such as:
■ information flow diagrams which provide a simple view of the way information is moved around an organisation;
■ dataflow diagrams which show the processes performed by a system and their data inputs and outputs;
■ entity relationship diagrams which summarise the main objects about which data need to be stored and the relationship between them.
6. The depth of analysis will be dependent on the existing knowledge of requirements. A user development may have limited analysis since the user will have a good understanding of their needs. A software house will need to conduct a detailed analysis which will form the basis for a contract with the company for which it is developing software.
SUMMARY
M10_BOCI6455_05_SE_C10.indd 386 30/09/14 7:21 AM
387ChaPter 10 SYSTEMS ANALYSIS
1. What is the difference between the ‘funnel’ and ‘pyramid’ approaches to structuring an interview?
2. Why can closed questions still be useful in an interview?
3. Assess the relative effectiveness of interviews versus questionnaires when attempting to establish user requirements.
4. In an information flow diagram, why should we not record information flows that lie completely outside the system boundary?
5. What are the main differences between an information flow diagram and a dataflow diagram?
6. What is meant by the term ‘levelling’ in dataflow diagrams?
7. In a sales order processing system, which of the following are not entities? Customer, colour, size, product, telephone number, sales order, salesperson, order date.
8. Why might the construction of an ERD still be useful even if an off-the-shelf package was going to be purchased?
ExERCISES
Self-assessment exercises
Discussion questions
1. Use a simple example with no more than five processes or ten information flows to examine the differences between the information flow diagram and the dataflow diagram. Which would be more effective for explaining deficiencies with an existing system to:
(a) a business manager; (b) a systems designer?
Justify your reasoning.
2. Compare the effectiveness of ‘soft’ methods of acquiring information such as interviews and questionnaires and ‘hard’ methods of gathering information such as document analysis and observation of staff. In which order do you think these analysis activities should be conducted and on which do you think most time should be spent?
3. ‘For producing a database, the only type of diagram from the analysis phase that needs to be produced is the entity relationship diagram. Dataflow diagrams are not relevant.’ Discuss.
Essay questions
1. Compare and contrast alternative fact-finding methods and analysis documentation tools as they might relate to bespoke software development and the purchase of off-the-shelf packages.
2. Errors in the analysis stage of a systems development project are far more costly to fix than those that occur later in the systems development lifecycle. Why do some organisations seem to devalue the analysis process by seeking to get to the system build as quickly as possible?
3. Compare and contrast the relative effectiveness of the use of information flow diagrams, dataflow diagrams and entity relationship diagrams by a business analyst to demonstrate inefficiency in a company’s existing information management processes. Use examples to illustrate your answer.
M10_BOCI6455_05_SE_C10.indd 387 30/09/14 7:21 AM
388 Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT
Examination questions
1. Briefly review the arguments for and against using interviewing as a means of determining system requirements.
2. Explain the relationship between the initiation and analysis phases of the systems development lifecycle.
3. Briefly explain (in one or two sentences) the purpose of each of the following diagramming methods:
(a) information flow diagram; (b) context diagram; (c) dataflow diagram; (d) entity relationship diagram.
4. Draw a diagram showing each of the following relationships on an ERD:
(a) The customer places many orders. Each order is received from one customer. (b) The customer order may contain many requests for products. Each product will feature
on many customer orders. (c) Each customer has a single customer representative who is responsible for them. Each
customer representative is responsible for many customers.
5. The final examination question is based on a detailed case study for Megatoys and is to be found on the companion web site.
Browne, g.J. and Rogich, M.B. (2001) ‘An empirical investigation of user requirements elicitation: comparing the effectiveness of prompting techniques’, Journal of Management Information Systems, 17, 4, 223–49
Buzan, T. and Buzan, B. (2010) The Mind Map Book, BBC Active, London
Checkland, P.B. (1999) Systems Thinking, Systems Practice, John Wiley, Chichester
Lindstrom, L. and Jeffries, R. (2004) ‘Extreme programming and agile software development methodologies’, Information Systems Management, 21, 3, 41–52
Shi, Y., Specht, P. and Stolen, J. (1996) ‘A consensus ranking of information systems requirements’, Information Management and Computer Security, 4, 1, 10–18
Taylor, D. (1995) Business Engineering with Object Technology, John Wiley, New York
Yeates, T. and Wakefield, T. (2004) Systems Analysis and Design, 2nd edition, Financial Times Prentice Hall, Harlow
References
Further reading
Ambler, S. and Lines, M. (2012) Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise, IBM Press.
Avison, D.E. and Fitzgerald, g. (2006) Information Systems Development: Methodologies, Techniques and Tools, 4th edition, Blackwell, Oxford.
M10_BOCI6455_05_SE_C10.indd 388 30/09/14 7:21 AM
389ChaPter 10 SYSTEMS ANALYSIS
Web links
www.cio.com CIO.com for chief information officers and IS staff has many articles related to analysis and design topics.
www.computerweekly.com Computer Weekly is an IS professional trade paper with UK/ Europe focus which has many case studies on practical problems of analysis, design and implementation.
www.research.ibm.com/journal IBM Systems Journal and the Journal of Research and Development have many cases and articles on analysis and design related to e-business concepts such as knowledge management and security.
kendall, k.E. and kendall, J.E. (2013) Systems Analysis and Design, 9th edition, Prentice-Hall, Englewood Cliffs, NJ.
Lejk, M. and Deeks, D. (2004) An Introduction to Systems Analysis Techniques and UML Distilled: A Brief Guide to the Standard Object Modelling Language, 2nd edition, Prentice Hall, Hemel Hempstead.
M10_BOCI6455_05_SE_C10.indd 389 30/09/14 7:21 AM
