MIS (Management Information System) Sharif University of Technology Session # 6

Session schedule Contents Systems Analysis and Design Planning the approach Asking questions and collecting data Recording the information Interpreting the information collected Specifying the requirement Sharif University of Technology MIS (Management Information System), Session # 6 2

Information system development System Analysis Five areas of a system analyst tasks: Investigation Communication with customers Documentation Understanding Preparation & planning Sharif University of Technology MIS (Management Information System), Session # 6 3

Information system development System Analysis System analysis process: The PARIS Model Analysis can be considered to be a Five-stage process Planning the approach Asking questions and collecting data Recording the information Interpreting the information collected Specifying the requirement We have divided the process of analysis into five stages, each of which will be described in detail in subsequent chapters. The first letters of each step form the five-letter word PARIS, which is a useful mnemonic to help you remember the steps. The five steps are: 1 Planning the approach This is the vital first stage in the PARIS model, and the success of the systems analysis phase of a project will depend on the thoroughness and care with which planning is carried out. During planning, objectives are set, constraints identified, terms of reference agreed, and preparations made for fact finding. Planning is described in Chapter 7, which also includes a section on the feasibility study. 2 Asking questions and collecting data This includes all the fact-finding activities carried out as part of the analysis. The key technique here is interviewing, which applies many of the principles introduced in Chapter 3 on communication. Interviewing is described in detail in Chapter 8 under three headings – planning, conducting, and recording the interview – and there is also a section on difficult interviews. Other fact-finding methods described in Chapter 8 include observation, designing and sending out questionnaires, document analysis and record searching. 3 Recording the information The third stage in the model is about recording information. The fact-finding methods, used during stage 2, yield many facts and details about the current and required systems. This information must then be recorded in a clear and unambiguous way. In structured systems analysis, a series of diagrams – or models – are drawn to represent the system, and these can be interpreted and built on by the analysis team, and may also be reviewed by the user to check that the information gathered by the analyst is complete and correct. Chapter 9 introduces two important models that are used to document the current system: the data flow diagram and the data model. Both are part of all structured methods, but we shall be concentrating on the way they are implemented in SSADM to explain how they are constructed and interpreted. 4 Interpreting the information collected Having documented the current physical system, we need to understand the underlying logical system, and then consider how the client’s requirements can be built in. Again, diagrams can be used to help analysts through this stage of the PARIS model, and Chapter 11 describes some techniques that can be used. 5 Specifying the requirement The final stage in the model, specifying the requirement, is described in detail in Chapter 12. This involves the analyst in preparing a number of options, based on the models constructed earlier, for the development of the new system. These options are discussed with the client, costed, and then presented in a way that emphasises the benefits they will bring to the client’s business. The analyst, during this stage, will usually be involved in writing a report, and in preparing and delivering a presentation. Once a decision has been made by the client on the way forward, a detailed functional specification will be prepared so that the designers will know exactly what the system has to do to meet the requirements.s Sharif University of Technology MIS (Management Information System), Session # 6 4

Information system development System Analysis Asking Questions and Collecting Data In order to collect this data and related information, a range of fact-finding methods can be used Interviewing, Questionnaires, Observation , Searching records and document analysis In order to collect this data and related information, a range of fact-finding methods can be used. Those most commonly used include interviewing, questionnaires, observation, searching records and document analysis. Each of these methods is described in this chapter, but it is important to remember that they are not mutually exclusive. More than one method may be used during a factfinding session: for example, during a fact-finding interview a questionnaire may be completed, records inspected and documents analysed. Sharif University of Technology MIS (Management Information System), Session # 6 5

Information system development System Analysis Recording the information Typically, the analyst collects a considerable amount of information during the investigation phase, which may include Interview reports, Observation records, Sample documents, Completed questionnaires and Lists of problems and requirements. Having looked earlier at planning and at the process of asking questions and collecting data, we now look at the third stage of the PARIS model of systems analysis – Recording the information. Typically, the analyst collects a considerable amount of information during the investigation phase, which may include interview reports, observation records, sample documents, completed questionnaires and lists of problems and requirements. Some of this relates to the current system, and some to the new system required by the client. It is important for the systems analyst to record this information in an unambiguous, concise manner that will be clear and accessible to others, and which can be used by other analysts and designers involved in developing the new system. Structured techniques were developed to help system developers to record information in this way, using diagrams and a limited amount of text, and in this chapter we introduce some of the key techniques. Sharif University of Technology MIS (Management Information System), Session # 6 6

Information system development System Analysis Recording the information Structured analysis and design views information systems principally in two ways: Data – the information that the system records Processing – what the system does with this data. As we saw in Chapter 2, structured analysis and design views information systems principally in two ways: first as data – the information that the system records – and second as processing – what the system does with this data. The most common techniques used for describing these two aspects of systems are data flow diagrams for processing, and entity models – also described as logical data structures or entity relationship diagrams – for data. Neither of these techniques, however, describes the precise order in which the system processes data. A third major view of the system, which describes the order in which external and internal events affect the system and the data, and brings together a view of the processing to complete the description of the system Sharif University of Technology MIS (Management Information System), Session # 6 7

Information system development System Analysis Recording the information The techniques of Data flow diagramming and Entity modeling, with a data dictionary, are used to record information about the current system. A requirements catalogue is used to record new requirements. This chapter introduces the techniques of data flow diagramming and entity modelling, describes how they are used, together with a data dictionary, to record information about the current system, and explains how a requirements catalogue is used to record new requirements. These activities are closely related, and are conducted in parallel during the early stages of requirements analysis. Before introducing these recording techniques we shall briefly describe data dictionaries and CASE tools, which help the analyst to create and edit diagrams, and to store data in a structured and meaningful way. Without data dictionaries and CASE tools the large-scale application of structured methods would be difficult, if not impossible, to achieve. Sharif University of Technology MIS (Management Information System), Session # 6 8

