Performing Requirements Determination




Performing Requirements Determination

As stated earlier and shown in Figure 5-1, the two parts to systems analysis are determining requirements and structuring requirements. We address these as two separate steps, but you should consider these steps as somewhat parallel and repetitive. For example, as you determine some aspects of the current and desired system(s), you begin to structure these requirements or to build prototypes to show users how a system might behave. Inconsistencies and deficiencies discovered through structuring and prototyping lead you to explore further the operation of the current system(s) and the future needs of the organization. Eventually your ideas and discoveries meet on a thorough and accurate depiction of current operations and the requirements for the new system. In the next section, we discuss how to begin the requirements determination process.

The Process of Determining Requirements

At the end of the systems planning and selection phase of the SDLC, management can grant permission to pursue development of a new system. A project is initiated and planned (as described in Chapter 4), and you begin determining what the new system should do. During requirements determination, you and other analysts gather information on what the system should do from as many sources as possible. Such sources include users of the current system, reports, forms, and procedures. All of the system requirements are carefully documented and made ready for structuring. Structuring means taking the system requirements you find during requirements determination and ordering them into tables, diagrams, and other formats that make them easier to translate into technical system specifications. We discuss structuring in detail in Chapters 6 and 7. In many ways, gathering system requirements is like conducting any investigation. Have you read any of the Sherlock Holmes or similar mystery stories? Do you enjoy solving puzzles? The characteristics you need to enjoy solving mysteries and puzzles are the same ones you need to be a good systems analyst during requirements determination. These characteristics include:

  • Impertinence: You should question everything. Ask such questions as “Are all transactions processed the same way?” “Could anyone be charged something other than the standard price?” “Might we someday want to allow and encourage employees to work for more than one department?”
  • Impartiality: Your role is to find the best solution to a business problem or opportunity. It is not, for example, to find a way to justify the purchase of new hardware or to insist on incorporating what users think they want into the new system requirements. You must consider issues raised by all parties and try to find the best organizational solution.
  • Relaxing of constraints: Assume anything is possible and eliminate the infeasible. For example, do not accept this statement: “We’ve always done it that way, so we have to continue the practice.” Traditions are different from rules and policies. Traditions probably started for a good reason, but as the organization and its environment change, they may turn into habits rather than sensible procedures.
  • Attention to details: Every fact must fit with every other fact. One element out of place means that the ultimate system will fail at some time. For example, an imprecise definition of who a customer is may mean that you purge customer data when a customer has no active orders; yet these past customers may be vital contacts for future sales.
  • Reframing: Analysis is, in part, a creative process. You must challenge yourself to look at the organization in new ways. Consider how each user views his or her requirements. Be careful not to jump to this conclusion: “I worked on a system like that once—this new system must work the same way as the one I built before.”

Deliverables and Outcomes

The primary deliverables from requirements determination are the types of information gathered during the determination process. The information can take many forms: transcripts of interviews; notes from observation and analysis of documents; sets of forms, reports, job descriptions, and other documents; and computer-generated output such as system prototypes. In short, anything that the analysis team collects as part of determining system requirements is included in these deliverables. Table 5-1 lists examples of some specific information that might be gathered at this time. The deliverables summarized in Table 5-1 contain the information you need for systems analysis. In addition, you need to understand the following components of an organization:

  • The business objectives that drive what and how work is done
  • The information people need to do their jobs
  • The data handled within the organization to support the jobs
  • When, how, and by whom or what the data are moved, transformed, and stored
  • The sequence and other dependencies among different data-handling activities
  • The rules governing how data are handled and processed
  • Policies and guidelines that describe the nature of the business, the market, and the environment in which it operates
  • Key events affecting data values and when these events occur

TABLE 5-1: Deliverables for Requirements Determination

Performing Requirements Determination

Such a large amount of information must be organized in order to be useful, which is the purpose of the next part of systems analysis—requirements structuring.

Requirements Structuring

The amount of information gathered during requirements determination could be huge, especially if the scope of the system under development is broad. The time required to collect and structure a great deal of information can be extensive and, because it involves so much human effort, quite expensive. Too much analysis is not productive, and the term analysis paralysis has been coined to describe a project that has become bogged down in an abundance of analysis work. Because of the dangers of excessive analysis, today’s systems analysts focus more on the system to be developed than on the current system. Later in the chapter, you learn about joint application design (JAD) and prototyping, techniques developed to keep the analysis effort at a minimum yet still be effective. Other processes have been developed to limit the analysis effort even more, providing an alternative to the SDLC. Many of these are included under the name of Agile Methodologies (see Appendix B). Before you can fully appreciate alternative approaches, you need to learn traditional fact-gathering techniques.



Frequently Asked Questions

+
Ans: Most businesses have discovered the power of Internet-based electronic commerce as a means to communicate efficiently with customers and to extend their marketing reach. view more..
+
Ans: All the information collected during project initiation and planning is collected and organized into a document called the baseline project plan. view more..
+
Ans: Most information systems projects have budgets and deadlines. view more..
+
Ans: As stated earlier and shown in Figure 5-1, the two parts to systems analysis are determining requirements and structuring requirements. view more..
+
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: 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: 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: Collection of information is at the core of systems analysis. view more..
+
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: 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 - 3/5
520 views

Advertisements