Solution Manual For Modern Systems Analysis and Design, 10th Edition by Joseph S Valacich Joey F. Ge

Solution Manual For Modern Systems Analysis and Design, 10th edition Joseph S Valacich Joey F. George Chapter 1-12

Table of Contents Chapter 1 – The Systems Development Environment

1

Chapter 2 – The Origins of Software

8

Chapter 3 – Managing the Information Systems Project

13

Chapter 4 – Identifying and Selecting Systems Development Projects

30

Chapter 5 – Initiating and Planning Systems Development Projects

41

Chapter 6 – Determining System Requirements

58

Chapter 7 – Structuring System Process Requirements

65

Chapter 8 – Structuring System Data Requirements

96

Chapter 9 – Designing Databases

115

Chapter 10 – Designing Forms and Reports

127

Chapter 11 – Designing Interfaces and Dialogues

135

Chapter 12 – System Implementation and Maintenance

143

1 Copyright © 2025 Pearson Education, Inc.

Chapter 1 The Systems Development Environment Chapter Overview Chapter 1 is an overview of the systems development process, as well as an overview of the textbook. This chapter introduces students to the modern approach to systems analysis and design using various methodologies. Students are introduced to several systems development components, including the process and data-oriented approaches to systems development, different types of information systems, and the systems development life cycle.

This textbook is intended primarily for juniors taking a core course in the information systems major, although the book can be adapted for a similar course at the junior college level or for a two-course sequence on analysis and design. Often students are not familiar with the systems development process, different organizational components, or how these components work together. This chapter provides the general organizational context in which systems development takes place.

The text uses the Systems Development Life Cycle (SDLC) methodology (including its associated problems with the traditional waterfall approach) to introduce students to the structured approach in creating new systems. The student is also introduced to other methodologies such as the Agile Methodologies, eXtreme Programming, and Scrum. The text compares and contrasts the new with more traditional methods in an effort to show both the advantages and limitations of these methods.

Chapter 1 introduces students to visual and emerging development tools. CASE tools are used to apply an engineering approach to systems development and can support each phase of the SDLC.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter.

From an instructor’s point of view, the objectives of this chapter are to: 1. Define and discuss the modern approach to systems analysis and design from an organizational perspective incorporating techniques, tools, and methodologies.

2. Explain how an organization‘s objectives, structure, and processes are essential in the development of systems to meet their needs.

3. Explain that the SDLC process is not sequential but cyclical and that the order is adaptable as required for different projects; also, to emphasize that often analysts and designers may go backwards to the previous step to complete unfinished products or to correct errors or omissions discovered in the next phase.

4. Explain the difference between the logical design and the physical design as it relates to systems development.

5. Discuss the problems with the waterfall SDLC and explain the different approaches analysts, designers and developers have developed to improve the Systems Analysis and Design process.

6. Discuss Agile methodologies and eXtreme programming and how these compare to the traditional Systems Development Life Cycle (SDLC).

7. Show students that the life cycle is a flexible basis for systems analysis and design and that it 2 Copyright © 2025 Pearson Education, Inc.

can support many different tools and techniques, such as Agile methodologies and eXtreme Programming.

8. Compare and contrast the various development approaches introduced in Chapter 1 and depict how they all use an iterative approach.

9. Finally, explain that the boundaries and divisions of the 5 steps in Figure 1-2 when imposed to explain the steps are neither hard nor fast and that in many real-world situations phases or sub-phases may be combined to improve efficiency and understanding. The cycle is an organizing and guiding principle; however, in companies and software development teams will adapt it to suit their needs for specific projects.

Classroom Ideas 1. Figure 1-1 depicts that methodologies, techniques, and tools drive organizational approaches to systems analysis and design. Ask students to identify the names of methodologies, techniques, and tools. List them on the board under the heading that they suggest; then after they have identified 5 or 6 in each heading, review and emphasize the differences among the three and move any from an incorrect category to the correct one and explain why it is one and not the other.

2. When introducing the systems development life cycle model featured in the textbook, discuss other life cycle models using actual ones from existing organizations. Show that the basic model presented (Planning, Analysis, Design, Implementation, and Maintenance) are broken down into smaller phases by many companies but that in the end they could be categorized into one of the basic five explained. This reinforces to students that no one standard life cycle model exists and the model they will use as a systems analyst will likely differ from the textbook‘s life cycle model. The point is that the life cycle represents activities that must be done; and the phases are a way to introduce, in an organized way, the methods, techniques, tools, and skills necessary for successful systems analysis and design.

3. Provide a brief overview of the activities and outputs from each of the five life cycle phases, based on your own experience or from reading the rest of the textbook. Table 1-1 summarizes the products, outputs or deliverables of each phase based on the in-text descriptions.

4. Ask students to compare Agile methodologies to traditional SDLC (see Table 1-3 Five Critical Factors that Distinguish Agile and Traditional Approaches to Systems Development).

Introduce a case study project where Agile methodologies were employed. Ask students to identify problems that the project ran into using Agile methodologies as well as any benefits gained by this approach.

5. This chapter introduces eXtreme programming. If your students have sufficient background, assign students to programming pairs and have them work on a small programming problem, including testing. Ask students to report upon their experience.

6. Discuss the benefits and organization design including roles for Scrum team members. Ask students to role play a typical sprint.

Answers to Key Terms Suggested answers are provided below.

1. Analysis: The second phase of the SDLC, in which system requirements are studied and structured.

3 Copyright © 2025 Pearson Education, Inc.

2. Application software: Computer software designed to support organizational functions or processes.

3. Design: The third phase of the SDLC, in which the description of the recommended solution is converted into logical and then physical system specifications.

4. Implementation: The fourth phase of the SDLC, in which the information system is coded, tested, installed, and supported in the organization.

5. Information systems analysis and design: The complex organizational process whereby computer-based information systems are developed and maintained.

6. Logical design: The part of the design phase of the SDLC in which all functional features of the system chosen for development in analysis are described independently of any computer platform.

7. Maintenance: The final phase of the SDLC, in which an information system is systematically repaired and improved.

8. Physical design: The part of the design phase of the SDLC in which the logical specifications of the system from logical design are transformed into technology-specific details from which all programming and system construction can be accomplished.

9. Planning: The first phase of the SDLC, in which an organization‘s total information system needs are identified, analyzed, prioritized, and arranged.

10. Systems analyst: The organizational role most responsible for the analysis and design of information systems.

11. Systems development life cycle (SDLC): (SDLC) The traditional methodology used to develop, maintain, and replace information systems.

12. Systems development methodology: A standard process followed in an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems.

Answers to Review Questions 1.1.

Information systems analysis and design is the complex organizational process whereby computer-based information systems are developed and maintained.

1.2.

In the early years of computing, analysis and design were considered an art. However, with the growing importance and changing nature of information technology and its usage in the work environment, work methods have evolved, making analysis and design a disciplined process. The analysis and design of computer-based information systems began in the 1950s with emphasis placed on automating existing processes. All applications were developed in machine language or assembly language and developed from scratch. The 1960s saw the first procedural, or third-generation languages, become available. Computers were still large and expensive, and storage was at a premium. In the 1970s, systems development became more disciplined as many people worked to make it more like engineering. In the 1980s, microcomputers became key organizational tools, the software industry expanded greatly, fourth-generation languages were used more and more to write applications, and CASE tools were developed. In the 1990s, the focus shifted to system integration, and developers were using visual programming environments to design user interfaces. Databases began residing on servers, as well as the application logic. Companies began purchasing enterprise-wide systems and more and more systems development focused on the Internet, particularly the Web. The current focus is on Web-based systems development and wireless components. Additionally, 4 Copyright © 2025 Pearson Education, Inc.

many system implementations use a three-tier design. Currently, companies may assemble their systems using off-the-shelf components or by using application service providers.

1.3.

The five systems development life cycle phases are planning, analysis, design, implementation, and maintenance. During the planning phase, an organization‘s total information system needs are identified, analyzed, prioritized, and arranged. During the analysis phase, requirements are gathered from users. The requirements are then studied and organized with any redundancies eliminated. The output of this phase is a solution recommended by the analysis team. During the design phase, the description of the recommended solution is converted into logical and then physical system specifications.

During the implementation phase, the information system is coded, tested, installed, and supported in the organization. During the maintenance phase, the system is systematically repaired and improved. Another problem was that roles of system users or customers was narrowly defined with users relegated to the requirements determination or analysis phase where it was assumed that all requirements could be specified in advance. In addition, hard dates were set for the early phases and were judged successful if the dates were met leaving little time to incorporate important changes. The end result of these problems is that the focus on deadlines led to systems that did not match users‘.

1.4.

There have been several problems with the traditional waterfall SDLC identified in the literature. One is that the ―downhill‖ nature of the SDLC process treats each phase as separate and complete unto itself and feedback is often ignored, resulting in locking users into requirements that had been previously determined, even though those requirements might have changed. Another problem is that roles of system users or customers were narrowly defined with users relegated to the requirements determination or analysis phase where it was assumed that all requirements could be specified in advance. In addition, hard dates were set for the early phases and were judged successful if the dates were met leaving little time to incorporate important changes. The end result of these problems is that the focus on deadlines led to systems that did not match users' needs and that required increasing development costs.

1.5.

Agile methodologies promote a self-adaptive software development process. While other methodologies focus on roles that individuals play in a project team, Agile methodologies focus more on the individual. As software is developed, the process used to develop it is refined and improved through a review process done by the development team through iteration.

1.6.

eXtreme programming is an approach to software development distinguished by short development cycles, an incremental planning approach, a focus on automated tests written by programmers and customers to monitor the development process, and reliance on an evolutionary approach to development that lasts throughout the lifetime of the system. This methodology uses an evolutionary approach to software development.

Coding and testing are part of the same process and are done by a two-person programming team. Code is tested shortly after it is written and integrated into the system within a few hours of being written. All phases of the life cycle converge into a series of activities based on coding, testing, listening, and designing.

1.7.

Scrum originated in 1995 and is a popular methodology for agile development. Scrum was designed for speed development and multiple functional product releases. The primary unit is the Sprint, which will run for 2-4 weeks. Each Sprint is a complete project, which starts with an eight-hour planning meeting focusing on two questions, namely 1) what will need to be delivered by the end of the Sprint, and 2) how will the team accomplish that work? A Daily Standup 15-minute meeting during the Sprint to 5 Copyright © 2025 Pearson Education, Inc.

evaluate progress made within the previous 24 hours. When the Sprint is completed it is followed by two additional meetings. The first one, the Sprint Review will last 4 hours, while the second one, the Sprint Retrospective, lasts three hours. The three primary artifacts in the Sprint process are: 1) the Product Backlog (an ordered list of everything included in the product), 2) the Sprint Backlog (a subset of the Product Backlog that lists only those items that are to be addressed in a particular Sprint), and 3) the Increment (which is the sum of the Product Backlog items completed during a sprint).

1.8.

A study of Agile in practice has revealed three primary success factors. The first is a delivery strategy resulting in the continuous delivery of working software in short time scales. The second is that by following agile software engineering practices managers and programmers continually focus on technical excellence and simple design. The third is team capability of building projects around motivated individuals. It was also found that agile methods can lead to improved job satisfaction and productivity on the part of programmers.

1.9.

Agile methods would be more likely to be employed instead of a more engineering-based approach when the project or team is relatively small; when the products are neither critical nor safety oriented, and design is relatively simple with relatively minimal documentation necessary; when agile-experts are continuously available in a critical mass; and in environments where the culture is one in which people thrive on chaos and are comfortable with several degrees of freedom.

Answers to Problems and Exercises 1.10.

1.11.

1.12.

The importance of using a systems analysis and design methodology is that a systematic step-by-step approach is taken which, if done correctly, results in a system that has fewer errors and is used with confidence by the users of the system. If shortcuts are taken for quick and easy development there is a greater chance for errors, as well as a system that does not meet user needs. The value of using an engineered approach results in a system that meets user needs while operating the way it was intended and built.

The similarities between the two figures are that they both contain the five phases of the SDLC. Figure 1-2, though, reveals a circular life cycle in which the useful life of one system leads to the beginning of another project that will lead to an improved or new system. Figure 1-3 is looked at as more of a spiral, in which phases are constantly cycling through at different levels of detail based on a Go/No Go axis where a decision is made to go through another cycle.

While Figure 1-2 is circular in design, Figure 1-7 is simply a vertical listing of steps that seem to indicate it is a one-time through methodology that may not necessarily be the case. Many of the same SDLC techniques and tools are used. Many different companies have their own SDLC steps but in the end, they are the same with some breaking them down into smaller sections to meet their own needs. The traditional waterfall life cycle shown by Figure 1-7 has the property of locking users into requirements that had been previously determined, even though those requirements might have changed.

Figure 1-2 reveals a circular life cycle in which the useful life of one system leads to the beginning of another project that will lead to an improved or new system. Figure 1-7 has the same major steps of the SDLC but by converting Figure 1-7 into a circle like Figure 1-2, we can interpret the project as being able to return to an earlier phase if necessary.

6 Copyright © 2025 Pearson Education, Inc.

Guidelines for Using the Field Exercises 1.13.

It should not be too difficult for students to list the various ―systems‖ for an organization, perhaps for their university. These may include standard computer-based information systems, such as a transaction processing system for recording point of purchase sales or for registering for a course. They should also include systems that are not computerbased, such as a physical filing system for receipts or for transcripts. Instruct students to place each of their ―systems‖ on their diagram and show how they (should) interact.

Discuss the diagrams with students and have them evaluate whether they think that the systems interact well with one another. This enables students to determine whether the systems are well integrated (be sure that students have a clear idea on what it means for systems to be integrated). If their diagrams do not reflect well-integrated systems, ask them to draw a new ―proposed‖ diagram in which they would interact in a better fashion.

This is useful to get them thinking in terms of as-is and to-be systems.

1.14.

Urge students to use their imaginations. You might have them imagine what would happen to the system design if one or more of the steps of the SDLC were ignored. For example, have students imagine what would happen if the planning phase was ignored.

They might imagine elegant, costly systems that do not solve the right problem and, as a result, are not used. Alternatively, they might imagine a system where a database is kept redundantly in several different locations, or where information is re-keyed into one part of the system while it already exists in another format in another part of the system. They might describe a system that is lost completely because no proper backup and recovery procedures exist. The useful part of this exercise is that no matter what disasters or problems they imagine, they have probably already happened in one setting or another.

1.15.

This is a useful exercise, particularly for beginning information systems students. This exercise enables students to see how information systems are used throughout an organization. Frequently, in smaller organizations, information systems development is more informal, and the various information systems roles are played by one or a small number of people. It is interesting to see how people in smaller organizations find creative ways to develop and implement technology on a limited budget and with a limited information systems staff. It is also useful to discuss how smaller organizations can integrate with systems outside the organization. For example, investigating how organizations, large and small, connect to credit card companies might provide students with a relevant task. Many instructors also find this is a way to inject service learning into this course as there are many well-deserving organizations out there that cannot afford systems consulting but are desperately in need of systems assistance. Many of these projects could be the foundation for a course-long project that mirrors the concepts being taught in the course.

1.16.

Encourage students to perform a search on the Web using search engines such as Google.

A report or presentation as a deliverable from this exercise might be appropriate.

Encourage students to consider how Agile methodologies differ from engineeringoriented process. The nice thing about presentations to the class is that students have the opportunity to hone their communications skills and knowledge is shared amongst the class.

Journals are an effective teaching and learning tool. It is useful to collect these journals from time to time and provide direct feedback to each student, commenting on their experiences and answering their questions. You might also periodically have students share their journal comments and questions with the rest of the class and use this as fuel for class discussions. Even if students do not share actual comments, have them discuss

1.17.

7 Copyright © 2025 Pearson Education, Inc.

the sources of their comments, such as newspaper articles, conversations with other faculty and students, advertisements, new topics they read in this textbook, or comments made by a parent. It might be interesting to note how students‘ thoughts on systems analysis and design change over the course of the semester. This exercise allows students to practice written communication and retrieval skills that will be necessary as they move out into the world of work and become project leaders and managers.

Chapter 2 The Origins of Software Chapter Overview The primary purposes of Chapter 2 are to show students that not all the software associated with a systems development project is developed in-house, and to emphasize that analysts should consider several design strategies based on the organization‘s resources before choosing one to pursue for further development in design. The secondary purpose is to emphasize that the consideration of a packaged software solution should be done after the analysis efforts are complete, not as a substitute for analysis.

The chapter discusses six sources for software: Information Technology Services Firms, packaged software producers, enterprise-wide solutions (ERP), cloud computing, open-source and in-house development. In addition, this chapter describes the reasoning that should be followed when choosing among the many options available to an analysis team for developing design strategies. The point is that the ―make-versus-buy‖ decision is not a choice of one or the other, but is in reality a spectrum of choices ranging from make at one end and buy at the other.

Just as important, more choices these days are made toward the buy end of the scale. The request for proposal (RFP) is shown as an important element to understanding how analysis and design 8 Copyright © 2025 Pearson Education, Inc.

requirements must be translated into a document that external source organizations can review for bid. The chapter includes a discussion of outsourcing, an option for systems development and management that may not occur to many students in their first systems development course.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 13. Show students that in-house developed systems are not the only source for software.

14. Six sources for software need to be understood: information technology services firms, packaged software producers, enterprise-wide solutions (ERP), cloud computing services, open-source, and in-house developers. An understanding of the advantages and disadvantages of each must be shown.

15. Cloud computing is likely to be new to students and even though they may have heard the term, it is important to ensure that they understand what it is and what its advantages are.

Emphasize that it enables customers (firms) to use hardware and software that is not installed on their computers, but rather is accessed over the Internet or a virtual private network (VPN) on a pay-for-use basis. Emphasize the three key advantages of cloud computing: (1) freeing internal IT staff, (2) gaining access to applications faster than via internal development, and (3) achieving lower-cost access to corporate-quality applications. Also mention that cost savings are achieved from elastic leasing of pooled resources dynamically resulting in lower costs by paying only for the resources actually used. This is referred to as scalability. Be sure to mention the security concerns associated with cloud computing.

16. Show students how to evaluate off-the-shelf software and why it is important to do thorough analysis first. Review the criteria to consider when purchasing off-the-shelf software. Also explain that the claims made by software and hardware vendors need to be validated by someone outside the vendor organization, such as current users and independent software testing centers. Emphasize that vendor information may be biased and even trade publication articles may describe software in a more than realistic positive light. When in doubt, check the information out.

Classroom Ideas 1. Use Table 2-1 and an updated version of the same information from a recent software survey to begin a discussion of the many, varied sources of software in the marketplace.

2. Use Table 2-2 to summarize the six alternative sources for software and how to choose among them for specific software needs. This table can serve as the basis for a discussion of the make-versus-buy decision and can be expanded to include the ―not invented here‖ syndrome. Additionally, invite a guest speaker who is currently responsible for software procurement and have him or her discuss the advantages and disadvantages of the sources of software.

3. Have students research the proper format and contents for requests for proposals and have them create and/or present an RFP (see Problems and Exercises 2.6). RFP preparation should include discussion of the hardware, software, and organizational issues presented in this chapter.

Answers to Key Terms Suggested answers are provided below.

9 Copyright © 2025 Pearson Education, Inc.

4. Cloud computing: The provision of computing resources, including applications, over the Internet so customers do not have to invest in the computing infrastructure needed to run and maintain the resources.

5. Enterprise resource planning systems (ERP): A system that integrates individual traditional business functions into a series of modules so that a single transaction occurs seamlessly within a single information system rather than several separate systems.

6. Outsourcing: The practice of turning over responsibility for some or all of an organization‘s information systems applications and operations to an outside firm.

7. Request for proposal (RFP): A document provided to vendors that asks them to propose hardware and system software that will meet the requirements of a new system.

Answers to Review Questions 1.18.

Six sources of software are identified in the text. These include: 1) information technology services firms, 2) packaged software producers, 3) enterprise-wide solution software, 4) cloud computing, 5) open-source, and 6) in-house development software.

Information technology services firms are used by companies who do not have the expertise or personnel to develop IS systems. These firms have experts in the development, hosting, and running of applications and other services to fit a customer‘s specifications.

Packaged software producers develop a vast number of applications for different markets that fit a large market segment. Prepackaged solutions may range from general, broadbased to narrow, niche packages that can run on a variety of platforms.

Enterprise solutions (ERP) consist of a series of integrated modules; these modules are integrated to focus on business processes rather than on business functional areas, allowing companies to store data in only one area without duplication. This allows the use of a single repository ensuring more accurate and consistent data with less maintenance.

Cloud computing is the provision of applications over the Internet or a virtual private network (VPN) such that customers do not need to invest in hardware and software infrastructure and can pay on a per-use basis. A key advantage is that server and storage capacity can be ordered on demand as needed. Information security remains a concern when considering cloud computing because of third party control of the applications.

Open-source software has risen in popularity because of the free availability of not only the product but the source code as well. This software is developed and maintained by a community of like-minded people dedicated to improving source code access, with Linux, MySQL, and Firefox being the most prevalent examples.

In-house development requires the resources, especially trained staff, to develop software targeted to an organization‘s own specific needs. Fewer companies are going this route today because of the expertise needed and the high costs of development.

1.19.

1.20.

Table 2-2 compares the six sources of software components.

When deciding what off-the-shelf software to buy, you should compare products and vendors. Additional criteria include (among others that are more situation-specific): cost, functionality, vendor support, vendor viability, flexibility, documentation, response time, and ease of installation. Vendor viability and vendor support are probably the two most important.

A request for proposal (RFP) is a formal document that provides detailed specifications about a target information system and asks vendors for information on how they would 10 Copyright © 2025 Pearson Education, Inc.

develop the system. Analysts use RFPs to get vendors to perform the research to determine what application design will meet user requirements and the hardware and systems software vendors believe are necessary for developing the new system.

1.21.

To verify vendor claims about a software package, an analyst can ask for a software demonstration, use the software (and its documentation and training materials) personally, talk with other users of the software, and consult independent software testing and abstracting services (surveys available for a fee). It is important to make sure that the system fits your organization‘s needs.

1.22.

Enterprise resource planning systems consist of a series of integrated modules; these modules pertain to specific, traditional business functions. However, these modules are integrated to focus on business processes rather than on business functional areas.

Enterprise resource planning systems‘ advantages include a single repository of data for all aspects of a business process, flexible modules, less maintenance, more consistent and accurate data, and ease of adding and integrating new modules into the existing system.

Possible disadvantages of this approach include complexity, lengthy implementation time, lack of in-house expertise, expense, and changing how the organization conducts its business. These projects when accomplished successfully are most often approached as an institutional change project, not simply an IT project.

Answers to Problems and Exercises 1.23.

An organization uses the request for proposal (RFP) to solicit proposals from several competing vendors. Usually, RFPs first provide background information on the company and the business units involved in the request, an explanation of the information systems needs, a description of what is wanted from the vendors (i.e., what information they must provide or other actions they must take), and an explanation of any rules or procedures for the RFP and system development process. The bulk of the document then describes the mandatory, essential, and desirable requirements in the areas of need (e.g., functionality, hardware, software, and service). Students‘ RFP outlines should include these key features.

1.24.

In addition to cost, functionality, vendor support, vendor viability, flexibility, documentation, response time, and ease of installation, several other ―real-world‖ criteria might be included. People often choose application packages, such as word processors and spreadsheets, based solely on their familiarity with the packages and/or their bias toward one hardware platform or operating system over another. To a certain extent this is functional. On the other hand, this can be a disadvantage; for example, it is useful to consider the current staff‘s familiarity with the new application software and the resulting need for retraining but if a company does not choose new software because of the employees‘ lack of familiarity with the software, they run the risk of being left behind using antiquated technology. Additional criteria include compatibility with currently used application software (so, for example, data can be shared), compatibility with existing hardware and system software, ability to support a range from novice to experienced (or power) users, and appeal of the user interface (ease of use).

1.25.

The list for evaluating alternative custom software developers is similar to that for selecting off-the-shelf application software or for computer hardware and system software. In addition to cost, functionality, vendor support, vendor viability, flexibility, documentation, response time, and ease of installation, you might include the current staff‘s familiarity with the software, need for retraining, compatibility and connectivity with current systems, and the track record of the vendor in successfully implementing 11 Copyright © 2025 Pearson Education, Inc.

1.26.

similar software in other organizations. Such vendors should have an established track record for developing similar software in other organizations. Their references should be checked thoroughly, including visits to other sites. Additionally, factors such as the vendor‘s employee turnover rate and history should be considered to ensure the same level of skill and talent is available. Vendor capability may change over time. If the developer‘s role ends after the application is accepted, then the vendor‘s reputation for handling this transition from external development to internal maintenance is important.

From a legal point of view, you may want to select a custom developer based on the willingness to sign a non-disclosure agreement, so that he is not allowed to develop a similar system for one of your competitors, at least for a certain amount of time.

The project team can use the advantages of the enterprise resource planning design as part of its strategy for selling this system. The team can stress that this solution consists of a series of integrated modules; these modules are integrated to focus on business processes, and the firm can integrate all parts of a business process. This approach includes a single repository of data, thus providing more consistent and accurate data and less maintenance.

These modules are flexible and new modules are easily integrated into an existing system.

Also, an enterprise resource planning (ERP) system might be justified on the following grounds: (1) it is a complete enterprise-wide solution that models all aspects of each transaction, supposedly seamlessly and within a single system; (2) an ERP system is based on a single repository of all corporate data, which implies consistency, accuracy, and flexibility of the data; and (3) adding new modules should be relatively painless as all modules are specifically designed to work together. On the other hand, some might counter that ERP systems are complex and require expensive outside expertise for implementation, and that the organization itself must adjust to fit the software‘s model of how organizations should operate rather than the reverse.

12 Copyright © 2025 Pearson Education, Inc.

In both cases, the team may also employ testimonials and reports of results from other organizations that have benefited from the ERP strategy. Other users can be both a reliable and insightful source of information.

Guidelines for Using the Field Exercises 1.27.

Business people are likely to use this list of criteria in some formal or informal way.

Have your students present their findings to the class so that they can learn about a variety of companies. It is useful for students to see how companies actually use these criteria and methods in purchasing off-the-shelf software. Encourage students to understand why their interviewees prioritized the criterion list in such a manner as different companies will have different lists of priorities.

1.28.

Obtaining RFPs may be difficult for your students. It may be necessary for you to obtain copies of RFPs either from business contacts or from the university. You may have to file a Freedom of Information Act (FOIA) request in order to obtain RFPs from public organizations. It is very useful for students to see real RFPs. Students are amazed at how lengthy and detailed these are for larger, more complex systems and at how complicated RFPs can become for governmental agencies. Help students understand that government agencies are subject to federal laws that do not always apply to private organizations.

1.29.

Start by contacting larger organizations (as they are more likely to employ ERP) where alumni from your university or college are now employed and help your students ―break the ice.‖ Also, most if not all universities now have comprehensive ERP installations that the IT folks would be willing to talk about. Chances are any organization that a student contacts about its ERP implementation will have a lot to say, provided the IT staff is willing to share the information. Typically, ERP implementations take several years and cost quite a bit in terms of consultant fees. There are many reasons to move to an ERP system, just as there are many reasons not to move to an ERP system. The organization was probably attracted to the promise of uniformity and consistency made by ERP vendors, although the exact reasons differ from firm to firm. Chances are good that the organization has made some internal changes, such as realigning departments internally to take advantage of the opportunities ERP systems offer, as well as to meet the demands ERP systems make in order to operate effectively. The chances are also good that most of the implementation work has been done by outside consultants, so for firms not used to managing large numbers of contractors, an ERP implementation is a new and different experience. The implementation is likely still going on at whatever firm a student happens to talk with, but it has probably been going on for many months or years, as each ERP implementation is a learning experience for the consultants and the adopting firm.

Chapter 3 Managing the Information Systems Project Chapter Overview Chapter 3 introduces students to the process of managing an information systems project.

Specifically, the chapter focuses on the systems analyst‘s role in managing information systems projects through the four phases in the life of all projects: initiation, planning, execution, and closedown. You and your students should view this chapter as a valuable reference throughout the systems analysis and design course and use the material in this chapter to assist in guiding and 13 Copyright © 2025 Pearson Education, Inc.

evaluating ongoing project activities. In order to provide students with a better understanding of the totality of an information systems project, this chapter is placed early in the textbook. You should emphasize that the skills and knowledge gained from this chapter are a critical foundation to the effective management of information systems projects and other types of projects and activities.

Chapter 3 also introduces the textbook‘s running case, Pine Valley Furniture, which is also used to demonstrate each chapter‘s key concepts. This running case provides a concrete example of a systems development project.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 8. Explain the process of managing an information systems project.

9. Describe the skills required to be an effective project manager. Emphasize that project managers must juggle numerous activities and that project management is, at times, more of an art than a science.

10. List and describe the skills of a project manager during project initiation, project planning, project execution, and project closedown. Stress the importance of communication and leadership skills. Table 3-1 lists the common activities and skills for a project manager.

11. Explain each of the planning activities involved in managing a successful project. Figure 3-9 outlines these activities.

12. Describe the documents and processes involved in each of the project steps beginning with the project charter and the project scope statement and culminating with the project closedown review.

13. Explain what is meant by critical path scheduling and describe the process of creating Gantt charts and network diagrams.

14. Explain the widely used method for project cost estimation COCOMO (COnstructive COst MOdel).

15. Explain the increasing emphasis on the elements in a communication plan and how it affects the overall project outcome. Also explain that communicating project status is critical at all stages and for all stakeholders.

16. Explain how commercial project management software packages assist in representing and managing project schedules.

Classroom Ideas 17. The chapter introduces many different concepts and terms that are central to the management of information systems projects. Accordingly, ask your students to review the chapter‘s key terms. As part of your class discussion, use Review Question 3.1, at the end of the chapter, to compare and contrast this chapter‘s key terms.

18. You may choose not to lecture from this chapter. Your students can read the chapter much as they might read a supplemental, background reading. This comment is especially true if your students have been exposed to project management concepts in another course. If you choose this approach, you should ask each student to apply the concepts of this chapter to a noninformation systems activity (e.g., going on a date and registering for classes). For the noninformation systems activity, ask students to describe the initiation, planning, execution, 14 Copyright © 2025 Pearson Education, Inc.

and closedown activities. Ask your students to create a work breakdown structure that includes precedence relationships and time durations for each activity. Additionally, ask your students to construct Gantt charts and network diagrams for these activities. Students can perform these tasks either inside or outside of class. If you allocate class time, ask students to describe their project and phases. Alternatively, this activity makes a good written assignment.

19. If you lecture from this chapter, the chapter‘s tables and figures are good resources for summarizing the major project management activities.

20. If you want to expose students to the current technology trends in project management, a quick overview of the many tools that project managers can use would be helpful. Start by showing a list of the all the potential solutions that can help manage projects. The most comprehensive lists are at: http://en.wikipedia.org/wiki/Comparison_of_project_management_software. You can then demonstrate a common locally installed project manager tool such as Microsoft Project.

Demonstrating a cloud-based version such as Clarizen would also be helpful in comparing different features. Most solutions, including Microsoft Project and Clarizen, have 30 to 60day trials that you and your students can use. Make sure students understand that the project management activities do not change though some of the ways different solutions have you enter the information and present the information may be different.

21. Another alternative to lecturing from the chapter is to discuss selected Review Questions, Problems and Exercises, and Field Exercises with your students. The selected questions help focus a discussion on project management concepts and techniques.

22. Make sure your students can construct Gantt charts and network diagrams, by hand and also using a common tool. During class, work several of the problems presented in the chapter or at the end of the chapter. Problems and Exercises 3.17 through 3.32 are good problems to work and discuss in class.

23. An out-of-the-box approach might be to ask students to simulate preparing an evening meal at home. This would include a multicourse dinner with varying times for course preparation.

All items are to be done at a certain time with limited resources (microwave, stove, etc.).

Students should prepare a Gantt chart and/or network diagram to demonstrate their solution.

24. Another effective approach to presenting this chapter is to ask students who have been on systems development teams to compare their experiences to the concepts presented in this chapter. This discussion is a good way to elaborate on alternative ways for managing systems development projects, especially if systems were constructed using different methodologies.

Use this discussion to explore whether these student projects followed the discrete phases outlined in the chapter. Ask your students to describe the project manager‘s activities. What activities are the same? What activities are different?

25. If you have access to a practicing systems development project manager, on-campus or offcampus, a useful activity is to invite her into your class to discuss how she manages projects.

Ask this person to discuss how she manages the four project management phases. Also: What tools are used? How do project members communicate? How does the person manage all the stakeholders?

26. Use a copy of the project management guidelines from a local systems development firm or consulting organization, or even from practicing colleagues on campus, to show students how extensive project management guidelines typically are. If you have students working in systems development organizations, you might ask them to bring to class their firm‘s guidelines. If possible, reproduce the table of contents from these manuals for all students.

Have your students compare the various guidelines to see what each organization emphasizes 15 Copyright © 2025 Pearson Education, Inc.

and what is different.

27. Introduce information from the Project Management Institute (www.pmi.org) regarding project management certifications, the membership and committee.

Answers to Key Terms Suggested answers are provided below.

28. COCOMO: The Constructive Cost Model (COCOMO) is an automated software estimation model that uses historical project data and current as well as future project characteristics to estimate project costs.

29. Critical path: The shortest time in which a project can be completed.

30. Critical path scheduling: A scheduling technique whose order and duration of a sequence of task activities directly affect the completion date of a project.

31. Deliverable: An end product of an SDLC phase.

32. Feasibility study: A study that determines if the proposed information system makes sense for the organization from an economic and operational standpoint.

33. Gantt chart: A graphical representation of a project that shows each task as a horizontal bar whose length is proportional to its time for completion.

34. Network diagram: A diagram that depicts project tasks and their interrelationships.

35. PERT (Program Evaluation Review Technique): A technique that uses optimistic, pessimistic, and realistic time estimates to calculate the expected time for a particular task.

36. Project: A planned undertaking of related activities to reach an objective that has a beginning and an end.

37. Project charter: A short document prepared for the customer during project initiation that describes what the project will deliver and outlines generally at a high level all work required to complete the project.

38. Project closedown: The final phase of the project management process that focuses on bringing a project to an end.

39. Project execution: The third phase of the project management process in which the plans created in the prior phases (project initiation and planning) are put into action.

40. Project initiation: The first phase of the project management process in which activities are performed to assess the size, scope, and complexity of the project and to establish procedures to support later project activities.

41. Project management: A controlled process of initiating, planning, executing, and closing down a project.

42. Project manager: A systems analyst with a diverse set of skills—management, leadership, technical, conflict management, and customer relationship—who is responsible for initiating, planning, executing, and closing down a project.

43. Project planning: The second phase of the project management process that focuses on defining clear, discrete activities and the work needed to complete each activity within a single project.

44. Project workbook: An online repository for all project-related documents that is used for performing project audits, orienting new team members, communicating with management and customers, identifying future projects, and performing post-project reviews.

16 Copyright © 2025 Pearson Education, Inc.

45. Resources: Any person, group of people, piece of equipment, or material used in accomplishing an activity.

46. Slack time: The amount of time that an activity can be delayed without delaying the project.

47. Work breakdown structure: The process of dividing the project into manageable tasks and logically ordering them to ensure a smooth evolution between tasks.

Answers to Review Questions 1.30. a. Critical path scheduling is a scheduling technique whose order and duration of a sequence of task activities directly affect the completion date of a project. Gantt is a specific, graphical technique for representing projects, showing each task activity as a horizontal bar whose length is proportional to its time for completion. Network diagramming is a critical path scheduling technique used for controlling resources.

Slack time is the amount of time that a single activity can be delayed without delaying the completion date of the project. b. A project is a planned undertaking of related activities to reach an objective that has a beginning and an end. Project management is a controlled process for initiating, planning, executing, and closing down a project (i.e., the science of managing a project). The project manager is a systems analyst with a diverse set of skills (management, leadership, technical, conflict management) who is responsible for initiating, planning, executing, and closing down a project. c. Projects are managed through four distinct phases: initiation, planning, execution, and closedown. Project initiation includes those activities that assess the size, scope, and complexity of the project and establishes procedures to support later project activities. Project planning focuses on defining clear, discrete activities and the work needed to complete each activity within a single project. Project execution puts the plans created in prior phases into action. Project closedown brings a project to an end. d. A project workbook is a repository for all project documentation to include project correspondence, inputs, outputs, deliverables, procedures, and standards that is used for performing project audits, orienting new team members, communicating with management, and customers, identifying future projects, and performing post-project review. Any people, group of people, piece of equipment, or material used in accomplishing an activity are resources. A work breakdown structure refers the process of dividing the project into manageable tasks and logically ordering them to ensure a smooth evolution between tasks.

1.31.

Information system projects are undertaken to take advantage of business opportunities or to solve business problems that help meet the strategies and goals of an organization.

Providing an innovative service to customers through the creation of a new system exemplifies taking advantage of an opportunity. Modifying the way in which an existing system processes data so that more accurate or timely information is provided to users exemplifies solving a business problem.

1.32.

The common activities and skills of a project manager are highlighted in Table 3-1.

Although a case can be made for each project management skill listed in the table, effective oral and written communication is likely the most fundamental skill for a project manager to master. Without effective communication skills, the ability to successfully complete activities is curtailed.

17 Copyright © 2025 Pearson Education, Inc.

1.33.

Project initiation has six major activities: (1) establishing the project initiation team; (2) establishing a relationship with the customer; (3) establishing a project initiation plan; (4) establishing management procedures; (5) establishing the project management environment and project workbook; and (6) developing the project charter. Establishing the project initiation team organizes an initial core of project team members to assist in accomplishing the project initiation activities. Establishing a relationship with the customer builds a cooperative and trusting partnership with the customer. Establishing a project initiation plan defines the necessary activities required to organize the initiation team while they are working to define the goals and scope of the project. Establishing management procedures focuses on developing team communication and reporting procedures, job assignments and roles, project change procedures, and determining how project funding and billing will be handled. Establishing the project management environment and project workbook creates the repository for all project correspondence, inputs, outputs, deliverables, procedures, and standards of the project team. Developing the project charter is a short, high-level document prepared for the customer to detail what the project will deliver and outlines the key elements of the project.

1.34.

The activities performed by the project manager during project planning include: (1) describing project scope, alternatives, and feasibility; (2) dividing the project into manageable tasks; (3) estimating resources and creating a resource plan; (4) developing a preliminary schedule; (5) developing a communication plan; (6) determining project standards and procedures; (7) identifying and assessing risk; (8) creating a preliminary budget; (9) developing a project scope Statement; and (10) setting a baseline project plan.