Information system development System Analysis Recording the information Data Dictionaries and CASE Tools A data dictionary is used to record all those pieces of information about a system (textual or numeric) that cannot be recorded on diagrams. In SSADM, the importance of the data dictionary is recognized in the concepts of Data flow models (DFMs) and Logical data models (LDMs), in which diagrams and their associated background documentation are considered as a whole. An essential concept underlying the use of structured methods is that of the data dictionary. A data dictionary is used to record all those pieces of information about a system (textual or numeric) that cannot be recorded on diagrams. It is the underlying structure that links the different views of the system presented by different types of diagram. In SSADM, for example, the importance of the data dictionary is recognised in the concepts of data flow models (DFMs) and logical data models (LDMs), in which diagrams and their associated background documentation are considered as a whole. In effect it is a database that supports analysts and designers in their tasks of analysing, modelling and designing computer systems. It is possible to use a paper-based data dictionary, but purpose-designed dictionaries based on commercial database management systems (DBMS) are now generally used. This is because they show the relationships between all the different components of the system’s models and designs that are constructed in a project using structured methods. This enables the impact of changes in one part of a model to be traced through to other components, making it much easier to keep the models consistent and accurate. CASE stands for Computer Aided Systems Engineering Sharif University of Technology MIS (Management Information System), Session # 6 9

Information system development System Analysis Recording the information Data Dictionaries and CASE Tools CASE stands for Computer Aided Systems Engineering, and is a term used to describe any software tool designed to make the development of computer systems easier. A data dictionary system can therefore be considered a CASE tool, although the data dictionary concept predates that of CASE. The term is also used to describe drawing tools specifically designed for the production of the types of diagram used in structured methods. CASE tools also incorporate drawing tools and a data dictionary, making it possible to check sets of diagrams for consistency and to see the results of changes. CASE stands for Computer Aided Systems Engineering, and is a term used to describe any software tool designed to make the development of computer systems easier. A data dictionary system can therefore be considered a CASE tool, although the data dictionary concept predates that of CASE. The term is also used to describe drawing tools specifically designed for the production of the types of diagram used in structured methods. These tools make it much easier and quicker to create and change diagrams than using paper and pencil, or even general-purpose computer-based drawing tools. They also produce more professional and readable results than manual methods. CASE tools also incorporate drawing tools and a data dictionary, making it possible to check sets of diagrams for consistency and to see the results of changes. These tools can be used to generate components of the eventual physical system, such as the database design, from the system models produced during analysis, and can partially automate many trivial analysis and design tasks. Sharif University of Technology MIS (Management Information System), Session # 6 10

Information system development System Analysis Recording the information Data Flow Diagrams Data flow diagrams are the most commonly used way of documenting the processing of current and required systems. They are a pictorial way of showing the flow of data into, around and out of a system. A complete set of DFDs provides a compact top-down representation of a system, which makes it easier for users and analysts to envisage the system as a whole. Data flow diagrams are the most commonly used way of documenting the processing of current and required systems. As their name suggests, they are a pictorial way of showing the flow of data into, around and out of a system. They can be understood by users, and are less prone to misinterpretation than textual description. A complete set of DFDs provides a compact top-down representation of a system, which makes it easier for users and analysts to envisage the system as a whole. Sharif University of Technology MIS (Management Information System), Session # 6 11

Information system development System Analysis Recording the information Data Flow Diagrams- DFD components DFDs are constructed using four major components: External entities, Data stores, Processes and Data flows. DFD Components DFDs are constructed using four major components: external entities, data stores, processes and data flows. Figure 9.1 shows how a DFD would be constructed using SSADM conventions, in which a process is represented by a rectangle, a data store by an open rectangle, a data flow by an arrow and an external entity by an ellipse. • External entities represent the sources of data that enter the system or the recipients of data that leave the system. Examples are clerks who enter data into the system or customers who receive letters produced by the system. In SSADM they are shown as ellipses with a name and a unique identifier consisting of a single lower-case letter. • Data stores represent stores of data within the system. Examples are computer files or databases or, in a manual system, paper files held in filing cabinets. They are drawn as open-ended rectangles with a unique identifier, a box at the closed end and the name of the store in the open section. Manual data stores Sharif University of Technology MIS (Management Information System), Session # 6 12

Information system development System Analysis Recording the information Data Flow Diagrams- DFD components DFDs are constructed using four major components: External entities, represent the sources of data that enter the system or the recipients of data that leave the system. Examples are clerks who enter data into the system or customers who receive letters produced by the system. DFD Components DFDs are constructed using four major components: external entities, data stores, processes and data flows. Figure 9.1 shows how a DFD would be constructed using SSADM conventions, in which a process is represented by a rectangle, a data store by an open rectangle, a data flow by an arrow and an external entity by an ellipse. • External entities represent the sources of data that enter the system or the recipients of data that leave the system. Examples are clerks who enter data into the system or customers who receive letters produced by the system. In SSADM they are shown as ellipses with a name and a unique identifier consisting of a single lower-case letter. • Data stores represent stores of data within the system. Examples are computer files or databases or, in a manual system, paper files held in filing cabinets. They are drawn as open-ended rectangles with a unique identifier, a box at the closed end and the name of the store in the open section. Manual data stores Sharif University of Technology MIS (Management Information System), Session # 6 13

