Systems Analysis and Design C ITIP211

Systems Analysis and Design C_ITIP211

Compiled by Sonja Visagie

Quality assured by Kebashnee Jurakhan

Edited by Chantal Joseph

Version 1.0

NQF Level 6

Credit value: 12

TABLE OF CONTENTS

INTRODUCTION ...... 1 Module aim ...... 1 Module abstract ...... 1 Learning outcomes and assessment criteria ...... 2 Summary of learning outcomes and assessment criteria ...... 2 Module content ...... 3 Lectures...... 3 Class exercises and activities ...... 4 Information resources ...... 4 Prescribed textbook ...... 4 Prescribed textbook for Systems Analysis and Design...... 4 Recommended information sources ...... 4 Using this Study Guide ...... 5 Purpose ...... 5 Structure ...... 6 Individual units ...... 6 Glossary ...... 7 The use of icons ...... 7 Alignment to prescribed textbook ...... 8 Study Guide/prescribed textbook alignment ...... 8 Concluding remarks ...... 8 UNIT 1: THE SYSTEMS DEVELOPMENT ENVIRONMENT ...... 9 Learning objectives ...... 9 Prescribed reading ...... 9 Introduction ...... 9 Information systems analysis and design ...... 10 System definition and characteristics ...... 10 System concepts ...... 11 Information system components ...... 13 The SDLC (Systems Development Life Cycle) ...... 15 1.5.1 Phase 1: systems planning and selection ...... 16 1.5.2 Phase 2: systems analysis ...... 16 1.5.3 Phase 3: systems design ...... 17 1.5.4 Phase 4: systems implementation and operation ...... 17 System life cycle models ...... 17 1.6.1 Waterfall model ...... 18 1.6.2 Prototyping ...... 19 1.6.3 (CASE) Computer-Aided Software Development tools ...... 19 1.6.4 JAD (Joint Application Development) ...... 20 1.6.5 RAD (Rapid Application Development) ...... 21 Concluding remarks ...... 24 Self-assessment ...... 24 UNIT 2: FEASIBILITY STUDIES AND FACT-FINDING TECHNIQUES ...... 25 Learning objectives ...... 25 Prescribed reading ...... 25 Introduction ...... 25 Feasibility study ...... 26 2.1.1 Operational feasibility ...... 26 2.1.2 Technical feasibility ...... 26 2.1.3 Economic feasibility ...... 26 2.1.4 Schedule feasibility ...... 27 SWOT analysis ...... 27 Feasibility report ...... 28 Fact-finding techniques ...... 29 Traditional methods for determining requirements ...... 30 2.5.1 Interviews ...... 30 2.5.2 Observation ...... 31

2.5.3 Investigation of documentation ...... 31 2.5.4 Questionnaires ...... 31 Concluding remarks ...... 32 Self-assessment ...... 32 UNIT 3: PROCESS MODELLING ...... 33 Learning objectives ...... 33 Prescribed reading ...... 33 Introduction ...... 34 Process modelling ...... 34 Decomposition diagram ...... 35 Context diagrams (Context DFDs) ...... 37 DFDs ...... 38 3.4.1 Balancing DFDs ...... 40 3.4.2 DFD mistakes: Black hole, miracle and grey hole ...... 40 Process modelling exercises ...... 41 3.5.1 DFD exercise 1 ...... 41 3.5.2 DFD exercise 2 ...... 42 Concluding remarks ...... 43 Self-assessment ...... 44 UNIT 4: DATA MODELLING ...... 45 Learning objectives ...... 45 Prescribed reading ...... 45 Introduction ...... 45 Entities and attributes ...... 46 3.6.1 Entities ...... 46 3.6.2 Attributes ...... 47 ERD relationships: degree, cardinality and naming ...... 49 3.7.1 ERD relationship ...... 49 3.7.2 Relationship degree, cardinality and naming ...... 50 Constructing an ERD ...... 52 3.8.1 Step 1: Identify the entities ...... 52 3.8.2 Step 2: Identify the attributes for each entity ...... 52 3.8.3 Step 3: Identify the relationships, including the degrees and cardinality ...... 52 3.8.4 Step 4: Name the relationships ...... 53 3.8.5 Step 5: Draw the ERD ...... 53 Data modelling exercises ...... 54 3.9.1 ERD exercise 1 ...... 54 3.9.2 ERD exercise 2 ...... 54 Concluding remarks ...... 55 Self-assessment ...... 55 GLOSSARY ...... 56 BIBLIOGRAPHY ...... 58

Introduction Page 1

Introduction Welcome to Systems Analysis and Design. This module aims to provide students with the knowledge and skills to undertake a systems investigation and to conduct process and data modelling techniques during systems analysis and design.

The main sources of information for Systems Analysis and Design are a prescribed textbook and this Study Guide. The Study Guide should not be seen as a replacement for the prescribed textbook – you have to use it in conjunction with the textbook, which contains the actual learning content of the module. You are expected to work through the relevant sections of the textbook independently. The Study Guide will facilitate this process by means of references to relevant chapters/sections in the prescribed textbook.

In this introductory unit, we provide you with the following information on Systems Analysis and Design:

 A brief description of the aim of the module  An abstract of the module  The learning outcomes and assessment criteria involved in the module  An outline of the module content  An outline of the module structure  An explanation of the purpose, design and proper use of the Study Guide and prescribed textbook

Module aim This module aims to provide students with the knowledge and skills to undertake a systems investigation and to conduct process and data modelling techniques during systems analysis and design.

Module abstract Information systems analysis involves focusing on a business problem and the requirements necessary to develop a system that will meet those requirements. Information systems design focuses on the technology that will be applied to implement a solution to the business problem.

You will explore the purpose of conducting a feasibility study and how to determine which systems development option would meet the business need. You will also understand the use of different fact-finding techniques for stakeholder requirements elicitation.

Systems analysts apply the SDLC (Systems Development Life Cycle) to develop information systems. You will examine the use of a traditional methodology (Waterfall model) and some agile models and techniques that could be applied during an information systems development project.

Learning outcomes and assessment criteria On successful completion of this module, you will:

1. Compare different systems life cycles

2. Discuss the importance of a feasibility study

3. Perform a systems investigation

The following table outlines the assessment criteria that are aligned to the learning outcomes.

Summary of learning outcomes and assessment criteria

Learning outcomes Assessment criteria to pass On successful completion of You can this module, you will 1.1 Evaluate the different systems life cycle models 1. Compare different systems life 1.2 Discuss the importance of following a cycles procedural/staged life cycle in a systems investigation 2.1 Discuss the components of a feasibility report 2. Discuss the importance of 2.2 Assess the effect of different feasibility criteria on a feasibility studies systems investigation 3.1 Undertake a systems investigation to meet a business need 3.2 Use appropriate systems analysis tools and 3. Perform a systems techniques to perform a systems investigation investigation 3.3 Create documentation to support a systems investigation 3.4 Evaluate how user and systems requirements have been addressed

These outcomes are covered in the module content, and they are assessed in the form of written assignments and semester tests. If you comply with and achieve all the pass criteria related to the outcomes, you will pass this module.

Learning and assessment may be performed across modules, at module level or at outcome level. Evidence may be required at outcome level, although opportunities exist for covering more than one outcome in an assignment.

Module content 1. Compare the different systems life cycles

Different systems life cycle models are discussed, including the SDLC, traditional and some agile methodologies for systems development.

The importance of following a staged life cycle in a systems investigation is discussed. This includes the typical SDLC phases: planning and selection, analysis, design, and implementation and operation.

2. Discuss the importance of a feasibility study

Fact-finding techniques, like interviews, observation, the investigation of documentation, and questionnaires are explored.

The importance of a feasibility analysis and feasibility criteria are explained, which includes operational, schedule, economic and technical feasibility.

3. Perform a systems investigation

The importance of undertaking a systems investigation to meet a business need is addressed by discussing systems analysis tools (CASE tools, etc.) and techniques (process and data modelling).

DFDs (Data Flow Diagrams) and ERDs (Entity-Relationship Diagrams) are constructed from case studies, which support a systems investigation.

Lectures Each week has four compulsory lecture hours for all students. It is recommended that the lecture hours be divided into two sessions of two hours each, but this may vary depending on the campus.

Each week has a lecture schedule, which indicates the approximate time that should be allocated to each activity. The week’s work schedule has also been divided into two lessons.

Class exercises and activities You will be required to complete a number of exercises and activities in class. These activities and exercises may also contribute to obtaining a pass; therefore, it is important that you are present in class so that you do not forfeit the opportunity to be exposed to such exercises and activities.

Activity sheets that are submitted should be kept by the lecturer so that they can be used as proof of criteria that were met, if necessary.

Information resources You should have access to a resource centre or library with a wide range of relevant resources. Resources can include textbooks, e-books, newspaper articles, journal articles, organisational publications, databases, etc. You can access a range of academic journals in electronic format via EBSCOhost. You will have to ask a campus librarian to assist you with accessing EBSCOhost.

