Systems Analysis and Design by Alan Dennis, Barbara Haley Wixom, Roberta M. Roth PDF

DENNIS WIXOM ROTH S YS T EM S A N A LY S IS & D ES I G N 6 TH E D I T I O N  Visible Analyst Student Edition Educating tomorrow’s developers today Visible Analyst is a “hands-on” tool for teaching students all aspect...

DENNIS WIXOM ROTH S YS T EM S A N A LY S IS & D ES I G N 6 TH E D I T I O N  Visible Analyst Student Edition Educating tomorrow’s developers today Visible Analyst is a “hands-on” tool for teaching students all aspects of analysis and design including dynamic rules, consistency checking, managing change, and understanding the integration issues across an IT project. Visible Analyst prepares students to enter the IT world as business or data architects, analysts, designers, and modelers. Visit us at www.visible.com to learn more. YOU CAN Start Today with the Visible Analyst! Only takes 2 minutes to install! Save… 33% discount! Please visit http://store.visible.com/Wiley.aspx to purchase and register with your information (see below) and obtain a valid license for your student edition of the software. To purchase the discounted software you will need to enter the following code: 978112014 Email support is provided to all registered students at [email protected]. Your registration includes the latest release of the Visible Analyst Student Edition (software) the Visible Analyst eTutorial a preloaded Sample Instructional Project access to Webcast “How to” and “Get Started” Instructional Videos. Disclaimer: The publisher of the textbook does not sponsor, review, or make decisions about Visible Analyst software, and will not be responsible for, or involved in, any changes to the software. SYSTEMS ANALYSIS AND DESIGN Sixth Edition Alan Dennis Indiana University Barbara Haley Wixom Massachusetts Institute of Technology Roberta M. Roth University of Northern Iowa VP & EXECUTIVE PUBLISHER Don Fowley EXECUTIVE EDITOR Beth Lang Golub CONTENT EDITOR Mary O’Sullivan ASSOCIATE EDITOR Ellen Keohane MARKETING MANAGER Christopher Ruel OPERATIONS MANAGER Yana Mermel ASSOCIATE PRODUCTION MANAGER Joyce Poh DESIGNER Wendy Lai This book was set by Aptara. Founded in 1807, John Wiley & Sons, Inc. has been a valued source of knowledge and understanding for more than 200 years, helping people around the world meet their needs and fulfill their aspirations. Our company is built on a foundation of principles that include responsibility to the communities we serve and where we live and work. In 2008, we launched a Corporate Citizenship Initiative, a global effort to address the environmental, social, economic, and ethical challenges we face in our business. Among the issues we are addressing are carbon impact, paper specifications and procurement, ethical conduct within our business and among our vendors, and community and charitable support. For more information, please visit our website: www.wiley.com/go/citizenship. Copyright © 2015, 2012, 2009 John Wiley & Sons, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc. 222 Rosewood Drive, Danvers, MA 01923, website www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030- 5774, (201)748-6011, fax (201)748-6008, website http://www.wiley.com/go/permissions. Evaluation copies are provided to qualified academics and professionals for review purposes only, for use in their courses during the next academic year. These copies are licensed and may not be sold or transferred to a third party. Upon completion of the review period, please return the evaluation copy to Wiley. Return instructions and a free of charge return mailing label are available at www.wiley.com/go/returnlabel. If you have chosen to adopt this textbook for use in your course, please accept this book as your complimentary desk copy. Outside of the United States, please contact your local sales representative. Library of Congress Cataloging-in-Publication Data Dennis, Alan. Systems analysis and design / Alan Dennis, Barbara Haley Wixom, Roberta M. Roth.—Sixth edition. pages cm Includes bibliographical references and index. ISBN 978-1-118-89784-3 (paperback) 1. System design. 2. System analysis. 3. Computer architecture. I. Wixom, Barbara Haley, 1969– II. Roth, Roberta M. (Roberta Marie), 1955– III. Wixom, Barbara Haley. IV. Roth, Roberta M. V. Title. QA76.9.S88D464 2014 004.2ʹ2—dc23 2014034532 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1  To Kelly To Chris, Haley, and Hannah To Rich and the boys, always. PREFACE PURPOSE OF THIS BOOK Slearnystems Analysis and Design (SAD) is an exciting, active field in which analysts continually new techniques and approaches to develop systems more effectively and efficiently. How- ever, there is a core set of skills that all analysts need to know no matter what approach or methodology is used. All information systems projects move through the four phases of plan- ning, analysis, design, and implementation; all projects require analysts to gather require- ments, model the business needs, and create blueprints for how the system should be built; and all projects require an understanding of organizational behavior concepts like change manage- ment and team building. This book captures the dynamic aspects of the field by keeping students focused on doing SAD while presenting the core set of skills that we feel every systems analyst needs to know today and in the future. This book builds on our professional experience as systems analysts and on our experience in teaching SAD in the classroom. This book will be of particular interest to instructors who have students do a major pro- ject as part of their course. Each chapter describes one part of the process, provides clear explanations on how to do it, gives a detailed example, and then has exercises for the students to practice. In this way, students can leave the course with experience that will form a rich foundation for further work as a systems analyst. OUTSTANDING FEATURES A Focus on Doing SAD The goal of this book is to enable students to do SAD—not just read about it, but understand the issues so that they can actually analyze and design systems. The book introduces each major technique, explains what it is, explains how to do it, presents an example, and provides opportunities for students to practice before they do it in a real-world project. After reading each chapter, the student will be able to perform that step in the system development life cycle (SDLC) process. Rich Examples of Success and Failure The book includes a running case about a fictitious company called Tune Source. Each chapter shows how the concepts are applied in situations at Tune Source. Unlike running cases in other books, this text focuses examples on planning, managing, and executing the activities described vi Preface in the chapter, rather than on detailed dialogue between fictitious actors. In this way, the run- ning case serves as a template that students can apply to their own work. Each chapter also includes numerous Concepts in Action boxes that describe how real companies succeeded— and failed—in performing the activities in the chapter. Many of these examples are drawn from our own experiences as systems analysts. Incorporation of Object-Oriented Concepts and Techniques The field is moving toward object-oriented concepts and techniques, both through UML 2.0, the new standard for object-oriented analysis and design, as well as by gradually incorporating object-oriented concepts into traditional techniques. We have taken two approaches to incor- porating object-oriented analysis and design into the book. First, we have integrated several object-oriented concepts into our discussion of traditional techniques, although this may not be noticed by the students because few concepts are explicitly labeled as object-oriented con- cepts. For example, we include the development of use cases as the first step in process mode- ling (i.e., data flow diagramming) in Chapter 4, and the use (and reuse) of standard interface templates and use scenarios for interface design in Chapter 9. Second, and more obvious to students, we include a final chapter on the major elements of UML 2.0 that can be used as an introduction to object-oriented analysis and design. This chapter can be used at the end of a course—while students are busy working on projects—or can be introduced after or instead of Chapters 5 and 6. Real-World Focus The skills that students learn in a systems analysis and design course should mirror the work that they ultimately will do in real organizations. We have tried to make this book as “real” as possible by building extensively on our experience as professional systems analysts for organ- izations such as IBM, the U.S. Department of Defense, and the Australian Army. We have also worked with diverse industry advisory boards of IS professionals and consultants in develop- ing the book and have incorporated their stories, feedback, and advice throughout. Many students who use this book will eventually apply the skills on the job in a business environ- ment, and we believe that they will have a competitive edge by understanding what successful practitioners feel is relevant in the real world. Project Approach We have presented the topics in this book in the SDLC order in which an analyst encounters them in a typical project. Although the presentation necessarily is linear (because students have to learn concepts in the way in which they build on each other), we emphasize the itera- tive, complex nature of SAD as the book unfolds. The presentation of the material should align well with courses that encourage students to work on projects, because it presents topics as students need to apply them. Graphic Organization The underlying metaphor for the book is doing SAD through a project. We have tried to emphasize this graphically throughout the book so that students can better understand how the major elements in the SDLC are related to each other. First, at the start of every major phase of the system development life cycle, we present a graphic illustration showing the major deliverables that will be developed and added to the electronic “project binder” during that phase. Second, at the start of each chapter, we present a checklist of key tasks or activities that will be performed to produce the deliverables associated with this chapter. These graphic  Preface vii elements—the deliverables tied to each phase and the task checklist tied to each chapter—can help students better understand how the tasks, deliverables, and phases are related to and flow from one to another. Finally, we have highlighted important practical aspects throughout the book by mark- ing boxes and illustrations with a “push pin.” These topics are particularly important in the practical day-to-day life of systems analysts and are the kind of topics that junior analysts should pull out of the book and post on the bulletin board in their office to help them avoid costly mistakes. WHAT’S NEW IN THE SIXTH EDITION The sixth edition contains several significant enhancements, including new and updated con- tent, new Concepts in Action features, and updated exercises. The most significant content changes are: Expanded discussion of Agile methodologies, particularly Scrum, in chapter 2. Considerable reorganization of chapter 4 (Use Case Analysis) so as to clarify concepts and add more illustrations. New content on mobile application architectures in chapter 8. Extensive revision of chapter 9, User Interface Design, in order to streamline the presentation for added clarity. New content has been added to reflect some impor- tant current user interface concepts, including usability, user experience (UX), issues of designing for touch screen interfaces, and several additional user interface design tools, including site maps, wireframe diagrams, and wireflow diagrams. New content in the chapter 11, Database Design, on the newer NoSQL databases and the BigData concept. Throughout the book, the chapter objectives have been revised to reflect active learning objec- tives. Chapter references to outside sources have been updated to current resources wherever possible. New Concepts in Action features appear throughout the book to provide updated, real-world illustrations of the textbook content. For this edition, a series of tutorial lessons have been created that will teach students how to use and apply the Visible Analyst™ computer-assisted software engineering (CASE) software to a simple systems development project scenario. (Please see the Supplements section of this Preface for more information on purchasing Visible Analyst software at a reduced price for use in your course.) We know that most professors and students find the Systems Analysis and Design class to have a lot of demanding content, particularly in those classes that include a significant project. Many professors would like their students to be able to experience first-hand how useful a CASE tool is to a systems analyst, but find it difficult to include instruction on a CASE tool in an already full course. The goal of these lessons is to enable students to learn the basics of the Visible Analyst CASE software with little involvement on the part of the professor. The lesson material is found on the student web site for this textbook (at www.wiley.com/college/ dennis), with references to these lessons found in new Your-Turn boxes throughout the book. Professors have the flexibility to assign these tutorial lessons if they want to include the Visible Analyst software in their courses, but are also free to exclude this material if they prefer. The tutorial lessons have been written to provide students with a sufficient foundation to apply Visible Analyst to a more significant systems development project, should that be a part of their course. viii Preface ORGANIZATION OF THIS BOOK This book is organized by the phases of the systems development life cycle (SDLC). Each chapter has been written to teach students specific tasks that analysts need to accomplish over the course of a project, and the deliverables that will be produced from the tasks. As students complete the book, tasks will be “checked off ” and deliverables will be completed and stored in project folders. Part 1 covers the first phase of the SDLC, the Planning Phase. Chapter 1 introduces the SDLC, the roles and skills needed for a project team, project initiation, the systems request, and feasibility analysis. Chapter 2 discusses project selection, the selection of an SDLC methodol- ogy for the project, and project management, with emphasis on the work plan, staffing plan, project charter, risk assessment, and tools used to help manage and control the project. Part 2 presents techniques needed during the analysis phase. In Chapter 3, students are introduced to requirements determination and are taught a variety of analysis techniques to help with business process automation, business process improvement, and business process reengineering. Chapter 4 focuses on use cases, Chapter 5 covers process models, and Chapter 6 explains data models and normalization. The Design Phase is covered in Part 3 of the textbook. In Chapter 7, students create an alter- native matrix that compares custom, packaged, and outsourcing alternatives. Chapter 8 focuses on designing the system architecture, which includes the architecture design, hardware/software specification, and security plan. Chapter 9 focuses on the user interface and presents interface design; in this chapter, students learn how to create use scenarios, the interface structure diagram, interface standards, and interface prototypes. Finally, data storage design and program design are discussed in Chapters 10 and 11, which contain information regarding the data storage design, the program structure chart, and program specifications. The Implementation Phase is presented in Chapters 12 and 13. Chapter 12 focuses on system construction, and students learn how to build and test the system. It includes informa- tion about the test plan and user documentation. Conversion is covered in Chapter 13, where students learn about the conversion plan, the change management plan, the support plan, and the project assessment. Chapter 14 (online) provides a background of object orientation and explains several key object concepts supported by the standard set of object-modeling techniques used by systems analysts and developers. Then, we explain how to draw four of the most effective models in UML: the use case diagram, the sequence diagram, the class diagram, and the behavioral state machine diagram. SUPPLEMENTS www.wiley.com/college/dennis Online Instructors Manual The instructors manual provides resources to support the instructor both in and out of the classroom: Short experiential exercises can be used to help students experience and understand key topics in each chapter. Short stories have been provided by people working in both corporate and consulting environments for instructors to insert into lectures to make concepts more colorful and real. Additional mini-cases for every chapter allow students to perform some of the key concepts that were learned in the chapter. Answers to end-of-chapter questions and exercises are provided.  Preface ix Online Instructor’s Resources PowerPoint slides, prepared by author Roberta Roth, are provided that instructors can tailor to their classroom needs and that students can use to guide their reading and studying activities. Test Bank includes a variety of questions ranging from multiple choice to essay- style questions. A computerized version of the Test Bank is also available. Student Web Site Web Quizzes help students prepare for class tests. See www.wiley.com/college/dennis. Wiley E-Text: Powered by VitalSource This Wiley e-text offers students continuing access to materials for their course. Your students can access content on a mobile device, online from any Internet-connected computer, or by a computer via download. With dynamic features built into this e-text, students can search across content, highlight, and take notes that they can share with teachers and classmates. Readers will also have access to interactive images and embedded podcasts. Visible Analyst Wiley has partnered with Visible Analyst to give students a discounted price for Visible Ana- lyst software, an intuitive modeling tool for all aspects of traditional or object-oriented systems analysis and design. All new copies of the text will have a Key Code (printed on a page near the front of this text) that will provide a discount on Visible Analyst software. To obtain the software, students should visit http://store.visible.com/Wiley.aspx and enter their Key Code. Students who buy a new print text or digital e-book will receive one-third off the price of a downloadable edition of the software with a 6-month license. With the software, they will also receive tutorials, how-to videos, and a sample project. Students who buy used copies of this text may buy Visible Analyst at full price using the URL provided. Project Management Software You can download a 60-day trial of Microsoft Project Professional 2013 from the following Web site: http://technet.microsoft.com/en-us/evalcenter/hh973401. Note that Microsoft has changed its policy and no longer offers the 120-day trial previously available. Another option now available to education institutions adopting this Wiley title is a free introductory 3-year membership for DreamSpark Premium. DreamSpark Premium is designed to provide the easiest and most inexpensive way for academic departments to make the latest Microsoft software available in labs, classrooms, and on student and instructor PCs. Microsoft Project software is available through this Wiley and Microsoft publishing partnership, free of charge with the adoption of any qualified Wiley title. Each copy of Microsoft Project is the full version of the software, with no time limitation, and can be used indefinitely for educational purposes. Contact your Wiley sales representative for details. For more information about the DreamSpark Premium program, contact [email protected]. ACKNOWLEDGMENTS We extend our thanks to the many people who contributed to the preparation of this sixth and past editions. We are indebted to the staff at John Wiley & Sons for their support, including Beth Lang Golub, Executive Editor; Christopher Ruel, Marketing Manager; Joyce Poh, Associate Production Manager; and Wendy Lai, Senior Designer. x Preface We would like to thank the following reviewers of the sixth edition for their helpful and insightful comments: Name School Las Adams Bethune-Cookman University Jon W. Beard George Mason University Claudia Howery Delta College Glynn Johnson University of Houston Kay Lee University of Kansas Long Li Grambling State University Suzanne Nordhaus Lee College We would like to thank the many practitioners from private practice, public organizations, and consulting firms for helping us add a real-world component to this project. A special remem- brance goes to Matt Anderson from Accenture, who was a role model for all who knew him— who demonstrated excellence in systems analysis and design and in life in general. Thanks also to our families and friends for their patience and support along the way, especially to Christopher, Haley, and Hannah Wixom; Alec Dennis; and Richard Jones. Alan Dennis Barb Wixom [email protected] [email protected] Robby Roth [email protected]  CONTENTS Preface v Managing and Controlling the Project 61 Refining Estimates 61 PART ONE PLANNING PHASE 1 Managing Scope 63 CHAPTER 1 The Systems Analyst and Information Timeboxing 63 Systems Development 2 Managing Risk 64 Introduction 3 Applying the Concepts at Tune Source 65 The Systems Analyst 4 Staffing the Project 66 Systems Analyst Skills 4 Coordinating Project Activities 69 Systems Analyst Roles 5 Chapter Review 70 The Systems Development Life Cycle 6 Appendix 2A—The Function Point Approach 73 Planning 9 Appendix 2B—Project Management Tools: Analysis 9 The Gantt Chart and PERT Chart 78 Design 10 Gantt Chart 78 Implementation 10 PERT Chart 78 Project Identification and Initiation 11 System Request 13 PART TWO ANALYSIS PHASE 81 Applying the Concepts at Tune Source 15 CHAPTER 3 Requirements Determination 82 Feasibility Analysis 18 Introduction 82 Technical Feasibility 18 The Analysis Phase 83 Economic Feasibility 19 Requirements Determination 85 Organizational Feasibility 25 What Is a Requirement? 85 Applying the Concepts at Tune Source 28 The Process of Determining Chapter Review 30 Requirements 87 Appendix 1A—Detailed Economic The Requirements Definition Statement 89 Feasibility Analysis for Tune Source 33 Requirements Elicitation Techniques 90 CHAPTER 2 Project Selection Requirements Elicitation in Practice 91 and Management 35 Interviews 91 Introduction 36 Joint Application Development (JAD) 98 Project Selection 37 Questionnaires 102 Applying the Concepts at Tune Source 38 Document Analysis 104 Creating the Project Plan 39 Observation 105 Project Methodology Options 40 Selecting the Appropriate Techniques 107 Selecting the Appropriate Development Requirements Analysis Strategies 108 Methodology 47 Problem Analysis 108 Estimating the Project Time Frame 49 Root Cause Analysis 108 Developing the Work Plan 50 Duration Analysis 110 Staffing the Project 55 Activity-Based Costing 110 Staffing Plan 55 Informal Benchmarking 110 Coordinating Project Activities 58 Outcome Analysis 111 xii Contents Technology Analysis 111 Creating Data Flow Diagram Fragments 178 Activity Elimination 112 Creating the Level 0 Data Flow Diagram 178 Comparing Analysis Strategies 113 Creating Level 1 Data Flow Diagrams Applying the Concepts at Tune Source 113 (and Below) 178 Eliciting and Analyzing Requirements 113 Validating the Data Flow Diagrams 183 Requirements Definition 114 Chapter Review 184 System Proposal 114 CHAPTER 6 Data Modeling 187 Chapter Review 116 Introduction 187 CHAPTER 4 Use Case Analysis 120 The Entity Relationship Diagram 188 Introduction 120 Reading an Entity Relationship Diagram 188 What is a Use Case? 122 Elements of an Entity Relationship The Use Case Concept in a Nutshell 122 Diagram 189 Use Case Formats and Elements 123 The Data Dictionary and Metadata 193 Casual Use Case Format 123 Creating an Entity Relationship Diagram 196 Use Cases in Sequence 126 Building Entity Relationship Diagrams 196 Fully Dressed Use Case Format 126 Advanced Syntax 199 Applying Use Cases 128 Applying the Concepts at Tune Source 200 Use Case Practical Tips 129 Validating an Entity Relationship Diagram 203 Use Cases and Functional Requirements 129 Design Guidelines 203 Use Cases and Testing 129 Normalization 206 Creating Use Cases 130 Balancing Entity Relationship Diagrams with Data Flow Diagrams 206 Applying the Concepts at Tune Source 144 Chapter Review 208 Identifying the Major Use Cases 144 Appendix 6A: Normalizing the Data Model 211 Elaborating on the Use Cases 145 Chapter Review 149 PART THREE DESIGN PHASE 217 CHAPTER 5 Process Modeling 153 CHAPTER 7 Moving into Design 218 Introduction 153 Introduction 218 Data Flow Diagrams 154 Transition from Requirements to Design 219 Reading Data Flow Diagrams 154 System Acquisition Strategies 221 Elements of Data Flow Diagrams 156 Custom Development 223 Using Data Flow Diagrams to Define Packaged Software 224 Business Processes 158 Outsourcing 225 Process Descriptions 162 Influences on the Acquisition Strategy 228 Creating Data Flow Diagrams 162 Business Need 228 Creating the Context Diagram 164 In-House Experience 229 Creating Data Flow Diagram Fragments 165 Project Skills 229 Creating the Level 0 Data Flow Diagram 166 Project Management 230 Creating Level 1 Data Flow Diagrams Time Frame 230 (and Below) 166 Selecting an Acquisition Strategy 230 Validating the Data Flow Diagrams 173 Alternative Matrix 231 Applying the Concepts at Tune Source 177 Applying the Concepts at Tune Source 233 Creating the Context Diagram 177 Chapter Review 234  Contents xiii CHAPTER 8 Architecture Design 237 Input Design 292 Introduction 237 Basic Principles 292 Elements of an Architecture Design 238 Input Tips 294 Architectural Components 238 Input Validation 296 Client–Server Architectures 239 Output Design 296 Client–Server Tiers 240 Basic Principles 296 Server-Based Architecture 242 Types of Outputs 298 Mobile Application Architecture 243 Media 300 Advances in Architecture Configurations 244 Applying the Concepts at Tune Source 301 Comparing Architecture Options 245 Understand the Users 301 Creating an Architecture Design 246 Organize the Interface 301 Operational Requirements 246 Define Standards 303 Performance Requirements 247 Interface Template Design 303 Security Requirements 249 Develop Prototypes 305 Cultural and Political Requirements 254 Interface Evaluation/Testing 305 Designing the Architecture 256 Chapter Review 306 Hardware and Software Specification 258 CHAPTER 10 Program Design 311 Applying the Concepts at Tune Source 260 Creating an Architecture Design 260 Introduction 312 Hardware and Software Specification 261 Moving from Logical to Physical Process Models 312 Chapter Review 262 The Physical Data Flow Diagram 312 CHAPTER 9 User Interface Design 265 Applying the Concepts at Tune Source 315 Introduction 266 Designing Programs 316 The Usability Concept 266 Structure Chart 319 Principles for User Interface Design 267 Syntax 320 Layout 267 Building the Structure Chart 322 Content Awareness 269 Applying the Concepts at Tune Source 324 Aesthetics 270 Design Guidelines 328 Usage Level 270 Program Specification 335 Consistency 272 Syntax 335 Minimize User Effort 273 Applying the Concepts at Tune Source 339 Special Issues of Touch Screen Chapter Review 341 Interface Design 273 User Interface Design Process 274 CHAPTER 11 Data Storage Design 346 Understand the Users 275 Introduction 347 Organize the Interface 277 Data Storage Formats 347 Define Standards 279 Files 348 Interface Design Prototyping 280 Databases 350 Interface Evaluation/Testing 283 Selecting a Storage Format 354 Navigation Design 286 Applying the Concepts at Tune Source 356 Basic Principles 286 Moving from Logical to Physical Data Models 357 Menu Tips 287 The Physical Entity Relationship Diagram 357 Message Tips 289 Revisiting the CRUD Matrix 359 xiv Contents Applying the Concepts at Tune Source 360 CHAPTER 13 Transition to the New System 400 Optimizing Data Storage 362 Introduction 400 Optimizing Storage Efficiency 363 Making the Transition to the New System 401 Optimizing Access Speed 364 The Migration Plan 402 Estimating Storage Size 369 Selecting the Conversion Strategy 402 Applying the Concepts at Tune Source 371 Preparing a Business Contingency Plan 406 Chapter Review 373 Preparing the Technology 408 Preparing People for the New System 408 PART FOUR IMPLEMENTATION PHASE 377 Understanding Resistance to Change 409 CHAPTER 12 Moving into Implementation 378 Revising Management Policies 410 Introduction 378 Assessing Costs and Benefits 411 Managing the Programming Process 379 Motivating Adoption 412 Assigning Programming Tasks 379 Enabling Adoption: Training 415 Coordinating Activities 380 Postimplementation Activities 418 Managing the Schedule 381 System Support 418 Testing 381 System Maintenance 419 Test Planning 382 Project Assessment 421 Unit Tests 384 Applying the Concepts at Tune Source 423 Integration Tests 386 Implementation Process 423 System Tests 386 Preparing the People 423 Acceptance Tests 386 Postimplementation Activities 424 Developing Documentation 388 Chapter Review 424 Types of Documentation 389 Designing Documentation Structure 389 CHAPTER 14 The Movement to Objects Writing Documentation Topics 391 (Online Only) 427 Identifying Navigation Terms 392 You can access this chapter at Applying the Concepts at Tune Source 394 www.wiley.com/college/dennis Managing Programming 394 INDEX I-1 Testing 394 Developing User Documentation 396 Chapter Review 397 MY PROJECT PART ONE PLANNING PHASE Planning st System Request Chapter 1 Project Initiation Feasibility Analysis llyysiss Project Workplan lan Chapter 2 Staffing Plan Project Management Project Standards rdss Risk Assessment ntt n Analysis The Planning Phase involves two primary issues: understanding why an information system should be developed and creating a plan for how the project team should develop it. Design The deliverables from both steps are combined into the project plan. The project sponsor and approval committee Implementation then decide if the project should continue on.  CHAPTER 1 THE SYSTEMS ANALYST AND INFORMATION SYSTEMS DEVELOPMENT PLANNING TASK Identify project. Develop systems request. CHECKLIST Analyze technical feasibility. Analyze economic feasibility. Analyze organizational feasibility. Perform project selection review. Estimate project time. Identify project tasks. Create work breakdown structure. Create PERT Charts. Create Gantt Charts. Manage scope. Staff project. Create project charter. Set up CASE repository. Develop standards. Begin documentation. Assess and manage risk. T his chapter introduces the role of the systems analyst in information systems develop- ment projects. First, the fundamental four-stage systems development life cycle (planning, analysis, design, and implementation) is established as the basic framework for the informa- tion system (IS) development process. Next, ways in which organizations identify and initiate potential projects are discussed. The first steps in the process are to identify a project that will deliver value to the business and to create a system request that provides the basic informa- tion about the proposed system. Next, the analysts perform a feasibility analysis to determine the technical, economic, and organizational feasibility of the system. OBJECTIVES Explain the role played in information systems development by the systems analyst. Describe the fundamental systems development life cycle and its four phases. Explain how organizations identify IS development projects. Explain the importance of linking the information system to business needs. Be able to create a system request. Describe technical, economic, and organizational feasibility assessment. Be able to perform a feasibility analysis.  Introduction 3 INTRODUCTION The systems development life cycle (SDLC) is the process of determining how an information system (IS) can support business needs, designing the system, building it, and delivering it to users. If you have taken a programming class or have programmed on your own, you have probably experienced some success in developing small software applications. Creating high-quality information systems that meet expectations and provide meaningful value to organizations is a much more complex endeavor, however. Numerous studies over the years report that projects involving information technology experience failure rates from 30 to 70%.1 The definition of failure in these studies is often quite different, so the meaning of these statistics is hard to pin down. It is clear, though, that bringing an information system development project to a successful conclusion is difficult and many things need to be done right if we hope to achieve a positive outcome. Although we would like to promote this book as a “silver bullet” that will keep you from experiencing failed IS projects, we must admit that such a silver bullet guaranteeing IS devel- opment success does not exist.2 Instead, this book will provide you with many fundamental concepts and practical techniques that you can use to improve the likelihood of success. The systems analyst plays a key role in the SDLC, analyzing the business situation, identi- fying opportunities for improvements, and designing an information system to implement the improvements. Many systems analysts view their profession as one of the most interesting, exciting, and challenging jobs around. As a systems analyst, you will work as a team with a variety of people, including business and technical experts. You will feel the satisfaction of seeing systems that you designed and developed make a significant positive business impact, while knowing that your unique skills helped make that happen. It is important to remember that the primary objective of the systems analyst is not to create a wonderful system. The primary goal is to create value for the organization, which for most companies means increasing profits. (Government agencies and not-for-profit organiza- tions measure value differently.) Many failed projects were abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would sup- port the organization’s goals, improve business processes, and integrate with other information systems to provide value. An investment in an information system is like any other investment, such as a new machine tool. The goal is not to acquire the tool, because the tool is simply a means to an end; the goal is to enable the organization to perform work better so that it can earn greater profits or serve its constituents more effectively. This book introduces you to the fundamental skills needed by a systems analyst. This is a pragmatic book that discusses best practices in systems development; it does not present a general survey of systems development that exposes you to everything about the topic. By definition, systems analysts do things and challenge the current way that an organization works. To get the most out of this book, you will need to actively apply the ideas and concepts in the examples and in the “Your Turn” exercises that are presented throughout to your own systems development project. This book will guide you through all the steps for delivering a successful information system. In the text, we illustrate how one organization, called Tune Source, applies the steps in one project, developing a Web-based digital music sales system. (Other illustrations of successful IS projects are provided on the course web site.) By the time 1Michael Krigsman, “CIO Analysis: Why 37 Percent of Project Fail”, zdnet.com, accessed February 2014. 2The idea of using the silver bullet metaphor was first described in a paper by Frederick Brooks. See Frederick P. Brooks, Jr., “No Silver Bullet—Essence and Accident in Software Engineering,” Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, H.-J. Kugler (ed.), 1986: 1069–76. 4 C ha pt e r 1 The Systems Analyst and Information Systems Development CONCEPTS 1-A Managerial Causes of IT Failures IN ACTION A significant proportion of IT projects fail to fulfill their An analysis of these IT failures reveals several contrib- original objectives, resulting in wasted resources and a uting factors. First, Qantas faced the challenges of a compli- damaged reputation for the responsible IT department. cated technical infrastructure and outdated legacy In many cases, the causes of the failure are organiza- applications. More significantly, however, was the failure of tional issues, not technical issues. company leadership to understand basic IT issues. In public Qantas, the Australian national airline, has endured statements, the company CFO seemed not to care about the two high-profile IT failures in recent years. In 1995, user perspectives on new software, preferring instead to put Project eQ, a 10-year technology services contract with in what management thought was appropriate. This atti- IBM, was cancelled after four years, at a cost of $200 tude, in part, led to union problems and claims of poorly million. Poor planning contributed to the failure to designed, hard-to-use software and inadequate training. upgrade a complex and unwieldy IT infrastructure sad- Aging applications and an unwieldy technical infra- dled with 700-odd applications written in older pro- structure are challenges faced by many organizations gramming languages. today. But the senior-management attitude that seem- In 2008, Qantas canceled Jetsmart, a $40 million ingly disregards the views of software users casts serious parts-management system implementation, due in part to questions about Qantas’ prospects for IT project success a dispute with the unionized users (aircraft mechanics) of in the future. the system. The union advised its members not to assist Adapted from: Michael Krigsman, “Quantas Airways: A with the implementation, claiming the software unneces- Perfect Storm for IT Failures?”, 2/29/08, zdnet.com, accessed sarily increased the members’ workload. March 2014. you finish the book, you will not be an expert analyst, but you will be ready to start building systems for real. In this chapter, we first describe the role of the systems analyst in information systems development projects. We discuss the wide range of skills needed to be successful in this role, and we explain various specialties that systems analysts may develop. We then introduce the basic SDLC that information systems projects follow. This life cycle is common to all projects and serves as a framework for understanding how information systems projects are accom- plished. We discuss how projects are identified and initiated within an organization and how they are initially described in a system request. Finally, we describe the feasibility analysis that is performed, which drives the decision whether to proceed with the project. THE SYSTEMS ANALYST The systems analyst plays a key role in information systems development projects. The sys- tems analyst works closely with all project team members so that the team develops the right system in an effective way. Systems analysts must understand how to apply technology to solve business problems. In addition, systems analysts may serve as change agents who iden- tify the organizational improvements needed, design systems to implement those changes, and train and motivate others to use the systems. Systems Analyst Skills New information systems introduce change to the organization and its people. Leading a successful organizational change effort is one of the most difficult jobs that someone can do. Understanding what to change, knowing how to change it, and convincing others of the need for change require a wide range of skills. These skills can be broken down into six major categories: technical, business, analytical, interpersonal, management, and ethical.  The Systems Analyst 5 Spotlight on Ethics-1 James is a systems analyst on a new account manage- James is uncomfortable with the request. He is not ment system for Hometown National Bank. At a recent sure the bank has the right to use a person’s data for meeting with the project sponsor, James learned about purposes other than the original intent. Who “owns” this some new ideas for the system that were not a part of data, the bank that collected it as a part of a customer the original project scope. Specifically, the bank’s mar- opening an account, or the customer who the data keting director has asked that some of the data that will describes? Should James insist that the customers give be collected by the new system from customers who authorization to use “their” data in this way? Or should open new checking and savings accounts also be used he say nothing and ignore the issue? Is it necessary (or as the basis of a marketing campaign for various loan appropriate) for a systems analyst to be an ethical watch- products the bank offers. dog in a systems development project? Why or why not? Analysts must have the technical skills to understand the organization’s existing technical environment, the new system’s technology foundation, and the way in which both can be fit into an integrated technical solution. Business skills are required to understand how IT can be applied to business situations and to ensure that IT delivers real business value. Analysts are continuous problem solvers at both the project and the organizational level, and they put their analytical skills to the test regularly. Often, analysts need to communicate effectively, one-on-one with users and business managers (who often have little experience with technology) and with programmers (who often have more technical expertise than the analyst does). They must be able to give presenta- tions to large and small groups and to write reports. Not only do they need to have strong interpersonal abilities, but they also need to manage people with whom they work, and they must manage the pressure and risks associated with unclear situations. Finally, analysts must deal fairly, honestly, and ethically with other project team members, managers, and system users. Analysts often deal with confidential information or information that, if shared with others, could cause harm (e.g., dissent among employees); it is important for analysts to maintain confidence and trust with all people. Systems Analyst Roles As organizations and technology have become more complex, most large organizations now build project teams that incorporate several analysts with different, but complementary roles. In smaller organizations, one person may play several of these roles. Here we briefly describe these roles and how they contribute to a systems development project. YO U R 1-1 Being an Analyst TU R N Suppose you set a goal to become an analyst after you Question graduate. What type of analyst would you most prefer to be? Why does this particular analyst role appeal to Develop a short plan that describes how you will pre- you? What type of courses should you take before you pare for your career as an analyst. graduate? What type of summer job or internship should you seek? 6 C ha pt e r 1 The Systems Analyst and Information Systems Development The systems analyst role focuses on the IS issues surrounding the system. This person develops ideas and suggestions for ways that IT can support and improve business processes, helps design new business processes supported by IT, designs the new information system, and ensures that all IS standards are maintained. The systems analyst will have significant training and experience in analysis and design and in programming. The business analyst role focuses on the business issues surrounding the system. This person helps to identify the business value that the system will create, develops ideas for improving the business processes, and helps design new business processes and policies. The business analyst will have business training and experience, plus knowledge of analysis and design. The requirements analyst role focuses on eliciting the requirements from the stakeholders associated with the new system. As more organizations recognize the critical role that com- plete and accurate requirements play in the ultimate success of the system, this specialty has gradually evolved. Requirements analysts understand the business well, are excellent commu- nicators, and are highly skilled in an array of requirements elicitation techniques (discussed in Chapter 3). The infrastructure analyst role focuses on technical issues surrounding the ways the sys- tem will interact with the organization’s technical infrastructure (hardware, software, net- works, and databases). This person ensures that the new information system conforms to organizational standards and helps to identify infrastructure changes that will be needed to support the system. The infrastructure analyst will have significant training and experience in networking, database administration, and various hardware and software products. Over time, an experienced infrastructure analyst may assume the role of software architect, who takes a holistic view of the organization’s entire IT environment and guides application design deci- sions within that context. The change management analyst role focuses on the people and management issues surrounding the system installation. This person ensures that adequate documentation and support are available to users, provides user training on the new system, and develops strat- egies to overcome resistance to change. The change management analyst will have signifi- cant training and experience in organizational behavior and specific expertise in change management. The project manager role ensures that the project is completed on time and within budget and that the system delivers the expected value to the organization. The project manager is often a seasoned systems analyst who, through training and experience, has acquired special- ized project management knowledge and skills. More will be said about the project manager in the next chapter. The roles and the names used to describe them may vary from organization to organiza- tion. In addition, there is no single typical career path through these professional roles. Some people may enter the field as a more technically oriented programmer/analyst. Others may enter as a business-oriented functional specialist with an interest in applying IT to solve busi- ness problems. As shown in Figure 1-1, those who are interested in the broad field of informa- tion systems development may follow a variety of paths during their career. THE SYSTEMS DEVELOPMENT LIFE CYCLE In many ways, building an information system is similar to building a house. First, the owner describes the vision for the house to the developer. Second, this idea is transformed into sketches and drawings that are shown to the owner and refined (often, through several draw- ings, each improving on the other) until the owner agrees that the pictures depict what he or she wants. Third, a set of detailed blueprints is developed that presents much more specific information about the house (e.g., the layout of rooms, placement of plumbing fixtures and  The Systems Development Life Cycle 7 Change Requirements management analyst analyst Entry-level Business business function analyst specialist Project manager Systems analyst Entry-level programmer/ analyst Infrastructure Software analyst architect More common path FIGURE 1-1 Career Paths for Less common path System Developers electrical outlets, and so on). Finally, the house is built following the blueprints—and often with some changes and decisions made by the owner as the house is erected. Building an information system using the SDLC follows a similar set of four fundamental phases: planning, analysis, design, and implementation (Figure 1-2). Each phase is itself com- posed of a series of steps, which rely on techniques that produce deliverables (specific docu- ments and files that explain various elements of the system). Figure 1-3 provides more detail on the steps, techniques, and deliverables that are included in each phase of the SDLC and outlines how these topics are covered in this textbook. Figures 1-2 and 1-3 suggest that the SDLC phases proceed in a logical path from start to finish. In some projects, this is true. In many projects, however, the project team moves through the steps consecutively, incrementally, iteratively, or in other patterns. Different pro- jects may emphasize different parts of the SDLC or approach the SDLC phases in different ways, but all projects have elements of these four phases. For now, there are two important points to understand about the SDLC. First, you should get a general sense of the phases and steps that IS projects move through and some of the techniques that produce certain deliverables. In this section, we provide an overview Planning Analysis Design Implementation Idea System success FIGURE 1-2 The Systems Development Life Cycle 8 C ha pt e r 1 The Systems Analyst and Information Systems Development Phase Chapter Step Technique Deliverable Planning 1 Identify opportunity Project identification System request Focus: Why build 1 Analyze feasibility Technical feasibility Feasibility study this system? Economic feasibility How to structure Organizational feasibility the project? 2 Develop workplan Time estimation Project plan Primary outputs: Task identification —Workplan —System request with Work breakdown structure feasibility study PERT chart —Project plan Gantt chart Scope management 2 Staff project Project staffing —Staffing plan Project charter 2 Control and direct project CASE repository —Standards list Standards —Risk assessment Documentation Timeboxing Risk management Analysis 3 Develop analysis strategy Business process automation System proposal Focus: Who, what, Business process improvement where, and when for Business process reengineering this system? 3 Determine business Interview —Requirements definition Primary output requirements JAD session —System proposal Questionnaire Document analysis Observation 4 Create use cases Use case analysis —Use cases 5 Model processes Data flow diagramming —Process models 6 Model data Entity relationship modeling —Data model Normalization Design 7 Design physical system Design strategy Alternative matrix Focus: How will this System specification system work? 8 Design architecture Architecture design —Architecture report Primary output: Hardware and software selection —Hardware and software specification —System specification 9 Design interface Use scenario —Interface design Interface structure Interface standards Interface prototype Interface evaluation 10 Design programs Data flow diagramming —Physical process model Program structure chart —Program design Program specification 11 Design databases and files Data format selection —Database and file specification Entity relationship modeling —Physical data model Denormalization Performance tuning Size estimation Implementation 12 Construct system Programming Test plan Focus: Delivery and Software testing Programs support of completed Performance testing Documentation system Migration plan Primary output: 13 Install system Conversion strategy selection —Conversion plan —Installed system —Business contingency plan Training —Training plan 13 Maintain system Support selection Support plan System maintenance Problem report Project assessment Change request 13 Post-implementation Post-implementation Post-implementation audit audit report FIGURE 1-3 Systems Development Life Cycle Phases  The Systems Development Life Cycle 9 of the phases, steps, and some of the techniques that are used to accomplish the steps. Second, it is important to understand that the SDLC is a process of gradual refinement. The deliverables produced in the analysis phase provide a general idea what the new system will do. These deliverables are used as input to the design phase, which then refines them to produce a set of deliverables that describes in much more detailed terms exactly how the system should be built. These deliverables in turn are used in the implementation phase to guide the creation of the actual system. Each phase refines and elaborates on the work done previously. Planning The planning phase is the fundamental process of understanding why an information system should be built and determining how the project team will go about building it. It has two steps: 1. During project initiation, the system’s business value to the organization is identified— how will it contribute to the organization’s future success? Most ideas for new systems come from outside the IS area and are recorded on a system request. A system request presents a brief summary of a business need and explains how a system that addresses the need will create business value. The IS department works together with the person or department generating the request (called the project sponsor) to conduct a feasibility analysis. The feasibility analysis examines key aspects of the proposed project: The technical feasibility (Can we build it?) The economic feasibility (Will it provide business value?) The organizational feasibility (If we build it, will it be used?) The system request and feasibility analysis are presented to an information systems approval committee (sometimes called a steering committee), which decides whether the project should be undertaken. 2. Once the project is approved, it enters project management. During project management, the project manager creates a workplan, staffs the project, and puts techniques in place to help control and direct the project through the entire SDLC. The deliverable for project management is a project plan that describes how the project team will go about develop- ing the system. Analysis The analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used (Figure 1-3). During this phase, the project team investi- gates any current system(s), identifies improvement opportunities, and develops a concept for the new system. This phase has three steps: 1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy usually includes studying the current system (called the as-is system) and its problems, and envi- sioning ways to design a new system (called the to-be system). 2. The next step is requirements gathering (e.g., through techniques such as interviews, group workshops, or questionnaires). The analysis of this information—in conjunction with input from the project sponsor and many other people—leads to the develop- ment of a concept for a new system. The system concept is explained through a set of requirement statements and a set of business analysis models that describe how the business will operate if the new system is developed. The analysis models represent user/system interactions and the data and processes needed to support the underlying business process. 10 C ha pt er 1 The Systems Analyst and Information Systems Development 3. The analyses, system concept, requirements, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key deci- sion makers (e.g., members of the approval committee) who will decide whether the project should continue to move forward. The system proposal is the initial deliverable describing the requirements the new system should satisfy. Some experts suggest this phase would be better named analysis and initial design, rather than analysis, since it really provides the first step in the new system design. Since most organizations continue to use the name analysis for this phase, we will use it in this book as well. It is important to remember, however, that the deliverable from the analysis phase is both an analysis and a high-level initial design for the new system. Design The design phase decides how the system will operate in terms of the hardware, software, and network infrastructure that will be in place; the user interface, forms, and reports that will be used; and the specific programs, databases, and files that will be needed. Although most of the strategic decisions about the system are made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate. The design phase has four steps: 1. The design strategy must be determined. This clarifies whether the system will be developed by the company’s own programmers, whether its development will be outsourced to another firm (usually a consulting firm), or whether the company will buy and install a prewritten software package. 2. This leads to the development of the basic architecture design for the system that describes the hardware, software, and network infrastructure that will be used. In most cases, the system will add to or change the infrastructure that already exists in the organization. The interface design specifies how the users will move through the system (e.g., by navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use. 3. The database and file specifications are developed. These define exactly what data will be stored and where they will be stored. 4. The analyst team develops the program design, which defines the programs that need to be written and exactly what each program will do. This collection of deliverables (architecture design, interface design, database and file specifications, and program design) is the system specification that is used by the program- ming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue (Figure 1-3). Implementation The final phase in the SDLC is the implementation phase, during which the system is actually built (or purchased and installed if the design calls for a prewritten software package). This is the phase that usually gets the most attention, because for most systems it is the longest and most expensive single part of the development process. This phase has three steps: 1. System construction is the first step. The system is built and tested to ensure that it per- forms as designed. Since the cost of fixing bugs can be immense, testing is one of the most critical steps in implementation. Most organizations should spend more time and attention on testing than on writing the programs in the first place.  Project Identification and Initiation 11 2. The system is installed. Installation is the process by which the old system is turned off and the new one is turned on. There are several approaches that may be used to convert from the old to the new system. One of the most important aspects of conversion is training, during which users are taught to use the new system and help manage the resulting organizational changes. 3. The analyst team establishes a support plan for the system. This plan usually includes a formal or informal post-implementation review, as well as a systematic way for identify- ing major and minor changes needed for the system. PROJECT IDENTIFICATION AND INITIATION Where do project ideas come from? A project is identified when someone in the organiza- tion identifies a business need to build a system. Examples of business needs include sup- porting a new marketing campaign, reaching out to a new type of customer, or improving interactions with suppliers. Sometimes, needs arise from some kind of “pain” within the organization, such as a drop in market share, poor customer service levels, unacceptable product defect rates, or increased competition. New business initiatives and strategies may be created and a system to support them is required, or a merger or acquisition may require systems to be integrated. Business needs also can surface when the organization identifies unique and competitive ways of using IT. Many organizations keep an eye on emerging technology, which is technology that is in the early stages of widespread business use. For example, if companies stay abreast of technological advances such as cloud computing, mobile apps, or Big Data, they can develop business strategies that leverage the capabilities of these technologies and introduce them into the marketplace as a first mover. Ideally, companies can take advantage of this first mover posi- tion by making money and continuing to innovate while competitors trail behind. Today, many new information system projects grow out of business process management (BPM) initiatives. BPM is a methodology used by organizations to continuously improve end- to-end business processes. BPM can be applied to internal organizational processes and to processes spanning multiple business partners. By studying and improving their underlying business processes, organizations can achieve several important benefits, including: enhanced process agility, giving the organization the ability to adapt more rapidly and effectively to a changing business environment; improved process alignment with industry “best practices”; and increased process efficiencies as costs are identified and eliminated from process workflows. BPM generally follows a continuous cycle of systematically creating, assessing, and alter- ing business processes. Business analysts, with their in-depth business knowledge, play a particularly important role in BPM by: 1. defining and mapping the steps in a business process, 2. creating ways to improve on steps in the process that add value, 3. finding ways to eliminate or consolidate steps in the process that do not add value, 4. creating or adjusting electronic workflows to match the improved process maps. The last step is particularly relevant to our discussion since the need for information sys- tems projects is frequently identified here. In fact, the automation of business processes (termed business process automation), is the foundation of many information technology sys- tems. In these situations, technology components are used to complement or substitute for manual information management processes with the intent of gaining cost efficiencies. 12 C ha pt er 1 The Systems Analyst and Information Systems Development BPM practitioners recognize, however, that it is not always advisable to just “pave the cow paths” by simply adding automation to speed up existing processes (step 4 above). In many situations, business process improvement (BPI) results from studying the business processes, creating new, redesigned processes to improve the process workflows, and/or utilizing new technologies enabling new process structures (steps 2, 3, and 4 above). For example, could a retail store’s checkout process be redesigned along the lines of the EZPass toll collection sys- tem on highways? Could customers check out and pay with their mobile devices while clerks simply review the contents of the customer’s shopping bag? Projects with a goal of BPI make moderate changes to the organization’s operations, and can improve efficiency (i.e., doing things right) and improve effectiveness (i.e., doing the right things). These types of projects involve more risk than business process automation projects since more significant changes are made to the organization’s operations. BPM may also reveal the need for the complete revamping of the organization’s business processes, termed business process reengineering (BPR). BPR means changing the fundamental way in which the organization operates—“obliterating” the current way of doing business and making major changes to take advantage of new ideas and new technology. As you might expect, BPR projects involve substantial risk due to the significant organizational and opera- tional changes that result. Top management support and careful management are critical in these fairly rare types of projects. Both IT people (i.e., the information systems experts) and business people (i.e., the sub- ject matter experts) should work closely together to find ways for technology to support busi- ness needs. In this way, organizations can leverage the exciting technologies available while ensuring that projects are based upon real business objectives such as increasing sales, improv- ing customer service, and decreasing operating expenses. Ultimately, information systems need to affect the organization’s bottom line (in a positive way!). When a strong business need for an information system is recognized, often as a result of BPM, a person (or group) who has an interest in the system’s success typically steps forward. We call this person (or group) the project sponsor. Often, the project sponsor develops the initial vision of the new system. The project sponsor works throughout the SDLC to make sure that the project is moving in the right direction from the perspective of the business and serves as the primary point of contact for the project team. Usually, the sponsor of the project is from a business function such as marketing, accounting, or finance; however, members of the IT area also can sponsor or cosponsor a project. CONCEPTS 1-B BPI on the Farm IN ACTION In the farming industry, grain is commonly loaded smartphone from the truck cab. Through the app, the into large grain-hauling trucks by the driver parking driver can initiate, monitor, and control the filling under the grain bin, jumping out of the truck cab, process without a grain bin operator and without leav- signaling the grain bin operator to start filling, moni- ing the truck. This real-world example illustrates BPI, toring the fill level, signaling the bin operator to stop the redesign of a business process with the right appli- filling, jumping back into the truck cab, driving 3 feet cation of information technology, providing signifi- forward, and repeating the cycle numerous times until cant efficiency gains. the truck bed is full. This laborious process can be simplified by digitizing the process. Cameras and Adapted from: Nicole Laskowski, “Crowdsourcing is the new secure Wi-Fi can be installed on the grain bin. When cloud computing—Get with it, CIOs,” searchcio.techtarget. a truck arrives, the driver can open an app on his com, accessed February 2014.  Project Identification and Initiation 13 YO U R 1-2 Implementing a Satellite Data Network TU R N A major retail store spent $24 million dollars on a large high-end (and high-profit) snow throwers quite quickly, private satellite communication system that provides the company’s nearest warehouse can prepare next-day state-of-the-art voice, data, and video transmission shipments to maintain a good inventory balance, while between stores and regional headquarters. When an item the competitor may not move quite as quickly and thus gets sold, the scanner software updates the inventory lose out on such quick inventory turnover. system in real time. As a result, store transactions are passed on to regional and national headquarters instantly, Questions which keeps inventory records up to date. One of the store’s major competitors has an older system in which 1. Do you think a $24 million investment in a transactions are uploaded at the end of a business day. private satellite communication system could be The first company feels that its method of instant com- justified by a cost-benefit analysis? Could this be munication and feedback allows it to react more quickly done with a standard communication line (with to changes in the market, giving the company a competi- encryption)? tive advantage. For example, if an early winter snowstorm 2. How might the competitor attempt to close the causes stores across the upper Midwest to start selling “information gap” in this example? The size or scope of the project often determines the kind of sponsor who is involved. A small, departmental system might be sponsored by a single manager; however, a large, organizational initiative might be sponsored by the entire senior management team and even the CEO. If a project is primarily technical in nature (e.g., improvements to the exist- ing IT infrastructure or research into the viability of an emerging technology), then spon- sorship from IT is appropriate. When projects have great importance to the business, yet are technically complex, joint sponsorship by both the business and IT functions may be necessary. The business need drives the high-level business requirements for the system. Business requirements describe the reasons for developing the system and outline the capabilities it will provide the organization. These requirements need to be explained at a high level so that the approval committee and, ultimately, the project team understand what the business expects from the final product. Business requirements summarize the features the information system must include, such as the ability to collect customer orders online or the ability for suppliers to receive inventory status information as sales occur. The project sponsor has the insights needed to determine the business value that will be gained from the system, in both tangible and intangible ways. Tangible value can be quantified and measured easily (e.g., 2% reduction in operating costs). An intangible value results from an intuitive belief that the system provides important, but hard-to-measure, benefits to the organization (e.g., improved customer service, a better competitive position). Once the project sponsor identifies a project that meets an important business need and he or she can identify the business requirements and business value of the system, it is time to formally initiate the project. In most organizations, project initiation begins by preparing a system request. System Request A system request is a document that describes the business reasons for building a system and the value that the system is expected to provide. The project sponsor usually completes this 14 C ha pt er 1 The Systems Analyst and Information Systems Development form as part of a formal system project selection process within the organization. Most system requests include five elements: project sponsor, business need, business requirements, business value, and special issues (Figure 1-4). The sponsor describes the person who will serve as the primary contact for the project, and the business n