Information system development System Analysis Recording the information Data Flow Diagrams- DFD components DFDs are constructed using four major components: Data stores, represent stores of data within the system. Examples are computer files or databases or, in a manual system, paper files held in filing cabinets. Manual data stores are identified by the letter M followed by a number, and identifiers for computerized stores are prefixed by a D. DFD Components DFDs are constructed using four major components: external entities, data stores, processes and data flows. Figure 9.1 shows how a DFD would be constructed using SSADM conventions, in which a process is represented by a rectangle, a data store by an open rectangle, a data flow by an arrow and an external entity by an ellipse. • External entities represent the sources of data that enter the system or the recipients of data that leave the system. Examples are clerks who enter data into the system or customers who receive letters produced by the system. In SSADM they are shown as ellipses with a name and a unique identifier consisting of a single lower-case letter. • Data stores represent stores of data within the system. Examples are computer files or databases or, in a manual system, paper files held in filing cabinets. They are drawn as open-ended rectangles with a unique identifier, a box at the closed end and the name of the store in the open section. Manual data stores Sharif University of Technology MIS (Management Information System), Session # 6 14

Information system development System Analysis Recording the information Data Flow Diagrams- DFD components DFDs are constructed using four major components: Processes, represent activities in which data is manipulated by being stored or retrieved or transformed in some way. Some practitioners insist on the use of verb-fronting phrases for process descriptions to ensure that the process is an action performed by the business. are identified by the letter M followed by a number, and identifiers for computerised stores are prefixed by a D. Data stores cannot be directly linked by data flows either to each other or to external entities without an intervening process to transform the data. • Processes represent activities in which data is manipulated by being stored or retrieved or transformed in some way. They are shown as larger rectangles with a numeric identifier in a box at the top left corner. The location where the process takes place or the job role performing it is recorded in a box in the top right corner and is used only in diagrams of the current physical system. The name of the process is recorded in the remaining area at the bottom. Process names should be unambiguous, and should convey as much meaning as possible without being too long. In general, names should take the form of an imperative and its object, as in Open Account. Generalised verbs such as Process or Update are not usually helpful. Some practitioners insist on the use of verb-fronting phrases for process descriptions to ensure that the process is an action performed by the business. • Data flows represent the movement of data between other components, for example a report produced by a process and sent to an external entity. They are shown as named arrows connecting the other components of the diagram. Data flows are generally shown as one-way only. Data flows between external entities are shown as dotted lines. It may be necessary to draw the same external entity or data store more than once on the same DFD in order to make the diagram clear and to avoid too many crossing lines. An external entity that appears more than once in the same diagram is shown with a diagonal line at the top left. Duplicate data stores are given an additional vertical line on the left side of their reference boxes. Sharif University of Technology MIS (Management Information System), Session # 6 15

Information system development System Analysis Recording the information Data Flow Diagrams- DFD components DFDs are constructed using four major components: Data flows, represent the movement of data between other components Data flows are generally shown as one-way only. Data flows between external entities are shown as dotted lines. are identified by the letter M followed by a number, and identifiers for computerised stores are prefixed by a D. Data stores cannot be directly linked by data flows either to each other or to external entities without an intervening process to transform the data. • Processes represent activities in which data is manipulated by being stored or retrieved or transformed in some way. They are shown as larger rectangles with a numeric identifier in a box at the top left corner. The location where the process takes place or the job role performing it is recorded in a box in the top right corner and is used only in diagrams of the current physical system. The name of the process is recorded in the remaining area at the bottom. Process names should be unambiguous, and should convey as much meaning as possible without being too long. In general, names should take the form of an imperative and its object, as in Open Account. Generalised verbs such as Process or Update are not usually helpful. Some practitioners insist on the use of verb-fronting phrases for process descriptions to ensure that the process is an action performed by the business. • Data flows represent the movement of data between other components, for example a report produced by a process and sent to an external entity. They are shown as named arrows connecting the other components of the diagram. Data flows are generally shown as one-way only. Data flows between external entities are shown as dotted lines. It may be necessary to draw the same external entity or data store more than once on the same DFD in order to make the diagram clear and to avoid too many crossing lines. An external entity that appears more than once in the same diagram is shown with a diagonal line at the top left. Duplicate data stores are given an additional vertical line on the left side of their reference boxes. Sharif University of Technology MIS (Management Information System), Session # 6 16

Information system development System Analysis Recording the information Data Flow Diagrams A system is rarely simple enough to be shown on a single DFD, and so a hierarchical set is produced. This consists of a top-level DFD in which the processes are major system functions described in more detail by one or more associated lower-level DFDs. The process of breaking a higher-level (parent) DFD into its constituent lower-level (child) DFDs is known as leveling. As a rule of thumb, however, processes on the lowest level, called elementary processes, should correspond to single events or actions affecting the system, for example cashing a cheque in a banking system. A system is rarely simple enough to be shown on a single DFD, and so a hierarchical set is produced. This consists of a top-level DFD in which the processes are major system functions described in more detail by one or more associated lower-level DFDs. The process of breaking a higher-level (parent) DFD into its constituent lower-level (child) DFDs is known as levelling. There are no particular rules to levelling, the aim being simply to make the diagrams less cluttered and therefore easier to read and understand. As a rule of thumb, however, processes on the lowest level, called elementary processes, should correspond to single events or actions affecting the system, for example cashing a cheque in a banking system. Sharif University of Technology MIS (Management Information System), Session # 6 17

Information system development System Analysis Recording the information Data Flow Diagrams Figure 9.2 shows a level 1 (top level) DFD, and Figure 9.3 shows a DFD from the next level down. The diagrams illustrate a number of additional conventions that have not been described yet. Sharif University of Technology MIS (Management Information System), Session # 6 18

