Supplement 1
A Systems Analysis and Design Project at Pine Valley Furniture

 L E A R N I N G    O B J E C T I V E S

After studying this supplement, you should be able to:

  1. Describe the life cycle of a specific systems analysis and design project, including the purpose and deliverables of each step.
  2. List the important skills required of a systems analyst in conducting a systems analysis and design project.
  3. Explain the purpose of adopting a standard methodology for systems development in an organization.
  4. Discuss the roles of individuals who work on a systems project.
  5. Explain the differences between the analysis, design, and implementation phases of a systems development project.
  6. Describe the purpose of basic documentation produced during a systems development project.


Chapter 1 in Modern Systems Analysis and Design (Hoffer, George, and Valarich, 1999) introduces systems analysis and design, including an overview of the systems development life cycle. This supplement illustrates highlights from a typical successful systems development project that follows this life cycle. Since you will likely read this supplement early in your study of systems development, our example project is somewhat idealistic. And keep in mind that not all projects go as well as the one described here. Throughout Modern Systems Analysis and Design, however, we raise various technical and managerial issues that can occur during a systems development project. This supplement includes various aspects of project management common in systems development. How the project leaders in our example case, Chris Martin and Juanita Lopez, run the project is their way, not the only way, so do not assume that all projects are managed in just this one way. Due to limited space, the project description is abbreviated (for example, only selected deliverables are illustrated) but you should develop a basic understanding of systems analysis and design from the discussion.

There are several reasons to read this supplement. First, many students in a systems analysis and design course have not used or even seriously thought about an information system, nor have they participated in a systems development project. The goal of Modern Systems Analysis and Design is to introduce you to the concepts and the skills you will use to analyze business information requirements and show you how to translate those concepts and skills into systems designs. The goal of this supplement is to briefly illustrate what you will be able to do after you complete a systems analysis and design course using the associated text. In addition, this supplement introduces the various skills, techniques, and concepts explained in detail in the text.

Second, most people learn best when they see specific, concrete examples. All chapters in the associated text contain numerous examples, illustrations, and documentation written during a systems development project, and each chapter concentrates on a specific aspect of systems development. We have structured this supplement to provide you with an overview of a systems project and to explain how the various aspects of systems analysis and design are related.

Finally, many instructors want you to begin the initial steps of a systems development group or individual course project early in the term. Due to the logical progression of topics in the associated text (project identification, project definition, analysis, design, implementation, and maintenance), you will probably study many pages before you decide on your target for the project. This supplement gives you an idea of where you are headed. By studying our example case, you can begin using some basic skills early on, before a more rigorous treatment of topics is presented in the text. For example, this supplement provides a benchmark for your writing of a project proposal or plan, which might be the first step in your course project. Obviously, as a brief supplement, the examples we use are much simpler than the systems development project in your course or in a real organization.

One note of caution: Do not be concerned with the details of techniques and notations while you study this supplement. You will read about these in depth in the associated text. At this point, try to understand the reason for the technique or diagram, and do not be concerned about whether you could use the technique or produce such a diagram.

This supplement illustrates the development process for a modern information system by an in-house development unit. The setting for our illustration is Pine Valley Furniture Company, which was briefly introduced in Chapter 1 of Modern Systems Analysis and Design.


Juanita Lopez, head of the manufacturing support unit of the Purchasing Department at Pine Valley Furniture Company (PVF), is concerned about the growing backlog and quality of work in her department as PVF expands. The Purchasing Department manages all interactions between external suppliers and internal PVF departments. These interactions include the following simultaneous processes:

Juanita is concerned about delays in placing vendor orders, inefficiencies in determining the status of vendor orders, and late management summary reports. Furthermore, relationships with vendors are becoming more critical as just-in-time inventory control methods are implemented by PVF manufacturing operations. As Juanita has been charged with solving these issues without adding office staff, she is hoping that new automation can help. A systems analyst for each business unit (like Purchasing) works as a liaison between that unit and the IS development group. Juanita calls Chris Martin, the systems analyst assigned to Purchasing, to discuss her concerns.

Chris has been with PVF for six years. He joined PVF right after graduating from the baccalaureate program in the Computer Information Systems program in the business school of Valley State University. His first job was as a Programmer/Analyst I, in which he coded and maintained financial application systems written in COBOL.

As Chris became more experienced in his job, he was asked to take on additional program design work and was soon promoted to Programmer/Analyst II. He assumed some supervisory responsibilities on projects and gained more authority in structuring programs, in choosing methods to access databases, and even in recommending functional changes to systems in order to take advantage of technology.

Eventually, the growth in systems work at PVF necessitated the expansion of the information systems development unit, and Chris was promoted to a Junior Systems Analyst position in the group supporting manufacturing operations. In this assignment, Chris participated on a team that developed a five-year plan that would enable information systems to support manufacturing at PVF. This plan considered all aspects of manufacturing and its interactions with other parts of the business, such as marketing, accounting, and purchasing. Chris also worked on one of the initial projects generated from this plan which dealt with product structure (or bill-of-materials) data. As part of this project, Chris was responsible for designing files and databases to maintain this data. Since some product data (primarily physical characteristics) depended on vendor specifications, he had to analyze relevant Purchasing computer files to obtain data descriptions. As a result, at the time of Juanita's call, Chris was already aware of some of the pressures on Purchasing caused by the growth and change in manufacturing operations and had a basic understanding of Purchasing systems at PVF.


Project Identification and Selection

Purpose: Develop a preliminary understanding of the business situation that has caused the request for a new or an enhanced information system.
Deliverable: A formal request to conduct a project to design and develop an information systems solution to the business problems or opportunities.

Juanita's career has also progressed rapidly. Her work has been rated very highly and she is well respected. Juanita has never worked on a systems development project, however, and her education at a small liberal arts college did not include any exposure to information systems. Although Juanita knows the operation of her department very well and has a fairly clear idea of some of its problems as well as opportunities for improvement, she does not know how to translate these into precise requests for help from systems development. The IS development group is highly regarded and Juanita believes her open management style and Chris's expertise can complement each other in working together.

At their first meeting, Chris explains that his role at this point is to help Juanita state what her business problem is and to suggest how support from any new or improved information systems could solve her problem. In fact, one of their early joint responsibilities is to develop a brief justification for their proposal. Chris points out that, due to the huge demand for new and improved systems at PVF, not all requests can be accommodated. Further, PVF has instituted a charge-out, or transfer pricing, scheme whereby business units requiring systems development have to pay for the work done by the systems development unit. Thus, Juanita has to receive approval from her boss to fund any work performed by Chris's unit.

