This type of analysis reflects a "bill-of-material" philosophy. In other words, if one part is changed, what other parts will feel its effect? "Impact Analysis" is a natural part of an IRM Repository and should be used to perform this type of analysis. Based on the "Impact Analysis" Project Management can then determine what pertinent ISEM phases and activities are required to implement the change. When this has been done, an Order-of-Magnitude estimate and schedule can then be calculated for review.

Before proceeding with the project, the Project Scope and estimates/schedules are reviewed with the user sponsor(s). It is important that the Project Manager and the users have consensus in terms of the work to be performed, the approach, and anticipated estimated time/costs/schedule. This is true regardless of the type of work effort. If it is new development, the estimate may only reflect a Detail estimate/ schedule for the remaining activities of Phase 1. If it is mod/imp related, the estimate may reflect an Order-of-Magnitude estimate/schedule for the entire project.  

CURRENT SYSTEM ANALYSIS

The subject of current systems analysis is usually greeted with dismay or disdain by systems departments. There are many reasons for this. In many installations, the support of current systems takes more than 85% of the systems department's time, and the departments are more than ready to get on with new systems development and bury the old, non-working systems as quickly as possible. In cases where systems do not require a lot of maintenance, the systems department may find that the current systems are not giving management the kind of information it needs for effective decision making; these current systems become likely candidates for replacement.

However, there are some very legitimate reasons for documenting existing systems:

1. The documentation process will make development personnel more knowledgeable about the enterprise's business. Users often complain that the systems people are ignorant or naive about the business, and usually there is some justification in this complaint. The process of capturing current systems in ISEM will educate Systems Engineers in the business of the company.

2. Documenting current systems will clearly show:

   • What information is being produced.

   • Who is using the information and how (functions, jobs, resources).

   • What data resources are being used (data, records, files, inputs, outputs).

   • What processing is being executed, and what is not.

     Quite often, user personnel do not use existing systems simply because they do not understand the purpose of the system or how it is to be used. If a system has been properly documented, perhaps only a few modifications are required as opposed to a major new application development effort. Unless we understand clearly what the old system is doing, how can we design a new system to replace the old? How can we plan the conversion from the old to the new? Most of the current system contains resources that will be re-usable for the new system. Data, records, files, inputs, outputs - most, if not all of these can be re-used in systems development.

     Weaknesses and misusage of current systems will also be uncovered. Because of inadequate documentation, it is not unusual to see a good system be misinterpreted by users, including DP Operations. As a consequence, the system is only partially utilized and the benefits not fully realized.

3. Programs and files which only serve the purpose of unnecessarily occupying computer storage space can be identified and removed.

Degree of Definition

Capturing current systems can be a huge undertaking. A single company can have hundreds of systems and sub-systems, and thousands of procedures and programs, some of which are very old. It is important to remember that the intent here is to ONLY IDENTIFY AND DESCRIBE THE CURRENT SYSTEM, NOT TO CORRECT DEFICIENCIES. Quite often, there is a temptation to try to correct an obvious problem at this stage. As a consequence, the task of capturing current systems takes longer and longer. When errors or problems are spotted they should be documented as future Modification/Improvements and not corrected as part of this effort.

How much definition is enough? Ultimately it is based on the organization's needs. No two companies will approach the problem in the same way. Their requirements will vary. However, the vendor recommends simplicity when describing the various resources. The following guidelines should help:

System Resources:

Normally, system resources require a minimal amount of description. What is essential is that a clear and concise statement of the processing be defined. The vendor recommends a Phase 3 level of detail (Sub-System Design) in most instances. The descriptions should be accompanied by a System Flowchart (showing the sub-systems), and a Sub-System Flowchart (showing the procedures).

SYSTEM DESCRIPTION - Normally, the system narrative describes who the system will serve, what information requirements it implements, and what processing is included. When documenting current systems, it should suffice to explain who the system serves and a concise description of the overall processing.

SUB-SYSTEM DESCRIPTION - Timing is a key element here. The definition of Frequency (how often it occurs), Offset (when it must start in the cycle) and Response Time (how fast it must occur) are important aspects to the definition of a sub-system. Who is responsible for executing the sub-system, what Inputs, Outputs and Files are used are also important. For text, a simple description of the "Business Purpose" of the sub-system should suffice in most instances.