Information system development System Analysis Recording the information Data Flow Diagrams The first thing to notice is that the child DFD – level 2 – has a box round it. This corresponds to a process box on the level 1 DFD and contains the same identifier. Processes on the child are given identifiers that show that they are sub-processes of the one on the parent by adding a number to the identifier of the parent, separated by a point: for example, process 1 on the level 2 DFD for process 4 has the identifier 4.1. The values of these numbers have no significance, as DFDs do not show the sequence of processing, only the flows of data between them. In this they differ from flowcharts, which are specifically intended to show a sequence of actions and decisions. Some of the process boxes on the diagrams are shown with an asterisk enclosed by a diagonal in the bottom right-hand corner. This means that the process concerned is not broken down any further and is therefore an elementary process. External entities, data flows and data stores can also be broken down into more detail on lower-level DFDs. External entities that are components of a parent external entity are distinguished by suffixing numbers to the parent identifier. In a similar way child data stores are referenced by their parent’s identifier followed by a lower-case letter. Data store 1 within process 4, for example, has the identifier D4/1. Data flows are not given any reference other than their name, but a data flow shown as a single line on a parent DFD may represent a number of flows on its child. On level 1 DFDs double-headed arrows may be used as a short-hand way of representing two or more flows in opposite directions in lower-level DFDs. Sharif University of Technology MIS (Management Information System), Session # 6 19

Information system development System Analysis Recording the information Data Flow Diagrams Diagrams alone are not sufficient to convey an understanding of the system being modeled. It is important that DFD components are described in more detail than can be conveyed by the short names they are given in the diagram. Data flows consist of a list of data items that must be documented in a data dictionary so that the data items can be related to attributes in the data model. Diagrams alone are not sufficient to convey an understanding of the system being modelled. It is important that DFD components are described in more detail than can be conveyed by the short names they are given in the diagram. For example, data flows consist of a list of data items that must be documented in a data dictionary so that the data items can be related to attributes in the data model. The term data flow model (DFM) is used in SSADM to refer to a complete set of DFDs describing a system, plus the necessary data dictionary documentation of objects shown on the diagrams. The extent to which higher-level DFDs are documented may vary, but it is essential that objects at the bottom levels are clearly described in order that the diagrams can be unambiguously understood, and to ensure that information about the system is carried through to later stages of the project. Sharif University of Technology MIS (Management Information System), Session # 6 20

Information system development System Analysis Recording the information Data Flow Diagrams only external data flows – data flows into and out of the system – need to be described in detail. These input/output (I/O) descriptions contain: • identifier of the object from which the data flows (e.g. the process number); • identifier of the object to which the data flows; • data flow name; • description of the data flow. Generally speaking, only external data flows – data flows into and out of the system – need to be described in detail. These input/output (I/O) descriptions contain: • identifier of the object from which the data flows (e.g. the process number); • identifier of the object to which the data flows; • data flow name; • description of the data flow. In a similar way only the bottom level – the elementary processes – need to be described, as this is where the detailed processing occurs. Elementary process descriptions consist of: • process number; • process name; • description of the process – this may be a simple textual description, or may use more rigorous techniques such as structured English or decision tables. External entity descriptions contain: • external entity identifier; • external entity name; • description of the external entity. Data stores are initially documented in a similar way, by a text description associated with the data store identifier and name. However, once the data flow model and the data model have become reasonably stable, data stores are documented in terms of the entities that they contain, as this provides a good way of cross-referencing the two models. Sharif University of Technology MIS (Management Information System), Session # 6 21

Information system development System Analysis Recording the information Data Flow Diagrams In a similar way only the bottom level – the elementary processes – need to be described, as this is where the detailed processing occurs. Elementary process descriptions consist of: • process number; • process name; • description of the process – this may be a simple textual description, or may use more rigorous techniques such as structured English or decision tables. External entity descriptions contain: • external entity identifier; • external entity name; • description of the external entity. Generally speaking, only external data flows – data flows into and out of the system – need to be described in detail. These input/output (I/O) descriptions contain: • identifier of the object from which the data flows (e.g. the process number); • identifier of the object to which the data flows; • data flow name; • description of the data flow. In a similar way only the bottom level – the elementary processes – need to be described, as this is where the detailed processing occurs. Elementary process descriptions consist of: • process number; • process name; • description of the process – this may be a simple textual description, or may use more rigorous techniques such as structured English or decision tables. External entity descriptions contain: • external entity identifier; • external entity name; • description of the external entity. Data stores are initially documented in a similar way, by a text description associated with the data store identifier and name. However, once the data flow model and the data model have become reasonably stable, data stores are documented in terms of the entities that they contain, as this provides a good way of cross-referencing the two models. Sharif University of Technology MIS (Management Information System), Session # 6 22

Information system development System Analysis Recording the information Starting the Data Flow Diagrams Two areas may cause difficulty when starting out. One is defining the boundary of the system. What are the parts of the business to be included in the system? Once the system boundary has been defined, what are the boundaries of the top-level functional areas included in the system? Two subsidiary techniques help to answer these questions: Context diagrams and Document flow diagrams. Two areas may cause difficulty when starting out. One is defining the boundary of the system. What are the parts of the business to be included in the system? And once the system boundary has been defined, what are the boundaries of the top-level functional areas included in the system? Two subsidiary techniques help to answer these questions: context diagrams and document flow diagrams. A context diagram is similar to a top-level DFD but with the whole system shown as a ‘black box’. In other words, external entities and data flows into and out of the system are drawn but no processes or data stores are shown. An example is shown in Figure 9.4. Context diagrams are used early in a project as a means of describing and agreeing the scope or boundary of the system to be developed. Sharif University of Technology MIS (Management Information System), Session # 6 23