Chris outlines the process he and Juanita will have to follow. He explains that several years ago PVF had instituted a structured systems development methodology. He gives Juanita a copy of a chart summarizing the various steps that have to be followed for projects managed by the IS unit (see Figure 1). Using this methodology means that all project requests, proposals, and development efforts follow a common and well-defined process. This methodology also specifies how a systems project will be managed and how progress will be measured, the roles of different people involved on the project team, the deliverables due at each step, the tools and techniques used during each step, and the form and content of a project dictionary or repository to document the project. This common development methodology--the PVF Systems Development Methodology (SDM)--allows for

The first step is to develop a System Service Request (SSR). An SSR briefly states the business problem or opportunity and presents general ideas on how an information system could deal with the problem or opportunity.

PVF has a standard SSR form, which Juanita and Chris need to complete together. Juanita and Chris will then submit this form to the Systems Priority Board, a diverse group of business and systems managers representing a cross section of PVF. This Board reviews all requests and determines which are worth pursuing. In some cases, the Board suggests that the end users making the request attempt to develop their own systems using user-friendly tools such as an electronic spreadsheet package or simple database management system. The Board also rejects some requests. In most cases, however, the Board assigns a priority to the request and places it in a backlog of such requests for further study. A systems analyst is assigned to these requests in decreasing order of priority. Although this is a very formal process, the systems development group tries to make it as painless as possible for the requesting end user through the help of someone from the liaison staff, like Chris.

Over a two-week period Chris and Juanita meet and talk on the telephone several times as they put together the SSR. The SDM calls for only a cursory analysis of Juanita's situation for the SSR. The idea is to lay out the scope and basic issues involved, not to thoroughly evaluate the situation. Later steps in the methodology refine the analysis. Chris explains to Juanita that one of the basic premises of the methodology is incremental commitment. Using incremental commitment, there are many review points during a project, each successively dealing with the information system request in greater depth. The goal is to not sink significant resources into a project until the work is reviewed and the organization is willing to commit further resources to the project. In this way, incremental commitment allows projects to be easily redirected or killed.

Figure 2 shows the System Service Request Chris and Juanita develop. As you can see, the request briefly describes the situation in Purchasing. Juanita shows this SSR to her boss, Sal Divario, who signs the form. Sal's signature does not commit him to funding the project, only to supporting the request being sent to the Board. Chris then submits this form to the Systems Priority Board for their decision.

Project Initiation and Planning

Purpose: State business situation and how information systems might help solve a problem or make an opportunity possible
Deliverable: A written request to study the possible changes to an existing system or the development of a new system.


The Systems Priority Board finds merit in Juanita's request and decides to assign it the highest priority. One of the advantages of this project is that it fits nicely into the five-year plan for manufacturing systems that had been developed earlier and adopted by the Board. Although meeting needs in the purchasing function had not been identified as an early part of the manufacturing plan, the way in which Chris had helped Juanita write the SSR mentioned some of the same issues that had driven the development of that plan. The Board asks that a lead systems analyst be assigned as soon as possible to continue the study of this request.

The Board believes that those closest to the situation outlined in the SSR are well aware of the issues surrounding the request and decides to reduce its direct involvement in the rest of this systems development project. The Board usually requires that the end user and lead systems analyst submitting the request report regularly so that they can assess progress and make decisions on further deployment of resources, ensure that the project fits into systems strategy, and decide whether or not the project should continue. In this case, however, the Board asks for a chance to review this project just one more time, when the complete detailed design for the system is set. In the meantime, the Board suggests that a project steering committee be formed to monitor project progress and to give the project team guidance. This committee consists of the head of the Purchasing Department, Sal Divario; the manager of Manufacturing Systems in the IS development unit, Stacy Morton; and the manager of Database Administration, Greg Sinise. The director of IS Development, a member of the Systems Priority Board, reviews his staffing, determines that Chris is scheduled to complete work on another project soon, and assigns Chris to continue to work on this project as the lead analyst and project manager.

The next major goal for Chris and Juanita is to create a more specific statement of the requirements Juanita and her staff have for information services to deal with the problems in Purchasing. The SDM outlines the general nature of steps to follow during this project initiation and planning phase (see Figure 1). Since different projects require different approaches, PVF has chosen to have its staff use the methodology as a guideline rather than a fixed set of steps. Although the details of the SDM documentation outline alternative approaches suitable for different situations (for example, small or large systems, short or longer lead time projects), the designers of the SDM knew they could not anticipate all possible project nuances. Thus, as part of conducting an initial study of the situation in the Purchasing Department, Chris and Juanita must outline a complete project plan of their own to present to the project steering committee.

The Project Plan

Chris takes leadership of the project at this point. To gather information, he conducts several short interviews with purchasing agents and other staff members who work for Juanita, reads recent correspondence about issues in the department, and spends several hours observing a few Purchasing Department staff members as they do their jobs. Chris uses this information to develop a project plan with several key elements:

Juanita reviews and edits each of these key elements. She has primary responsibility for preparing the initial business case, which has to be formulated to solve a business rather than a technology problem. The business case is based on identifying and, where possible, quantifying the possible benefits and costs of solving the problem. The business case justifies the system project as economically, technically, legally, and politically sound. The time line shows that the project schedule is feasible since each step is reasonable and will result in the project being completed in time to deal with the business problem. That is, the system makes financial sense and can be built and implemented within the organization. Since the actual requirements are not yet known and a precise system design is constructed in a later step, the business case at this point primarily identifies broad categories of costs and benefits such as lower inventory levels, improved service to customers, improved morale in Purchasing, and more favorable pricing from suppliers. The business case is readdressed and refined in each phase of the project.

Their project plan is a 10-page document plus figures. Figure 3 contains an excerpt from this plan: a sample of the Gantt and PERT charts specifying the time line of events for the next phase of the project--the analysis phase. The full document shows similar charts for all the remaining phases from analysis through implementation. The total estimated project length is 31 weeks, with the analysis phase taking about the first 10 weeks. The Gantt chart in Figure 3a shows that the analysis phase has 10 steps and two milestones. Each activity is critical: Some cannot be delayed without the whole project being delayed. Steps 4 and 5 occur during the same period but, as we will see in the PERT chart, they are not independent of each other. Additional Gantt charts not shown here match the requested human resources to each project activity so that everyone can see when each project team member is required. IS and other managers use the human resource Gantt charts to assign their staff to multiple projects and duties throughout the life of the Purchasing Fulfillment System project.

Figure 3b is an overview PERT chart for the analysis phase. As we can see from this figure, only steps 7 and 8 occur independently of each other, but neither can start until step 6 is completed, and step 9 cannot begin until both steps 7 and 8 are completed. This chart, along with more detailed PERT charts not included here, shows a clear understanding of the nature of the planned project and gives useful information to anyone trying to understand the project.

Chris and Juanita used several key principles in developing the project plan and schedule: use of frequent review points, scheduling parallel steps where feasible, and thoroughness. First, there are definite review points scheduled (shown by the diamonds on the Gantt chart). Each step and phase of the project produces an identifiable deliverable that is reviewed with the project steering committee, the Systems Priority Board, a set of end users, or others interested in the project. Early in the study, Chris identified many stakeholders whose needs must be met for the system to be fully implemented. Some of the stakeholders are on either the steering committee or the Priority Board while some have other roles in and around the project. The stakeholders include the following people:

Chris knows from past experience that it is essential to involve these stakeholders in the process, to work closely with them in setting realistic expectations about the system changes, to obtain their insights into system requirements and design, and to gain their commitment to the new system. Input from the stakeholders also helps Chris identify the risks of the project, which might involve potential interfacing problems with other systems, resistance from certain stakeholders, or management policy issues that constrain what a new system might do. Both Chris and Juanita will spend most of their time communicating in writing and orally with these stakeholders at official review points and also informally as needed. The review points serve as a mechanism to check that all stakeholders are reasonably in agreement on the direction of the project.

A second key aspect of the project plan depicted in Figure 3 is that the process includes parallel steps, where possible, to decrease overall project time. The project is broken down into identifiable and manageable tasks that can be assigned to different people working in parallel. Although this approach places an extra burden on Chris and Juanita, who must coordinate the activities of these people, compression of the project schedule is necessary so that the problems in Purchasing can be addressed expeditiously.

The final key aspect of the project plan is the thoroughness with which Chris and Juanita have thought out the project. The SDM was a big help in developing the plan because it outlines the standard steps to follow under different circumstances (for example, different system sizes, different types of systems, and constraints on development time) and indicates which techniques and tools to use along the way. Chris knows, however, that even with the slack time built in, he and Juanita cannot anticipate all contingencies. Business needs might change, people involved in the project may not be available when needed, or financial resources might have to be diverted to solve a crisis with another system or elsewhere in Purchasing. Chris and Juanita realize they have to be firm but flexible in managing this schedule. Chris and Juanita submit their plan and make a brief presentation to the project steering committee. The committee endorses the plan, and Sal Divario authorizes expenditures from his budget to cover the costs of systems analysts and other IS staff to conduct the full analysis phase. Sal also writes a memo to the Purchasing Department staff explaining the project and requesting their full cooperation. Such visible commitment from senior management is often important in gaining the attention of all the personnel needed to conduct a successful project.


Purpose: Analyze the business situation thoroughly to determine requirements for a new or an enhanced information system, structure those requirements for clarity and consistency, and select among competing system features those that best meet user requirements within development constraints.
Deliverable: The functional specifications for a system that meets user requirements and is feasible to develop and implement.


Chris and Juanita begin the analysis phase by learning about the Purchasing Department functions that will be addressed in this project. Their goal is to outline the operations at a macro level so that they can structure more detailed work that will be done by a small team of systems analysts assigned to work with them for two weeks. The project plan calls for a top-down approach to systems analysis, typical of the structured philosophy of the SDM. Chris and Juanita develop two charts, a context diagram (CD) and a level-0 data flow diagram (DFD), to structure the analysts' work (Figure 4). The diagrams are built using the CASE tool used by PVF. This CASE tool contains the following features:

All documentation of the current and new systems will be created using the CASE tool. By having the analysts use the CASE tool to document their work, all project team members will have access to accurate and consistent documentation on various parts of the system. Thus, combining and comparing their work is simplified.

The context diagram of Figure 4a shows the scope of the project. The organizational system the analysts will study is called the Purchasing Fulfillment System, identified by the rectangle with rounded corners in the center of this figure. This open system interacts with three entities external to the Purchasing Fulfillment System: Suppliers--who are outside PVF--and Production Schedulers and Engineering--which are other PVF units. The context diagram shows that the part of Pine Valley Furniture that will be analyzed and redesigned is contained within this one rectangle. As long as the interactions of the Purchasing Fulfillment System with its external entities are preserved and met, the system itself can be redesigned as needed. Since the Purchasing Fulfillment System is an information system, these interactions are data flows between the system and the external entities.

Figure 4a is still at too gross a level to structure the work for the systems analysts. The data flow diagram of Figure 4b shows the inter-relationships among the major components of the current operations in the Purchasing Department that include the functions of the Purchasing Fulfillment System. Again, major functions called processes (for example, process 1.0--Forecast Material Needs) are shown by rectangles with rounded corners; data flows (for example, Material Forecasts) are shown by directional lines. Even at this level of description, data retained by the system, called data stores, are not shown (although they could be shown on such diagrams). These will be enumerated in subsequent project steps. Chris and Juanita plan to organize the project so that each systems analyst studies the portion of the Purchasing Department covered by different sections of the diagram in Figure 4b.

Chris and Juanita meet with the assigned analysts before they begin their work. The team reviews the project and the process they will follow during the analysis phase. Chris portrays the steps as resembling an hour glass in which the analysis will start off very broadly and refine iteratively into more detail until the analysts develop a precise picture of the current purchasing operations. Then they will build the analysis back up to a comprehensive conclusion culminating with the design for a new system. This is consistent with the top-down and bottom-up techniques employed in structured systems development. The analysis steps they follow are listed below:

  1. Each systems analyst develops more and more detailed DFDs to show how the functions, data flows, and data stores in his or her portion of the diagram are handled by the current procedures; these additional DFDs describe the current physical system, including the people, business forms, and technology currently used with each process, data flow, and data store. The diagrams identify specific reports, forms, transactions, and other media on which information are stored and transmitted. The systems analysts use interviews, analysis of business documents, and observation to develop these diagrams. Chris emphasizes the importance of not being influenced by how the current system operates. Rather, the purpose of these DFDs is to inventory what the current data processing requirements are so that the team can consider which must be handled in the new system. The data model in the next step will also help the team to not simply duplicate current procedures.
  2. Each analyst then rewrites these diagrams to exclude all references to the physical form in which information is processed and develops a logical, or functional, specification of the current system. During this step, each analyst prepares diagrams that explain the natural structure of data independently of how it is processed. This data model is described in a notation called an entity-relationship (E-R) diagram which we will illustrate later in this section.
  3. Chris then brings the team of analysts together to discuss their independent work and to review the process of combining their logical diagrams (both data flow and entity-relationship) into a consistent and comprehensive description of the current system operations. They then outline the precise problems they discovered with the current system and suggest possible restructuring.
  4. Next, the team conducts further data collection by interviewing end users and other stakeholders about problem areas within the current operations and about desired information requirements. They also hold a Joint Application Design (JAD) session in which users, analysts, and systems developers come together to discuss the problems with the current system and ideas for change.
  5. Then the team of analysts along with Chris and Juanita restructure the current logical system process structure and data models and identify the major features of two or more alternative new systems. Each alternative takes a different approach to dealing with Purchasing issues: for example, Alternative 1 might assume a preferred supplier for each material item whereas Alternative 2 might assume a supplier is selected from a set of possible vendors for each material item. These alternative structures are described at a general level, sufficient to show major differences but stopping short of a detailed design. This will be done in the next phase of the project--Logical Design. For each alternative, the team identifies its advantages and disadvantages as well as its organizational impacts on Purchasing and other departments.
  6. Finally, the team and Chris and Juanita develop a detailed justification to recommend one of the alternatives to the steering committee.