Describing project scope, alternatives, and feasibility develops an understanding of the content and complexity of the project by gaining answers to and agreement on the following types of questions:     

What problem or opportunity does the project address?

What are the quantifiable results to be achieved?

What needs to be done?

How will success be measured?

How will we know when we are finished?

After defining the scope of the project, the next objective is to identify and document general solutions for the current business problem or opportunity and assess each solution for feasibility so that a choice can be made as to which to consider during subsequent SDLC phases.

Dividing the project into manageable tasks is a critical activity that leads to a smooth evolution between tasks. Estimating resources and creating a resource plan approximates resource requirements for each project activity and uses this information to create a project resource plan. Developing a preliminary schedule uses information regarding tasks and resource availability to assign time estimates to each activity in the work breakdown structure. This assignment will allow for the creation of target starting and ending dates for the project. Developing a communication plan outlines the communication procedures between management, project team members, and the customer. Determining project standards and procedures specifies how various deliverables are produced and tested. Identifying and assessing risk examines sources of project risk and estimates the consequences of those risks. Risks might arise from the use of new technology, resistance to change, availability of critical resources, competitive and regulatory actions, and team member inexperience with technology or the business 18 Copyright © 2025 Pearson Education, Inc.

area.

Creating a preliminary budget means outlining the planned expenses and revenues associated with the project. Developing a project scope statement results in outlining the work to be done and clearly describing what the project will deliver. The focus of setting a baseline project plan is to develop an initial plan that reflects the best estimate of the project‘s tasks and resource requirements and is used to guide the next project phase: execution.

1.35.

Project execution activities include: (1) executing the baseline project plan; (2) monitoring project progress against the baseline project plan; (3) managing changes to the baseline project plan; (4) maintaining the project workbook; and (5) communicating the project status.

The focus of executing the baseline project plan is to initiate the execution of project activities, acquire and assign resources, orient and train new team members, keep the project on schedule, and ensure the quality of project deliverables. The focus of monitoring project progress against the baseline project plan is to compare the actual progress of the project to that projected in the baseline project plan. If the project gets ahead of (or behind) schedule, adjustments to resources, activities, and budgets can be made. The focus of managing changes to the baseline project plan is to incorporate approved changes to project specifications and reflect those changes in the baseline plan and project workbook. The focus of maintaining the project workbook is to update the project workbook, which contains project-related information. The focus of communicating the project status is to inform all interested parties, systems developers, managers, and customers, about how the project is progressing.

1.36.

Table 3-2 summarizes project team communication methods. Table 3-2 rates each method in terms of formality and use (informing, resolving issues, or keeping permanent records). The following table lists the communication methods from Table 3-2 and provides an example of the type of information that might be shared among team members for each method.

19 Copyright © 2025 Pearson Education, Inc.

Team Communication Methods and Corresponding Examples Communication Methods

Examples

Project Workbook

Official system documentation, such as data flow diagrams or entity–relationship diagrams, interview notes

Meetings

Review project schedule

Seminars and Workshops

Techniques and methods to be used in subsequent project phases

Project Newsletters

Introduce new team members, explain upcoming project activities

Status Reports

Project activity completions and issues

Specification Documents

Form designs, program structure charts

Minutes of Meetings

Decisions made on alternative system designs

Bulletin Boards

Project status, awards for team members

Memos

Guidance to team members, personnel appraisals

Brown Bag Lunches

Information from trade shows attended by team members, ideas about articles read on systems analysis and design

Hallway Discussions

Answers to questions, advice on how to deal with problems

1.37.

The project closedown activities performed by the project manager are: (1) closing down the project, (2) conducting reviews, and (3) closing the customer contract. The focus of closing down the project is to conclude the project. The objective of conducting reviews is to assess the strengths and weaknesses of project deliverables, the processes used to create them, and the project management process. The focus of closing the customer contract is to ensure that all contractual terms of the project are met.

1.38.

Critical path scheduling is a scheduling technique whose order and duration of the sequence of task activities directly affect the completion date of a project. Applicable project characteristics include: (1) well-defined activities that have a clear beginning and end point; (2) activities that can be worked on independently of other tasks; (3) activities that are ordered; and (4) activities that when completed serve the purpose of the project.

1.39. The steps involved in making a Gantt chart are: (1) identify each activity to be completed in the project; (2) determine time estimates and calculate the expected completion time for each activity; (3) determine the sequence of the activities and precedence relationships among all activities; and (4) construct the Gantt chart.

20 Copyright © 2025 Pearson Education, Inc.

1.40. The steps involved in making a network diagram are: (1) identify each activity to be completed in the project; (2) determine time estimates and calculate the expected completion time for each activity; (3) determine the sequence of the activities and precedence relationships among all activities; and (4) construct the network diagram.

1.41. Project planning typically occurs during the project initiation and planning phase of the SDLC. Project management occurs during all phases of the SDLC; however, different project management activities occur during different SDLC phases.

1.42. Task sequence depends on which tasks produce deliverables needed in other tasks, when critical resources are available, constraints placed on the project by the client, and the process outlined in the SDLC.

Answers to Problems and Exercises 1.43. Each of the four project management phases has its unique challenges, so student answers will vary. Project initiation, the first phase, involves team building, building relationships with customers, defining the problem and project, and other challenging tasks. Some students will argue that the first phase is most important. If the first phase is conducted poorly, the project is likely to be doomed to failure. Project planning, the second phase, is also important because it can make or break the success of the project work that follows.

In addition, resource planning, scheduling, crafting a budget and other planning tasks are difficult. Good planning is a challenge, since there is almost always pressure to truncate or do away with planning. Many students are likely to choose project execution, the third phase. This phase involves actually building the system, which is the analyst‘s primary responsibility and often is the longest phase of project management. Students are not likely to choose the fourth phase, closing down the project. However, this phase is equally challenging. The dismantling of the team is a difficult, often overlooked aspect of project management. In addition, assignment changes for team members and performance appraisals are challenges associated with this phase.

1.44. Sources of risk include the use of new technology, prospective users‘ resistance to change, availability of critical resources, competitive reactions or changes in regulatory actions due to the construction of a system, and team member inexperience with the technology or business area. A manager should identify the potential sources of risks, describe the possible negative outcomes, determine the probabilities of occurrence, and prepare contingency plans for those significant outcomes with a high probability of occurrence.

1.45. Several project management software packages are available for the personal computer.

Microsoft Project and Oracle‘s Primavera are two widely used project management software packages that can be installed on your computer. Clarizen is a popular project management tool that can be accessed from your Web browser. Information about project management software can be obtained from a variety of sources, including the World Wide Web, trade magazines, the library, marketing packets, and testing services. The World Wide Web is an excellent source of information. As part of your class activities or as a homework assignment, students can search the Web for relevant information about project management software. If time permits, ask students to investigate cloud based, open source and shareware products. Encourage them to compare these products compare with Microsoft Project.

Advice given to prospective buyers is much like the advice provided to buyers of other types of software. For example, the individual should first determine what he needs and why they need it, and then they should see what packages best meet these needs at an 21 Copyright © 2025 Pearson Education, Inc.

acceptable price. The opinions of other users are also advisable. A discussion between installed software and cloud-based solution would also be appropriate.

1.46. During project initiation there are several activities that help to assess size, scope and complexity of the project. The project manager starts this first step of the project by establishing a project team. This can be done in a variety of ways, but the team often consists of members for several different areas. Next, the project manager would establish a relationship with the customer. This is done by assigning a specific liaison, so the customer has one person to reach out to if they have any questions. Next, the project initiation plan is undertaken. This includes defining the goals and the scope of the project.

Subsequently, the project manager will establish management procedures, which are developed to give the project team and the consumer a clear understanding of the management structure and communication structure with a description of how information will flow in the project team. The second last step is to collect and organize the tools that managers use to help run the project. Also, diagrams, charts and system description are assembled into a workbook. Taken together, this step is called establishment of a project management environment and project workbook. Finally, the project manager will develop a project charter, which includes several elements that detail the different aspects of the project.

1.47. It is possible to have two (or even more) critical paths. This happens with the length of critical paths are equal. For example, Task1+Task2+Task3+Task6 = 10 days where Task1+Task5+Task6 = 10 days.

1.48. The expected times for this exercise are summarized in the following table.

Problems and Exercises 3.19 Expected Times Summary Table Task

Expected Time

A

7

B

9

C

3

D

5

E

6

F

5

G

4

H

4

I

5

J

6.83

22 Copyright © 2025 Pearson Education, Inc.

1.49. The expected times for this exercise are summarized in the following table to include the early finish, late finish, and slack times for this exercise. This table also identifies the activities located on the critical path.

Problems and Exercises 3.20 Activity Summary Table Activity

Time

Immediate Predecessors

Early

Late

Finish

Finish

Slack

Critical Path?

1

3

--

3

3

0

Yes

2

2

1

5

5

0

Yes

3

2

2

7

8

1

No

4

6

2

11

11

0

Yes

5

3

3

10

11

1

No

6

2

3, 4

13

17

4

No

7

4

4, 5

15

15

0

Yes

8

5

6, 7

20

22

2

No

9

7

7

22

22

0

Yes

10

2

8, 9

24

24

0

Yes

A variety of software products can be used to produce a network diagram. The important issue is that students accurately express the relationships among the activities in this problem. a. Network Diagram

b. The earliest expected completion time is 24 weeks. c. The activities in the boxes with the darker border are on the critical path. These activities include collect requirements, analyze processes, design processes, design reports, test and document, and install. d. Changing Activity 6 from 2 weeks to 6 weeks will create two critical paths. Since Activity 6 was not on the critical path originally, this change does not affect the project‘s completion time.

23 Copyright © 2025 Pearson Education, Inc.

1.50. Microsoft Project was used to create the following Gantt chart. This chart has a February 2, 2015 start date.

Problems and Exercises 3.21 Gantt Chart for Problem 3.20

1.51. The new time estimates have pushed the earliest expected completion time to 57 weeks.

The activities in the boxes with a darker border are on the critical path. The activities on the critical path include collect requirements, analyze processes, design processes, design reports, test and document, and feedback. The network diagram was completed using Microsoft Project.

Problems and Exercises 3.22 Network Diagram

Activity Summary Table Activity

Time

Immediate Predecessors

Early

Late

Finish

Finish

Slack

Critical Path?

1

6

--

6

6

0

Yes

2

2

1

8

8

0

Yes

3

4

2

12

20

8

No

4

18

2

26

26

0

Yes

5

6

3

18

26

8

No

6

4

3, 4

30

42

12

No

24 Copyright © 2025 Pearson Education, Inc.

7

12

4, 5

38

38

0

Yes

8

10

6, 7

48

52

4

No

9

14

7

52

52

0

Yes

10

4

8, 9

56

56

0

Yes

11

1

9, 10

57

57

0

Yes

1.52. Student answers will vary. To make it worthwhile to create Gantt and network diagrams, encourage your students to choose projects of sufficient complexity. Encourage students to use project management software to create their charts. Have students compare their charts and, if possible, compare charts created using different software products. Have students discuss the comparative strengths and weaknesses of these packages.

Alternatively, compare charts drawn using software with those drawn by hand. Have your students discuss the comparative advantages and disadvantages of drawing these charts by hand as opposed to using project management software. Emphasize the typical power of any computer tool, which is the efficiency of making changes to the data compared to manual methods.

1.53. Some of these difficulties are easier to deal with than others. When changing the project plan to account for the delays, students will simply adjust their Gantt and network diagrams accordingly. Other difficulties, however, are more problematic. For example, dealing with the boss is potentially more difficult. Frequent communication, accurate and full assessments of the situation, requests for reasonable means to deal with problems, and a history of being a good project manager are necessary to gain compliance from the boss.

There are basically four problems. The reassigned team member and the changes in due dates are beyond the control of the project manager. However, the personality clashes among team members and the mistaken completion estimate for one of the tasks are within the control of the project manager. If these two problems remain unsolved, they may reflect poorly on the project manager. One prudent alternative is to explain the situation to the boss. The project manager should also explain to the boss what he is doing to solve these two problems. If the boss absolutely cannot accept the project past the original deadline, then additional resources are needed to complete the project on time. If additional resources will solve the problem, and they are available, the project manager should provide a fairly strong, convincing rationale for why these new resources should be allocated to this project. The project manager might show, for example, that the project cannot be completed on time unless the boss doubles the programmers available for this project or takes some much-needed experts off other projects and assigns them to this project.

1.54. The following table summarizes the early finish, late finish, and slack times for this exercise. This table also identifies the activities located on the critical path. A Gantt chart is also provided. The Gantt chart was prepared with Microsoft Project; the starting date is July 26, 2004.

25 Copyright © 2025 Pearson Education, Inc.

Problems and Exercises 3.25 Activity Summary Table Activity

Time

Immediate Predecessors

EF

LF

Slack

Critical Path?

A

5

--

5

5

0

Yes

B

3

A

8

12

4

No

C

4

A

9

9

0

Yes

D

6

C

15

15

0

Yes

E

4

B, C

13

16

3

No

F

1

D

16

16

0

Yes

G

5

D, E, F

21

21

0

Yes

Problems and Exercises 3.25 Gantt Chart

1.55. A suggested network diagram is provided below. Microsoft Project was used to prepare the network diagram. Activities A, C, D, F, and G (shown with a darker border) are on the critical path.

Problems and Exercises 3.26 Network Chart

1.56. Suggested answers are provided below; Microsoft Project was used to prepare the network diagram. Activities in boxes with a darker border are on the critical path. The following table summarizes the times, immediate predecessors, early and late finish times, and slack times for each activity. As noted in the table and network diagram, activities A, D, E, F, I, and J are on the critical path.

26 Copyright © 2025 Pearson Education, Inc.

Problems and Exercises 3.27 Activity Summary Table Activity

Time

Immediate Predecessors

Early

Late

Finish

Finish

Slack

Critical Path?

A

4

--

4

4

0

Yes

B

5

A

9

31

22

No

C

6

A

10

17

7

No

D

7

A

11

11

0

Yes

E

6

A, D

17

17

0

Yes

F

5

C, E

22

22

0

Yes

G

4

D, E

21

22

1

No

H

3

E

20

26

6

No

I

4

F, G

26

26

0

Yes

J

5

H, I

31

31

0

Yes

Problems and Exercises 3.27 Network Diagram

1.57. A Gantt chart, based on the previous question‘s criteria, is presented below. The start date is February 2, 2015. Microsoft Project was used to prepare this chart.

Problems and Exercises 3.28 Gantt Chart

1.58. Suggested answers are provided below. Microsoft Project was used to prepare the network diagram, and the Gantt chart. On the network diagram, activities in boxes with a darker border are on the critical path. The following table summarizes the times, immediate predecessors, early and late finish times, and slack times for each activity. As noted in the table and network diagram, activities A, C, D, F, G, H, I, and J are on the critical path.

27 Copyright © 2025 Pearson Education, Inc.

Problems and Exercises 3.29 Activity Summary Table Activity

Time

Immediate Predecessors

Early

Late

Finish

Finish

Slack

Critical Path?

A

3

--

3

3

0

Yes

B

1

A

4

5

1

No

C

2

A

5

5

0

Yes

D

5

B, C

10

10

0

Yes

E

3

C

8

12

4

No

F

2

D

12

12

0

Yes

G

3

E, F

15

15

0

Yes

H

5

F, G

20

20

0

Yes

I

5

G, H

25

25

0

Yes

J

2

I

27

27

0

Yes

Problems and Exercises 3.29 Gantt Chart

Problems and Exercises 3.29 Network Diagram

1.59. Student answers will vary. However, students will likely mention reviewing degree requirements, visiting with advisors, comparing schedules with friends (making sure they are in the same class), reviewing work schedules, and course schedules. Encourage students to use project management software to create their network diagrams and Gantt charts. Ask them to discuss the advantages to using project management software over constructing the charts by hand.

1.60. Student answers will vary. Some students may only decompose their project into two levels and this may not be sufficient to reach a level that represents manageable tasks.

Others may decompose their task into 4 or 5 layers making the project too detailed such that management would become complex and cumbersome.

1.61. Student answers will vary. Now students must start to think about the timing and sequencing of activities and here is where they may make tasks too small or too large.

Typically a task that can be done in a week or two weeks is of a reasonable size for WBS planning. If students create tasks that are too small (a few hours or a single day) or too 28 Copyright © 2025 Pearson Education, Inc.

large (several weeks or months long), give them feedback to help them revise their WBS and merge small tasks together and break larger ones into sets of more manageable tasks.

1.62. Student group results will vary. This can be a fun exercise for students and can help them to see how others on their teams and on other teams may view the size and duration of tasks differently. Work with the groups to help them identify omissions or size disparities that might make project management more difficult.

Guidelines for Using the Field Exercises 1.63. Students will provide a variety of answers for this question, so it is useful for students to compare their answers. Each of us is unique, as are project managers, so students are likely to find variations in the skills and activities for which project managers are responsible, the skills and activities they find more challenging, those at which they are better, and those they prefer. Table 3-1 is a fairly complete list, so it will be interesting to see if students can find managers who mention skills or activities not listed in the table.

You can use the information generated by students in your project management lecture the next time you teach the course.

1.64. As with the previous question, students are likely to provide a variety of answers for this question. Thus, it is useful for students to compare their answers. While the project planning elements in Figure 3-9 are fairly complete, they are operationalized differently within each organization. Students are likely to find variations in the extent to which these elements are part of each person‘s planning process. Have students discuss why barriers exist and what can be done to eliminate, exploit, or work around these barriers.

1.65. People have different communication strengths, weaknesses, and preferences. Also, different forms of communication are emphasized in different organizations. However, meetings, memos, and hallway discussions occur in nearly all organizations. People are likely to have distinct ideas about which types of communication are best for certain situations. For example, people tend to use memos for more formal communication.

Similarly, people tend to use hallway discussions for more informal and/or sensitive information.

1.66. This question parallels Field Exercise 3.35 in many ways. In fact, it is useful for students to answer these two field exercises simultaneously. While the project execution elements in Figure 3-15 are fairly complete, they are operationalized differently within each organization. Students are likely to find variations in the extent to which these elements are part of each person‘s work. Have students discuss why the barriers exist and what can be done to either eliminate, exploit, or work around these barriers.

1.67. This is a substantial question, but it should provide rich, useful information for class discussion. The key issues are the similarities and differences between information systems projects and other types of projects. In particular, are different personal leadership attributes required for systems projects versus non-systems projects? An organization‘s culture and general management style can affect leadership attributes applied in each case. Many people argue that leadership skills and attributes are generic and transcend most tasks and jobs. However, students may uncover some perceived differences from their small data set they build from the individual reports of project managers.

1.68. This is a very useful exercise, especially if students can observe an information system project team building a real system. If not, it is still useful for students to conduct the same exercise using a class-based student project team. Alternatively, your students can read something like Tracy Kidder‘s award-winning book, The Soul of a New Machine, 29 Copyright © 2025 Pearson Education, Inc.

which is an account of an information systems project (new computer system design) team in industry (Data General). This book is an excellent case study of the sociology of teams and projects. Have your students‘ compare their answers to see if a general set of project team dos and don‘ts arises. Have students also address the extent to which each of these dos and don‘ts is generalizable to other project team settings.

Chapter 4 Identifying and Selecting Systems Development Projects Chapter Overview Chapter 4 introduces students to the first phase of the systems development life cycle, identifying and selecting systems development projects. The premise is that organizations benefit by following a formal process for identifying and selecting projects. Chapter 4 overviews the corporate strategic planning process and then links this process to information systems planning.

Both planning approaches are presented as three-step processes.

During the first step of information systems planning, a senior manager, a business group, an IS manager, or a steering committee identifies all possible systems development projects that an organizational unit can undertake. During the second step, projects are classified and ranked according to some criteria that are important to the organization. During the third step, those projects deemed most likely to yield significant organizational benefits, given available resources, are selected for subsequent development activities.

Beginning in Chapter 4, students are introduced to how systems development projects for Internet-based applications proceed. Pine Valley Furniture‘s WebStore is used as a running case example. The PVF WebStore project is an excellent way of comparing and contrasting traditional systems development with Internet-based applications systems development.

Instructional Objectives Specific learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 48. Illustrate the project identification and selection process.

49. Provide a comprehensive overview of the corporate strategic planning and information systems planning processes.

50. Describe the relationship between corporate strategic planning and information systems planning.

51. Illustrate how information systems planning assist in identifying and selecting systems development projects.

52. Explain how information systems planning matrices are used to determine affinity between information systems and IS projects and the impact of IS projects on business objectives.

53. Discuss the identification and selection of systems development projects for Internet-based applications.

Answers to Key Terms Suggested answers are provided below.

30 Copyright © 2025 Pearson Education, Inc.

54. Affinity clustering: The process of arranging planning matrix information so that clusters of information with a predetermined level or type of affinity are placed next to each other on a matrix report.

31 Copyright © 2025 Pearson Education, Inc.

55. Bottom-up planning: A generic information systems planning methodology that identifies and defines IS development projects based upon solving operational business problems or taking advantage of some business opportunities.

56. Competitive strategy: The method by which an organization attempts to achieve its mission and objectives.

57. Corporate strategic planning: An ongoing process that defines the mission, objectives, and strategies of an organization.

58. Data dictionary: A centralized repository of information about data such as meaning, relationships to other data, origin, usage, and format.

59. Electronic commerce (EC) 60. Incremental commitment: A strategy in systems analysis and design in which the project is reviewed after each phase and continuation of the project is rejustified.

61. Information systems planning (ISP): An orderly means of assessing the information needs of an organization and defining the systems, databases, and technologies that will best satisfy those needs.

62. Internet: A large, worldwide network of networks that use a common protocol to communicate with each other.

63. Internet-of-Things (IoT): A broad class of physical objects that feature an Internet address and connectivity that communicate between these objects and other Internet-enabled devices and systems.

64. Mission statement: A statement that makes it clear what business a company is in.

65. Objective statements: A series of statements that express an organization‘s qualitative and quantitative goals for reaching a desired future position.

66. Top-down planning: A generic ISP methodology that attempts to gain a broad understanding of the information systems needs of the entire organization.

67. Value chain analysis: Analyzing an organization‘s activities to determine where value is added to products and/or services and the costs incurred for doing so; it usually also includes a comparison with the activities, added value, and costs of other organizations for the purpose of making improvements in the organization‘s operations and performance.

Answers to Review Questions 1.69.

4.1. a. A mission is a statement that makes it clear what business a company is in. Objective statements express an organization‘s qualitative and quantitative goals for reaching a desired future position. A competitive strategy is the method by which an organization attempts to achieve its mission and objectives. b. Corporate strategic planning is an ongoing process that defines the mission, objectives, and strategies of an organization. Information systems planning is an orderly means of assessing the information needs of an organization and defining the systems, databases, and technologies that will best satisfy those needs. c. Top-down planning is a generic information systems planning methodology that attempts to gain a broad understanding of the information system needs of the entire organization. Bottomup planning is a generic information systems planning methodology that identifies and defines IS development projects based on solving operational business problems or taking advantage of business opportunities.

32 Copyright © 2025 Pearson Education, Inc.

d. Low-cost producer is a strategy that reflects competing in an industry based on product or service cost to the customer. Product differentiation is a strategy that reflects capitalizing on a key product criterion requested by the market. Product focus or niche is a strategy that is similar to both the low-cost and differentiation strategies but with a much narrower market focus.

1.70.

4.2.

Project identification and selection identifies potential development projects, classifies and ranks these projects, and then selects projects for development.

Organizations vary as to how they identify projects, and all methods of identification have strengths and weaknesses. Research has found, for example, that projects identified by top management often have a strategic organizational focus. Some projects are identified by top-down initiatives; others are identified by bottom-up initiatives. Whereas limited resources preclude the development of all proposed systems, most organizations have some process for classifying and ranking the merit of each project. Projects deemed inconsistent with overall organizational objectives, redundant in functionality to some existing system, or unnecessary are removed from consideration. Project selection considers both short- and long-term projects and selects those projects most likely to achieve business objectives. As business conditions change over time, the relative importance of any single project may substantially change.

1.71.

4.3.

Table 4-2 identifies several evaluation criteria, including value chain analysis, strategic alignment, potential benefits, resource availability, project size/duration, and technical difficulties/risks. Value chain analysis examines the extent to which activities add value and costs when developing products and/or services. Strategic alignment examines the extent to which the project is viewed as helping the organization achieve its strategic objectives and long-term goals. Potential benefits examine the extent to which the project is viewed as improving profits, customer service, and so forth, and the duration of these benefits. Resource availability examines the amount and type of resources the project requires and their availability. Project size/duration examines the number of individuals and the length of time needed to complete the project. Technical difficulties/risks examine the level of technical difficulty to successfully complete the project within given time and resource constraints.

1.72.

4.4.

Value chain analysis is the process of analyzing an organization‘s activities for making products and/or services to determine where value is added, and costs are incurred. After gaining an understanding of each activity, function, and process where value is or should be, the organization can determine associated costs. The organization can then use this information to benchmark its value chain with other organizations. This technique is one method the company can use to prioritize information systems development projects.

4.5.

Chapter 4 identifies several factors as evidence of the need for improved information systems planning. These factors include: the cost of information systems has risen steadily and approaches 40% of the total expenses in some organizations; many systems cannot handle applications that cross organizational boundaries; many systems often do not address the critical problems of the business as a whole nor support strategic applications; data redundancy is often out of control, and users may have little confidence in the quality of data; systems maintenance costs are out of control as old, poorly planned systems must constantly be revised; and application backlogs often extend three years or more, and frustrated end users are forced to create (or purchase) their own systems, often creating redundant databases and incompatible systems in the process.

1.73.

1.74.

4.6.

Corporate strategic planning involves three major steps. The first step is the development of a mission statement. The company‘s mission statement typically states, 33 Copyright © 2025 Pearson Education, Inc.

in very simple terms, what business the company is in. After defining its mission, an organization then defines its objectives. The objective statements are ―broad and timeless‖ goals for the organization. These goals are expressed as a series of statements that are either qualitative or quantitative, but typically do not contain details that are likely to change substantially over time. Once a company has defined its mission and objectives, a competitive strategy is formulated. A competitive strategy is the method by which an organization attempts to achieve its mission and objectives.

1.75.

4.7.

Low-cost producer, product differentiation, and product focus or niche focus are three generic competitive strategies. The low-cost producer strategy reflects competing based on product or service cost to the consumer. The product differentiation strategy reflects capitalizing on a key product criterion requested by the market. The product focus or niche strategy is similar to both the low-cost and differentiation strategies but with a much narrower market focus.

1.76.

4.8.

Information systems planning is an orderly means of assessing the information needs of an organization and defining the information systems, databases, and technologies that will best satisfy those needs. ISP is a three-step process. The first step assesses the current IS-related assets—human resources, data, processes, and technologies. Second, target blueprints of these resources are developed. These blueprints reflect the desired future state of the resources needed by the organization to reach its objectives as defined during strategic planning. Third, a series of scheduled projects is defined, helping move the organization from its current to future desired state.

1.77.

4.9.

The top-down planning approach offers several advantages, including a broader perspective, improved integration, improved management support, and better understanding. Descriptions for each approach are provided in Table 4-4.

1.78.

4.10. A Location-to-Function matrix identifies which business functions are being performed at various organizational locations. A Location-to-Unit matrix identifies which organizational units are located or interact with a specific business location. A Unit-toFunction matrix identifies the relationships between organizational entities and each business function. A Function-to-Objective matrix identifies which functions are essential or desirable in achieving each organizational objective. A Function-to-Process matrix identifies which processes are used to support each business function. A Function-to-Data Entity matrix matches which business functions utilize which data entities. A Process-toData Entity matrix identifies which data are captured, used, updated, or deleted within each process. A Process-to-Information System matrix identifies which information systems are used to support each process. A Data Entity-to-Information System matrix identifies which data are created, updated, accessed, or deleted in each system. An Information System-to-Objective matrix identifies which information systems support each business objective as identified during organizational planning.

1.79.

4.11. When designing Internet-based applications, as opposed to intranet or extranet applications, designers are concerned with whom the user is, the connection speed, and the access method. Security concerns should be considered as well.

Answers to Problems and Exercises 1.80.

4.12. Results will vary but one example might be: ―Our mission is to put the customer first by providing a unique customer experience at a fair price.‖

1.81.

4.13. Answers will vary but in regards to objectives, typically two types of objectives are used: financial and strategic. Financial objectives target outcomes that relate to 34 Copyright © 2025 Pearson Education, Inc.

1.82.

improving the company‘s financial performance. Two examples are increasing earnings growth by 10 to 15% per year and boosting return on equity investment from 15 to 20%.

The competitive strategy for achieving the mission would be achieving a low-cost leadership strategy or a differentiation strategy where they differentiate themselves from competitors based on features, service, or other factors. Within these two general strategies, companies sometimes provide either a broad or focused set of products and/or services. Of course, some companies try to achieve several of these goals. For example, some implement a best-cost provider strategy, where they give customers more value for their money by combining an emphasis on low cost with an emphasis on upscale differentiation.

4.14. Answers will vary but may include: planning is difficult and costly (time, money, people, and other resources), people want short-term results, people disagree with the IS vision/architecture, people do not want to change the current system or plan, and many people fear change. On the one hand, these reasons are not justifiable because people may not be thinking and acting in the organization‘s best interests.

1.83.

The implications for poor or no strategic IS planning are many. Users may not be able to access the data that they need, and issues with data compatibility may exist. Users may receive mixed signals about strategic applications and how the organization desires to apply information technology. Little or no guidance regarding the procurement of hardware and/or software may be provided. Finally, this may lead to what F. Sweet has called the ―Winchester Syndrome‖ (April 1984, Datamation). He reasoned that without proper planning, information systems will suffer the same fate as the famous Winchester Mystery House, with its false chimneys, doors that open onto blank walls, and stairways that lead to ceilings. The Winchester Mystery House is a monument to ―on the fly‖ design.

1.84.

4.15. Operating in an organization that does not have a formal corporate planning process presents a difficult situation to IS planners. The IS planners need to plan and garner the support and participation of others in an atmosphere where people do not plan.

In addition, because IS plans are driven by the organization‘s mission, the IS planners would, in essence, be planning in a vacuum. The IS planners would have to work hard to determine what the organization‘s mission is (i.e., they would perform corporate planning, as well as IS planning). It is likely that there would be different, possibly even conflicting, notions of what the mission is and ought to be.

1.85.

Those responsible for IS planning may have to consult with corporate leadership to identify the mission, objectives, and strategies of the organization. Since it would be rather risky to conduct information systems planning without understanding the corporate strategic plan, IS planners may have to survey the organization‘s CEO and other members of the top management team to gain a better understanding of the current enterprise, future enterprise, and strategic plan.

1.86.

4.16. At this early stage, the most important criterion is the extent to which the potential project under consideration supports the organization‘s mission. At this point, economic concerns are secondary. Economic concerns become more important during the next project phase, project initiation and planning. More important is the effect the planned IS will have on the value chain. Other important factors include the planned system‘s fit with the organization‘s mission and future enterprise vision.

1.87.

4.17. In an organization that does an excellent job of IS planning, the goal of the planners is to develop systems that support the organization‘s mission. If a project is identified from a bottom-up process that supports the organization‘s mission and even if 35 Copyright © 2025 Pearson Education, Inc.

this new system was not originally planned, the planners are likely to incorporate this new system into their IS planning. In organizations where planning is done well, there are mechanisms that build flexibility into the planning process. Planning should not be too rigid or inflexible. Also, having a plan stimulates people to think of specific projects that help fulfill the plan.

1.88.

4.18. Affinity clustering is the process of arranging planning matrix information so that clusters of information with a predetermined level or type of affinity are placed next to each other on a matrix report. Referencing Figure 4-13, four functions (production scheduling, fabrication, assembly, and finishing) use the work center, equipment, employees, and work order data entities. Such clustering suggests that these functional areas are likely to work closely together in time and/or on related or sequential tasks. In any event, they definitely use similar information in their work processes. The analyst might develop the subsystems for these functions simultaneously. Alternatively, one subsystem might be built to serve each of the functional areas.

1.89.

4.19. For example purposes, assume the sales representatives are located in Chicago, St. Louis, New Orleans, Boston, Dallas, and Phoenix. The locations include northern California, upper-Midwest, Chicago, St. Louis, New Orleans, Boston, Dallas, and Phoenix. For this organization, the units include research and development, manufacturing, accounting, finance, human resource management, sales, and information systems. One central function is circuit manufacturing, which includes the processes of circuit printing, drying, and testing. Another important function is circuit design, which includes the processes of drawing the artwork for a circuit and developing a prototype.

This organization uses many of the data entities that are commonly used by most manufacturers, such as customer, product, vendor, raw material, order, work center, equipment, employee, invoice, and work order. The information systems include payroll processing, accounts payable, accounts receivable, inventory management, computeraided design, and computer-integrated manufacturing.

1.90.

4.20. Two matrices are provided below. The first example is a Function-to-Data Entity matrix. The second example is an Information System-to-Data Entity matrix. This organization also uses office automation applications, such as electronic mail, word processing, spreadsheets, graphics packages, and Internet interface software.

36 Copyright © 2025 Pearson Education, Inc.

Chapter 4

Instructor’s Manual

Modern Systems Analysis and Design 10th edition

Function-to-Data Entity Matrix Data Entities

Customer

Product

Vendor

Raw Material

Order

Work Center

Equipment

Employee Invoice

Work Order

Functions Circuit Manufacturing

X

X

X

X

X

X

X

X

Circuit Design

X

X

X

X

X

X

X

X

Order Fulfillment

X

X

Distribution

X

X

Accounts Receivable

X

X

X X

X

X X

X

Accounts Payable

X

X

X

Process-to-Data Entity Matrix

Data Entities

Customer

Product

Vendor

Raw Material

Order

Work Center

Equipment Employee Invoice

Process Circuit Printing

X

Circuit Drying

X

X

36 Copyright © 2025 Pearson Education, Inc.

X

X

X

X

X

X

Work Order

Data Entities

Customer

Product

Vendor

Raw Material

Order

Work Center

Equipment Employee Invoice

Process Circuit Testing

X

X

X

X

Circuit Drawing

X

X

X

X

Prototyping

X

X

X

X

X

37 Copyright © 2025 Pearson Education, Inc.

Work Order

Chapter 4

Instructor’s Manual

Modern Systems Analysis and Design 10th edition

Process-to-Information System Matrix Information System

P a y ro ll P ro c e s s ing

A c c o unt s P a y a b le

A c c o unt s R e c e iv a b le

Inv e nt o ry x M a na g e me nt

CAD

CAM

x

x

x

Circuit Drying

x

x

Circuit Testing

x

Circuit Drawing

x

Process Circuit Printing

x

Prototyping

x

x

Data Entry to Information Systems Matrix Information System

P a y ro ll P ro c e s s ing

A c c o unt s P a y a b le

A c c o unt s R e c e iv a b le

Inv e nt o ry x M a na g e me nt

CAD

CAM

Data Entry

x

Customer

x x

Product

x

Vendor

x

x

Raw Material

x

x x

O rder

Work Center

x

Invoice

x

x

x

x x

x

x

x

x x

x

x x

Work O rder

1.91.

x

x

Equipment

Employee

x

x

4.21. The most important changes involve the locations matrices. These matrices would need to be updated to reflect the eight new locations.

1 Copyright © 2025 Pearson Education, Inc.

Guidelines for Using the Field Exercises 1.92.

4.22. Acquiring an organization‘s mission statement should be easy for the students to do. An organization‘s mission statement can be obtained from the library, the Web, or directly from the organization. If the mission statements are well written, your students should be able to determine what business the organization is in and what that organization values. For example, from the Courtyard by Marriott‘s mission statement, one can tell that the company is in the lodging industry for business travelers and that it values high quality, clean facilities, high-quality service, and employing competent, friendly staff members. If the organization is strategically planning and implementing information systems, then these systems should support the organization‘s mission. For example, at Courtyard, automated registration systems help the company provide better service.

1.93.

4.23. This question requires time and effort to answer, but its usefulness is commensurably higher. If the chosen organization is of moderate size, then some degree of formal IS planning is probably undertaken. Similarly, such an organization is likely to engage in some degree of formal strategic planning. If the organization is doing things right, a clear fit between the IS plan and the organization‘s strategic plan should be apparent, with the organization-wide plan driving the IS plan. If a good fit does not exist, ask your students to express ideas on any problems that may arise and their forecasts for the future of this company.

4.24. After conducting short interviews with IS and non-IS personnel within the selected organizations, your students can quickly generate fairly accurate portrayals of the IS plan. In fact, your students are likely to provide accurate, interesting, and useful information to the IS manager when presenting the outline to him.

4.25. This is a useful exercise and is easy to complete. Using a university as an example, sample locations include the main campus, additional campuses, distance learning locations, an off-campus business incubator, and, if the university is part of a state system, a chancellor‘s office. Some of the units include academic colleges (e.g., the School or College of Business), academic administration (e.g., Registrar‘s Office), and business units (e.g., Plant and Equipment). In addition, a university has many functions, processes, and data entities. A university has functions, processes, and data entities similar to a business organization. Additionally, the university has functions, processes, and data entities not found in a business setting. For example, one function is having students register for classes. One process for this function is students requesting classes.

Data entities include student, course, and instructor. Ask your students to compare their planning matrices, particularly if they have chosen similar organizations.

1.94.

1.95.

1.96.

4.26 Require your students to write their own versions of the mission statements before reading the actual mission statements. Students are likely to already know a lot about these organizations and their missions simply by listening, watching, and reading the organizations‘ advertisements. Advertisements often give us a very accurate, current summary of the organization‘s mission. Thus, students are likely to write fairly accurate mission statements for these three large, prominent organizations. Encourage the students to share their ideas on what information systems would be useful to help these organizations achieve their respective missions. Are there any differences in the types of systems that would be useful to these organizations? The URLs for Microsoft, Apple, and Facebook are http://www.microsoft.com, https://apple.com, and https://about.meta.com/.

2 Copyright © 2025 Pearson Education, Inc.

1.97.

4.27. Students are likely to find a variety of ways that information systems projects are identified. Project identification methods range from informal to formal and the origins of requests come from a variety of places. How information systems projects are identified tells us a lot about how the broader organization is managed and the value that is placed on information systems.