PROCEDURE DESCRIPTION - Procedures are primarily concerned with determining the work flow in an organization. Each procedure should specify who is to perform the work and when. Offset and Response Time should be uniquely defined for each procedure. As with sub-systems, each procedure should have prescribed Inputs, Outputs and Files. Again, for text, a simple description of the "Business Purpose" of the procedure should suffice in most instances. For Administrative Procedures, it may be necessary to detail the Operational Steps (Tasks) in "playscript" format.

PROGRAM DESCRIPTION - If program descriptions are important, then they should describe the functionality of the program, what it is to perform and how. The programming language, memory should also be defined, along with the Inputs/Outputs and Files.

Data Resources:

These resources contain the most essential intelligence in current systems analysis. They are the basic building blocks for all systems design. The definition of these resources must be taken seriously. Superficial definitions will cause problems later. Data resources have both logical and physical definitions. Both are important, but the physical characteristics will be the most visible during current systems analysis.

DATA DEFINITIONS - Each data element will have only one logical business definition, but can have more than one physical implementation. The logical definition is critical. The physical characteristics (length, precision, scale, picture, etc.) may vary from application to application. Select the most popular physical description when defining the data element. Express exceptions on the record (RD) where it resides.

RECORD DEFINITIONS - When capturing current systems, you will most likely be identifying physical records as opposed to logical. These can be easily identified from file layouts.

FILE DEFINITIONS - As with records, most files identified in current systems analysis will be physical and found in file layouts. The definition of the file must identify what records it contains. It should also describe whether it is a computer or manual file, and whether it is a primary or working file.

INPUT DEFINITIONS - Inputs help to identify the ultimate source of the data required to produce the information. They should each have a prescribed "Business Purpose," which includes who uses them and when, and what forms or screens are used to implement them. They should also describe what transactions they are used for (e.g., for data collection, or display/print requests).

OUTPUT DEFINITIONS - Outputs are used to identify the receivers of the information. Like inputs, they should specify the timing of the outputs (Frequency, Offset and Response Time), and what forms or screens are used to implement them. For text, each output should have a prescribed "Business Purpose." For customers requiring more detail, pertinent processing messages (Error/Warning/Information) should be documented as RD resources and related to the pertinent outputs (and inputs).

Corporate Entities:

To many people, the definition of corporate entities appears to be an overhead. In reality, the definition of these resources holds vital corporate intelligence, particularly in the area of Functional Entities. If carefully defined, they can be extremely helpful in understanding the business of the company and how it is implemented.

FUNCTIONAL ENTITIES - These are logical descriptions of either an enterprise or a business function. Defining business functions is particularly useful when interviewing Users for information requirements. What is basically required is a description of the "Functional Scope," along with a description of the "Duties and Responsibilities." These functions should also describe the specific Organizational Entities which implement them.

ORGANIZATIONAL ENTITIES - These resources represent the physical jobs which are used to implement the logical functions and are described by title, e.g., Manager, Clerk, Supervisor, Vice President, etc. It is important to note that the full job descriptions should be written by management and not necessarily by Systems Engineering.

HUMAN/MACHINE RESOURCES - Representing personnel and machine resources. The attributes of these resources should be defined by management and/or personnel.

NOTE: FE, OE and RE resources are normally defined under the Enterprise Engineering Methodology (EEM).

INFORMATION REQUIREMENTS - Current information requirements should be defined whenever possible. These can be defined by analyzing existing outputs and who they serve. When defined, it is extremely useful to compare and contrast existing requirements versus new. These requirements should be completed in full.

Tactics

Capturing current systems is an exercise in reverse engineering. Whereas, system design is a top-down effort, current systems analysis begins with an examination of the procedural flow and works up and down the system hierarchy.

According to the "PRIDE" definition of system structure, a sub-system consists of one or more administrative procedures and one or no computer procedures. With this in mind, the assumption can be made that a computer procedure represents a sub-system. Although a sub-system is limited to one computer procedure at most, a computer procedure is NOT limited to one computer program. A review of the computer "job streams" will reveal the computer procedures, their programs, outputs, and files.

A review of the computer procedure timings will show when jobs are being run, such as daily, weekly, monthly, year-end, etc. This can then be used to determine the timing specifications for the sub-systems. File back-up procedures can also be used to indicate timing considerations.