The analysis phase review meeting with the steering committee is well planned. As this review point was in the original project plan, the meeting had already been scheduled with each committee member. During the analysis phase, Chris and Juanita had made it a point to speak with each committee member approximately once a week to keep them abreast of project progress and to give them a chance to provide any insights on issues or questions that had arisen. Due to this two-way communication, the committee already feels some ownership in the team's efforts. And as Chris had sent a copy of the agenda for the meeting to each committee member one week prior to the meeting, everyone knew what to anticipate. The agenda for the analysis phase project status review meeting appears in Figure 5.

The purpose of the meeting is to

Two alternative system directions are described at a fairly general level. The objective is to give the committee enough information to make a decision without providing more detail than needed. Also, the team does not want to spend a lot of time developing system details at this point for an alternative that is not acceptable.

The data flow diagrams that the analysts developed help the group focus on areas of concern. Because the diagrams were developed in a top-down matter, following a process called functional decomposition, the team has a large number of charts, each concentrating on one area of Purchasing operations. Thus, when a question arises, the team shows one chart with an overview of the relevant part of Purchasing operations and then focuses in on any area that requires more elaboration with a detailed chart.

The analysis phase review meeting lasts two hours. The first hour is devoted to presentations by various team members followed by a question and answer period. During the second hour, participants deliberate on the team's recommendation. At the beginning of the meeting, each committee member was given a written project status report including an executive overview page plus a copy of all the presentation overheads. Figure 6 shows three key overheads: Figure 6a shows an entity-relationship (E-R) diagram, a conceptual data model, for part of the data deemed essential in a new Purchasing Fulfillment System while Figures 6b and 6c contain the justification, or business case, for the recommended alternative new system.

The E-R diagram at this point in the project shows the categories of data needed by the proposed system (for example, supplier, item, product, and shipment data entities are needed). The lines connecting data entities, or rectangles, represent relationships, or direct linkages, between data. For example, a SUPPLIER Supplies one or more ITEMs (to keep the diagram less cluttered, we are leaving off the name of the relationship in the opposite direction, such as an ITEM Supplied by from one to four SUPPLIERs). For simplicity, the chart in Figure 6a covers only part of the conceptual data model for the system. The project team will refine this diagram during the logical design phase in the SDM by adding all the individual data items needed to produce computer displays and reports. The E-R diagram shows important rules about the Purchasing function. For example, the marks near the SUPPLIER box on the line (relationship) labeled Supplies indicate that there are at least one and at most four recognized suppliers of an individual purchased item. Also, in PVF terms, a SHIPMENT involves exactly one material item (this is stated by the two marks near ITEM on the line [relationship] labeled Receives). Since the relationship between ITEM and PRODUCT represents which items go into making a product, we call this the Bill of Materials relationship.

The justification proposes the financial basis for the new system. These benefits and costs are now more specific than in the initial stage of the project since further analysis has been carried out and specific system capabilities are better known. Figure 6b lists the identified benefits and costs for the recommended system. Tangible (quantifiable) benefits and costs are broken down into one-time (in year 0) and recurring (annual in each of the following five years) categories. Intangible (nonquantifiable) benefits and costs are also listed for discussion, but these are not part of the financial analysis of the project's net benefits.

Figure 6b also includes a list of risks the project team identified for this project and system. An analysis and consideration of risks is important at this and at every review point. Risks show important elements to be managed and also alert stakeholders to issues before they become critical. For example, one risk of the proposed system is that, unless properly handled, suppliers could react negatively to the features of the new system that will cause more careful evaluation of supplier performance. Finally, Figure 6c displays the financial analysis Juanita and Chris present to the steering committee.

Also part of the presentation is a request for additional resources in order to continue the project. This request involves the assignment of a database design expert, a LAN specialist, two of the more experienced purchasing agents, and a programmer to the project team, along with the retention of the analysts throughout the next two phases--logical and physical design. Chris and Juanita explain that the programmer would be useful in the design phases to help facilitate the transition into the implementation phase. They also present an updated project budget, including an estimate of the total development and operating costs.

The estimated return on investment for the new system is large enough that the steering committee has no trouble approving continuation of the project, including support for the new project team members. Sal Divario, Juanita's manager, points out some new purchasing policies under consideration by upper management that will affect the proposed system. As well, Stacy Morton and Greg Sinise suggest some refinements in part of the E-R diagram to accommodate the results of a manufacturing systems plan just developed for one of the production lines.

Logical Design

Purpose: To elicit and structure all information requirements for the new system.
Deliverables: Detailed functional specifications of all data, forms, reports, computer displays, and processing rules for all aspects of the system.


Chris and Juanita have now managed the Purchasing Fulfillment System project over some significant hurdles. Whereas their roles so far have included not only project leadership but also direct involvement in many project activities, the addition of new team members changes Chris's and Juanita's roles. Now they can concentrate more on coordinating team members, setting work plans and methods, reconciling differences among work done by team members, guiding the project as issues and questions arise, and finalizing project documentation, especially communication with stakeholders. The detailed systems analysis and design work during logical design and subsequent phases will be done by the other team members.

The analysis phase produced a clear statement of the general features of the new Purchasing Fulfillment System, but the detailed steps were purposely left unspecified until steering committee approval of a specific direction for the system. In logical design, a detailed and highly structured set of functional specifications for the system is produced and agreed to by all affected parties (end users, management, outside people and units that have to interact with the new system). Further, these specifications must be unambiguous for the programmers and other IS personnel who will be responsible for physical system design and programming, testing, and installation. Once these requirements are accepted, the subsequent physical design phase develops a technology architecture for the system and programs, computer files, and hardware.

The SDM calls for the development of four deliverables during logical design:

  1. Logical DFDs that show all aspects of the movement and processing of data in the new system and with its environment.
  2. Precise designs for all business forms, CRT displays, and printed reports--the system inputs and outputs with user-system interfaces. In addition, dialogue scripts are developed that outline the sequence of displays and messages presented to users during their interaction with the system.
  3. Specification of the logic necessary to transform inputs to a process into its outputs, including detailing decision rules and data validation standards.
  4. Detailed E-R diagrams and other structured data definitions with all data items associated with each identified entity or relationship.
As before, all of these deliverables will be produced with the assistance of the CASE tool, and all descriptions will be stored in the CASE tool's repository.

Chris and Juanita discuss several possible ways to gather the additional information requirements to develop these materials. They decide that the team will use two primary approaches:

  1. The project team will develop the detailed system description from information collected during the analysis phase and then conduct meetings with system users, called structured walkthroughs, to gain feedback on the logical system design.
  2. The project team will use prototyping with a 4th-generation programming language and code-generation capabilities of the CASE tool to iteratively develop and refine the CRT screens and report layouts. The generated code will give them a head start on the implementation phase since much of this can be used in the actual system.