Prescribed textbook

Prescribed textbook for Systems Analysis and Design Valacich, J.S.; George, J.F. & Hoffer, J. 2015. Essentials of systems analysis and design, global edition. 6th edition. Pearson Education. ISBN: 9781292076614.

Recommended information sources Dennis, A.; Wixom, B.H. & Roth, R.M. 2014. Systems analysis and design. 6th edition. New Jersey: John Wiley and Sons.

Freetutes. 2015. Systems analysis and design. [Online] Available at: www.freetutes.com/systemanalysis/ [Accessed: 10 September 2015].

Lejk, M. & Deeks, D. 2002. An introduction to system analysis techniques. 2nd edition. Boston: Addison Wesley.

Student resources: [Online] Available at: http://highered.mcgraw- hill.com/sites/0073052337/student_view0/ [Accessed: 10 September 2015].

Whitten, J.L. & Bentley, L.D. 2007. Systems analysis and design methods. 7th edition. Boston: McGraw-Hill Higher Education.

NOTE ● Web pages provide access to a further range of Internet information sources. ● Students must use this resource with care, justifying the use of information gathered.

Using this Study Guide As we indicated earlier, the prescribed textbook is your main source of information for this module, whereas the Study Guide serves as a guide to the prescribed textbook.

The purpose of the Study Guide is to facilitate your learning and help you to master the content of the prescribed textbook and other material. It, further, helps you to structure your learning and manage your time; provides outcomes and activities to help you master said outcomes; and directs you to the appropriate chapters/sections in the prescribed textbook. It is, therefore, important that you start with the Study Guide.

The Study Guide has been carefully designed to optimise your study time and maximise your learning so that your learning experience is as meaningful and successful as possible. To deepen your learning and enhance your chances of success, it is important that you read the Study Guide attentively and follow all the instructions carefully. Pay special attention to the module outcomes at the beginning of the Study Guide as well as at the beginning of each unit.

It is essential that you complete the exercises and other learning activities in the Study Guide, as your module assessments (examinations, tests and assignments) will be based on the assumption that you have completed these activities.

The Study Guide accompanies the prescribed textbook and, therefore, it should be read in conjunction with such; it should not be deemed as a replacement for the prescribed textbook.

Purpose The purpose of the Study Guide is to facilitate your learning process, to help you to structure your learning and to master the content of the module. The textbook will cover certain themes/topics in detail. Where applicable, more simplified explanations are provided in the Study Guide.

It is important for you to work through both the prescribed textbook and Study Guide attentively and to follow all instructions set out in the Study Guide. In this way, you should be able to deepen your learning and enhance your chances of success.

Structure The Study Guide is structured as follows:

Introduction Unit 1 The systems development environment Unit 2 Feasibility studies and fact-finding techniques Unit 3 Process modelling Unit 4 Data modelling Glossary Bibliography

Individual units The individual units in the Study Guide are structured in the same way. Each unit contains the following features, which should enhance your learning process:

Each unit title is based on the title and/or content of a specific Unit title learning outcome or assessment criterion (criteria) as discussed in the unit. The unit title is followed by an outline of the learning outcomes and assessment criteria, which will guide your learning process. Learning outcomes and It is important for you to become familiar with the learning assessment criteria outcomes and assessment criteria, as they represent the overall purpose of the module as well as the end product of what you should have learnt in the unit. Learning objectives, which follow the learning outcomes and assessment criteria, are statements that define the expected goals of the unit in terms of specific knowledge and skills that Learning objectives you should acquire as a result of mastering the unit content. Learning objectives clarify, organise and prioritise learning and help you to evaluate your own progress, thereby taking responsibility for your learning. The learning objectives are followed by information outlining prescribed reading. This section indicates the relevant Prescribed reading chapters/sections in the prescribed textbook that you are expected to study for the unit. The prescribed reading section is followed by an introduction Introduction that identifies the key concepts of the unit. The content of each unit contains the theoretical foundation of the module and is based on the work of experts in the field of Content this module. Theory is illustrated by means of relevant examples. The concluding remarks at the end of each unit provide a brief Concluding remarks summary of the unit as well as an indication of what you can expect in the following unit. The unit ends off with a number of theoretical self-assessment Self-assessment questions that test your knowledge of the unit content.

Glossary As you will see, we include a glossary at the end of the Study Guide. Please refer to it as often as necessary in order to familiarise yourself with the exact meaning of terms and concepts.

The use of icons Icons are used to highlight (emphasise) particular sections or points in the Study Guide, to draw your attention to important aspects of the work or to highlight activities. The following icons are used in the Study Guide:

Activity

This icon indicates learning activities/exercises that have to be completed, whether individually or in groups, in order to assess (evaluate) your understanding of the content of a particular section.

Definition This icon appears when definitions of a particular term or concept are given in the text.

Example This icon points to a section in the text where relevant examples of a particular topic (theme) or concept are provided.

Learning outcome alignment This icon is used to indicate how individual units in the Study Guide are aligned to a specific learning outcome and its assessment criteria.

Prescribed reading This icon indicates reference to relevant chapters/sections in the textbook that you are expected to study.

Test your knowledge This icon appears at the end of each unit in the Study Guide. It indicates that you are required to answer self-assessment questions to test your knowledge of the content of the foregoing unit.

Alignment to prescribed textbook The following table reflects the alignment between the learning outcomes, assessment criteria, units in the Study Guide and chapters in the prescribed textbook.

Study Guide/prescribed textbook alignment

Study Textbook Learning outcomes Assessment criteria Guide chapter unit 1.1 Evaluate different systems life cycle 1. Compare the models different systems 1.2 Discuss the importance of following a 1 1 life cycles procedural/staged life cycle in a systems investigation 2.1 Discuss the components of a feasibility 2. Discuss the report importance of a 2 4, 5 2.2 Assess the effect of different feasibility feasibility study criteria on a systems investigation 3.1 Undertake a systems investigation to 1, 3, 4 6, 7 meet a business need 3.2 Use appropriate systems analysis tools 3. Perform a and techniques to perform a systems systems investigation investigation 3.3 Create documentation to support a 3, 4 6, 7 systems investigation 3.4 Evaluate how user and systems requirements have been addressed

Concluding remarks

At this point, you should be familiar with the module design and structure as well as with the use of the prescribed textbook in conjunction with the Study Guide.

In Unit 1, we start with the actual module content by looking at the systems development environment.

Unit 1: The systems development environment

Unit 1 is aligned with the following learning outcomes and assessment criteria:

Learning outcomes LO1 Compare the different systems life cycles LO3 Perform a systems investigation

Assessment criteria AC1.1 Evaluate different systems life cycle models AC1.2 Discuss the importance of following a procedural/staged life cycle in a systems investigation AC3.1 Undertake a systems investigation to meet a business need

Learning objectives After studying this unit, you should be able to:

● Understand system theory and information system components ● Understand the SDLC (Systems Development Life Cycle) ● Evaluate systems life cycle models ● Explain the importance of following a procedural/staged life cycle

Prescribed reading

Valacich, J.S.; George, J.F. & Hoffer, J. 2015. Essentials of systems analysis and design, global edition. 6th edition. Pearson Education. Chapter 1.

Introduction This unit will introduce you to information systems analysis and design, including system characteristics and components, system concepts and the SDLC. Traditional and agile methodologies are also discussed.

Information systems analysis and design Information systems analysis involves focusing on the business problem and the requirements necessary to develop a system that will meet those system requirements. Information systems design focuses on the technology that will be applied to implement a solution to the business problem.

Frederick Brooks, author of a well-known software engineering paper titled “No Silver Bullet – Essence and Accidents of Software Engineering”, states that “there is no silver bullet – there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity" (Brooks, 1995).

This statement from Brooks (1995) is still true today. There is no one single method that will ensure success during information systems development. We can, however, use the tools and techniques available to us to enhance our chances of successfully completing a systems development project.

System definition and characteristics A system is like a bicycle. It consists of a group of components working together to achieve a specific goal. The goal of a bicycle is to get from point A to B. If one component should be removed, for example – the front wheel, the bicycle could not achieve its goal.

System “A system is an interrelated set of business procedures (or components) used within one business unit, working together for some purpose” (Valacich, George & Hoffer, 2015:32).

There are seven characteristics of a system, namely:

1. Components (sub-systems): A system consists of components working together towards achieving a goal. 2. Interrelationships: The components are interrelated and have an effect on each other. 3. Boundary: A system has a boundary to indicate what will be included and what will be excluded from the system in terms of requirements. Everything that is included in the system will be developed. 4. Environment: The external environment that interacts with the system, which is outside the system. 5. Interfaces: This is the point of contact between the system and its environment. 6. Input: A system receives input from its environment to process it.