Information system development System Analysis Recording the information Context Diagrams A context diagram is similar to a top-level DFD but with the whole system shown as a ‘black box’. In other words, external entities and data flows into and out of the system are drawn but no processes or data stores are shown. Context diagrams are used early in a project as a means of describing and agreeing the scope or boundary of the system to be developed. Two areas may cause difficulty when starting out. One is defining the boundary of the system. What are the parts of the business to be included in the system? And once the system boundary has been defined, what are the boundaries of the top-level functional areas included in the system? Two subsidiary techniques help to answer these questions: context diagrams and document flow diagrams. A context diagram is similar to a top-level DFD but with the whole system shown as a ‘black box’. In other words, external entities and data flows into and out of the system are drawn but no processes or data stores are shown. An example is shown in Figure 9.4. Context diagrams are used early in a project as a means of describing and agreeing the scope or boundary of the system to be developed. Sharif University of Technology MIS (Management Information System), Session # 6 24

Information system development System Analysis Recording the information Context Diagrams Two areas may cause difficulty when starting out. One is defining the boundary of the system. What are the parts of the business to be included in the system? And once the system boundary has been defined, what are the boundaries of the top-level functional areas included in the system? Two subsidiary techniques help to answer these questions: context diagrams and document flow diagrams. A context diagram is similar to a top-level DFD but with the whole system shown as a ‘black box’. In other words, external entities and data flows into and out of the system are drawn but no processes or data stores are shown. An example is shown in Figure 9.4. Context diagrams are used early in a project as a means of describing and agreeing the scope or boundary of the system to be developed. Sharif University of Technology MIS (Management Information System), Session # 6 25

Information system development System Analysis Recording the information Document flow Diagrams Document flow diagrams may be used as a preliminary to producing DFDs for the current system in the early stages of a project. They are used to show how documents move round in a manual system. By drawing boundaries around parts of the diagram, different functional areas of the system can be distinguished. Areas of the diagram outside the boundaries are external to the system and will appear as external entities and external data flows on the current system DFDs. The bounded areas will appear as processes on the level 1 DFD. Document flow diagrams may be used as a preliminary to producing DFDs for the current system in the early stages of a project. As their names suggest, they are used to show how documents move round in a manual system. The example in Figure 9.5 shows how documents and the people or departments who handle them are represented. By drawing boundaries around parts of the diagram, different functional areas of the system can be distinguished. Areas of the diagram outside the boundaries are external to the system and will appear as external entities and external data flows on the current system DFDs. The bounded areas will appear as processes on the level 1 DFD. Sharif University of Technology MIS (Management Information System), Session # 6 26

Information system development System Analysis Recording the information Document flow Diagrams Document flow diagrams may be used as a preliminary to producing DFDs for the current system in the early stages of a project. As their names suggest, they are used to show how documents move round in a manual system. The example in Figure 9.5 shows how documents and the people or departments who handle them are represented. By drawing boundaries around parts of the diagram, different functional areas of the system can be distinguished. Areas of the diagram outside the boundaries are external to the system and will appear as external entities and external data flows on the current system DFDs. The bounded areas will appear as processes on the level 1 DFD. Sharif University of Technology MIS (Management Information System), Session # 6 27

Information system development System Analysis Recording the information Data flow Diagrams Top-level processes are usually fairly easy to identify as they often correspond to departments in the organization. When the top-level processes have been identified they should be looked at in more detail to see if they need to be broken down further. The aim is to break the processing down until the bottom-level processes each handle a single event such as the return of a book. Top-level processes are usually fairly easy to identify as they often correspond to departments in the organisation. In our library example Acquisitions, Cataloguing and Loans are likely to be separate sections in a large library, run by different librarians. They indicate the presence of processes called Acquire Books, Catalogue Books and Lend Books. However, these activities may not be organised into sections, and the staff in one section may perform a number of processes. The presence of major data stores such as the book catalogue and the loans file can also indicate different areas of activity even if the work is done by the same section. When the top-level processes have been identified they should be looked at in more detail to see if they need to be broken down further. Lend Books, in our example, has been broken down into Issue Books, Reserve Books and Recall Books. These may in their turn be broken down still further. Issue Books may be split into Record Book Loan and Record Book Return. The aim is to break the processing down until the bottom-level processes each handle a single event such as the return of a book. Sharif University of Technology MIS (Management Information System), Session # 6 28

Information system development System Analysis Recording the information Data flow Diagrams Entity Models An entity model represents the network of relationships between classes of things that need to have data recorded about them in the system. The term entity type or entity is used to describe a ‘class of things’. entities represent not only physical objects but also conceptual objects, such as ‘bank account’, or events, such as ‘transaction’. An entity model represents the network of relationships between classes of things that need to have data recorded about them in the system. The term entity type or entity is used to describe a ‘class of things’. Having drawn an entity model, it is possible to show how the system can use these relationships by following them as paths for obtaining related pieces of data, either for update or for reporting and enquiry purposes. For example, many different transactions may be made on a bank account during a month. In order to print a monthly statement for the account, all the transactions must be found and a relationship between the entities ‘bank account’ and ‘transaction’ must be present. The general concept of a bank account corresponds to an entity, whereas the bank account for a particular customer is known as an occurrence or instance of the entity. As this example shows, entities represent not only physical objects but also conceptual objects, such as ‘bank account’, or events, such as ‘transaction’. Sharif University of Technology MIS (Management Information System), Session # 6 29