Another approach would be to analyze and sort inputs and outputs by common timing and receivers (such as those reports or screens used by Sales, by Customer Services, by Manufacturing, etc.). These groupings would ultimately represent sub-systems.

When sub-systems have been defined, they should be grouped into systems based on commonality. With this complete, you now have a skeleton of the system hierarchy.

What systems or sub-systems do you begin with? Start with those that provide operational information - those that are at the heart of the business operations. Those parts of the systems that provide policy and control information can be delayed until the operational systems have been captured, since they will require the same data created in the operational systems.  

DEFINING REQUIREMENTS

Specifying information requirements is perhaps the most important task in Phase 1. All designs that follow must ultimately satisfy the requirements. Therefore, they must be defined with a high degree of precision and accuracy. This requires a highly skilled Systems Engineer; someone who is adept at analyzing business problems.

During Phase 1, end-users are first interviewed in terms of the information they need to support their area of the business. The Systems Engineer then interprets the user's description and prepares a formal information requirement definition which is reviewed with the user for accuracy.

Historically, analysts have been at a loss as to how to properly define information requirements. To a large extent, this was due to inadequate training. They simply did not know how to ask the right questions. Consequently, users would be interviewed in terms of the type and format of the outputs they wanted (reports and screens), as opposed to WHY they wanted it (the business rationale). Because of this, incomplete systems would be developed that would only satisfy some of the needs of the users (not all). Fortunately, the Information Requirement (IR) specification as provided in "PRIDE" helps to overcome this problem. Instead of physical media requirements, "PRIDE" focuses on the types of business actions and decisions that need to be supported. The IR is used to specify:

• The BUSINESS PURPOSE of the requirement.

• The ACTIONS AND/OR BUSINESS DECISIONS to be made, including WHO must make them and WHEN.

• The BENEFITS of having this information.

• The OUTPUT(S) and SYSTEM(S) used to satisfy the requirement.

• The OBJECT(S) associated with the requirement.

• The required DATA ELEMENTS to implement the requirement; including both primary and generated values.

The Systems Engineer must be wary of trying to specify too much (or too little) in a single requirement definition. As a general guideline, requirements should be separated and sorted according to:

• Unique time frame (Frequency/Offset/Response Time).

• Common "receivers" of the information.

• Common purpose - Policy/Control/Operational requirements should be separated.

In addition to a formal printed definition of each Information Requirement, an Information Flow Diagram (IFD) provides a graphical illustration of how information moves throughout a business. The IFD, as provided in ISEM, shows each information requirement, along with its timing and characteristics (P/C/O). Further, the graphic expresses users in the information flow, such as "originators," "participators," and "receivers." In this way, the graphic represents the boundaries of the application and the project scope.

The IR resource in the IRM can also be used to represent non-information related requirements, such as machine specifications.  

PHASE 1/ACTIVITY E

Activity E represents the first major review with the end user. This is where the Information Requirements and Project Scope are reviewed and confirmed prior to seeking a systems solution. Each requirement must be evaluated by the user in terms of accuracy and clarity. The net result, the users and Systems Engineer reach consensus in terms of WHAT is required, WHO requires it, WHEN and WHY.

Glossary of Terms

During requirements definition the Systems Engineer defines the data elements needed to support the Information Requirements. As a by-product of this effort the Systems Engineer assembles a "Glossary of Terms." This glossary is an assemblage of all of the data elements in the applications and presented in a Webster/Oxford style format, complete with proper name and definition. Such a glossary is invaluable for clarifying the data items needed to support the requirements.  

ROUGH DESIGN

Following confirmation of the information requirements, the Systems Engineer is then charged with the task of devising a system solution. To do so, the engineer prepares a complete rough design of a system. This involves the decomposition of the system into sub-systems, into procedures (both computer and administrative), into programs. In this respect, the design process takes on the appearance of a mini-Phase 2, 3, and 4-II.

Participating in the rough design are representatives from Software Engineering, Data Engineering, Enterprise Engineering, Data Base Administration, Data Communications, User Management, DP Operations; all of which consult with Systems Engineering during design. The intent is to arrive at a viable solution for the company to implement. In terms of programming, Software Engineering considers the method of implementation (e.g., languages, techniques and tools). Data Base personnel consider data storage/communications implications.

