About the Course
This course is intended to:
- provide students with a broad understanding of the issues involved in
- 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:
- 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.
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.
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.
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.
Send mail to
with questions or comments about this web site.
Copyright © 1997, 1998 Essential Strategies, Inc.
Last modified: December 21, 1998