Information system development System Analysis Recording the information Data flow Diagrams Entity Models The entity model in SSADM is called logical data structure (LDS). LDSs are simpler than DFDs in that they have only two major components – entities and the relationships between them. An entity is usually represented as a rectangle containing its name, written as a singular noun. Relationships are shown as lines linking entities. Relationships can be traversed in both directions, and so each end of a relationship is named in order to describe it from the point of view of the entity at that end. As we are using SSADM as our example structured method, we’ll look at the logical data structure (LDS), which is the name given to the entity model in SSADM. LDSs are simpler than DFDs in that they have only two major components – entities and the relationships between them. Entities, as already described, are classes of things about which data is recorded in a system. An entity is usually represented as a rectangle containing its name, written as a singular noun. It is important that entities are given meaningful names, preferably ones that are used by or will be understood by the users. In SSADM the entity rectangles have rounded corners. Sharif University of Technology MIS (Management Information System), Session # 6 30

Information system development System Analysis Recording the information Data flow Diagrams Entity Models Classification of relationships is known as the degree of the relationship Most relationships are between one master entity and many detail entities. <<one-to many relationship>> Relationships may also be <<many-to-many >> or <<one-to-one>>. One-to-one relationships are uncommon, as it is usually found that two entities that are linked in this way can be combined to give a single entity. Many-to-many relationships are more common, but it is usual to resolve them by introducing a new ‘link’ entity that is a detail of the two original entities Relationships are shown as lines linking entities. Relationships can be traversed in both directions, and so each end of a relationship is named in order to describe it from the point of view of the entity at that end. Most relationships are between one master entity and many detail entities. This is known as a one-tomany relationship and is shown by giving the line a ‘crow’s foot’ at the many or detail end as shown in Figure 9.6, which represents a relationship between one ‘bank account’ and many ‘transactions’. Other methods may use an arrow rather than a crow’s foot. Relationships may also be many-to-many or one-to-one. This classification of relationships is known as the degree of the relationship. One-to-one relationships are uncommon, as it is usually found that two entities that are linked in this way can be combined to give a single entity. Many-to-many relationships are more common, but it is usual to resolve them by introducing a new ‘link’ entity that is a detail of the two original entities, as shown in Figure 9.7. In this case the many-to-many relationship between ‘book’ and ‘borrower’ is resolved by introducing the entity ‘loan’, which has a relationship with both ‘borrower’ and ‘book’. Sharif University of Technology MIS (Management Information System), Session # 6 31

Information system development System Analysis Recording the information Data flow Diagrams Entity Models Relationships are shown as lines linking entities. Relationships can be traversed in both directions, and so each end of a relationship is named in order to describe it from the point of view of the entity at that end. Most relationships are between one master entity and many detail entities. This is known as a one-tomany relationship and is shown by giving the line a ‘crow’s foot’ at the many or detail end as shown in Figure 9.6, which represents a relationship between one ‘bank account’ and many ‘transactions’. Other methods may use an arrow rather than a crow’s foot. Relationships may also be many-to-many or one-to-one. This classification of relationships is known as the degree of the relationship. One-to-one relationships are uncommon, as it is usually found that two entities that are linked in this way can be combined to give a single entity. Many-to-many relationships are more common, but it is usual to resolve them by introducing a new ‘link’ entity that is a detail of the two original entities, as shown in Figure 9.7. In this case the many-to-many relationship between ‘book’ and ‘borrower’ is resolved by introducing the entity ‘loan’, which has a relationship with both ‘borrower’ and ‘book’. Sharif University of Technology MIS (Management Information System), Session # 6 32

Information system development System Analysis Recording the information Data flow Diagrams Entity Models Relationships are also classified in terms of their optionality. Relationships can be described as exclusive. One type of exclusivity occurs if a detail entity has two (or more) masters and an occurrence of the detail may be linked to only one of the masters but not both. The other is the converse situation where a master may be linked to only one of two or more sets of details. Exclusive relationships are shown by drawing an exclusion arc to connect them Relationships are also classified in terms of their optionality. This describes the situation where the analyst considers whether an entity occurrence at one end of a relationship can ever be present in the system without the presence of a corresponding occurrence of the entity at the other end of the relationship. Figure 9.8 shows the different types of optionality that may occur. Relationships can be described as exclusive. One type of exclusivity occurs if a detail entity has two (or more) masters and an occurrence of the detail may be linked to only one of the masters but not both. The other is the converse situation where a master may be linked to only one of two or more sets of details. Exclusive relationships are shown by drawing an exclusion arc to connect them, as shown in Figure 9.9. Sharif University of Technology MIS (Management Information System), Session # 6 33

Information system development System Analysis Recording the information Data flow Diagrams Entity Models Relationships are also classified in terms of their optionality. This describes the situation where the analyst considers whether an entity occurrence at one end of a relationship can ever be present in the system without the presence of a corresponding occurrence of the entity at the other end of the relationship. Figure 9.8 shows the different types of optionality that may occur. Relationships can be described as exclusive. One type of exclusivity occurs if a detail entity has two (or more) masters and an occurrence of the detail may be linked to only one of the masters but not both. The other is the converse situation where a master may be linked to only one of two or more sets of details. Exclusive relationships are shown by drawing an exclusion arc to connect them, as shown in Figure 9.9. Sharif University of Technology MIS (Management Information System), Session # 6 34

Information system development System Analysis Recording the information Data flow Diagrams Entity Models Relationships are also classified in terms of their optionality. This describes the situation where the analyst considers whether an entity occurrence at one end of a relationship can ever be present in the system without the presence of a corresponding occurrence of the entity at the other end of the relationship. Figure 9.8 shows the different types of optionality that may occur. Relationships can be described as exclusive. One type of exclusivity occurs if a detail entity has two (or more) masters and an occurrence of the detail may be linked to only one of the masters but not both. The other is the converse situation where a master may be linked to only one of two or more sets of details. Exclusive relationships are shown by drawing an exclusion arc to connect them, as shown in Figure 9.9. Sharif University of Technology MIS (Management Information System), Session # 6 35