The system design is considered "rough" in the sense that it represents a tentative design for evaluation purposes. Regardless, there is considerable attention to detail in terms of identifying the system and data resources needed to satisfy the information requirements. During this activity, the Systems Engineer will consider alternatives. For example, the Systems Engineer will identify...

• Re-usable resources - system and data resources that have already been developed and are suitable for inclusion in the application.

• Existing resources requiring modification to accommodate the system.

• New resources that will have to be designed and developed.

• Resources that can be implemented by commercial software packages.

• Data interface requirements between all of the above.

The point is, rough designs are used to propose practical cost-effective solutions for management to consider. However, there are additional benefits. The rough design will become the basis for formulating a project plan, estimate and schedule. This can then be used for "make versus buy" decisions. It will also improve communications and cooperation between the development staff due to early participation in the planning phase.

One final word of advice on rough designs: Do not attempt to perform the whole project in Phase 1. It must be remembered that the intent of Phase 1 is to propose a viable solution for management to consider. Although the rough design may be rigorous, it must not be considered the final design; this is what the succeeding phases of ISEM are for. In other words, do not try to build the perfect system in Phase 1; simply take it to the level where the project team has confidence in the design and that a realistic project plan/estimate/schedule can be prepared.

System Concept Diagram

To graphically represent the system solution, the Systems Engineer prepares a System Concept Diagram. This is a free-form schematic that illustrates to the user how the envisioned system will operate upon completion. This is similar in intent to an artist's rendering as used in architecture.

Although there are no formal standards for this type of graphic, the System Concept Diagram normally shows the user departments involved, the business processes, and interfaces to other systems (if any).  

EVALUATING A PACKAGED SOLUTION

A commercial software package provides one alternative for implementing an information system. Normally, it is not a complete information system but only tested computer programs that is sometimes accompanied by user procedures for input preparation. Most packages tell the purchaser what input is required to produce a specified output without telling the purchaser who does what, when and how. Because of this, the overall system, sub-system and administrative procedures may have to be documented to convert a package into an information system before installation can be accomplished. In other words, a package should be documented in the IRM like any other resource.

User Management typically buys more packages than system developers. This is primarily due to the proliferation of micro-computers throughout organizations in an attempt to solve information problems. Because of the traditional backlog or user requests, packaged software is an attractive alternative for the user.

There are two reasons why purchased packages can fail. One is because the User, having a definite information need or wishing to solve a business problem, purchases a package because it appears to solve the problem. An example of this is where the Order Processing Department purchases an Order Processing System because it seems to solve the problem. After the package is purchased, it is turned over to systems development for implementation. Shortly thereafter systems development discovers that: extensive changes are required to make the package interface with other systems; the package has poor documentation; the package does not completely meet the user's requirements; it will require considerable time to modify and implement.

A second reason is that systems development, behaving in a manner similar to the user, also conducts a superficial package evaluation. Little investigation is made as to how complete the documentation is, what modifications might be required to suit in-house needs, how it will interface with other systems, how long it may take to implement, etc.

In both examples, the solution to the problem was a package purchased before the real needs of the company were defined. Therefore, AN ELEGANT SOLUTION TO THE WRONG PROBLEM SOLVES NOTHING.

Even with this in mind, experience with many installations has been that the purchase decision is a viable alternative to 're-inventing the wheel'. This is especially true in those situations where resource and/or time constraints have necessitated the purchase consideration. When handled intelligently and adequately managed, packages can be successfully installed to the mutual satisfaction of both systems development and users to solve pressing business problems.

How then is it possible to avoid the common pitfalls and evaluate packages intelligently? Fortunately, the answer is simple: Phase 1. It provides all of the background information necessary to intelligently investigate packages. If performed correctly, the Phase 1 will have produced:

• Information Requirements.

• Rough Designs - containing tentative specifications about data and processing specifications.

This becomes the focal point for preparing a comparative analysis:

• Information Requirements/Outputs Analysis - by analyzing the package's outputs, the Systems Engineer should be able to determine which outputs satisfy the various Information Requirements, either in part or in full. A matrix is very useful for illustrating these relationships.

  It must be remembered that packages are developed by vendors to solve general problems; not your specific information requirements. However, the vendor may have more insight into the business problem than the customer. As such, they may provide you with additional considerations in terms of specifying information requirements.