7. Output: A system processes input into output which is returned to its environment.

Figure 1 shows seven system characteristics:

Figure 1 – Seven system characteristics Source: Valacich et al. (2015:33)

System concepts A useful method during systems analysis is to break down a system into its sub-systems in order to obtain an increased understanding of the system as a whole.

Decomposition Decomposition entails breaking a system up into smaller, more manageable components or sub-systems. The main reason for decomposing a system is to understand the different sub- systems for improved analysis.

Systems analysts use decomposition to do the following to break the system into smaller, more manageable sub-systems and to study and analyse one sub-system at a time. By analysing the sub-systems in isolation, the systems analyst increases their understanding of the inner workings of the system as a whole.

Figure 2 illustrates an example of a decomposition diagram to analyse and understand a library information system:

Figure 2 – A library information system: decomposition diagram Source: Visagie (2015)

Modularity Modularity is the process of dividing a system into modules to simplify the design process. For example, studying the components of the library system in Figure 4, one can see how decomposition aids to understand the entire system.

Coupling Coupling refers to sub-systems which are dependent on each other. All the sub-systems need to work in order for the total system to work. For example, without a “return book” sub- system, the stock report sub-system will not be able to produce accurate stock reports.

Cohesion Cohesion refers to the extent to which a sub-system performs a single function, for example – the stock report that the system should be able to generate.

Group activity Create a decomposition diagram for a student attendance management information system. The lecturer will facilitate a group discussion session.

Information system components The main focus of information systems analysis and design is to create a new system for an organisation or to improve or upgrade an existing information system.

Example New information system A new library is currently using a paper-based system and needs an information system to automate and manage the processes of borrowing and returning of books.

Improving an existing information system An existing clothing retail store needs to update its website to support e-commerce for customers to order and pay securely for clothes online.

An information system consists of the following components:  Hardware  Specific job roles  Controls  Users (people)  Documentation and training manuals  System software

Figure 3 illustrates these components:

Figure 3 – Components of a CBIS (Computer-Based Information System) application Source: Valacich et al. (2015:31)

It is vital that systems analysts understand the software engineering process. By using appropriate methodologies, techniques and tools (Figure 4), the systems analyst and development team will increase their chances of developing a well-functioning information system.

Figure 4 – The software engineering process Source: Valacich et al. (2015:31)

A technique is a specific way of carrying out a task to achieve a goal, whereas a tool is used to carry out the technique. A methodology is like a framework being applied, consisting of stages, to achieve an overall outcome.

Methodologies A sequence of step-by-step approaches that help develop the information system (Valacich et al., 2015:31).

Techniques Processes that the analyst follows to ensure thorough, complete, and comprehensive analysis and design (Valacich et al., 2015:31).

Tools Computer programs that aid in applying techniques (Valacich et al., 2015:31).

Example In the construction industry, a technique would be to design the foundation of a new building. The software used to aid in this design process would be the tool used by architects/designers. A chosen methodology or framework typically used in foundation engineering will then be applied by the team.

The SDLC (Systems Development Life Cycle) Systems analysts apply the SDLC, which is a logical process, to develop information systems. Each organisation uses a slightly different version, but the overall approach is very similar. The process follows through a series of stages or phases, and once complete, a high-quality information system that works effectively is produced. The SDLC and its phases (steps) are shown in Figure 5:

Figure 5 – SDLC Source: Valacich et al. (2015:39)

An information system, will at some stage during its life, reach a point of obsolescence, where an upgrade or overall improvement is required. This is when the methodology is used to improve the system or to invest in a new information system to solve the business problem or opportunity. Some organisations develop their own unique methodologies, based on the typical SDLC, if the methodologies available do not fully suit their needs.

1.5.1 Phase 1: systems planning and selection The information system department receives many system requests, as individuals and departments identify the need for new or enhanced systems. A systems analyst should analyse all the information systems currently used and needed in an organisation. The analyst has to prioritise possible system development projects and identify the most feasible project to continue with. It is important to determine the scope of these projects. A feasibility analysis is usually carried out, including a SWOT analysis, to analyse the strengths (S), weaknesses (W), opportunities (O) and threats (T) of a proposed system. An argument is then presented about whether or not the potential project should be continued.

1.5.2 Phase 2: systems analysis The systems analyst has to study and analyse the system that is currently in place to understand what the new system should be able to solve. The aim is to construct logical models of the system, focusing on the “what” and not on the “how”. It is important to determine the requirements by eliciting these from the stakeholders.

The requirements should then be structured, analysed and selected, which will help identify the system boundary (what is included and excluded from the system).

1.5.3 Phase 3: systems design The aim of systems design is to work from the requirements to create a set of logical and physical design specifications which will be used during the next phase to construct the system. Logical design focuses on the “what” and physical design, on the “how”. During physical design, a technical specification document is produced, stating the input and output requirements, user interfaces, system architecture, and so on.

1.5.4 Phase 4: systems implementation and operation The system is constructed (coded) according to the system design specifications. Testing is conducted to fix errors and ensure that the quality of the system is up to standard. The end-users receive training, and system documentation is handed over to the customer; this includes user manuals, technical manuals, etc. The conversion plan should also be carried out to oversee a smooth and effective conversion from the old to the new system.

System life cycle models “Sequential development” refers to a method whereby one phase flows to the next phase, and the one phase cannot begin until the previous phase has been completed. This approach is often called the “traditional” or “waterfall development approach”.

Agile software development was a reaction to the limitations of the traditional methodologies. Agile methodologies emerged in the late 1990s. There was a need for more adaptive methodologies, especially around changing requirements. In 2001, the Agile Manifesto was compiled by a group of programming methodology practitioners who formed the Agile Alliance, as it is known today. They have created the following four values and state that “while there is value in the items on the right, we value the items on the left more” (Agile Alliance, 2015):

 Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan

Useful website Article title: “Making the case for agile in the enterprise.” Author: Mack, J.

Link: http://www.cio.com/article/2938926/agile- development/making-the-case-for-agile-in-the-enterprise.html See Bibliography for more detail.

The traditional methodology (Waterfall model) and some agile models and techniques will be discussed in the following sections.

1.6.1 Waterfall model There are many variations of the Waterfall model. The following Waterfall model version consists of six phases (Figure 6):  Phase 1: Project initiation  Phase 2: Analysis  Phase 3: Design  Phase 4: Development  Phase 5: Implementation  Phase 6: Review and closure

Figure 6 – The Waterfall model Source: Visagie (2015)

Each completed phase produces a tangible product or deliverable and should be treated as a milestone used to measure the probability of a successful product. The next phase will not start until the previous phase has been completed successfully. Figure 6 shows the Waterfall model.

This model should be used when the requirements are well defined and stable; structure and control are required during the systems development process and system documentation is important.

1.6.2 Prototyping Prototyping is used to construct a scaled-down version of a system. This version is then analysed, designed, developed and tested. User feedback is obtained early on during systems development, and by following this approach, developers can make improvements as soon as these improvements are identified, to ensure a high quality end product. Prototyping is an iterative process, meaning that the system is developed in small iterations; thereafter user feedback is obtained and incorporated into the next iteration. The developers and users thus work very closely together.

1.6.3 (CASE) Computer-Aided Software Development tools CASE tools are automated software tools used by systems analysts to develop information systems. Valacich et al. (2015:45) highlight the following general types of CASE tools:

 Diagramming tools  Computer display and report generators  Analysis tools  Repository  Documentation generators  Code generators

Diagramming tools are used by systems analysts to create various types of diagrams, including DFDs (Data Flow Diagrams), ERDs (Entity Relationship Diagrams), and so on. Some of the well-known diagramming tools are IBM System Architect, Microsoft Visio and SmartDraw. Figure 7 is a screenshot of the SmartDraw official website. Many mobile application versions are also available for creating diagrams, like the SmartDraw and Draw Express Lite apps. There are also open source diagramming tools, available from the Internet. It is important to study the availability and functionality of a diagramming tool before making a decision to use it.

Figure 7 – SmartDraw official website screenshot Source: SmartDraw (2015)

Individual activity Study the functionality of Microsoft Visio Standard 2013, and spend at least 15 minutes familiarising yourself with this drawing tool. The lecturer will facilitate a brief practical session.

1.6.4 JAD (Joint Application Development) JAD is a structured process in which users, managers and systems analysts work together for a couple of days in a series of intensive meetings to review system requirements. The requirements review process is conducted more efficiently by using a joint effort. Figure 8 is of a typical JAD session room layout:

Figure 8 – JAD session: typical room layout Source: Valacich et al. (2015:166)

1.6.5 RAD (Rapid Application Development) RAD was a response to the structured methods developed in the 1970s and 1980s to cater for rapid delivery of software and changing requirements. RAD emphasises the importance of ongoing user involvement through the use of prototyping to obtain user feedback throughout the development process. By obtaining user feedback from an early stage, the chances of meeting the customer’s requirements are increased. Figure 9 illustrates RAD compared to the standard SDLC:

Figure 9 – RAD compared to standard SDLC Source: Valacich et al. (2015:46)

Barry Boehm developed the first RAD alternative, known as the “spiral model”. The spiral model incorporates and highlights the importance of risk analysis in the ongoing phases of systems development. Risk is thus analysed and solved every time the spiral goes through the risk analysis step. Figure 10 shows the spiral model:

Figure 10 – The Spiral model Source: Boehm (2000)

Individual activity Do research on the Spiral model by studying the workshop report by Boehm (2000), titled ‘Spiral development: experience, principles, and refinements’. Link: http://www.sei.cmu.edu/reports/00sr008.pdf Further details on the source can be found in the bibliography of this guide. The lecturer will facilitate a discussion session.

Group activity Do research on SCRUM (an agile methodology), and complete the table below. The lecturer will facilitate a group discussion session.

Term Description SCRUM Scrum master Scrum meeting Product backlog Sprint backlog Burndown chart

Concluding remarks This unit introduced you to information systems analysis and design, including system characteristics and components, system concepts and the SDLC. Traditional and agile methodologies were also explored.

The next unit will discuss the importance of feasibility studies and basic fact- finding techniques used for requirements elicitation.

Self-assessment

Test your knowledge

1. Describe the phases of the SDLC.

2. Identify the components of an information system.

3. Define decomposition, modularity, coupling and cohesion.

4. Evaluate the different life cycle models.

Unit 2: Feasibility studies and fact-finding techniques

Unit 2 is aligned with the following learning outcome and assessment criteria:

Learning outcome LO2 Discuss the importance of a feasibility study

Assessment criteria AC2.1 Discuss the components of a feasibility report AC2.2 Assess the effect of different feasibility criteria on a systems investigation

Learning objectives After studying this unit, you should be able to:

 Understand the purpose of conducting a feasibility study  Evaluate the different feasibility criteria as part of a systems investigation  Identify fact-finding techniques for requirements elicitation

Prescribed reading

Valacich, J.S.; George, J.F. & Hoffer, J. 2015. Essentials of systems analysis and design, global edition. 6th edition. Pearson Education. Chapters 4 and 5.

Introduction When an organisation needs to acquire a new system, various options are available. The organisation could develop the system itself, buy the system from a software supplier or outsource the development of the solution to an IT consulting organisation. Organisations should not consider a systems development project if the project is not going to be feasible.

This unit will focus on conducting a feasibility study and applying fact-finding techniques for requirements determination.

Feasibility study The information system department receives many system requests. In order to prioritise these requests, a feasibility study is conducted to determine which systems development option would be the most feasible to meet the business need. Options may range from developing a system in-house to buying the software off the shelf. It is better to terminate a project than to continue with a project that is not feasible. It is thus essential to determine whether a project will be feasible.

There are four basic types of feasibility used to measure the overall feasibility of the system development options.

2.1.1 Operational feasibility This category reviews how the introduction of a new system will affect day-today operations and how well the solution will meet the systems requirements. Another operational factor to consider is whether there will be resistance from users that will affect possible system benefits.

2.1.2 Technical feasibility Technical feasibility is the process of assessing the availability of technical resources and expertise to obtain or develop the system. For a systems development project, the resources refer to the availability of analysts, programmers and tools (software to develop the system), etc. Expertise refers to the experience and skills required to obtain or develop the system.

Example If an organisation does not have programmers to develop a system, outsourcing could be considered. If outsourcing is not an option, owing to cost, the project might not be technically feasible. Another example could be that the technical tools are not available for a specific project. This might also cause the project to not be technically feasible.

2.1.3 Economic feasibility This category focuses on costs and benefits, and the purpose is to determine whether the benefits will be more than the costs. Organisations want to make investments in instances where the benefits will outweigh the costs. It is important to show cost calculations as part of economic feasibility. The following techniques are usually carried out to support this feasibility category:

 NPV (Net Present Value)  ROI (Return On Investment)  BEA (Break-Even Analysis)

2.1.4 Schedule feasibility This category reviews whether the timeframe is reasonable.

There are no best feasibility types to choose during a feasibility study; the types used depend on the situation and the type of system being considered for development. Valacich et al. (2015:128) explain two other types of feasibility that could also be included during the feasibility analysis process:

 Legal and contractual feasibility: This category reviews the legal and contractual consequences linked to the system being developed. The system might have to adhere to new laws and regulations of an industry.  Political feasibility: The focus is on the different viewpoints of all the stakeholders towards the system development project. Different levels of stakeholder power might affect the project.

After reviewing the outcome of a feasibility study, management will be more informed to make a decision as to whether or not to continue with the systems development project.

SWOT analysis SWOT analysis is a useful method to analyse an organisation, a specific project or any other situation in an organisation. A SWOT analysis should be performed during the same time as a feasibility study. Strengths and weaknesses are internal and opportunities and threats are external to the topic analysed with SWOT.

The following example focuses on conducting a SWOT analysis for an organisation:

 Strengths refer to what an organisation does well and what it does that makes it better than its competitors in a market.  Weaknesses are those aspects which can be improved in an organisation.  Opportunities are those aspects which an organisation could pursue to improve the organisation and to identify new trends in the market.  Threats refer to obstacles that the organisation faces and what competitors are doing better in the market. It can also include economic occurrences or advancements in technology.

Useful website YouTube video title: “SWOT Analysis: Analyze Your Organization’s Strengths, Weaknesses, Opportunities, and Threats.” Link: https://www.youtube.com/watch?v=S2GZOsemVNk

The following example focuses on conducting a SWOT analysis for an information system:

 Strengths o The system is very user-friendly o The system improves employee productivity  Weaknesses o The system’s security could be improved o The system is not scalable  Opportunities o Advancements in technology to upgrade the system o Integrating the system with other organisational systems  Threats o A competitor implements a similar, more advanced system during the development of the system o The system might be hacked

Group activity Conduct a SWOT analysis on any high school in your area. Complete the table below. One example for each component of SWOT is provided in the table, and the group should include another example for each component. The lecturer will facilitate a group discussion session.

I n Strengths Weaknesses t a. The school has many teachers a. The school building e with adequate teaching needs maintenance r experience work n b. ______b. ______a l E Threats x Opportunities a. Other high schools in t a. The development of a student the area offering e attendance management system better educational r b. ______services n b. ______a

Feasibility report Organisations create their own templates to compile a feasibility report. A typical feasibility report will consist of the following content:

 Cover page: Should include project name, author’s details, version number, etc.

 Executive summary: Could include an overview of the problem or opportunity, the scope and recommendations.  Document introduction: Could include the purpose of the document, abbreviations used and references to other documentation.  Background: Could include an explanation of the problem or opportunity and the aim of the new solution.  Goals: Could include the goals or objectives that should be reached.  Scope: Could include the boundary and constraints and assumptions.  Analysis of options: In this section all the options are analysed according the feasibility criteria by using a weighting and scoring system.  Recommendation: The recommendation is made based on the outcome of the analysis of options.

Individual activity Conduct research by searching for and studying the headings used in any feasibility report template on the Internet. The lecturer will facilitate a discussion session.

Fact-finding techniques To complete any project successfully, the client’s requirements should be met or exceeded. In order to achieve this, gathering the requirements becomes an important aspect of a project. Various techniques could be applied to elicit requirements. Most of the time, it will not be time or cost-effective to apply many or all of the techniques for one project. For this reason, the systems analyst must select techniques that are appropriate for the situation under study.

It is important that the person carrying out the technique has the necessary skills and experience to do so; otherwise, the technique might not be as effective as it could be. It is important that the technique used provides useful information for the development team – to have an increased understanding of the domain and subsequent problem or opportunity that led to the initiation of the systems development project.

A systems development project involves gathering requirements from the stakeholders. IS professionals have knowledge and experience in systems development, but the domain is best known by the people who actually work in the domain and environment on a daily basis. For this reason, it is very important to involve the right people in the requirements gathering process.

Some techniques are more effective than others, depending on the type of information and the target group used to obtain the information from.

Example To conduct research on whether a new fitness club (gymnasium) should be opened in a small town, it would not be cost-effective to interview all the people living in the town. This would also be too time-consuming. It would be more effective to distribute a well-designed questionnaire to a sample of people living in the town.

Traditional methods for determining requirements

2.5.1 Interviews An interview is a face-to-face meeting between two or more people in which an interviewer seeks to obtain information from the interviewee to understand a phenomenon. The interviewer documents the interview responses and then analyses the overall responses to make conclusions or recommendations. Interviews can be time-consuming, but advantages are that you can elaborate on the responses if you need more information, and you are able to observe the interviewee’s non-verbal cues. There are different types of interviews:

 Structured: A pre-defined list of questions is prepared, and only those questions are used during the interview.  Semi-structured: A list of questions is prepared, but if other questions emerge during the interview, these are discussed and included in the interview findings.  Unstructured: There is no pre-defined list of questions, and the interviewer discusses topics with the interviewee in an open-ended method.