From his experience, Chris knows that the logical design is the most crucial stage in systems development. If the project team does not get the requirements right based on the work done in the analysis and logical design phases, any subsequent costs to change the system's capabilities will grow exponentially the further the team gets into the project. On the other hand, Chris also knows from experience that there is no way they will get all the requirements defined, even using prototyping. Due to changing business conditions and the inherent complexity of any system, some elements will be missed entirely or will be inadequate. To deal with the inevitability of not getting all the requirements right in the early stages, Chris encourages the project team to design and build a system that can be easily changed. System maintainability can be accomplished by

From Chris's experience, it is not uncommon to find that 70 percent of a system's total life cost is spent on maintenance; in order to reduce the lifetime cost of the system, it is important to address system maintainability early in detailed design.

The logical specifications of the system are developed in stages. First, the known outputs and inputs of the system are studied. The outputs and inputs are identified from the DFDs as data flows from and to system users. Reports and displays are generated using CASE tool code generators and the report and computer form designer modules of PVF's database management system. These report and form designs are built with a sample database so that users can see sample output. Also, users can interact with the system by requesting on-demand reports and forms and can use prototypical versions of the buying model. Figure 7a shows a mock-up for one system output, the Price Quote report, as produced from the report generator of the database management system PVF uses for prototyping, Paradox for Windows. This report contains information about price quotes from all possible suppliers of selected items. Each item may have multiple vendors and each vendor may have several quotes for the same item, each for different order quantities. The vendor may have certain conditions or restrictions on each quote (for example, seasonal pricing). The report also notes overall experience comments for each vendor. Such report and form designs are reviewed with the relevant users and other interested parties. These parts of the system are iteratively built and rebuilt, using suggestions from users.

As the systems analysts finalize the report and form designs, the database analyst takes these designs and develops a logical data model for each. The notation used to describe the data in each system output and input is called the relational database model, a standard in the IS field. In this model, data is structured into relations that have desirable data maintenance properties. Figure 7b shows the three resulting relations (for now, you can think of a relation as a logical file) for the data in the report of Figure 7a. These three relations show all the data attributes as well as the entities and relationships of the required in the database to produce this report. The QUOTE relation links items with vendors. Since the CONDITIONS attribute can appear with each detail line in the report, this is a characteristic of a quote.

Relations developed from each Purchasing Fulfillment System input and output design are then combined into a comprehensive set of relations for the whole application. Finally, the conceptual entity-relationship diagram developed in the analysis phase is translated into relational form and compared to the logical data model relations. Differences between the logical and conceptual data models are reconciled and the relations are modified to include all of the anticipated data requirements from known system inputs and outputs as well as more general data about purchasing. It is this reconciled combined set of relations and accompanying entity-relationship data model that are referenced in subsequent system-building work on the Purchasing Fulfillment System. This combined data model is controlled by the data analyst, who also checks to make sure that this data model is consistent with other data models for Pine Valley databases.

As the team consisting of the database analyst, one systems analyst, and several users finalize the logical database design, other analysts and users work on designing the business processes to capture the needed data, including the design of business dialogues for interactions with system users during input and output processes. Dialogues are illustrated using a combination of sample displays and a tree indicating which displays are accessed from which other displays. Display mock-ups are developed from the form generator module of the database management system. Such mock-ups are similar to the sample report layouts illustrated in Figure 7a, so we do not illustrate a form for the Purchasing Fulfillment System.

The sample dialogue tree in Figure 8 shows the sequence of displays, which displays are accessed from which other displays, and what exit paths exist from each display. This dialogue tree is related to process 4.0 in Figure 4b, Select Preferred Supplier. That is, these displays contain data that support a purchasing manager in making the decision about a preferred supplier. This figure is read top-to-bottom with the initial display indicated by the top box. This structure is similar to a menu tree, which you may have seen for an electronic spreadsheet package or other software product. Each display has a numeric label and title. The label numbers are nested so that it is clear which displays are accessed from which other displays. The bottom row of numbers shows the displays the user may exit to form a particular display. Note in Figure 8 that the same display layout, Supplier Display, is accessed from two different displays but that the exit options vary depending on how the user gets to this display.

The analysts working on designing the processing steps also develop descriptions of the rules governing how data are processed and transformed. These rules help to guide those involved in physical design. Several forms of such documentation, including Structured English, are used. Structured English shows which input conditions produce different output. Logic documentation provided via structured English serves two purposes. First, such documentation is reviewed with users to verify that the systems analysts have accurately depicted the rules governing how data are processed. Second, this code-independent description of processing logic is essential for programmers who must write code to perform this logic. Since the particular programming language for the Purchasing Fulfillment System will be selected during the physical design phase of the project, the logic must be specified in a language-independent form for now. Figure 9 shows sample structured English used in the Select Preferred Supplier process. This logic is triggered from display 1.1.1 in Figure 8. The structured English statements indicate how a supplier can automatically be found for selected values entered by the user.

Although the total logical design phase takes eight weeks, Chris arranges for a second programmer to begin working with the team during the fifth week. He knows that as soon as specific parts of the logical design are finalized, work can begin on designing programs and computer files. Chris directs the database analyst and programmers to begin designing the data entry programs and the database. These programs handle the business transactions and populate the Purchasing Fulfillment System database. By running the logical and the physical design phases in parallel, Chris helps to shorten the overall systems development cycle.

Near the end of the logical design phase, Chris assigns one of the systems analysts to be in charge of overall system functional documentation. It is this systems analyst's job to develop training materials and user documentation from the charts, displays, reports, diagrams, and other project documentation. The CASE tool's repository, as well as structured and documented code, will comprise the bulk of the system documentation needed by programmers during maintenance. Chris knows that much of the user documentation cannot be finalized yet since some changes in the functional aspects of the system will occur in later phases as users gain more understanding of the system and tests pinpoint flaws in the design. Thus, there will be some backtracking from implementation to physical and even logical design in order to correct design flaws. However, it is best to start to pull the user documentation together now when the reason for certain system elements are fresh in the minds of project team members.

As in the past, Chris and Juanita keep the members of the project steering committee briefed on the project's progress. In addition, Sal Divario sits in on several of the sessions when the system design elements are reviewed with users. Greg Sinise meets with the database analyst and Chris to review the final entity-relationship diagrams and relations. Chris and Juanita meet once with the whole steering committee to discuss a suggestion made by Sal Divario that the team consider the alternative of acquiring a pre-written purchasing system from a leading software vendor instead of building the system. If this alternative is selected, the results of the logical design phase will be used as the requirements listed in a request for proposal (RFP) sent to prospective vendors. After some discussion, the steering committee agrees with Juanita's recommendation that the system should be developed in-house. Her reasons are as follows:

  1. The five-year IS plan called for the Purchasing Fulfillment System to be the foundation for electronically linking PVF with its suppliers and as such is to be eventually treated as a system with potential strategic value to PVF; in this case it will be necessary to have a proprietary system.
  2. The Purchasing Fulfillment System is not a stand-alone application. In fact, the systems analysis has revealed many interfaces to other existing systems. These interfaces will cause significant reprogramming of any purchased system, minimizing any advantages of acquiring an off-the-shelf package.
  3. The Purchasing Department is not in urgent need of a new system. Thus, they can wait for an in-house system to be developed and tested.