• Rough Design Analysis - because of the completed rough design, Systems Engineering can evaluate how well the package satisfies processing and data requirements. The Systems Engineer should be able to illustrate:

  • Which sub-systems can be implemented by the package, either in part or in full. Timing requirements, in particular, should be considered.

  • The types of file structures that accompany the package and if the files are accessible for additional customer specific processing requirements.

  • How well the package's physical data characteristics conform to in-house requirements. For example, does the package express dates, times, names, monetary values, etc. in the same manner as is commonly used in the company? In other words, how does the vendor express data length, precision, scale, etc? Severe conflicts may be incompatible for in-house use.

For each packaged solution, Systems Engineering prepares a system evaluation. This allows all possible alternatives to be considered and clearly identifies the time and money saved by the purchase, if any. When preparing this evaluation, the engineer must consider additional time to customize and install the product. In addition, consideration must be given to interfacing the package to other parts of the customer's systems.

Installation Considerations

Whenever possible, package documentation should be incorporated into the IRM for management and control. This means that narrative and specifications should be entered in the IRM regarding:

• Systems, Sub-Systems, Administrative Procedures, Computer Procedures, Programs, Modules.

• Inputs, Outputs, Files, Records, Data Elements.

This does not necessarily mean entering the product's documentation in its entirety into the IRM, although this would be ideal. It may be more desirable to simply establish cross-references to the package's own documentation. However, because the package will, ultimately become a natural part of the company's systems, sufficient intelligence should be put into the IRM so that the customer can merge the package's information resources with their own. This provides invaluable control to the customer, particularly when performing an "impact analysis." It also provides the customer with the ability to evaluate a product release prior to putting it into production.

The customer may elect to execute ensuing ISEM phases in order to properly document the package. This may be accomplished by either the 'in-house' development staff, by vendor personnel, or both working together.

Package Summary

The decision to purchase a package to reduce development time and costs can produce satisfying results for both the user and systems development staff. This does, however, require that the organization first develop the information requirements, evaluate and install the package that best meets the requirements, and finally, perform an audit of the project. The ISEM approach is a means for good communications among the participants and earns their commitment, thereby increasing the chances for a successful implementation.

For additional information on this subject, consult:

• Commercial Software Criteria

HARDWARE CONSIDERATIONS

During the rough design consideration must be given to the physical implementation of the system. In many instances, the existing operating environment is assumed. However, the rough design may suggest the need for additional equipment and/or enhancements to the current operating environment. This is one reason why DP Operations and Data Base personnel participate in the preparation of the rough design; to appraise the impact of the proposed system on the current operating environment.

In studying the rough design, consideration is given to:

• The areas of the business served.

• Processing requirements: such as, Interactive, Batch, etc. Also, distributed versus central processing.

• Types of media (Inputs/Outputs): Graphical, Textual, Audio, Optical, etc.

• Data transmission/conversion requirements.

• Required processing speed and volume of transactions.

• Storage requirements (files).

• Back-up/file retention requirements.

From this, assumptions can be made regarding:

• Computer equipment and operating systems.

• Input/Output peripherals; e.g., terminals, printers, etc.

• Communication hardware/software, including networking.

• Data Base hardware and software.

• Other equipment and files (non-computer related).

From this evaluation, an estimate of anticipated expenditures can be prepared for inclusion in the overall project estimate. At this point, hardware decisions are only tentative. The final decision on these matters should be reserved for subsequent ISEM Phases as the system design is finalized.

Client/Server Computing

The expression "client/server" is used to describe a physical method of implementation for an information system. It suggests a network of computers where some are dedicated to managing key files ("file servers") and others that access the file servers remotely ("clients"). Obviously, this is but one approach to computing. Mainframe and mid-range solutions with "dumb" terminals will remain a viable solution for a long time to come. The larger machines are still a cost-effective solution for most of the "number crunching" required by major corporations. However, as the smaller machines gain in power, a truly distributed computing environment is becoming more and more attractive to companies.