Chapter 5 Initiating and Planning Systems Development Projects Chapter Overview Chapter 5 introduces students to project initiation and planning. Project initiation includes those activities that assist in organizing a team to conduct project planning. During project initiation, one or more analysts work with a customer to establish work standards and communication procedures. Project planning is the process of defining clear, discrete activities and the work needed to complete each activity. The project charter is the document that initiates the project and this document is critical to the planning process and indeed to the systems project as a whole. The project charter is the final document produced at the end of project initiation, shown at the end of the process in Table 5-1. The objective of the project planning process is the development of a baseline project plan (BPP) and the project scope statement (PSS), shown at the end of the process in Table 5-2. The BPP becomes the foundation for the remainder of the development project. The PSS produced by the team clearly outlines the objectives and constraints of the project. The size, scope, and complexity of a project dictate the comprehensiveness of the project planning process and resulting documents, similar to the project initiation process. In the real world, many of these documents might be combined or in very short informal projects the project charter may serve all of these purposes. All of the documentation and processes referred to in Chapters 3 and 4 are referenced from the Project Management Body of Knowledge (PMBOK, 2021) produced by the Project Management Institute.

An important aspect of the project initiation and planning process focuses on the assessment of a project‘s feasibility and risk. Chapter 5 describes several types of feasibility, including economic, technical, operational, schedule, legal and contractual, and political. Students will find that the economic feasibility assessment techniques described in this chapter are similar to techniques they learned in a prior managerial accounting or finance course. Other forms of feasibility assessment are likely to be new. The extent to which you focus on each aspect of feasibility is influenced by your overall curriculum.

Pine Valley Furniture‘s WebStore is used to demonstrate how initiating and planning systems development projects for Internet-based applications are similar to more traditional systems development activities. This section briefly discusses how Jim Woo and Jackie Judson initiate and plan PVF‘s WebStore.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 68. Illustrate the steps involved in the project initiation and planning process.

69. Explain the need for and describe the contents of a project scope statement and baseline project plan.

3 Copyright © 2025 Pearson Education, Inc.

70. Provide a comprehensive overview of the various methods for assessing project feasibility.

71. Explain the differences between tangible and intangible benefits and costs and between one-time and recurring benefits and costs.

4 Copyright © 2025 Pearson Education, Inc.

72. Illustrate how to perform cost-benefit analysis and describe what is meant by the time value of money, present value, discount rate, net present value, return on investment, and break-even analysis.

73. Describe how to evaluate the technical risks associated with a systems development project.

74. Explain the activities and participant roles within a structured walkthrough.

75. Prepare your students to develop a plan for conducting a term project involving several phases of systems development using the SDLC or other methodologies.

76. Compare and contrast the initiation and planning of Internet-based electronic commerce applications to the initiation and planning process for more traditional applications.

Classroom Ideas 77. Chapter 5 introduces several concepts and terms central to understanding the project initiation and planning process. Ask your students to review this chapter‘s key terms. Use Review Question 5.1 to assess whether your students understand the chapter material.

78. Secure an IT executive at a company that goes through some of the same processes and activities referred to in the text and have them give a lecture or presentation to the company.

Be sure to alert the students so they have a chance to put together pertinent questions for the speaker.

79. During your lecture, use the tables and figures in this chapter to illustrate the major concepts.

Link the processes described in the chapter to a specific example, such as Pine Valley Furniture. This is a good way for students to understand the chapter‘s more abstract concepts.

Given the interrelatedness of Chapters 5 and 6, you may want to blend the tables and figures from these chapters. As part of your lecture, have students suggest various costs and benefits that might arise with specific systems. One alternative is to briefly describe a systems development project with which you have been involved and ask the students to list the possible costs, benefits, and risks that would be part of a feasibility assessment for that system.

80. An alternative to lecturing on this chapter is to lecture from the Review Questions, Problems and Exercises, and Field Exercises. Pose selected questions to your students, focusing the discussion on specific, important concepts. Problems and Exercises 5.12-5.16 are good problems to work on in class.

81. Another very effective in-class exercise is to ask students who have been on systems development teams to compare their experiences to the concepts presented in Chapter 5. This discussion is a good method for elaborating on alternative ways for identifying and selecting information systems projects. This comparison can be done through discussions of Field Exercises 5.30-5.33.

82. If you have access to practicing systems analysts, an insightful activity is to invite them into your class to discuss how they initiate and plan projects in their organizations. Ask them to provide certain types of documentation, such as the Table of Contents for the equivalent of the baseline project plan and statement of work, project schedules and work descriptions, feasibility tables or spreadsheets, and team organization descriptions. Some organizations have formal documents called business cases that must accompany any project request; if possible, ask your guests to outline what their organizations consider to be the ideal format for a business case.

83. Discuss with your students the viability of economic feasibility assessments. How accurate and helpful are classical cost-benefit analyses of information systems? What measures of 5 Copyright © 2025 Pearson Education, Inc.

economic worth apply to systems projects? Should information systems be treated as investments, necessary costs, enablers of change, or otherwise? Information Economics by M.M. Parker and R.J. Benson, listed in the References section at the end of the chapter, provides several good ideas on alternative ways for viewing the economics of information systems. You may wish to locate more recent publications in both trade and academic publications, since this is a recurring topic in our literature. Feasibility is often discussed in the introductory MIS class, so link this topic to what students have studied in prior courses.

Remind your students that even when classical economic feasibility is assessed at this stage of a project, often only categories of costs and benefits, not actual dollar values, can be fixed at this point. The incremental commitment and frequent review nature of systems projects means that the economic feasibility (as well as other feasibilities) are reassessed at each project review point, with a decision to continue, redirect, or terminate the project as an outcome.

84. Ask your students to identify several different types of businesses. Next, ask your students to identify Internet-based electronic commerce applications for these businesses. Using the feasibility criteria presented in this chapter, ask your students to justify the development of these applications.

85. Have your students use one of the above scenarios or if you are using ―real‖ external service-learning projects, they could form the basis for a walkthrough presented to the class, using the guidelines given in Table 5-8.

Answers to Key Terms Suggested answers are provided below.

86. Baseline Project Plan (BPP): A major outcome and deliverable from the project initiation and planning phase that contains the best estimate of a project‘s scope, benefits, costs, risks, and resource requirements.

87. Break-even analysis: A type of cost–benefit analysis to identify at what point (if ever) benefits equal costs.

88. Business case: The justification for an information system, presented in terms of the tangible and intangible economic benefits and costs and the technical and organizational feasibility of the proposed system.

89. Discount rate: The rate of return used to compute the present value of future cash flows.

90. Economic feasibility: A process of identifying the financial benefits and costs associated with a development project.

91. Intangible benefit: A benefit derived from the creation of an information system that cannot be easily measured in dollars or with certainty.

92. Intangible cost: A cost associated with an information system that cannot be easily measured in terms of dollars or with certainty.

93. Legal and contractual feasibility: The process of assessing potential legal and contractual ramifications due to the construction of a system.

94. One-time cost: A cost associated with project start-up and development or system start-up.

95. Operational feasibility: The process of assessing the degree to which a proposed system solves business problems or takes advantage of business opportunities.

96. Political feasibility: The process of evaluating how key stakeholders within the organization view the proposed system.

6 Copyright © 2025 Pearson Education, Inc.

97. Present value: The current value of a future cash flow.

98. Project Scope Statement (PSS): A document prepared for the customer that describes what the project will deliver and outlines generally at a high level all work required to complete the project.

99. Recurring cost: A cost resulting from the ongoing evolution and use of a system.

100. Schedule feasibility: The process of assessing the degree to which the potential time frame and completion dates for all major activities within a project meet organizational deadlines and constraints for affecting change.

101. Tangible benefit: A benefit derived from the creation of an information system that can be measured in dollars and with certainty.

102. Tangible cost: A cost associated with an information system that can be measured in dollars and with certainty.

103. Technical feasibility: A process of assessing the development organization‘s ability to construct a proposed system.

104. Time Value of Money (TVM): The concept that money available today is worth more than the same amount tomorrow.

105. Total cost of ownership (TCO): The cost of owning and operating a system, including the total cost of acquisition, as well as all costs associated with its ongoing use and maintenance.

106. Walk-through: A peer group review of any product created during the systems development process; also called a structured walk-through.

Answers to Review Questions 1.98.

5.1. a. Break-even analysis discovers at what point in time benefits equal the total cost of investment. The present value represents the current value of a future cash flow. The net present value uses a discount rate, determined from the company‘s cost of capital, to establish the present value of a project. The return on investment is the ratio of the net cash receipts of the project divided by the cash outlays of the project. b. Economic feasibility identifies the financial benefits and costs associated with a development project. Legal and contractual feasibility assesses potential legal and contractual ramifications due to the construction of a system. Operational feasibility assesses the degree to which a proposed system solves business problems or takes advantage of business opportunities. Political feasibility evaluates how key stakeholders within the organization view the proposed system. Schedule feasibility determines the degree to which the potential time frame and completion dates for all major activities within a project meet organizational deadlines and constraints for affecting change. c. Intangible benefits are derived from the creation of an information system that cannot be easily measured in dollars or with certainty. Tangible benefits are derived from the creation of an information system that can be measured in dollars and with certainty. d. Intangible costs are costs associated with an information system that cannot be easily measured in terms of dollars or with certainty. Tangible costs are those costs associated with an information system that can be measured in dollars and with certainty.

7 Copyright © 2025 Pearson Education, Inc.

1.99.

5.2.

Project initiation focuses on activities that assist in organizing a team to conduct project planning. The types of activities performed during project initiation are listed in Table 5-1. Project planning is the process of defining clear, discrete activities and the work needed to complete each activity within a single project. The objective of the project planning process is the development of a baseline project plan (BPP) and a project scope statement (PSS). The range of activities performed during project planning is shown in Table 5-2.

1.100.

5.3.

The baseline project plan (BPP) contains all information collected and analyzed during project initiation and planning. The plan reflects the best estimate of the project‘s scope, benefits, costs, risks, and resource requirements given the current understanding of the project. The BPP specifies detailed project activities for the next life cycle phase, analysis, and less detail for subsequent project phases (these depend on the results of the analysis phase). The content and format of a BPP depends on the size, complexity, and standards of an organization; therefore, plans may differ widely in format and content even within a single organization across multiple projects.

1.101.

5.4.

Three commonly used methods for performing economic cost-benefit analysis are 1) net present value (NPV), return on investment (ROI), and break-even analysis (BEA). These methods are listed and described in Table 5-6. NPV uses a discount rate determined from the company‘s cost of capital to establish the present value of a project.

ROI is the ratio of the net cash receipts of the project divided by the cash outlays of the project. BEA finds the amount of time required for the cumulative cash flow from a project to equal its initial and ongoing investment.

1.102.

5.5.

The project feasibility factors are economic, technical, operational, schedule, legal and contractual, and political. Economic feasibility identifies the financial benefits and costs associated with a development project. Technical feasibility assesses the development organization‘s ability to construct a proposed system. Operational feasibility assesses the degree to which a proposed system solves business problems or takes advantage of business opportunities. Schedule feasibility determines the degree to which the potential time frame and completion dates for all major activities within a project meet organizational deadlines and constraints for affecting change. Legal and contractual feasibility assesses potential legal and contractual ramifications due to the construction of a system. Political feasibility evaluates how key stakeholders within the organization view the proposed system. No one factor is ―most‖ important; one factor may be more important in some situations, whereas another factor is more important in other situations.

1.103.

5.6.

The potential consequences of not assessing and managing technical risks include failure to attain expected benefits from the project, inaccurate project cost estimates, inaccurate project duration estimates, failure to achieve adequate system performance levels, and failure to adequately integrate the new system with existing hardware, software, or organizational procedures. The most serious consequence would be project failure or abandonment in the middle of the project.

1.104.

5.7.

Numerous factors are used to assess a project‘s risk, including project size, project structure and familiarity of the development group with similar systems and technology, and the familiarity of the user group with the systems development process.

Table 5-7 lists and describes these risk factors in more detail.

1.105.

5.8.

The two primary benefit categories from an IS project are tangible benefits and intangible benefits. Tangible benefits are benefits derived from the creation of an information system that can be measured in dollars and with certainty. Intangible benefits are benefits derived from the creation of an information system that cannot be easily 8 Copyright © 2025 Pearson Education, Inc.

measured in dollars or with certainty.

1.106.

5.9.

Intangible benefits are derived from the creation of an information system and cannot be easily measured in dollars or with certainty. Competitive necessity, more timely information, improved organizational planning, and increased organizational flexibility are four possible intangible benefits. Additional intangible benefits are listed in Table 5-3. Some intangible benefits may also be unique to a specific project or industry, which is why it is important to fully understand the organizational environment in which the system will be operated.

1.107.

5.10. The time value of money (TVM) refers to the concept of comparing present cash outlays to future expected returns. A dollar today is worth more than a dollar one year from today because money can be invested. The rate at which money can be borrowed or invested is called the cost of capital and is called the discount rate for TVM calculations.

1.108.

5.11. A structured walkthrough occurs when a peer group systematically reviews a product created during the systems development process. The objective of this review is to assure that the product conforms to organizational standards and that all relevant parties understand and agree with the information contained in the product (e.g., a baseline project plan). Most walkthroughs are not rigidly formal or exceedingly long in duration. It is important, however, that a specific agenda be established for the walkthrough so that all attendees understand what is to be covered and the expected completion time.

At walkthrough meetings, individuals play specific roles. A coordinator plans the meeting and facilitates a smooth meeting process. This person may be the project leader or a lead analyst responsible for the current life cycle step. The presenter describes the work product to the group. The presenter is usually an analyst who has done all or some of the work being presented. A user (or group) assures that the work product meets the needs of the project‘s customers. This user would usually be someone not on the project team. A secretary takes notes and records decisions, or recommendations made by the group. This may be a clerk assigned to the project team, or it may be one of the analysts on the team. The standards bearer assures that the work product adheres to the organization‘s technical standards. Many larger organizations have staff groups within the unit responsible for establishing standard procedures, methods, and documentation formats. These standards bearers validate the work so that others can use it in the development organization. A maintenance oracle reviews the work product in terms of future maintenance activities. The goal is to make the system and its documentation easy to maintain.

1.109.

Answers to Problems and Exercises 1.110.

5.12. This is a small project and should not take long to complete. If your students‘ familiarity with PCs is moderate to high, or if they have the help of someone who is familiar with buying and installing PCs, then the risk for this project is relatively low.

Risks can arise when leading-edge technology is selected. For example, as this book is finalized, Windows 11 has been released. Ask your students to comment on how reliable Windows 11 is compared to Windows 10 and the risk accepted by early adopters of the newer operating system.

1.111.

5.13. Use of a PC at work provides several tangible benefits. For one, it helps reduce labor costs. For example, documents can be prepared, edited, and copied faster with a PC and word processing software than without this equipment. The use of a word processor and spreadsheet helps reduce errors in spelling and in calculations. If the right software is used, spreadsheets and graphics can be embedded within word processing documents, 9 Copyright © 2025 Pearson Education, Inc.

allowing greater flexibility in creating and integrating documents. File and network management software allows greater control over work quality and workflow. Use of project management software helps improve resource control and project outcome quality. For example, spreadsheet analysis helps shorten and strengthen the decisionmaking process. Given these tangible benefits, the use of a PC seems beneficial.

10 Copyright © 2025 Pearson Education, Inc.

1.112.

Use of a PC at work provides several intangible benefits. For one it can increase employee morale and customer satisfaction as processes will be smoother, faster, and less error prone. Better decisions can result from what-if analysis using spreadsheets and other software to help explore additional alternatives, which can also lead to increased confidence and ability to assess multiple situations efficiently. New employees can more easily be trained as processes are streamlined and embedded in systems, thus they can more easily learn and understand the business. Database software and accompanying forms, reports, and query results can provide information that would otherwise not be available and in a timelier manner, which can also improve marketing, decision making, and customer service response time. Increases in efficiency and effectiveness of processes can free employees from mundane, routine tasks and give them more time to think and thus enlarge the intellectual and knowledge aspects of their jobs, which can lead to increased innovation, creativity, and job satisfaction. Given these intangible benefits, the use of a PC seems beneficial.

1.113.

The analysis of intangible benefits supports that done for tangible benefits as the two types of benefits are complementary. Given both the tangible and intangible benefits and the interplay between them, the use of a PC seems very beneficial.

1.114.

5.14. There are several one-time costs, including equipment purchase or lease, equipment installation, hardware and software, and disruption to the rest of the organization. The purchase of the equipment (Web server, cabling, installation, and software) presents substantial one-time costs. Structural modifications to the facilities where the server will reside may be required (electrical outlets, cooling, lighting, door locks, and other security devices). These possible structural modifications represent one-time costs. Recurring costs include the costs of maintaining and replacing equipment and software, updating the Web site, renewing the domain names, and for the personnel required to fulfill these tasks.

1.115.

5.15. Students should estimate, as best they can, the dollar figures for each of the costs they described in their answer for Question 5.14. In addition, they should quantify, as best they can, the benefits from such a system. They should then present an analysis with each of the items provided in the spreadsheet for the previous question. Let us assume that the one-time costs of implementing the Web site are $50,000 and the recurring costs are $10,000 per year. Assume the benefits are $40,000 per year. The following spreadsheet analysis provides an economic summary of this situation.

11 Copyright © 2025 Pearson Education, Inc.

Net Economic Benefit Discount Rate (.12) PV Benefits

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals $ $ 40,000 $ 40,000 $ 40,000 $ 40,000 $ 40,000 1.00 0.89 0.80 0.71 0.64 0.62 0 $ 35,714 $ 31,888 $ 28,471 $ 25,421 $ 24,837

NPV of all Benefits

0 $

35,714 $

67,602 $

96,073 $

121,494 $

146,331 $ 146,331

One-time Costs Recurring Costs Discount Rate (.12) PV of Recurring Costs

$ (50,000) $ $ 1.00 $ $

(10,000) $ 0.89 (8,929) $

(10,000) $ 0.80 (7,972) $

(10,000) $ 0.71 (7,118) $

(10,000) $ 0.64 (6,355) $

(10,000) 0.62 (6,209)

NPV of all Costs

$ (50,000) $

(58,929) $

(66,901) $

(74,018) $

(80,373) $

(86,583) $ (86,583)

Overall NPV

$ 59,748

Overall ROI

0.69

Break-Even Analysis Yearly NPV Cash Flow $ (50,000) $ Overall NPV Cash Flow $ (50,000) $

(23,214) $ (73,214) $

702 $ (72,513) $

22,055 $ (50,458) $

41,120 $ (9,337) $

59,748 50,411

Break Even Occurs between year 4 and 5 Use first year of positive cash flow to calculate break-even fraction Actual Break Even

1.116.

5.16

0.156 4.16 years

The following is a sample project scope statement for the new Web site.

Rick’s Computers

Prepared by: John Won

Project Scope Statement

Date: September 10, 20XX

General Project Information Project Name: Sponsor: Project Manager:

Web site Development Lisa Lee, CIO John Woo, PMP

Problem/Opportunity Statement: The current Web server hosted by another company is not functioning well and is difficult to develop on without direct access.

Project Objective: To enable the developers to have direct access to a Web server to maintain uptime, access logs, and host multiple Web sites.

12 Copyright © 2025 Pearson Education, Inc.

Project Description: A new Web server will be bought, cabling and connected to the Internet. Another workstation will be added for development and administration purposes. The project will follow typical project practices.

Business Benefits: Improve uptime of the Web sites Allow developers direct access to the Web server for complex coding tasks All to develop multiple Web sites Project Deliverables: Web server systems analysis and design Web server documentations Functioning Web site on equipment Administration workstation completed Estimated Project Duration: 1 Month 1.117.

5.17. The following spreadsheet summarizes the economic analysis requested in this question.

Net Economic Benefit Discount Rate (.12) PV Benefits NPV of all Benefits

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals $ $ 85,000 $ 85,000 $ 85,000 $ 85,000 $ 85,000 1.00 0.89 0.80 0.71 0.64 0.62 0 $ 75,893 $ 67,761 $ 60,501 $ 54,019 $ 52,778 0 $

75,893 $

143,654 $

204,156 $

258,175 $

310,953 $ 310,953

One-time Costs Recurring Costs Discount Rate (.12) PV of Recurring Costs

$ (75,000) $ $ 1 $ $

(35,000) $ 0.91 (31,818) $

(35,000) $ 0.83 (28,926) $

(35,000) $ 0.75 (26,296) $

(35,000) $ 0.68 (23,905) $

(35,000) 0.62 (21,732)

NPV of all Costs

$ (75,000) $ (106,818) $ (135,744) $ (162,040) $ (185,945) $ (207,678) $ (207,678)

Overall NPV

$ 103,275

Overall ROI

0.50

Break-Even Analysis Yearly NPV Cash Flow $ (75,000) $ (30,925) $ Overall NPV Cash Flow $ (75,000) $ (105,925) $

7,911 $ (98,015) $

42,116 $ (55,899) $

Break Even Occurs between year 3and 4 Use first year of positive cash flow to calculate break-even fraction Actual Break Even

13 Copyright © 2025 Pearson Education, Inc.

72,229 $ 16,330 $

103,275 119,606

0.774 3.77 years

1.118.

5.18

The baseline project plan Report is as follows.

BASELINE PROJECT PLAN REPORT

1.0 Introduction A. Project Overview – The current Web server hosted by another company is not functioning well and is difficult to develop on without direct access.

B. Recommendation – A full analysis and design process needs to be undertaken before the equipment is purchased.

2.0 Systems Description A. Alternative – Using hosted or cloud-based systems are possible.

B. System Description – A new Web server will be bought, cabling and connected to the Internet. Another workstation will be added for development and administration purposes. The project will follow typical project practices.

3.0 Feasibility Assessment A. Economic Analysis – The project will break even in 3.77 years and have an NPV of 103,275 after five years. Further, the ROI is 0.50.

B. Technical Analysis – There are several risk factors for this project. The most significant is developing a Web server that will have problems and disrupt business, especially our online business.

C. Operation Analysis – This project solves two main business problems. First, our current Web solution is not reliable and fails often. Second, it will allow us to create unique applications for our Web site.

D. Legal and Contractual Analysis – there are limited legal issues with this project.

E. Political Analysis – Stakeholders with a relationship to the current Web host provider must be consulted in this process for their buy-in.

F. Schedule, Time Line, and Resource Analysis – We hope to launch this project in the next two weeks and the project should take one month.

4.0 Management Issues A. Team Configuration and Management – A project team will be set up with Jim Won managing the team and the project. The team includes two Web site developers and a network engineer.

B. Communication Plan – A complete communication matrix will be developed so all stakeholders will evaluate and accept changes.

C. Project Standards and Procedures – A steering committee will meet weekly to determine how the project will be evaluated and then subsequently do these evaluations.

14 Copyright © 2025 Pearson Education, Inc.

1.119.

5.19.

The discount rate is now 10%.

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals Net Economic Benefit $ $ 85,000 $ 85,000 $ 85,000 $ 85,000 $ 85,000 Discount Rate (.10) 1.00 0.91 0.83 0.75 0.68 0.62 PV Benefits 0 $ 77,273 $ 70,248 $ 63,862 $ 58,056 $ 52,778 NPV of all Benefits

0 $

77,273 $

147,521 $

211,382 $

269,439 $

322,217 $ 322,217

One-time Costs Recurring Costs Discount Rate (.10) PV of Recurring Costs

$ (75,000) $ $ 1 $ $

(35,000) $ 0.91 (31,818) $

(35,000) $ 0.83 (28,926) $

(35,000) $ 0.75 (26,296) $

(35,000) $ 0.68 (23,905) $

(35,000) 0.62 (21,732)

NPV of all Costs

$ (75,000) $ (106,818) $ (135,744) $ (162,040) $ (185,945) $ (207,678) $ (207,678)

Overall NPV

$ 114,539

Overall ROI

0.55

Break-Even Analysis Yearly NPV Cash Flow $ (75,000) $ (29,545) $ Overall NPV Cash Flow $ (75,000) $ (104,545) $

11,777 $ (92,769) $

49,343 $ (43,426) $

Break Even Occurs between year 3 and 4 Use first year of positive cash flow to calculate break-even fraction Actual Break Even

15 Copyright © 2025 Pearson Education, Inc.

83,493 $ 40,067 $

114,539 154,607

0.520 3.52 years

1.120.

5.20.

The recurring costs are now $40,000.

Net Economic Benefit Discount Rate (.10) PV Benefits NPV of all Benefits

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals $ $ 85,000 $ 85,000 $ 85,000 $ 85,000 $ 85,000 1.00 0.91 0.83 0.75 0.68 0.62 0 $ 77,273 $ 70,248 $ 63,862 $ 58,056 $ 52,778 0 $

77,273 $

147,521 $

211,382 $

269,439 $

322,217 $ 322,217

One-time Costs Recurring Costs Discount Rate (.10) PV of Recurring Costs

$ (75,000) $ $ 1 $ $

(40,000) $ 0.91 (36,364) $

(40,000) $ 0.83 (33,058) $

(40,000) $ 0.75 (30,053) $

(40,000) $ 0.68 (27,321) $

(40,000) 0.62 (24,837)

NPV of all Costs

$ (75,000) $ (111,364) $ (144,421) $ (174,474) $ (201,795) $ (226,631) $ (226,631)

Overall NPV

$ 95,585

Overall ROI

0.42

Break-Even Analysis Yearly NPV Cash Flow $ (75,000) $ (34,091) $ 3,099 $ Overall NPV Cash Flow $ (75,000) $ (109,091) $ (105,992) $

36,908 $ (69,083) $

Break Even Occurs between 4 and 5 Use first year of positive cash flow to calculate break-even fraction Actual Break Even

16 Copyright © 2025 Pearson Education, Inc.

67,644 $ (1,439) $

95,585 94,146

0.015 4.02 years

1.121.

5.21.

The year time horizon was changed to 3 years

Year 0 Year 1 Year 2 Year 3 Totals Net Economic Benefit $ $ 85,000 $ 85,000 $ 85,000 Discount Rate (.10) 1.00 0.91 0.83 0.75 PV Benefits 0 $ 77,273 $ 70,248 $ 63,862 NPV of all Benefits

0 $

77,273 $

147,521 $

211,382 $ 211,382

One-time Costs Recurring Costs Discount Rate (.10) PV of Recurring Costs

$ (75,000) $ $ 1 $ $

(40,000) $ 0.91 (36,364) $

(40,000) $ 0.83 (33,058) $

(40,000) 0.75 (30,053)

NPV of all Costs

$ (75,000) $ (111,364) $ (144,421) $ (174,474) $ (174,474)

Overall NPV

$ 36,908

Overall ROI

0.21

Break-Even Analysis Yearly NPV Cash Flow $ (75,000) $ (34,091) $ 3,099 $ Overall NPV Cash Flow $ (75,000) $ (109,091) $ (105,992) $ Break Even Does not occur

17 Copyright © 2025 Pearson Education, Inc.

36,908 (69,083)

1.122.

5.22.

The analysis is as follows.

Net Economic Benefit Discount Rate (.11) PV Benefits

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals $ $ 50,000 $ 60,000 $ 70,000 $ 80,000 $ 90,000 1.00 0.90 0.81 0.73 0.66 0.59 0 $ 45,045 $ 48,697 $ 51,183 $ 52,698 $ 53,411

NPV of all Benefits

0 $

45,045 $

93,742 $

144,926 $

197,624 $

251,035 $ 251,035

One-time Costs Recurring Costs Discount Rate (.11) PV of Recurring Costs

$ (80,000) $ $ 1.00 $ $

(45,000) $ 0.90 (40,541) $

(45,000) $ 0.81 (36,523) $

(45,000) $ 0.73 (32,904) $

(45,000) $ 0.66 (29,643) $

(45,000) 0.59 (26,705)

NPV of all Costs

$ (80,000) $ (120,541) $ (157,064) $ (189,967) $ (219,610) $ (246,315) $ (246,315)

Overall NPV

$

4,720

Overall ROI

0.02

Break-Even Analysis Yearly NPV Cash Flow $ (80,000) $ (75,495) $ (63,321) $ (45,041) $ (21,986) $ 4,720 Overall NPV Cash Flow $ (80,000) $ (155,495) $ (218,817) $ (263,858) $ (285,844) $ (281,124) Break Even Does not occur

1.123.

5.23.

12% discount

Net Economic Benefit Discount Rate (.12) PV Benefits

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals $ $ 50,000 $ 60,000 $ 70,000 $ 80,000 $ 90,000 1.00 0.89 0.80 0.71 0.64 0.57 0 $ 44,643 $ 47,832 $ 49,825 $ 50,841 $ 51,068

NPV of all Benefits

0 $

44,643 $

92,474 $

142,299 $

193,141 $

244,209 $ 244,209

One-time Costs Recurring Costs Discount Rate (.12) PV of Recurring Costs

$ (80,000) $ $ 1.00 $ $

(45,000) $ 0.89 (40,179) $

(45,000) $ 0.80 (35,874) $

(45,000) $ 0.71 (32,030) $

(45,000) $ 0.64 (28,598) $

(45,000) 0.57 (25,534)

NPV of all Costs

$ (80,000) $ (120,179) $ (156,052) $ (188,082) $ (216,681) $ (242,215) $ (242,215)

Overall NPV

$

Overall ROI

1,994 0.01

Break-Even Analysis Yearly NPV Cash Flow $ (80,000) $ (75,536) $ (63,578) $ (45,783) $ (23,540) $ 1,994 Overall NPV Cash Flow $ (80,000) $ (155,536) $ (219,114) $ (264,897) $ (288,437) $ (286,443) Break Even Does not occur

18 Copyright © 2025 Pearson Education, Inc.

1.124.

5.24.

Recurring costs are $40,000.

Net Economic Benefit Discount Rate (.12) PV Benefits

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Totals $ $ 50,000 $ 60,000 $ 70,000 $ 80,000 $ 90,000 1.00 0.89 0.80 0.71 0.64 0.57 0 $ 44,643 $ 47,832 $ 49,825 $ 50,841 $ 51,068

NPV of all Benefits

0 $

44,643 $

92,474 $

142,299 $

193,141 $

244,209 $ 244,209

One-time Costs Recurring Costs Discount Rate (.12) PV of Recurring Costs

$ (80,000) $ $ 1.00 $ $

(40,000) $ 0.89 (35,714) $

(40,000) $ 0.80 (31,888) $

(40,000) $ 0.71 (28,471) $

(40,000) $ 0.64 (25,421) $

(40,000) 0.57 (22,697)

NPV of all Costs

$ (80,000) $ (115,714) $ (147,602) $ (176,073) $ (201,494) $ (224,191) $ (224,191)

Overall NPV

$ 20,018

Overall ROI

0.09

Break-Even Analysis Yearly NPV Cash Flow $ (80,000) $ (71,071) $ (55,128) $ (33,774) $ (8,353) $ 20,018 Overall NPV Cash Flow $ (80,000) $ (151,071) $ (206,199) $ (239,973) $ (248,327) $ (228,309) Break Even Does not occur

1.125.

5.25.

1.126.

The Web site needs to be functional and running exclusively on the equipment purchased. The system is to include a Web server, plus one workstation to develop and administer the Web server. At this point there are no foreseeable constraints to implementing the system.

1.127.

It is important that this initial section of the baseline project plan be complete, accurate, and understood by all. Otherwise, there might be disagreements later about what this system will entail, and an inadequate or unwanted system might be implemented.

1.128.

5.26. For the system described above, alternative configurations could use cloud and proven hosting systems. At first glance, this system seems to be highly feasible, but the alternative needs to be considered.

5.27. This system seems to be feasible from an economic perspective. The initial costs are significant, but they are far outweighed by the tangible and intangible benefits that this system will provide. This system is relatively easy to implement, and the technology it uses is very stable, so the system is technically feasible. The skills required among personnel may be new, so there may be some risk of the technical staff having difficulties understanding multi-user operating systems. The system solves the business problem well and will not change day-to-day activities adversely. Thus, the system is operationally feasible. As long as software is used legally and is not copied illegally, the system should present no legal or contractual problems.

1.129.

1.130.

Students should submit an answer similar to the following:

5.28. Assume there are four members on this team. The team consists of a project leader, who is a senior systems analyst, a junior developer, a senior developer, and 19 Copyright © 2025 Pearson Education, Inc.

network administrator. The two developers will work primarily with getting the Web pages up and running on the system. The network administrator will optimize, back up, and generally manage the Web environment. The team also agrees to follow the systems development guidelines established by the organization and use hardware and software supported by the company, when possible.

1.131.

People sometimes feel that these project management steps are a waste of time because they do not contribute directly to the completion of the project. However, setting these ground rules for who will work on the project and how they will work together is very important. Without this agreement, conflicts may occur later, which may adversely affect the success and timely completion of the project. Such agreements manage everyone‘s expectations and lead to greater satisfaction with the project.

Guidelines for Using the Field Exercises 1.132.

1.133.

1.134.

5.29. Students should be able to present a project overview, recommendation, alternatives, and system description for nearly any project they are considering. This question demonstrates that the baseline project plan is robust and useful for planning nearly any project.

5.30. Similarly, the students should be able to discuss their projects in terms of the feasibility categories. Ask your students to share feasibility information for their projects with the class. This activity demonstrates that feasibility issues are important for all projects, whether they involve systems or not.

5.31. The baseline project plans will vary slightly from this chapter‘s baseline project plan. However, each plan is likely to be comprised of the same basic elements. Students will notice that these plans are modified in various ways during the life of the projects. It is best to think of these plans as a set of flexible guidelines rather than a set of rigid operating procedures that are etched in stone. Project planning should be flexible. The point of a plan is to guide and prepare, not to constrain.

1.135.

5.32. Most PC-based software packages have a licensing agreement that permits the purchaser to use one copy of the software on any single computer, provided the software is in use on only one computer at any time. If an organization has multiple licenses for the software, then at any time the organization may have as many copies of the software in use as they have licenses. The software is typically considered in use on a computer when it is loaded into the temporary memory (i.e., RAM) or installed into the permanent memory (e.g., hard disk or other storage device). Some software vendors allow that if the software is permanently installed on the hard disk or other storage device of a computer and one person uses that computer more than 80% of the time it is in use, then that person may also use the software on a portable or home computer. Some software vendors also allow the purchaser to make one back-up copy of the original software. Organizations frequently purchase site licenses that allow them to make and use multiple copies of software. Software vendors vary on the strictness of their licensing agreements. However, over the past few years, software vendors have become stricter with licensing agreements and infringements throughout business, education, and government.

1.136.

5.33. Students are likely to find a variety of ways that information systems projects are initiated. Sometimes the initiation comes from users, managers of users, or systems personnel. In addition, project initiation is relatively informal in some organizations, whereas in other organizations the process is relatively formal. It is useful for students to compare their answers and see the variety of ways that this task is completed. Have your students discuss the relative merits of these various initiation methods.

20 Copyright © 2025 Pearson Education, Inc.

1.137.

5.34. Students are likely to find organizations that develop information systems quickly and/or in an ad hoc fashion. In these settings the systems personnel are probably under great pressure to build systems as quickly as possible. Under such pressure, there is little or no time for planning. Alternatively, it may be that there is planning, but that it happens on the back of envelopes or in the minds of the systems personnel. It is useful for students to compare their answers to this question and discuss the potential disadvantages of this lack of planning and the reasons why systems personnel develop systems in this way.

Chapter 6 Determining System Requirements Chapter Overview Chapter 6 introduces students to several methods that systems analysts use to determine requirements for a proposed system. This chapter categorizes the requirements gathering techniques as traditional or radical. It also introduces Agile methodologies. Traditional requirements gathering techniques include interviews, questionnaires, nominal group technique, observations, and evolutionary and throwaway prototyping. Business process reengineering (BPR) and the use of disruptive technologies are radical methods for determining system requirements. This chapter concludes with an illustration of how system requirements are determined for Internet-based electronic commerce applications.

After studying this chapter, students should have an appreciation for the different types of requirements analysts collect and the different methods they use to collect these requirements.

However, reading about and discussing how analysts collect requirements is no substitute for direct hands-on experience with these techniques. Most of the classroom suggestions listed below involve some type of hands-on experience for students. You probably will not have time to use all these suggestions in class. However, try to use one or two of these classroom ideas.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 107. Provide insight into using interviews to determine system requirements and include the preparation of an interview plan.

108. Show students how questionnaires are designed, distributed, and used to determine system requirements.

109. Discuss the advantages and disadvantages of observing workers to determine system requirements.

110. Demonstrate how the analysis of business documents provides system requirements information.

111.

Show how prototyping is used for requirements determination.

112.

Stress that BPR involves more than just tweaking or automating processes.

113.

Illustrate how disruptive technologies enable the breaking of long-held business rules.

114.

Discuss Agile methodologies and how these can be used for requirements determination.

21 Copyright © 2025 Pearson Education, Inc.

115. Discuss the system requirements determination process for Internet-based electronic commerce applications.

Classroom Ideas 116. Point out that, while requirements determination tools and techniques are valuable in the analysis phase, analysts benefit from their use in other phases of the life cycle. Demonstrate this with examples from other phases. For example, prototyping will enable you to quickly convert basic requirements into a working, though limited, version of the desired information system. Also, observation is useful during system implementation to verify that the new system is being used as expected.

117. Use Figure 6-2 to show how to construct an interview plan. Construct a plan with students during class and have them generate similar plans as homework.

118. Use Field Exercise 6-18 and 6-19 as an in-class exercise. This exercise typically takes about one hour to complete, including time for discussion of the results. Students can submit their reports at the next class meeting.

119. Use the box ―Lost Soft Drink Sales‖ as a starting point for a class discussion on the advantages and disadvantages of direct observation. You may want to expand the discussion of direct observation, especially if you have experience as an action researcher, since the methods are similar. You can discuss using confederates, how to avoid observer biases, and other issues you consider important. Often students are reluctant to use direct observation and should be encouraged to consider it equal to interviewing.

120. Figures 6-3 (example procedure), 6-4 (example invoice), and 6-5 (example report) can serve as the basis for a discussion of document analysis and how system requirements can be determined from documents. You or your students should bring sample documents, such as bills and order forms, to class for analysis. Demonstrate how you analyze these documents to discover business rules, as well as content requirements. For example, a shipping form shows whether the firm has ship to, order from, and bill to addresses. A class registration form may indicate the maximum length for student names.

121. Conduct a prototyping session in class, using a 4GL or pidoco (www.pidoco.com) prototyping tool. If such software is available to your students, have them create prototypes based on system requirements found in a business case or in materials you provide. This can include developing an Android or iPhone app with www.appmakr.com, which requires no coding.

122. Conduct a session using Agile usage-centered design methodologies.

123. Take an activity with which students are familiar, such as enrollment in classes. Have your students reengineer this activity. Encourage students to be innovative.