Because they have been involved throughout the logical design phase, the steering committee decides to wait for another complete project review until the end of the physical design phase, when the team will make another formal presentation to the Systems Priority Board. In fact, the Board and the steering committee will meet jointly at this project milestone. Stacy Morton assigns two more programmers to the project team for the next phase--physical design. She also sends a memorandum to several hardware and software specialists in the IS unit to request that they be available to assist the project team in making technology selections and system design decisions in the next phase. Using the talents of these programmers during physical design was suggested in the SDM.

Physical Design

Purpose: To develop all technology and organizational specifications for the new information system.
Deliverables: Program and database structures, technology purchases, physical site plans, and organization redesigns.


Physical design is the last step before the system is actually built. During physical design, the project team selects all the technology that will be used in the system and produces all the "blueprints" needed by the programmers and other people involved in building the system. In this phase, the team must decide on such physical characteristics for the system as the following:

Besides these computer system components, work in physical design specifies new facility layouts in the Purchasing Department offices to accommodate new work methods and computer equipment (including lighting, ventilation, and furniture). Testing procedures are established and test data generated. Also, since the system might redistribute work among purchasing agents and other PVF employees, the project team must address organizational and staffing changes as a probable consequence of the new system.

Juanita plays less of a role during physical design than she has played in prior stages, and she starts working on several parallel steps to get the team ready for the implementation phase. She develops a training plan and a system conversion and installation plan. The education plan specifies which people require what kinds of training or awareness education on the new system. Juanita's plan includes a schedule of news bulletins, seminars, and training sessions.

The conversion and installation plan addresses how to make a smooth transition from current operations to those required by the new system. This plan addresses how to switch from the old to the new system and how to deploy the Purchasing Department staff during this transition. It will be necessary not to disrupt department operations during the transition. As coordinating the transfer of data from current PVF files to the new database requires special timing, a database analyst works with Juanita. The final conversion and installation plan Juanita chooses is a type of single location or pilot approach, illustrated in the Gantt chart of Figure 10. This type of plan includes different organizational units in different phases. The first phase involves converting all the vendor data; the second phase converts data and systems for the wood materials items; and the final phase converts the data and systems for fastener items. This approach allows the project team to concentrate support with a few users at a time. This minimizes errors, isolates system start-up problems to a few users, and allows the team to refine conversion and installation methods as new user groups are incorporated.

The project team makes all the technology choices before designing any of the programs and chooses to use equipment and system software already approved by PVF for two reasons. First, the Purchasing Fulfillment System has no unique requirements that call for additional technology. Second, PVF has standard technology and a special request must be made to deviate from these standards. The chosen platform is Paradox for Windows and Sybase's SQL ServerTM database engine on PVF's local area network. Paradox for Windows will be used to build the front-end user interface modules, and the Sybase engine will handle all database management functions. SQL-Link will connect Paradox and SQL Server. This will be the first application at PVF using this combination of technologies, which is somewhat of a risk to the project team. The PVF IS plan calls for movement to the client/server network environment supported by these technologies and, after consulting with various stakeholders, the project team decides that this project is of an appropriate size and complexity to be a good first attempt to build a system within this new technology architecture. Several new PC workstations are needed in Purchasing and additional disk capacity is needed on the network server. An expert in computer capacity planning works with the team during this step to estimate processing volumes for the new system and the load this will place on the network and server.

An important step in physical design is the design of database structures. The database analyst refers to the relations developed in logical design. Although it is not always the most efficient method, the database analyst chooses to define a database file for each relation. The database analyst uses the CASE tool to automatically generate file descriptions in both Paradox and SQL (SQL is the database language understood by SQL Server) from information in the repository. The database analyst then reviews this generated database definition code and modifies some of the field types and lengths, indexes, and other database structures when it is believed more efficient choices can be made. Definitions in Paradox for three of the system files (ITEM, VENDOR, and QUOTE), those needed for the Price Quote Report of Figure 7, appear in Figure 11. The definition of each file shows the fields and for each, its data type, size (if appropriate), and whether the field has an index. Key fields are also indicated, a requirement of the relational database model. The project team decides that the whole database will be stored on the central file server on PVF's local area network so that all database functions are centralized in this one database managed by the SQL Server software. Since this network is not very busy and the transaction volume for the Purchasing Fulfillment System is not expected to be heavy, the team decides that all data capture programs will be on-line; as a result, no batch data input will be done. Some periodic reports will be built using SQL with SQL Server.

The specifics of all inputs and outputs, as well as a description of all processing steps, have been completely outlined in logical design in such documentation as computer form and report designs, dialogue charts, and Structured English. In physical design, all the processing steps are translated into diagrams or various forms of pseudocode, which resembles English and is one step short of actually writing in a programming language. Although some CASE tools can generate physical design diagrams and pseudocode from repository contents, PVF's tool only helps the team to develop this documentation, which it then stores in the repository. The team of system analysts, programmers, and other specialists involved in physical design use several forms of physical system documentation, including the following:

While the team finishes all of the physical system specifications, Chris and Juanita work on their presentation to the steering committee and Systems Priority Board. Their responsibility is to justify the physical design and to again convince these groups that the project work should continue. Now that more precise costs to build and operate the system can be estimated, the project team again has to justify the system. Chris takes responsibility for the costs to build and operate the system, and Juanita develops improved benefits projections.

PVF maintains data about the time required to develop its systems and Chris uses this history to estimate the programming costs for the Purchasing Fulfillment System. The physical system design shows the proposed system in enough detail that Chris is able to compare the characteristics of the new system to those previously developed at PVF. Chris uses an industry standard called function points, which measure units of programming work. The CASE tool is helpful since it is able to calculate the number of function points from the physical design specifications in its repository. Chris also produces estimates for the time needed to write documentation, to develop educational and training materials, to conduct training sessions, to handle the system conversion, and to purchase and maintain new equipment. These numbers go into developing a projected cash flow of one-time and recurring expenses for the new system, similar to those shown in Figure 6. Note that the cost of the project so far is not considered. Expenses already incurred are considered sunk costs and, at this point, are not pertinent to the go/no-go decision.