Before a company jumps into "client/server" (a physical processing decision) they obviously should perform the logical system design and determine their processing requirements. As mentioned, consideration should be given to anticipated transaction volume, processing speed, security, file access, etc. Only after these areas have been specified should consideration be given to the required physical platform. The point is, "client/server" may or may not be right for you. Just because it is technically fashionable doesn't make it the right solution for your company. Again, emphasis should be placed on logical system design in order to properly specify physical requirements.

In terms of system design, aside from some special programming requirements, there is actually little difference between a normal "mainframe" based development project and a "client/server" project. Both types of projects will require the same phases and activities as prescribed by "PRIDE"-ISEM.  

PROJECT PLANNING

This means that the remaining phases of the project can be deduced from the system structure. It also means that the project can branch into parallel phases. As an aside, this approach reflects the "explosion/implosion" design and development process inherent in the methodology.

Although the above phase/system-resource relationship is the normal way of conducting an ISEM project, there may be exceptions to the rule. For example:

• If multiple Phase 2's have been identified, it may be more practical to split them into separate projects.

• Although Phase 4-I is normally used to write all of the administrative procedures in a sub-system, there may be occasions where a complex procedure may require the execution of a separate Phase 4-I.

• Phase 5 is normally used to write and test a single program. However, if the program is extremely large and complex, it may be more practical to divide it into sub-Phase 5's where the modules of the program can be written and tested.

• Phase 8 marks the start-up of the system. If a large system, it may be more practical to execute a Phase 8 for a group of sub-systems. In other words, deliver the system in stages.

• Depending on the scope of the project and/or organizational considerations, the project may wish to include DBEM phases for Data Base Engineering. Normally this is treated as a separate project.

The point is, ISEM provides a good framework for executing a systems development project. However, Project Management must consider the practical implications for controlling the project and, as such, must make the final decision on project execution.

After the path of the project has been determined an Order-of-Magnitude (OOM) estimate and schedule can be calculated. This is an estimate and schedule of the amount of effort required to perform the remaining phases in the project. The estimate, thereby, is an expression of labor charges.  

HUMAN RESOURCE REQUIREMENTS

Following the rough design and the project plan, consideration must be given to the types of human resources required to implement the project. Based on the type of application being developed, Project Management considers the types of Systems Engineers and Software Engineers required to work on the project, including the skills and proficiencies needed to perform the work. Based on this analysis, Project Management has four options:

• Use in-house personnel.

• Recruit additional personnel.

• Use outside personnel (contractors).

• Combinations of the above.

In all instances, the use of human resources is based on their qualifications, their availability, and their cost. Project Management, therefore, must balance these variables when selecting personnel. There may be trade-offs to consider; for example:

• One person may be more expensive than others but can deliver the work faster.

• A senior analyst could perform the work in fewer hours than a junior analyst, but is committed to other project assignments. Consequently, the analyst cannot devote sufficient time to the project. Whereas the junior analyst may have fewer conflicts and is more available for project work.

The use of known human resources has a direct impact on the Order-of-Magnitude estimate and schedule. However, in the situation where resources are unknown, the Order-of-Magnitude estimate and schedule can still be calculated. Here, the Project Manager must make some assumptions as to the type of skills and proficiencies required and the number of Systems and Software Engineers needed for the project. The estimate thereby becomes the basis for recruiting additional personnel or hiring contractors. It also becomes the basis for determining training requirements, the cost of which should be absorbed by the project.  

COST/BENEFIT ANALYSIS

The purpose of a Cost/Benefit Analysis is to perform an economic impact analysis on the system and the project. Prior to performing this, Project Management has prepared an Order-of-Magnitude estimate to complete the project, along with any additional planned expenditures (such as for additional hardware/software acquisitions).

"PRIDE" provides a worksheet to assist in the preparation of the Cost/Benefit Analysis. However, in-house standards should be observed when performing the analysis.

During the analysis Project Management must consider how the proposed system solution will affect the company:

• Will it increase or reduce staffing?

• Will it increase or reduce equipment resources?

• What will be the annual savings and expenses of the system as it applies to the various user departments?

• What will be the one-time savings and expenses of the project as it applies to the various user departments?

• What will be the intangible benefits of the system?

• What is the investment evaluation? For example, what will be the Break Even Point of the project? What will be the Return On Investment (ROI)?

The Cost/Benefit Analysis becomes the basis for the preparation of the Cost and Evaluation Summary, a textual justification for the project.  

