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
|These Topics Are Also In Your Syllabus|
|1||Case study: The World Wide Web||link|
|You May Find Something Very Interesting Here.||link|
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
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.
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.