 | Team-Fly  | |
 | Requirements Analysis: From Business Views to Architecture
By David C. Hay
| | Table of Contents | | | | Chapter 2. Managing Projects |
Process Six: Determine the Existing Systems Environment As stated above, the set of current systems should not define the requirements for systems in an organization. The requirements analysis phase should be carried out independent of technology. The assignment here is to determine what data and processing a business requires to carry out its objectives. Once these requirements have been stated, then the design phase can apply technology to these requirements. Still, to the extent that systems usually constitute an important part of the business owners ' views of their current environment, it is useful to know just what exists presently and the roles of various systems in the way the enterprise's business is carried out. Moreover, it is important to document the existing systems environment. This knowledge can provide useful insights in preparing the models described above, and it is important during transition when the time comes to move from the existing systems environment to a new one. Because the skills required for conducting this kind of research are different from those used to model the business, this Process can be done by a separate team in parallel with and at the same time as other Processes in the requirements analysis project. This process is one of making sure we understand not just what systems exist and what they do, but also the operating environment, -
The physical architecture, -
The technical architecture, -
Operating procedures, and -
Capacity. Specifically, it involves the following steps: Step 1: Define Operating Environment What is the overall environment? A centralized mainframe? The World Wide Web? Hundreds of independent personal computers? A "client/server" network? This environment provides a context for the entire system development project. And of course there is the accompanying question, "How would this environment change with the advent of new systems"? Step 2: Identify Software Environment What software (purchased or developed inhouse) is currently in place? Specifically this step consists of identifying the following: -
Database management systems : Does the company have a single database management system or several? How compatible are they? How many people are conversant with each? -
Applications software : This is the big one. An inventory of all systems developed within the company may well be beyond the resources of any particular project. With luck, the Y2K project back in 1999 produced some sort of inventory that can be drawn upon. At the very least, however, it is important to know the principal systems that are used in the area of interest to this particular requirements project. A good source of information is the set of current physical data flow or process flow diagrams. These present the information used by each process and should also indicate the source (human or technological) of that information. In general, this research should also include determining who uses the software, although this may not be easy for something disseminated via the World Wide Web. What packages has the company purchased? Which departments maintain and use each? What functional areas and what parts of the data model are addressed? What systems have been developed inhouse? Because of the informal nature of many inhouse projects, the boundaries may not be as clear for these systems as for those purchased from an outside vendor. Still, it is important to at least document them and their purposes and to describe their scope as best you can. Task 1: Identify Development Tools What sort of CASE and other development tools will be used to support this effort? What kinds of query tools, data-transportation software, and fourth-generation languages are available? These are not the applications that will do the work to meet the objectives of the project. Rather they are tools to be used by developers to create such applications. -
System data structures : What are the actual files that exist to hold the company's information? What systems are they part of? How valid are the data contained in them? What will be required to clean up the data and move them into the structures envisioned by the data model? -
 Current software standards : Does the enterprise already have in place standards for data definition, program structure, documentation, and so forth? What are they? To what extent are they currently enforced? Should they be re-evaluated? Step 3: Define Technological Architecture This is all about describing the kinds of technology that now exist and how they are connected to each other. -
Hardware, including processors and networks (including current hardware standards) : This includes everything from mainframes and other servers to personal computers on employees ' desks. It also includes the web servers and other computers that run various networks and perform less visible tasks . -
Network protocols and the like : What is the nature of the enterprise's networks? This includes local area and wide area networks, intranets , and so forth. Document the existence of each, along with its protocols, extent, and other technological characteristics. -
Systems software : What operating systems are in use? What kinds of applications are run under each? How are they interconnected ? There may be more now than in the 1970s but, with luck, fewer than were in use in the 1990s. Step 4: Define Operational Procedures What is the operating environment of the systems? This involves: -
System processes : For batch jobs, how are the various program runs organized? For interactive systems, how are the various users linked together? What preconditions exist for each? That is, in order for Samantha to enter a transaction, must Charlie have done something first? Much of this will be revealed by the process flow and/or data flow diagrams, but here we are looking for more specific information about what components of various systems are involved. -
System data communications (interfaces) : Data pass from one software application to another. In what form? How frequently? Step 5: Identify Existing Capacity How much processing capacity and disk space is available (or can be made available) for this project? Below we discuss determining capacity requirements. What capacity can be drawn upon, and what approaches are available for acquiring more? Step 6: Deliverable: System Inventory The steps in this process will result in reports and lists of various kinds. These will provide the basis for planning further development phases. |