124. Have students identify an organization that would benefit from an Internet-based electronic commerce application. Place your students into groups of three or four individuals.

Then, have students determine the system requirements for the Internet-based electronic commerce application.

Answers to Key Terms Suggested answers are provided below.

125. Business process reengineering (BPR): The search for, and implementation of, radical change in business processes to achieve breakthrough improvements in products and services.

22 Copyright © 2025 Pearson Education, Inc.

126. Closed-ended questions: Questions in interviews that ask those responding to choose from among a set of specified responses.

127. Disruptive technologies: Technologies that enable breaking long-held business rules that inhibit organizations from making radical business changes.

128. Formal system: The official way a system works as described in organizational documentation.

129. Informal system: The way a system actually works.

130. Key business processes: The structured, measured set of activities designed to produce a specific output for a particular customer or market.

131. Nominal group technique (NGT): A facilitated process that supports idea generation by groups. At the beginning of the process, group members work alone to generate ideas. The ideas are then pooled under the guidance of a trained facilitator.

132.

Open-ended questions: Questions in interviews that have no prespecified answers.

133. Prototyping: An iterative process of systems development in which requirements are converted to a working system that is continually revised through close collaboration between an analyst and users.

Answers to Review Questions 1.138.

6.1.

Systems analysis involves determining how the current information system functions and assess what users would like to see in a new system. Analysis has two subphases, requirements determination and requirements structuring.

1.139.

6.2.

Traditional techniques for collecting requirements include interviewing individuals, interviewing groups, observing users, and study of business documents.

1.140.

Interviewing involves speaking with users, individually or as a group, to discover their views about the current and target systems; it also involves carefully preparing an interview outline and guide before conducting the interview. Interviews are best done when only a few people are involved, when you use open-ended questions, or the questions vary from individual to individual, or when a more personal method is needed.

1.141.

Directly observing users involves watching how people work in order to uncover information. Direct observation is best when detailed or complicated procedures must be documented, when you do not want people to know they are giving you information you need, when only a few people are involved, and observational data are representative of all situations.

1.142.

Analyzing procedures and other documents involves identifying and collecting written procedures, forms, reports, and other relevant documents in order to better identify data and processes that would be part of the current and target systems. Analyzing documents is the best technique when documents are complete and unbiased, when other forms of requirements determination are too obtrusive, and when history must be studied, and people do not have firsthand data about history.

1.143.

6.3.

The nominal group technique (NGT) is a facilitated process that supports idea generation by groups. NGT encourages individuals to identify and prioritize problems with an existing system or requirements for a new system.

1.144.

6.4.

During requirements determination, prototyping is used to collect user requirements and present them in the form of a quick working system prototype. Users can look at, play with, and compare the prototype to their system requirements. Analysts can 23 Copyright © 2025 Pearson Education, Inc.

then adjust the prototype to better fit what the users have in mind. Prototyping is better than traditional methods where system requirements are not well understood, where few users that are stakeholders are involved, where designs may be complex, where there have been past communication problems, and where the necessary tools are readily available.

Prototyping may be worse than traditional methods where formal requirements are not documented, where prototypes become idiosyncratic to the initial user, where issues of data sharing and integration with other systems are ignored, and where SDLC checks are bypassed.

24 Copyright © 2025 Pearson Education, Inc.

1.145.

6.5.

As part of the business process reengineering (BPR) effort, key business processes should be identified. Key business processes are the structured, measured set of activities designed to produce a specific output for a particular customer or market. Once these key business processes have been identified, activities that can be radically improved should be identified. Primary candidates include activities that are viewed as important, changeable, or dysfunctional. BPR benefits include radical improvements in speed, quality, and customer satisfaction.

1.146.

6.6.

Disruptive technologies enable the breaking of long-held business rules that inhibit organizations from making radical business changes. Disruptive technologies enable companies to innovatively apply information technology. As a point of discussion, ask students to discuss the concept of a virtual university as compared to a tradition one. Is this an acceptable application of disruptive technology?

1.147.

6.7.

One problem with the traditional waterfall SDLC is that users are involved only at the beginning of the project and then when the project is delivered. The continual involvement of users throughout the development lifecycle allows any changes to business processes to be reflected in the completed system. Also, users are more likely to have a system developed that meets their needs. This approach works best with methodologies that are iterative, such as Agile methodologies. In order for this technique to work, the user who works with the development team must be knowledgeable and able to give up his or her normal business responsibilities in order to become heavily involved in the project.

1.148.

6.8.

Agile usage-centered design is where a group of experts are gathered together and work with a facilitator. What is unique about Agile usage-centered design is the focus, which is on user goals, user roles and the tasks necessary to achieve these goals. The planning game involves two types of players: business, those who know the business processes and represent the group for whom the project is being developed, and development, represented by those who are actually designing and building the system. The game pieces are cards that contain a description of a procedure or feature to be included in the system. There are three phases: exploration, commitment, and steering. During exploration, business writes a story card and development provides an estimate. During commitment, business sorts out stories by necessity, development sorts stories by risk and business chooses the stories for the next release. During steering, business reviews progress and business and development adjust plan. Both Agile usage-centered design and the planning game are similar in that both involve participation of users; both rely upon cards and focus on tasks that the system being designed is supposed to perform.

Answers to Problems and Exercises 1.149.

6.9.

Responses may vary as there are numerous articles available on prototyping. Two examples were reviewed. The first article entitled ―Design Prototypes as Boundary Objects in Innovation Processes‖ by the faculty of Bangkok Chulalongkorn University in Thailand focuses on how design prototypes can foster communications in organizations that deal with the development of innovations. As part of this study, they first focused on the impact of prototypes at the level or organizational design teams that develop ideas and concepts for solutions. The second focus was on the impact of prototypes on the level or organizational teams and developments in the innovation process such as production, financing, and marketing.

25 Copyright © 2025 Pearson Education, Inc.

1.150.

The second article is entitled ―What is Prototyping?‖ by faculty in the IS department of the University of Missouri – St. Louis. This article details the process of building a model of a system that is intuitive and easy to manipulate for end users. This article adheres to the principle that prototyping inherently increases the quality and amount of communications between the developer/analyst and the end user.

1.151.

Some reasons why this type of system would be useful might include reducing development time and cost, increase involvement of the users, instant feedback from user involvement, and higher user satisfaction.

1.152.

6.10.

Using a confederate or a hidden camera, the analyst can conduct observations unobtrusively, so the effect on the users‘ behavior is minimized. The analyst can also brief the users on the observation so that the users will relax and behave naturally. For example, you can make it clear to users that they are not being evaluated and that the observations collected will not be associated with any one individually. In addition, the analysts can perform multiple observations over time. This tends to minimize the effects of aberrant behaviors. Alternatively, the analysts can supplement their requirements determination with additional data collection methods.

1.153.

6.11.

One of the primary problems with analyzing business documents is that these documents do not provide a full picture of how work is done and why. First, business documents are often incomplete, since people have selectively retained documentation.

Second, business documents often describe the formal system as opposed to the informal system, which is more often the way the work is actually completed. Whether the business documents are accurate or not, they provide useful information. If the business documents are accurate, then much of the work of gathering information requirements is nearly finished. If the business documents are inaccurate, then the analyst can use the documents to understand how the work processes ought to be done, or are thought to be done, or, perhaps, should not be done. In any event, analyzing business documents should be done in conjunction with other, supplemental data collection methods. In addition, the analyst should speak to multiple people to gather their perceptions and uses of the documents.

1.154.

6.12.

The meeting‘s objective is to determine courses that are required to develop necessary programmer/analyst skills. The agenda might include introductions, background, discussion of the courses already taken, discussion of course requirements not yet met, discussion of additional courses to take for preparation, plotting course schedules for successive semesters, summary of major points, questions from advisor, and closing. A meeting like this can last anywhere from 30 to 60 minutes, depending on the level of familiarity that the advisor has with the student‘s case.

1.155.

6.13.

Three possible closed-ended questions, each in a different style, are:

1. Which of the following is the best feature about the word processor that you currently use to do your job? (pick only one): a. good help system b. extra tools such as spell check, grammar check, thesaurus, and auto correct c. compatibility with other applications, such as graphics package and spreadsheet 2. Please rank the following three items in terms of their need for improvement in the next version of this word processor. Place a ―1‖ by the item that is most in need of improvement.

26 Copyright © 2025 Pearson Education, Inc.

___ ease of use ___ speed ___ compatibility

1

2

3

4

5

6

7

Strongly

Agree

Agree

Neutral

Disagree

Disagree

Strongly

Agree

Somewhat

Somewhat

Disagree

3. The next version of this word processor should enable you to create and use hypertext markup language documents for use on the World Wide Web. 1.156.

6.14.

Because the group interview might be more difficult to conduct and more timeconsuming, the analyst might add to the interview guide time certain events or timestamped agenda items. For example, if the meeting begins at 8:00 A.M., and the manager of the users will come in to the meeting to give a brief talk, this event might be scheduled for 8:15 A.M. until 8:30 A.M. Other processes in the meeting will be postponed during this event. With time stamping, the analyst writes definitive start times next to each of the agenda items and then uses this to keep the group on track. Alternatively, the analyst might write specific questions that should be asked of particular members of the interview group.

If several analysts are involved in the group interview, the group could be broken into parallel sessions, each with its own agenda. Finally, agenda activities should be allotted for discussion and interchange between the interviewees, so that consensus and synergy can occur.

1.157.

6.15.

Some of the problems include scheduling difficulty, participation of all group members during the meeting, individuals afraid or unwilling to speak in front of other people, conflicts among group members, keeping the group on track, and accurately collecting all the information when multiple people speak at once. Ways to deal with these problems include providing training in team building, group dynamics, and managing conflict; having multiple interviewers work together; and using a technological aid such as Group Support Systems (GSS) or collaborative technologies such as Google Docs.

1.158.

6.16.

The answer to this question is facilitated by revisiting the definitions for corporate strategic planning and information systems planning. Corporate strategic planning is an ongoing process that defines the mission, objectives, and strategies of an organization. Information systems planning is an orderly means of assessing the information needs of an organization and defining the systems, databases, and technologies that will best satisfy those needs. The key to understanding BPR is that it is the search for and implementation of radical change in key business processes. Those organizations involved with BPR are looking for new, innovative ways to perform these processes.

1.159.

6.17.

Student responses will vary. Other Agile methodologies they could write about include: 

Scrum



Extreme Programming



Adaptive Software Development



Feature Driven Development



Dynamic Systems Development Method (DSDM) 27 Copyright © 2025 Pearson Education, Inc.

1.160.

(hyperlinks to each method in Wikipedia are provided and have been deemed active in January 2024)

Guidelines for Using the Field Exercises 1.161.

1.162.

6.18.

This exercise can take an entire class period, but it is very useful. This exercise simulates actual interviewing and gives students much needed interview practice, comparison, and feedback. Allow sufficient time for discussion, or alternatively, have students write a short paper on their observations (as mentioned at the end of the exercise).

6.19.

This is a useful method for learning about the team‘s work processes. Students should identify and apply the comparative advantages and disadvantages of group interviews as discussed in the chapter. Student observations may vary based on group size, group history, and whether the group leader is present. This also can be done in class.

Students can describe systems they use at work or systems they use at school (e.g., registration system or course management system).

1.163.

6.20.

If the chosen teams closely follow the prescribed work method, then the information from the interview should match the information from the written documentation. If, however, some of the chosen teams use a more informal system for completing work, then the information from the interview is not likely to match the information from the written documentation. Ask your students to compare their answers and discuss why, and with what implications, these differences might exist. If done using a class, role-play the documentation from the content management or registration system could also be helpful.

1.164.

6.21.

Students will discover that the organization‘s systems were not merely tweaked; they were significantly modified to the betterment of the organization. If students cannot find a contact person, a visit to the library or to the Web will yield results. Also, you should encourage your students to identify companies that have undergone BPR, such as Ford.

Ask students to identify the tangible and intangible benefits of this process. Students should identify the costs as well.

1.165.

6.22.

For this exercise, you should suggest that your students perform a search on the Internet to find an organization that uses Agile techniques. One good place to start is with the Agile Alliance Web site (www.agilealliance.org), which contains a section on user stories. Also, most Internet businesses such as Microsoft and eBay utilize Agile methods.

Looking at large software companies would be useful.

Chapter 7 Structuring System Process Requirements Chapter Overview Chapter 7 introduces students to several process modeling techniques for representing business processes. After a brief introduction to process modeling, data flow diagramming techniques are introduced in a section called ―Data Flow Diagramming Mechanics.‖ This section demonstrates the basic DFD symbols, definitions, and rules. The Gane and Sarson symbol set is used throughout the book, and these symbols are explained in this section. Hoosier Burger‘s food ordering system is used to illustrate basic data flow diagramming concepts. This section also includes explanations of decomposition and balancing.

28 Copyright © 2025 Pearson Education, Inc.

The chapter introduces four different types of DFDs: current physical, current logical, new logical and new physical. Hoosier Burger‘s inventory control system (which is manual) is used to illustrate the first three types of DFDs. Current practice in using DFDs indicates that very little time should be spent on the current physical DFD. The section ―Using Data Flow Diagramming in the Analysis Process,‖ introduces guidelines for drawing and using DFDs. This is different from the mechanical rules presented earlier. Topics include completeness, consistency, timing, iterative development, primitive DFDs, and analyzing DFDs for system inefficiencies and discrepancies among DFDs that are supposed to be modeling the same system. A Hoosier Burger example helps illustrate these guidelines.

We also introduce students to business process modeling, and the related Business Process Modeling Notation (BPMN). The basic notation is presented, and students will be able develop business process models using the four basic concepts: event, activity, gateway and flow.

In the last section of this chapter, an overview of the process modeling for Internet-based electronic commerce applications is provided. It is explained that process modeling for Internetbased electronic commerce applications does not differ from more traditional applications development projects.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 134.

Show how to logically model processes with data flow diagrams.

135. Teach students data flow diagram symbols and the mechanical rules necessary to create accurate, well-structured process models.

136.

Show students how to decompose data flow diagrams into lower-level diagrams.

137. Illustrate the concept of balanced DFDs. 138. Explain and demonstrate the differences among the four levels of DFDs: current physical, current logical, new physical, and new logical.

139. Illustrate how data flow diagrams are used as tools to support systems analysis.

140. Explain and stress the importance of the DFD guidelines: completeness, consistency, timing considerations, the iterative nature of drawing DFDs, and drawing primitive DFDs. 141. Understand how to use basic Business Process Model Notation.

142. Understand each of the symbols used in BPMN: 1) event, 2) activity, 3) gateway, and 4) flow.

143. Discuss processing modeling for Internet-based electronic commerce applications.

Classroom Ideas 144. Use Figures 7-2 and 7-6 to illustrate the basic DFD symbols and the correct and incorrect ways to draw data flow diagrams. Use Figure 7-3 to demonstrate the problem with trying to include sources/sinks inside the system being modeled.

145. Once you have covered the basics of drawing DFDs, have students complete Problems and Exercises 7.19 and 7.20 as in-class exercises. Once students have completed these problems, review the problems in class, reinforcing the points that you have made.

146. Use Figures 7-4, 7-5, 7-7, 7-8, and 7-9 in class to teach decomposition. Next, ask students 29 Copyright © 2025 Pearson Education, Inc.

to complete Problems and Exercises 7.21 and 7.27; these exercises should be completed in class.

147.

Use Figure 7-10 to illustrate unbalanced DFDs.

148. Supplement the chapter material on DFD mechanics, decomposition, and balancing with your own examples, which you can work with your students in class. Written organizational procedure statements are a good source of such examples. Modified procedure statements also make good homework problems. See Problems and Exercises 7.28 and 7.29 for examples. It is best to devote at least one complete class period to working examples.

Students can prepare these diagrams outside of class or try preparing them for the first time in class. Many issues arise that are best handled with examples. For example, students often encounter difficulties when: 

identifying when to show a direct data flow between processes and when to decouple these with a data store (emphasize that data stores allow different processes to work at different rates and at different times).



deciding what activities to encompass with each process (emphasize the principle of cohesion and the goal of each process being of roughly equal size and complexity).



distinguishing processes from sinks and sources (emphasize factors such as audience and the ability to change or control in making such distinctions).



encountering logical inconsistencies or ambiguities in narrative descriptions (emphasize that this is the power of DFDs, and the typical interaction between requirements structuring and requirements determination necessary to resolve such ambiguities).

149. The Hoosier Burger inventory control system example demonstrates the differences between current physical, current logical, and new logical DFDs. Working through the entire example in class is an effective way to illustrate the differences in these three types of DFDs. Working through another example from your own experience, or having students come up with their own examples, will supplement the Hoosier Burger example.

150. Use a CASE tool in class to demonstrate ways to model processes other than DFDs. Have students compare and contrast these alternative methods with DFDs. 151. Using a CASE tool that supports DFDs, show in class how the tool provides for decomposition and balancing and how DFDs are linked to the CASE repository. Later, when teaching Chapter 8, you can show how the repository links DFDs and entity-relationship diagrams.

152. Use a CASE tool in class to show how the tool checks for completeness, consistency, and other elements of analysis as discussed in the chapter.

153. Use a data diagram tool to answer exercises done in class. There are several possible tools that would be helpful. This includes: a) Microsoft Visio: see https://support.microsoft.com/en-us/office/create-a-data-flowdiagram-in-visio-509a0489-4b63-479c-84ae-4cd5bc7c896d b) Edraw Flowchart: http://www.edrawsoft.com/Data-Flow-Diagrams.php c) Open-source product Graphviz: http://www.graphviz.org/

Answers to Key Terms Suggested answers are provided below.

30 Copyright © 2025 Pearson Education, Inc.

154. Action stubs: The part of a decision table that lists the actions that result for a given set of conditions.

155. Activity: In business process modeling, an action that must take place for a process to be completed.

156. Balancing: The conservation of inputs and outputs to a DFD process when that process is decomposed to a lower level.

157. Condition stubs: The part of a decision table that lists the conditions relevant to the decision.

158. Context diagram: An overview of an organizational system that shows the system boundaries, external entities that interact with the system, and the major information flows between the entities and the system.

159. Data flow diagram (DFD): A picture of the movement of data between external entities and the processes and data stores within a system.

160. Data store: A DFD that is the result of n nested decompositions from a process on a level0 diagram.

161. Decision table: A matrix representation of the logic of a decision; it specifies the possible conditions for the decision and the resulting actions.

162. DFD completeness: The extent to which all necessary components of a DFD have been included and fully described.

163. DFD consistency: The extent to which information contained on one level of a set of nested DFDs is also included on other levels.

164.

Event: In business process modeling, a trigger that initiates the start of a process.

165.

Flow: In business process modeling, it shows the sequence of action in a process.

166. Functional decomposition: An iterative process of breaking the description of a system down into finer and finer detail, which creates a set of charts in which one process on a given chart is explained in greater detail on another chart.

167. Gap analysis: The process of discovering discrepancies between two or more sets of DFDs or discrepancies within a single DFD. 168.

Gateway: In business process modeling, a decision point.

169. Indifferent condition: In a decision table, a condition whose value does not affect which actions are taken for two or more rules.

31 Copyright © 2025 Pearson Education, Inc.

170. Level-0 diagram: A DFD that represents a system‘s major processes, data flows, and data stores at a high level of detail.

171. Level-n diagram: A DFD that is the result of n nested decompositions from a process on a level-0 diagram.

172. Pool: In business process modeling, a way to encapsulate a process that has two or more participants.

173. Primitive DFD: The lowest level of decomposition for a DFD. 174. Process: The work or actions performed on data so that they are transformed, stored, or distributed.

175. Rules: The part of a decision table that specifies which actions are to be followed for a given set of conditions.

176. Source/sink: The origin and/or destination of data; sometimes referred to as external entities.

177.

Swimlane: In business process modeling, a way to visually encapsulate a process.

Answers to Review Questions 1.166.

7.1.

A data flow diagram is a picture of the movement of data between external entities and the processes and data stores within a system. Systems analysts use data flow diagrams to help model the processes internal to an information system and how data from the system‘s environment enter the system, are used by the system, and are returned to the environment. DFDs help analysts understand how the organization handles information and what its information needs are or might be. Analysts also use DFDs to study alternative information handling procedures during the process of designing new information services.

1.167.

7.2.

The rules for DFDs are listed in Table 7-2 and illustrated in Figure 7-6. Table 7-3 lists advanced rules for data flow diagramming. Processes cannot have only outputs, cannot have only inputs, and must have a verb phrase label. Data can only move to a data store from a process, not from another data store or an outside source. Similarly, data can only be moved to an outside sink or to another data store by a process. Data to and from external sources and sinks can only be moved by processes. Data flows move in one direction only. Both branches of a forked or a joined data flow must represent the same data. A data flow cannot return to the process from which it originated.

1.168.

7.3.

Decomposition is the iterative process by which a system description is broken down into finer and finer detail, creating a set of diagrams in which one process on a given diagram is explained in greater detail on a lower-level diagram. Balancing is the conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a lower level. You can determine if a set of DFDs are balanced or not by observing whether a process that appears in a level-n diagram has the same inputs and outputs when decomposed for a lower-level diagram.

1.169.

7.4.

The highest level DFD is a context diagram. It represents the system as a single process, with all the related entities and the data flows in and out of the system. The next level diagram, called a level-0, decomposes the one process from the context diagram into two to seven high-level processes. Each process in a level-0 diagram can be decomposed if necessary. Each resulting diagram is a level-1. Should processes in a level-1 diagram be decomposed, each resulting diagram is a level-2 diagram. Each one of these processes would be decomposed on a level-3 diagram, and so on.

32 Copyright © 2025 Pearson Education, Inc.

1.170.

7.5.

Analysts draw multiple sets of DFDs because each type provides a different perspective on the current or proposed system. Current physical DFDs often show the people and technology used within a system, illustrating who does what and the media on which data are stored. Current logical DFDs attempt to show the essence of the system without regard to the actual physical implementation.

1.171.

7.6.

DFDs can be used as analysis tools to help determine the completeness of a system model and a model‘s internal consistency, to focus on when system events occur through analyzing timeliness, and, through iterative use, to develop and check models.

Analysts can study DFDs to find excessive information handling, thus identifying areas for possible efficiencies.

1.172.

7.7.

You stop decomposing a DFD when the following six conditions are satisfied: (1) each process is a single decision or calculation or a single database operation, such as retrieve, update, create, delete, or read; (2) each data store represents data about a single entity, such as a customer, employee, product, or order; (3) the system user does not care to see any more detail, or when you and other analysts have documented sufficient detail to do subsequent systems development tasks; (4) every data flow does not need to be split further to show that different data are handled in different ways; (5) you believe that you have shown each business form or transaction, computer screen, and report as a single data flow; or (6) you believe there is a separate process for each choice on all lowestlevel menu options for the system.

1.173.

7.8.

Sources and sinks are always outside of the system being considered. They are of interest to the system being considered only because they represent sources of data coming into the system and destinations for data leaving the system. If any data processing occurs inside a source or sink, it should be of no interest to the system being modeled. If the processing is of interest, however, or if the identified source/sink has several inputs and outputs to and from the rest of the system, it may be better considered as an internal process.

1.174.

7.9.

Context diagrams have only one process that represents the entire system being modeled and show only the data flows into and out of the system. The context diagram also includes sources and sinks, which represent the system‘s environmental boundaries.

There are usually no data stores in a context diagram.

7.10. A business process is a standard method for accomplishing a particular task necessary for an organization to function. Business process diagramming is important as it can depict complex processes that is less technical than other methods such as UML. This makes business process diagramming a good tool for communicating effectively between the technical analysts and the system users.

1.175.

1.176.

7.11. Business Process Modeling Notation or BPMN is a standard way to depict business processes. BPMN is overseen by the Object Management Group (OMG), which is the same group that oversees nation for object-orientated modeling.

1.177.

7.12.

There are four main concepts in BPMN. They are as follows:

a) Event: a trigger that indicates the start process b) Activity: an action that must take places for a process to be completed c) Gateway: a decision point d) Flow: shows the sequence of action in a process 1.178.

7.13. A swimlane is a way to encapsulate a process. A pool can encapsulate two or more participants. Swimlanes can be depicted horizontally or vertically to show one 33 Copyright © 2025 Pearson Education, Inc.

process and with one actor. A pool is made up of at least two swimlanes that each focus on a participant (e.g., a person or a department). Pools can also be depicted horizontally or vertically.

1.179.

7.14. There are three different variations of the flow concept in BPMN. The first is sequence, in which the starting event is triggered by an action outside the process itself, either a message or a particular time. A default flow, usually seen after a gateway, shows that flow through a gateway typically follows one path out of those available. The third flow symbol is a little different. The arrow line is dotted, and it begins with a circle. This symbol is used to signify the flow of a message rather than the flow of sequence from one activity to the next.

1.180.

7.15.

The steps to create a decision table are:

1. Name the conditions and the values each condition can assume.

Determine all of the conditions that are relevant to your problem and then determine all of the values each condition can take. For some conditions, the values will be simply ―yes‖ or ―no‖ (called a limited entry). For others the conditions may have more values (called an extended entry).

2. Name all possible actions that can occur.

3. List all possible rules.

When you first create a decision table, you have to create an exhaustive set of rules. Every possible combination of conditions must be represented.

4. Define the actions for each rule.

Now that all possible rules have been identified, provide an action for each rule. If an action doesn‘t make sense, you may want to create an ―impossible‖ row in the action stubs in the table to keep track of impossible actions. If you can‘t tell what the system ought to do in that situation, place question marks in the action stub spaces for that particular rule.

5. Simplify the decision table.

To reduce the size and complexity of a decision table you can remove any rules with impossible actions, consult users on rules where system actions aren‘t clear, and look for patterns in the rules 1.181.

7.16. Limited entry in a decision table means that some conditions will simply have a limited set of possible values, such as ―yes‖ or ―no.‖

1.182.

7.17. Multiply the number of values for each condition by the number of values for every other condition. For example, if we have two conditions with three values each, we would need 2 × 3 or 6 rules. If we add a third condition with three values, we would need 2 × 3 × 3 = 18 rules.

Answers to Problems and Exercises 1.183.

7.18. Students can draw their data flow diagrams in several ways, depending on the level of detail they choose to capture. Students should realize that there is not one ―right‖ data flow diagram for this or most other business processes. Relevant data flows include payment information, receipt, goods sold information, and inventory information. Three data stores are a goods sold file, an inventory file, and daily sales total file. Processes include update goods sold file, update inventory file, update daily sales total file, and 34 Copyright © 2025 Pearson Education, Inc.

produce management reports. Sources/sinks include customer and store manager. A sample context diagram and level-0 data flow diagram are provided below. In the level-0 data flow diagram, Transform Customer Purchase, Update Goods Sold File, Update Inventory File, and Update Sales Total File, were selected as processes rather than as sources/sinks because they were deemed to be central to the point of sale process. Point out why these DFDs are balanced.

35 Copyright © 2025 Pearson Education, Inc.

Retail Store Context Diagram

Retail Store Level-0 Diagram

1.184.

7.19. Sample context and level-0 data flow diagrams are provided below. As with the previous question, students can draw their data flow diagrams in several ways, depending on the level of detail they choose to capture. Students should realize that there is not necessarily one ―right‖ data flow diagram for this or most other business processes. It is important that the diagrams be balanced, have a clear and purposeful boundary, and obey the rules for drawing DFDs.

36 Copyright © 2025 Pearson Education, Inc.

Cap and Gown Context Diagram

Cap and Gown Level-0 Diagram

1.185.

1.186.

7.20. Encourage your students to review the rules presented in Table 7-2, Table 7-3, and Figure 7-6 and check each of their data flow diagrams. Alternatively, if students use a CASE tool to create their data flow diagrams, the CASE tool can automatically check for errors in the diagrams. There are no rule violations in the example DFDs, but problems that are not logical cannot be verified until the diagrams are decomposed to a primitive level. One obvious missing system capability is how to handle invalid orders; typically, processes to handle abnormal conditions, like invalid orders, are shown on primitive or at least low-level diagrams.

7.21. Your students may choose a variety of situations to use for the nth level data flow diagram for this answer. Basically, students should continue the process of decomposition until they have reached the point where no subprocess can logically be broken down further (i.e., each process meets the definition of a primitive process). See the example level-1 data flow diagram from Exercise 7.19, which shows a sample decomposition of the process titled Finalize Order from the level-0 data flow diagram developed for Problem and Exercise 7.19. The (italicized) labels for processes and sources/sinks without borders represent the origin or destination of flows that pass between this subsystem and other system components. Note that the Goods Sold File is a potential black hole, or possibly should 37 Copyright © 2025 Pearson Education, Inc.

be treated as a sink.

Cap and Gown Level-1 Diagram

1.187.

7.22. Some errors and peculiarities in these diagrams include: (1) different names and numbers are used for apparently the same data store on the two diagrams; (2) in the level0 diagram, the data store, Class Roster, does not have the data flow, Scheduled Classes, flowing into it, rather this data flow connects processes 2 and 3, thus these DFDs are not balanced; (3) Process 1 appears to accomplish nothing because its inflow and outflow are identical; such processes are uninteresting and probably unnecessary; it is possible that this process will become interesting when it is decomposed, where validation and error handling processes might appear; (4) Process 2 does not appear to need Course Request as input in order to perform its function, as implied by its name, and (5) some students may also wonder if Process 3 has input sufficient to produce its output. For example, where are prior class registrations kept so that Process 3 can determine when a course is full?

1.188.

7.23. For data flow diagrams to be complete, all the necessary components of a data flow diagram should be included in the diagram and fully described in a project repository. As described in the chapter, the repository entries typically include the following:

1.189.



The data flow should be labeled or named



The data flow should have a short description



All repository objects should be grouped into categories by the type of object



A list of data elements should be included



Supplemental information that go beyond defining the data flow



A listing of locations on which the data flow appears along with the names of sources and destinations 7.24. Three major errors in Figure 7-28 are: (1) Process 1.0 (P2) has only inputs, making it a black hole; (2) data flow DF5 should not move directly from source E1 to data store DS1 without first going through a process; (3) data flow DF1 should not move directly from source E1 to sink E2 without first going through a process. Other peculiarities (such as Process 1.0 has label P2 and the data store has only a label, not a 38 Copyright © 2025 Pearson Education, Inc.

number) are only that, not errors.

39 Copyright © 2025 Pearson Education, Inc.

1.190.

7.25. There is a general formatting issue with these DFDs because there are no numbers on processes and data stores, but students should be able to find logical errors as well. Three particular logical errors in Figure 7-29 are: (1) the data store DS1, not DS2, should be represented on the level-1 diagram; (2) data flow DF3 should be an outflow on the level-1 diagram, and data flow DF6 should not be on the level-1 diagram; (3) process P1.4.2 has no inputs and is thus a miracle process.

1.191.

7.26. The following context and level-0 data flow diagrams represent one way to model the hiring process described in this question. Variations, based on different assumptions, are possible. For example, it is possible to include the processes performed by the Personnel Manager outside the system as a source/sink; in our diagram, we assume the way the Personnel Manager does her work might be studied in more detail, and the way this work is done is subject to change. Also, some students might show Applicant and Hired Employee as separate sources because only Hired Employees provide the information on a nondisclosure agreement.

1.192.

The example assumes that there is always a successful hiring decision (that is, there is no loop between Processes 4 and 3 in the level-0 diagram); also, application and job description data flows are accurate and complete, so there is no reason to explode associated processes to show error handling. Moreover, the assumption is made that all Hiring Decision Letters result in an accepted hiring offer. You may want to give your students the example answer shown and ask them to identify additional assumptions made, which may be different than what they concluded. The simplifications made mean that it is unlikely that the level-0 diagram needs to be decomposed.

1.193.

The example solution also shows split data flows; be sure to emphasize that a split flow means that the same data flow at the same time, but to multiple destinations. In the example given, the Employee data store shows only on the level-0 diagram, not on the context diagram. Technically, you could show it on the context diagram, but it is assumed that this is a detail that is necessary to be known only to those looking at level-0 and lower diagrams. A frequent mistake student‘s make is to forget to include the purge process (on level-1 or lower diagrams) to get rid of year-old applications. Related to this, since applications are retained for a year and the system operates whenever new jobs are posted (this timing cannot be seen on DFDs), there is a need to have an application data store inside the system (that is, on level-1 and lower diagrams); some students will miss this essential element of the logical system description.

1.194.

Students can choose to further decompose the processes; if they do, check that the decompositions are balanced and provide detail needed to show separate processing steps and unique data flows and stores. Some students also make mistakes by trying to use information in the Problem and Exercise that is meaningless for drawing DFDs (for example, there are 500 engineers of different types); this exercise is a good opportunity to emphasize to your students that any given system model, like a DFD, does not model all aspects of an organization, although these facts are relevant (the fact that there are 500 engineers is relevant for physical database design, for example).

40 Copyright © 2025 Pearson Education, Inc.

Hiring System Context Diagram

Hiring System Level-0 Diagram

1.195.

7.27. The following context and level-0 data flow diagrams represent one way to model the help desk process described in this question. This solution includes the processes performed by the consultants and operators as subsystems within the system rather than as sources/sinks; this adds detail, but allows bottlenecks in these processes to be corrected. Note that data store D1 is repeated in the level-0 diagram, to avoid 41 Copyright © 2025 Pearson Education, Inc.

excessive crossing of data flow lines. Several processes can be exploded further, but the student will need to make many assumptions to do so.

1.196.

There are several ways that students can improve this system. For example, with the current system, a customer may have to explain their problem and/or question over and over to multiple people: an operator and possibly several consultants. The customer may begin to believe that they are getting the ―run-around.‖ One way to avoid this potential problem is to let the initial operator have access to the customer problem database so that when the caller is handed off to a consultant the customer‘s already opened problem file will go along with him. In addition, the operator could have sufficient information and the option to direct the call to the proper consultant.

Alternatively, clients could call the assigned consultant directly on follow-up calls to an initial call for help.

1.197.

Ask your students for characteristics of a DFD that imply areas for improvement.

Possible answers are: processes that simply collect and pass on information rather than transforming data, collecting the same information in several processes, placing untransformed data into data stores thus causing unknown delays in processing this data, or cycles or loops that have no apparent termination.

Help Desk Context Diagram

42 Copyright © 2025 Pearson Education, Inc.

Help Desk Level-0 Diagram

1.198.

7.28.

A suggested answer is provided below.

Hospital Pharmacy Context Diagram

43 Copyright © 2025 Pearson Education, Inc.

Hospital Pharmacy Level-0 Diagram

1.199.

7.29.

A suggested answer is provided below.

Contracting System Context Diagram

44 Copyright © 2025 Pearson Education, Inc.

Contracting System Level-0 Diagram

1.200.

7.30.

A suggested answer is provided below.

Training Logistics System Context Diagram

45 Copyright © 2025 Pearson Education, Inc.

Training Logistics System Level-0 Diagram

1.201.

7.31. There are many different varieties of BPMN. The table below indicates six possible variations for each major concept.

Concept Variation Event

Depiction

Concept

Variation

Activity

Abstract

Start Event

Intermediate Event

Service

End Event

Send

46 Copyright © 2025 Pearson Education, Inc.

Depiction

Concept

Interrupting Message

Receive

Noninterrupting Message

User

Interrupting Timer

Manual

Variation

Gateway Exclusive Gateway without Marker

1.202.

7.32.

Depiction

Concept

Variation

Flow Sequence Flow

Exclusive Gateway with Marker

Message Flow

Inclusive Gateway

Association

Parallel Gateway

Data Association

Complex Gateway

Conditional Sequence

Event-Based Gateway

Default Sequence

Answers will vary. One such example could be:

47 Copyright © 2025 Pearson Education, Inc.

Depiction

Event 1: Register for classes Activity 2: Select classes for next semester Gateway 3: Do you have a registration hold Activity 4: Visit advisor to remove hold Activity 5: Register for classes Activity 6: Register for classes Event 7: Registered for the fall term

Event 1: Buy some clothes from a department store online Activity 2: Return three items Gateway 3: Do you return them to the store or ship them back Activity 4: Return at the store Activity 5: Ship back to the store Gateway 6: Returned items received Activity 7: Money returned on credit card Event 8: Return finalized 7.33. The following diagram done in Microsoft Visio represents one possible solution for a BPMN for figure 7-5.

Kitchen

1.203.

Cook Order

Browse Menu

Order Accepted ?

Receive Order

Manager

Customer

No

Yes

Pay for Order

Generate Reports

48 Copyright © 2025 Pearson Education, Inc.

1.204.

7.34. The following diagram done in Microsoft Visio represents one possible solution for a BPMN for figure 7-15.

Look at Inventory Levels Manager NO

Do we need to order?

Yes

Receive Order

Supplier

Receive Inventory

Generate Order

Generate Invoice

1.205.

7.35.

Receive Payment

Send Inventory

Is the account Yes Send Inventory current?

Generate Invoice

Send Payment

NO

The BPMN diagram with two swimlanes follows:

49 Copyright © 2025 Pearson Education, Inc.

Credit Account

1.206.

7.36.

The BPMN diagram with three swimlanes follows:

1.207.

7.37. Most of the processes in the DFDs created in this chapter for Hoosier Burger‘s food ordering system do not lend themselves well to decision table logic; as they simply transform data from one form to another or generate reports. However, process 3.0 and process 4.0 from the inventory management system are good choices to represent the decision logic of one or more of the processes as decision tables.

Decision Table for Process 3.0 Generate Orders Hoosier Burger’s Inventory Control System

Conditions/

Rules

Courses of Action

Inventory level Below Minimum Order Quantity

1

2

N

Y

Place order with Vendor

X

Do NOT place order with Vendor

X

50 Copyright © 2025 Pearson Education, Inc.

Decision Table for Process 4.0 Generate Payments Hoosier Burger’s Inventory Control System

Conditions/Courses of Action

Rules 1

2

3

Due Status

L

D

N

Generate Rush Payment

X

Generate Payment

X

Postpone Payment

X

Due status: L = Late; Date of invoice is more than 30 days before today‘s date.

D = Due; Date of invoice is 30 days before today's date.

N = Not due; Date of invoice is less than 30 days before today‘s date.

1.208.

7.38. Below is a list of some types of questions needed to be asked during requirements determination in order to gather the information needed for logic modeling.

Student examples will vary. 

What decisions are made during each process?



Are there specific rules as to when certain actions take place?



What possible conditions trigger specific actions during a decision process?



Are there specific times or quantities that trigger actions?



Are there levels or types of customers or products that are handled differently?



Are there guidelines that determine which actions are taken under specific conditions?