Information system development System Analysis Recording the information Data flow Diagrams Entity Models <<Recursive relationships>>: In other words, individual occurrences of entities can be related to other occurrences of that entity. There are two ways in which this can happen. The first is where there is a one-to-many or hierarchical relationship between entity occurrences. or by a single entity called manager, which has a recursive relationship with itself. recursive relationships. In other words, individual occurrences of entities can be related to other occurrences of that entity. There are two ways in which this can happen. The second way in which an entity can be related to itself is where there is a many-to-many relationship between occurrences, indicating a network structure. The classic example of this sort of relationship is known as the bill of materials processing or BOMP structure. This is where, for example, a piece of machinery is made up of many different parts, some of which are sub-assemblies that themselves contain a range of different parts. This structure is not a hierarchy, as some parts may be listed as components at a number of different levels of assembly. One way in which the structure can be shown is as a single entity linked to itself by a many-to-many relationship. However, a more helpful representation is gained by breaking the many-to-many relationship into two one-to-many relationships and creating a new entity that acts as a link between different occurrences of the original entity. These two representations are shown in Figure 9.11, where food products are used as an example. For instance, jam is a food product made up of other food products such as fruit and sugar. However, jam may appear as an ingredient of a cake, which also has fruit or sugar specified as ingredients independently of their use in the jam. Sharif University of Technology MIS (Management Information System), Session # 6 36

Information system development System Analysis Recording the information Data flow Diagrams Entity Models <<Recursive relationships>>: The second way in which an entity can be related to itself is where there is a many-to-many relationship between occurrences, indicating a network structure. There are two ways in which this can happen. One way in which the structure can be shown is as a single entity linked to itself by a many-to-many relationship. breaking the many-to-many relationship into two one-to-many relationships and creating a new entity that acts as a link between different occurrences of the original entity. recursive relationships. In other words, individual occurrences of entities can be related to other occurrences of that entity. There are two ways in which this can happen. The second way in which an entity can be related to itself is where there is a many-to-many relationship between occurrences, indicating a network structure. The classic example of this sort of relationship is known as the bill of materials processing or BOMP structure. This is where, for example, a piece of machinery is made up of many different parts, some of which are sub-assemblies that themselves contain a range of different parts. This structure is not a hierarchy, as some parts may be listed as components at a number of different levels of assembly. One way in which the structure can be shown is as a single entity linked to itself by a many-to-many relationship. However, a more helpful representation is gained by breaking the many-to-many relationship into two one-to-many relationships and creating a new entity that acts as a link between different occurrences of the original entity. These two representations are shown in Figure 9.11, where food products are used as an example. For instance, jam is a food product made up of other food products such as fruit and sugar. However, jam may appear as an ingredient of a cake, which also has fruit or sugar specified as ingredients independently of their use in the jam. Sharif University of Technology MIS (Management Information System), Session # 6 37

Information system development System Analysis Recording the information Data flow Diagrams Entity Models-The Logical Data Model A logical data model (LDM) consists of an LDS diagram and a set of entity descriptions and relationship descriptions, which give more detail about the diagram components. Relationship are usually documented in both directions. In other words, they are described from the point of view of each of the two entities that make up the relationship. As with DFDs, LDS diagrams are not able to carry all the information that analysts need to record about a system. A logical data model (LDM) consists of an LDS diagram and a set of entity descriptions and relationship descriptions, which give more detail about the diagram components. Relationship are usually documented in both directions. In other words, they are described from the point of view of each of the two entities that make up the relationship. For each relationship ‘half’, the following information should be recorded: • first entity name (the entity at this end of the relationship); • second entity name (the entity at the other end); • relationship name or phrase shown on the LDS; Sharif University of Technology MIS (Management Information System), Session # 6 38

Information system development System Analysis Recording the information Data flow Diagrams Entity Models-The Logical Data Model For each relationship ‘half’, the following information should be recorded: First entity name (the entity at this end of the relationship); Second entity name (the entity at the other end); Relationship name or phrase shown on the LDS; Description of the relationship (in business terms); Degree of the relationship (one to many, many to one, etc.); Cardinality of the relationship (the number of second entities expected to be Linked to each first entity – this may be an average or, better, a distribution); Optionality of the relationship; List of users and their access rights to the relationship (update, read, etc.). As with DFDs, LDS diagrams are not able to carry all the information that analysts need to record about a system. A logical data model (LDM) consists of an LDS diagram and a set of entity descriptions and relationship descriptions, which give more detail about the diagram components. Relationship are usually documented in both directions. In other words, they are described from the point of view of each of the two entities that make up the relationship. For each relationship ‘half’, the following information should be recorded: • first entity name (the entity at this end of the relationship); • second entity name (the entity at the other end); • relationship name or phrase shown on the LDS; Sharif University of Technology MIS (Management Information System), Session # 6 39

Information system development System Analysis Recording the information Data flow Diagrams Entity Models-The Logical Data Model Entity descriptions should contain at least the following information: Entity name; Alternative names (synonyms); Description of the entity; The owner (this is the user to whom the data in the entity belongs); List of users and their access rights to the entity (update, read, etc.); Expected number of occurrences of the entity and growth rates; Rules for archiving and deleting entity occurrences. As with DFDs, LDS diagrams are not able to carry all the information that analysts need to record about a system. A logical data model (LDM) consists of an LDS diagram and a set of entity descriptions and relationship descriptions, which give more detail about the diagram components. Relationship are usually documented in both directions. In other words, they are described from the point of view of each of the two entities that make up the relationship. For each relationship ‘half’, the following information should be recorded: • first entity name (the entity at this end of the relationship); • second entity name (the entity at the other end); • relationship name or phrase shown on the LDS; Sharif University of Technology MIS (Management Information System), Session # 6 40

