Before we look at systems analysis methodologies, we must first consider one very important factor: A new system, or modifications to an existing system, may represent a significant change in the work environment, something we humans usually do not accept easily. We tend to become comfortable in the way we operate, and change creates some level of discomfort (how uneasy, of course, depends on the individual).

Even the best-designed and -implemented information system will be useless if users don't accept it. This means that as well as determining the organization's data management needs, those in charge of system change must be very sensitive to how users react to modifications.

The simplest way to handle resistance to change is to understand that if people have a stake in the change, then they will be personally invested in seeing that the change succeeds. Many of the needs assessment techniques that you read about in this chapter can foster that type of involvement. Ask the users what they need, and then really listen to what they are saying. Show the users how you are implementing what they need. For those requests that you can't satisfy, explain why they aren't feasible. Users who feel that they matter, that their input is valued, are far more likely to support procedural changes that may accompany a new information system.

The are a number of theoretical models for managing change, including the following: ¹

The classic method for developing an information system is known as the structured design life cycle. It works best in environments where it is possible to specify the requirements before the system is developed because they are fairly well known. Typically, the process includes the following activities:

The reason the preceding process is called a “cycle” is that when you finish Step 7, you go right back to Step 1 to modify the system to handle any problems identified in the evaluation (see Figure 2-1). If no problems were found during the evaluation, then you wait awhile and evaluate again. However, the process is also sometimes called the waterfall method because the project falls from one step to another, like the waterfall in Figure 2-2. Database designers are typically involved in Steps 1 through 5. The database design itself takes place during Step 5, but that process cannot occur until the preceding steps are completed.

Many systems analysts believe that the needs assessment is the most important part of the systems development process. No matter how well developed, even the best information system is useless if it doesn't meet the needs of its organization. A system that isn't used is just a waste of money.

A systems analyst has many tools and techniques available to help identify the needs of a new or modified information system, including:

Sometimes a systems analyst will discover that what actually occurs isn't what is supposed to be standard operating procedure. If there is a difference between what is occurring and the way in which things “should” happen, then either employee behavior will need to change or procedures will need to change to match employee behavior. It's not the systems analyst's job to make the choice but only to document what is occurring and to present alternative solutions.

Occasionally observations and interviews can expose informal processes that may or may not be relevant to a new system. Consider what happened to a systems analyst who was working on a team that was developing an automated system for a large metropolitan library system. (This story is based on an incident that actually occurred in the 1980s.) The analyst was assigned to interview staff of the mobile services branch, the group that provided bookmobiles as well as individualized service to housebound patrons. The process in question was book selection and ordering.

Here's how it was supposed to happen: Each week, the branch received a copy of a publication called Publishers Weekly. This magazine, which is still available, not only documents the publishing trade but also lists and reviews forthcoming media (primarily books). The librarians (four adult librarians and one children's librarian) were to go through the magazine and place a check mark next to each book the branch should order. Once a month, the branch librarian was to take the marked-up magazine to the central order meeting with all the other branch librarians in the system. All books with three or more checks were to be ordered, although the branch librarian was to exercise her own judgment and knowledge of the branch patrons to help make appropriate choices.

The preceding is what the systems analyst heard from the branch librarian. The five librarians, however, told a different story. At one point they concluded that the branch librarian wasn't exercising any judgment at all but was simply ordering all books with three checks. There was only one children's librarian, and therefore children's books almost never received three checks. Few children's books were being ordered.

To test their theory, the librarians placed four check marks next to a significantly inappropriate title—a coffee table book that was too heavy for many of their elderly patrons to handle and that exceeded the branch's price limit—and waited to see what happened. The coffee table book was ordered, so they thought that no professional judgment was being used at the order meeting.

The librarians therefore took the situation into their own hands. When the branch librarian returned from the order meeting, she gave the copy of the Publishers Weekly to one of the clerks, who created cards for each ordered book. The cards were to be matched to the new books when they arrived. However, the librarians arranged for the clerk to let them see the cards as soon as they were made. The librarians removed books that shouldn't be ordered and added those that had been omitted (primarily children's books). The clerk then phoned the changes to the order department.

What should the analyst have done? The process was clearly broken, and it appeared that the branch librarian wasn't doing her job. The librarians had arranged things so the branch functioned well, but they were circumventing SOP and were probably putting their jobs in jeopardy by doing so. This was a case of “the end justifies the means.” No one was being harmed, and the branch patrons were being helped. How should the analyst have reported her findings? Should she have exposed what was really happening, or should she simply have documented how the procedure was supposed to work? What would happen when the ordering process was automated and there were no longer any centralized order meetings? There would be no order cards held at the branch and no opportunity for the librarians to correct the book order.

This was a very delicate situation because if it were exposed, either the branch librarian or the other librarians (or both) would face significant problems. A systems analyst's job is to observe, interview, and record, not to intervene in employee relations. The book-ordering process would be changing anyway with an automated system. If the librarians had to continue to work around the branch librarian, they would need to change their informal process as well. Therefore, the best strategy for the analyst probably was to remove herself from the personnel problems and report the process as it was supposed to work.

In cases where informal procedures do not violate SOP, an analyst can feel free to report what is actually occurring. This will help in tailoring the new information system to the way in which the business actually operates.

A focus group can be a double-edged sword. The members of the focus group are not privy to many of the constraints under which a business operates and the limitations of technology. Their suggestions may be impractical. The analyst conducting the focus session needs to be careful not to make promises to group members that can't be kept. Participants in a focus group can have their expectations raised so high that those expectations can never be met, creating disappointment and disaffection with the business.