Are there exceptional situations that require special processes? If so what are the possible exception conditions and the resulting actions?

51 Copyright © 2025 Pearson Education, Inc.

1.209.

7.39.

The Decision Table example below depicts the logic for the scenario.

Decision Table for Purchasing Personal Computers Conditions/

Rules

Courses of Action 1

2

3

4

5

6

7

8

9

Purchase–amount >$15,000.00

N

N

Y

Y

Y

Y

Y

Y

Y

Purchasing–Department APPROVES Purchase

Y

N

-

-

-

-

-

-

-

Purchasing–Department APPROVES RFP

-

-

N

Y

Y

Y

Y

Y

Y

3 Proposals received

-

-

-

Y

Y

Y

N

N

N

Winning–Vendor APPROVED by Purchasing–Department

-

-

-

Y

N

Y

Y

N

Y

No Violations

-

-

-

Y

-

N

Y

-

N

Bid Process

X

X

X

X

X

X

SEND RFP

X

X

X

X

X

X

Rebid process

X

X

X

SEND RFP

X

X

X

X

X

AWARD contract

X

Issue Purchase Order

X

X

X

PURCHASE equipment

X

X

X

PURCHASE Denied 1.210.

1.211.

X

X

X

X

X

(Note in cases where the purchasing department does not approve a purchase or RFP or the vendor is NOT approved or has violations the action PURCHASE Denied was added.

52 Copyright © 2025 Pearson Education, Inc.

Presented below is a simpler sample decision table for some aspects (exclusive of the bidding process).

Decision Table for Purchasing Personal Computers Conditions/Courses of Action

Rules 1

2

3

4

Purchase Amount

G

L

G

L

Vendor Approved

Y

Y

N

N

Award Contract to Winning Vendor

X

Issue Purchase Order

X

X

Purchase Equipment

X

X

Award Contract to Other Approved Vendor

X

Find Another Approved Vendor Purchase Amount:

X

G = greater than $15,000.00 L = less than or equal to $15,000.00

Vendor Approved: Department Department

1.212.

Y = Yes; approved by Purchasing N = No; not approved by Purchasing

7.40. As there are four limited entry conditions, there are 16 rules in one complete decision table. To save space, the three separate, 16-rule condensed tables are combined into one. The first section of rules addresses whether to reduce the purchase amount for large cumulative sales; the second section shows the logic for calculating commission; and the third section indicates when a bonus is due. The table is presented in this way to show students that they can adapt the basic decision table notation in creative ways to depict, in very compact form, some complicated logic. Note that each section covers all 16 rules due to indifferent responses to some conditions; numbers are used in the action portion of each section to show the sequence in which actions should be performed.

53 Copyright © 2025 Pearson Education, Inc.

Decision Table for Electronic Keypad and Switch Sales Process Conditions/ Courses of Action

Rules 2

<1>

<3>

Section 1

2

3

4

5

6

7

Customer–annual–purchases >$100,00

Y

N

-

-

-

-

-

Purchase within rep region

-

-

Y

Y

N

-

-

Shared Sale

-

-

N

Y

-

-

-

Rep–sales => rep–sales–goal

-

-

-

-

-

Y

N

Subtract 10% from purchase–amount

1

Add purchase–amount to customer– annual–purchases

2

2

2

Add purchase–amount to rep–sales

3

3

3

Add 10% of purchase–amount to rep– commission

4

Add 8% of purchase–amount to rep– commission

4

Add 2% of purchase–amount to rep– commission

4

Add 5% of purchase–amount to rep– commission

5

1.213.

7.41. This problem narrative describes a process of handling information rather than a decision process, so logic modeling is not as useful as process modeling. Students will provide different versions, depending on their assumptions about the tenure process.

1.214.

54 Copyright © 2025 Pearson Education, Inc.

For this answer it is assumed that all possible levels participate in the review.

Decision Table for faculty tenure Process Rules

Conditions/ Courses of Action

1

2

3

4

Length of Service

S

N

S

N

Special Permission

Y

Y

N

N

Go up for Tenure

X

X

X

Postpone Tenure Review

Length of Service:

X

S = sufficient; at least six years of service.

N = not sufficient; fewer than six years of service.

Special Permission:

Y = yes; special permission to come up for tenure review.

N = no; no special permission.

7.42. A suggested answer is provided below. Student answers will vary, depending on their assumptions. For example, the rules for additional hardware and software are imprecise in the description.

Decision Table for Microcomputer HW/SW Upgrade Conditions/ Courses of Action

Rules 1

2

3

4

5

6

7

8

User Status L

L

H

M

O

L

H

M

O

Special Approvals

S

S

S

S

U

U

U

U

Standard Complement

X

X

X

Upgrade Complement

X X

55 Copyright © 2025 Pearson Education, Inc.

X

Mobile Complement

X

X

User Status:

L = light; H = heavy; M = moderate; O = mobile

Special Approvals:

S = standard; approval for standard complement U = upgrade; approval for upgrade complement

1.215.

7.43.

Decision table example solutions are provided below for parts a and b.

a.

Decision Table for Courses based on work Hours Conditions/ Courses of Action

Rules 1

2

Hours worked <=10

Y

N

Take 1 Major class plus 1 elective

X

Take 2 Major classes plus 1 elective

X

56 Copyright © 2025 Pearson Education, Inc.

b.

Decision Table for Class Registration Conditions/Courses of Action

Rules 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Able to Register for Physics and Physics Lab

Y

N

Y

N

Y

N

Y

N

Y

N

Y

N

Y

N

Y

N

Able to Register for English Comp

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Able to Register for Java

Y

Y

Y

Y

N

N

N

N

Y

Y

Y

Y

N

N

N

N

Able to Register for Music Appreciation

Y

Y

Y

Y

Y

Y

Y

Y

N

N

N

N

N

N

N

N

Register for P, PL, EC, C & MA

X

Register for P, PL, EC, C & 1 R

X

Register for P, PL, EC, MA, and 1 R

X

Register for P, PL, EC, & 2 R

X

Register for P, PLO, C, MA and 1 R

X

Register for P, PL, C, & 2 R

X

Register for P, PL, MA & 2 R

X

Register for P, PL, and 3 R Register for EC, C, MA & 2R

X X

Register for EC, C, & 3 R

X

Register for EC, MA & 3 R

X

Register for EC & 4 R

X

57 Copyright © 2025 Pearson Education, Inc.

Register for C, MA & 3 R

X

Register for C and 4 R

X

Register for MA and 4 R

X

Register for RR

X

R = Replacement Class (es)

1.216.

7.44. This is a fully reduced decision logic table that would show all the conditions under which an application for graduate school would be made.

Decision Table for Class Registration Conditions/ Courses of Action

Rules

MBA

1

2

3

4

Y

Y

Y

Y

MS MIS Southeast region - location

Y

Y

Top 10 school

5

6

7

8

Y

Y

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Y

Y

At least 1 well-known faculty member

Y

Y

Scholarship awarded

Y

N

Y

N

Y

N

Y

N

Financial Aid awarded

N

Y

N

Y

N

Y

N

Y

Apply to this graduate school

X

X

X

X

X

X

X

X

58 Copyright © 2025 Pearson Education, Inc.

1.217.

7.45.

A decision table representation is provided below.

Decision Table for Loan Approval Conditions/ Courses of Action

Rules

1

2

3

4

5

6

L

S

S

S

S

A A A A A

M

M

M

M

M

M

M

M

Loan type

C

E

E

E

E

E

E

E

E

Employment income verified

Y N Y Y Y

Amount requested < cost of attendance

Y

Y

Y

N

Y

Y

Y

Y

Educational loan amount <$35,000

Y

Y

Y

Y

N

N

N

G

F

P

G

F

P

X

X

X

X

Loan amount

Credit rating

G F

Account at our bank

P

C

8

9

C

C

G

G F

X

X X

10 11 12 13 14 15 16 17 18

C

P

Y N

Loan approved

X X

Loan denied Loan to VP to be reviewed

F

7

X X X

X

X

X

X

Loan amount: >$200,000 = L, <=$2000 = S, >$2000 and <$200,000 = A Loan type Education: = E, Car, Mortgage or other = C Credit rating: Good/Excellent = G, Fair = F, Poor = P

59 Copyright © 2025 Pearson Education, Inc.

X

Guidelines for Using the Field Exercises 1.218.

1.219.

7.46. Because data flow diagrams are a popular tool, students are likely to find analysts who are using them. Students are also likely to find that data flow diagrams for real information systems are much larger and more complex than those discussed in this chapter. This is likely to help students see why data flow diagrams are so useful. Without them, it would be difficult to make sense of large, complex business processes and information systems. Students will also likely discover different notations are in use than depicted in this text. Some systems analysts may prefer object-oriented modeling rather than DFDs or may state that their organization is reducing the use of DFDs in favor of entity-relationship diagrams and other notations. It would also be interesting to discover what type of drawing or CASE tool analysts use for developing and maintaining DFDs. 7.47. Students are likely to have a difficult time constructing data flow diagrams for a real business process and information system. As with previous questions, there are a number of ways that students can draw their data flow diagrams for the system under question. Students should realize that there is not necessarily one ―right‖ data flow diagram for this or most other business processes. Even if students have not had much practice in constructing data flow diagrams, they can still construct diagrams that will be interesting and useful to the people who have developed or who are using and/or maintaining the system under question. Remind students to start with a context diagram and use decomposition to create refined, focused diagrams of different subsystems. It is difficult to draw DFDs because it can be difficult to get an unambiguous explanation from one or several people. Also, it may be hard to determine from business documents how a system works (or is supposed to work). Real business situations are typically messy, and unequivocal descriptions are not easy to obtain. This point is important for your students to learn and reveals the value of reasonably precise notations (models) such as DFDs.

1.220.

7.48. Students are likely to find that various types of software packages have elements in them that can be used to construct data flow diagrams. For example, a drawing package might include data flow diagram symbols. Alternatively, a database management package might include some data dictionary features. However, none of these will be as effective and easy for constructing data flow diagrams as will a repository tool with features for this purpose. If students do not believe this, have them construct a simple data flow diagram using a drawing package, and then have them move sources or processes around on the screen. Chances are that the drawing package does not automatically move all the connected data flows while these objects are moved around the screen. Also, drawing packages do not know DFD rules, so no automatic error checking can be done, and decomposition is not a function of the package. In addition, since a drawing package has no repository, symbols on different diagrams probably cannot be linked (e.g., when details on a higher-level diagram change, these are automatically reflected on nested diagrams).

1.221.

7.49. Students might find that these people draw their business process using either a data flow diagram, a flow chart, a series of input/output models, or some combination of these techniques. People will draw the diagram using the techniques with which they are familiar. If they are not familiar with any techniques for modeling processes, then they will probably draw pictures that represent physical reality (e.g., a piece of paper moving from one person to another person, or a piece of paper moving from one person to a file cabinet). For people who are not familiar with data flow diagrams, students should find that it is relatively easy to show them that data flow diagrams are a better way to model 60 Copyright © 2025 Pearson Education, Inc.

processes. Chances are that this person‘s original picture already has many of the elements of a standard data flow diagram anyway. Research has found that process modeling is a very natural activity for most people, even when they are not formally trained in this technique.

1.222.

7.50. For this exercise, you may need to help your students find a company that uses BPMN. If this is not feasible then you could find one or two professionals to come talk with the class. Be sure students address all the questions asked.

1.223.

7.51. Encourage your students to take the ideas listed or to come up with their own and use BPMN to depict each of the processes involved. Have students share their results with the class.

Chapter 8 Structuring System Data Requirements Chapter Overview Chapter 8 presents a detailed description of the techniques used to structure the data requirements for an information system application. Entity-relationship (E-R) diagramming, the most common notation used by practicing systems and data analysts, is emphasized. E-R diagramming is used, along with process and logic modeling techniques, to develop a thorough, unambiguous description of system requirements. In addition to the standard constructs of the E-R model (entities, attributes, and relationships), data-oriented questions that should be raised during requirements determination are described. This chapter discusses the modeling of business rules for entity integrity, referential integrity, domains, and triggering operations using both E-R diagrams and textual constraint statements and introduces the student to object modeling using class diagrams. The chapter concludes with an example of conceptual modeling for an Internetbased electronic commerce application.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 178. Emphasize the importance of understanding organizational data and convince your students that unless they can represent the data requirements of an application unambiguously in logical terms, they cannot implement a system that will effectively serve the needs of management.

179. Present the E-R model as a conceptual data model that captures the structure and much (although not all) of the semantics of data in several front-end stages of the systems development process.

180. Show students how data, process, and logic models represent data requirements, and that conceptual data models (such as an E-R diagram) provide a more thorough, stable representation of data than do other types of system structures.

181. Show students, via a Hoosier Burger example, how to match data requirements from data, process, and logic system models. This example emphasizes the differences between data stores and data entities yet shows how to reconcile process and data models to ensure each covers all data requirements (while each represents different semantics about data).

61 Copyright © 2025 Pearson Education, Inc.

182.

Discuss data modeling for Internet-based electronic commerce applications.

Classroom Ideas 183. This chapter was to be read following Chapters 6 and 7 on process and logic modeling, respectively. However, many instructors prefer to emphasize data modeling by requiring their students to first study data modeling then study other modeling techniques. If you choose this approach, ask your students to skip the ―Electronic Commerce Application: Conceptual Data Modeling‖ section. This section is tightly linked to the preceding chapters. You can then have students read this section after reading Chapters 6 and 7.

62 Copyright © 2025 Pearson Education, Inc.

184. This chapter covers topics addressed in most database management courses. Depending on your curriculum, this chapter may review previously covered material or may be covered (in more depth) in a subsequent course. Conceptual data modeling is not strictly a database topic and is essential for thorough systems analysis, thus it is an activity that should not be assigned to only specialists (database analysts). Although you are strongly encouraged to cover this chapter in your systems analysis and design course, you should coordinate how you address this topic with those who teach database courses. This chapter is carefully written for the systems analysis and design student. First, data modeling is presented as a step of the larger systems development process. Second, questions to ask users and investigate via other requirements determination techniques are introduced, again placing data modeling within the whole systems development effort. Finally, the wording is less technical, and the breadth and depth of coverage has been reduced to make the material more accessible to those who do not have an extensive database background. This chapter is an excellent refresher for those who have already studied E-R modeling and will provide a solid introduction to E-R modeling for those students who will study this topic later in a database course.

185. This is a very detailed chapter, and there are many concepts as well as notations to cover.

You should devote at least two lecture periods to this chapter, and if possible, schedule a third session that is devoted entirely to working sample exercises with students.

186. It is important to review with students how central a role data modeling and data design play in systems development. You should discuss Figure 8-2 with your students and show examples of the types of data models, designs, and code developed in each phase of the systems development process. Discuss who in the organization is most involved in each of these phases and how end users may best participate in the process.

187. It is important that students learn what questions to ask during requirements determination. Learning what questions to ask comes from the experience of developing structured statements and models, like E-R models, of requirements. Problems and Exercises 8.27 is a good in-class exercise. This exercise emphasizes what information should be collected during requirements determination. Ask your students to work in pairs. One student should play the manager of Pine Valley Furniture‘s order entry department and the other student should play a systems analyst. Give students 10 minutes to prepare for the interview and 15 to 20 minutes to conduct the interview. Each team should develop an E-R diagram based on the interview answers. Ask the teams to present their results and discuss in class why the data models differ among the teams. This exercise emphasizes the importance of careful interviewing and the need to be impertinent by seeking out detailed business rules at every point in the interview.

188. Introduce the notation that is used in the chapter for E-R diagrams (Figure 8-5). Provide an example (and then have students provide examples) for each of the constructs shown in the figure.

189. Contrast the terms ―entity type‖ and ―entity instance.‖ Discuss other examples, such as STUDENT (with each student in the classroom as an instance). Warn students that the term ―entity‖ is often used either way, with the meaning intended to come from the context in which it is used. Have students come up with and discuss other possible examples. These can be from the book or examples found elsewhere.

190. Discuss the representation of multivalued attributes and repeating groups in E-R diagrams and provide several examples. If students are familiar with programming languages that support arrays and other data structures of repeating data, use this understanding to emphasize the need to separate conceptual from physical data modeling.

63 Copyright © 2025 Pearson Education, Inc.

191. Discuss relationships and their different degrees (Figure 8-11). Have your students develop additional examples (students are quite creative with this type of exercise when paired up in class!).

192. Introduce the concept and notation of cardinalities in relationships (Figure 8-14). Start with a basic example in Figure 8-14, and again, have your students develop additional examples.

193. As a general suggestion, you should show (develop step-by-step) many examples of small (two to three entities) and larger (eight to ten entities) E-R diagrams in class. Develop these from your own personal experience. Three approaches work well and mixing these is best. One approach is to give students descriptions of an organization and have them identify entities, attributes, and relationships (with degrees and cardinalities). You can do this as a group exercise, asking for volunteers or calling on students in class. The second approach is to show E-R diagrams and ask factual and interpretive questions about the business depicted in the diagram (such as, how many faculty advisors a student might have, or would all universities have only one department associated with each course and why). Yet a third approach is to pair students and have one student in the pair develop an E-R diagram for an exercise you give them, and then have the other student in the pair read the diagram to see if it agrees with the description. Once each pair of students develops a diagram both are satisfied with, have several teams present their diagrams to the class and discuss differences.

You can also have students bring in copies of computer system forms and reports and develop E-R models for each. Several of the Problems and Exercises can be used for in-class practice problems, especially Problems and Exercises 8.18, 8.22, 8.23, 8.24, 8.25, 8.30, and 8.36. If you have part-time students, or students with prior work experience, several of the Field Exercises also make excellent class discussions.

194. Unary and ternary relationships can be especially difficult for some students. Present several examples of each (for unary, for example, a hierarchical organization structure or the relationships between geographical areas or governmental territories; for ternary, for example, a faculty member advising students about majors, or a customer buying products through different sales channels).

195. If you have the time, an exciting way for students to better appreciate conceptual data modeling is to listen to a guest speaker who has developed an enterprise data model for a local organization. Students are usually amazed by how many entities and relationships exist in any reasonably sized organization (several dozen entities and relationships are common, and models with a hundred entities exist). Such a guest can usually discuss: the difficulties in developing this data model; misunderstandings people had or controversies that existed before the data model was developed; how the data model is being used to guide the development of many new or redesigned systems; and the administrative effort necessary to maintain such a data model (as well as many other topics).

196. Students who study process modeling before data modeling often have difficulties with this chapter. For instance, students may try to include entities for the sources and sinks from the process model. You must emphasize that data entities must be described by attributes, and each instance must have a primary key. Further, there are usually multiple instances. For example, in a data model for a retail store, a student might include the store or the store‘s manager as a data entity. Such concepts do not satisfy the definition of a data entity.

197. Have students identify the entities and relationships associated with an Internet-based electronic commerce application, such as the ordering process for an electronic clothing store.

Next, have your students prepare an E-R diagram for this application.

64 Copyright © 2025 Pearson Education, Inc.

Answers to Key Terms Suggested answers are provided below.

198. Associative entity: An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity Instances; also called a gerund.

199. Attribute: A named property or characteristic of an entity that is of interest to the organization.

200. Binary relationship: A relationship between instances of two entity types. This is the most common type of relationship encountered in data modeling.

201.

Business rules: Specifications that preserve the integrity of the logical data model.

202. Candidate key: An attribute (or combination of attributes) that uniquely identifies each instance of an entity type.

203. Cardinality: The number of instances of entity B that can (or must) be associated with each instance of entity A. 204. Composite attribute: An attribute that has meaningful component parts.

205. Conceptual data model: A detailed model that captures the overall structure of organizational data and is independent of any database management system or other implementation considerations.

206.

Degree: The number of entity types that participate in a relationship.

207. Derived attribute: An attribute whose value can be computed from related attribute values.

208. Disjoint rule: Specifies that if an entity instance of the supertype is a member of one subtype, it cannot simultaneously be a member of any other subtype.

209.

Domain: The set of all data types and values that an attribute can assume.

210. Entity instance: A single occurrence of an entity type. Also known as an instance.

211. Entity-relationship data model (E-R model): A detailed, logical representation of the entities, associations, and data elements for an organization or business area.

212.

Entity-relationship diagram (E-R diagram): A graphical representation of an E-R model.

213.

Entity type: A collection of entities that share common properties or characteristics.

214. Identifier: A candidate key that has been selected as the unique, identifying characteristic for an entity type.

215. Multivalued attribute: An attribute that may take on more than one value for each entity instance.

216.

Optional attribute: An attribute that may not have a value for every entity instance.

217. Overlap rule: Specifies that an entity instance can simultaneously be a member of two (or more) subtypes.

218. Partial specialization rule: Specifies that an entity instance of the supertype does not have to belong to any subtype.

219. Relationship: An association between the instance of one or more entity types that is of interest to the organization.

220.

Repeating group: A set of two or more multivalued attributes that are logically related.

65 Copyright © 2025 Pearson Education, Inc.

221.

Required attribute: An attribute that must have a value for every entity instance.

222. Subtype: A subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings.

223.

Supertype: A generic entity type that has a relationship with one or more subtypes.

224.

Ternary relationship: A simultaneous relationship among instances of three entity types.

225. Total specialization rule: Specifies that each entity instance of the supertype must be a member of some subtype of the relationship.

226. Triggering operation (trigger): An assertion or rule that governs the validity of data manipulation operations such as insert, update, and delete; also called a trigger.

227. Unary relationship: A relationship between instances of one entity type; also called recursive relationship.

Answers to Review Questions 1.224.

8.1.

Some systems developers believe that a data model is one of the most important parts of the statement of information system requirements for four reasons: (1) completely representing data requirements is crucial for the design of databases, programs, computer screens, and printed reports—critical elements of any information system; (2) data, not processes, are the most complex aspects of many modern information systems and requires a central role in structuring system requirements; 3) the characteristics about data are reasonably permanent, so designing information systems based on data yields more stable systems with longer lives (and less maintenance); and (4) structural information about data is essential for automatic program generation.

1.225.

8.2.

Data modeling performed during information systems planning tends to be less detailed than in the phases of the development of a system. Further, a data model prepared during planning covers many systems, but usually shows only entities and relationships, not attributes, and an entity in a planning data model may represent several entities and relationships in other data models. The purpose of data modeling during project initiation and planning is to show the scope of the proposed system in terms of data requirements. Entities, attributes, and relationships represented are only those needed for the application under study. Data modeling during the analysis phase adds details and validates the earlier project data model, since systems analysts have now thoroughly studied specific information requirements. Thus, the resulting data model is usually more extensive, including more entities, attributes, or relationships, than earlier data models.

1.226.

8.3.

Data stores, data flows, and even processes all provide information for data modeling. A data store often represents one or more data entities and their associated attributes. All data in data flows must either be stored in some entity, be computed from data in entities, or in rare circumstances pass through the system. The description of a process sheds light on business rules that must be represented in the data model.

1.227.

8.4.

Although some CASE tools do not support representing ternary relationships but rather force the analysts to represent the ternary relationship as three binary relationships, this enforced representation is not semantically correct. A ternary relationship represents the simultaneous association of three entities (such as a selling relationship links a customer with a product and salesperson), not three binary relationships (between a sale entity/associative entity and customer, sale and product, and sale and salesperson). When representing a ternary relationship as three binary relationships, you make the minimum 66 Copyright © 2025 Pearson Education, Inc.

cardinality 1 for each of the three entities in their relationships with the associative entity (such as, for each sale there is exactly one customer and exactly one salesperson and at least one product), but the maximum cardinality can be 1, many, or a specific value.

1.228.

8.5.

A many-to-many relationship must be modeled as an associative entity when there are attributes associated with the relationship or when the relationship itself has relationships to other entities.

1.229.

8.6.

A triggering operation business rule governs the validity of data for insertion, update, and deletion operations on an entity. A triggering operation controls the integrity of data when data maintenance events occur. The rule states what condition must be true when the data maintenance event occurs, and what action is to be taken under this condition.

1.230.

8.7.

One-to-one and many-to-many relationships (associative entities) may have attributes. For example, a one-to-one unary relationship between employees, married to, may have a Date Married attribute, and a many-to-many binary relationship between students and courses, Takes, may have a Grade attribute.

8.8.

An important linkage is that each describes, in different ways, the data requirements of an information system; these different descriptions must be consistent.

For example, rules in a decision table may correspond to business rules in a data model; attributes in data flows must be stored in or generated from attributes of data entities; different states on a state-transition diagram correspond to different values for an attribute, which may then define a domain business rule for that attribute.

1.231.

1.232.

8.9.

The degree of a relationship indicates the number of entity types participating in a relationship. The three most common relationships are unary, binary, and ternary. An employee working for a department is an example of a binary relationship. A part composed of other parts is an example of a unary (also known as a recursive) relationship. A customer placing an order with a salesperson is an example of a ternary relationship.

1.233.

8.10. An example of a ternary relationship might be that of a car service. A particular driver and car might be assigned to a particular client. Another possible ternary relationship is that of an airline pilot, which is assigned to a particular airplane going to a particular place. A third example might be a baseball manager assigned to a team that is playing games in a season.

8.11. The primary deliverable for the conceptual modeling part of analysis is an E-R diagram, showing the major categories of data and the business relationships between them. A full set of entries about data objects to be stored in the project repository is also produced.

1.234.

1.235.

8.12. Minimum cardinality refers to the minimum number of instances of entity B that must be associated with entity A. If the minimum cardinality of B is one, then entity B is a mandatory participant in the relationship. However, if the minimum cardinality for entity B is zero, then entity B is an optional participant in the relationship.

1.236.

8.13. An identifier that meets the criteria set forth in the chapter is an ideal choice. The criteria include: (1) choosing an attribute that will not change its value over the life of each entity type, (2) choosing an attribute that for each instance of the entity will have valid values and will not be null, (3) avoiding intelligent key usage, and (4) substituting surrogate keys for large composite keys.

1.237.

8.14. Conceptual data modeling is different when you start with a prepackaged software rather than a clean sheet for several reasons. First, prepackaged software has 67 Copyright © 2025 Pearson Education, Inc.

defined business processes that are hard to adjust or change. Second, prepackaged software dictates the capabilities of the data that is captured and stored in a given system.

Taken together, prepackaged software has predefined models that limit the ability of the data model to be expanded.

68 Copyright © 2025 Pearson Education, Inc.

1.238.

8.15. a. Subtype; supertype: A subtype is a subgrouping of the entities in an entity type that is meaningful to the organization and that share common attributes or relationships distinct from other subgroupings. A supertype is a generic entity type that has a relationship with one or more subtypes. b. Total specialization rule; partial specialization rule: The total specialization rule specifies that each entity instance of the supertype must be a member of some subtype in the relationship. In contrast, the partial specialization rule specifies that an entity instance of the supertype is allowed not to belong to any subtype. c. Disjoint rule; overlap rule: The disjoint rule specifies that if an entity instance of the supertype is a member of one subtype, it cannot simultaneously be a member of any other subtype. The overlap rule specifies that an entity instance can simultaneously be a member of two (or more) subtypes. d. Attribute; operation: Attributes refer to an object‘s data, operation refers to a function or a service that is provided by all the instances of a class.

Answers to Problems and Exercises 1.239.

8.16. This is a version of a bill-of-materials structure in which components are different entities from products, but raw materials are considered components. This exercise also indicates a minimum cardinality of 3 for the number of components composing a product, but no such restriction is placed on components as part of other components. Associative entities are used for the many-to-many relationships because quantity attributes are indicated. Unique attribute names are used even though the exercise text involves homonyms. The following E-R diagram depicts this situation.

1.240.

8.17. One interpretation of this exercise is not as complicated as the situation involving products at Pine Valley Furniture. In its simplest terms, there are two prices implied in this exercise: the price at the time of a transaction and the current price. This simply 69 Copyright © 2025 Pearson Education, Inc.

means two different price attributes, one associated with the transaction and one associated with the stock entity. The following E-R diagram depicts this situation (only a few attributes have been added to clarify this example).

1.241.

1.242.

8.18. Many CASE tools have facilities to help people create and edit E-R diagrams.

Users select drawing tools, such as for drawing entity symbols, from a tool palette and draw symbols with a click and drag of the mouse. Some tools also let users link the elements of the E-R diagram directly with elements of a data repository and other parts of the CASE tool. Such a tool might also have a library of ―generic‖ diagrams and relationships for common business processes (e.g., order entry, manufacturing company, and personnel management). Users could then choose the diagrams for a corresponding process and quickly and easily edit them so that they fit the situation. A data modeling CASE tool might translate verbal descriptions of business rules into semantically rich data models. Such a feature allows more direct translation from requirements determination to requirements structuring. Also, an E-R tool should seamlessly integrate with other requirements structuring tools, so that all dimensions (data structure, data movement, processing logic, and timing of events) of the same object are nonredundantly and consistently modeled. Visio has many built in templates that would work.

1.243.

8.19. This exercise defines two entities, Training Program and Training Module, with a one-to-many relationship (Composed of) between them, and a unary optional (because some modules do not have a prerequisite, and some modules are not a prerequisite to other modules) many-to-many relationship (Is Prerequisite for) on the Training Module entity. This is represented in the E-R below:

1.244.

8.20. This exercise defines two entities, ADVISOR and STUDENT, and two relationships, Is Assigned Advisor and Registers, between ADVISOR and STUDENT. An advisor is assigned zero-to-many students, and a student is assigned to exactly one 70 Copyright © 2025 Pearson Education, Inc.

advisor; an advisor registers zero-to-many students, and a student is registered by exactly one advisor. An important rule in this exercise is that the data model cover only ―the current term,‖ so no historical records need to be kept. As an alternative, it is also possible to create a data model with the above two entities and a ROLE associative entity in between, where ROLE has an attribute of ROLE PLAYED (which could take on values of ‗Advises,‘ ‗Advises and Registers,‘ and ‗Registers‘). Then, we would create a relationship between the entities through the associative entity such that an advisor is associated with zero to many students, and a student is associated with one or two advisors. The problem with this alternative is clarifying on only the data model what combination of ROLE PLAYED values are permitted for a given student. This is represented in the E-R below:

1.245.

8.21. As Part_Number and Drawing_Number most likely have unique values for each entity instance, these attributes are candidate keys. Part_Number is a logical choice for the identifier. As a part number is unique, is a single-attribute, and will not be null, these features make it a good candidate.

1.246.

8.22. a.

The identifier is a combination of Employee_ID and Course_ID. b. If an employee is permitted to take the course multiple times, then the identifier is no longer unique. Therefore, another identifier must be specified. The new identifier is a combination of Employee_ID, Course_ID, and Date. Students may also specify other identifiers for this situation.

1.247.

8.23. a.

An employee can work on one-to-many projects.

b. The Includes relationship is a binary relationship. c. No associative entities are directly shown by the associative entity or gerund symbol.

The only many-to-many relationship, Works On, has no attributes, so it does not need to be shown as an associative entity. d. The SKILL attribute can be modeled as an attributive or weak entity. e. It is not possible for the Includes relationship to have attributes because it is a one-tomany relationship. Only one-to-one and many-to-many relationships are allowed to have attributes. f. TASK could be modeled as a gerund since it falls at the intersection of mandatory binary relationships between PROJECT, TOOL, and CITY, depending on the meaning of task. As currently modeled, TASK is something done on a project with a tool at a city, so it is not an independent concept. TASK can be modeled as an entity because it has its own primary key independent of the keys of PROJECT, CITY, and TOOL. Some 71 Copyright © 2025 Pearson Education, Inc.

semantic information would be lost if TASK were modeled as a gerund (e.g., the minimum cardinalities related to task on the Includes, Done at, and Used on relationships). g. HOURLY PAY RATE would be an ideal entity that would be between EMPLOYEE and PROJECT. The relationships between EMPLOYEE to HOURLY PAY RATE is many to one. The relationship between PROJECT to HOURLY PAY RATE is a many to many relationship. The HOURLY PAY RATE would have Employee_ID and Project_ID are the primary key for the attitude.

1.248.

8.24.

Following is one possible set of relationship cardinalities for Figure 8-24.

Places:

A customer places zero to many orders, and an order is for exactly one customer.

Generates:

An order generates zero to one backorder, and a backorder is for exactly one order.

Includes:

An order includes one to many products, and a product is included on zero to many orders.

Comprised of:

A product is comprised of one to many components, and a component goes into making one to many products.

Supplied by:

A component is supplied by zero-to-many vendors (the manufacturer makes some components), and a vendor supplies one to many components.

1.249.

8.25. Each of the four statements yields a new entity and relationship with an existing entity in Figure 8-24.

■

■

■

■

The assignment of customers to sales representatives adds a SALES REP entity and an Assigned to relationship, such that a sales representative is assigned one-to-many customers, and a customer is assigned zero (the statement does not say all customers are assigned a sales representative) or one sales representatives (a sales representative gets a unique set of customers).

The statement in this exercise that causes the most difficulty is the one about customers becoming ―members‖ with unique benefits. The debatable term is ―unique.‖ Unique means that only members, not other customers, receive benefits. Using this assumption, the following representation is reasonable: Create a BENEFIT entity and a many-tomany Receives relationship between BENEFIT and CUSTOMER, such that a customer receives zero (not all customers are members) to many benefits (each benefit is recorded as a separate instance of the BENEFIT entity), and a benefit is received by zero (on a transient basis, nobody may hold a given benefit) to many customers (this also allows different members to receive different benefits). Again, this statement points out how much more precise an E-R model is than a requirements, narrative statement.

The creation of manufacturing teams adds a TEAM entity (the exercise does not say we need to know what employees are on a team) and a Produces relationship such that a team produces one-to-many products, and a product is produced by exactly one team (teams get unique sets of products, and some team has to produce each product).

The assignment of purchasing agents to vendors is analogous to the first situation described, so we create an AGENT entity and a relationship, such that an agent is responsible for one-to-many vendors, and a vendor is under the responsibility of zero or one agent.

72 Copyright © 2025 Pearson Education, Inc.

1.250.

8.26. Student answers will vary depending on the document they find. Generally, each type of document involves three or four entities or gerunds, with a gerund representing the many-to-many relationship between two of the other entities. Also, each document has master entity or header data and detail or line item data. Since normalization is not done until logical data modeling, students may combine some entities.

1.251.

8.27. This is, of course, a very open-ended question. An actual interview dialogue is quite long and varies depending on the particular order entry function. The following is an excerpt from a representative interview script. This excerpt illustrates the types of initial and probing questions that arise as an analyst attempts to understand the data required to support order entry. Bold terms indicate data modeling requirements. Suggest to your students that they create a script that includes questions from all eight of the areas covered in Table 8-1 so that they practice exploring all the dimensions of data modeling.

An example script follows: Question:

What basic operations are performed in order entry?

Answer:

Order entry concerns the creation and maintenance of data about customer orders.

Question:

What do you know about a customer order?

Answer:

We know the order date, order number, customer P.O. number, promised delivery date for the order, customer name, ship-to address, bill-to address, customer number, customer phone number, product number, order quantity, color ordered (if applicable), and item description. (So, there are customer, customer order, product, and order line item entities.)

Question:

Does a customer have the same ship-to and bill-to address for every order she places?

Answer:

No, the ship-to address can vary by order, but the bill-to address is always the same for each of our customers. Some customers have many stores to which we ship furniture. If we have a customer, like Fred‘s Furniture, which has different purchasing offices where invoices are sent for different regions of the country, we consider each office a separate customer for billing purposes. (Thus, ship-to address is a characteristic of the customer order, whereas billto address is a characteristic of the customer.)

Question:

What distinguishes one customer from another customer?

Answer:

We assign each customer a unique customer number.

Question:

Must a customer have a customer number before you start to keep track of them?

Answer:

Yes, but often we do not know some of the other data about a customer, like the bill-to address. (So, nulls are not permitted for customer number, but other customer and order data can be null.)

Question:

What is the format of a customer number?

Answer:

A customer number is six digits long. (This is useful information to clarify what is an attribute. This is also necessary 73 Copyright © 2025 Pearson Education, Inc.

information for later physical file and database design steps.)

Question:

Are there any restrictions on when an order is promised?

Answer:

Yes, the promised delivery date is no sooner than one day after the order date and cannot be more than three months after the order date. (So, there are integrity rules on the promised delivery date.)

Question:

How long do you retain data about customer orders?

Answer:

We retain order data for seven years after the order is paid. (So, it is likely that many customers will have many associated orders.)

Question:

Do you keep information about customers that have never ordered from you or who have not ordered for more than seven years?

Answer:

Yes, we do receive data about prospective customers, and we want to keep track of potential, previous, and current customers. (So, the minimum cardinality is 0.)

Question:

Are customers grouped or categorized in any way?

Answer:

Yes, we group customers by regions of the country or by foreign country (which we consider separate regions), and we have a sales manager responsible for each region.

Question:

Can a sales manager be responsible for more than one region and must a region have only one manager?

Answer:

Yes. (So, there is a one-to-many relationship between sales manager and region, and then a one-to-many relationship from region to customer.)

Question:

Can a sales manager be responsible for a customer order outside her region?

Answer:

Yes, either because she initiates that order or because she changes regions after the order is placed.

Question:

Do you want to keep track of these out-of-region orders for sales managers?

Answer:

Yes, since sales managers are paid partially based upon commissions. We need to distinguish and track both the sales manager of the region in which the customer resides as well as the sales manager who initiated the sale. (So, there need to be relationships from customer order to customer to region to sales manager as well as a relationship directly from customer order to sales manager.)

1.252.

74 Copyright © 2025 Pearson Education, Inc.

8.28.

1.253.

8.29. Three examples of ternary relationships are provided below.

■ television programming: the ternary relationship among a TV show, a date/time slot, and a channel ■

shipping: the ternary relationship among a product, a carrier, and a ship-to location

■

class scheduling at a multi-campus university: the ternary relationship among a course, an instructor, and a campus

1.254.

A difficult issue with a ternary relationship is determining the cardinalities along each edge of the relationship. Be sure students can argue the logic of the cardinalities they choose.

1.255.

8.30. A vessel holds potentially many consignments, and a consignment is on at most one vessel, which probably means that the holds relationship keeps track of the consignments currently held on a vessel (and the vessel, if any, which currently holds a consignment). A vessel goes on potentially many voyages, but a voyage involves only one vessel. The Transports relationship says that a consignment is transported on zero to many voyages (which may involve the same or different vessels), and a voyage transports zero to many consignments. Given that a consignment might be on many voyages, and even though each voyage involves exactly one vessel, it is not known from just Transports and Goes on which vessel a consignment is currently on (there are no attributes from which to infer this). Thus, all three relationships are needed.