According to Valacich et al. (2015:155), the following guidelines should be followed for conducting effective interviews:

 Plan the interview  Be neutral  Listen and take notes  Review notes  Seek diverse views

Group activity You are required to interview ten third-year IT students from your campus to obtain information from them in order to compile a document containing student advice for new first- year IT students. Create a list of interview questions that could be used during these interview sessions. The lecturer will facilitate a group discussion session.

2.5.2 Observation Observation can be very effective if you need to study people’s behaviour in a natural setting. Observation is a way of eliciting requirements assessing a stakeholder’s work environment. This technique is appropriate when documenting details about current business processes. Some people may behave differently, because they know they are being watched, and behaviour bias is another concern. There are two types of observations:

 Active observation: The observer participates in the observation process and asks questions.  Passive observation: There is no involvement by the observer, and observations are usually made from a distance.

2.5.3 Investigation of documentation Document investigation and analysis is a means to gather requirements by studying available documentation on existing and comparable solutions and identifying relevant information. The systems analyst should identify and consult all likely sources of requirements in the organisation, as this will ensure that most requirements are covered. For this reason, it is vital that an organisation keep its documentation up to date.

This documentation could provide information about the following (Valacich et al. (2015:160):

 Problems with existing systems  Opportunities to meet new needs  Organisational direction  Title and names of key individuals  Values of organisation or individuals  The reasons why current systems are designed in a specific way  Data, rules for processing data, and principles

2.5.4 Questionnaires A questionnaire is a way of gathering information from a large amount of people in a relatively short period of time. Respondents are presented with a series of statements and asked for their level of agreement. A set of written questions are prepared, consisting of different types of questions:

 Open-ended questions: There is no prescribed answer, for example – “What did you learn during the end-user training session?”  Closed-ended questions – There is a range of answers from which an individual should select the most appropriate answer. The answers are thus pre-determined and fixed. The following types of questions could be used: o Yes-or-no questions o Multiple-choice questions o True-or-false questions

o Ranking questions

Questionnaire responses that were completed manually on paper can be analysed by capturing the responses into a software tool like Microsoft Excel and generating graphs. Some researchers use online survey tools like SurveyMonkey, where respondents complete the questionnaire online, and the result graphs are processed online and are immediately visible.

Group activity You are required to distribute a short questionnaire to a sample of CTI students to determine whether a sports day should be included in the campus social activity planning. Create a short questionnaire (consisting of five questions) that could be used for this research. The lecturer will facilitate a group discussion session.

Concluding remarks This unit provided you with an understanding of the importance of feasibility studies. An explanation of how to perform a systems investigation was provided as was an explanation of the components of a feasibility report and how to assess the effect of different feasibility criteria on a systems investigation.

The next unit will undertake a systems investigation to meet a business need by using appropriate systems analysis tools and techniques. You will also learn how to create documentation to support a systems investigation.

Self-assessment

Test your knowledge

1. Briefly discuss the components of a SWOT analysis.

2. Explain the different feasibility types.

3. Differentiate between different fact-finding techniques used for requirements elicitation.

Unit 3: Process modelling

Unit 3 is aligned with the following learning outcome and assessment criteria:

Learning outcome LO3 Perform a systems investigation

Assessment criteria AC3.1 Undertake a systems investigation to meet a business need AC3.2 Use appropriate systems analysis tools and techniques to perform a systems investigation AC3.3 Create documentation to support a systems investigation AC3.4 Evaluate how user and systems requirements have been addressed

Learning objectives After studying this unit, you should be able to:

 Understand process modelling terms and symbols used  Construct a context diagram and lower level DFDs (Data Flow Diagrams)

Prescribed reading

Valacich, J.S.; George, J.F. & Hoffer, J. 2015. Essentials of systems analysis and design, global edition. 6th edition. Pearson Education. Chapter 6.

Introduction In many industries, professionals working on new projects have to plan and analyse a situation carefully before developing a solution for it. In the medical profession, doctors have to carefully plan an operation before performing actual surgery on a patient. In the industrial architecture industry, architects plan the project and then analyse and design the project by drawing models (graphical representations) of the building before moving into the construction phase. This trend of planning, analysis and design can thus be found in many industries.

In the IT industry, systems analysts also draw logical and physical models (various diagrams) of the information system before going into the construction phase, where the programmers then build the system according to the specifications completed by the analysts. Drawing diagrams supports analysts to analyse the new system from various perspectives and focus on different aspects. Analysts use modelling software tools (CASE tools) to assist them in constructing complete and consistent diagrams. Various types of diagrams are useful, each focusing on a specific aspect of a system.

Process modelling A DFD is a key tool for modelling the business and system processes. It shows the processes in a system, with its inputs, outputs and data (Whitten & Bentley, 2007:162). A DFD is also called a “process model”, as this type of diagram models processes. A systems analyst usually draws different levels of DFDs. The analyst will break the system down into sub-processes until the lowest level is reached wherein the most detail is captured. This is usually done by constructing a decomposition diagram and then using the decomposition diagram to create DFDs and other diagrams.

A context diagram is the highest level DFD. Lower level DFDs are drawn from the context diagram to analyse the processes in more detail. A systems level DFD is the next level, and the processes can be broken down into sub- processes until the lowest level DFD is drawn, which is referred to as the primitive level DFD.

The following terms are used during process modelling:

 Data flow: Depicts data that are in motion and moving as a unit from one place to another in the system (single piece of data or logical collection of information).  Data store: Depicts data at rest and may represent data in a file folder, computer-based file or notebook. Four actions are usually carried out on data stores. This is referred to as CRUD (Create; Read; Update; Delete). When using Create, Update and Delete, the direction of the data flow will move towards the data store. When using Read (to view data), the direction of the data flow will move towards the process.

 Process: Depicts work or actions performed on data so that they are transformed, stored or distributed. Each process should perform only one activity. A process should always start with a verb.  Source/sink/external entity: Depicts the origin and/or destination of the data. It can be a person, organisation or another system that is external to the system but interacts with it.

Four symbols, developed by Gane and Sarson, are used when constructing DFDs, as shown in Figure 11:

Figure 11 – Four DFD symbols (Gane and Sarson) Source: Valacich et al. (2015:185)

Decomposition diagram Decomposition was discussed in Unit 1: Section 1.3. Systems analysts find it useful to first draw a decomposition diagram to understand the system with its related sub-systems and processes. By breaking the system down into its component parts, the analyst increases their understanding of the system being analysed. Figure 12 is an example of a decomposition diagram for an online cell phone apps store.

Figure 12 – Decomposition diagram example Source: Visagie (2015) & Valacich et al. extra notes (2015: Chapter 6:6-15)

The decomposition diagram helps the analyst to plan the breakdown of sub- systems and processes which can then be used to start drawing the context diagram and the rest of the DFDs. Figure 13 shows the usefulness of the decomposition diagram in identifying sub-systems and processes which can then be used to construct the different levels of DFDs.

Figure 13 – Decomposition diagram and DFD diagram levels Source: Visagie (2015) & Valacich et al. extra notes (2015: Chapter 6:6-15)

Context diagrams (Context DFDs) A context diagram is the highest level DFD, and it shows the system boundary, overall scope, by including one overall process (usually the system name; numbered with zero), external entities, input data flows and output data flows. No data stores are shown on a context diagram. This diagram gives an overview of the entire system scope and thus paints a bigger picture of the system.

Figure 14 is an example of a context diagram for an online cell phone apps store. Take note that there is only one process (the system name), and it is numbered with a zero (0). No data stores are shown on a context DFD – only one main process, sources/sinks (external entities) and data flows.

Figure 14 – Context diagram example Source: Valacich et al. extra notes (2015: Chapter 6:6-15)

DFDs A DFD shows the system broken down into processes and sub-processes – the data flowing in and from the processes, where the data is stored, as well as the origin (external entities/sources/sinks) of the input and output data flows.

Systems analysts use DFDs to analyse and understand the system being investigated. Analysts can also use DFDs to explain the system and their understanding of it to the customer and users for feedback and validation, as the people who work in the domain usually understand the processes very well.

Figure 15 is an example of a DFD for an online cell phone apps store, constructed from the context diagram shown in Figure 14. Three processes have been identified in the decomposition diagram in Figure 12 and are indicated by the numbers 1.0, 2.0 and 3.0. Note that data stores are shown on Level-0 and lower level DFDs. In this example, there is only one data store (D1: App Sales History):

Figure 15 – DFD example Source: Valacich et al. extra notes (2015: Chapter 6:6-15)

Several data flow diagramming rules that should be followed when creating DFDs, as indicated in Figure 16:

Figure 16 – DFD rules Source: Valacich et al. (2015:190)

Valacich et al. (2015:196-198) highlight five guidelines for drawing DFDs:

1. Completeness: The extent to which all necessary components of a DFD have been included and fully described. 2. Consistency: The extent to which information contained on one level of a set of nested DFDs is also included on other levels. 3. Time consideration: DFDs do not indicate the timing of data flows; therefore, the diagram should be drawn as if the system never started and will never stop. 4. Iterative development: A DFD will most likely have to be redrawn several times – each time getting closer to a good approximation to the system being modelled. 5. Primitive DFDs: This focuses on when to stop decomposing processes; it is the lowest level of decomposition for DFDs.

3.4.1 Balancing DFDs When the systems analyst decomposes a DFD, the inputs to and outputs from a process should be conserved at the next level of decomposition, as this would ensure the balancing of a DFD. Balancing ensures that DFDs are consistent with other diagrams in the information systems DFD set and that all data flows, data definitions and process descriptions are included. All the sources/sinks (external entities) and data flows on the context diagram should be included in the lower level DFDs drawn. If a data flow is changed, for example – because of an error on the lower level DFD, ensure that the corresponding context diagram is also updated. Consistency is very important as part of balancing all the DFDs drawn on different levels of detail.

3.4.2 DFD mistakes: Black hole, miracle and grey hole The following three mistakes are commonly made when constructing DFDs, and should be avoided:

 Black hole: A process has input flows but no output flows. The example in Figure 17 shows that process 1.0 does not have any outputs.

Figure 17 – Black hole example Source: adapted from Valacich et al. extra notes (2015: Chapter 6:6-15)

 Miracle: A process has output flows but no input flows. Figure 18 shows that process 1.0 does not have any inputs.

Figure 18 – Miracle example Source: adapted from Valacich et al. extra notes (2015: Chapter 6:6-15)

 Grey hole: A process has output which is greater than the sum of its input, or the output does not make sense if one studies the input. The example in Figure 19 shows that the input does not make sense for the output produced.

Figure 19 – Grey hole example Source: adapted from Valacich et al. extra notes (2015: Chapter 6:6-15)

Process modelling exercises

3.5.1 DFD exercise 1

Group activity Create a context diagram and Level-0 DFD by studying the case study and completing the steps. The lecturer will discuss the suggested solution.

Starting with a context diagram, draw as many nested DFDs as you consider necessary to represent all of the details of the patient flow management system described in the following narrative. You must draw at least a context diagram and a Level-0 diagram. In drawing these diagrams, if you discover that the narrative is incomplete, make up reasonable explanations to complete the story. Provide these extra explanations along with the diagrams.

Case study

Dr Frank’s walk-in clinic has decided to go paperless and will use an information system to help move patients through the clinic as efficiently as possible. Patients enter the system at the front desk by providing demographic information to the personnel. If this is the first time the patient has been seen, insurance and basic demographic information is collected from the patient. If they have been seen previously, they are asked to verify the information pulled from the patient registry.

The front desk person then updates the patient registry and ensures that the patient has a chart in the electronic medical records system; if not, a new medical record is started by placing formatted demographics into a blank medical record. The front desk person then enters the medical record ID into the system. Next, a medical technician collects the patient’s health history, weight, height, temperature, blood pressure and other medical information, and combines this information with any information from the patient’s medical record, summarising the information into a health trend. A doctor then sees the patient, prescribes medication or treatment, where appropriate, based on the medical trend, and sends the patient to checkout. The employee at checkout updates the patient’s electronic medical record and provides prescriptions for medications or treatments and a printed record of the health services received.

 Step 1: Identify the system name and number it with a zero.  Step 2: Identify all processes and sub-processes and create a decomposition diagram.  Step 3: Identify the external entities (sources/sinks).  Step 4: Identify all data flowing in and data flowing out.  Step 5: Draw a context diagram.  Step 6: Draw a Level-0 DFD.

3.5.2 DFD exercise 2

Group activity Create a context diagram and Level-0 DFD by studying the case study and completing the steps. The lecturer will discuss the suggested solution.

Case study

Projects, Inc. is an engineering firm with approximately 500 engineers who provide mechanical engineering assistance to organisations, which requires managing many documents. Projects, Inc. is known for its strong emphasis on change management and quality assurance procedures. The customer provides detailed information when requesting a document through a Web portal.

An engineer is assigned to write the first draft of the requested document. Upon completion, two peer engineers review the document to ensure that it is correct and meets all requirements. These reviewers may require changes or may approve the document as is. The document is updated until the reviewers are satisfied with its quality.

It is then sent to the customer for approval. The customer can require changes or accept the document. When the customer requires changes, an engineer is assigned to make the changes to the document. When those changes are made, two other engineers must review them. When those reviewers are satisfied with the changes, the document is sent back to the customer. This may happen through several iterations until the customer is satisfied with the document.

Other exercises The lecturer will distribute more exercises and discuss the suggested solutions in class.

Concluding remarks This unit discussed logical process modelling by discussing context diagrams and lower level DFDs. Process modelling terms and symbols used when constructing DFDs were explained. Rules, guidelines and common mistakes made during DFD construction were discussed, and case studies were applied to practise the construction of context diagrams and lower level DFDs.

The next unit will discuss data modelling.

Self-assessment

Test your knowledge

1. Differentiate between a context diagram and a Level-0 DFD.

2. Discuss the terms that are commonly used during process modelling.

3. Identify three common mistakes that are made when constructing DFDs.

4. List the five guidelines that should be followed when developing DFDs.

Unit 4: Data modelling

Unit 4 is aligned with the following learning outcome and assessment criteria:

Learning outcome LO3 Perform a systems investigation

Learning objectives After studying this unit, you should be able to:

 Understand data modelling terms and symbols used  Construct an ERD (Entity Relationship Diagram)

Prescribed reading

Valacich, J.S.; George, J.F. & Hoffer, J. 2015. Essentials of systems analysis and design, global edition. 6th edition. Pearson Education. Chapter 7.

Introduction Conceptual data modelling focuses on representing an organisation’s data, and the aim is to highlight the rules related to the meaning and interrelationships among an organisation’s data. The main aim of conceptual data modelling is to create an Entity-Relationship Diagram (E-R diagram or ERD).

Definition An ERD (Entity-Relationship Diagram) is a key tool for modelling the systems data and is used to design a relational database (Whitten & Bentley, 2007:163).

An ERD is a detailed, logical, and graphical representation of the entities, associations and data elements for an organisation or business (Valacich et al., 2015:227).

The following are key data-modelling terms which will be discussed in the sections that follow:  Conceptual data model  ERD (or E-R diagram)  Entity type  Entity instance  Attribute  Candidate key  Multivalued attributes  Relationship  Degree  Cardinality  Associative entity

Entities and attributes It is important to understand the terms associated with data modelling. The terms “entity” and “attribute” are important terms used in the construction of ERDs. If you are referred to as an “entity”, your “attributes” would be things like your name, date of birth, hair colour, height, and so on.

3.6.1 Entities

Definition “An entity is a person, place, object, event or concept in the user environment about which the organization wishes to maintain data. An entity type is a collection of entities that share common properties or characteristics and an entity instance is a single occurrence of an entity type” (Valacich et al., 2015:229-230).

Entity types could be grouped into strong, weak and associative entities. Strong and weak entity types will be explained with the following examples:

Example A STUDENT entity is seen as a strong entity type, because it will exist independently of entities such as COURSE or DEGREE.

An ORDER entity could be seen as a weak entity type, because without a CUSTOMER or a PRODUCT, an order will not exist.

An associative entity type links the instances of one or more entity types and has attributes that are specific to the relationship between these entity instances. Thus, new attributes could be formed for the associative entity. Associative entities are created when two entities have a many-to-many relationship which needs to be resolved. This will be discussed further under the relationship section that follows.

The following example distinguishes between the terms “entity”, “entity type” and “entity instance”:

Example Entity: STUDENT Entity type: Strong entity Entity instance 1: “Jack Wilson” Entity instance 2: “Neo Mokoena”

For the purpose of systems analysis, entities are objects of importance in organisations. There are the same entities which are found in many organisations, like EMPLOYEE, but each organisation will have its own unique entities. For example, a higher-education institution will find entities like “student” and “course” important. The following are examples of entities:

 Student  Course  Customer  Order  Product  Stock

3.6.2 Attributes

Definition “An attribute is a named property or characteristic of an entity that is of interest to an organization” (Valacich et al., 2015:230).

The following are some examples of attributes (take note of the use of capital letters in the words used after the first word listed for the attribute):

 studentNumber  employeeName  productColour  departmentName  productWeight  bookAuthor  studentSurname

Example A higher-education institution might be interested in only some characteristics of students. These might include a student’s first name, last name, date of birth, contact number, and so on. The institution is not interested in all characteristics associated with the student entity – only in the attributes that are relevant to the type of information they need to maintain in the information system for the student entity. The institution might want to store attributes like studentNumber (PK), studentFirstName, studentLastName, studentContactNumber, etc.

It is important to name attributes in such a way that it is easy to interpret what the attribute means. Attribute names should not be too long, but should clearly describe the characteristic of the entity.

Example If the analyst identifies a “Date” attribute for an ORDER entity, it is necessary to be more specific as to what date this attribute refers to. The word “Date” can be linked to many attributes, like an order date, a submission date, a date of birth, a resignation date, an appointment date, a salary payment date, etc. For this reason, it is very important to clearly and accurately specify attributes, for example in this case, “orderDate”.

Group activity Create a list of possible attributes for a COURSE entity related to a higher-education institution. The lecturer will facilitate a group discussion session.

It is important to identify an attribute or set of attributes for an entity which uniquely identifies each entity instance of an entity type. This is why organisations create membership numbers or customer identification numbers, or why higher-education institutions use student numbers, as no two students will have the same student number.

This unique identifier is unique for each entity instance and is referred to as a PK (Primary Key) or a candidate key. It is important to identify a candidate key that will not change over its lifetime. Choosing “age” as a candidate key is not a good choice, as a person’s age will change over time. If organisations struggle to identify candidate keys from the attributes identified, they create a new attribute as a PK, for example – a customer membership number captured at a fitness club.

Another important key is an FK (Foreign Key). A FK is normally the PK from the main entity that is added to another entity. The FK is explained with the following example.

Example If a customer places an order, it is important to know which order the customer is linked to. Thus, by displaying the customer number on the order slip, the customer will be linked to that order. The customerNumber (PK) appearing on the order slip is then referred to as an FK (Foreign Key) as part of the ORDER entity.

Organisations have to pay for database storage, and the more attributes that are created for data storage, the more costly the system will be. The aim is to not take up unnecessary space in the database. For this reason, it is important to not include attributes which can be automatically calculated by the system. If the analyst needs to include an “Age” attribute for an EMPLOYEE entity, the system can be programmed to automatically calculate an employee’s age by using the “dateOfBirth” attribute and the current date.

An attribute that can have more than one value for an entity instance is referred to as a multivalued attribute. If a higher-education institution wants to store their employees’ qualifications, an attribute called “lecturerDegree” will be created. It is possible for a LECTURER entity to have obtained more than one degree; thus, “lecturerDegree” will then be called a multivalued attribute, as it may contain more than one value for each entity instance. A multivalued attribute is shown in these brackets: {}, for example {lecturerDegree}.

ERD relationships: degree, cardinality and naming

3.7.1 ERD relationship Relationships indicate the significant real-world associations between various entities. In other words, relationships show how one entity is associated with another. Relationships between entities are usually seen when evaluating an organisation’s business rules. An example of a business rule in a library could be that a member is not allowed to borrow a book if outstanding fees are not settled.

Relationships always flow in two directions and are, therefore, bi-directional. The following explains this concept:

 An employee must work for a department.  A department may consist of one or more employees.

In such a case, there is a relationship between the EMPLOYEE and DEPARTMENT entities stating that an employee must work for a certain department and that a department could consist of one or more employees.

3.7.2 Relationship degree, cardinality and naming A relationship degree shows the number of entity types that participate in the relationship. There are three common relationships used in data modelling, as shown in Figure 20: unary, binary and ternary.

Figure 20 – Three common relationship degrees Source: Valacich et al. (2015:229)

Example Unary: An EMPLOYEE manages an EMPLOYEE (because a manager is also an employee). Binary: An EMPLOYEE works for a DEPARTMENT. Ternary: A CUSTOMER places an ORDER with a SALESCLERK.

Cardinality refers to the amount of instances of one entity that can be associated with another entity. A relationship can be identified between a CUSTOMER and an ORDER, as shown in Figure 21.

If the minimum cardinality of ORDER is one, then ORDER is a mandatory participant in the relationship. However, if the minimum cardinality for CUSTOMER can be zero, then CUSTOMER is an optional participant in the relationship. A customer cannot be forced to place an order (“may”).

The degree is thus optional or zero for the customer. A customer may place zero or many orders. An order must be placed by one customer for the order to exist. By studying the notation used to show “many”, one can recognise why this is known as the “Crow’s Foot Notation”.

Figure 21 –Example of cardinality Source: adapted from Valacich et al. (2015:244)

Cardinality can be included in more detail as part of the relationship if such information is provided by the organisation. For example, if the organisation has a business rule in place that only a maximum of ten orders per customer is allowed, the cardinality will be noted as shown as [0;10] in Figure 22:

Figure 22 – Example of cardinality (minimum and maximum specified) Source: Visagie (2015) & adapted from Valacich et al. (2015:244)

It helps to understand the ERD when relationships are named. The name of a relationship should not be too long and should capture the essence of the relationship as shown in Figure 15: A customer “places” an order and an order “is placed by” a customer. Some verbs fit the situation better than others, for example – it will not make sense to state “A customer ‘asks’ for an order”. The known term used with an order is to “place” an order. For this reason, it helps to read the relationship names aloud in both directions to ensure that it makes sense within the context being analysed.

Constructing an ERD The notation used to construct an ERD involves three constructs: entities, attributes and relationships. These constructs were discussed in the previous sections. Read the following case study, and take note how the process works for constructing an ERD (Valacich et al. extra notes (Chapter 7:7-18), 2015).

Case study

A performance venue hosts many concert series a year. Performers have a name and perform several times in a concert series (each constituting a performance with a different date). Concert series have one or more performers and have a name and a specified seating arrangement. A concert series is held in one (and only one) of several concert halls, each of which has a room number. Represent this situation of concerts and performers with an ERD.

3.8.1 Step 1: Identify the entities  Performer  Concert_Series  Concert_Hall

3.8.2 Step 2: Identify the attributes for each entity Although it is possible to identify more attributes for each entity, in this example only some attributes are identified.

 Performer o Performer_ID o Name  Concert_Series o Series_ID o Name  Concert_Hall o Concert_Hall_ID o Room#

3.8.3 Step 3: Identify the relationships, including the degrees and cardinality  A performer may be involved in one or many concert series.  A concert series may have one or many performers associated with it.  A concert hall may host zero or many concert series.  A concert series is associated with one concert hall.

Take note that there is a many-to-many relationship between “Performer” and “Concert_Series” which needs to be resolved with an associative entity called “Performance”. This new entity could have an attribute such as “Date” of performance. The two primary keys of the linked entities will also be included for the “Performance” entity.

3.8.4 Step 4: Name the relationships It is important to name the relationships, although relationship naming is not included in this activity. It helps to read the relationships aloud in both directions to confirm whether the relationship names make sense in the business domain being studied.

3.8.5 Step 5: Draw the ERD

Figure 23 – Example ERD Source: notes from Valacich et al. (2015: Chapter 7:7-18)

Data modelling exercises

3.9.1 ERD exercise 1

Group activity Create an ERD by studying the case study and completing the steps. The lecturer will discuss the suggested solution.

Case study

Draw an ERD for a patient appointment system. Consider the entities patient, patient appointment, doctor, prescription and pharmacy. Identify and depict the cardinality of each relationship. Also identify the attributes and candidate key (primary key) of each entity.

 Step 1: Identify the entities (already done in case study).  Step 2: Identify the attributes for each entity.  Step 3: Identify the relationships, including the degrees and cardinality.  Step 4: Name the relationships.  Step 5: Draw the ERD.

3.9.2 ERD exercise 2

Group activity Create an ERD by studying the case study and completing the steps. The lecturer will discuss the suggested solution.

Case study

A restaurant chain has several store locations in a city (with a name and ZIP code stored for each), and each is managed by one manager. Managers manage only one store. Each restaurant location has its own unique set of menus. Most have more than one menu (e.g. lunch and dinner menus). Each menu has many menu items, and items can appear on multiple menus and with different prices on different menus. Represent this situation of restaurants with an E-R diagram.

 Step 1: Identify the entities.  Step 2: Identify the attributes for each entity.  Step 3: Identify the relationships, including the degrees and cardinality.  Step 4: Name the relationships.  Step 5: Draw the ERD.

Other exercises The lecturer will distribute more exercises and discuss the suggested solutions in class.

Concluding remarks This unit discussed logical data modelling by explaining ERDs. Data modelling terms and symbols used when constructing ERDs were explained. Case studies were applied to practise the construction of ERDs.

Self-assessment

Test your knowledge

1. Define an entity, entity type, entity instance, attribute, primary key and foreign key.

2. Explain ERD relationships, including the degree, cardinality and naming.

3. Identify the steps that should be followed to construct an ERD.

Glossary

A named property or characteristic of an entity that is of interest to Attribute an organisation. Black hole A process has input flows but no output flows. Candidate key A unique identifier for each entity instance. The amount of instances of one entity that can be associated with Cardinality another entity. Automated software tools used by systems analysts to develop CASE tools information systems. Cohesion The extent to which a sub-system performs a single function. The highest level DFD, and it shows the system boundary, overall scope, by including one overall process (usually the system name; Context diagram numbered with zero), external entities, input data flows and output data flows. Coupling Sub-systems which are dependent on each other.

Depicts data that are in motion and moving as a unit from one place Data Flow to another in the system. Depicts data at rest and may represent data in a file folder, Data store computer-based file or notebook. Breaking a system up into smaller, more manageable components or Decomposition sub-systems. The main reason for decomposing a system is to understand the different sub-systems for improved analysis. It helps the analyst to plan the breakdown of sub-systems and Decomposition diagram processes which can then be used to start drawing the context diagram and rest of the DFDs. DFD (Data Flow A key tool for modelling the business and system processes. It shows Diagram) the processes in a system with its inputs, outputs and data. A means to gather requirements by studying available Document investigation documentation on existing and comparable solutions and identifying relevant information. This feasibility category focuses on costs and benefits and the Economic feasibility purpose is to determine whether the benefits will be more than the costs. A person, place, object, event or concept in the user environment Entity about which the organisation wishes to maintain data. A collection of entities that share common properties or Entity type characteristics. Entity instance A single occurrence of an entity type. ERD (Entity A detailed, logical, and graphical representation of the entities, Relationship Diagram) associations and data elements for an organisation or business. A study conducted to determine which systems development option Feasibility study would be the most feasible to meet the business need. FK (Foreign Key) The PK from the main entity that is added to another entity. A process has output which is greater than the sum of its input or Grey hole the output does not make sense if one studies the input. A face-to-face meeting between two or more people where an Interview interviewer wants to obtain information from the interviewee to understand a phenomenon. A structured process in which users, managers and systems analysts JAD (Joint Application work together for a couple of days in a series of intensive meetings Development) to review system requirements.

This feasibility category reviews the legal and contractual Legal feasibility consequences linked to the system being developed. A sequence of step-by-step approaches that help develop the Methodologies information system Miracle A process has output flows but no input flows. The process of dividing a system into modules to simplify the design Modularity process. An attribute that can have more than one value for an entity Multi-valued attribute instance. A way of eliciting requirements assessing a stakeholder’s work Observation environment. This feasibility category reviews how the introduction of a new Operational feasibility system will affect day-to-day operations and how well the solution will meet the systems requirements. PK (Primary Key) A unique identifier for each entity instance. This feasibility category focuses is on the different viewpoints of all Political feasibility the stakeholders towards the system development project. Depicts work or actions performed on data so that they are Process transformed, stored, or distributed. Used to construct a scaled-down version of a system. This version is Prototyping then analysed, designed, developed and tested. A way of gathering information from a large amount of people in a Questionnaire relatively short period of time. A response to the structured methods developed in the 1970s and RAP (Rapid Application 1980s to cater for rapid delivery of software and changing Development) requirements. Indicates the significant real world associations between various Relationship entities. Relationship degree Shows the number of entity types that participate in the relationship This feasibility category reviews whether the timeframe is Schedule feasibility reasonable. A logical process followed to develop information systems. The SDLC (Systems process follows through a series of stages or phases, and once Development Life complete, a high-quality information system that works effectively, is Cycle) produced. Depicts the origin and/or destination of the data. It can be a person, Source/sink/external organisation or another system that is external to the system but entity interacts with it. Highlights the importance of risk analysis in the ongoing phases of Spiral model systems development. A useful method to analyse an organisation, a specific project or any SWOT analysis other situation in an organisation. An interrelated set of business procedures (or components) used System within one business unit, working together for some purpose. The process of assessing the availability of technical resources and Technical feasibility expertise to obtain or develop the system. Techniques Processes that the analyst follows to ensure thorough, complete, and comprehensive analysis and design. Tools Computer programs that aid in applying techniques. Waterfall model A traditional systems development methodology.

Bibliography Agile Alliance. 2015. [Online] Available at: http://www.agilealliance.org/ [Accessed: 10 September 2015].

Boehm, B. 2000. Spiral development: experience, principles, and refinements. Spiral Development Workshop February 9. [Online] Available at: http://www.sei.cmu.edu/reports/00sr008.pdf [Accessed: 10 September 2015].

Brooks, F.P. 1995. No silver bullet-essence and accidents of software engineering. [Online] Available at: http://worrydream.com/refs/Brooks- NoSilverBullet.pdf [Accessed: 10 September 2015].

Mack, J. 2015. Making the case for agile in the enterprise. [Online] Available at: http://www.cio.com/article/2938926/agile-development/making-the-case- for-agile-in-the-enterprise.html [Accessed: 10 September 2015].

SmartDraw. 2015. [Online] Available at: http://www.smartdraw.com/ [Accessed: 10 September 2015].

Valacich, J.S.; George, J.F. & Hoffer, J. 2015. Essentials of systems analysis and design, global edition. 6th edition. Pearson Education. ISBN: 9781292076614.

Whitten, J.L. & Bentley, L.D. 2007. Systems analysis and design methods. 7th edition. Boston: McGraw-Hill Higher Education.

Bibliography Page 59 Contact details

Bedfordview Campus Bloemfontein Campus 9 Concorde Road East, Bedfordview Tourist Centre, 60 Park Avenue, Willows, Bloemfontein P.O. Box 1389, Bedfordview, 2008 P.O. Box 1015, Bloemfontein, 9300 Tel: +27 (0)10 595 2999, Fax: +27 (0)86 686 4950 Tel: +27 (0)51 430 2701, Fax: +27 (0)51 430 2708 Email: [email protected] Email: [email protected]

Cape Town Campus Durban Campus The Brookside Building, 11 Imam Haron Str 1 Lunar Row, Umhlanga Ridge, Durban (old Lansdowne Road), Claremont P.O. Box 20251, Durban North, 4016 P.O. Box 2325, Clareinch, 7740 Tel: +27 (0)31 564 0570/5, Fax: +27 (0)31 564 8978 Tel: +27 (0)21 674 6567, Fax: +27 (0)21 674 6599 Email: [email protected] Email: [email protected] Durbanville Campus East London Campus Kaapzicht, 9 Rogers Street, Tyger Valley 12 Stewart Drive, Berea, East London P.O. Box 284, Private Bag X7 PostNet Suite 373 Tyger Valley, 7536 Private Bag X9063, East London, 5200 Tel: +27 (0)21 914 8000, Fax: +27 (0)21 914 8004 Tel: +27 (0)43 721 2564, Fax: +27 (0)43 721 2597 Email: [email protected] Email: [email protected] Port Elizabeth Campus Nelspruit Campus 50 Murray Street, Nelspruit Building 4, Ascot Office Park P.O. Box 9497, Sonpark, Nelspruit, 1206 Cnr Ascot & Conyngham Roads, Greenacres Tel: +27 (0)13 755 3918, Fax: +27 (0)13 755 3918 P.O. Box 40049, Walmer, 6065 Email: [email protected] Tel: +27 (0)41 374 7978, Fax: +27 (0)41 374 3190 Email: [email protected] Potchefstroom Campus Pretoria Campus 12 Esselen Street, Cnr Esselen Street 22 Umgazi Street, Menlo Park, Pretoria & Steve Biko Avenue, Die Bult, Potchefstroom PostNet Suite A147, Private Bag X18, P.O. Box 19900, Noordbrug, 2522 Lynnwood Ridge, 0040 Tel: +27 (0)18 297 7760, Fax: +27 (0)18 297 7783 Tel: +27 (0)12 348 3060, Fax: +27 (0)12 348 3063 Email: [email protected] Email: [email protected] Randburg Campus Vanderbijlpark Campus 6 Hunter Avenue, Cnr Bram Fischer Drive Building 2, Cnr Rutherford & Frikkie Meyer Boulevards Ferndale, Randburg Vanderbijlpark P.O. Box 920, Randburg, 2125 P.O. Box 6371, Vanderbijlpark, 1900 Tel: +27 (0)11 789 3178, Fax: +27 (0)11 789 4606 Tel: +27 (0)16 931 1180, Fax: +27 (0)16 933 1055 Email: [email protected] Email: [email protected] Group Head Office Management Services Building 44 Alsatian Road, Glen Austin Extension 3, Midrand P.O. Box 1398, Randburg, 2125 Tel: +27 (0)11 467 8422, Fax: +27 (0)86 583 6660 Website: www.cti.ac.za

CTI is part of Pearson, the world’s leading learning company. Pearson is the corporate owner, not a registered provider nor conferrer of qualifications in South Africa. CTI Education Group (Pty) Ltd. is registered with the Department of Higher Education and Training as a private higher education institution under the Higher Education Act, 101, of 1997. Registration Certificate number: 2004/HE07/004. www.cti.ac.za.