Radical Methods for Determining System Requirements

Radical Methods for Determining System Requirements

Whether traditional or modern, the methods for determining system requirements that you have read about in this chapter apply to any requirements determination effort, regardless of its motivation. Yet, most of what you have learned has traditionally been applied to systems development projects that involve automating existing processes. Analysts use system requirements determination to understand current problems and opportunities, as well as what is needed and desired in future systems. Typically, the current way of doing things has a large impact on the new system. In some organizations, though, management is looking for new ways to perform current tasks. These ways may be radically different from how things are done now, but the payoffs may be enormous: Fewer people may be needed to do the same work; relationships with customers may improve dramatically; and processes may become much more efficient and effective, all of which can result in increased profits. The overall process by which current methods are replaced with radically new methods is referred to as business process reengineering (BPR).?

To better understand BPR, consider the following analogy. Suppose you are a successful European golfer who has tuned your game to fit the style of golf courses and weather in Europe. You have learned how to control the flight of the ball in heavy winds, roll the ball on wide-open greens, putt on large and undulating greens, and aim at a target without the aid of the landscaping common on North American courses. When you come to the United States to make your fortune on the U.S. tour, you discover that improving your putting, driving accuracy, and sand shots will help, but the new competitive environment is simply not suited to your playing style. You need to reengineer your whole approach, learning how to aim at targets, spin and stop a ball on the green, and manage the distractions of crowds and press. If you are good enough, you may survive, but without reengineering, you will never become a winner. Just as the competitiveness of golf forces good players to adapt their games to changing conditions, the competitiveness of our global economy has driven most companies into a mode of continuously improving the quality of their products and services. Organizations realize that creatively using information technologies can significantly improve most business processes. The idea behind BPR is not just to improve each business process but, in a systemsmodeling sense, to reorganize the complete flow of data in major sections of an organization to eliminate unnecessary steps, combine previously separate steps, and become more responsive to future changes. Companies such as IBM, Procter & Gamble, Wal-Mart, and Ford have had great success in actively pursuing BPR efforts. Yet, many other companies have found difficulty in applying BPR principles. Nonetheless, BPR concepts are actively applied in both corporate strategic planning and information systems planning as a way to improve business processes radically (as described in Chapter 6).

BPR advocates suggest that radical increases in the quality of business processes can be achieved through creatively applying information technologies. BPR advocates also suggest that radical improvement cannot be achieved by making minor changes in existing processes but rather by using a clean sheet of paper and asking, “If we were a new organization, how would we accomplish this activity?” Changing the way work is performed also changes the way information is shared and stored, which means that the results of many BPR efforts are the development of information system maintenance requests, or requests for system replacement. You likely have encountered or will encounter BPR initiatives in your own organization. A recent survey of IS executives found that they view BPR to be a top IS priority for the coming years.V

Topics You May Be Interested In
Real Time And Distributed System Security
Qualifications And Responsibilities Of System Analyst Constructing A Gantt Chart And Network Diagram At Pine Valley Furniture-representing And Scheduling Project Plans
What Is Information Systems Analysis And Design? Initiating And Planning Systems Development Projects
Trends In Distributed Systems Modern Methods For Determining System Requirements
Mobile And Ubiquitous Computing Pine Valley Furniture Webstore: Determining System Requirements

Identifying Processes to Reengineer

A first step in any BPR effort is to understand what processes need to change, what are the key business processes for the organization. Key business processes are the structured set of measurable activities designed to produce a specific output for a particular customer or market. The important aspect of this definition is that key processes are focused on some type of organizational outcome such as the creation of a product or the delivery of a service. Key business processes are also customer focused. In other words, key business processes would include all activities used to design, build, deliver, support, and service a particular product for a particular customer. BPR, therefore, requires you first to understand those activities that are part of the organization’s key business processes and then to alter the sequence and structure of activities to achieve radical improvements in speed, quality, and customer satisfaction. The same techniques you learned to use for system requirements determination can be applied to discovering and understanding key business processes: interviewing key individuals, observing activities, reading and studying organizational documents, and conducting JAD sessions.

After identifying key business processes, the next step is to identify specific activities that can be radically improved through reengineering. Michael Hammer and James Champy, two academics who coined the term BPR, suggest systems analysts ask three questions to identify activities for radical change:

1. How important is the activity to delivering an outcome?