75 Copyright © 2025 Pearson Education, Inc.

1.256.

8.31.

A suggested answer is provided below.

CUSTOMER Customer_No Name Street_Address City State Zip

Places

ORDER Order_No Order_Date Promise_Date Includes

PRODUCT Product_No Description Quantity Unit_Price

1.257.

8.32.

1.258.

Suggested answers are provided below. a.

b.

76 Copyright © 2025 Pearson Education, Inc.

c.

d.

77 Copyright © 2025 Pearson Education, Inc.

1.259.

8.33.

Suggested answers are provided below.

a.

b.

c. Yes this is possible; if the relationship married is changed to an associative entity as in the figure below.

1.260.

8.34. A suggested answer is provided below. Ask students if limits should be placed on the range of this attribute. Why or why not? For the triggering operation, an assumption is made that when an account is first opened the initial balance cannot be less than $100.00. a. Domain Definition: Name: Balance Meaning: Balance of the Customer‘s Account Data Type: Numeric Format: 2 Decimal Places Uniqueness: Nonunique Null support: Non-null

b. Triggering Operation: User Rule: Initial ACCOUNT Balance is equal to or greater than $100.00 Event: Insert Entity name: ACCOUNT Condition: Initial Deposit < required starting ACCOUNT Balance Action: Reject the insert transaction 78

Copyright © 2025 Pearson Education, Inc.

1.261.

79 Copyright © 2025 Pearson Education, Inc.

8.35. While the E-R diagrams tell us about the data, relationships among data, and the relevant business rules, decision trees focus on the logic in the models. Obviously, it is necessary to know about the data, the relationships, the business rules, and the business processes in order to develop a good system. Thus, the various modeling techniques are complementary.

If either data or logic modeling techniques (decision trees) are done poorly (or not done at all) the resulting system suffers. For example, if data modeling is left out, the business process is well understood but the implementation of the databases is likely flawed. The system probably provides information to the right person at the right time, but the information will be useless. Conversely, if logic-modeling techniques are done poorly, the databases might be implemented well, but they will not do anyone much good.

1.262.

8.36. This is one of the more complex exercises because there are many entities, relationships, and complicated business rules. It is assumed that a caseworker may not have been assigned a purchase request, and that some vendors, who only bid on the large purchase requests, are not approved to supply commonly purchased products and services. Further, it is assumed that a purchase request is for exactly one product or service, and that a purchase request is tracked before bids start to come in. Finally, it is assumed that to be recognized as a customer, the customer must have submitted at least one purchase request. The E-R diagram can be more explicit (than shown below) if generalization-modeling techniques are used. Without supertype and subtype relationships, a TYPE attribute on the PURCHASE REQUEST entity would have to be used; detailed business rules would have to be written that indicate that large purchase requests require bids, whereas small requests do not. It also appears from the scenario that only small purchase requests are associated with products and services, which necessitate a business rule to elaborate on the E-R diagram. A suggested answer follows.

Guidelines for Using the Field Exercises 1.263.

8.37. Students are likely to come up with several E-R diagrams for a variety of work settings. If they focus their answers on a situation that mirrors the one discussed in the book (e.g., order entry), or if several students focus on the same situation in different organizations, it is useful for them to compare their answers. This comparison highlights 80 Copyright © 2025 Pearson Education, Inc.

the different business rules used across organizations for these same activities and the robustness and applicability of the E-R diagramming technique. Alternatively, your students can build from their own educational experiences and the education examples provided in this chapter and draw an E-R diagram for a situation at their school.

1.264.

8.38. The E-R diagramming technique is robust and applicable across a variety of situations. There should be little or no difference in using the technique for serviceversus product-oriented organizations. Similarly, there should be little or no differences in using the technique for public, private, or governmental organizations. Your students may find that governmental organizations are a bit more rule-bound than nongovernmental organizations, and so there may be more and stricter rules that apply to data. The only other major differences are the various ways that data happen to be stored and used in these organizations. This is not likely based on the ―type‖ of organization, but on the choices made for managing data and business processes. More detailed and dedicated students may find that the E-R model needs more semantic richness or some extended constructs. Business rules provide one useful extension.

1.265.

8.39. Students are likely to discover that conceptual data modeling is handled in a variety of ways. Some larger organizations, with relatively large systems staff, offer formal training in conceptual data modeling, and they use formal conceptual data modeling as a fixed part of the analysis phase. This activity might be performed by systems personnel with the explicit title of ―modeler,‖ ―data modeler or analyst,‖ or ―conceptual data modeler.‖ In other organizations, conceptual data modeling is done less formally, probably by an ―analyst‖ who performs this and many other functions throughout the SDLC. In other organizations, particularly those where the systems are relatively small and simple, there may be no true conceptual data modeling; that is, systems are implemented without a thoughtful design of a conceptual database for the organization.

1.266.

8.40. If students find analysts who have experience with conceptual data modeling, then these analysts will likely provide several examples for all three relationships. The analysts‘ experiences with each type of relationship will vary depending on their amount and level of experience with modeling and the relative complexity of the systems they help to develop and maintain.

1.267.

8.41. Students are likely to find that where E-R diagrams are being used the systems personnel are using CASE tools to create and edit them. Many of these CASE tools have been discussed throughout this book. CASE tools with E-R diagramming features are very effective for the creation and manipulation of good E-R diagrams and the linking of E-R diagram elements to other information within the CASE tool and system. For those people who are drawing E-R diagrams by hand, perhaps they do not know of or have not yet found the proper automated tool. Even with the limitations of CASE tools to draw advanced E-R features (such as ternary relationships), advanced features can be simulated and useful, approximate data models (albeit imprecise for generating code) can be created.

1.268.

8.42. There are several different standards for E-R diagramming. The Peter Chen method uses diamonds for the relationships, whereas the James Martin version uses no symbols for relationships but instead calls for the relationship to be written near each entity box in the relationship. Different ways to represent minimum and maximum cardinality exist. In addition, some CASE tools use their own slightly modified, nonstandard notation. So, whatever the student is able to get from a systems analyst will probably differ from what is in the book, if only slightly. The best way to find and analyze the differences is to do a point-by-point comparison.

81 Copyright © 2025 Pearson Education, Inc.

1.269.

8.43. This question‘s answer is similar to that for Field Exercise 8.42 in that the details of the diagram depend on the E-R diagramming method being used. The bill-of-materials E-R diagram will be more specific as it pertains to a specific assembly or subassembly.

Chapter 9 Designing Databases Chapter Objectives Chapter 9 introduces students to database design, discussing both logical and physical database design. During logical design, logical data models are created for each known user interface, the logical models for each interface are integrated into a consolidated logical database model, the application‘s conceptual E-R data model is translated into normalized data requirements, and the logical database model is then integrated with the translated E-R model. During physical design, decisions about data types, data structures, file organizations, and media are made.

This chapter discusses the relational data model, the most common notation used for representing detailed data requirements necessary for database design. Concepts of the relational data model, normalization principles for creating relational models with desirable properties, a process for combining different relational data models into a consolidated relational data model, and how to translate an entity-relationship data model into a relational data model are presented.

Chapter 9 reviews several choices systems builders have for the design of physical data storage structures. Decisions for which a systems analyst is most likely to have input as opposed to the very technical data structure decisions made by database administrators and analysts are emphasized. You should stress to your students throughout this section that physical design issues are addressed as part of a team of system analysts and technology specialists. Systems analysts bring an in-depth understanding of the application to the table, whereas technology specialists intimately understand the relative efficiency, security, integrity, and reliability of different technologies in different settings. To communicate with these specialists, systems analysts must have a sound knowledge of physical design issues, which is accomplished by studying the chapters in this section. Some students are attracted to the more technical topics (possibly because of prior exposure to computer science topics), and others are interested in the more methodological and managerial issues. Thus, another challenge of teaching Chapter 9 is keeping a balance of business and technical issues so that you hold the attention of all students.

Finally, Chapter 9 provides a transition from typical systems analysis topics to data analysis topics; these topics are often discussed in database management courses. You should coordinate the teaching of this chapter with database management course faculty so that purposeful redundancy occurs and important topics are not missed across the courses in your curriculum.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 228. Show the relationship between systems analysis and design and database design. The philosophy of this textbook is that database design is a topic of joint interest between systems analysts and database specialists. In most cases, considerable interaction between conceptual and logical database design exists, combining the top-down approach of conceptual data modeling with a bottom-up approach using logical data modeling tools. Application area 82 Copyright © 2025 Pearson Education, Inc.

knowledge and enterprise database knowledge (often found in a data administration group) are necessary to converge to a viable logical design for an application‘s database. Remember, an application‘s logical database design does not imply a separate physical database for that application, but rather only a separate view of data, which may be part of a more comprehensive physical database.

229. Show the relationship between logical database design and physical database design. An important point under this objective is that it is the job of the analyst to capture during prior systems development phases, especially analysis and logical design, all of the parameters needed to make physical system design decisions. Although some information is not necessary for the techniques of prior stages, this information (such as field length, data integrity requirements, and an estimated number of entity instances) is essential for physical system design.

230. Present the relational data model as a logical data model that captures the structure of data in a very fundamental, stable form and suggests ways to organize data during physical database design, resulting in desirable data maintenance properties (which avoid certain data anomalies).

231. Show students how a conceptual data model can obscure some details about data requirements that must be better understood in order to perform physical database design.

232. Show students, using an example from Hoosier Burger, how to translate a conceptual data model into a logical data model and how to incorporate the data requirements of specific system outputs into the process of forming a logical data model.

233. Improve the ability of students who will take systems analyst jobs to communicate with technical specialists on systems development teams.

234. Emphasize the distinction between logical and physical system design by coverage of such topics as denormalization; such topics clarify the different objectives of logical and physical design (which is basically semantic richness of describing information requirements versus efficient and secure data processing).

235.

Discuss database design for Internet-based electronic commerce applications.

Classroom Ideas 236. This chapter, like Chapter 8, covers a topic addressed in most database management courses. Depending on your curriculum, this chapter may review previously covered material or introduce material covered (in more depth) in a subsequent course. However, logical database design is not strictly a database topic, but is essential for thorough systems analysis, thus it is an activity that should not be assigned to only specialists (database analysts).

Although you are strongly encouraged to cover this chapter in your systems analysis and design course, you should coordinate how you address this topic with those who teach database courses. Chapter 9 is carefully written for the systems analysis and design student.

This chapter is an excellent refresher for students who have studied the relational data model and normalization and provides a solid introduction to these topics for those students who will address this topic later in a database management course.

237. Emphasize to your students that logical data modeling is still technology independent. A logical data model is not necessarily mapped on a one-to-one basis into a physical database design. The purpose of logical database modeling is to prepare the description of stored data requirements into a format that makes it easier for physical database design decisions to be made. Students may want to go directly from conceptual data modeling to physical database design, so spend some time discussing the purpose of logical database modeling.

83 Copyright © 2025 Pearson Education, Inc.

238. Review the key steps of logical database modeling. It is important that novice data modelers understand that all four steps are necessary to produce a thorough logical data model as input to physical database design.

239. Understanding the relational data model is critical for doing logical database modeling.

The relational model is fairly simple, and because most students have experience with a database management system, this model is intuitive for them. Emphasize the five properties of relations and the concept of anomalies.

240. You can introduce normalization to your students from two perspectives. One approach is to introduce first, second, and third normal forms and teach your students to transform unnormalized data into third normal form by stepping through each normal form in sequence.

Another approach is to emphasize functional dependencies and determinants (see Problems and Exercises 9.20). Use whichever approach is most comfortable for you; this chapter supports either approach.

241. Consider spending a significant portion of your class periods (allocated to Chapter 9) working problems that show how to translate between E-R and relational data models. Table 9-1 is a compact summary of how to map E-R constructs into relational constructs. Your students should become competent with translating in either direction. Problems and Exercises 9.16, 9.17, 9.18, and 9.20 are suitable for in-class exercises, but you should create other examples. Work a few examples for your students, and then have your students work (either individually or in small teams) on several problems in class and then present their answers. Practice is the best teacher of both normalization and translating between relational and E-R models.

242. Emphasize to your students that most E-R models developed during analysis are incomplete because system inputs and outputs are not designed in detail until logical design.

Use this explanation to motivate the need for view integration. Be sure to discuss the potential pitfalls (view integration problems) that make view integration more than a mechanical process. Again, use many examples; Problems and Exercises 9.18 is a fairly simple one that students can work on inside or outside of class. Ask your students why view integration problems arise; for example, sample problems include independent analysts or project teams of different subsystems with slightly different data semantics, the integration of multiple independently-developed applications coming together to create an enterprise data model, and imprecision or lack of naming standards by analysts.

243. You should review in class the Hoosier Burger example found in the ―Logical Database Design for Hoosier Burger‖ section. This example illustrates how to deal with both translating an E-R model into 3NF relations as well as integrating specific system requirements into the data model during logical database design.

244. You should emphasize to your students that physical database design is technology dependent, as well as logical requirements dependent. To make physical data storage decisions, one must know what constraints and opportunities available technologies have.

What file organizations do the available database management systems have? What data types do the operating system and other system software support? What are the physical characteristics of secondary memory devices and what overhead space does data management software require? These are questions that technical specialists can answer; systems analysts with application knowledge, along with technical specialists armed with answers to these questions can together perform physical file and database design.

245. Discuss with your students the role of the CASE repository as a central source of information necessary to make physical design decisions and as a place where these decisions are stored. You can also point out the interactive nature of some logical and physical design 84 Copyright © 2025 Pearson Education, Inc.

issues, such as choosing field data types, and that a CASE repository helps to synchronize logical and physical design activities. For example, when prototyping computer displays or reports with many design tools, analysts may have to select the data type and length of fields before these fields are placed on the prototype. If this display or report generator is a module of the CASE tool, then it draws on the CASE repository for necessary information in building the user interface.

246. Emphasize the important role analysts play in designing data integrity controls. Analysts are essential because designers need an in-depth knowledge of the business area and application to choose default values, picture formats, and range constraints; to determine whether null values should be allowed; and if a null value is present, how to process the data.

247. Review the types of file organizations. Discuss the seven factors that analysts consider when selecting a file organization. Have students evaluate each file organization with respect to each of the seven factors. Finally, review Table 9-3 as a way to summarize the discussion.

248. Often when students prepare system development projects for the systems analysis and design course, they do not include adequate file and database controls into the system. Call your students‘ attention to the section ―Designing Controls for Files‖ and emphasize that controls are essential elements of a system and must be designed into the system, not added as an afterthought.

Answers to Key Terms Suggested answers are provided below.

249. Calculated field: A field that can be derived from other database fields. Also known as a computed field or a derived field.

250. Data type: A coding scheme recognized by system software for representing organizational data.

251. Default value: A value a field will assume unless an explicit value is entered for that field.

252. Denormalization: The process of splitting or combining normalized relations into physical tables based on affinity of use of rows and fields.

253.

Field: The smallest unit of named application data recognized by system software.

254.

File organization: A technique for physically arranging the records of a file.

255. Foreign key: An attribute that appears as a nonprimary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation.

256. Functional dependency: A constraint between two attributes in which the value of one attribute is determined by the value of another attribute.

257. Hashed file organization: A file organization in which the address of each row is determined using an algorithm.

258.

Homonym: A single attribute name that is used for two or more different attributes.

259. Index: A table used to determine the location of rows in a file that satisfy some condition.

260. Indexed file organization: A file organization in which rows are stored either sequentially or nonsequentially, and an index is created that allows software to locate individual rows.

261. Normalization: The process of converting complex data structures into simple, stable data structures.

262.

Null value: A special field value, distinct from zero, blank, or any other value, that 85 Copyright © 2025 Pearson Education, Inc.

indicates that the value for the field is missing or otherwise unknown.

263. Physical file: A named set of table rows stored in a contiguous section of secondary memory.

264. Physical table: A named set of rows and columns that specifies the fields in each row of the table.

265.

Pointer: A field of data that can be used to locate a related field or row of data.

266. Primary key: An attribute (or combination of attributes) whose value is unique across all occurrences of a relation.

267. Recursive foreign key: A foreign key in a relation that references the primary key values of that same relation.

268. Referential integrity: A rule that states that either each foreign key value must match a primary key value in another relation or the foreign key value must be null (i.e., have no value).

269. Relation: A named, two-dimensional table of data. Each relation consists of a set of named columns and an arbitrary number of unnamed rows.

270.

Relational database model: Data represented as a set of related tables or relations.

271. Second normal form (2NF): A relation is in second normal form if every nonprimary key attribute is functionally dependent on the whole primary key.

272. Secondary key: One or a combination of fields for which more than one row may have the same combination of values.

273. Sequential file organization: A file organization in which rows in a file are stored in sequence according to a primary key value.

274.

Synonym: Two different names that are used for the same attribute.

275. Third normal form (3NF): A relation is in second normal form and has no functional (transitive) dependencies between two (or more) nonprimary key attributes.

276. Well-structured relation: A relation that contains a minimum amount of redundancy and that allows users to insert, modify, and delete the rows without error or inconsistencies; also known as a table.

Answers to Review Questions 1.270.

1.271.

1.272.

9.1.

The purpose of normalization is to rid relations of anomalies. The goal is to form well-structured relations that are simple and stable when data values change, or data are added or deleted.

9.2.

The five properties of relations are: 1) entries in columns are simple, 2) entries in columns are from the same set of values, 3) each row is unique, 4) the sequence of columns is insignificant, and 5) the sequence of rows is insignificant.

9.3.

There are several problems that can arise from merging relationships. This includes: 1) synonyms, 2) homonyms, 3) transitive dependencies, and 4) class/subclass relationships can arise during view integration. Synonyms occur when two or more different names are used for the same attribute from different user views. Homonyms occur when two or more attributes from different user views have the same name.

Transitive dependencies are functional dependencies between non-key attributes that arise when functionally dependent non-keys come from different user views.

Class/subclass relationships refer to relations representing the same entity from different 86 Copyright © 2025 Pearson Education, Inc.

user views that actually represent different subsets of the same entity type.

1.273.

9.4.

Relationships between entities are represented in several ways in the relational data model. A binary 1:M relationship is represented by placing a foreign key (the primary key of the entity on the one side of the relationship) in the relation for the entity on the many side of the relationship. In a binary 1:1 relationship, a foreign key is placed in the relation on either side of the relationship or on both sides. For a binary and higher degree M:N relationship, a relation is created with a primary key, which is the concatenation of the primary keys from the related entities. In a unary relationship, a recursive foreign key is added to the relation.

1.274.

9.5.

The fundamental rule of normalization is that each non-key attribute must be fully functionally dependent on the whole primary key attribute (a non-key is dependent on the whole key and nothing but the key). Thus, there can be no functional dependencies between non-keys.

1.275.

9.6.

1.276.

9.7.

Instances in a relation cannot prove that a functional dependency exists; however, you can use sample data to demonstrate that a functional dependency does not exist. The sample data does not show every possible instance, only a sampling. Knowledge of the problem domain is a reliable method for identifying functional dependencies.

1.277.

9.8.

The choice of data type often limits the possible values that may be stored for a field. For example, a numeric data type forbids alphabetic characters. Some data types have an assumed length (e.g., SMALLINT) that places an implicit range control on values. Data type may also limit the kinds of data manipulations possible, thus further controlling the integrity of the data or results from manipulating the data. For example, a DATE data type causes addition and subtraction to be limited by rules about dates.

1.278.

9.9.

A referential integrity control requires the data management software to access other data records to determine if the value is permitted, whereas a range control is checked by looking up values outside the files and database, in a repository or other source of metadata.

1.279.

9.10. The purpose of denormalization is to physically locate data close to one another if they are often needed together for processing, thus minimizing secondary memory I/O operations. Because normalization forces all attributes dependent on the same primary key to be logically placed in one relation, a relation can become quite diverse with many attributes. For example, a PART relation might have attributes related to engineering, production, accounting, and marketing. It is likely that in only rare instances attributes from two or more of these areas are needed in the same data processing steps. If the attributes were stored in the same physical record, the record would be long and it would take more time to access this file than if the file were divided into segments and each segment had the same primary key and only fields for those attributes used together.

1.280.

9.11. The factors that influence the decision to create an index are the data retrieval, insertion, deletion, and updating costs with and without the index. Indexes allow for rapid random retrieval and sorting of data, but indexes create additional storage and maintenance costs.

1.281.

9.12. Data compression techniques are pattern matching and other methods that replace repeating strings of characters with codes of shorter lengths, thus reducing data storage requirements.

1.282.

9.13. The two goals of designing physical tables are: 1) the efficient use of secondary storage and 2) data processing speed.

A foreign key is identified by using a dashed underline.

87 Copyright © 2025 Pearson Education, Inc.

1.283.

9.14. The seven factors to consider when selecting a file organization are: 1) fast data retrieval, 2) high throughput for processing transactions, 3) efficient use of storage space, 4) protection from failures or data loss, 5) minimizing need for reorganization, 6) accommodating growth, and 7) security from unauthorized use.

Answers to Problems and Exercises 1.284.

9.15. The wording in the problem clarifies some of the relationships and associated cardinalities. As VENDOR is functionally dependent on COMPNAME, there can be at most one vendor for each component (and it is assumed that there may be no vendor for a given component). Also, since COMPNAME is functionally dependent on PRODNAME, there can be at most one component per product (a rather odd situation, but that is what the wording says; it is assumed that some products have no components). Although not clarified in the problem, it is assumed that a product is assigned to exactly one salesperson, while a salesperson can be assigned one-to-many products. Given these clarifications, the 3NF relations are (foreign keys have dashed underlines): PRODUCT (PRODNAME, SALESPERSON, COMPNAME) SALESPERSON (SALESPERSON) COMPONENT (COMPNAME, VENDOR) VENDOR (VENDOR)

1.285.

9.16. Listed below are sample 3NF relations for the conceptual data model diagram in Figure 8-23. Given below are a few, representative attributes to make this normalization meaningful (foreign keys have dashed underlines). The CITY and TOOL_ID relations contain nonkey attributes, whereas the PRODITEM and SUPPITEM relations, the result of the many-to-many relationships, have no nonkey attributes, since these are not shown as associative entities in Figure 8-23. At this point, proper primary keys have not been created.

TASK (TASK_ID, TIME, SKILL, TOOL_ID, CITY_ID) PROJECT (PRODUCT_ID, TASK_ID, EMPLOYEE_ID) EMPLOYEE (EMPLOYEE_ID, PROJECT_ID) CITY (CITY_ID) TOOL (TOOL_ID) 9.17. Listed below are 3NF relations for the E-R diagram on Figure 9-21. (Foreign keys have dashed underlines.) QUOTE QUANTITY is not sufficient as the primary key of the PRICEQUOTE relation, but this attribute along with the primary keys of the two associated entities is a sufficient concatenated (or composite) primary key for this associative entity. The PART RECEIPT entity is called a weak or attributive entity, since its existence depends on a PRICE QUOTE entity instance. In this case, however, the PART RECEIPT entity has its own primary key, ORDER NO. The 3NF relations are:

1.286.

VENDOR (VENDOR NO, ADDRESS) PRICEQUOTE (VENDOR NO, ITEM NO, QUOTE QUANTITY, PRICE) PART (ITEM NO, DESC) PART RECEIPT (ORDER NO, VENDOR NO, ITEM NO, QUOTE QUANTITY, DATE, ORDER QUANTITY) 1.287.

9.18.

88 Copyright © 2025 Pearson Education, Inc.

a. Listed below are merged 3NF relations for this hospital example. This is an interesting exercise because it points out how semantically lacking the relational data model is, since questions arise about functional dependencies across separately developed relations. One observation is clear: The second 3NF PATIENT relation in this exercise has only one value of TREATMENT DESCRIPTION, so each patient must be associated with only one treatment, otherwise this relation would not be in 3NF. But, it must also be assumed that each department has only one supervisor and each supervisor can supervise only one department. This last assumption means that only a supervisor or a department relation can be created, but not both. This is sufficient because, if the original set of six 3NF relations is comprehensive, there are no nonkey attributes dependent on either DEPARTMENT or SUPERVISOR ID. We, however, create both supervisor and department relations, with a one-to-one relationship between them, to allow for some evolution of the data model. One additional assumption about supervisors: SUPERVISOR is a separate entity from PHYSICIAN. It is also assumed that the attribute ADDRESS means the same address in both PATIENT relations, and further there are no other synonyms or homonyms across the relations. Interestingly, there is no relationship between patient and physician implied in the original 3NF relations, and it is assumed none exists.

With these assumptions, the merged relations are (foreign keys have dashed underlines): PATIENT (PATIENT NO, ADDRESS, ROOM NO, ADMIT DATE, TREATMENT ID) ROOM (ROOM NO, PHONE, DAILY RATE) PHYSICIAN (PHYSICIAN ID, NAME, DEPARTMENT ID) TREATMENT (TREATMENT ID, DESCRIPTION, COST) SUPERVISOR (SUPERVISOR ID, DEPARTMENT ID) DEPARTMENT (DEPARTMENT ID, SUPERVISOR ID) b. To create the E-R diagram from these 3NF relations, additional assumptions about minimum cardinalities must be made. It must be assumed that every patient is assigned a room, but a room may be empty; not all treatments have to be associated with a patient, but a patient has to have a treatment; and that each department has one supervisor and each supervisor has one department. Relationships are shown from both a department and a supervisor to a physician, but only one is necessary; it is also assumed that a physician must be associated with both a department and a supervisor.

This is an interesting E-R diagram because it contains two, disconnected parts. This is possible, although rare in actual organizations. A suggested E-R diagram, including attributes, for this situation is presented below.

Application E-R Diagram

89 Copyright © 2025 Pearson Education, Inc.

TREATMENT SUPERVISOR DEPARTMENT

Supervises

Treatment_ID Description Cost

Given

Supervisor_ID

Department_ID

Works_in PATIENT Patient_NO Address Admit_Date

PHYSICIAN Physician_ID name

Works_for

ROOM

Located_in

1.288.

Room_NO Phone Daily_Rate

9.19. a. There are several foreign keys in these relations. OFFICER ID is a foreign key in OFFICE referencing MEMBER ID from the MEMBER relation. OFFICE NAME is a foreign key in EXPENSE referencing OFFICE NAME in the OFFICE relation.

OFFICER IN CHARGE is a foreign key in COMMITTEE referring to OFFICER ID or OFFICE NAME (which is not clear from simply the relations) in the OFFICE relation. EXPENSE LEDGER NUMBER is a foreign key in PAYMENT referencing LEDGER NUMBER in the EXPENSE relation. MEMBER ID in both RECEIPT and WORKERS cross-references MEMBER ID in the MEMBER relation.

COMMITTEE ID in WORKERS cross-references COMMITTEE ID in COMMITTEE. b. See the accompanying E-R diagram. For simplicity, attributes are not shown on this E-R diagram. The WORKERS relation exists because of a many-to-many relationship, Works On, between MEMBER and COMMITTEE. Fraternity E-R Diagram

MEMBER

Submits

RECEIPT

Incurs

EXPENSE

Holds

Works on

OFFICE

In Charge of

Reimburse

COMMITTEE

PAYMENT 90

Copyright © 2025 Pearson Education, Inc.

1.289.

c. It is inferred that a member sometimes has many receipts, but a receipt must have a member. An expense sometimes has multiple payments, but each payment must have an expense. Each office sometimes has multiple expenses, but each expense must have an office. Each office may have a member as an officer-in-charge, and each member sometimes holds many offices. An office sometimes is responsible for many committees, and each committee must have an office in charge (although it is possible that office may not have a member assigned as officer). Committees sometimes have many workers, and each worker sometimes works on many committees. The E-R diagram is more expressive in that it displays explicitly the minimum cardinalities of relationships and shows exactly which entities are related.

9.20. a. As there are four determinants among the functional dependencies, there will be four relations. The last functional dependency, the one with only a three-key composite determinant, signifies all the dates on which a particular applicant interviewed for a particular position. This functional dependency does not signify a many-to-many relationship, like many composite keys do, since date interviewed is itself not a determinant. It signifies an entity with a three-component composite key. The four 3NF relations are: APPLICANT (APPLICANT ID, APPLICANT NAME, APPLICANT ADDRESS) POSITION (POSITION ID, POSITION TITLE, DATE POSITION OPENS, DEPARTMENT) APPLICATION (APPLICANT ID, POSITION ID, DATE APPLIED) INTERVIEW (APPLICANT ID, POSITION ID, DATE INTERVIEWED) b. A suggested E-R diagram is provided below. For clarity, composite keys are shown as a single composite attribute.

APPLICANT

Applies Applicant_ID Applicant_Name Applicant_Address

APPLICATION Application_ID Applicant_ID Position_ID Date_Applied

POSITION

Responds to Position_ID Position_Title Department Date_Position_Opens

Interviews for

INTERVIEW Interview_ID Position_ID Date_Interviewed

1.290.

9.21. The objectives of a good coding scheme are to minimize storage space and to increase data integrity. Student major is a classic example of a sparse field that can benefit from being codified for storage and data entry. For online data entry, a list of possible majors could be provided from which the data entry person must choose; this legal list of codes will need to be updated, but this can probably be done separately from data entry of student data. A fundamental coding choice is whether to use codes that are as dense as possible or to try to use reasonably dense codes that have some meaning to most users (e.g., MIS versus 31 for a Management Information Systems major). Short character string codes (e.g., three alphabetic characters) may take as little storage as a two-digit numeric code, so a short character string may achieve both objectives. An 91 Copyright © 2025 Pearson Education, Inc.

interesting way to approach this question is to have your students identify how their university and at least two other universities represent a student‘s major. Have your students compare and contrast these coding schemes. It is likely that they will locate universities where the code is numeric, alphabetic, or alphanumeric.

1.291.

9.22. Suggestions for the primary keys are underlined in the following relations.

(Foreign keys have dashed underlines).

VENDOR (VENDOR NO, ADDRESS) PRICEQUOTE (VENDOR NO, ITEM NO, QUOTE QUANTITY, PRICE) PART (ITEM NO, DESC) PART RECEIPT (ORDER NO, VENDOR NO, ITEM NO, QUOTE QUANTITY, DATE, ORDER QUANTITY) If VENDOR NO, ITEM NO, and ORDER NO are numeric values assigned without any relationship to the associated entities, then these numbers would not change as the realworld changes, and they would be acceptable as primary keys or components of composite primary keys. QUOTE QUANTITY, on the other hand, is likely volatile, and is not suitable as part of the primary key for the PRICEQUOTE table. A non-intelligent primary key for the PRICEQUOTE table must be created. Also, individual secondary index keys on VENDOR NO and ITEM NO attributes from this relation may be needed to facilitate joining the PRICEQUOTE table with the VENDOR and PART tables, respectively.

92 Copyright © 2025 Pearson Education, Inc.

1.292.

9.23. a. The guidelines for identifying keys for indexing suggest that attributes used for selection, sorting, grouping, and joining are potential candidates. The three queries are to be considered as the only accesses to the database, so primary key indices are not implicitly needed. The frequency of the three queries compared to update operations is not known, so it is impossible to make precise, optimal decisions on the most economical indices. Space does not seem to be an issue since none of the qualifying fields are very long. So, all possible indices that might speed query processing are indicated. The first query, Query A, appears to access the PART and PRICEQUOTE tables, but actually the PRICEQUOTE table is sufficient. The E-R diagram indicates that every part has at least one vendor, so every part has at least one price quote. Thus, all parts appear at least once in the PRICEQUOTE table. The data reported in Query A (ITEM NO, VENDOR NO, QUOTE QUANTITY, and QUOTE PRICE) are found in the PRICEQUOTE table. The query asks for the results to be sorted by ITEM NO and by VENDOR NO (but not by quote quantity).

A composite index on these two attributes is the most efficient way to directly produce this sorted output, thus avoiding the need to do a sort of the data once it is retrieved. This assumes that the DBMS or file system utilizes a composite index when it sees the compound sorting condition. Thus, for Query A, a secondary composite index on first ITEM NO and then VENDOR NO is ideal. b. The second query, Query B, asks to display all the attributes from the PART RECEIPT and PART tables; since ITEM NO is an attribute in the PART RECEIPT relation, there is no need for the PRICEQUOTE relation to link the PART RECEIPT and PART tables. No sorting is done, but the query wants data for only a specified part receipt date. Assuming that many days of part receipt data are kept, then it may be desirable to create a secondary key index on DATE and a secondary key index on ITEM NO in the PART RECEIPT table and a primary key index on ITEM NO in the PART table to efficiently support the selection and joining needed for Query B. c. The third query, Query C, involves selection of a particular vendor and display of attributes from all associated PRICEQUOTE rows for that vendor; thus, all the data needed for this query can be found in the PRICEQUOTE table. No sorting is mentioned. Thus, for Query C, only a secondary key index on VENDOR NO in the PRICEQUOTE table would support efficient processing.

1.293.

9.24. This question highlights the difficulty of setting useful default values. Our analysis also suggests the potential difficulty of choosing a marital status field attribute. If it were possible to have only one default value, several years of student data could be studies prior to picking the modal marriage value. If default values were conditional on student type (e.g., undergraduate, graduate, professional), then the model values could be used for each student type. Thus, it would be desirable to have values for student type to be entered before the marital status. Alternatively, an impertinent student might respond to this question by saying why even store marital status.

1.294.

9.25. One suggested answer is a situation where an employee needs to know a contact name for a vendor, a quoted price for a particular item, and a description for the item. If the tables are denormalized, this query requires the joining of only two tables; however, if we are using normalized relations, this query requires the joining of all three relations.

93 Copyright © 2025 Pearson Education, Inc.

1.295.

9.26. In this example a family relationship is modeled. Assuming we want to track the type of relationship we would need 3 tables one for the employee, one for the relationship, and one for the associative table. In the PERSON_RELATIONSHIP table the primary key would consist of three attributes. Both the Person_ID‘s in the PERSON_RELATIONSHIP table would also be foreign keys.

PERSON (Person_ID, Person_Name, Person_DOB) RELATIONSHIP (Relationship_Type, Relationship_Name) PERSON_RELATIONSHIP (Person_ID, Person_ID, Relationship_Type, Comments)

Guidelines for Using the Field Exercises 1.296.

9.27. Students can search through academic journals, textbooks, or the Web. They are likely to find information about other normal forms such as Boyce-Codd normal form (remove remaining anomalies resulting from functional dependencies), fourth normal form (removing multivalued dependencies), and fifth normal form (removing remaining anomalies). Students are likely to encounter these other normal forms in a database class (often from a Computer Science department) or on the job, particularly in a job where they are developing a relatively large, complex database. As with all normal forms, each rids the data model of potential redundancies and inconsistencies.

1.297.

9.28. For this exercise, it would be helpful for the individual to bring in some real examples. Also, regarding third normal form, ask the individual why they do or do not normalize all tables to 3NF. 9.29. The individual should identify several types of information that are most useful for file and database design. Information as it relates to primary keys, secondary keys, data types, business rules, relationships, data integrity control methods, volume, present and future required data storage space, and file organization should be collected.

1.298.

1.299.

9.30. There are probably a number of DBMSs available at the student‘s university. For example, the student‘s computer laboratory is likely to have at least one DBMS available; perhaps Microsoft Access for Windows is available. A client-server or object-oriented DBMS might be available as well. In addition, the university‘s administrative database applications are probably run on a mainframe or minicomputer. A DBMS such as IBM‘s DB2 or the Oracle DBMS are probably being used. The data types supported by these DBMSs provide important criteria for determining for which types of applications each of these DBMSs are best suited. DBMSs tend to have fewer physical file and database design options than do mini- or mainframe computer-based DBMSs. In addition, students should consider the number of records and physical file organizations that the DBMS allows, the available storage space on physical storage mediums, the record locking and other security features that the DBMS provides, the availability of a CASE tool, and other factors.

1.300.

9.31. Your students should find that many of the physical file and database design issues presented in the chapter are dealt with at their university. For instance, storage space, file organizations, and data types are issues that must be addressed.

Chapter 10 Designing Forms and Reports Chapter Overview 94 Copyright © 2025 Pearson Education, Inc.

Chapter 10 introduces students to the process of designing forms and reports. Form and report design is a key ingredient for successful systems because users often equate the quality of a system to the quality of its input and output methods. This is especially true for Internet-based electronic commerce systems. Because of this, students need to understand the role of active user involvement in the form and report design process. A key to designing usable forms and reports is consistency. Students can gain the skills needed to design consistent, usable forms and reports by learning the guidelines of formatting information, using color, highlighting, and avoiding the biasing of information. The deliverable from this design process is a specification that has three sections: a narrative overview explaining the need for and use of the form or report, a sample design, and all testing and usability assessment information. Understanding that individuals who design a form or report may not be the individuals responsible for implementing it underscores the need for complete design specifications.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 277. Illustrate the process of designing forms and reports and the deliverables for their creation.

278.

Describe how to apply the general guidelines for formatting forms and reports.

279.

Illustrate how color is used to improve the usability of information.

280.

Illustrate how to format text, tables, and lists effectively.

281. Explain how the formatting of information can bias users‘ understanding.

282. Describe how to assess usability and illustrate how variations in users, tasks, technology, and environmental characteristics influence the usability of forms and reports.

283. Discuss the importance of form and report design for Internet-based electronic commerce applications.

284.

Discuss common errors that occur when designing Web page layouts.

285.

Discuss the importance of lightweight graphics and template-based HTML.

Classroom Ideas 286. This chapter introduces concepts and terms that are central to understanding the form and report design process. Use Review Questions 10.1 and 10.2 as a starting point for class discussion.

287. During a lecture, an effective way to teach the various information formatting concepts is to use the tables and figures in the chapter to contrast proper and improper designs.

288. An alternative to lecturing on the chapter contents is to lecture from the Review Questions, Problems and Exercises, and Field Exercises. Pose selected questions to your students; this helps focus a discussion on specific concepts.

289. Another effective in-class exercise is to ask students who have been on systems development teams to compare their experiences to the concepts presented in Chapter 10.

This discussion is a good way to elaborate on alternative ways for designing forms and reports. As some organizations have standards for form and report design, ask students to bring these standards to class and bring example forms or reports showing how these standards are followed. If standards do not exist, have students bring examples of forms and reports from the same or different systems, showing inconsistencies that can result from not 95 Copyright © 2025 Pearson Education, Inc.

having standards.

290. If you have access to practicing systems analysts, an insightful activity is to invite the analysts into your class to discuss how they design forms and reports in their organization (processes, types of development and prototyping tools, etc.). As with the previous classroom idea, have your guests discuss any standards their organization has for form and report design. Also, ask your guests to discuss how form and report designs are reviewed or approved, especially if a human factors review is involved.