Juanita talks with the various end users in order to update the system benefits estimated earlier. She generates updated estimates for both expected and worst-case savings as well as new income figures. In addition, she refines the previously identified intangible benefits that cannot be factored into the financial analysis. Since most features of the Purchasing Fulfillment System support Purchasing operations, benefits are reasonably easy to quantify from time savings, error reductions, and improved decision-making support. A few system features are aimed more toward improved relationships with vendors and other factors that are more difficult to quantify, so these additional factors remain intangibles.

Juanita is in charge of the review meeting. This is a key decision that Chris and she have agreed to. The reason for Juanita taking the lead is to show that the project has been client-focused and that business needs, not technology, have driven the project. She leads off with a brief review of the project, including a comparison of the project plan with what has occurred. She uses the project Gantt and PERT charts to compare projected versus actual times and costs. She shows that the project to date is on time and within budget, which suggests that it has been well managed and feasible. This message is important in the request for project continuation.

Next, Juanita outlines the business case for continuing the development. The primary element of this business case is the updated financial cost and benefit analysis. In addition, she outlines some organizational changes necessary in order to derive the most benefit from the new system. These include upgrading some Purchasing positions, as higher skills will be required to use the new system, and restructuring the Purchasing staff. This restructuring will organize purchasing agents around supported manufacturing units rather than types of raw materials. The organization is a major intangible selling point for the new system because managers in manufacturing have been frustrated by having to work with so many different purchasing agents to get their materials.

Chris then reviews the essential logical and physical design features. Next, he outlines the timetable for the rest of the project, again using Gantt and PERT charts as in prior steps. He concludes with a request for the allocation of people with certain skills to work on the remaining stages of the project.

Juanita leads the meeting wrap-up. She quickly overviews the education and conversion plans to show that the project team has considered these important remaining elements. She also raises several project risks centering on possible resistance among some purchasing staff members and outlines how she intends to deal with these issues if they arise. Juanita closes the meeting by listing all the people who have contributed to the project, including all the people not on the project team who have participated in JAD sessions, have been interviewed, or have in any way contributed to the project team. This closing reveals the tremendous energy and intelligence behind the recommendations.

Most of the information in this presentation is not totally new to the steering committee and Systems Priority Board members. Both Juanita and Chris have informally met with most of these stakeholders prior to the meeting to review those parts of the presentation of most interest to each member. For example, Chris met with Stacy Morton and Greg Sinise to review the physical design specifications. Thus, after a 40-minute presentation and 20 minutes of questions, both the committee and Board approve the allocation of financial and human resources to complete the project.


As you might expect, many important steps remain before the Purchasing Fulfillment System begins operation. In this section, we quickly bring the description of the Purchasing Fulfillment System development project to a conclusion by limiting our presentation to highlights of the role of systems analysts in the remaining project phases.

The Implementation Phase

Implementation Phase

Purpose: To program the system, build all data files, test the new system, install system components, convert and cease operation of prior systems, train users, and turn over system to operations.
Deliverables: Programs that work accurately and to specifications, documentation, training materials, and project reviews.

As outlined in Chapter 1 of Modern Systems Analysis and Design, the implementation phase includes six subphases: coding, testing, installation, documentation, training, and support. Coding is performed by the programmers assigned to the project. Often, information systems development staff members with several years of experience perform both systems analyst and programmer functions. In this way the same people who designed the system program the system, which reduces the possibility of any misunderstandings. When different programmers perform each function (whether they are in-house programmers or outside contract programmers), analysts meet periodically with programmers to answer questions about the physical design specifications and to review programs for design compliance.

Analysts become more involved during testing. Testing is a multiple-step process crucial to the success of the system. Systems analysts develop the test data necessary to ensure that the programs handle all possible circumstances before testing begins (often as early as the analysis phase when special data maintenance conditions are identified). These test cases cover all valid and invalid input data so that all paths through programs are tested, if possible. The testing process can be aided by computerized testing software which repeatedly presents the same test cases to a program. This ensures that, as programmers create each version of a program (as bugs are fixed and new features added), the program goes through consistent and thorough testing. Analysts also generate test data to stress test the system. A high volume of input is presented to see whether the system breaks down as the database and intermediate files become very large, representing peak loads on the system. Although testing processes vary, systems analysts typically monitor the testing process through the point of user acceptance testing.

During system installation, project team members transfer data from old files to new files and databases, being careful to review old data to validate and correct the data before the data are loaded into the new system. Figure 10 shows a typical conversion schedule for a project. As mentioned earlier in this chapter, installation must be planned so that minimal disruption of the business occurs. Installation ends with the new system successfully operating in the organization.

In parallel to these other steps, all documentation--both for systems professionals and users--all training units, and all support procedures are designed and implemented. Many of these design activities were begun much earlier in the project, but they are finalized during implementation. Training for the Purchasing Fulfillment System includes units on how to enter data, how to interpret reports and displays, and how to override default decisions the system makes. The project team decided that the regular user consultants were sufficient to support this new system but that these consultants needed to be trained on the Purchasing Fulfillment System. They decided to establish a separate telephone number to call for assistance and created a newsletter to announce changes to the system, print user comments, and help the users network with each other.

Another major step in implementation is the close-down of the systems development project. In the case of the Purchasing Fulfillment System, this would involve the following steps:

It will be necessary, however, to monitor the new system closely for a while to ensure that the system actually works in live operation. After this follow-up period, the next phase begins--maintenance.


Purpose: To monitor the operation and usefulness of a system, to repair and enhance the system as required, and to determine when the system is obsolete.
Deliverables: Periodic audits of the system to demonstrate whether the system is accurate and still meets business needs.

The Maintenance Phase

Maintenance is the process of

Recoding to correct minor technical flaws and to make small changes (for example, to create a new report or improve display design) might require only programming skills. Sometimes additional systems analysis and design is necessary to analyze the current system along with the new information needs to determine changes affecting file design or the structure of the system. Any extensive changes require the skills of a systems analyst.

Various individuals can stimulate maintenance. Users might identify flaws and the need for enhancements and then submit a system change request, similar to the System Service Request which instigated the Purchasing Fulfillment System project. Data center staff might find processing errors or inefficiencies and submit a change request. System auditors might identify the need to fix more subtle flaws or to add data protection features like security controls or better system backup. Some organizations employ internal systems auditors who periodically check that systems perform as specified. A system audit might be done as part of an accounting audit by a public accounting firm.

The maintenance phase is typically the longest phase in the life of a system. Whereas the phases through implementation might require 3 to 12 months, maintenance can continue for years thereafter. Thus, most systems analysis and design work falls within the maintenance phase rather than the other life cycle phases. Maintenance is usually done in batches similar to new version releases of purchased software. Each major release is managed like a project, as we have seen in this supplement. Minor or interim releases may be managed more casually, but in some way all the steps (analysis, design, and implementation) must be carried out to ensure that new releases of a system meet specifications.