The results of the needs assessment are collected into a requirements document. At this point in the process, the needs identified by the analyst are expressed in general terms. For example, the requirements document might include a call for a new Web site shopping cart that allowed users to check out on one page rather than three. The fact that the redesigned Web page needs to include the customer's area code as a separate piece of data isn't documented at this point.

Once the operational requirements of a new system have been documented, the systems analyst turns to assessing the feasibility of the required system. There are three types of feasibility that systems analysts consider:

Operational feasibility looks at whether it makes sense for the company to change any part of its operating procedures to accommodate a new system. If payroll employees currently enter data from time cards by hand, a change to a machine-readable system is operationally feasible. The procedure for entering hours worked changes slightly, but the employees will still use some sort of time card, and payroll employees will still be processing the data. In contrast, consider the situation where a new system would require all purchase requisitions to be placed using an online form. However, some offices in remote locations do not have Internet access, so it is not feasible to shut down paper-based requisitions entirely.

Operational feasibility also relies to a large extent on an organization's and its employees’ willingness to change. Assume, for example, that insurance company representatives currently fill out paper forms when making a sale at a customer's home. The company would like to replace the paper with laptops that use wireless connections to exchange data with the home office. Certainly, this is a reasonable choice given the way in which the company operates, but if many of the salespeople are resistant to working with a laptop, then a project to introduce the laptops may fail. Sometimes the introduction of new technology, especially in a manufacturing environment, is crucial to maintaining a company's competitive position and therefore its ability to stay in business. Employees who are resistant to the new technology (either unwilling or unable to be retrained) may need to be laid off to ensure that the company survives.

Technological feasibility is relatively easy to assess. Can the necessary technology be purchased? If not, is it possible to develop that technology in a reasonable amount of time and at a reasonable cost? Consider, for example, the situation of a rural library cooperative in the mid-1980s. Most library information systems used minicomputers. However, the rural cooperative was interested in a client/server architecture with small servers at each library. Before proceeding, the cooperative needed to determine whether such a system actually existed or whether one was soon to become available. ²

Financial feasibility means asking the question “Can we afford it?” Often the answer is “We can't afford not to do it.” In such a situation, an organization will spend as much as it can to implement a new information system.

Because no specific system alternative has been selected at this point, financial feasibility assessment is often very general. It can be conducted in-house, or an outside firm can be hired to conduct the analysis. The analysis includes market research to describe the market, its size, and typical customers as well as competition in the marketplace. From those data the analyst can estimate demand for the company's product and generate an estimate of revenue. In addition to hardware and software costs, the cost estimates include facility expenses (rental, construction, and so on), financing (loan costs), and personnel expenses (hiring, training, salaries, and so on). The result is a projection of how a new information system will affect the bottom line of the company. As with the needs assessment, the results of the feasibility analysis are presented as part of the requirements document.

One thing to keep in mind during a feasibility analysis is that the systems analyst—whether an employee of the company contemplating a new system or an employee of an outside firm hired specifically to conduct the analysis—will not be making the decision as to whether an entire project will proceed. The decision is made by the organization's management.

The third section in the system requirements document is a list of two or more system design alternatives for an organization to consider. Often they will be distinguished by cost (low cost, medium cost, and high cost). However, the first alternative is almost always “Do nothing; keep the current system.”

A low-cost alternative generally takes advantage of as much existing facilities, hardware, and software as possible. It may rely more on changing employee behavior than installing new technology.

A moderate-cost alternative includes some new hardware and software purchases, some network modification, and some changes in employee behavior. It may not, however, include the top-of-the-line hardware or software. It may also use off-the-shelf software packages rather than custom-programmed applications. Employee training may include sending users to take classes offered by hardware and software vendors.

The high-cost solution usually includes the best of everything. Hardware and software are top-of-the-line and include a significant amount of excess capacity. Custom programming is included where appropriate. Employee training includes on-site seminars tailored specifically to the organization.

Evaluating alternatives involves assigning numeric values to the costs and the benefits of each alternative. Some costs are easy to quantify, especially the cost of hardware and prepackaged software. Labor can be estimated relatively accurately as well. However, assigning dollar values to the benefits of a systems development project can be difficult because they are often intangible. For example, when a system is being designed to generate an increase in sales volume, the amount of increase is by its very nature an estimate. Increased customer satisfaction and better employee attitudes are difficult to measure. The impacts on system maintenance costs and future system development costs are at best only estimates.

The analyst completes the requirements document by adding the cost/benefit analyses of the proposed alternatives and then presents it to company management. Although the requirements document typically includes specific groups of hardware, software, and labor for each alternative, management may decide to use part of one alternative (for example, existing hardware) and part of another (for example, custom-written application programs).

Once company management agrees to the project and its specifications, the requirements document can become a contract between IT and management, defining what IT will provide and what management should expect. The more seriously all parties view the document as a contract, the more likely the system development project is to succeed.

The alternative chosen by an organization is usually expressed as a general strategy such as “Implement a new Web site backed by an inventory database.” Although many of the exact requirements of the database were collected during the systems analysis phase of the life cycle, company management doesn't really care about the details of which specific data will be in the database. The system that they chose has been specified as a series of outputs, the details of which may not have been designed yet.

Therefore, the first job in the design phase is to document exactly what data should be in the database and the details of application programs. This is the time when user interfaces are designed and an organization begins to build its data dictionary. Once the data specifications are in place, actual database design can begin.

As mentioned at the beginning of this chapter, the structured design life cycle works best when the requirements of an information system can be specified before development of the system begins. However, that is not always possible. In some cases, users need the system developer to produce something to which they can react. They may not be able to articulate their needs in the abstract, but they can indicate whether an existing piece of software works for them, and if it does not, how the software should be changed to better meet their needs.