291. If you have access to a CASE tool or a visual development tool (e.g., Microsoft Expressions), it is often fun and informative for you to rapidly construct several forms or reports interactively with the class. Alternatively, if you can hold your class in a computer classroom where each student has access to a PC and development software, you can have students create designs for some fictitious system. Even though you provide students with the same specifications, it is an interesting exercise to have your students share their designs with other class members. After doing this, discuss why some of the designs are different, but still conform to the design guidelines from the chapter and the specifications that you gave them.

Now, discuss how this all relates to usability, consistency in design, and so on.

292. Ask students to bring to class (better yet, give a copy to you in advance so you can make transparencies from them) example forms and reports that they receive. Students receive and use invoices, order forms, class registration documents, ride share cards, airline tickets, and a host of other computer input and output. Using the guidelines from the chapter, critique these forms and reports and ask students to redesign these documents to better satisfy the guidelines.

293. Given your teaching objectives and experience, you may want to consider integrating the teaching of Chapters 10 and 11. Although the authors organized the material in these two chapters in a logical sequence, reviewers have indicated that it is possible to rearrange the topics across these two chapters. So, you can consider Chapters 10 and 11 as a package of material, rather than two separate chapters. However, your students should still read the chapters in sequence, even if you choose to blend in-class topics from both chapters.

294. Another idea is to play user and put up a slide or write on the board several very easy requirements for a form, but make sure to use words like name and address (not broken into specific fields). See what students come up with and why, for example without the name broken into first and last names searches, and sorts would be impossible. This is a very simple and graphic way to show how data definition and input forms are related.

Answers to Key Terms Suggested answers are provided below.

295. Efficiency: A usability dimension concerned with how quickly users can perform tasks once they know how to perform them.

296. Error rate: A usability dimension concerned with how many errors a user might encounter and how easy it is to recover from those errors.

96 Copyright © 2025 Pearson Education, Inc.

297. Form: A business document that contains some predefined data and may include some areas where additional data are to be filled in. An instance of a form is typically based on one database record.

298. Learnability: A usability dimension concerned with how difficult it is for the user to perform a task for the first time.

299. Lightweight graphics: Small, simple images that allow a Web page to be displayed more quickly.

300. Memorability: A usability dimension concerned with how easy it is to remember how to accomplish a task when revisiting the system after a period of time.

301. Paper prototype: A series of mock screens that can be used to test content, look, and feel, as well as the task flow and other usability factors.

302. Report: A business document that contains only predefined data; it is a passive document used solely for reading or viewing. A report typically contains data from many unrelated records or transactions.

303. Satisfaction and aesthetics: A usability dimension concerned with how enjoyable a system‘s visual appeal is and how enjoyable the system is to use.

304. Stylesheet-based HTML: A Web design approach that separates content from the way in which it is formatted and presented, making ongoing maintenance easier and site-wide consistency much higher.

305. Usability: An overall evaluation of how a system performs in supporting a particular user for a particular task.

306. User eXperience design (UX): A design approach that involves an understanding of the target audience such as their tasks, goals, information needs, and experience levels.

307. Wireframe: A simple design to show the placement of information elements on a screen and the space needed for each element.

Answers to Review Questions 1.301.

10.1. Designing forms and reports is a user-focused activity that typically follows a prototyping approach. First, you must gain an understanding of the intended user and task objectives by collecting initial requirements during requirements determination. After collecting the initial requirements, you structure and refine this information into an initial prototype. Structuring and refining the requirements are completed independently from the users, although you may need to occasionally contact users to clarify some issue overlooked during analysis. Finally, you ask users to review and evaluate the prototype.

After reviewing the prototype, users may accept the design or request that changes be made. If changes are needed, you will repeat the construction-evaluate-refinement cycle until the design is accepted. Usually, several iterations of this cycle occur during the design of a single form or report. The major deliverables produced from the process of designing forms and reports are the creation of design specifications. A design specification includes a narrative overview, a sample design, and a testing and usability assessment section.

1.302.

Some specification information may be irrelevant when designing some forms and reports. For example, the design of a simple ―Yes – No‖ selection form may be so straightforward that no usability assessment is needed. Also, much of the narrative overview may be unneeded, unless it is used to highlight some exception that must be considered during implementation.

97 Copyright © 2025 Pearson Education, Inc.

1.303.

10.2. The initial questions that an analyst must gain answers to in order to build an initial prototype of a system are listed in Table 10-2. These questions include: (1) who will use the form or report; (2) what is the purpose of the form or report; (3) when is the form or report needed and used; (4) where does the form or report need to be delivered and used; and (5) how many people need to use or view the form or report?

1.304.

10.3. There are several situations where highlighting is a valuable technique for conveying special information, these include: (1) notifying users of errors in data entry or processing; (2) providing warnings to users regarding possible problems such as unusual data values or an unavailable device; and (3) drawing attention to keywords, commands, high-priority messages, and data that have changed or gone outside normal operating ranges.

1.305.

10.4. The benefits and problems associated with the use of color are listed in Table 105. As the use of color displays became widely available during the 1980s, a substantial amount of color versus no-color research was conducted. The objective of this research was to gain a better understanding of the effects of color on human task performance. The general findings from this research showed that the use of color has positive effects on user task performance and perceptions when the user is under time constraints for the completion of a task. Color is also beneficial for gaining greater understanding from a display or chart. An important conclusion from this research is that color is not universally better than not using color. The benefits of color only seem to apply if the information is first provided to the user in the most appropriate presentation format. That is, if information is most effectively displayed in a bar chart, color can be used to enhance or supplement the display. If information is displayed in an inappropriate format, color has little or no effect on improving understanding or task performance.

1.306.

10.5. The general guidelines for formatting text are presented in Table 10-6. The guidelines for formatting a help screen are based on the general guidelines for formatting text. These guidelines address case, spacing, justification, hyphenation, and abbreviations.

1.307.

10.6. Three types of labeling improve the usability of a table or list; these types include: (1) all columns and rows should have meaningful labels; (2) labels should be separated from other information by using highlighting; and (3) re-display labels when the data extends beyond a single screen or page.

1.308.

10.7. The guidelines for formatting columns, rows, and text in a table or list include: (1) sort in a meaningful order (e.g., ascending, descending, or alphabetic); (2) place a blank line between every five rows in long columns; (3) similar information displayed in multiple columns should be sorted vertically (that is, read from top to bottom, not left to right); (4) columns should have at least two spaces between them; (5) allow white space on printed reports for user to write notes; (6) use a single typeface, except for emphasis; (7) use the same family of typefaces within and across displays and reports; and (8) avoid overly fancy fonts.

1.309.

10.8. The guidelines for formatting numeric, textual, and alphanumeric data in a table or list include: (1) right justify numeric data and align columns by decimal points or other delimiter; (2) left justify textual data; use short line length, usually 30–40 characters per line; and (3) break long sequences of alphanumeric data into small groups of three to four characters each.

1.310.

10.9. Usability is an overall evaluation of how a system performs in supporting a particular user for a particular task. Usability addresses speed, accuracy, and satisfaction.

98 Copyright © 2025 Pearson Education, Inc.

1.311.

10.10. According to the textbook, most development groups consider time to learn, speed of performance, rate of errors, and retention over time, and subjective satisfaction.

1.312.

10.11. Table 10-11 summarizes the common errors that may occur when designing Web page layouts. These errors include nonstandard use of GUI widgets, anything that looks like advertising, bleeding-edge technology, scrolling test and looping animations, nonstandard link colors, outdated information, slow download times, fixed-formatted text, and displaying long lists as long pages.

1.313.

10.12. Examples where variations in user, task, system, and environmental characteristics might impact the design of system forms and reports are provided in Table 10-10. As an example, assume you are designing a data entry form for a Microsoft Access database. If you are designing this form for the sole use of a novice user, you may choose to place buttons on the form for features such as printing, saving, and navigating.

However, if you are designing a form for an experienced user, you can reasonably assume that the user knows how to work with Access and can design the form to be more flexible.

Answers to Problems and Exercises 1.314.

10.13. Essentially, your students should elicit from their colleagues a definition of the problem and the basic requirements for the budget report. These requirements would include the content, how they want to use the data (e.g., what comparison or decisions they will make from the data), and any other expectations they have about the style of the report. Students should then develop an initial, working prototype using the spreadsheet package. Next, they should use this spreadsheet prototype to revise and enhance the system iteratively with their colleagues. When ready, the prototype is converted to an operational system.

1.315.

10.14. Your students‘ answers will vary depending on their assumptions. For departmental budget reports, there are likely to be many users. If democratic, participative decision making is employed, then the department manager is likely to make copies of the report for each of the workers in her department. The users will then review the budget report and decide together what, if any, actions should be taken. If more autocratic decision making is employed, then the department manager is likely to review the budget report independently and make any necessary decisions. The department manager might also make a copy of the report to send to her area manager, who will integrate and review the various departmental budget reports within the area. The general purpose of these reports is to enable decision makers to review past revenue generation and spending and to make decisions for the future.

1.316.

Budget reports are typically generated at the end of business quarters and at the end of the year. Quarterly reports summarize information for the past three months and the annual reports summarize the entire year. These reports are generally mailed directly to the users, through the organization‘s in-house mail system, through the U.S. Postal Service or some other carrier, or electronically through the organization‘s wide area network, a communication service, or through the Internet.

1.317.

10.15. The worst possible reports come so late that the information is useless, the reports contain information that the user does not need, and they do not contain the information that the user really needs. The presented information has errors and is inconsistent from page to page and from report to report. The layout is difficult to read and understand, and the reports are inflexible, prohibiting the user from changing the information to her liking. As farfetched as this sounds, these types of problems happen 99 Copyright © 2025 Pearson Education, Inc.

frequently with poorly designed reports.

1.318.

The consequences are that the users of these reports are not able to use the reports in any meaningful way. Users ultimately become frustrated with the reports and eventually stop looking at the reports. If the users cannot find the information they need in some other way, their decision making and performance suffers. Ultimately, the organization‘s performance will suffer. The prototyping process helps guard against these problems because users and system personnel work together to ensure that the reports are useful; they present useful information in an effective format, and they are delivered in a timely manner.

1.319.

10.16. There are a variety of ways that students can design such a form. Similarly, they may choose from among a variety of tasks for their form. They may choose to create a form that shows registration information for a guest or that shows the room charges for a guest. This form may have a place for the guest to sign at the bottom of the form. Using the guidelines from the chapter, students should create effective black/white and color forms. If a color printer is available, have students print out all their forms, without their names attached. Then pass the forms around the room and have students rate them.

Alternatively, display the corresponding pairs of black/white and color forms for the entire class and have them critique each form based on the guidelines from the chapter.

10.17. Students are likely to choose an example that is familiar to them, such as transcripts. Traditionally, transcripts have been difficult to obtain on time. For official transcripts, students usually request in writing that the transcripts be sent to another university or to a prospective employer. The transcripts are then sent through regular mail to the intended party. The turnaround on this process is usually very slow. If the student no longer lives in the town where the university is located, then their initial request for official transcripts must also be sent through regular mail, which lengthens the process even further. Obtaining unofficial copies of transcripts, even when requested in person, often takes several days. Transcripts are often accurate, although recent grades and/or changes in grades might not appear on transcript copies. Satisfaction with the use of transcripts is usually mixed. When the transcripts are well designed, they are easy and satisfying to use. When the transcripts are not well designed, with poor layout and cryptic symbols and terminology, they are difficult to use and are not satisfying. Transcripts can be improved by changing the layout so that they are useful for students as well as university staff and administrators. In addition, transcripts would be more useful if the turnaround time on a transcript request could be shortened. Some universities have made transcript information available online.

1.320.

1.321.

10.18. Expect your students to list at least a graphical user interface/operating system, word processor, spreadsheet, graphics package, and, perhaps, some games. It is useful for students to compare their answers, particularly if they are using the same or competing software packages. It will be useful for you, the instructor, to generate your own answer to this question and share this with your students. One common set of software applications for an instructor would be Microsoft Windows, Word, Excel, and PowerPoint, which have each improved markedly in their usability and performance.

1.322.

10.19. This form can be improved in several ways. For example, the organization name should be listed with the title information. In addition to the printing date, the date when the report was last updated is needed. The information presented in this report is limited.

The user may need to know more about each of the customers other than their identification number and name. The information is packed tightly and is difficult to read.

Navigation information is not provided, such as which page of the ―n‖ pages is being observed. The order in which entries appear is also unclear; note that Cust-ID and 100 Copyright © 2025 Pearson Education, Inc.

Organization sortings are not identical.

1.323.

Depending on what the users will do with the data, sorting the list by Cust-ID may not be useful. In order to further critique the form, certain assumptions must be made about the users and applicable task. For example, if all that is needed is a list of the current customers, then the information presented on the report is adequate. If, however, the users need to know whether or not customers are currently active, and when they placed their last order, then the information presented on the report is not sufficient.

1.324.

10.20. For consistency, the form should make use of the same button or keystroke sequence to move from this form to other parts of the system. In addition, the same terminology and abbreviations should be used for information used on this and other forms. For example, the term, ―customer name,‖ should always appear the same way. For efficiency, the input points for customer information should be aligned so that the necessary information can be input efficiently. Totals for charges should be computed automatically. For ease, labels should be used for each of the pieces of information that are to be entered (customer name, address, telephone number, method of payment, etc.).

The registration clerk should not have to remember information from previous uses of this and other systems in order to use the form. For example, the current rates for various rooms should be readily available. For format, the information should be placed on the screen in such a way that it is obvious what information must be input. Proper decimal places and dollar signs should be used for charge and payment information. For flexibility, the user should be allowed to choose between clicking on buttons with the mouse and using shortcut keystrokes to perform these same operations. Users should also be able to enter information in any order, depending on the order that the customer gives the information.

1.325.

10.21. Table 10-10 summarizes the characteristics to consider when designing forms and reports. Differences in the user, task, system, or environment influence the time to learn, performance, error rate, retention, and satisfaction. The forms and reports used by hospital admitting staff, cashiers, and delivery personnel are good examples. For instance, a new user of the patient admitting form requires an easy to use, straightforward form. An experienced user requires an easy-to-use form, but also requires a form that allows more flexibility. With the hospital admitting example, you can also compare the impact that different operating systems have on the accomplishment of the task and the way the user interacts with the system.

1.326.

10.22. This question will promote much discussion among your students, since they have likely encountered many Web sites that contain these common errors. If you have access to a computer in the classroom, you may want to access several of these sites during class time. You can demonstrate and discuss with your students several of the errors that they have identified.

1.327.

10.23. Students should be encouraged to use different tools to generate the screen designs.

1.328.

10.24. Students should be encouraged to use different tools to generate the screen designs. You might split up the class and have groups of students try one tool and others try different tools.

Guidelines for Using the Field Exercises 1.329.

10.25. Students are likely to note many of the same criticisms about their grade reports that they noted about their transcripts. Grade reports often take a long time to arrive at the 101 Copyright © 2025 Pearson Education, Inc.

student‘s house, and this delivery time could be shortened. Grade reports are often accurate, although students may joke that they wish the grade reports would report a grade higher than the grade that they received. Similar to transcripts, satisfaction with grade reports is usually mixed. Sometimes they are well designed, as recommended in this chapter. Sometimes they are not well designed. When grade reports have poor layout and cryptic symbols and terminology, they are difficult to use and are not satisfying. To improve grade reports they might also have additional information that students often want to know, such as their grade on a final project or on a final examination, GPA by major as well as overall and by semester, or their grade compared to class averages.

1.330.

10.26. It should be relatively easy for students to gain access to this type of software either through their university or their place of work. If they cannot actually access the software, they can look through the manuals for this software. These packages are rich with powerful features for designing printed output. For example, Microsoft‘s Visual Studio Suite lets you design the layout of printed outputs as if you were using a word processor or a graphics package.

1.331.

10.27. The use of displays is prevalent in nearly every field. For example, displays are used in aviation, all forms of mass media, education, government, and in professional sports. For obvious reasons, some of these other areas have more standardized displays.

For example, in aviation the display screens of the air traffic controller are very rigidly mandated to ensure consistency and, thus, safety. Other fields have more informal rules, or no rules at all, about how information is displayed. For example, printed mass media have a variety of forms. It will be useful to have students use their imaginations and then share their answers with each other. This helps demonstrate the diversity of display uses.

10.28. Students are likely to find a variety of forms. For example, they may analyze a product order form, an employment application, or a class registration form.

Alternatively, they may observe online forms, such as a computer sign-on menu.

Similarly, students are likely to find a variety of reports. They may analyze an invoice, a pie or bar chart summarizing information, a budget, or a class roster. They may also observe an online report, such as a summary of inventory information.

1.332.

1.333.

10.29. In addition to the library, students will also find that the Web is a useful source of information about companies. Corporate annual reports are a wonderful example of how printed reports (and now online reports) convey information and even persuade. Modern annual reports use color and graphics extensively to highlight information. Be sure that students look closely at the use of formatting in order to hide or enhance the understanding of information. Corporations typically use formatting in their annual reports very effectively in order to emphasize the positive and de-emphasize or downplay the negative.

1.334.

10.30. Students are likely to find that there are differences of opinions over and preferences for various PC-based software packages. In fact, there are often heated debates over whether PC-based or Mac-based software is best. Generally, with large sample sizes and many trial uses, software vendors gain an accurate picture of the usability of a software application for a given market sector. For their relatively small, convenient samples, students might not be able to find any consensus among the users they interview.

Chapter 11 Designing Interfaces and Dialogues 102 Copyright © 2025 Pearson Education, Inc.

Chapter Objectives Chapter 11 introduces students to the process of designing interfaces and dialogues. The content of this chapter naturally extends the topics presented in Chapter 10, which means that the guidelines for designing forms and reports also apply to the design of human–computer interfaces. Additionally, form and report design and interface and dialogue design have similar processes and deliverables. Thus, your lectures and exercises should stress this similarity, emphasizing the importance of the right information, in the right amount of detail, at the right time. Some instructors prefer to teach these topics together to avoid redundancy and to show the linkages between the chapters. Teaching these topics together or separately is equally effective.

Chapter 11 provides a review of human–computer interaction methods and devices. Depending on your overall curriculum, these topics may be redundant or too rudimentary for your students.

If so, simply have students skim this material. The most important parts of this section (and possibly the most interesting to discuss) are the menu design guidelines and Tables 11-3 and 11-4, which contrast interaction devices. Both topics are worthy of some class time. In the ―Designing Interfaces‖ section, students are given pointers for designing layouts, structuring data entry, controlling data input, providing feedback, and providing help. The ―Designing Dialogues‖ section introduces students to three major dialogue design steps. These steps include designing the dialogue sequence, building a prototype, and assessing usability. Table 11-13 summarizes the guidelines for the design of human–computer dialogues. In the chapter‘s final section, the authors provide general guidelines for designing the human interface for Internet-based electronic commerce applications. Table 11-15 identifies nine common errors that occur when designing the interfaces and dialogues for Web sites.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 308. Explain the process of designing interfaces and dialogues and the deliverables for their creation.

309.

Describe and contrast several methods for interacting with a system.

310. Describe various input devices and discuss usability issues for each in relation to performing different tasks.

311. Illustrate how to apply the general guidelines for designing interfaces and specific guidelines for layout design, structuring data entry fields, providing feedback, and system help.

312. Illustrate how to design human–computer dialogues, including the use of dialogue diagramming.

313.

Illustrate how to design graphical user interfaces.

314. Discuss general guidelines for designing the human interface for Internet-based electronic commerce applications.

315. Discuss common errors that occur when designing the interfaces and dialogues for Web sites.

Classroom Ideas 316. This chapter introduces concepts and terms that are central to understanding the interface and dialogue design process. Discuss Review Question 11.2 in class to be sure that your 103 Copyright © 2025 Pearson Education, Inc.

students understand the chapter material. Also, ask your students to review the Key Terms listed at the end of the chapter.

317. During a lecture, an effective way to teach the various information formatting concepts is to use the tables and figures in the chapter to contrast proper and improper designs.

318. Lecturing from the Review Questions, Problems and Exercises, and Field Exercises is one alternative to lecturing on the chapter contents. Pose selected questions to your students, helping focus a discussion on specific concepts.

319. Another effective in-class exercise is to ask students who have been on systems development teams to compare their experiences to the concepts presented in Chapter 10.

This discussion is a good way to elaborate on alternative ways for designing human– computer interfaces.

320. If you have access to practicing systems analysts, an insightful activity is to invite them into your class to discuss how they design dialogues and interfaces in their organizations (processes, types of development and prototyping tools, etc.).

321. If you have access to a CASE tool or a visual development tool, it is often fun and informative for you to rapidly construct an interface interactively with the class.

322. If you can hold your class in a computer classroom where each student has access to a computer and development software, ask your students to create designs for some fictitious system. Even though you provide students with the same specifications, it is an interesting exercise to have students share their designs with other class members. After doing this, discuss why some of the designs are different, but still conform to the design guidelines from the chapter and the specifications that you gave them. Now, discuss how this relates to usability, consistency in design, and so on.

323. Comparing and contrasting designing for a mouse-driven computer and a finger- or gesture-driven tablet would be an interesting conversation for students. Ask students to come up with a tablet interface and then the same computer interface to help highlight the point of the challenges designing for different devices. Use Table 11-3 to drive the in-class conversation.

Answers to Key Terms Suggested answers are provided below.

324. Command language interaction: A human–computer interaction method whereby users enter explicit statements into a system to invoke operations.

325. Cookie crumbs: The technique of placing ―tabs‖ or sequenced links on a Web page that show a user where he or she is within a site and where he or she has been.

326.

Dialogue: The sequence of interaction between a user and a system.

327. Dialogue diagramming: A formal method for designing and representing human– computer dialogues using box and line diagrams.

328. Drop-down menu: A menu-positioning method that places the access point of the menu near the top line of the display; when accessed, menus open by dropping down onto the display.

329. Form interaction: A highly intuitive human–computer interaction method whereby data fields are formatted in a manner similar to paper-based forms.

330.

331.

Icon: Graphical picture that represents specific functions within a system.

Interface: A method by which users interact with an information system.

104 Copyright © 2025 Pearson Education, Inc.

332. Menu interaction: A human–computer interaction method in which a list of system options is provided and a specific command is invoked by user selection of a menu option.

333. Natural language interaction: A human–computer interaction method whereby inputs to and outputs from a computer-based application are in a conventional spoken language such as English.

334. Object-based interaction: A human–computer interaction method in which symbols are used to represent commands or functions.

335. Pop-up menu: A menu-positioning method that places a menu near the current cursor position.

Answers to Review Questions 1.335.

11.1. a. A dialogue reflects the sequence of interaction between a user and a system. An interface is a method by which users interact with information systems. b. Command language interaction is a human–computer interaction method where explicit statements are entered into a system to invoke operations. Menu interaction is a human–computer interaction method where a list of system options is provided, and a specific command is invoked by user selection of a menu option. Form interaction is a highly intuitive human–computer interaction method where data fields are formatted in a manner similar to paper-based forms. Object-based interaction is a human–computer interaction method where symbols are used to represent commands or functions. Natural language interaction is a human–computer interaction method where inputs to and outputs from a computer-based application are in a conventional speaking language such as English. c. A drop-down menu is a positioning method that places the access point of the menu near the top line of the display; when accessed, menus open by dropping down onto the display. A pop-up menu is a positioning method that places a menu near the current cursor position.

1.336.

11.2. The process of designing interfaces and dialogues is similar to that of designing forms and reports (outlined in Chapter 10). Thus, the design process is a user-focused activity that typically follows a prototyping approach. First, you must gain an understanding of the intended user and task objectives by collecting initial requirements during requirements determination. After collecting the initial requirements, you structure and refine this information into an initial prototype. Structuring and refining the requirements are completed independently from the users, although you may need to occasionally contact users to clarify some issue overlooked during analysis. Finally, you ask users to review and evaluate the prototype. After reviewing the prototype, users may accept the design or request that changes be made. If changes are needed, you repeat the construction-evaluate-refinement cycle until the design is accepted. Usually, several iterations of this cycle occur during the design of a single interface or dialogue. The deliverables produced from the process are design specifications that include a narrative overview, sample design, testing and usability assessment, and outline of dialogue sequence.

105 Copyright © 2025 Pearson Education, Inc.

1.337.

Some specification information may be irrelevant when designing some systems.

For example, for a simple system, using common modules, the design may be so straightforward that no usability assessment is needed. Also, much of the narrative overview may be unnecessary unless it is used to highlight some exception that must be considered during implementation.

1.338.

11.3. Methods for interacting with a system include: (1) command language interaction, (2) menu interaction, (3) form interaction, (4) object-based interaction, and (5) natural language interaction. Command language interaction is a human–computer interaction method where explicit statements are entered into a system to invoke operations. Menu interaction is a human–computer interaction method where a list of system options is provided, and a specific command is invoked by user selection of a menu option. Form interaction is a highly intuitive human–computer interaction method where data fields are formatted in a manner similar to paper-based forms. Object-based interaction is a human– computer interaction method where symbols are used to represent commands or functions. Natural language interaction is a human–computer interaction method where inputs to and outputs from a computer-based application are in a conventional speaking language such as English.

1.339.

Each method is different, and all have their strengths and weaknesses. Without specifying the characteristics of the user, task, environment, etc. it is not possible to flatly state that one method is ―better‖ than the others.

1.340.

11.4. Common input devices are summarized in Table 11-2. Each device is different, and all have their strengths and weaknesses. Without specifying the characteristics of the user, task, environment, etc. it is not possible to flatly state that one device is ―better‖ than the others. You might present your students with specific situations and ask them to identify which interaction device is preferable in the given situation.

1.341.

11.5. Guidelines for the design of menus are summarized in Table 11-1. In certain circumstances, some of the menu design guidelines can be violated. For example, in some cases, a menu title can be shortened below that of being meaningful for all users if the most likely user is an expert.

1.342.

11.6. The general sections of a typical business form contain header, sequence or timerelated, instruction or formatting, body or data details, totals or data summary, authorization or signatures, and comments information.

Computer-based and paper-based forms should have the same components, if possible, in order to ease the transfer of information from paper-based forms to a system.

Consistency in design makes it easier for users to understand the meaning of the information on the form, speeds data entry, and, in general, reduces communication and data entry errors.

1.343.

1.344.

1.345.

11.7. The functional capabilities of an interface are summarized in Table 11-5. When designing the navigation procedures within your system, flexibility and consistency are primary concerns. Users should be able to freely move forward and backward or to any desired data entry fields. Consistency extends to the selection of keys and commands.

Each key or command should have only one function, and this function should be consistent throughout the entire system and across systems if possible. The most important capabilities vary from system to system. For a given system, consistency is the most important capability.

11.8. The general guidelines for structuring data entry fields are summarized in Table 11-6. Some of the design guidelines can be violated in certain circumstances. For 106 Copyright © 2025 Pearson Education, Inc.

example, a help system can be omitted from a very simple system or a system designed to be used by a single user (or small group).

1.346.

11.9. Types of data errors include: (1) appending, (2) truncating, (3) transcripting, and (4) transposing. The appendage data error occurs when characters are added to a field.

The truncation data error occurs when characters are lost from a field. The transcription data error occurs when invalid data is entered into a field, and the transposition data error occurs when the sequence of one or more characters in a field is reversed.

1.347.

11.10. Validation tests and techniques include class or composition, combinations, expected values, missing data, pictures/templates, range, reasonableness, self-checking digits, size, and values. These validation tests and techniques are summarized in Table 11-9.

1.348.

11.11. Three types of system feedback are discussed in the chapter; these include: (1) status information, (2) prompting cues, and (3) error and warning messages. No single method can be deemed ―most‖ important because each is critical to an effective design.

1.349.

11.12. The general guidelines for designing usable help are summarized in Table 11-11.

These guidelines are simplicity, organize, and show. Some of these design guidelines can be violated in certain circumstances. For example, a help system can be omitted from a very simple system or a system designed for use by a single user (or small group).

1.350.

11.13. The three major steps in dialogue design are: (1) design the dialogue sequence, (2) build a prototype, and (3) assess usability. A case can be made for the importance of all steps. Yet, designing the dialogue (with input from the user) is likely the most important step because this is where you collect and structure the users‘ requirements.

1.351.

11.14. The common properties of GUI windows and forms are summarized in Table 1114. When creating a dialogue, the property in a GUI that is likely the most important is that of modality. Modality allows you to create forms that either require the user to resolve a request before proceeding or selectively choose to resolve a request before proceeding. Creating dialogues that allow the user to jump from application-toapplication, or from module-to-module within a given application, requires you to carefully think through the design of dialogues and their applications.

1.352.

11.15. Common interface and dialogue errors found on Web sites include: opening a new browser window, breaking or slowing down the back button, complex URLs, orphan pages, scrolling navigation pages, lack of navigation support, hidden links, links that do not provide enough information and buttons that provide no click feedback. Table 11-15 provides descriptions of these common errors.

Answers to Problems and Exercises 1.353.

1.354.

11.16. Students should be familiar with several PC-based software applications. Nearly all PC-based software applications use graphical user interfaces with pop-up menus, drop-down menus, buttons, icons, and the point-and-click of a mouse. For example, this instructor‘s manual is being composed in Microsoft Word. To spell-check this answer, the user drags the mouse pointer across the text, clicks on the button for the spell checker, and clicks on a button in a pop-up window to end the operation. For the most part the new, Windows-based software applications are quite sophisticated, so student evaluations should be positive.

11.17. The users for a hotel registration system include hotel employees working at the front desk, people working at the concierge desk, and guests. The system‘s primary purpose is to assist in quickly and effectively registering guests to the hotel. The people at 107 Copyright © 2025 Pearson Education, Inc.

the concierge desk can use the system to register guests when the front desk has an overload. They might also use the system to check on or change a guest‘s information.

The hotel might even let prospective guests use the system directly to either register or check their registration. Such a system might display information on room availability and rates, places for the user to enter guest information, and a map to show the guest how to get to his room and where to park his car.

1.355.

11.18. The primary users of a university registration system are the personnel in the university registrar‘s office. These users are likely to know a fair amount about the content of their work, but they are not likely to be computer experts. They need a system that is easy to use. This system‘s primary task is to quickly and accurately register students for the university. Thus, the system should be fast and error-free. In addition, because the users are processing many applications, the system should be designed so that it does not unnecessarily fatigue the users.

1.356.

There are a number of systems on which this application can be implemented.

The type of system on which this application is implemented influences how the interface is designed. For example, system characteristics determine whether the application runs with a black and white, text-based interface or a full color, graphical user interface. The environment differs from university to university and plays an important role in shaping the system. For example, the relative status of the users in their organization determines how much money is spent on their application, which influences the type of interface used. The location of the users also influences the nature of the system and interface. Are the users located in a back office, or are they located at a front desk where they interact directly with students who might see the screen?

11.19. Your students have probably used a software package that employs a command language and menus as part of its interface. In addition, nearly all packages that have a graphical user interface employ menus of one kind or another. If your students have programmed recently with applications like Microsoft‘s Visual Basic, then they have had experience with objects. It appears that the command language interface is going away, while the menus within graphical user interfaces are pervasive. Many predict that the object type of interface, which is currently growing in use, is the interface of the future.

1.357.

1.358.

11.20. Because form interaction is a way to input and present information, there are many business tasks that are good candidates for form interaction. Any task that requires a customer or employee to provide information is a likely candidate. For example, product order forms and employee applications are good candidates. In addition, tasks where the system presents information to the user are served well with form interaction.

For example, to check inventory, an employee can call up a part form and enter information about the part (e.g., the part name or number). The system then uses the input data to search for and present the needed information to the user. The system might allow the user to input onto the form some parameters to use when searching for the part. The user might request parts that were made between certain dates, made using certain equipment, or purchased from a certain vendor.

1.359.

11.21. Students are likely to have used a keyboard, mouse, joystick, and trackpad. Still others have used a touch screen or a stylus. Fewer students have used a graphics tablet or voice. Your students‘ personal evaluations of the input devices will vary. It is useful for your students to compare their evaluations so that they can see the diversity of preferences and uses that drives device design and choices. Ask your students to discuss new devices that are not included in the chapter. Ask your students to evaluate these new technologies and compare these technologies to the input devices discussed in the chapter. Are there any interface devices that are currently not being made and sold that 108 Copyright © 2025 Pearson Education, Inc.

students envision being made and sold in the future?

109 Copyright © 2025 Pearson Education, Inc.

1.360.

1.361.

11.22. There are several settings for which natural language interaction is useful. For those settings where users are not computer experts, natural language enables these users to interact with the system quickly and easily. For example, when employees with little or no computer expertise (or time or inclination to learn) must access and query a database, natural language is useful. In addition, there are some settings where the subject matter does not lend itself well to vocabulary, grammar, and style of computer software languages. For example, an expert system designed to truly mimic the behavior of a human can do so much more effectively with a natural language interface. Similarly, voice interfaces are useful in settings where users must use their hands to perform other operations, or where users are physically unable to use their hands.

11.23. If students do not have their own software, or if they cannot access software at a workplace, they can access multiple software packages in the computer laboratories at their university. Nearly all of the newer software packages have extensive help systems.

Thus, these packages should do well in an evaluation using the guidelines in Table 11-11.

For example, Microsoft Word has the following components as part of its help system: table of contents, search tool, index, a quick preview of the word processor (i.e., a tutorial), examples, demonstrations, tips, help for users of other word processors, information on getting technical support, and product version information. As a side issue, ask students how they feel about the ―assistant‖ feature provided in products like Microsoft Office.

1.362.

11.24. Students should easily design a simple display for hotel registration data entry.

Such a display basically requires the user to input the prospective guest‘s name, address, telephone number, method of payment, information about payment (e.g., credit card number or check number), whether or not they have a car and, if so, the license plate of the car and the state in which the car is licensed, length of stay, and whether the guest wants a smoking or nonsmoking room. It is not important that students capture all the necessary information on their sample displays; rather, it is important that their displays conform to the guidelines outlined in Table 11-6, and that students can argue logically for the design choices they have made.

1.363.

11.25. One potential dialogue scenario for a hotel registration system might be: a request to view room availability and relevant rates, select a room and rate, input guest information, input and verify payment information, select printing of receipt, and leave the system.

1.364.

11.26. There are several ways that students can design their dialogue diagrams for their sample hotel registration data entry system. It is helpful for your students to use as a guide the dialogue diagram in Figure 11-19, which is for the Customer Information System at Pine Valley Furniture. Students may place the data entry display within the broader information system at the hotel, much like the request to view year-to-date customer information was placed within the dialogue diagram of the overall Customer Information System. It is not important that all the pieces of the student‘s system are included, nor is it necessarily important how the student chooses to diagram the interaction; rather, it is important that students‘ diagrams show logical, simple navigation and the appropriate components (i.e., top, middle, and bottom) of each box representing screens.

1.365.

11.27. The textbook mentions the Web‘s single ―click to act‖ method of loading static hypertext documents, limited capabilities of most Web browsers to support finely grained user interactivity, limited agreed-upon standards for encoding Web content and control mechanisms, and lack of maturity of Web scripting and programming languages as well as limitations in commonly used Web GUI component libraries.

110 Copyright © 2025 Pearson Education, Inc.

1.366.

11.28. This question should promote much discussion among your students, since they have likely encountered many Web sites that demonstrate the common errors highlighted in Table 11-15. If you have access to a computer in the classroom, you may want to access several of these sites during class time. You can demonstrate and discuss with your students several of the errors that they have identified.

Guidelines for Using the Field Exercises 1.367.

11.29. Students should target their search on articles in the academic journals and magazines in the popular press, as opposed to reviewing only books on natural language interaction. This enables your students to learn about the more recent status of the field.

Also, much information about natural language interaction is available on the Web. So, as an alternative to the library, students can search the Web for related, up-to-date information.

1.368.

It is important that students use what they have learned in the literature to support their forecast for how long it will be before natural language capabilities are prevalent in information system use. Have students give and support their answers in front of the class. If there are differences of opinion, have students find out what arguments and assumptions underlie these differing forecasts.

1.369.

11.30. In many ways, PC interfaces are converging. However, there are still subtle differences in how these interfaces operate and look. Surprisingly, there are often very strong differences of opinion about the relative merits, limitations, and differences among these interfaces. One thing about interfaces is clear; people have different preferences for interacting with their PC via a graphical user interface. Some people like to click on an item in a menu bar and have the drop-down menu open and remain open, even if the user releases the mouse button. Others prefer the drop-down menu remain open only if the user holds down the mouse button. Differences like these are subtle, but some people prefer one method to another. Students should keep in mind that what is intuitive, easy, and better for one person is not necessarily better for another person.

11.31. It is useful for students to answer this question after answering Problem and Exercise 11.21. Students can supplement their knowledge and use of input devices by talking with other people. Although students have probably used a keyboard, mouse, joystick, trackpad, and stylus, they probably have not used a touch screen, graphics tablet, or voice interface. They may be able to find someone at their workplace or university that has used one of these other devices. They may even contact someone at an organization where they have seen new input devices used. For example, delivery truck drivers often use a stylus to have customers sign for packages. Car rental agency employees often use hip-based PCs and printers to log in the return of a rented car and issue a receipt.

Alternatively, students can review computing magazines or a shopping guide and call vendors directly.

1.370.

1.371.

11.32. Graphical user interfaces (GUI) are used in nearly every organization, so it should not be hard to find analysts and programmers who have experience with these interfaces. Students are likely to find that to build a good quality graphical user interface, analysts and programmers spend a lot of time in the design phase carefully planning the flow and navigation throughout the system. Students are also likely to find that, fortunately, the actual building of graphical user interfaces is relatively easy. System developers can build graphical user interfaces using software development tools that have a graphical user interface. For example, Microsoft‘s Visual Basic provides for the programmer a graphical user interface to use to quickly and easily build graphical user 111 Copyright © 2025 Pearson Education, Inc.

interfaces for users. Building a working interface is not much more difficult than drawing the interface using a graphics package.

Chapter 12 System Implementation and Maintenance Chapter Overview This chapter introduces students to many of the activities carried out during implementation, including coding, testing, installation, documentation, user training, and support for a system after it is installed. Although most systems development texts do not include much material on implementation, this situation is remedied by providing material on relevant management issues, including change management, organizational politics, and implementation success. The chapter also includes a discussion of implementation failure, something few systems developments texts discuss, despite the high rate of information systems failure. The discussion of failure is presented in the context of factors the analyst (and project manager) can control in an attempt to ensure success.

One of the goals of this chapter is to show the student that implementation is neither simple nor mechanical. Throughout the textbook, systems development is emphasized as a change process.