In this supplement we used a hypothetical example case to demonstrate some of the depth and texture of a systems analysis and design project. Our goal was to provide you with an overview of the topics within systems analysis and design, to help you anticipate issues you will confront as you work on projects during your systems analysis and design course, and to provide a basis for chapters in Modern Systems Analysis and Design.

The PVF case study showed the application of the systems development life cycle and some of the typical principles, such as incremental commitment and functional decomposition, that characterize modern systems development approaches. The systems development life cycle is a common framework that outlines a project from request for new services to the analysis of the current business situation, to identification of information requirements, to the design of the logical, technology-independent system, and ultimately to the design and implementation of the physical system. The life cycle allows for consistent management of projects and greater proficiency through the experience of project team members and proven techniques and tools. Each phase of the project reaches a specific milestone with specific deliverables. These deliverables or products become part of the system documentation and are input to subsequent project phases. We also briefly introduced a variety of typical documentation notations, such as data flow diagrams, entity-relationship diagrams, Structured English, and structure charts, all of which can be used to describe the functional and physical specifications of current or new information systems throughout the life cycle.

As part of this discussion we have highlighted the importance of a rigorous approach to project management including the strong need for project planning. We presented various charts, specifically Gantt and PERT, that are used to outline and monitor project progress. We also portrayed the roles of various people--from users to technicians to general managers--during different steps of systems development. In addition, we included glimpses of education, installation, and documentation as important elements of a systems development project.

This supplement also shows the very close working relationship between the lead systems analyst and lead user contact necessary for successful systems projects. We illustrated how Chris and Juanita anticipated issues, addressed needs in business, not technical, terms first, communicated the status of the project regularly and thoroughly to a variety of project stakeholders, planned meetings carefully, and performed many other tasks in a highly professional manner. Several questions at the end of the supplement ask you to discuss why Chris and Juanita were successful project leaders.

For brevity, we presented only a cursory overview of the systems implementation and maintenance phases of the systems development process. In Modern Systems Analysis and Design we describe in detail the management of programming, different kinds of system testing, alternative ways to switch from an old to a new system, and issues in the long-term maintenance of application software.

 C H A P T E R    R E V I E W


Business case
Context diagram
Data flow diagram
Functional decomposition
Incremental commitment
Systems development methodology


  1. Define each of the following terms:
    1. Gantt chart
    2. client
    3. funder
    4. end user
    5. maintenance
    6. installation
    7. entity-relationship diagram
    8. system service request
    9. steering committee
    10. test plan
    11. education (training)
    12. system audit
  2. What are the advantages of using a standard systems development methodology for all system projects in an organization?
  3. Outline the logic behind the incremental commitment philosophy applied in many structured systems analysis and design methodologies.
  4. Explain the purpose of the System Service Request as it is applied in Pine Valley Furniture.
  5. What was the role of the Systems Priority Board in Pine Valley Furniture? How was this role different from that of the project steering committee created for the Purchasing Fulfillment System?
  6. What is the purpose of a context diagram during early stages of systems analysis?
  7. What are the general contents of a business case to justify a systems project?
  8. Describe the steps necessary to initiate a systems project.


  1. Match the following terms to the appropriate definitions.
        entity-relationship diagram
        data repository
        structured walkthrough
        system flow chart
        structure chart
        action diagram
    a. map or diagram that shows a sequence of actions to be performed on a database
    b. iteratively building a working version of a system
    c. shows the hierarchical structure of a computer program, including messages
    d. database of a CASE tool that contains the definitions for all elements of a system description
    e. diagram of the entities and relationships between entities consistent with the rules and policies of an organization
    f. step-by-step discussion of documentation about a current or proposed system
    g. diagram of the flow of data between computer programs which also shows the computer equipment used within a system
  2. Discuss the skills or qualities you recognized in Juanita Lopez that made her a good end-user leader for a systems development project team.
  3. Discuss the skills or qualities you recognized in Chris Martin that made him a good systems analyst and project leader for a systems development project team.
  4. Discuss why you think Pine Valley Furniture used their systems development methodology as a guideline rather than as a fixed process from which systems development projects could not vary.
  5. Explain why it is important to separate logical design and physical design into two identifiable steps.
  6. Discuss the importance and role of the informal communication that occurs between systems development project leaders and stakeholders in the system; informal communication is that which occurs outside of formal project review meetings.
  7. Discuss the purpose of a written agenda distributed in advance of a project review meeting.
  8. Explain why it is important to get as many of the requirements for a new information system right during logical design rather than during later stages of systems development.
  9. Discuss why Chris Martin and Juanita Lopez assumed the roles they did during the review meeting at the end of the physical design phase.
  10. Discuss why Chris Martin wanted to spend so much time in the logical design phase for the Purchasing Fulfillment System project.
  11. Evaluate the System Service Request used at Pine Valley Furniture. What are its strengths and weaknesses? What improvements could be made to the form?


  1. Ask someone you know in the IS department of your university or other organization to provide you with a copy of the form used in his or her organization to request changes to a system or to create a new information system. How is this form different from the System Service Request format used in Pine Valley Furniture? If you discover that the organization does not have a form like the SSR, describe how new projects are requested. Design a rough draft of a form that might be used.
  2. Many organizations document their systems development life cycle in a manual that outlines each phase and step and who does what, which techniques are used, and what documentation must be produced. IS consulting companies are especially rigorous in outlining standard systems development processes. Through contacts in consulting companies (often a faculty member or student club officer can give you a name and phone number) or literature in your placement office, investigate the definition of the SDLC used by an IS consulting organization. How is this SDLC different from that used by Pine Valley Furniture?
  3. If your community has a local chapter of an IS professional organization (for example, AITP [Association of Information Technology Professionals]), find out when their meetings are and whether students are welcome to attend. If permitted, attend a meeting and, in conversations, ask chapter members to describe positive qualities in lead analysts and project leaders. Compare what you hear to the qualities demonstrated by Chris Martin in this chapter.
  4. Almost any new idea that requires funding in an organization, whether it be a new product, an organizational change, the construction of a new facility, or whatever, requires those proposing the idea to make the business case for the innovation. Find an example business case (from someone you know in an organization or possibly from another business course you have taken) and summarize the essential features of this business case. Compared to this business case, was the one made for the Purchasing Fulfillment System insufficient in any way?
  5. Interview someone who has been involved in the development of a moderate-to-large-sized information system. If you have been involved in such a development project, use your own example for this exercise. In what capacity and in what ways was this person involved in the project? Does his or her involvement resemble that of any of the people in the Pine Valley Furniture project? If so, whom and in what ways? In what ways did the development process for this person's project resemble that used for the Pine Valley Furniture project? How did it differ? Does this person consider the development project he or she was involved in to be a success? Why or why not? Does this person consider the personal development experience that took place to be positive, negative, or neutral? Why?

Back to the suppliment index

1999 Prentice-Hall, Inc., A division of Pearson Education, Upper Saddle River, New Jersey 07458 Legal Statement
Comments should be directed to