Information system development System Analysis Recording the information Data flow Diagrams Entity Models-The Logical Data Model One of the things we also need to record about an entity is the list of attributes it contains. An attribute, or data item, is a piece of information that the system needs to record about an entity. Attributes may be held by an entity purely as information, or they may play a role in relationships between entities, in which case they are known as key attributes or keys. One of the things we also need to record about an entity is the list of attributes it contains. An attribute, or data item, is a piece of information that the system needs to record about an entity. Attributes may be held by an entity purely as information, or they may play a role in relationships between entities, in which case they are known as key attributes or keys. Keys are principally of two types: prime keys and foreign keys. Prime keys are used to identify different occurrences of the same entity. The entity ‘bank account’ is a generalisation of many different occurrences of individual bank accounts. To extend our previous example, in order to produce a statement for a particular account on demand it must be possible to pick out that account from all the other accounts in the system. The way to do this is to identify, or invent, a piece of information about the account that is unique and distinguishes it from all other accounts. The obvious candidate for this in our example is the account number. Sharif University of Technology MIS (Management Information System), Session # 6 41

Information system development System Analysis Recording the information Data flow Diagrams Entity Models-The Logical Data Model Keys are principally of two types: prime keys and foreign keys. Prime keys are used to identify different occurrences of the same entity. Foreign keys are attributes that are also present as prime keys on other entities. One of the things we also need to record about an entity is the list of attributes it contains. An attribute, or data item, is a piece of information that the system needs to record about an entity. Attributes may be held by an entity purely as information, or they may play a role in relationships between entities, in which case they are known as key attributes or keys. Keys are principally of two types: prime keys and foreign keys. Prime keys are used to identify different occurrences of the same entity. The entity ‘bank account’ is a generalisation of many different occurrences of individual bank accounts. To extend our previous example, in order to produce a statement for a particular account on demand it must be possible to pick out that account from all the other accounts in the system. The way to do this is to identify, or invent, a piece of information about the account that is unique and distinguishes it from all other accounts. The obvious candidate for this in our example is the account number. Sharif University of Technology MIS (Management Information System), Session # 6 42

Information system development System Analysis Recording the information Data flow Diagrams Entity Models-The Logical Data Model One of the things we also need to record about an entity is the list of attributes it contains. An attribute, or data item, is a piece of information that the system needs to record about an entity. Attributes may be held by an entity purely as information, or they may play a role in relationships between entities, in which case they are known as key attributes or keys. Keys are principally of two types: prime keys and foreign keys. Prime keys are used to identify different occurrences of the same entity. The entity ‘bank account’ is a generalisation of many different occurrences of individual bank accounts. To extend our previous example, in order to produce a statement for a particular account on demand it must be possible to pick out that account from all the other accounts in the system. The way to do this is to identify, or invent, a piece of information about the account that is unique and distinguishes it from all other accounts. The obvious candidate for this in our example is the account number. Sharif University of Technology MIS (Management Information System), Session # 6 43

Information system development System Analysis Recording the information Data catalogue The data catalogue is a list of all the data items or attributes that have been identified as being required in the system. Attributes are the individual items of data that are used to describe entities in the logical data model and which travel along data flows in DFMs, where they are listed on the I/O descriptions. The data catalogue is in fact a subset of the data dictionary and is concerned with individual data items and the values they may take As its name suggests, the data catalogue is a list of all the data items or attributes that have been identified as being required in the system. Attributes are the individual items of data that are used to describe entities in the logical data model and which travel along data flows in DFMs, where they are listed on the I/O descriptions. The data catalogue is in fact a subset of the data dictionary and is concerned with individual data items and the values they may take. The information that should be recorded about attributes includes: • attribute name; • alternative names (synonyms); • description of the attribute; • attribute location (entity or data flow); • relationships to other attributes; • format (including units and length); • values (or ranges of values) the attribute is allowed to have; • rules for deriving the value of attribute occurrences; • optionality of the attribute; • the owner, i.e. the user to whom the data in the attribute belongs; • list of users and their access rights to the attribute (update, read, etc.). Sharif University of Technology MIS (Management Information System), Session # 6 44

Information system development System Analysis Recording the information Data catalogue The information that should be recorded about attributes includes: Attribute name; Alternative names (synonyms); Description of the attribute; Attribute location (entity or data flow); Relationships to other attributes; Format (including units and length); Values (or ranges of values) the attribute is allowed to have; Rules for deriving the value of attribute occurrences; Optionality of the attribute; The owner, i.e. the user to whom the data in the attribute belongs; List of users and their access rights to the attribute (update, read, etc.). As its name suggests, the data catalogue is a list of all the data items or attributes that have been identified as being required in the system. Attributes are the individual items of data that are used to describe entities in the logical data model and which travel along data flows in DFMs, where they are listed on the I/O descriptions. The data catalogue is in fact a subset of the data dictionary and is concerned with individual data items and the values they may take. The information that should be recorded about attributes includes: • attribute name; • alternative names (synonyms); • description of the attribute; • attribute location (entity or data flow); • relationships to other attributes; • format (including units and length); • values (or ranges of values) the attribute is allowed to have; • rules for deriving the value of attribute occurrences; • optionality of the attribute; • the owner, i.e. the user to whom the data in the attribute belongs; • list of users and their access rights to the attribute (update, read, etc.). Sharif University of Technology MIS (Management Information System), Session # 6 45