For many users, the most obvious evidence of change comes during implementation. Once a new system has been coded, tested, and installed, the systems development team does not simply walk away. The organizational members left with the new system, the users, need a solid understanding of how the new system fits into their work lives and how the system can support them in their day-to-day work activities. User documentation, training, and continuing support are all parts of providing this solid understanding to users. In some organizations, other specialists in the IS department, such as technical communicators, trainers, local experts, and help desk employees, are available to help the analyst complete this part of the implementation process. In other organizations, the analyst will do most of this work alone. In the latter case, the importance of user documentation, training, and support should not be overlooked. The success of a system implementation effort depends on what the users think of the system and their inclination to use it well. The training and support efforts have a definite effect on user attitudes and inclinations.

Systems security is also an important element of implementation and should be designed, as well as acknowledged, as an ongoing maintenance issue. Table 12-8 shows the organizational significance of this threat and the economic impact on the firm.

In the ―Electronic Commerce Application: System Implementation and Operation for Pine Valley Furniture‘s WebStore‖ section, the concepts presented in this chapter are applied to the implementation process conducted at PVF‘s WebStore. The authors discuss the preparation of test cases and the alpha and beta testing process for the WebStore.

The chapter also introduces students to the process of maintaining information systems, the final phase of the systems development life cycle. More information systems professionals are devoting their careers to systems maintenance. Also, as more systems move from initial development into operational use, it is likely that even more professionals will work in maintenance-related activities in the future. This chapter links maintenance to the SDLC and describes the four types of maintenance requests: corrective, adaptive, perfective, and preventive.

After describing the types and costs of maintenance, the chapter describes several managerial issues related to system maintenance. The chapter concludes by describing the role of CASE in 112 Copyright © 2025 Pearson Education, Inc.

maintenance, discussing Web site maintenance, and examining the maintenance process at Pine Valley Furniture‘s WebStore. The topics presented in this chapter are very important for students to understand because they represent the most prominent systems development activity, an activity that many students are likely to encounter. The impact of CASE tools and their use in reverse engineering and reengineering should also be discussed as the future of maintenance of systems and how they minimize costs and allow the more rapid deployment of modified and extensible systems.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 336.

Discuss with students the sub-processes that make up system implementation.

337. Teach students about the many different types of testing that occur in implementation and when each one is appropriate.

338.

Show students how to prepare a test plan for an information system.

339. Have students distinguish among four installation strategies (direct, parallel, single location, and phased installation) and know when to use each one.

340. Explain the differences between system and user documentation, emphasizing that system documentation occurs throughout the SDLC. 341. Provide students with the information necessary for them to write task-oriented user documentation.

342. Demonstrate the many different modes available for training users, including tutorials, courses, self-training, e-learning, electronic performance support systems, and other types of embedded training.

343.

Show students how to prepare a training plan for an information system.

344. Explain to students the issues associated with user support, whether internal or external to the organization.

345. Teach students about the factor and political models of implementation and how to use such models to help ensure implementation success.

346.

Explain and contrast four types of maintenance.

347. Describe several factors that influence the cost of maintaining an information system and apply these factors to the design of maintainable systems.

348. Describe maintenance management issues, including alternative organizational structures, quality measurement, handling change requests, and configuration management.

Classroom Ideas 349. If your students have completed programming courses and are familiar with both coding and testing, ask your students to think about coding and testing in the context of what they have learned about systems development. What methods can they suggest that would help manage coding and testing in an ongoing systems development project, as opposed to a series of isolated programming class projects?

350. Have your students generate a test plan for one or more of the various systems development projects presented in the text; for example, Hoosier Burger‘s food ordering system or inventory control system. Have students consider Mosley‘s seven types of testing, 113 Copyright © 2025 Pearson Education, Inc.

as well as user acceptance testing. Alternatively, have students develop a testing plan (at a general level) for a major packaged software release, such as a new version of a popular DBMS (e.g., Microsoft Access or Oracle) or a major application system, such as SAP. 351. Present a series of information system implementation scenarios. Have your students determine which strategy, direct, parallel, single location, or phased, works for each scenario and why.

352. Have your students identify the aspects of the factor and political models of implementation they should consider for the Hoosier Burger and Pine Valley Furniture systems presented in the text. Ask your students to generate lists of what they believe could go wrong during implementation for either company. These lists should accompany suggestions for addressing these potential problems.

353. Use Table 12-5 to demonstrate the differences between system and user documentation.

Encourage your students to think about being a user, not a developer or IS specialist, wherein one‘s focus is on doing the job, not using the software. Bring in a user‘s manual for a common product (e.g., microwave oven or an electronic device) and have your students analyze the features of this manual that make it a good or bad manual.

354. Several examples of documentation are provided in the chapter. Ask your students to bring in other examples. Some students will have access to documentation prepared for customized applications developed for a variety of purposes and computer platforms. Ask your students to present their documentation to the class. Your students should show at least the table of contents and samples from different sections of the documentation.

355. Use Table 12-7 as the starting point for a discussion on the various training modes.

Prepare an example that utilizes several modes, so students can see how training varies by mode. For example: how would training for an order processing system operator look if the training were a tutorial? If it were a formal course? If it were provided by a local expert (e.g., the operator at the next station)? If it were embedded in the order processing software?

356. Have students include a detailed training plan in the user documentation they turn in as part of their semester projects. Have at least one group (or student) present its training plan in class.

357. Ask your students to compare and contrast the different types of user support discussed in the chapter. For a particular system or job, which types of support would they, as users, prefer and why? Use this in-class discussion to develop recommendations on when to use the different forms of user support.

358. Invite an IS professional from a local organization to your class to discuss how his organization manages user documentation, training, and support. Ask this guest to discuss such topics as: how documentation is tested, who manages updates and distribution of updated documentation, how updating documentation is coordinated with updating the software, what training methods the organization employs, who conducts the training and how trainers are trained, how much the organization spends on information systems training as a percentage of the total IS budget or IS development budgets, how much the organization spends on information systems support as a percentage of the total IS budget, and how the help desk and information center functions have changed over time.

359. Invite an IS professional to speak to the class about the internal and external threats to the organization from breaches in IS security.

360.

Discuss Review Question 12.18 in class, because it encourages students to compare 114 Copyright © 2025 Pearson Education, Inc.

several key terms. Also, ask your students to review the key terms listed at the end of the chapter.

361. An alternative method to presenting the chapter material is to lecture from the Review Questions, Problems and Exercises, and Field Exercises. Pose selected questions to your students, helping focus a discussion on specific concepts. Problems and Exercises 12.39, 12.40, 12.41, 12.43, and 12.46 and Field Exercise 12.55 are good motivators for class discussion.

362. Another very effective in-class exercise is to ask students who have maintained an information system to compare their experiences to the concepts presented in Chapter 12.

This discussion is a good way to elaborate on key system maintenance issues.

363. If you have access to practicing systems analysts, an insightful activity is to invite these analysts into your class to discuss how maintenance is managed in their organization.

Answers to Key Terms Suggested answers are provided below.

364. Acceptance testing: The process whereby actual users test a completed information system, the end result of which is the users‘ acceptance of it.

365. Adaptive maintenance: Changes made to a system to evolve its functionality to changing business needs or technologies.

366.

Alpha testing: User testing of a completed information system using simulated data.

367. Baseline modules: Software modules that have been tested, documented, and approved to be included in the most recently created version of a system.

368. Beta testing: User testing of a completed information system using real data in the real user environment.

369. Build routines: Guidelines that list the instructions to construct an executable system from the baseline source code.

370. Configuration management: The process of ensuring that only authorized changes are made to a system.

371. Corrective maintenance: Changes made to a system to repair flaws in its design, coding, or implementation.

372. Desk checking: A testing technique in which the program code is sequentially executed manually by the reviewer.

373. Direct installation: Changing over from the old information system to a new one by turning off the old system when the new one is turned on.

374. Help desk: A single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department.

375. Inspections: A testing technique in which participants examine program code for predictable language-specific errors.

376. Installation: The organizational process of changing over from the current information system to a new one.

377. Integration testing: The process of bringing together all of the modules that a program comprises for testing purposes. Modules are typically integrated in a top-down, incremental fashion.

378.

Maintainability: The ease with which software can be understood, corrected, adapted, and 115 Copyright © 2025 Pearson Education, Inc.

enhanced.

379.

Maintenance: The fixing or enhancing of an information system.

116 Copyright © 2025 Pearson Education, Inc.

380. Mean time between failures (MTBF): A measurement of error occurrences that can be tracked over time to indicate the quality of a system.

381. Parallel installation: Running the old information system and the new one at the same time until management decides the old system can be turned off.

382. Perfective maintenance: Changes made to a system to add new features or to improve performance.

383. Phased installation: Changing from the old information system to the new one incrementally, starting with one or a few functional components and then gradually extending the installation to cover the whole new system.

384.

Preventive maintenance: Changes made to a system to avoid possible future problems.

385.

Refactoring: Making a program simpler after adding a new feature.

386. Single-location installation: Trying out a new information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization.

387. Stub testing: A technique used in testing modules, especially where modules are written and tested in a top-down fashion, where a few lines of code are used to substitute for subordinate modules.

388. Support: Providing ongoing educational and problem-solving assistance to information system users. For in-house developed systems, support materials and jobs will have to be prepared or designed as part of the implementation process.

389. System documentation: Detailed information about a system‘s design specifications, its internal workings, and its functionality.

390. System librarian: A person responsible for controlling the checking out and checking in of baseline modules for a system when a system is being developed or maintained.

391. System testing: The bringing together of all of the programs that a system comprises for testing purposes. Programs are typically integrated in a top-down, incremental fashion.

392. Testing harness: An automated testing environment used to review code for errors, standards violations, and other design flaws.

393. Unit testing: The process of testing each module alone in an attempt to discover any errors in its code.

394. User documentation: Written or other visual information about an application system, how it works, and how to use it.

Answers to Review Questions 1.372.

12.1. The deliverables: (1) from coding, code and program documentation; (2) from testing, test scenarios and test data, and the results of program and system testing; (3) from installation, user guides, user training plans, and installation and conversion plans.

1.373.

12.2. The testing process involves testing code for errors and functionality. The testing process, guided by a detailed testing plan, can begin as soon as modules are coded and proceeds in parallel with the rest of the coding process. Modules are tested individually and then as parts of larger programs and parts of larger systems.

1.374.

12.3. Structured walkthroughs for code are organized, but informal, reviews of code, led by a project manager or chief programmer, where the code‘s author presents what has been written to a panel of reviewers. Their purpose is to find errors. Walk-throughs are 117 Copyright © 2025 Pearson Education, Inc.

different from code inspections in that walk-throughs focus on logic whereas inspections focus on finding well-known errors peculiar to the programming language in which the code was written.

1.375.

12.4. The four approaches to installation are: (1) direct, (2) parallel, (3) single location, and (4) phased. With the direct approach, the old system is turned off, and the new one is turned on. In the parallel approach, both systems are run until management decides the old system can be turned off. In single location, the system is tried out in a pilot project at one location and then implemented elsewhere if the pilot is successful. With the phased approach, the new system is brought online gradually, usually function by function.

Parallel is usually the most expensive due to the redundant costs, and direct is usually the riskiest due to the potential hazards if the new system fails. An organization decides on which approach to use depending on the scope and complexity of the change and the organization‘s risk aversion.

1.376.

12.5. Conventional wisdom is that implementation success depends on user participation and managerial support. Without understanding your stakeholder‘s needs designers are left with many questions that are difficult to answer.

1.377.

12.6. Several factors are important to the successful implementation of a system, including: (1) management support, (2) the involvement of users, and (3) user expectations.

Additionally, commitment to the project, commitment to change, and extent of project definition and planning are important. Commitment to the project refers to managing the project so that the problem being solved is well understood and the target system solves the problem. Commitment to change means being willing to change behaviors and procedures. Project definition and planning means more extensive planning is more effective than less extensive. Lucas (1997) identified two methods for determining if implementation has been successful: the user‘s satisfaction with the system and the extent to which the system is used. Factors influencing the extent to which the system is used include user‘s personal stake, system characteristics, user demographics, organization support, performance, and satisfaction.

1.378.

12.7. As mentioned in the previous question, Lucas identified two methods for determining if an implementation has been successful: the user‘s satisfaction with the system and the extent to which the system is used. Lucas further identified six factors that influence the extent to which a system is used; these are user‘s personal stake, system characteristics, user demographics, organization support, performance, and satisfaction.

Figure 12-8 illustrates the relationships these factors have to each other. An analyst will have more control over certain factors (system characteristics and level of support); however, the analyst will not have direct control over the demographics of the user, personal stake in the system, management support, or problem urgency. This model points out that the analyst should balance the factors that cannot be changed with those factors that can be changed.

1.379.

12.8. System documentation is the detailed information about a system‘s design specifications, its internal workings, and its functionality, whereas user documentation consists of written or other visual information about an application system, how it works, and how to use it.

1.380.

12.9. The most common delivery method for corporate training remains traditional instructor-led classroom training. Many times, users turn to the resident expert and to fellow users for training. Corporations also rely heavily on e-learning as a key delivery 118 Copyright © 2025 Pearson Education, Inc.

mode for training. E-learning generally means the same thing as distance learning; that is, a formalized learning system designed to be carried out remotely, using computer-based electronic communication.

119 Copyright © 2025 Pearson Education, Inc.

1.381.

12.10. Self-training is just what it sounds like, computer users train themselves in how to use computing for their needs.

1.382.

12.11. E-learning is training that takes place at ones‘ own pace using computer tools, such as Blackboard, Moodle or others to simulate a classroom experience while keeping costs reasonable. This is the fastest growing segment of the training market, and the course material may be prepared internally or purchased and then administered and delivered over the Web or through a company‘s internal portal or intranet.

1.383.

12.12. Several studies, cited in the text, stress the importance of tailoring end user training to the user‘s specific needs, thus necessitating the usage of different training modes.

1.384.

12.13. The increasing reliance on vendor support as corporations move to client/server architectures is due in part to the lack of standards governing client/server products and the resulting need to make equipment and software from different vendors compatible.

1.385.

12.14. Vendors provide support through the following mechanisms: automated support, such as online support forums; bulletin board systems; on-demand fax; voice-response systems; providing help desk support; and technical support 800 telephone units, all or some of which are either external or internal to the user organization.

1.386.

12.15. The help desk serves as a single point of contact for all user inquiries and problems about an information system or for all users in a particular department. The help desk staff requires both technical and people skills. At their largest, help desks may employ five levels of professionals: (1) the first level help desk employee takes calls, screens them, and routes them to the appropriate location; (2) at the next level are the people who deal with most of the problems users have; (3) if the problems are too difficult, they are passed on to the third level of help desk employee, specialists who can solve almost any problem the organization‘s users may have; (4) the fourth level is occupied by supervisors, who have the day-to-day oversight responsibilities for those who work directly with users; and (5) the final level of employee is the help desk manager.

12.16. Table 12-8 lists the common threats to IT systems. There are numerous ways that these threats can be minimized or eliminated including: software and hardware to detect and deflect intruding software or unauthorized system access, password security and modification including strong passwords that are difficult to duplicate, and internal procedures and practices designed to train and help eliminate personnel related issues.

1.387.

1.388.

12.17. a. Adaptive maintenance refers to the changes made to a system to evolve its functionality to changing business needs or technologies. Corrective maintenance refers to changes made to a system to repair flaws in its design, coding, or implementation. Perfective maintenance refers to changes made to a system to add new features or to improve performance. Preventive maintenance refers to changes made to a system to avoid possible future problems. b. Baseline modules are software modules that have been tested, documented, and approved to be included in the most recently created version of a system. Build routines are the guidelines that list the instructions to construct an executable system from the baseline source code. The system librarian is the person responsible for controlling the checking-out and checking-in of baseline modules for a system when a system is being developed or maintained.

120 Copyright © 2025 Pearson Education, Inc.

c. Maintenance refers to the changes made to a system to fix or enhance its functionality.

Maintainability refers to the ease with which software can be understood, corrected, adapted, and enhanced.

1.389.

12.18. Four major activities occur within maintenance: (1) obtaining maintenance requests, (2) transforming requests into changes, (3) designing changes, and (4) implementing changes. The first phase of the SDLC, project identification and selection, is analogous to the maintenance process of obtaining a maintenance request. The SDLC phases of project initiation and planning and analysis are analogous to the maintenance process of transforming requests into a specific system change. The design phase of the SDLC equates to the designing changes process. Finally, the SDLC phase implementation equates to implementing changes. This similarity between the maintenance process and the SDLC is no accident. The concepts and techniques used to initially develop a system are also used to maintain it.

1.390.

12.19. Table 12-10 summarizes the different types of maintenance. Corrective maintenance repairs flaws in a system‘s design, coding, or implementation. Adaptive maintenance evolves a system‘s functionality to changing business needs or technologies.

Perfective maintenance adds new features or improves system performance. Preventive maintenance makes changes to a system to avoid possible future problems.

1.391.

12.20. Several factors influence maintenance costs. Three of these are very important: (1) defects, (2) customers, and (3) documentation quality. The number of latent defects refers to the number of unknown errors existing in the system after it is installed. Because corrective maintenance accounts for most maintenance activity, the number of latent defects in a system influences most of the costs associated with maintaining a system. If there are no errors in the system after it is installed, then maintenance costs will be relatively low. If there are a large number of defects in the system when it is installed, maintenance costs will likely be high. A second factor influencing maintenance costs is the number of customers for a given system. In general, the greater the number of customers, the greater the maintenance costs. A third major contributing factor to maintenance costs is the quality of system documentation. Without quality documentation, maintenance efforts can increase exponentially.

1.392.

12.21. The three ways of organizing maintenance personnel are: (1) separate, (2) combined, and 3) functional. The advantages and disadvantages of each approach are summarized in Table 12-11.

1.393.

12.22. To measure effectiveness, you must measure: (1) the number of failures, (2) the time between each failure, and (3) the type of failure. Measuring the number and time between failures provides you with the basis to calculate a widely used measure of system quality. This metric is referred to as the mean time between failures (MTBF). As its name implies, the MTBF measure shows the average length of time between the identification of one system failure to the next. Over time, you should expect the MTBF value to rapidly increase after a few months of use (and corrective maintenance) of the system. If the MTBF does not rapidly increase over time, it is a signal to management that major problems exist within the system and that these problems are not being adequately resolved through the maintenance process.

1.394.

12.23. Measuring maintenance effectiveness provides important management information for future projects. For example, if a higher frequency of errors occurs when a particular development environment is used, such information can help guide personnel assignments, training courses, or the avoidance of a particular package, language, or 121 Copyright © 2025 Pearson Education, Inc.

environment during future development.

1.395.

12.24. The book presents a flowchart in Figure 12-16 that suggests one possible method for dealing with maintenance change requests. The flowchart suggests that you must determine the type of request. If, for example, the request is an error, that is, a corrective maintenance request, then the flowchart shows that a question must be asked related to the error‘s severity. If the error is ―very‖ severe, then the request has top priority and is placed at the top of a queue of tasks waiting to be performed on the system. If, however, the error is considered not very severe, then the change request can be categorized and prioritized based upon its type and relative importance. If the change request does not concern an error, then you must determine if the request is to adapt the system to technology changes and/or business requirements or to enhance the system so it will provide new business functionality. For adaptation requests, they too will need to be evaluated, categorized, prioritized, and placed in the queue. For enhancement type requests, they must first be evaluated to see if they are aligned with future business and information systems plans. If not, the request will be rejected and the requester will be informed. If the enhancement appears to be aligned with business and information systems plans, it can then be prioritized and placed into the queue of future tasks.

1.396.

The method for reviewing maintenance requests strongly suggests that all requests should not be handled in the same way. The process also suggests what should be done with different types of requests. In situations where there is a catastrophic failure of the system, time may be of the essence, and a formal review of a request will take too long. In such a situation, the formal evaluation process can be circumvented.

1.397.

12.25. Configuration management is the process of assuring that only authorized changes are made to a system. A system librarian controls the baseline source code modules. If maintenance personnel are assigned to make changes to a system, they must first check out a copy of the baseline system modules because no one can directly modify the baseline modules. This ensures that only those modules that have been checked out and then formally checked in can reside in the library. Organizations have adopted this approach so that before any code can be checked back in to the librarian, it must pass the quality control procedures, testing, and documentation standards established by the organization.

Answers to Problems and Exercises 1.398.

12.26. PVF‘s Purchasing Fulfillment System involves the following processes: (1) get supplier data, (2) get material data, (3) generate supplier description, (4) generate purchased goods, (5) specifications, and (6) place materials orders, as well as other processes. Your students should describe whether they would employ stub testing, integration testing, system testing, or some combination of these testing methods.

Students should also defend their choices. In creating the testing plan, your students should also think through the potential problem areas, list these areas, and develop ways to test for problems. Students should come up with a list of test cases, each of which may contain several individual tests, and then group these test cases into test cycles (see Figures 12-3 and 12-4).

1.399.

12.27. PVF‘s Purchasing Department plays a central role in the operations of this manufacturing firm. Given the current concerns for delays in placing vendor orders and the growing use of just-in-time inventory control methods, PVF needs a relatively smooth, quick, and safe installation method. Thus, a parallel or phased conversion makes the most sense. The feasibility of a phased approach depends on how easy it is to unplug 122 Copyright © 2025 Pearson Education, Inc.

current modules and plug in new modules. A combination of parallel and phased is the most viable. A direct conversion is too risky, and single-location conversion is not applicable for this one location situation. The inventory management system is equally important to the operations of Hoosier Burger, although this system is relatively smaller and simpler than the Purchasing Fulfillment System at PVF. Thus, in addition to the parallel or phased conversion, a direct conversion is feasible for Hoosier Burger, if the risk is deemed tolerable. The single-location conversion also is not applicable for Hoosier Burger.

1.400.

12.28. Students should first refer to the chapter‘s discussion of the four conversion methods. Students should pull from the discussion the essential characteristics of each of these methods and then derive a list of criteria to use to compare the four methods. Your students can use criteria such as risk, speed, cost, simplicity, time until installation begins, and benefits of the new system are achieved, ability to identify and correct errors, confusion for users, and scope of problems with the new system. Next, your students should create a table with the four conversion methods on one axis and the criteria on the other axis. Your students should then fill in the boxes of the matrix with short descriptions for each method on each criterion; most comments can be taken from the text.

1.401.

12.29. There are many factors to consider when choosing a pilot site (or several) for a single-location conversion. You can choose a site that provides for a relatively simple, manageable pilot conversion, thereby increasing the chances of having a successful installation. Such a site might have a small number of users, might be relatively convenient for systems staff, and is willing to be an early adopter. On the other hand, you can choose a larger, more complex site for the pilot, to better test the quality of the system and/or to better prove to people that the system was well developed.

Alternatively, you can choose a relatively high-profile site, to increase the visibility of the new system. On the other hand, you can choose a relatively low-profile site, so that the installation is not ―under the microscope‖ of everyone in the organization. If possible, you can pick several sites that satisfy several criteria to get a representative mix. How the site is chosen and what factors are used is different for every situation. It all depends on what you want to accomplish with the installation.

1.402.

12.30. It is important that, on whatever system your students choose to focus their answer, they present a logical set of criteria to use to judge whether their system is ready for general distribution. For example, if a student chooses a word processor, the student should present a convincing set of arguments for judging whether this single-user, shrinkwrapped software package is ready for mass distribution. For this type of system, massive beta testing should be conducted over a long period of time and with a great variety of users. Great care should be taken to ensure that this word processor at least matches and, preferably, goes beyond the capabilities of its competing word processing packages.

Valid, reliable measures of usability should be established. The package should be reliable and nondestructive of data even when it fails. Security is an issue for some users.

Ultimately, extensive acceptance testing within the target market of users should be conducted. Testing should cover the software and its printed documentation, online help, and technical support.

12.31. It is important to keep a history of test cases and results for several reasons. First, it is a good idea for the systems personnel to keep a clear record of what testing was done so that, if problems with the system occur later, the systems personnel can show that they did, in fact, conduct tests. Second, if problems do occur even after a series of tests, the track record of testing helps the systems personnel rule out pieces of the system that were

1.403.

123 Copyright © 2025 Pearson Education, Inc.

tested as potential sources of these new system problems. Third, particularly for a situation where there have been several revisions of a system, there may be a need to retrace the steps of the system development back through the test history to diagnose problems or, worse, to make a decision to revert back to a former version of the system.

Fourth, the history of test cases provides at least a baseline of test cases for future versions and results from prior tests to which results from current tests can be compared when possible.

1.404.

12.32. Students will express different views in their answers to this question. For example, they may argue that documentation should be as brief, graphical, to-the-point as possible, and available when needed but no sooner. Also, the importance of documentation is not necessarily how much documentation has been prepared; rather, it is important that the documentation is truly helpful for users. Documentation should be complete, easy to read, and easy to understand. Documentation should describe what the system can do and how to use the system for work.

1.405.

12.33. The arguments for centralizing training and support in an organization are similar to those used for centralizing other organizational functions (marketing, purchasing, accounting, etc.). By centralizing such functions, organizations can potentially save money and other important resources and perhaps better control these functions. For example, a centralized training and support facility can save money that is spent on duplicating facilities and hiring redundant trainers for each separate facility throughout the organization. Career paths for trainers should be easier to manage if the function is centralized. For a centralized facility to justify its existence, it should continue to meet the diverse needs of each of its many constituents. The facility should be flexible and able to change along with the different types of training needed. In addition, some creative scheduling should be done to meet the incredible demand for this sole facility. The facility should be customer focused and actively work with end users to identify training needs and develop appropriate training programs. In addition, the facility should adapt previously developed training programs to the needs of different user communities.

12.34. Your students are likely to suggest various training programs for the users of Hoosier Burger‘s inventory control system. What they propose to do is not as important as the soundness of the arguments they use to support their proposed methods. Given that the organization and user base are relatively small, one sound strategy is to offer a short course for the few people who will use the system. This course can be offered by someone from within the organization or outsourced to an external vendor. In addition, some software help components should be built into the system with the help of the users.

A crucial element of the training program is how to handle employee turnover, to the extent that people other than Bob and Thelma will use the system. Possibly a video or online tutorial, to be used as part of the overall orientation program for new employees, is a good approach.

1.406.

1.407.

12.35. As with the previous question, students are likely to come up with a variety of ideas for the support systems for the users of Hoosier Burger‘s inventory control system.

Again, what they propose to do is not as important as the soundness of the arguments they use to support their proposed methods. Given that the organization and user base are relatively small, one sound strategy is to develop a relatively simple help desk. In addition to answering basic on-demand questions and providing a demonstration site for the system, help desk staff can help users write their own programs in fourth-generation languages and extract data from the system to use for analysis on their personal computers. The help desk would support all Hoosier Burger systems. It is likely that the personnel of the help desk, given Hoosier Burger‘s size, would also be analysts and 124 Copyright © 2025 Pearson Education, Inc.

programmers working on new system development and maintenance.

1.408.

12.36. Students are likely to find a help desk at their university or school. Alternatively, they are likely to find an organization with a help desk in the local or nearby community.

Help desks are common for medium to large organizations of all types. Your students are likely to find that these help desks perform many of the same functions described in the chapter. Students may find organizations that perform the following additional functions: consulting users on their own applications development, consulting users on their own purchase of hardware and software, evaluating new versions of software and sharing this information with users, and helping users ensure that their applications are compatible with other applications being developed by other users. A help desk might also be the point of contact to initiate repair orders for computers and network hardware. As end-user development becomes more prevalent, help desks are becoming more service- and consultation-oriented.

1.409.

12.37. Students should describe systems documentation, including internal and external documentation, and user documentation for the new inventory control system at Hoosier Burger. For the system documentation, students can get hints from Table 12-5, which shows generic documentation corresponding to each phase in the SDLC. For user documentation, students can refer to Table 12-6, which outlines a generic user‘s guide.

12.38. This exercise should be done with great care as many organizations, and a university would be no different, are very defensive about their security practices and more specifically any breaches. The best way to approach this question might be to have students outline the procedures and practices that they are aware of in their dealings with the campus systems, such as password driven wireless access, network authentication and other procedures that are in place. If a group could be very mindful of tactful interviewing techniques, they might interview the Chief Information Officer for the university or another high-ranking IS manager about these issues.

1.410.

1.411.

12.39. For a variety of reasons, it makes sense to talk about maintenance as both the final stage of the SDLC and as a process similar to the SDLC. On the one hand, maintenance is typically conducted as the final, albeit ongoing, step in a properly conducted SDLC. On the other hand, a properly conducted maintenance stage is like a microcosm of the SDLC process, complete with its own form of project identification and selection, project initiation and planning, analysis, design, and implementation.

Maintenance is simultaneously the end of the broader SDLC and a mini-SDLC of its own. It is possible, natural, and useful for the maintenance stage to exist in this dual form, so there is no inherent conflict in describing maintenance in this way.

1.412.

12.40. For the most part, a request to change an information system is handled much like a request for a new information system. For example, for a new system request, the systems personnel must estimate the duration and scope of the project and assess its risk and feasibility. However, a change request is handled somewhat differently. For instance, the systems personnel must determine how the requested change will affect the current system. Also, change requests are often batched together into a maintenance project to gain some economies of scale and to minimize the frequency of change for users. Thus, change requests interact with one another, and may be modified to meet conflicting and complementary needs of different requests. One could argue that for a new information system the parallel would be that systems personnel must determine how the new information system will affect and interact with other current information systems and business processes.

1.413.

12.41. To reduce corrective maintenance the answer is clear: do a better job in 125 Copyright © 2025 Pearson Education, Inc.

analyzing, designing, coding, and implementing (including testing) new information systems. There is no better way to reduce the number of repairs to an information system than to do an effective, thorough job in the development process. Usually the most expensive errors to correct are those that fix incorrect requirements, so doing a thorough job in analysis (both requirements determination and structuring) not only reduces the need for corrective maintenance, but also provides the extensive documentation that can reduce maintenance time. Also, building systems using common tools and languages makes it easier for a variety of highly trained maintenance personnel to quickly do their jobs. However, there are some problems requiring corrective maintenance that cannot be avoided or even foreseen. For example, some components purchased and installed from a third party as part of a new information system may later be found to be defective. A ―Murphy‘s Law‖ approach would be to do as good a job as possible in designing, coding, and implementing the system, and then be prepared for when the inevitable problems occur.

1.414.

1.415.

1.416.

12.42. The intent of the system service request (SSR) is to briefly state the business problem or opportunity, along with general ideas of how to address the problem or opportunity. Pine Valley‘s SSR does provide this information. However, the SSR could be modified to indicate the type of request (maintenance or new system development) being requested. Students will provide additional recommendations.

12.43. To manage defects, the first cost element of maintenance, the analyst can better design, code, and implement the system to try to avoid these defects. The analyst can then try to prepare for defects, some of which are inevitable. Analysts cannot manage the customer cost element, but they can lobby for more money or new hires if their customer base grows too large for them to handle effectively. The only element of control an analyst has on customer cost occurs during project scoping, at which time an analyst can argue for decomposition of a project into smaller projects, each with fewer customers.

For the documentation cost element, analysts can work hard with users to develop highquality documentation that passes strict testing. For the personnel cost element, analysts might not have much control. However, if analysts are involved directly in maintenance tasks, they can work hard and efficiently so that money is not squandered on maintenance personnel costs. In terms of tools, analysts can participate in a rigorous cost benefit analysis for proposed new tools and ensure that only the necessary tools are purchased for maintenance tasks. In terms of software structure, analysts can work hard to ensure that software is designed so that it can be more easily maintained. For example, they can help to develop good system documentation that is likely to be needed for subsequent system maintenance.

12.44. It is not important which form of E-R diagramming notation your students choose; it is more important that your students list the relevant types of information required for a system librarian to perform her job well. The entities that the system librarian is concerned with include the system, baseline modules, and system personnel.

Each system comprises modules, which have version information, maintenance status, quality standard status, check in/out status, and build routines. Many entities have effective dates, indicating when that object was active; alternatively, date ranges can be used for a broader set of status indicators for objects, such as planned, designed, coded, tested, released to developers, and released to customers. The data model would also show usage activity, so the workload on the librarian can be tracked. Another goal of the data model is to show module reuse, much as a bill-of-materials data model shows product component reuse. Security and controlling access to entities is an issue, so systems personnel need maintenance authority levels for each of the systems and 126 Copyright © 2025 Pearson Education, Inc.

modules.

1.417.

12.45. Product design engineers manage the configuration of their products in much the same way as described in this chapter. They use the equivalent of baseline modules, build routines, and system librarians to manage changes in their products. In addition, they use logbooks, extensive note taking, and automated tools, such as project management software, to manage these changes. In fact, some have argued that the information systems field has attempted (and rightly so) to become more like the engineering field in its rigor, discipline, and consistency, hence the term ―software engineering.‖

1.418.

12.46. An interesting way to approach this question is to ask your students to investigate the maintenance services provided by various Web hosting services. The ISP‘s responsibilities will vary depending on what it has been contracted to do. However, Web site maintenance

issues address those presented in the textbook: operating 24 hours a day, how maintenance is actually performed, making sure that links are up-to-date, validating HTML, re-registration, and notifying visitors of future editions.

Guidelines for Using the Field Exercises 1.419.

12.47. Given the high degree of change in organizations today, students should easily find an organizational change of one kind or another. For example, many organizations are downsizing, merging, implementing new systems, or undergoing business process reengineering. One of the practical issues in managing and assessing the impact of change is that it is difficult to isolate the effects of individual changes, since organizations are typically undergoing many simultaneous changes. Thus, the models in the chapter may be too simplistic to account for the confluence of change in organizations.

1.420.

12.48. All information systems projects involve people to some degree. Thus, whether we like it, and whether or not we choose to admit it and deal with it, all systems projects are inherently political. The political perspective is a useful way of analyzing information systems projects and organizational changes of all kinds. Ultimately, information systems are developed by, with, through, and for people. Understanding the motivations of people throughout the process is incredibly useful.

1.421.

12.49. Students should compare their answers to this question. This way they can learn about the perceptions of a variety of systems professionals. Students should keep in mind, however, that the perceptions of a handful of professionals in the field are not necessarily generalizable to all system implementations. These bits of anecdotal evidence should be integrated with research on systems implementation in order to gain a more complete, accurate, generalizable understanding of system implementation.

12.50. The same holds for this answer as did for the previous answer. Although this method of data gathering provides stronger evidence than that required for the previous question, students should be reminded that they should not generalize their conclusions to all system implementations. In any event, finding what has happened on real system projects from people who were directly involved in these projects provides valuable information to students. Alternatively, trade publications publish case studies (or brief descriptions) from which students might extract some key factors of information system implementation success. Extensive literature on adoption and diffusion of technology is available, which is relevant to information system implementation.

1.422.

127 Copyright © 2025 Pearson Education, Inc.

1.423.

12.51. If students find people who use best-selling packaged software, and if these people have the user documentation that came with this software available, then students are likely to find that this documentation is relatively good and conforms to the guidelines discussed in this chapter. If these users are using other types of software (e.g., internally developed application systems), then students are likely to find a variety of documentation quality. In some cases, no documentation may exist.

1.424.

For internally developed systems, your students should inquire about how the documentation is tested and updated as the software evolves. One advantage of packaged software is that given the large number of users, vendors can invest (and need to invest for marketing purposes) in high-quality documentation. Individual organizations, under pressure to reduce the systems development backlog, often compromise on the scope and quality of user documentation.

1.425.

12.52. At a typical help desk at a university (or monitor in a student computing lab), students are likely to encounter users who are students, faculty, staff, administrators, and even people from the community. Users ask a variety of questions, including:

1.426.

―What are the hours of the computer lab?‖

1.427.

―How do I customize a header in my word processor?‖

1.428.

1.429.

―Can you help me develop an e-mail distribution list for my class?‖ ―How do I download files from the Internet?‖

1.430.

―Can someone come over and help us with the new student records database?‖

1.431.

―How much does a new laser printer cost?‖

1.432.

People might think that this kind of work is relatively easy, but it is not. Solving problems and dealing with people all day long is challenging, sometimes intense work.

The diversity of questions is great, and customers are almost always in a hurry with an immediate need for answers. This type of work requires special communication and problem-solving skills and love for this kind of work.

1.433.

12.53. Students will find that Table 12-6 and the related discussion provide a useful basis for constructing a user‘s guide. Students‘ guides should describe the task completely, in addition to any error messages that the user may see if a problem arises.

Given that no word processing package or e-mail system was specified, it is not important that students describe each step in detail. Students should at least present an outline of their user task guide. Alternatively, if students know of a way to perform this task using a specific word processor and e-mail system, they should describe how it is done.

1.434.

12.54. Students are likely to find that their organization of choice is using the classical maintenance organizational structure; that is, the maintenance group is separate from the development group. However, many organizations are trying other structures for organizing this function (especially those that locate development and maintenance staff closer to users), so students may find other forms being used. Students should find that the managers cite advantages to their particular maintenance organizational structure that are similar to those discussed in the chapter and listed in Table 12-11. Have your students compare their answers. If there are differences, have your students discuss why these different structures are being used in these different organizational settings. Similarly, if different reasons for using the same structure are cited across different organizations, have your students explore why different reasons were given.

12.55. Students are likely to find that systems personnel are using methods similar to

1.435.

128 Copyright © 2025 Pearson Education, Inc.

those described in the chapter. Calculating the mean time between failure and other analyses of systems failures are common ways to measure maintenance effectiveness. In addition, some organizations are measuring their users‘ satisfaction with maintenance and their perceptions of effectiveness in order to supplement other measures of maintenance effectiveness. If students have obtained quantitative or qualitative historical data about maintenance effectiveness, they will probably find that as organizations are becoming more service-oriented, as training in and subsequent use of the SDLC improves, and as technology gets better and easier to use, maintenance effectiveness should have improved over the past few years.

1.436.

12.56. If the organization or systems staff is relatively large, the chances are greater of finding someone with the explicit job title of systems librarian. Otherwise, your students are more likely to find someone with a different job title fulfilling the role of systems librarian. Students are likely to find that these individuals use a database application, project management application, or CASE tool to perform their systems library tasks.

These individuals come from a variety of backgrounds. They have backgrounds in maintenance, programming, analysis, and help desk functions. This type of job is commonly given to a new MIS undergraduate who has limited experience and technical training. He might spend a short time in this position to ―learn the ropes‖ before moving on to another position. Have your students compare their answers so that they can see the variety of ways that organizations handle this position and the variety of people that hold it.

129 Copyright © 2025 Pearson Education, Inc.