Topics You May Be Interested In
Systems Models Types Of Models - Systems Environment And Boundaries Failure Handling
Feasibility Study And Its Importance System Models
Scope And Classification Of Metrics Examples Of Distributed Systems
Financial Trading Outsourcing-systems Acquisition
Trends In Distributed Systems Radical Methods For Determining System Requirements

2. How feasible is changing the activity?

3. How dysfunctional is the activity?

The answers to these questions provide guidance for selecting which activities to change. Those activities deemed important, changeable, yet dysfunctional, are primary candidates for alteration. To identify dysfunctional activities, Hammer and Champy suggest you look for activities that involve excessive information exchanges between individuals, information that is redundantly recorded or needs to be rekeyed, excessive inventory buffers or inspections, and a lot of rework or complexity. An example of a dysfunctional process and how BPR is used to change it is presented at the end of Chapter 6.

Disruptive Technologies

Topics You May Be Interested In
System Definition And Concepts | Characteristics And Types Of System Architectural Elements
Cost-benefit And Analysis -tools And Techniques Representing And Scheduling Project Plans
Scope And Classification Of Metrics Using Project Management Software
Mobile And Ubiquitous Computing Establishing A Project Starting Date-using Project Management Software
System Models Initiating And Planning Systems Development Projects

Once key business processes and activities have been identified, information technologies must be applied to improve business processes radically. Hammer and Champy suggest that organizations think “inductively” about information technology. Induction is the process of reasoning from the specific to the general, which means that managers must learn about the power of new technologies and think of innovative ways to alter the way work is done. This approach is contrary to deductive thinking, in which problems are first identified and solutions then formulated. Hammer and Champy suggest that managers especially consider disruptive technologies when applying deductive thinking. Disruptive technologies are those that enable the breaking of long-held business rules that inhibit organizations from making radical business changes. For example, Toyota is using production schedule databases and electronic data interchange (EDI)—an information system that allows companies to link their computers directly to suppliers—to work with its suppliers as if they and Saturn were one company. Suppliers do not wait until Saturn sends them a purchase order for more parts but simply monitor inventory levels and automatically send shipments as needed. Table 5-5 shows several long-held business rules and beliefs that constrain organizations from making radical process improvements. For example, the first rule suggests that information can appear in only one place at a time. However, the advent of distributed databases, which allow business units to share a common database, has “disrupted” this long-held business belief.

TABLE 5-5: Long-Held Organizational Rules That Are Being Eliminated through Disruptive Technologies

Radical Methods for Determining System Requirements


Topics You May Be Interested In
Basic Principles Of Successful System Case Study: The World Wide Web
Direct And Indirect Measures, Reliability Physical Models
Characterization Of Distributed Systems Sources Of Software-systems Acquisition
Concurrency Establishing A Project Starting Date-using Project Management Software
Transparency Performing Requirements Determination


Frequently Asked Questions

Ans: Even though we called interviews, questionnaires, observation, and document analysis traditional methods for determining a system’s requirements, all of these methods are still used by analysts to collect important information. view more..
Ans: Collection of information is at the core of systems analysis. view more..
Ans: In the last chapter, you read how Pine Valley Furniture’s management began the WebStore project—to sell furniture products over the Internet. view more..
Ans: Whether traditional or modern, the methods for determining system requirements that you have read about in this chapter apply to any requirements determination effort, regardless of its motivation. view more..
Ans: Process modeling involves graphically representing the processes, or actions, that capture, manipulate, store, and distribute data between a system and its environment and among components within a system. view more..
Ans: Data-flow diagrams are versatile diagramming tools. view more..
Ans: Sofware engineering syllabus The course of the program is designed in an exceedingly manner that it covers all the aspects of software system engineering needed for higher understanding of the scholars. The delivery methodology of the program is usually schoolroom lectures Associate in Nursing sensible laboratory sessions beside seminars and internships being an integral a part of the course. BE/B.Tech software system Engineering give students data of evaluating the correct codes and software system for specific tasks. view more..
Ans: The first published model of software development process was derived from more general system engineering processes. Because of the cascade from one phase to another, this model is known as the waterfall model or software life cycle. The principal stages of the model map onto fundamental development activities: view more..
Ans: System prototyping performs the analysis, design, and implementation phases concurrently in order to quickly develop a simplified version of the proposed system and give it to the users for evaluation and feedback. view more..
Ans: Software is defined as collection of data, programs, procedures, associated documentaion and rules. which does not have any mass, volume and colour. software does not wear out,get tired or degrade over a long period of time view more..

Recommended Posts:

Rating - NAN/5