Requirements Analysis Course

About the Course

This course is intended to:

provide students with a broad understanding of the issues involved in analyzing requirements
provide students with attitudes required
provide students with an understanding of the range of techniques involved and the kinds of things they address
teach students some of the specific techniques that can be used.

The analysis of business requirements requires an analyst to understand an enterprise at a deep level, without regard for the technology that is either in place or might be put in place, and without regard for the specific procedures and approaches currently being taken to perform the tasks. The fundamental questions are: What is the enterprise in business to do? and What is its inherent structure. From the answers to these questions we can determine how technology might help do these things more efficiently, and how to structure such technology so that it is compatible with the enterprise.

The questions are answered in a series of iterations, representing progressively more detailed views of the enterprise's operations. We begin at a strategic level, trying to determine the overall goals and objectives of the organization and the constraints under which it operates. From there, we select a particular area of interest and try to understand that area in detail, from a business perspective. Then we express this business understanding in terms of the way the organization uses information.

Only after we have completed the analysis to this degree do we begin to ask how to apply technology to the needs of the enterprise. Only now do we design screens, programs and database tables.

Note that this progression occurs on many different fronts. Most obvious are the data and processing perspectives. Traditionally these have been analyzed separately, but the object oriented approach is revealing how they can be analyzed together. In addition to data and processing, there are issues of geographical distribution, human resources, and business rules and constraints. The analysis of each of these aspects also progresses from the strategic to the technological.

Improved tools have made it possible to build prototypes quickly, for the purpose of exploring technological opportunities. This has its place in various parts of the life cycle, but it does not eliminate the importance of identifying the organization's true requirements before trying to build a solution.

The techniques taught in the course include:

Interviewing
Conducting feedback sessions
Entity/relationship modeling (the Oracle version)· Function hierarchies
Essential Data Flow Diagrams (after McMenamin and Palmer)
Entity Life Histories (an object-oriented approach to data modeling)
State Transition Diagrams
Writing and organizing findings

In one week, students will become conversant with these techniques. Moreover, through use of the case study, they will have experience with them. They will of course not become proficient at them until they have had the opportunity to use them in a real project, but this course should prepare them to do so.

It is not expected that course attendess will use all of the techniques in any given project. It is important, however, that they understand the range of techniques available and when to apply them.

Course Outline

Introduction

This is where we discuss attitudes towards systems analysis, and review the field. We cover a little history of the industry, the relationships among the techniques, and what to expect in the course. We will also attempt to become "buzzword-compliant" with a review of all the current terms and how they relate both to each other and to traditional techniques.

Review Strategy

This course was designed to follow a one-week strategy course where data modeling and function hierarchies were already taught. For a group which has not been through that course, this is where we introduce those techniques. The particular techniques taught can be replaced with others, but the important thing is to identify what the techniques should be revealing to you about the structure of an enterprise's data and its functions.

In particular, the course will here introduce students to data ("entity/relationship") modeling and function hierarchy modeling. In each case, the students will be introduced to the terminology, how to read the models, and general principles for constructing them.

Conduct Detailed Interviews

Interviewing skills are critical if the analyst is to learn how an organization really works. Here we talk about the kinds of questions to ask and what to do when you don't get the answers that you need.

Refine or Define Business Functions

Here we use McMenamin and Palmer's "Essential Data Flow Diagrams" to identify the "essential (elementary or atomic) processes" being performed and their relationships to the events that drive the business. This "event-oriented" approach to data flow diagrams prepares the student for several important object-oriented concepts.

We will also explore the technique of building "Entity Life Histories" as an alternative way to describe functions in an enterprise. This technique is a tightly integrated view of the interaction between the data and processing sides of the organization's operations. These techniques can provide guidance in the definition of roles to be performed in the carrying out of processes, and the kinds of information required for each role. We also can expand on the techniques to make assertions about the appropriate geographical distribution of the activities. In both cases, one of the outputs of the process will be explicit statement of the business rules and constraints under which the enterprise operates.

Refine Data Requirements

This covers several areas:

First, we will "converge" the data model, making it reflect more fundamental things of significance to the business. This will make the model simpler and more robust.
Second, we discover how the data model can reveal the need to explicitly describe business rules and constraints.
Third, we will examine the data stores in the data flow diagrams to establish reasonable "sets of views" of the data model, and map these to the data flow diagram.
Fourth, we will discuss issues associated with the geographical distribution of data.
Finally, there will be a tutorial on normalization and the rules for arriving at the "3d norm al form" organization for data.

Reviews With Users

This section will discuss the issues involved in presenting findings to users in a "feedback session." How should it be organized, how should it be conducted, and so forth. Related to this is the process of using group sessions instead of interviews for gathering information in the first place.

Document Processing in Detail

The particular requirements for documenting processes vary from company to company. Here, without dwelling on specific formats, we discuss the things which must be recorded about each process.

Identify Requirements for a new System

Most of the analysis process is concerned with simply understanding an enterprise's business. What does it do? What is its structure? Here we take what we have learned and add to it our knowledge of available technology to make recommendations about where to go from here.

Plan for Transition

A major new system will allow an enterprise's management to do things that were not possible before. If it is to become part of an organization's infrastructure, it will represent a tremendous change for many people. If it is to succeed, this change must be planned for, and the planning must begin as soon as the dimensions of the change are understood. Beginning this planning is a very important part of the analysis process.

Publish Report

Again, the particular format and deliverables of an analysis project will vary from company to company. Here, however, we can discuss the elements that must be present, whatever their form.

Summary

By the end of the week, the students should be overwhelmed with the amount of material that has been covered. At this point, we stop and review what has been learned, and attempt to put all the various pieces together in context.