PHASE 1 REVIEW

The formal deliverable resulting from Phase 1 is the "System Study & Evaluation Report." This represents a packaging of the various elements produced during the phase (e.g., Project Scope, Information Requirements, System Concept Diagram, System Logic Narrative, Project Plan, Order-of-Magnitude, Cost and Evaluation Summary, etc.). A formal meeting with management is conducted to review the deliverable. At this time, management may elect to approve the project as proposed in the deliverable, request revisions before proceeding, or cancel the project completely.

There may be many reasons for discontinuing a project at this time, perhaps the project team cannot produce an adequate solution for satisfying the business problem, or perhaps the economics of the project are not justifiable (the Return on Investment may be too low for example). Common sense would dictate never to expend human and financial resources on an activity which will never prove to be worthwhile.

Assuming cancellation of the project, the company retains specifications regarding:

• The current system.

• Information Requirements.

• A rough design of a proposed new system.

Project Management prepares/revises a Project Scope for the project. Based on the scope, Project Management prepares an estimate/schedule for review and approval by Systems Resource Management and User Management.

1. If the project is to proceed only through Phase 1, Project Management and Systems Engineering will prepare a Detail estimate and schedule for the PHASE.

2. If the project is to proceed to other phases and activities, then an estimate is prepared to complete the whole project.

   If the project appears to be relatively small and easy to manage, then a Detail estimate and schedule is required.

   If the project appears to be large and complex, then an Order-of-Magnitude estimate and schedule is required.

Activity B - Current Systems Analysis

Systems Engineering studies the current system. The engineer interviews users and DP Operations and samples work from this area. Data Base personnel also advises the engineer on existing file structures. Consequently, current system documentation is updated as required and a Current Systems Analysis is prepared highlighting the strengths and weaknesses of the current system. This analysis is reviewed with User Management for accuracy.

Activity C - Survey Information Requirements

Systems Engineering prepares an interview outline and schedule for determining information requirements and interviews User Management accordingly.

Activity D - Prepare Requirements & Scope

Systems Engineering interprets user information requirements and prepares a formal definition of each. An Information Flow Diagram is also prepared which shows how information within this application flows between users. As required, the Project Scope is updated at this time.

Activity E - Review Requirements & Scope

Systems Engineering reviews the information requirements, Project Scope and Information Flow Diagram with User Management for clarity and accuracy. This is the first major review point in the methodology.

Activity F - Develop System Approach

Systems Engineering prepares a system solution that will satisfy the User's information requirements. A complete rough design of the system is prepared at this time. This becomes the basis for considering alternative solutions, such as a "make versus buy" solution. Other functions participate in the rough design including Software Engineering, Data Base personnel, DP Operations, etc.

Activity G - Prepare System Evaluation

Based on the rough system design prepared in the previous activity, Project Management prepares a Project Plan which details the remaining phases in the project. From the plan an Order-of-Magnitude estimate and schedule is prepared to complete the project. This estimate combined with any other anticipated financial expenditures (for such things as hardware/software) is used in the preparation of a Cost/Benefit Analysis. This becomes the basis for developing the Cost and Evaluation Summary, a textual justification for the project.

Project Management and Systems Engineering then assemble the deliverables produced in the phase and packages them into a single phase review document which is evaluated by Quality Assurance prior to conducting the formal phase review with management.

Activity H - Phase 1 Review

Project Management conducts a formal review of the Phase 1 deliverables with Executive Management, User Management, Information Resource Management, and Enterprise/Systems/ Data Resource Management. The review is used to evaluate the work performed thus far and revise as required. At this time, management will review the formal Phase 1 "System Study & Evaluation Report" consisting of:

• Phase Cover Page
• Project Scope
• Current System Analysis
• Information Flow Diagram (IFD)
• Project Information Flow
• Information Requirements
• System Concept Diagram
• System Logic Narrative
• Project Plan
• Project Estimate/Schedule Recap
• Cost and Evaluation Summary
• Glossary of Terms
• Phase Review Checklist
• Supporting Matrices:
  • Requirements/System Matrix by Project
  • Entity/System Matrix by Project
  • Information Requirements/Outputs Matrix

Based on this report and subsequent review meeting, management may elect to revise parts of the report, discontinue the project, or approve it for continuation.