CDM Vol1

ORACLE METHODSM
CDM STANDARDS AND

GUIDELINES LIBRARY
VOLUME 1 - REQUIREMENTS
MODELING USING ORACLE
DESIGNER
Release 6.0.0
February, 2000
CDM Standards and Guidelines Library,

Volume 1 - Requirements Modeling using Oracle Designer, Release 6.0.0
Copyright 1996, 2000, Oracle Corporation. All rights reserved.
Authors:
Sigrid Gylseth, Steven Davelaar, Ton van Kooten
Contributors: Lauri Boyd, Lucas Jellema, Sandra Muller
Editor:
Mary Sanders
The Programs (which include both the software and documentation) contain proprietary
information of Oracle Corporation; they are provided under a license agreement containing
restrictions on use and disclosure and are also protected by copyright, patent, and other
intellectual and industrial property laws. Reverse engineering, disassembly, or
decompilation of the Programs is prohibited.
The information contained in this document is subject to change without notice. If you find
any problems in the documentation, please report them to us in writing. Oracle Corporation
does not warrant that this document is error free. Except as may be expressly permitted in
your license agreement for these Programs, no part of these Programs may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any purpose,
without the express written permission of Oracle Corporation.
If the Programs are delivered to the U.S. Government or anyone licensing or using the
programs on behalf of the U.S. Government, the following notice is applicable:
Restricted Rights Notice Programs delivered subject to the DOD FAR Supplement are
"commercial computer software" and use, duplication, and disclosure of the Programs,
including documentation, shall be subject to the licensing restrictions set forth in the
applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal
Acquisition Regulations are "restricted computer software" and use, duplication, and
disclosure of the Programs shall be subject to the restrictions in FAR 52.227-19, Commercial
Computer Software - Restricted Rights (June, 1987). Oracle Corporation, 500 Oracle
Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or
other inherently dangerous applications. It shall be the licensee's responsibility to take all
appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of
such applications if the Programs are used for such purposes, and Oracle Corporation
disclaims liability for any damages caused by such use of the Programs.
ORACLE, Oracle Designer, Oracle Developer, SQL*Plus, SQL*Loader, SQL*Net,
CASE*Method, ORACLE Parallel Server, PL/SQL, Pro*C, SQL*Module are registered
trademarks of Oracle Corporation, Redwood City, California.
AIM Advantage, CDM Advantage, EMM Advantage, PJM Advantage, Oracle Cooperative
Applications, Oracle Financials, Oracle Alert, Oracle Manufacturing, Oracle Inventory,
Oracle Bills of Material, Oracle Engineering, Oracle Capacity, Oracle Commissions, Oracle
Master Scheduling, Oracle MRP, Oracle Work in Process, Oracle General Ledger, Oracle
Assets, Oracle Order Entry, Oracle Cost Management, Oracle Payables, Oracle Receivables,
Oracle Personnel, Oracle Payroll, Oracle Purchasing, Oracle Quality, Oracle Sales and
Marketing, Oracle Service, and Application Object Library are trademarks of Oracle
Corporation, Redwood City, California.
Oracle is a registered trademark, and Oracle Method is a service mark of Oracle
Corporation. Microsoft and MS-DOS are registered trademarks and Windows, Word for
Windows, PowerPoint, Excel, and Microsoft Project are trademarks of Microsoft
Corporation. Visio is a trademark of Visio Corporation. Project Workbench and Project
Bridge Modeler are registered trademarks of Applied Business Technology. All other
company or product names mentioned are used for identification purposes only and may be
trademarks of their respective owners.
Contents
Send Us Your Comments..........................................................................vii

CHAPTER
Introduction to Requirements Modeling ............................................. 1-1

Goal of Requirements Modeling .............................................................. 1-2
Types of Modeling.............................................................................. 1-2
Requirements Modeling Techniques ....................................................... 1-4
Process Modeling................................................................................ 1-4
Entity Relationship Modeling............................................................ 1-5
Function Modeling ............................................................................. 1-6
Business Rule Modeling ..................................................................... 1-6
Prototyping ......................................................................................... 1-7
Dataflow Diagramming ..................................................................... 1-7
Audience ............................................................................................. 1-7
Oracle Designer Road Map to Requirements Modeling ........................ 1-8
Business Process Modeling (RD.010) .............................................. 1-11
System Process Modeling (RD.100)................................................. 1-13
Entity Relationship Modeling (RD.040, RD.060, RD.080).............. 1-14
Function Modeling and Change
Event Rules (RD.030, RD.070, RD.090) ........................................... 1-15
Authorization Rules (TA.090).......................................................... 1-17
CHAPTER
Process Modeling ..................................................................................... 2-1

Related CDM Tasks................................................................................... 2-2
What is Process Modeling?....................................................................... 2-3
Benefits of Process Modeling............................................................. 2-4
Oracle Method
Contents i
The Business Process Model.............................................................. 2-5

The System Process Model ................................................................ 2-6
Overview of Process-Oriented Development .................................. 2-7
Oracle Designer Support.................................................................... 2-9
Modeling the Business Context.............................................................. 2-12
Business Area.................................................................................... 2-12
Defining Business Objectives and Primary Processes ................... 2-13
Elements of the Context Process Diagram ..................................... 2-14
Using Oracle Designer to Construct the
Context Process Diagram................................................................. 2-17
Modeling Business Processes ................................................................. 2-24
Modeling Primary Processes ........................................................... 2-24
Using Oracle Designer to Document Business Processes ............. 2-36
Modeling Support Processes ........................................................... 2-45
Constructing the Business Process Model...................................... 2-49
Other Process Modeling Concepts.................................................. 2-51
Process Models and Function Hierarchy Models................................. 2-53
Functions and Processes .................................................................. 2-55
Building and Using Function Hierarchies
with Oracle Designer........................................................................ 2-56
Process versus Function for Project Scoping.................................. 2-61
The System Process Model ..................................................................... 2-63
Developing the System Process Model........................................... 2-64
Transition from Analysis to Design ................................................ 2-65
Business Process Modeling versus
System Process Modeling ................................................................ 2-67
Verifying the Process Model .................................................................. 2-68
Business Area Comparisons ............................................................ 2-68
Process Integration within the Business Area................................ 2-68
Processes and Function Areas ......................................................... 2-69
Process Steps and Elementary Business Functions........................ 2-69
Some Concluding Remarks .................................................................... 2-70
CHAPTER
Business Rule Modeling ......................................................................... 3-1

Business Rule Classification Scheme ....................................................... 3-4
ii Contents
Requirements Modeling using Oracle Designer
Static Data Constraint Rules..................................................................... 3-8

Attribute Rules.................................................................................... 3-9
Tuple Rules (TPL) ............................................................................. 3-13
Entity Rules ....................................................................................... 3-15
Inter-Entity Rules.............................................................................. 3-17
Additional Remarks ......................................................................... 3-21
Dynamic Data Constraint Rules............................................................. 3-22
Create Rules (CRE) ........................................................................... 3-22
Update Rules..................................................................................... 3-23
Modify Rules (MOD)........................................................................ 3-24
Delete Rules....................................................................................... 3-25
Change Event Rules with DML.............................................................. 3-27
Default Rules (DFT).......................................................................... 3-27
Other Change Event Rules (CEV) ................................................... 3-28
Change Event Rules without DML (CEW)............................................ 3-30
Authorization Rules (AUT) .................................................................... 3-31
Function Access Rules...................................................................... 3-32
Vertical Data Access Rules Authorization...................................... 3-33
Horizontal Data Access Rules ......................................................... 3-34
Recording a Business Rule as a Function .............................................. 3-35
Organizing Rules .............................................................................. 3-36
Rule-Triggering Events .................................................................... 3-40
What to Record ................................................................................. 3-43
Presentation to the Business Community....................................... 3-46
The Process of Business Rule Modeling ................................................ 3-48
CHAPTER
Entity Relationship Modeling ................................................................ 4-1

The Entity Relationship Model................................................................. 4-3
Business Data Modeling versus System Data Modeling................. 4-3
Client Involvement ............................................................................. 4-4
Cross-Checking with Function or Process Model............................ 4-5
Entities........................................................................................................ 4-6
Recognizing Entities ........................................................................... 4-6
Naming Entities .................................................................................. 4-7
Oracle Method
Contents iii
Conceptual Views............................................................................. 4-10

Attributes ................................................................................................. 4-11
Unique Identifier .............................................................................. 4-11
Attributes and Relationships ........................................................... 4-12
Relationships............................................................................................ 4-13
Optionality and Degree.................................................................... 4-13
Naming Relationship Ends .............................................................. 4-14
Hierarchical Relationships............................................................... 4-15
Subtypes and Supertypes ....................................................................... 4-17
Naming of Subtypes......................................................................... 4-18
Supertypes......................................................................................... 4-18
Implied Subtypes.............................................................................. 4-19
Arcs and Subtypes............................................................................ 4-19
Almost Subtypes............................................................................... 4-19
ER Diagrams............................................................................................ 4-23
Knowing Where to Start .................................................................. 4-23
Testing the Data Model.................................................................... 4-23
Merging Structures........................................................................... 4-24
Cleaning Up ...................................................................................... 4-24
Knowing When to Stop.................................................................... 4-24
Verifying the Data Model ................................................................ 4-25
CHAPTER
Function Modeling................................................................................... 5-1

Overview of Function Modeling.............................................................. 5-3
Business Function Modeling.............................................................. 5-3
System Function Modeling ................................................................ 5-3
Business versus System Function Modeling .................................... 5-4
Cross-Checking with the Data Model............................................... 5-5
Function Hierarchy ................................................................................... 5-6
What a Function Hierarchy Does Not Do ........................................ 5-6
Software Packages .............................................................................. 5-9
Where to Start ..................................................................................... 5-9
Where to Stop ..................................................................................... 5-9
Top-Down versus Bottom-Up ......................................................... 5-10
Elementary Functions and Non-Decomposed Functions .................... 5-11
iv Contents
Function Short Definition and Description ........................................... 5-12

Function Frequency .......................................................................... 5-12
Function-Entity Usage............................................................................. 5-13
Tools .................................................................................................. 5-15
Function-Attribute Usage ....................................................................... 5-16
Common Functions ................................................................................. 5-17
Function Network............................................................................. 5-17
Verifying the Function Model ................................................................ 5-18
Higher Levels in the Hierarchy ....................................................... 5-18
Lower Levels in the Hierarchy ........................................................ 5-18
Lowest Level in the Hierarchy ........................................................ 5-18
Some Concluding Remarks..................................................................... 5-19
CHAPTER
Prototyping................................................................................................ 6-1
Approach to Prototyping.......................................................................... 6-3
General Guidelines ............................................................................. 6-3
Goals of Prototyping During Requirements Modeling ................... 6-3
Risks of Prototyping ........................................................................... 6-4
Conducting Prototype Sessions......................................................... 6-5
Prototyping Using Oracle Designer ......................................................... 6-7
Managing Design Objects .................................................................. 6-7
Oracle Method
Contents v
Send Us Your Comments

CDM Standards and Guidelines Library
Volume 1 - Requirements Modeling using Oracle Designer,
Release 6.6.0
Oracle Corporation welcomes your comments and suggestions on the
quality and usefulness of this publication. Your input is an important
part of the information used for revision.
Did you find any errors?
Is the information clearly presented?
Do you need more information? If so, where?
Are the examples correct? Do you need more examples?
What features did you like most about this manual?
If you find any errors or have any other suggestions for improvement,
please indicate the chapter, section, and page number (if available). You
can send comments to us in the following ways:
iDevelopment Center of Excellence
Oracle Corporation
Rijnzathe 6
3454 PV De Meern
The Netherlands
email: cdminfo.us@us.oracle.com
Oracle Method
Readers Comment Form vii
Preface
T
his manual, Requirements Modeling using Oracle Designer, provides

guidance and describes guidelines and considerations for modeling
business and system requirements using the Oracle Designer tool set.
This manual is part of the Standards and Guidelines Library (SGL) of
Oracles Custom Development Method (CDM).
The Standards and Guidelines Library consists of a series of manuals
that help you and your organization to deliver quality Oracle solutions.
This manual, the SGL volumes, the CDM manuals and the Custom
Development Method itself, are part of Oracle MethodSM -- Oracles
integrated approach to solution delivery. For more information on
CDM and Oracle Method, refer to CDM Quick Tour..
Oracle Method
Preface ix
Positioning
The SGL manuals are positioned between the CDM Classic and CDM
Fast Track Process and Task References and the product-oriented Oracle
tools manuals. The SGL manuals continue in more detail where the
CDM Process and Task Reference ends, and through references they form
an entry into the Oracle tools manuals. This section describes the
relationship of this manual to the following:
other SGL volumes
Oracle Custom Development Method
other system development methods
other Oracle manuals
Relationship to Other SGL Volumes

The Standards and Guidelines Library consists of the following
volumes:
Volume 1 - Requirements Modeling using Oracle Designer
Volume 2 - Design and Generation of Mult-Tier Web Applications
Volume 3 - Building Systems using Oracle8 Programming Tools
Volume 4 - CDM Standards
This manual (Volume 1) has a strong relationship with Volume 2 Design and Generation of Multi-Tier Web Applications. Both manuals focus
on modeling, designing, and generating multi-tier web applications
using Oracle Designer. The concept of modeling business rules that is
introduced in this manual is used and carried forward during design
and generation.
Volume 3 - Building Systems using Oracle8 Programming Tools covers the
other Oracle8 programming tools, such as, SQL, PL/SQL, and SQL*Plus
that can be used together with Oracle Designer and Oracle Developer.
Volume 4 - CDM Standards includes a list of detailed and numbered
standards and guidelines per deliverable of CDM Classic and CDM Fast
Track.
x Preface
Relationship to Oracle CDM Classic and CDM Fast Track

Oracles Custom Development Method (CDM) defines a set of
organized and flexible process steps that guide all involved personnel
through the Custom Development process. CDM Classic is the natural
successor of CASE Method and CDM Fast Track is the natural successor
of CASE Method Fast Track.
CDM Classic and CDM Fast Track are both deliverable-based. Every
task produces one clearly defined deliverable. This manual and the
other SGL manuals provide standards and guidelines on the best way to
produce these deliverables, assuming the Oracle tools are used to
model, design, and build the application system.
Each chapter in this manual contains a reference to all related CDM
Classic and CDM Fast Track tasks that benefit from the information in
that chapter.
Relationship to Other Methods

Where a method other than Oracle CDM Classic or Fast Track is to be
used for a project, the project manager should conduct a mapping of
CDM tasks and deliverables to the tasks and deliverables of the other
method. This ensures that the method to be employed for a particular
project covers the requirements of the project.
As long as Oracle Designer is used, this manual provides valuable
guidelines for systems design and generation.
Relationship to the Oracle Manuals

Each Oracle product has a range of technical manuals to support its use.
These manuals generally fall into the categories of user guides and
references, but also include training tutorials and other specialist advice.
However, these manuals do not relate the product to a project
development effort and do not take into account actual field experience.
The SGL manuals are based on best practices of Oracle consultancy
world wide and provide proven standards and guidelines with a
clearly-defined link to the tasks and deliverables of Oracle CDM Classic
and CDM Fast Track.
The Oracle SGL manuals concentrate on the quality issues that
developers and managers encounter within the project life-cycle and do
not repeat advice contained in the Oracle product manuals.
Oracle Method
Preface xi
Audience
This manual is written for business and system analysts, system
designers and developers, managers, and service groups that are
involved within the life-cycle of system development and
implementation. This includes project managers and support staff of
Oracle Corporation, business partners, and customers.
How This Manual is Organized

This manual contains guidelines for performing systems design and
generation, describing techniques, and referencing Oracle CDM tasks.
This SGL manual should be used in conjunction with Volume 4 - CDM
Standard). The manuals are organized as follows:
Volume 1 - Guidelines
Volume 1 contains the guidelines. The guidelines provide advice and
suggestions for completing CDM tasks. The guidelines are not
mandatory, but offer proven techniques and alternatives for task
completion. Guidelines alone are insufficient to ensure that a quality
product is produced, but can contribute substantially to the creation of
quality products.
Volume 4 - Standards
Volume 4 contains the standards. The standards impose a specific
working method. They are unambiguous and measurable. They allow
you, to a certain extent, to objectively assess the quality of the CDM
Classic and Fast Track deliverables involved. Standards are defined at a
detailed level so that all staff within a project or organization can follow
the standards, easing conflict and enhancing the maintainability of
systems. To allow for reference of the standards in this document, each
description of a standard is provided with a unique identification
number, for example, OMS-00001 (OMS stands for Oracle Method
Standard).
If an OMS standard number is underscored, this means that the
standard concerned is automatically checked by one of the utilities of
Headstart Oracle Designer. Refer to Appendix F, Headstart Oracle
Designer, in Volume 2, for more information on how to obtain these
API-based utilities.
xii Preface
How to Use This Manual

For the guidelines of this manual to be of value, you should have a
working knowledge of Oracle Designer. Also, this manual should be
used in conjunction with the CDM Classic Process and Task Reference and
the CDM Fast Track Process and Task Reference. It is the design and
generation tasks and deliverables of these references that benefit from
the standards and guidelines in this manual.
Before starting on systems design, carefully read the guideline chapters
in this volume to familiarize yourself with the proper use of the
techniques, and to be aware of any special cases or pitfalls.
When you record the modeling results in Oracle Designer, use the
related standards chapters in Volume 4 to check your work. Refer back
to the guidelines chapters for assistance when confronted with choices
not covered by the standards.
Oracle Services recommends that users of this manual, or any
SGL/CDM manual, or CDM Classic or CDM Fast Track, take advantage
of CDM training courses provided by Oracles Education Services. In
addition to manuals and training, Oracle Consulting also provides
experienced CDM consultants and automated work management tools,
customized for CDM.
Oracle Method
Preface xiii
Conventions Used in This Manual

The following textual conventions are used in this manual:
UPPERCASE TEXT
Uppercase text is used to call attention to command keywords, object
names, filenames, and so on.
Italicized Text
Italicized text indicates the definition of a term or the title of a manual,
and may also be used to set off a single word or short phrase, especially
to illustrate a point with an example.
Bold Text
Bold text is designed to attract special attention to important
information.
Capitalization
Names of tasks, deliverables, process and phases are always give title
capitals. For example, Design Audit Facilities task, System Data Model
deliverable, Technical Architecture process and Build phase.
Abbreviations and Acronyms
Occasionally, it is necessary to use abbreviations and acronyms when
adequate space is not available. The Glossary lists meanings of all
acronyms and abbreviations.
Fonts
The courier font is used to indicate examples of actual program code,
for example:
Example
select
*
from
(select * from dept) a -- subquery
,
emp b
where
a.deptno = b.deptno
or examples of computer responses to program code, for example:

ORA-00054: Resource busy and acquire with NOWAIT
specified
xiv Preface
Suggestions
We provide you with helpful suggestions throughout the handbook to
help you get the most out of the method. We highlight these
suggestions with an illuminated light bulb. Here is an example of a
suggestion:
Suggestion: Verify your backup and recovery plan with your
hardware and software vendors.
Attention
We sometimes highlight especially important information or
considerations to save you time or simplify the task at hand. We mark
such information with an attention graphic, as follows:
Attention: Since project team training occurs simultaneously
with this task, some recommendations (or decisions) from
training may be implemented in the mapping environment.
In this case, these training inputs become predecessors to this
task.
Warning
Considerations that can have a serious impact on your project are
highlighted by a warning graphic. Read each warning message and
determine if it applies to your project. Here is an example:
Warning: Any time you insert data directly into Oracle
Application tables, you run the risk of corrupting the
database. Oracle strongly discourages inserting data directly
into Oracle tables that are not designed as an Open Interface.
For More Information
Throughout the handbook we alert you to additional information you
may want to review. This may be a task section, appendix, or reference
manual. We highlight these references with an easy-to-notice graphic.
Here is an example:
Reference: For more information about content for the
design presentation, review the Critical Success Factors, page
3-7.
Oracle Method
Preface xv
Web Site
Information available on the World Wide Web is indicated by a Web
symbol and an appropriate Web address. Here is an example:
Web Site: Pure Atria Corporations Home Page on the
World Wide Web is http://www.pure.com/
Tool Version Differences
When there are differences between versions of tools, for example,
version 6 and 7 of the Oracle Server, we highlight these references with
an easy-to-notice graphic. Here is an example:
Difference: The optimizer of the Oracle7 Server under the
cost-based approach will consider the location of data when
estimating the cost of accessing it.
Tools
When there are specific Oracle tools that can be used to automate the
systems design and generation process, we highlight these references
with an easy-to-notice graphic. Here is an example:
Data
Schema
xvi Preface
Tools: Data Diagrammer; Edit Table Table, Column Defn

and Constraints tabsheets;
Related Publications
Books in the CDM suite include:
CDM Quick Tour
CDM Classic
CDM Classic Method Handbook
CDM Classic Process and Task Reference
CDM Fast Track
CDM Fast Track Method Handbook
CDM Fast Track Process and Task Reference
CDM Fast Track Techniques Handbook
CDM Fast Track Addendum
CDM Standards and Guidelines Library
Volume 1 - Requirements Modeling using Oracle Designer (this

book)
Volume 2 - Design and Generation of Multi-Tier Web Applications
Volume 3 - Building Systems using Oracle8 Programming Tools
Volume 4 - CDM Standards
Each of these books and their relationships to each other is discussed in

the CDM Quick Tour.
You may also refer to the following Project Management Method (PJM)
suite of reference books:
Oracle Method
PJM Method Handbook
PJM Process and Task Reference
Preface xvii
CHAPTER
Introduction to
Requirements
Modeling
T
his chapter gives a general introduction to requirements modeling.

It discusses the following topics:
Oracle Method
the goal of requirements modeling
the various requirements modeling techniques available within

Custom Development Method
a road map for using Oracle Designer for requirements

modeling
Introduction to Requirements Modeling 1 - 1
Goal of Requirements Modeling

Traditionally, we used to distinguish between Analysis and Design of
an application system. This distinct separation of the What (Analysis)
as opposed to the How (Design) often did not work out in practice.
Experience has shown that often the best way to be sure that we have
properly understood what is needed is to show the users how we will
satisfy their needs. In addition, the separate roles of system analyst and
system designer are more and more performed by the same people. We
should not force these people to only describe the What, if they
already have a clear picture of the How in their minds and not allow
them to write it down!
Modern project approaches, such as Fast Track and prototyping
techniques, prosper because of this knowledge. This knowledge should
also not be ignored in a waterfall-like project approach.
Types of Modeling
Oracles Custom Development Method (CDM), be it the classic or the
fast track approach, carries forward the above principle by identifying
two levels of requirements modeling:
business modeling
system modeling
Business Modeling
Business models describe the informational and functional requirements
necessary to meet the defined business objectives. The scope of
investigation is a business area, focus is on what the business has to do
to meet its objectives. There is no distinction between manual functions
and functions that need to be supported by the computer system.
Current procedures and mechanisms should only be described within
supporting documentation (CDMs existing system deliverables).
System Modeling
System models focus on functionality that must be implemented or
supported by the computer system and identify the nature of that
1 - 2 Introduction to Requirements Modeling
support. This includes functionality concerned with the systems

infrastructure and delivery mechanisms, for example:
data structures for the control of queues and replication of data

across a distributed network
functions to help administer the operation of the system (error

logging, system restart and recovery, etc.)
functions to control the flow of processing through the system

(network messaging, batch job scheduling, etc.)
Although the techniques used to perform business and system

requirements modeling are largely the same, you should be well aware
of the differences between the two. Make sure the client has the same
perception you do concerning the scope and type of requirements
analysis you plan to do.
Because of the similarity in techniques, the rest of this manual does not
explicitly carry forward the difference between business and system
modeling. However, this manual provides standards and guidelines for
requirements modeling using Oracle Designer. Concepts discussed in
this manual, especially the chapter on business rules, anticipate the
subsequent use of the wizards and generators available in Oracle
Designer. Therefore, they are geared towards system modeling and are
less applicable to business modeling.
Having defined the difference between business modeling and system
modeling, it is quite clear that the technology and tools that will be used
to build the system do influence system requirements modeling.
This especially holds true if multi-tier architectures are to be used. The
distribution of your application over multiple platforms offers
opportunities but also includes risks. The challenge is to take advantage
of the opportunities, avoiding the risks as much as possible.
Oracle Method
Requirements Modeling Techniques

CDM is based on a number of simple techniques that, when correctly
applied, provide a great deal of information in an easily understood
format. Requirements modeling is an iterative process with a number
of people discussing alternative representations. Involving clients in
discussions during model development will lead to more accurate
models that will be accepted by the client when they are delivered.
The section discusses the following major analysis techniques:
Process Modeling
Entity Relationship Modeling
Function Modeling
Business Rule Modeling
Prototyping
Dataflow Diagramming
Process Modeling
Process models provide a horizontal view of the organization, showing
additional information on how the organization accomplishes specific
repetitive tasks.
This simple but powerful technique is widely known and one of the
main pillars for Business Process Reengineering (BPR). With the
introduction of Oracles CDM, process modeling has become one of the
three main contributors to requirements modeling and definition.
In custom development, the primary purpose of process modeling is to
scope and define business requirements for system development. But
the real power of this technique lies in its contribution to the following
key areas of the custom development life-cycle:
It provides an efficient tool for understanding and

communicating business requirements.
It depicts a representation of work flow in an organization that

facilitates definition of the application system architecture and
design.
It provides a structure for organizing testing, design, and

training development.
It provides a framework for determining appropriate

implementation strategies.
Process modeling is based on the view that an organization is a system.

Systems exist in an environment. They receive inputs from the
environment and produce outputs. Organizations are adaptive and
purposeful systems that respond to changes in their environment. How
well they adapt and respond is a determinant of their success. Systems
consist of subsystems that in turn accept inputs and produce outputs.
The subsystems are the business processes of an organization. Process
modeling views processes as systems that are triggered by events,
receive inputs and produce outputs.
Process flow diagrams visually represent the event response. They
show the process steps that are executed to produce the output that is
required as a response to the triggering event.

Entity Relationship modeling provides a model of the information
within a company, and illustrates how that information is linked.
The things of importance (entities) within the business, the properties of
those things (attributes), and how they are related (relationships) are
recorded on a diagram using soft boxes with connecting lines and
residing within the analysis repository. The entity model is one of the
three pillars of requirements modeling in CDM, along with the function
model and the process model.
The entity model is a very powerful communication tool for creating
complex models using simple conventions that can be easily explained.
This technique is independent of the mechanisms used to hold that
information, such as paper forms or computers. As long as the business
does not change, the model will remain accurate.
Entity relationship modeling is covered in Chapter 4 of this manual.
Oracle Method
Function Modeling
Function modeling provides a model of what a business does
(functions) and how those functions can be grouped.
The functions within a business are grouped into a hierarchy. The
starting point and highest function of the hierarchy is the mission
statement or goal of the business. The finishing point is an elementary
business function such as sending out an invoice. The purpose of
function modeling is to show how that mission statement is fulfilled by
the functions performed within the business. This is a very powerful
technique and can lead to some very fundamental questions about how
an organization operates.
Function modeling is covered in Chapter 5 of this manual.
Business Rule Modeling

Traditionally, business rules have been more or less implicitly modeled
during entity relationship modeling and function modeling. Creating
an entity relationship model simply meant modeling a subset of dataoriented business rules. An elementary function used to describe
presentation functionality as well as application logic.
Within business requirements modeling, this is still a valid approach.
A business analyst wants to present the analysis information in a way
that is best understood by the business community, and thus records
business rules in a way that makes it easy to communicate to the
business community. This does not mean that business rules should be
described together with the entities or business functions. By
connecting business rules to entities and functions it is still possible to
present business rules in way they are easy to communicate. Experience
has learned that showing the business rules that are triggered by a
business function is the best way to present to the user.
During system requirements modeling, the impact of Internet
computing should be taken into account. Applying a multi-tier
architecture where the application logic is located on the middle tier,
business rule modeling should be regarded as a discipline on its own,
without undermining the techniques of entity relationship modeling
and function modeling.
By using a classification scheme of business rules, we explicitly define

what kind of functionality is part of the application logic layer. The
developer exactly knows which rules need to be implemented that
layer. Another advantage of classifying business rules is that design
estimates are much more reliable.
Business rule modeling is covered in Chapter 3 of this manual.
Prototyping
Prototyping is a powerful technique which can support you in verifying
the correctness and completeness of your requirement models.
Prototyping enables the user to see your interpretation of what is
required in the system, and to provide feedback. Because it is tangible,
the prototype also helps the client feel like they are getting something
for their money.
Prototyping is covered in Chapter 6 of this manual.
Dataflow Diagramming
With the introduction of process modeling, the need for dataflow
diagramming is strongly reduced. Dataflow diagrams depict processes
within the business using lines to illustrate the information being passed
(dataflows) and the subset of information available to a process
(datastores). As such, a dataflow diagram can be regarded as a specific
instance of a process flow diagram that only shows data dependencies.
Audience
As the audience for business and system models includes the future
users, you should use natural language in all free text objects, avoiding
technical jargon. As much as possible, use entity, attribute and
relationship names within the descriptions. If the resulting phrases are
incomprehensible, your naming of entities, attributes and relationships
is probably wrong!
Oracle Method
Oracle Designer Road Map to Requirements Modeling

The various modeling techniques discussed in the previous section are
complimentary to each other. Activities based on these techniques are
always performed in parallel. Information gathered during entity
relationship modeling feeds the function model and vice versa. New
functions lead to the discovery of missing entities. Entity life-cycle
analysis can reveal missing functions; for example, a function may have
been modeled to update an entity, but there is no create function.
Function modeling is also complimentary to process modeling.
Functional decomposition diagrams represent a vertical view of the
organization. Process flow diagrams provide a horizontal view of the
organization, showing additional information on how the organization
accomplishes specific repetitive tasks. Both views will increase your
understanding of the business and help you to identify missing business
functions (process steps).
Because of the complimentary nature of the techniques, the following
road map only applies to the preferred sequence of activities within
each modeling area. As stated in the previous section, business rule
modeling should be regarded as a discipline on its own. However, as
some classes of business rules are strongly related to either entity
relationship modeling or function modeling, the road map is organized
into the following modeling areas:
Business Process Modeling
System Process Modeling
Function Modeling And Change Event Rules
Authorization Rules
The above modeling areas reference specific tasks in CDM. The

following table provides the modeling areas and the CDM tasks and
their associated deliverables addressed in this manual:
ID
Deliverable
Task Name
Business Process Modeling

RD.010
Business Process Model
Create Business Process Model
System Process Modeling

RD.100
System Process Model
Create System Process Model

RD.040
Initial Business Data Model
Create Initial Business Data Model
RD.060
Business Data Model
Construct Business Data Model
RD.080
System Data Model
Construct System Data Model
Function Modeling and Change Event Rules

RD.030
High-Level Business Function Model
Create High-Level Business Function

Model
RD.070
Detailed Business Function Model
Construct Detailed Business Function

Model
RD.090
System Function Model
Construct System Function Model
Authorization Rules
TA.090
Oracle Method
Security and Control Strategy
Develop Security and Control Strategy
Depending on the scope and complexity of your application system, and

the project approach applied, you will iterate more or less through the
steps of the working sequence. You will produce a high-level
requirements model the first time, and refine this model in a later
round.
Deviations from the road map, given the choice of development
approaches, may occur in the sense that some steps, or a set of steps, are
repeated. Sometimes you can swap two steps or omit a step which is
not required, depending on your specific project situation.
Reference: The road map does not cover steps related to
project management and quality control. Refer to the Project
Management Method Handbook for more information on these
topics.
Business Process Modeling (RD.010)

Process Modeling within custom development can be split in two main
steps:
Define primary business processes (steps 1, 2 and 3).
Complete the Business Process Model (steps 4, 5 and 6).
The primary processes do not make up a complete set of all the

processes in the business area. There are many other supporting
processes, mostly low-level and consisting of a few elementary process
steps. Steps 3 to 5 use the technique of event-response analysis to
identify these processes.
1. Identify the Primary Processes
Identify primary processes by defining the business problems and
business objectives.
Reference: For more information, refer to the section,
Modeling the Business Context, of Chapter 2, Process
Modeling.
Tools: Process Modeler
Process
Modeller
2. Define Business Units

Define the hierarchy of organization units.
Modeling the Business Context, of Chapter 2, Process
Modeling.
Tools: Process Modeler; Creating an Organization Unit
Process
Modeller
3. Develop Process Flow Diagrams for Primary Processes

For each primary process, identify the events, process inputs, and
process outputs. Break the process down into process steps. Determine
the sequence of the process steps and define the process flows between
Oracle Method
process steps. Identify process steps that represent a business decision

and define the outcome. Identify the agents performing the process
steps and decisions.
Modeling Business Processes, of Chapter 2, Process
Modeling.
Tools: Process Modeler; FileNew
Process
Modeller
4. Identify Events to which the Business Area Responds

Identify and describe external, temporal, and internal events.
Modeling.
Tools: Process Modeler; Create Trigger
Process
Modeller
5. Identify and Document Business Processes Associated with each

Event
Identify and name the process associated with each event. Identify
process inputs and outputs. Describe the process. Identify current
systems support for the process and identify business issues associated
with each process.
Modeling.
Tools: Process Modeler; Create Process Step
Process
Modeller
6. Develop Business Process Flow Diagrams

Break the process down into process steps. Determine the sequence of
the process steps and define process flows between them. Identify the
agents performing the process steps. Consolidate process flow
diagrams for events that have similar responses.
Modeling.
Tools: Process Modeler; Create Process Flow
Process
Modeller
System Process Modeling (RD.100)

1. Identify Automated Process Steps
Identify online process steps and desired user-interface characteristics
(screen, report). Identify batch process steps. Determine the
mechanism of process flows (electronic, hard copy, verbal
communication, etc.). Define volume, frequency and availability
requirements for each process step.
Modeling.
Process
Modeller
2. Determine Interfaces with other Systems

Identify interfaces between the new application and other existing
systems.
Reference: For more information, refer to the sections,
Modeling the Business Context, and Modeling Business
Processes, of Chapter 2, Process Modeling.
Process
Modeller
Oracle Method
3. Develop System Process Flow Diagrams

Develop graphics to visually represent process steps with user
interfaces and include these where needed in the process flow diagrams.
Depict interfaces to existing systems on process flow diagrams.
System Process Model, of Chapter 2, Process Modeling.
Tools: Process Modeler; Iconic Mode
Process
Modeller
Entity Relationship Modeling (RD.040, RD.060, RD.080)

1. Define Entities and their Relationships
Reference: For more information, refer to the section, InterEntity Rules, of Chapter 3, Business Rule Modeling. You
can also refer to Chapter 4, Entity Relationship Modeling.
Entity
Relation
Tools: Entity Relationship Diagrammer; Create Entity,

Create Relationship
2. Define Attributes
Reference: For more information, refer to Chapter 4, Entity
Relationship Modeling.
Entity
Relation
Tools: Entity Relationship Diagrammer; Edit Entity

Attributes tabsheet
3. Define Constraint Rules

Define the different types of Static Data Rules:
attribute rules
define unique identifier rules
define tuple rules
define other entity rules
define inter entity rules

Inter-Entity Rules, and Recording Business Rules as a
Function, of Chapter 3, Business Rule Modeling.
Entity
Relation
Function
Hierarchy
Tools: Dependent of the type of rule: Entity Relationship

Diagrammer
Tools: Edit Entity Function Hierarchy Diagrammer; Create
Function, Edit Function Text tabsheet
4. Add Entity Detail

Define Volumes, Synonyms and detailed Entity Description.
Adding Entity Detail, of Chapter 4, Entity Relationship
Modeling.
Entity
Relation
Tools: Entity Relationship Diagrammer; Edit Entity

Definition, Synonyms and Text tabsheets
Function Modeling and Change Event Rules (RD.030, RD.070, RD.090)

1. Define Function Hierarchy
Define each function and its relationship to other functions.
Function Hierarchy, of Chapter 5, Function Modeling.
Tools: Function Hierarchy Diagrammer; Create Function
Function
Hierarchy
Oracle Method
2. Define Function Entity Usage and Function Attribute Usage

Function Entity Usage, and Function Attribute Usage, of
Chapter 5, Function Modeling.
Function
Hierarchy
Tools: Function Hierarchy Diagrammer; Edit Function

Entity Usage, Attribute Usage tabsheets
3. Add Function Detail

Define frequency, response (immediate or overnight), functions
triggered, and add function description.
Function Definition and Function Description, of Chapter 5,
Function Modeling.
Function
Hierarchy
Tool Function Hierarchy Diagrammer; Edit Function

Definition, Triggers and Text tabsheets
4. Define Change Event Rules

Define separate functions for rules that describe what will happen after
a change in the state of the data (creation, update, or deletion of an
entity or attribute) has taken place. This definition includes recording
the triggering event.
Change Event Rules, and Recording Business Rules as a
Function, of Chapter 3, Business Rule Modeling.
Function
Hierarchy
Tools: Function Hierarchy Diagrammer; Create Function,

Edit Function Entity Usage, Attribute Usage tabsheets
Authorization Rules (TA.090)

1. Define Lower-level Business Units
Define the hierarchy of organization units, including departments, user
roles, and managers.
Authorization Rules, of Chapter 3, Business Rule
Modeling.
Tools: Process Modeler; Creating an Organization Unit
Process
Modeller
2. Define Function Access Rules

Define which business units are authorized to perform which functions.
Business Unit Data Access, of Chapter 3, Business Rule
Modeling.
Process
Modeller
Tools: Matrix Diagrammer

Matrix
Tools: Repository Object Navigator

RON
Oracle Method
3. Define Vertical Data Access Rules

Define business unit data access if severe data security requirements
apply to your application system.
Function Access Rule, of Chapter 3, Business Rule
Modeling.
Process
Modeller
Tools: Matrix Diagrammer

Matrix
Tools: Repository Object Navigator

RON
CHAPTER
Process Modeling
T
his chapter describes guidelines for developing a process model. It

covers the following topics:
Oracle Method
Process Modeling Concepts and Benefits
Business Context Modeling
Modeling Business Processes
Modeling Primary Processes
Using Oracle Designer to Document Business Processes
Modeling Support Processes
Constructing the Business Process Modeling
Process Models and Function Hierarchy Models
The System Process Model
Verifying Process Models
Some Concluding Remarks
Process Modeling 2 - 1
Related CDM Tasks

The guidelines in this chapter apply to the following tasks of the
Custom Development Method:
Classic Approach:
Create Existing System Process Model (ES.040)
Create Business Process Model (RD.010)
Create System Process Model (RD.100)
Fast Track Approach:
2 - 2 Process Modeling
Create Existing System Process Model (ES.040)
Create Context Process Model (RD.005)
Create High-Level Business Process Model (RD.011)
Create Detailed Business Process Model (RD.049)
Revise Requirement Models (RD.115)
What is Process Modeling?

Process modeling is a technique for systematically describing the work
of an organization. It is based on the notion that an organization may be
viewed as a system. Organizations, like systems, receive inputs and
produce outputs to their environment. Systems consist of subsystems
that in turn accept inputs and produce outputs. In an organizational
system these subsystems are termed business processes. Process
modeling focuses development on these business processes, therefore
emphasizing the requirements most important to the business. By
focusing development efforts on the organizations business processes,
requirements vital to the objectives of the organization are emphasized.
Business Process Reengineering (BPR) is based on this idea. In order to
achieve radical, order-of-magnitude improvements in the performance
of the business, BPR focuses on the primary business processes which
produce visible output to the customer. These key business processes
are reengineered to improve efficiency, reduce bottlenecks, and
eliminate redundancy on an enterprise-wide level. Although BPR gains
can be quite significant, this level of effort requires the task to be
managed apart from any custom development and will typically occur
prior to software development. Business process redesign, on the other
hand, is a smaller scale task and fits within the scope of the Custom
Development Method.
Process modeling views business processes as systems which receive
input, produce output, and are triggered by events. Process modeling
specifies each detailed step within a process which must be performed
to transform the inputs into the process outputs. Additionally, process
modeling places every business process in its organizational context by
showing the organizational element responsible for each step in the
process.
A process flow diagram(PFD) is a visual representation of the workflow
performed in the execution of the business process, as well as the
information needs that arise during the execution. Some automated
approaches to process modeling, such as Oracle Designer, are able to
depict process executions that demonstrate timing of process steps and
can even include video and audio representations of process steps.
Oracle Method
Benefits of Process Modeling

No single modeling technique can completely capture the entire set of
business area requirements. To fully document these requirements,
CDM models the following views of the business:
a behavioral view modeled using process model diagrams
a functional view modeled using function hierarchy diagrams
an informational view modeled using entity relationship

diagrams
Process models provide the customer and developer with a dynamic

view of the business, one which describes the expected behavior of the
system. Business process models represent work actually performed by
the users and are therefore more real to them while the other two
models tend to be more abstract. The process models represent the
work of the organization and show how information is used. The
outputs they produce are tangible and essential to the organizations
mission. So, from the perspective of the customer, a process model is an
intuitive and natural description of the business defined in
understandable terms. These characteristics make the process model an
ideal feedback analysis tool. In a single view, the process model
describes business workflow in terms of the sequence of tasks, the
participating organizations, and the events which initiate them.
Process modeling does not replace other modeling techniques in our
methods toolkit. However, it provides additional analytical power and
lends itself to the rapid development of high quality applications. As a
powerful communications tool, an efficient technique for organizing
and representing requirements, and as a springboard for application
system design, process modeling provides the foundation for the
analysis and design of custom developed systems.
Downstream Benefits
In the development of user documentation and training, process models
have proven to be an effective tool. Because the process model shows
which user roles are responsible for performing which process steps,
training and user documentation can be designed for specific user roles
performing specific process steps. This greatly increases the ease and
efficiency of training material and documentation development.
The process model can also be used as a basis for developing testing
scenarios. Module tests can be constructed around individual process
steps; module integration tests correspond one to one with processes;
and system and systems integration tests can be developed for closelyrelated sequences of processes. Because the process model presents the
user view of the system, users can effectively participate in the design of
scenarios and test cases.
The Business Process Model

When we approach a client wanting a new system, our first task is to
define the business area that the new system will automate. To do this,
we need to understand the clients objectives and the business processes
that the system will implement. We also need a way of understanding
the size and complexity of the business area. The Business Process
Model provides an excellent means to understand, communicate and
document these aspects of the business area.
The Business Process Model represents the business requirements that are
within the scope of the project. The objectives of the business process
model are as follows:
to improve communication between the business analyst and

the business client about how work is actually performed
to show the sequence of steps used to produce the process

deliverable
to show how different parts of the organization work together

to execute a business process
to aid in identifying and evaluating process improvement

alternatives
to provide a framework for the development of new or

enhanced systems
The project team develops the Business Process Model during Business
Requirements Definition. It is a complete process model representation
of the business area. It includes the following:
Oracle Method
a definition of all events to which the business area must

respond, and the mechanism(s) used to recognize events
the sequence of elementary business functions that make up the

complete response to each event
the agents that perform the process steps
process flow diagrams representing processing performed by all

multi-step processes in the business area
an identification of appropriate process steps as elementary

business functions
an identification of the inputs and outputs; a description of the

processing for all elementary business functions; identification
of the agent, at the role level, that performs the elementary
process
Business Processes
A business process, in general, is the combination of operational steps and
management controls that, taken together, produce a product or deliver
a service. The central idea in this definition is that a business process
produces a result or output of some kind. The product or service may
be something that is received by an external customer, such as fulfilling
a customer order. Other business processes produce outputs that are
not visible to the external customer, but are still essential to the
effectiveness of the organization. Taking inventory or hiring an
employee are good examples.
Business processes occur as preplanned responses to business events.
An event is an occurrence inside or outside of the business environment
that causes an event response to execute. Event responses follow an
established, repeatable set of steps that make up the complete response
to the business event. The combination of an event and its event
responses form a process. A planned response system is comprised of the
entire set of processes in the business area. The Business Process Model
is the representation of the business areas planned response systems.
Processes may be modeled at different levels, depending upon the
breadth of the process steps that are defined. When performing
business process reengineering, an analyst usually works with highlevel processes, analyzing these processes at a macro level. Custom
development and application implementation, on the other hand, must
ultimately work with business processes at the elementary level.

The Business Process Model reflects the requirements of the business
processes that are to be supported by the new system. It does not
address the technical requirements that must be met to satisfy the business
requirements. This is the function of the System Process Model. The
System Process Model has three objectives:
to define the requirements for the system technical architecture
to define the requirements for the user interface
to enable users to visualize how the process will be executed

with the new system
The System Process Model expresses the technical characteristics of the

new system that must be fulfilled in order for the system to effectively
support the business requirements. Specifically, the System Process
Model includes the following information:
for each process step, delineation of where the user interface

boundary lies
for each event, the physical mechanism(s) by which the event

will be recognized (that is, phone call, electronic transmission,
batch operations schedule, etc.)
mapping of automated process steps to the types of processors

that will execute them
for each process step, identification of the type(s) of user

interfaces to the system (that is, GUI, block mode, radio
communications, hand held computer, etc.)
identification of electronic interfaces with other systems
a matrix cross referencing processes with the geographic

locations where they will be executed
By expressing requirements in terms of technical characteristics, the

System Process Model is the bridge between the analysis of the
requirements and the design of the application. There should be
sufficient information in the System Process Model for a system
architect to fully specify the technical architecture for the application.
Overview of Process-Oriented Development

In CDM, it is the Business Requirements Definition process that
identifies and defines the business needs of the application. The tasks
within this requirements gathering process have a process modeling
basis. As an analyst, you must first determine which processes support
Oracle Method
the organizations business objectives, thereby focusing the application

development upon these primary processes. Next, identify the external
systems and external entities which interact with the system as you
have initially defined it. This step sets the initial scope or context of the
application. Typically, you create a context process model to capture this
information. The scope of the context process diagram should include
all primary processes and external agents.
The team builds a context model to illustrate function area context and
high-level application system interfaces. Next, the top layers of the
business functions are organized into functional areas under the
business area. The Business Process Model is developed concurrently to
document all of the business events and subsequent responses that the
application must support. Finally, the team refines the function model,
detailing each of the business functions indicated in the process model.
While these tasks are being performed, the data model is built in
parallel with the function and process models to represent business
area information needs. This process is illustrated further in figures 2-1
and 2-2.
REPOSITORY
NAVIGATOR
BOBJ
Define and
Validate Business
Objectives
A20.090
PROCESS
CPM2
ID Primary
Processes
A20.090
ORGS
ID Business Units
(Agents)
CPM3
Create Context
Process Diagram
A10.030
A20.090
BPM
Complete
Business Process
Model
A20.090
SPM
Construct System
Process Model
B30.110
CPM1
ID External
Interfaces
A20.120
FUNCTION
DIAGRAMMER
BFM
Construct
Business Function
Model
A20.100
ENTITY
DIAGRAMMER
BIM
Construct
Business Data
Model
A20.110
DATAFLOW DIAGRAMMER
SFM
Construct System
Function Model
B30.100
SIM
Construct System
Data Model
A30.090
CIM
Construct
Context Data Flow
Model
(Optional)
Figure 2-1
Business Requirements Definition Process
Oracle Designer Support

Oracle Designer fully supports the Custom Development Method in
addition to many other structured methods being used in industry
today. In CDM, the Process Modeler is central to the Business
Requirements Definition tasks and is used to describe both the
behavioral and functional requirements of the system. It provides a
graphical interface into the repository allowing the team to define
Oracle Method
business events, processes, flows and stores as well as organizational

structures. The Process Modeler has additional capabilities to compute
the critical path and animate the flows through each process.
When using the Process Modeler in Oracle Designer to document the
business processes, the function hierarchy is populated automatically.
Each time a process step is created in the Process Modeler, it is stored as
a business function in the Oracle Designer repository. Specifically, each
root process is created as a root function and each process step within is
created as a child function to the root. These two modeling tools are
closely tied together, accessing many of the same elements in the
repository. Both tools must be used in a complementary fashion in
order to fully capture the business requirements. We discuss this
interaction between the two models in detail later in the chapter.
B u siness L ayer
Context
Scope
P ro cess & T ask R eference

B usin ess
P roc ess
M od el (B PM )
Process
C o ntext
M od el
(C M )
P roc ess
M od eller
Function
T op Laye r
B usin ess
F un ctio ns
(B F M )
P roc ess
M od eller
P roc ess
M od eller
H ig hleve l
B usin ess
F un ctio n
M od el
(B F M )
F un ctio n
H ie rarch y
C reate H ig h-level /
C o m po site B usin ess
F un ction M od el
(R D .030/R D .031)
z d o cu m e n t sc o pe o f
BA
z o rg a n ize a pp lica tio n
into F A s
z re-p a re n t/o rg a n ize
E B Fs u nd e r FA s
z rec o rd d e ta ile d E B F
d e sc rip tion s
z d o cu m e n t refere nc e
e n tity fun ctio ns
z review sc o pe o f E B Fs
E ntity
R e latio n
C reate Initial/ H igh L evel B u sin ess D ata

M o d el (R D .040/
R D .041)
z d o cu m e n t b u sin e ss
d a ta req u ire m e nts
z cre a te bu s in es s
e n tities , a ttrib utes
a n d re la tion sh ip s
F un c D ef.
F un ctio n
H ie rarch y
F un ctio n
H ie rarch y
Data
Initia l
B usin ess
D a ta
M od el
(B D M )
E ntity
R e latio n
Figure 2-2
Oracle Method
C reate (H ig h -L evel)
B u siness P ro cess
M o d el (R D .010/R D .011)
z illu strate fun ctio n
a re a c o ntext
z sh o w h ig h-le ve l
interfa ce s
z d o cu m e n t b u sin e ss
e ve n ts
z d o cu m e n t w ork
flo w s
z d e velop p roc e ss a n d
p ro ce ss s te p s (E B F s)
Oracle Designer Support for Business Requirements Definition
Modeling the Business Context

If your project is large or moderately sized, it is good practice to build
one or more context process diagrams. A context process diagram
provides a process overview of the entire business area for
understanding, discussion, and initial scoping. These diagrams help to
organize the processes on a high level and functions that you have
identified at this point.
The Business Process Model represents the business requirements within
the scope of the project. Although treated separately here, the Context
Process Model is typically considered a part of the Business Process
Model.
Business Area
When the need for a new system is determined, our first task is to
define the business area that the new system will automate. To do this,
we need to understand the clients business objectives and primary
business processes. We also need some way of understanding the size
and complexity of the business area. We can accomplish this by
answering the following questions:
How many processes are there?
How do the objectives of the project relate to the business

processes?
How many different agents are involved in executing primary

processes?
What information is needed for the processing?
Are the processes geographically dispersed?
The Context Process Model considers these issues by looking at the

business area as a system and its relationship to the environment. This
high level or contextual perspective provides a unique view of the
business area. It defines the scope by specifying what is inside the
business area and what is outside the business area.
The term business area is used to refer to the set of business processes
within the scope of a custom development project. Although the project
sponsor drives the definition of scope, we use process modeling to
expose and clarify what is in scope. Once process-based functionality is

understood we organize the business area by functional area in the
function hierarchy. We may then use the function hierarchy to establish
appropriate boundaries for the business area.
Defining Business Objectives and Primary Processes

In custom development, the primary purpose of process modeling is to
facilitate the development of a new system. Users want new systems
because they solve business problems. The first step in developing the
Business Process Model is to document the business problem and
develop a clear problem statement. This is accomplished by working
with the project sponsor and a few others close to the business area.
Start with a simple question, such as, What is the problem, and why do
you want a new system? You get the following types of answers:
Our inventory costs are killing us!
It takes too long to get a research project off the ground.
Our huge backlog of customer service calls is exceeding our

capacity to handle them. We are losing customers because of
it.
We get too many complaints from our customers that we are

billing them for the wrong products and amounts.
The next step is to recast the problem in terms of a set of business

objectives. Objectives are business conditions which, if met, will solve
the business problem. Well-defined objectives are measurable and often
relate directly to business processes and deliverables. For example:
to reduce stock by 75% without increasing inventory carrying

costs
to complete QA review of 95% of all proposals within 48 hours
to respond to 95% of all customer service calls within 24 hours
to reduce billing errors by 90%
Each objective directly or indirectly references a business process, for

example: Replenish Stock, Review Proposals, Provide
Customer Service, Bill Customers. Each business objective should
tie to a business process. The set of business processes, identified in
association with the objectives, represent the primary processes of the
business area.
Oracle Method
Elements of the Context Process Diagram

To create a context diagram, you must include the following elements:
primary processes
organizational units (also referred to as agents)
external systems
process flows
You may include the following elements, if necessary:
business events
decision and conditional flows
material or information flows
material or data stores
We have already discussed primary processes and how they are

determined from business objectives. The remaining elements are best
illustrated by an example.
Example
Hollywood Video Rentals

Description: Hollywood Video Rentals is a company with over 350
outlets nationwide. Hollywood rents movie videos and computer
games as their primary source of revenue. In addition, they also
sell videos, movie posters, and concessionaire snack items. The
company has recognized that the current process of procuring their
stock could use some improvement. Inefficiencies in the process
are eating up profits.
Hollywood has identified the business problems and objectives for the
Stock Procurement business area shown in the following table.
PROBLEMS
OBJECTIVES
Perceived lack of financial

control at Head Office
Provide visibility into stock procurement processes

for Head Office
Lack of standardized bill

paying across locations
nationwide
Provide rental stores a streamlined and simplified

procurement process they will follow.
PROBLEMS
OBJECTIVES
Excessive late payments to

vendors. Incurring late fees.
Some vendors now requesting
advance payment prior to
shipping.
Reduce late payments to less than 1% of total

payments.
Unable to perform effective cash

planning
Increase accuracy of cash planning to +/- 5% of

actuals.
Lack of centralized purchasing

process. Unable to take
advantage of volume discounts
Increase profit on unit items.
The existing Accounts Payable

system only handles Purchase
Orders, no alternative payment
methods handled.
Take advantage of existing system capabilities.
Reduce errors on invoices and accounts to less

than 1% of total payments.
Maintain high demand, with latest and greatest

items in inventory.
Given this information and the current organizational structure,

primary processes are developed which directly support the business
objectives. It is important to determine the relevant organizational units
and the primary processes they are responsible for. Each primary
process is added to the context process diagram in the responsible
agents channel. External interfaces are also included on the context
process diagram. Externals can be modeled as external agents or
alternatively as process step in the Unspecified agent channel.
Organizational units and external systems are discussed in the
following sections.
Oracle Method
EVALVENDOR
Evaluate and
Track Vendor
Performance
HEAD OFFICE
NOTIFY
Notify Stores
of Product
Availability
ACCOUNTS PAYABLE
FORECAST
Forecast Cash
E001 Requirements
INVOICE
Process
Invoices
PURCHASING
RENTAL STORE
CONTRACT
Award
Contracts
PURCHASE
Purchase
Products
ORDER
Order Items
RECEIVE
Receive
Goods
E002
INVENTORY
Unspecified
Triggering Events:
E001: End of Month
E002: Stock Low
Figure 2-3
Automated
Accounting
System (AAS)
Context Diagram for Stock Procurement
This context diagram captures the scope of the business area and also
conveys a general flow of the primary business processes. We have also
documented primary business processes, their responsible agents, and
all external interfaces all on a single diagram.
Notice that all the diagram elements are high level. The purpose of the
context process diagram is not to capture detail, but to capture the scope
of the business area through high level processes and flows. You may
also notice that the FORECAST process is not connected by any flows. At
the context level it is possible that we have several independent primary
processes in our business. We may also define the external interfaces to
our business by adding the external systems to our diagram as we have
with the Automated Accounting System shown in the Unspecified
agent channel. Now, how do we create these diagram elements in
Oracle Designer?
Using Oracle Designer to Construct the Context Process Diagram

To create a new context process diagram, begin with a new root process
called CONTEXT. This creates a separate hierarchy apart from any
functions you may have already entered into the repository. Select New
Diagram from the File menu, then click on the Create New Root Process in
the dialog box.
Create New
Diagram
Button
Create New
Diagram
Element Button
Create New
Diagram
Element Button
Figure 2-4
New Diagram, Create New Root Process
Once the new diagram has been created, organizational units

representing the business agents are added to the diagram. At this
point, you may either create new organizational units or, if they already
have been defined, you can include them by selecting the Include option
from the Edit Menu. Adding a process step or store is done in a similar
manner. Select the appropriate create button and click in the agent
channel where you wish to place the element.
Oracle Method
To further specify the agent, double click on the one you wish to edit.
The Edit Dialog Box appears and allows you to add or edit information
about the diagram element. This Edit Dialog Box behavior is standard
for all diagram elements in Oracle Designer.
Organizational Units (Agents)
RENTAL
STORE
The agents that perform the process steps are shown to the left of the
process rectangle. The rows running horizontally across the diagram
serve to separate process steps performed by one unit from those
performed by another. Agent names should be singular nouns.
The horizontal strip associated with an agent is called a swim lane, or
agent channel. In Oracle Designers Process Modeler, an agent is
defined using an organizational unit.
An agent refers to the party responsible for a process step. An agent
may be an organization, a functional unit such as a department or
division, an employee role, or a party external to the organization, such
as a customer or supplier. In our example, RENTAL STORE and HEAD
OFFICE represent functional units in the organization while ACCOUNTS
PAYABLE and PURCHASING represent departments within the HEAD
OFFICE.
Process
Modeller
Process
Modeller
Tools: When you decompose the Process Model into lower

levels in Oracle Designer, it is probable that you will move
into an area where only one sub organization unit is involved.
To be able to include this sub organization in the diagram,
you will first have to include the main organization unit,
before you can include the sub organization.
Tools: If you use sub organization units in Oracle Designer,
it is possible to open and collapse the swimlanes, to either
show only the top organization unit, or including the
detailed units. When the swimlanes are collapsed into the
top organization unit, all the steps in the detailed units will
be shown in that swimlane. Note however, when you open
the detailed organization units, the layout of your processes
have been changed.
There may be many agents that are involved in performing a primary

process. For instance, Purchase Products may involve the STORE
MANAGER, the VENDOR and the HEAD OFFICE PURCHASING DEPARTMENT.
In this case, you should indicate only the single responsible agent for the
process step. A process step should not span organizational units. In
the context diagram the higher level responsible agent should be used.
For example, use RENTAL STORE instead of STORE MANAGER and STORE
CLERK.
Process
Modeller
Tools: If there is a large amount of interaction between two

agents, it can simplify the diagram if they are placed next to
each other. To move an organizational unit, hold the control
key while pressing the up or down arrows. To change the
height of the channel, hold the shift key and press the up or
down arrow keys.
Process Steps
AP 4.3.1
Pay Supplier
All process steps must have a name that begins with a verb. Names
should be shown centered within the process step symbol. Include a
label as a text annotation to make the label visible on the diagram.
Place the label above the top left hand corner of the process step.
Process
Modeller
Tools: To create the label in Oracle Designer, double-click on

the process step to edit the properties. Select the Multimedia
tab, enter the label in the text annotation field, and set the
annotation type to Text.
Flows
A flow represents the sequential order of process steps. Primarily
used to show the order in which steps are performed, a flow may also
represent the movement of information or materials between
individual process steps or between process steps and stores.
The process flows should be drawn between the defined Process Steps.
These should be classified as either a Data Flow, a Temporary Flow or a
Material Flow. Flows can be drawn between the process steps in Oracle
Designer and can be classified as one of the three above, or just as a
Flow only. Only use this option if you do not yet know what kind of
flow it is. Normally you would also include the Temporary Flows at
this level (for example, Year end processing).
Oracle Method
It is often desired to be visualize the difference between the various type

of flows. You will not get this by default using Oracle Designer, but it is
recommended to provide this by using different line widths as shown in
the figure below.
Figure 2-5
Visualizing the Different Process Flow Types
The following drawing conventions are used for the flows:

Data :
Standard arrow width
Temporary : Arrow with width 5 times standard width
Material : Light Gray arrow with width 5 times standard width
Events
E0123
Each process flow diagram may show one or more events. A context
diagram can indicate one or more high-level events if they aid in
understanding the business area. Primary process diagrams, which
are described in the next section, should always have at least one
trigger event and one outcome event.
An event is shown as an open arrow, indicating the first process step
in the response to that event. Include only the event label in the
arrow, since the event name is most likely too long to fit neatly inside.
Also indicate the full names of the supported events in a legend on
the diagram. Legends can be added to a process diagram by using
the OLE 2 features of the diagrammer. Choose the menu selection
Edit>Insert New Object... to insert onto the diagram. Add the
appropriate legend text in the object. The included object is saved
with the process diagram.
A complete context process model includes external events. This could
for instance be a customer calling to order a specific product. The
events should be drawn as a trigger or an outcome in the Process
Modeler. From version 2 of Oracle Designer, you can classify the event
as an External event by choosing external as the Type of the event. Note
that this classification can only be performed in the RON and not in the
Process Modeler itself.
If you need to use the same external event as you used in the higher
level of the Process Model, then you need to open the event in the
Repository Object Navigator. Add the process step that the event
triggers under Triggering Functions, and the process steps that triggers
the outcome events under Triggered by Functions. When this has been
done, then you can include the events in the process model, by using
Edit->Include->Trigger, or Edit->Include->Outcome.
Stores
INVOICE FILES
A store on a process diagram represents a collection of information or

materials. For example, a store can represent a warehouse containing
finished goods inventory, a filing cabinet containing proofs of
delivery, or a database containing client details. A store is shown as a
rectangle with rounded corners.
The intent of including stores on a process model is to show only
significant data or materials which are of central importance within the
business area. It is neither necessary nor appropriate to show every
data store defined for the system in the process model. For example,
steps in the Receive Goods process will need to access inventory,
orders, vendors, and product stores. However, it is more appropriate
to deal with this interaction through a CRUD matrix or a dataflow
diagram. INVOICE FILES is shown on our process diagram only
because we wanted to highlight the fact that invoices are being stored in
more than one location.
Oracle Method
External Interfaces
You can represent flows to or from other systems in two ways. The first
approach uses the Unspecified Organization Unit to cover the external
area to the development. You then depict each external system as a
function/process step in the organization unit Unspecified. Use this
method when you need to represent, at most, a single flow to or from an
external system on the diagram. You can then show a process flow to
or from the system and any other process step.
If you must show multiple flows to or from a single system, make the
system its own agent. Depict process steps in the swim lanes that
correspond with functions executed by the other system. You can show
much more detail about the processing of the external system and the
flows to or from the business process steps in this way.
If you use this approach, then you can make the model more readable if
you color the external agents differently to the internal ones. In addition
you might find it useful to add an entry to the external unit to explicit
indicate that the Agent is external. The Externals are defined as an
external source or recipient of a specific flow. You can do this by
opening the external Business Unit in the Repository Object Navigator,
and then add the entry under the Represented by Externals node.
Process
Modeller
Tool: If you use colors in diagrams, then it is recommended

to use color printers to print the diagrams. If this is not
possible, then it is recommended to use bold letters, and the
following colors give good results using non-color printers.
The three first colors provides most variations in a
black/white print:
white
most light yellow
dark gray
light gray (prints darker than most light yellow)
most light blue (between light yellow and light gray)
Externals are systems, agents, or entities which are considered to be

outside the business area being modeled, but interact with the business
area in some manner. This interaction or interface can be accomplished
by sending and receiving data or materials, or by initiating events which

require some type of response.
Oracle Designer gives you several alternatives for specifying these
externals in the repository. In the Process Modeler, as previously
mentioned, externals can be modeled as agents and all external
functions can be assigned to the responsible external agent. In our
example, we chose a second alternative and modeled the external
system as a process step in the UNSPECIFIED agent channel. This
approach is similar to that taken by the Data Flow Diagrammer when
creating a Context Data Flow Diagram (DFD).
Process
Modeller
Tools: There is an important distinction to be aware of. In

the Data Flow Diagrammer, an External is treated and
marked as an External Entity, not as a function as it is in the
process modeler.
Attention: Some analysts are more comfortable using a DFD
to represent the context of the business. In CDM, the DFD
context diagram can complement the Context Process
Diagram but does not replace it. If we use the DFD, we must
model externals as global functions in the DFD to maintain
consistency between the two models. The process model
does not include entities, only stores. Therefore, external
entities defined in the DFD would not appear in the process
diagram. Conversely, the data flow model does not include
organizational units, so external organizational units would
not appear in the DFD.
Oracle Method
Modeling Business Processes

Processes may be modeled at different levels, depending upon the
breadth of the process steps that are defined. When performing
business process reengineering, an analyst will usually work with highlevel processes, analyzing these processes at a macro level. Custom
development and application implementation, on the other hand, must
ultimately work with business processes at a much lower level.
After developing the context process diagram, the next step in defining
the Business Process Model is to construct process flow diagrams for
each of the primary processes. Primary processes are easily recognized
-- they correspond to the main business objectives of the business area.
They often are triggered by external events and result in one or more
key visible outcomes.
Modeling Primary Processes

Primary processes occur as preplanned responses to business events.
An event is an occurrence inside or outside of the business environment
that causes an event response to execute. Event responses follow an
established, repeatable set of steps that make up the complete response
to the business event. The combination of an event and its event
response forms a process. A planned response system is comprised of the
entire set of processes in the business area. The Business Process Model
is the representation of the business areas planned response system.
Users provide a valuable information source for building the Business
Process Model. They should be familiar with the processes being
documented and therefore can assist you in identifying inputs, outputs,
process steps, and triggering events for the processes.
Primary processes usually consist of many process steps and involve
many different agents. For this reason, it will probably take the
involvement of more than one user to develop each process flow
diagram. The project sponsor will need to identify and gain the
participation of users to define each primary process. It is highly
recommended that the users who understand each process meet as a
group to develop the process flow diagram and document the process
steps.
Process Steps and Leveling

Business processes are made up of process steps. An important part of
process modeling is taking a process of interest and breaking it up into
the discrete steps that are required to execute the process from start to
finish.
Consider the process, Return Video Rental, consisting of the
following process steps:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Oracle Method
Present Returned Copy

Log Copy Return
Determine Excess Charges
Pay Excess Charges
Record Excess Payment
Check Bookings for Returned Title
Place Copy Back on Store Shelf
Place Copy on Reservations Shelf
Reserve Copy When it Becomes Available
Notify Member Product is in Stock
Example
MEMBER
E001
RENT 3.1[E]
Present returned
copy
RENT 3.4[E]
Pay excess
STORE CLERK
RENT 3.9[E]
RENT 3.5[E]
Record excess
excess payment
payment
Place copy on
reservations shelf
Yes
RENT 3.2[E]
Log copy return
Excess
charges?
No
Is this title
reserved?
Yes
E002
RENT 3.7[E]
Reserve a copy of a
pre-booked title when
it becomes available
No
RENT 3.8[E]
INVENTORY
Place copy back on

store shelf
E003
STORE MANAGER
RENT 3.10[E]
Notify member that
a copy of a prebooked product is
in stock
E004
Unspecified
Events:
E001
E002
E003
E004
Figure 2-6
Return of Copy
Copy Reserved
Copy Available for Rent
Member Notified
Process Flow Diagram for Return Rentals
Notice that the process step, Record Excess Payment, is at such a low
level that you would not break it down into smaller steps. This process
step corresponds to an elementary business function. All business
processes should at least be decomposed to the level where every nonexternal process step corresponds to a single elementary business
function. External process steps may, if necessary, be left at a higher
level, if knowing the details of these functions is not important.
What is an elementary business function (EBF)? An EBF (EBF) is a
function that, once started, must either complete successfully, or, if it
cannot complete successfully, must undo any effects that it has had up
to the point of failure. It is helpful to look at an EBF as a single
transaction. From the standpoint of functional decomposition, EBFs

exist at the lowest level of detail in a functional decomposition diagram.
EBFs correspond to elementary process steps. They are also the
fundamental unit of process modeling. Since elementary functions
participate in both models, they provide the linkage between the
function decomposition and the process model.
Agents (Revisited)
Agents represent who is performing the work of a process. From the
perspective of systems development, agents identify job functions that
will be automated. The combination of the process step and the
responsible unit provides a jumping-off point for designing user
interactions with a computer system in performing a specific job role.
Note that in the Return Rental example, each of the agents (Member,
Store Clerk, Store Manager) represent specific roles.
As noted previously, agents can represent any level in an organization,
from a business unit down to a specific job description. Using our
Hollywood Videos example again, agents that might be involved in the
process of purchasing videos for the company could be:
CONTRACT MANAGEMENT
HEAD OFFICE
VENDOR
STORE MANAGER
LOCAL VIDEO STORE
PURCHASING DEPARTMENT
ADMINISTRATIVE ASSISTANT
STORE CLERK
These examples show the different levels at which agents can be

identified. CONTRACT MANAGEMENT is a business unit within Hollywood
Videos. VENDOR represents an organization external to Hollywood that
supplies goods and services to the company. STORE MANAGER,
ADMINISTRATIVE ASSISTANT, and STORE CLERK identify specific
roles.
The generic definition of an agent as responsible party gives the
analyst a high degree of modeling freedom. For example, instead of
Oracle Method
using CONTRACT MANAGEMENT as the unit, we could have used

CONTRACTING AGENT. This detail may or may not be significant. From
the perspective of a new store manager trying to understand the
process, knowing that you need to contact a CONTRACTING AGENT
would be useful information.
The level of detail represented in the specification of an agent should be
driven by the level of the process or process step for which the agent is
responsible. The agent responsible for the process Purchase Products,
viewed at a high level in the context model, might be represented as
PURCHASING. Similarly, the agent CONTRACT MANAGEMENT identifies the
functional area responsible for awarding, monitoring, and terminating a
contract with a vendor. Viewing the process Award Contracts in more
detail, we would differentiate CONTRACT MANAGEMENT into FINANCIAL
ANALYST, PURCHASING AGENT, CONTRACTING AGENT, ATTORNEY, etc.
Include all parties who are responsible for carrying out any of the steps
within the process. Indicate at the user-role level, if possible. For
instance, if the STORE CLERK role is specifically responsible for the
process step Process Returns, do not use a high-level unit such as LOCAL
STORE.
Trigger Events
E0123
The Return Rental process is triggered by the event Copy Returned.

This event, whenever it occurs, causes the business to execute the
indicated series of process steps. We give the event a name (Noun,
followed by a Verb) as well as a label (in this case, E001) to easily
differentiate it in the Event Catalog.
Attention: It is very important to make sure that we identify
a complete set of triggering events during out analysis as this
set, the Event Catalog, will serve as a primary boundary of
functional scope for the application under development.
Primary process diagrams should always have at least one trigger event
(and at least one outcome event). An event is shown as an open arrow,
indicating the first process step in the response to that event. Include
only the event label in the arrow, since the event name is most likely too
long to fit neatly inside (for example Customer Requests Electrical
Service Where Facilities Exist). Also indicate the full names of
supported events in a legend on the diagram. See the previous section,
Events, for instructions on how to use Oracle Designer to do this.
There are three basic types of triggering events. Events can be viewed
as being external to the organization, internal to the organization, or
temporal in nature.
An external event is initiated outside the business area.
An internal event is initiated inside the business area.
A temporal event is when, under specified conditions, real time

reaches a predetermined date or time.
The triggering event Copy Returned occurs outside the business area,
so it is an external event. In this business area, an event such as Blank
Tape Inventory Falls Below Restock Point would be an example of an
internal event, since it falls within the boundaries of the business area.
The triggering event Close of Business Occurs is a temporal event that
may trigger many processes, for instance, Secure Premises or
Reconcile Daily Receipts.
Showing Process Steps

AP 4.3.1
Pay Supplier
Show process steps on the process flow diagram initially as

rectangles. All process steps must have a name that begins with a
verb. Names should be shown centered within the process step
symbol. Include a label above the top left hand corner of the process
step. See the previous section, Process Steps, for more information
on how to use Oracle Designer to do this.
In a business process model, process steps may be further categorized
as report or data entry process steps. The symbols are shown in the
following figure.
ORD 6.11[E]
REC 6
Record Received
Goods
List Overdue
Videos
The Report subtype is used

to show output from the
system.
Figure 2-7
The Data Entry subtype is

used to show input to
the system.
Process Step Subtypes
Besides defining your process steps as either data entry or report, you
also want to indicate which process steps correspond to elementary
Oracle Method
business functions. Do this by appending their labels with an E. This

way, when displaying the labels on the diagrams, all elementary
business functions are clearly marked as an aid in QA.
This makes it also easier to identify the true elementary functions when
viewing the related events. The triggering event of a process step will at
the same time trigger the first low level process step within that high
level process step (when it is decomposed). This may look confusing
when reviewing the event in the Repository Object Navigator (RON).
View the following example :
Figure 2-8
Events in Repository Object Navigator
It is obvious from this picture that the event only triggers one
elementary process step/function. This information is important when
the event should be implemented for the module(s) representing the
business function.
Also, if you choose to model external process steps, it is recommended
to prefix the Label with EXT, so that it is immediately visible that it is an
external function, for example EXT00001. It may also be useful to use
another color on the process diagram.
Attention: Manual processes are indicated by grayed-in
process step boxes. This designation is generally done in the
System Process Model, but some analysts prefer to signify
manual process steps earlier in the business model.
In the context process diagram of figure 2-3, we identified eight primary

processes. In this example, we will construct the process diagram for
the primary process Receive Goods. To fully define this process, we need
to specify the following:
1.
2.
3.
4.
5.
6.
7.
Example
A description of the primary process

Individual process steps within the primary process
Flows to and from each process step
Events which trigger the primary process
Resulting outcomes of the primary process
Agents, specified at the lowest organizational unit
Any key stores
Hollywood Video Rentals

Description of the Receive Goods Process: The Receive Goods
process is followed by each local store whenever a shipment
arrives. The store clerk is responsible for making sure that the
products received are properly processed and put on the shelves for
the customers. The clerk is also responsible for making sure the
goods are checked for damage and reports any defective items to the
head office. If movies are received as part of the shipment, the
availability of the new titles are announced to the other stores in
the area. The store manager handles the paperwork and processes
the invoice that came with the shipment. He makes sure the invoice
matches what was shipped and then pays the supplier for the goods
received. A copy of the invoice is sent to the Head office and the
original is filed at the store. If there are any problems, such as
mismatches between the invoice and what was actually shipped, the
store manager contacts the vendor to resolve the problem.
Oracle Method
INV5.2[E]
STORE CLERK
Add a new
copy to the
inventory
REC1[E]
E003
Check
Shipment to
Packing List
INV12
Test Video
Video Shipment
Existing Title?
Yes
INV5.3
Yes
No
Define New
Title
No
REC11[E]
REC6[E]
Record
Received
Goods
INV5.1
Notify Head
Office
E005
Notify Other
Stores of New E006
Title
HEAD OFFICE
INVOICE
FILES
REC9
STORE MANAGER
Call Vendor
with
Problems
REC8
E004
Review
Invoice
AP4.3.1
REC10
Match
Invoice
Pay Supplier
Invoice
OK
Unspecified
Triggers
Outcomes
E003: Shipment Arrives E005: Receive Results
E004: Invoice Arrives E006: New Title Notice
INVOICE
FILES
(LOCAL)
Figure 2-9
Hollywood Receive Goods Process
As we can see on the diagram, two external events: Shipment Arrives

and Invoice Arrives trigger this process and are depicted as open
arrows pointing into the first process step. Two outcomes are also
identified: Receive Results and New Title Notice. These outcomes
are placed against the process steps which produce them. The
individual process steps are placed on the diagram within the
responsible agents channel and the sequence of steps is documented by
connecting the process steps with flows in the order they are
accomplished.
Notice that instead of simply assigning the process steps to the agent
STORE, we assigned the steps to the roles STORE MANAGER and STORE
CLERK. In this way we specify the individuals in the organization who
actually perform the tasks.
Process Flows (Revisited)

A process flow represents the sequential order of process steps. They
are primarily used to show the order in which steps are performed.
A flow may also represent the movement of information or materials
between individual process steps or between process steps and
stores.
Show the flow of material or information between process steps only
when it is important to the understanding of the process. Use a solid
arrow with a label indicating the information or material that moves
from one step to another. In this way you can show how information
moves from one step of the process to another, or from a step into a
store, or from a store to a step.
Invoice
The following table provides the subtypes available for a flow:

Subtype
Description
Temporal flow
Represents a time-based dependency,

indicating that the process step at the
destination of the flow cannot begin until a
process step at the source of the flow has
been completed. Most commonly used flow.
Data flow
Represents the flow of information between

two elements.
Material flow
Represents the flow of tangible objects

between two elements.
Showing Decisions
Decision points are represented in the diagram as a diamond symbol.
Decision points show places in the process sequence where the result
of a decision determines which one of several paths will be executed.
No:25%
Test
Successful?
Yes:75%
The decision point is a marker that gives the decision visibility. If

decisions determine different process flows, you should include them
in the diagram.
Decision steps allow the specification of conditional flows, that is, flows
that are followed only if certain conditions are true. In this way,
multiple routes through the process can defined as well as the
Oracle Method
conditions which determine the route. Show a flow from the decision
point for each possible outcome. Each outcome of a decision is mutually
exclusive, in other words, only one path is executed for a given
condition.
Label each flow with the name of the outcome and optionally, the
percentage frequency of the outcome (for example: Yes: 75%/No: 25%,
Excellent: 10%/Good: 40%/Fair: 45%/Poor: 5%, Residential:
99%/Commercial: 1%). For example, a process might include a
decision point that tests whether the cost of a particular operation is
greater than a certain amount. The decision point could then have two
flows attached, one with a rule labeled "Cost >= 5000" and one with a
rule labeled "Cost < 5000". Different process paths are constructed to
illustrate what happens in either case.
Outcome Events
The previous example Return Rental shows three outcome events: Copy
Reserved, Copy Available for Rent, and Member Notified.
Outcome events are used in a process model to document the possible

reactions a process has to the triggering event(s). In this case, when a
copy of a video is returned, it is either made available for rental again or
it is reserved and the reserving member notified. The conditions under
which the outcomes occur are defined by the individual process steps in
the diagram.
Indicating Stores
INVOICE FILES
A store on a process diagram represents a collection of information or

materials. For example, a store can represent a warehouse containing
finished goods inventory, a filing cabinet containing proofs of
delivery, or a database containing client details.
The intent of including stores on a process model is to show only
significant data or materials which are of central importance within the
business area. It is neither necessary nor appropriate to show every
data store defined for the system in the process model. For example,
steps in the Receive Goods process will need to access inventory,
orders, vendors, and product stores. However, it is more appropriate
to deal with this interaction through a CRUD matrix or a dataflow
diagram. INVOICE FILES is shown on our process diagram only
because we wanted highlight the fact that invoices are being stored in
more than one location. As a general rule, only add stores to a process
diagram when it aids in the understanding of the process flow.
You may want to distinguish between certain types of stores. You may
specify a store subtype as either a data store or a material store. If you
use subtypes for flows and stores, these should be consistent. For
example, a material store should have a material flow going into it, not
a data flow.
INVOICE
FILES
VENDOR
WAREHOUSE
Oracle Method
An open, rounded rectangle represents a store of data, such as a

computer system.
A closed, rounded rectangle represents a store of material, such as a
warehouse.
Using Oracle Designer to Document Business Processes

You should use Oracle Designer to document primary business
processes. Create a process flow diagram for each primary process.
You can create a new diagram in the same way that you did to create
the context process diagram. Simply highlight the process on the
context diagram that you wish to create a diagram of. Then, choose the
File>Open Down menu selection. A new diagram will be created.
Navigating the Process Diagram Hierarchy

Our Business Process Model consists of at least one context process
diagram and at least one additional diagram for each primary process.
How do you create this hierarchy of diagrams and how do you navigate
through them?
We could simply use the Create New Diagram option under the File
Menu, but there may be problems with this. The new child process
diagram would not be linked to the current parent unless the function
had already been defined and we based the new diagram on that
function.
Instead, we select the Open Down option under the File Menu, or we
open another menu by using the right mouse click. To do this, first
select the process step from the context process diagram you wish to
define, then select Open Down. The process modeler then creates a new
diagram linked to the parent. The diagram will automatically bring in
the agents from the parent diagram and also any functions which may
already be connected to the parent function. To avoid confusion later,
make sure to save the diagram before leaving it. This way, if later you
reparent the functions in the Function Hierarchy Diagrammer, your
process diagram will remain unchanged unless you requery the data.
After the diagrams are created, subsequent uses of the Open Up and
Open Down options will open the desired diagram and make it the
active window in the Process Modeler. Note that when you will use
Open Up no process steps must be selected.
Drill Down
Option in right
mouse click menu
Open Up
Option in right
mouse click menu
Figure 2-10 Navigating through the Process Diagrams
Oracle Method
Elements and Subtypes

A process diagram consists of five basic diagram elements: events,
process steps, process flows, agents, and stores. With the exception of
agents (organizational units) each of these elements can be more
specifically defined as being a particular type of element. Once you have
specified the basic diagram elements, you will want to make another
iteration through the diagrams to add subtype information where
necessary. In Oracle Designer, all diagram elements will default to the
generic element type unless you specifically select the subtype on
creation, all diagram elements can be further defined as subtypes. You
can specify the subtype when you create the element or you can edit it
via the Specific Tab in the Edit Dialog Box.
Figure 2-11 Process Steps Tab in the Edit Dialog Box
Oracle Designer has three viewing modes available under the View
Menu. They are: Symbol, Enhanced Symbol, and Iconic. In the Symbol
mode, no visual distinction is made between subtypes on the diagram.
All process steps will appear as rectangles. In the Enhanced Symbol
mode, different shapes are used for process step subtypes and store
subtypes only. Event subtypes always appear as an open arrow and
flow subtypes as a line arrow. If you want to make a visual distinction,
use the Preferences options to do so.
Specifying Agents and Organizational Hierarchies

Oracle Designer allows you to define and display the organizational
hierarchy on the process diagram. This option works well when it is
important to show the part an organizational structure plays in the
process. Whenever an agent is included in the diagram, the process
modeler will also include the agents parent organizational as well.
Attention: This can result in unwanted agents cluttering the
diagram. It is more appropriate to define the role level agents
without parent organizational units. In this way you may
include the role level agent without including the entire
organizational structure above it.
The quickest way of creating the organizational structure of the business
is through the process modeler. By selecting the New Organizational
Unit tool button and then clicking on the parent organizational unit, the
modeler automatically links the two together. To reparent an existing
organizational unit, double click on the child unit to edit the properties
and change the parent unit there.
The Edit Dialog Box gives you the ability to specify the parent
organization and also designate the unit as a role. You should try to
assign all non-external process steps to role level agents, except when
you are working at the context level.
Oracle Method
Figure 2-12 Organization Edit Dialog Box
Designer brings in the entire hierarchy when you include an agent in the
diagram.
Specifying Process Steps

Process steps can be subtyped as Data Entry, or Report (decision points
are also entered as a type of process step more on this later).
Remember, these are represented on the diagram as Enhanced Symbols
only when the proper view mode is selected. Otherwise, all process
steps appear as rectangles. As a general rule, the Enhanced View Mode
should be used as the default.
Adding function labels to the process steps enhances the Business
Process Model by making it easier to cross reference the function
hierarchies to the process diagrams and to locate particular functions.
To add the labels, first make sure to check the Use Multimedia on
Database option under the Options>Customize>Advanced Menu. This
way, the label can be added once and it will then be used in every
diagram where the function is. Without this option checked, each
diagram would have to be updated separately. Next, using the

Multimedia Tab in the Edit Dialog Box, set the Annotation Type to Text
and enter the label name in the Text field. If the step is an Elementary
Process Step, append the label name with an [E].
Figure 2-13 Adding Function Labels to a Process Step
The Repository Object Navigator is a good place to enter the label into
the Text field. You can see whether the function is elementary or not
and then simply cut and paste the label appending the label as required.
The labels can be toggled on and off by selecting the Annotation option
under the View Menu.
Oracle Method
Including Global Process Steps

In the Process Modeler, the Include option under the Edit Menu allows
you to include a Process Step or a Global Process Step to the current
diagram. The difference in the two options has to do with how the
processes are hierarchically related.
Figure 2-14 Include Process Step Option
If the process step you wish to include is a child process step to the
current process, you would use the Include Process Step Option. This
option would be used, if say, you cut a process step from the diagram
(not deleted it from the repository!) and you wanted to return it back to
the diagram. If, however, the process step appears anywhere else in
the hierarchy, you must use the Include Global Process Step option. See
the topic, Eliminating Common Functions in the next section. The
following figure illustrates the point.
GLOBAL
GLOBAL
Current
Process Step
INCLUDE
INCLUDE
INCLUDE
GLOBAL
GLOBAL
GLOBAL
GLOBAL
GLOBAL
GLOBAL
GLOBAL
GLOBAL
GLOBAL
Figure 2-15 Includes versus Global Includes
Drawing Flows
Flows are created by first selecting the Create Flow button on the Tool
Bar, selecting the originating process step, and then selecting the
destination process step. In the edit dialog box which pops up, you can
optionally name and select the type of flow. More detailed information
on the flow can be added by editing the flow. You should not name
temporal flows. You should name data or material flows to explicitly
show the flows content on the diagram.
Oracle Method
Including Decision Points and Conditional Flows

A flow can be made conditional by including specifics for the flow:
Figure 2-16 Labeling Conditional Flows
A decision point is created as a process step of subtype decision within

the Process Modeler.
When modeling decision points, label each outgoing conditional flow
with the condition that activates it. The condition under which the flow
is activated is called a rule. To show this condition on the diagram, use
the Rule field on the Specific Tab of the Edit Dialog Box and check the
Display Box in the Rule group. To display the flow percentage with the
rule, you must append it to the value in the rule field. The number
entered in the Flow Percentage field does not display on the diagram.
Including Triggering Events on the Diagram

Use Oracle Designer event types external, internal, and time to describe
external, internal, and temporal events respectively. Add trigger events
on the diagram by first selecting the Create Trigger button on the Tool
Bar then selecting the first process step in the sequence. Note that the
external and internal types for the events only can be entered in the
Repository Object Navigator.
Including Outcome Events

Outcome events have the same subtypes as triggering events and are
created in the diagram by first selecting the Create Outcome button on
the Tool Bar then selecting the last process step responsible for that
particular outcome.
Modeling Support Processes

This section discusses the following topics:
Refining the Business Process Model
Event Response Analysis
Examining Event Mechanisms
Refining the Business Process Model

At this point in our example, we have specified important aspects of our
business area, but only partially. Our analysis is still incomplete. We
need to identify additional processes for the business area which are not
included as part of the primary processes. In addition, many of the
process steps already defined need to be refined to add additional
details and supplemental information must be collected for the diagram
elements.
The primary processes do not make up a complete set of all the
processes in the business area. A business area typically includes many
other processes. Many of the additional processes exist to support the
primary processes. Many of them update one, or a few, stored data
items. Some examples of these types of processes might be:
Oracle Method
change distributors address
check if reserved item is available
change passengers seat
receive returned rental item
cancel a reservation
change a customers credit rating
customer returns damaged tape
patient arrives for appointment
These support processes must be uncovered in sessions with the users.

Event response analysis can be a useful mechanism to identify these
processes.
Event Response Analysis

All business processes can be considered as planned responses to
business events. An event is simply an occurrence that causes a
response to execute. Some examples of processes that are responses to
events are:
Response
Event
Customer Places Order
Fulfill Customer Order
Position Opens
Hire Employee
Request for Proposal Arrives
Prepare Proposal
Year Ends
Prepare Tax Return
The most effective way to identify these types of processes is through

event-response analysis. This is best accomplished with a group of users
who understand the day-to-day workings of the business area. We start
event-response analysis by returning to the view that the business area
is a system with planned responses to events. We ask the user to
identify the events external, internal and temporal for which the
business area has a planned response. Providing the users with a few
familiar examples of events and responses greatly facilitates their ability
to perform this exercise. If the users work as a group on this, it usually
takes less than a day to come up with a reasonably comprehensive list
of events.
The next step is to name and describe the process response for each
event. Again, you can gather this information most efficiently by
working with the users in a group session. The information you should
collect for each process includes the following items:
name of the event
name of the process
process inputs
process outputs
description of the process or list of process steps
elementary business function (y/n)?
In developing these details, utilize the users terminology in the written

documentation.
You should gather additional information about each process,
including:
current systems support
business issues associated with the process
frequency of process execution
average time and cost for a single execution
The information you gather and the amount of detail you include
should, to some extent, be driven by the business problem and
objectives. If current systems are an issue, then document the current
system. If cost competitiveness is an issue or if activity-based costing is
of interest, you may want to record cost.
Many of the process steps you identify in this way are elementary
business functions. Since these EBFs have been identified
independently of the function hierarchy, you can build the function
model from the bottom up, either by finding or creating the appropriate
functions under which to group them. This can be a much faster way of
building the function hierarchy than following a strictly top-down
decomposition approach.
Some of the process steps discovered through event-response analysis
may not be at the elementary business function level. You should break
these steps down until you can create a process flow diagram for each
process that consists of a sequence of elementary business functions.
Examining Event Mechanisms

You may find that events that you have documented actually
correspond to several different events. Consider the example of the
event Customer Requests Service causing the process response Provide
Customer Service. On further analysis, this event may be found to
actually represent several types of service request events. If this is
determined to be the case, simply include the more specific cases on the
appropriate process diagrams. A utility company, for example, may
have many types of service request events:
Oracle Method
customer requests setup of service
customer notifies company of power outage
customer notifies company of faulty meter
customer requests termination of service
customer notifies company of downed line
The event Customer Requests Service is really the most general case of
these different types of events.
Event mechanisms identify the various ways in which an event is
recognized. For example, the arrival of a timesheet may be via
electronic mail, surface mail, or fax. A customer order may be placed
by phone or through the mail. The ultimate deliverable the fulfilled
order, is the same, regardless of which mechanism is used; but details of
the process execution may be very different. If the customer places an
order by phone, a clerk may enter the order in the system while the
caller is on the phone. When an order is received by mail the process
steps may be:
1. Stamp the order with the date received.
2. Check the order for errors.
3. Enter the order into the system if there are
no errors.
4. Return the order to the customer with a
request to fix the problem if there is an
error.
Steps 1, 2 and 4 are not performed when the order is received by phone.
If there is more than one mechanism by which an event can be
recognized, and the event response is significantly different depending
on the mechanism, you should model the differences. The best way to
do this is by considering each event-mechanism combination as a
different event and producing a process flow diagram for each. Using
the above example, we would have two different events:
1. Customer Phones in Order
2. Customer Mails in Order
You would then develop a process flow diagram for each event.
If the responses to an event recognized through more than one
mechanism are similar, you can use one diagram, but show each
mechanism on the diagram as a separate event.
Constructing the Business Process Model

The project team develops the Business Process Model during Business
Requirements Definition. It is a complete process model representation
of the business area. It includes the following:
Oracle Method
the definition of all events to which the business area must

respond, and the mechanism(s) used to recognize events
the sequence of elementary business functions that make up the

complete response to each event
the agents that perform the process steps
process flow diagrams representing processing performed by all

multi-step processes in the business area
an identification of appropriate process steps as elementary

business functions
an identification of the inputs and outputs; a description of the

processing for all elementary business functions; identification
of the agent, at the role level, that performs the elementary
process
The following figure shows the major steps necessary to construct a

business process model. Notice that specifying the primary processes is
only part of the task. We must also refine the diagrams and add
additional detail. We also will perform event response analysis to help
us uncover other processes in the business model, such as maintenance
and support processes. Finally, we perform a quality check on the
model making sure it accurately reflects the business area and that the
diagrams conform to standards.
PROCESS MODELER
BPM3
BPM1
Specify Primary
Processes
Perform Event
Response Analysis
Specify Remaining
Triggers & Outcomes
on Process Diagrams
BPM6
BPM2
Refine Agents to
Role Level
FUNCTION HIERARCHY
DIAGRAMMER
BPM4
Refine Processes to
Elementary Process
Step Level
QA PROC
Quality Check
Diagrams for
Accuracy and
Standards
MULTIMEDIA
Add Multimedia to
Process Diagrams
BPM5
ID Support and
Maintenance
Processes
REPOSITORY OBJECT
NAVIGATOR
BPM7
ID Current System
Support for
Processes
Unspecified
Figure 2-17 Constructing the Business Process Model
Other Process Modeling Concepts

This section discusses other process modeling concepts. It includes the
following topics:
Diagramming Similar Event Responses
Handling Complex Diagrams
Single Step Processes
Multiple Inflows and Outflows
Diagramming Similar Event Responses

If we were developing a process flow diagram for the process Provide
Customer Service, we may identify many different triggering events. If
the response to each of these events is the same, or very similar, there
would be no benefit to developing a process flow diagram for each
event. The additional diagrams would contain little or no new
information, and would require significant time to create and maintain.
If there are significant differences in the planned responses to each of
these events, a separate PFD for each event would be useful. Each
diagram would show requirements that might otherwise be lost or
obscured on a single diagram.
Quite often, reality lies somewhere between these two extremes. You
must decide whether a single PFD is sufficient or if multiple diagrams
representing more specific types of events are needed. The number of
decision steps in the PFD can be an important indicator in determining
the need for breaking up an event. It may be possible to eliminate some
of the decision steps and separate pathways by differentiating the
triggering event into different events, and developing the PFDs for these
separately.
Handling Complex Diagrams

In Oracle Designer, you can represent a complex process using multiple
diagrams. First, represent the process on a single master diagram and
include all high-level or continued process steps that are detailed on
other lower level diagrams. Be sure to exactly match the label of the
continued process step with the name of the new process diagram so
that readers are able to quickly navigate through the set of diagrams
and follow the process steps through the model. Oracle Designer does
Oracle Method
this automatically. Simply accept the default naming conventions for

the diagrams. Oracle Designer prompts you with the short description
of the process step when naming the diagram. This process of opening
down is continued until all process steps are at the EBF level.
PROD 3
Deliver Product
to Customer
A continued process step should be shown as a bolded rectangle on

the diagram. In this way the reviewer can immediately see that
additional detail is available. The name of the continued process step
should exactly match the name of the PFD on which the detailed
steps are shown. To display a process step as bold, first select the
process step, then select the Change line width button on the Tool Bar.
Single-Step Processes
Although most processes are both multi-step and cross-functional, it is
possible that the planned response to an event is a process that can be
executed in a single process step. These responses are called simply
single-step processes and do not have to have separate process diagrams.
Single-step processes are typically captured only as functions in the
function hierarchy. Examples of single-step processes might be: Change
Customer Address or Add Customer Type.
Many of these single-step processes are referred to in system analysis as
data entry or reporting processes. These processes involve recording a
change of some factual information in the stored memory of the
organization or providing a report on stored information. Without
knowing more about the business, it is not safe for the analyst to assume
that these are simple processes, but experience may suggest that they
are.
Multiple Inflows and Outflows

A process step may have multiple flows coming in and/or out. All
outflows are assumed to begin once the process step is complete.
For multiple inflows, it is possible use the AND/OR feature to define
the combination of inflows which initiate the process step. Under the
Specific tab in the edit dialog box, you can define the flow logic as either
AND or OR. This group of option buttons specifies what happens if the
process step at the destination of this flow has more than one flow
coming into it. Selecting the OR option button specifies that the
destination is activated as soon as either this flow or another flow (or
group of flows that are ANDed together) is completed. Selecting the
AND option button specifies that the destination is activated only when
all the flows marked AND are completed.
Process Models and Function Hierarchy Models

You and your team will discover many, if not most, business functions
through process modeling. The business functions of a few processes
may be contained wholly within a single functional area. However,
most processes are cross-functional, meaning they include process steps
from more than one functional area. An example of this would be the
process of manufacturing an item according to customer specifications.
The process in this example would be triggered by the placement of an
order with Sales, and include steps in the Design, Manufacturing and
Distribution business functions.
Because the process model is the model that the users relate to the most,
it is recommended to keep the process model as the primary model
when modeling the business. You should keep in mind that you should
not change the Process Hierarchy created by the process modeler, as you
then also change the actual process models..
During Process Modeling your team will also discover functions that
are so common that they appear as part of the execution of many
process flows. For example, the function Check Customer Credit may
appear as a process step in the processes Log Customer Order, Open
Additional Account, and Process Shipments. You want to specially identify
these functions.
If your development project is of any size, the default process-wise
organization of elementary business functions that results may not serve
your team well. It will become cumbersome as you move into detailed
analysis -- where a deeper knowledge of functional areas is required -and especially as you move into the design and construction phases of
the project. You may need to organize your EBFs more efficiently by
using the function hierarchy to represent the net usage of all of the
applications functions.
Especially if your project is a Fast Track project, you need to consider
whether it is required to create a separate function hierarchy model for
your project. When using the Process Modeler, you also eventually
reach the elementary functions. Creating a function hierarchy in
addition to your process hierarchy naturally takes more time, than only
using the process hierarchy. Therefore, you need to weigh the benefits
of what the function hierarchy provides the project against the
additional time and effort that is required to include it and keep it upto-date.
Oracle Method
A process provides a picture of a complete set of responses to an event

until a result is provided. Particularly on a high level, this provides a
cross functional picture where the process flows through a number of
functional areas. A function model, on the other hand, provides a
picture of the functionality grouped per functional area. This picture
makes it more easy to verify whether the activities within the functional
areas are complete. For example, when discussing the business
processes, do not define all the business functions required to set up
specific Business Reference Data. When grouping the functions per
functional area, it is often easier to identify gaps within that functional
area. When drawing the business processes, it is easier to identify gaps
in the business workflow.
Recall that in building process models, our goal is not to create a formal
decomposition of functions, but to fully define our business processes
down to the lowest level business tasks. In doing so, we are not
classifying and categorizing these tasks, but organizing them by process
decomposition. As a result this Process Hierarchy does not properly
represent the functional scope of our system. It is easier to have them
organized under the Application Hierarchy, thereby creating a smart
catalog of functions. The Application Hierarchy fully represents the
functional scope of our business area.
When you in your Fast Track project makes the decision on whether to
create a separate Application hierarchy, keep in mind that you should
develop for Fitness for Business Purpose. Determine whether it is a
must have for your development. For businesses that are not traditional
and unknown to the developer organization, it might aid the
understanding of the business, especially if there are a lot of processes
crossing different functional areas.
By creating an Application Hierarchy the level of effort of our
application is more visible. In the Application Hierarchy functions are
refined, manual functions are eliminated and further identification of
elementary business functions is performed. In this way we also
determine the automation boundary of our application. You can also
refine your functions by only using the Process Hierarchy, nevertheless
the Process Model will always contain a complete set of functions and
not only those you will automate.
Functions and Processes

Functions are defined as something an enterprise must do to achieve its
objectives. This definition does not carry with it the same constraints as
the definition for process a planned response to a business event,
consisting of a sequence of operational steps that produces a product
and/or delivers a service. We identify and define functions without the
criteria that are inherent in the definition of processes.
At the highest level in a functional decomposition, functions are
groupings of related activities Sales, Marketing, Manufacturing,
Distribution, etc. High-level functions include processes, but from a
modeling perspective, we should not attempt to achieve a one-to-one
correspondence between functions and processes at the top levels in a
functional hierarchy. In fact, one of the very important advantages that
process modeling brings to the table is that it provides a cross-functional
perspective. Process modeling enables us to understand business
activity as it crosses functional boundaries. It accomplishes this by
allowing us to see interactions between process steps that are in
different subtrees of the function hierarchy.
When processes are fully specified, the process steps are defined down
to the elementary business function level. At this level, there is
necessarily a one-to-one correspondence between the elementary
business functions in the function model and the process steps in the
process model. If you make both hierarchies, then as a quality
assurance step, you should make sure that each elementary process step
equates to an elementary business function in the function model and
each elementary business function either appears in the process model
or is a single-step process in itself.
Oracle Method
The relationship of elementary process steps to elementary business

functions is shown in the following figure.
Application
Hierarchy
F1: Sales
F2: Operations
F3: Accounting
F11
F21
F31
F12
F22
F32
F13
F23
P02.2
P02:Take Custom
Order
P31: Assemble
Product
P02.1
P31.1
P02.2
P31.2
P02.3
P02: Take Custom Order

P02.1
Process
Hierarchy
Deliver Product To Customer

Effectively
Deliver Product To Customer

Effectively
P02.3
P31.3
P31: Assemble Product

P31.1
P31.2
P31.3
Figure 2-18 Relationship between the Process and Application Hierarchies
Building and Using Function Hierarchies with Oracle Designer

When creating both hierarchies, then you should develop the function
hierarchy in parallel with the Business Process Model. When you begin
the process of defining business requirements, create a high-level
functional area hierarchy or Application Hierarchy in addition to the
context process diagram. In the previous figure, an application
hierarchy was created with three functional areas: Sales, Operations,
and Accounting.
At this point two function hierarchies actually exist in the Oracle
Designer repository, the Application Hierarchy representing just the
functional areas and the Process Hierarchy created when we built the
context process diagram. The application hierarchy is completed by
reparenting the significant elementary process steps in the process
hierarchy to the appropriate location in the application hierarchy. The
process models remain intact after this reparenting. Figure 2-18 also
shows the relationship between the two hierarchies.
Building The Application Hierarchy

A top-level function hierarchy is created first to establish the primary
functional areas in the organization. Process models are then created to
document business events and processes within the organization.
Top Level Function Model
Hollywood
Rent Videos
Manage Inventory
Manage Sales and
Marketing
Figure 2-19 Example of a Top-Level Function Hierarchy
Oracle Designer stores process steps as business functions in the

repository. The root process that the diagram is based on also
automatically creates a corresponding root function. As each of the
subsequent process steps are added to the diagram, they are stored as
child functions under the root function in the repository.
This automatic creation of parent and child functions creates a default
Process Hierarchy in the repository. When creating an Application
Hierarchy you need to reparent the functions under the appropriate leg
of the top-level function hierarchy.
Oracle Method
Process steps become functions which

reference the parent function by default,
Decision creating a default functional hierarchy
Point
Return Rentals
Return Rentals
Pay
excess
Change
Status
Record
payment
reserved
?
No
Pay Excess
No
Record Payment
Put on
Rental
shelf
reserved?
Put on Rental Shelf
Yes
Notify
member
Put on
Reseved
shelf
Notify Member
Put on Reserved Shelf
"Common"
process steps
Add Copy to Inventory
Receive
from
shipping
Change Status
Add Copy to Inventory
Change
status to
Available
Assign inventory code
Assign
inventory
code
Receive from shipping
Put on Rental Shelf
Change status to
Available
Put on
Rental
Shelf
Figure 2-20 Default Function Hierarchies
To perform this reparenting task, we must examine the functions

created by the process modeler and identify which are true elementary
functions that should be moved to the Application Hierarchy.
Function Hierarchy
Once the processes have been adequately decomposed, they may now
be included on the Application Hierarchy diagram using the Include
Root Function option. Open both the Process Model Diagrammer and
the Function Hierarchy Diagrammer at the same time.
Create a function hierarchy diagram based on the application hierarchy
root function. Then select the Edit>Include Root... option from the menu.
Include a branch of the process model hierarchy so that reparenting is
easy simply by dragging the functions to the Application Hierarchy.
This will add the Process Step to the diagram and allow you to reparent
the significant functions over to the Application Hierarchy.
Top Level Function Model

Hollywood
Include context root process

and reparent significant
functions over to the
Application Hierarchy tree
Rent Videos
Manage Sales &

Marketing
Manage Inventory
Return Rentals
Record Payment
Add Copy to
Inventory
Add Inventory Code
Change status to
Available
Figure 2-21 Include Context Root Processes
Reparenting Functions
We would like to our Application Hierarchy to represent the full scope
of our business application and will refine it to scope our automation
boundary during systems analysis. Therefore, we only reparent the
significant functions over to the Application Hierarchy. When we
define our business processes, the process steps we define can be
decision points, manual steps, external steps, or even trivial steps. By
leaving these steps behind and not including them in the Application
Hierarchy, we are effectively pruning the tree and defining scope and
boundaries of our application.
If the application is a large one, the Application Hierarchy will be large
as well. To aid in the cataloging of functions, you may want to add
some intermediate functions to the hierarchy to further categorize your
EBFs and allow you to find them easier. These intermediate functions
can be lower level functional areas or sometimes they may correspond
to processes you have already created. In this case, simply reparent the
entire subtree from the Process Hierarchy over to the Application
Hierarchy.
As your Application Hierarchy grows, you will notice that your
function labels do not necessarily convey a functional decomposition.
After all, they were created by decomposing processes not functions. As
the hierarchy takes shape, you may want to go back and relabel the
functions to reflect the functional decomposition. At this point you may
also want to add the labels to the process diagrams using the text
annotation feature as previously discussed and then consolidating your
process diagrams to show the new labels.
Oracle Method
Common Functions
During analysis, functions are discovered that are used by more than
one process diagram. You can include an existing function on a process
diagram by using the Include Global Process Step option in the Process
Modeler. The shared function need only be defined once and then
included on subsequent diagrams.
Duplicate functions are identified and consolidated in the repository.
Sometimes, as an intermediate step, the duplicates are flagged as
common functions so they may be consolidated or eliminated in the
repository. Common functions are marked by editing the function in
the Function Hierarchy Diagrammer. The common tab of the properties
window allows you to set the master item to the function you want to
duplicate. The duplicate is then represented by two vertical bars in the
Function Hierarchy Diagrammer.
B2
Change Status to
Available
Change Status
A6
Edit function to reference

parent function making it
common
Figure 2-22 Duplicate Functions
Eliminating Common Functions

A process step should never be based on a common function it
should always reference the master. Common functions should be
removed from the Application Hierarchy and all references should be
moved to the master function. Common functions typically occur when
two or more functions are created in different processes and/or by
different analysts. Upon further examination you realize that they
perform the same function.
A global process step can be any function that is defined in the Oracle
Designer repository, including those from other applications. A process
step is considered a global process step when it is included in another
process in addition to the one in which it was originally defined.
Common functions, on the other hand, cannot be used in a process
diagram. If any flows or usages are defined against a function, Oracle

Designer will prevent you from flagging it as common.
The distinction between a global process step and a common function
can sometimes be confusing. When a common function is defined, a
link is actually created in the repository between the master function
and the copy. Two functions actually exist in the repository. When you
include a global process step on a process diagram, you are simply
including the representation of an existing function on the diagram.
Unlike with common functions, no new function is created and so only
the original appears in the function hierarchy and repository.
Including Other Functions
Complete the Application Hierarchy by including single-step or
standalone process steps. These processes, typically identified through
event response analysis, are not created in the process model as they
have no flows associated with them. A single-step process step needs to
be explicitly entered in the function model as an elementary business
function if it is to be implemented by the application.
Using the Application Hierarchy

The Application Hierarchy helps organize your work in the process
modeler making it easy to find particular functions. Rather than having
to search through hundreds of process steps in several process flow
diagrams, you can locate the function simply by looking down the
function hierarchy.
Process versus Function for Project Scoping

The Business Process Model and the Application Hierarchy provide two
different dimensions of project scope: functional scope and level of
effort. The two do not directly correlate. For example, an increase in
the functionality of an application may not require a corresponding
increase in the level of effort to build the application. Conversely, an
increase in the level of effort does not always result in increased
functionality (we know this all too well).
The first dimension, functional scope, is dictated by the set of business
events that are defined in the Business Process Model. Once this set of
events is enumerated, we have a way of bounding the functionality of
an application (but not necessarily the level of effort). We know very
Oracle Method
clearly what functionality is in the scope and what is not: we support

functions that are necessary to respond to the identified business events.
Users, in fact, often grow accustomed to thinking of events as units of
functionality. It is not uncommon during the course of the project to
have a user request a new event that may have been left out initially.
The function hierarchy provides the second dimension of project scope
for custom development level of effort. When fully detailed, each
EBF in the function hierarchy represents a unit of processing that is
usually associated with one or more modules in the Application Design.
By rating each EBF in terms of its complexity, we can estimate the level
of effort that is required to design, build, test and implement the
application.

The Business Process Model reflects the requirements of the business
processes that are to be supported by the new system. It does not
address the technical requirements that must be met to satisfy the business
requirements. This is the function of the System Process Model. The
System Process Model has three objectives:
to define the requirements for the system technical architecture
to define the requirements for the user interface
to enable users to visualize how the process will be executed

with the new system
The System Process Model expresses the technical characteristics of the

new system that must be fulfilled in order for the system to effectively
support the business requirements. Specifically, the system process
model includes the following information:
for each process step, delineation of where the user interface

boundary lies
for each event, the physical mechanism(s) by which the event

will be recognized (that is, phone call, electronic transmission,
batch operations schedule, etc.)
mapping of automated process steps to the types of processors

that will execute them
for each process step, identification of the type(s) of user

interfaces to the system (that is, GUI, block mode, radio
communications, hand held computer, etc.)
identification of electronic interfaces with other systems
a matrix cross referencing processes with the geographic

locations where they will be executed
By expressing requirements in terms of technical characteristics, the

System Process Model is the bridge between the analysis of the
requirements and the design of the application. There should be
sufficient information in the System Process Model for a system
architect to fully specify the technical architecture for the application.
The System Process Model should also help users visualize how the
process will work when the new system is in production. This goal can
Oracle Method
be accomplished in several ways and with varying levels of

sophistication.
Developing the System Process Model

The simplest approach to developing the System Process Model is to
include images in the process flow diagram that depict various aspects
of users interacting with the system in the performance process steps
and job roles. They can be accompanied by annotations about user
interface characteristics, format of reports, types of electronic
communications, etc. Screen mockups and prototypes can also be used
to show what the user will see when performing process steps, and to
provide experience with how the system will work. These additions can
be easily incorporated into the process diagrams through the use of
Oracle Designers multimedia features.
Use the text annotation
feature to enter the
function label. Select
Both Text and Graphics
as annotation type in the
Edit Tabbed Dialog.
RENT4.1[M]
Rent Video to
Customer
No:20%
Video Overdue?
E-Mail
Use the annotation

feature to select the
graphics file. Select Both
Text and Graphics as
annotation type in the
Edit Tabbed Dialog.
RENT4.2.1[E]
Use the flow name to

depict mechanisms for
the System Process
Model
Collect Overdue Fees

from Customer
Yes:80%
Use the Rule field in the

Edit Tabbed Dialog to
annotate conditional
flows. Select the Display
checkbox.
Figure 2-23 Oracle Designer Features for System Process Modeling
The system process model may also be extended to include animated

executions of the process. Animation requires that execution timing
and delay information be included for process steps and flows. These
animations also may include video and audio effects associated with
each process step that will be displayed during the execution of process
steps.
Transition from Analysis to Design

Transition from analysis to design has always been one of the most
difficult steps in custom development. Entity-relationship models
transform into relational database designs relatively easily. Translating
process models into a highly interactive, user friendly and maintainable
system is more difficult.
The purpose of the System Process Model is to facilitate the transition
from analysis to design. In developing the System Process Model, we
must first decide which processes will be supported by the system that
we will build. The set of processes to be automated defines the scope of
the Database and Module Design and Build tasks for custom
development. We will then determine what the technical requirements
are for supporting these processes, and what characteristics we desire
for the user interface. System process flow diagrams incorporate much
of this information on the diagrams themselves.
Figure 2-24 shows a process flow diagram (PFD) for a business process.
Figure 2-25 shows the PFD for the same process in the System Process
Model.
352*
RESEARCHANDEDUCATION
DIRECTOR
E0084
Request ResearchStudy
ProgressReport
352*
352*
ReviewProgressReport
352*
Record"NoAction"
UpdateStatus
D003
D002
Yes:50%
ReworkNeeded?
No:20%
No:50%
StatusChanged?
352*
Review
Recommendations
352*
NotifyPrimary
Investigarorof
Recommendations
Yes:80%
PRIMARYINVESTIGATOR
E0085
STEERINGCOMMITTEE
352*
PrepareProgressRepor
t
352*
ReworkReport
352*
Implement
Recommendations
352*
ReviewProgressReport
No:90%
D001
352*
Draft Recommendations
Recommend? Yes:10%
Unspecified
Figure 2-24 Example of PFD from Business Process Model
Oracle Method
3 52
52*
*
RESEARCH AND EDUCATION

DIRECTOR
E0084
3 52
52*
*
Request Research Study

Progress Report
3 52
52*
*
Review Progress Report
Record "No
Action"
D003
E-mail Request
3 52
52*
*
No:50%
Update Status
Rework Needed?
No:20%
Status Changed?
Yes:50%
D002
Yes:80%
3 52
52*
*
Review
Recommendations
3 52
52*
*
Notify Primary
Investigaror of
Recommendations
Server Generated
3 52
52*
*
PRIMARY INVESTIGATOR
E0085
E-mai
l
Implement
Recommendations
3 52
52*
*
3 52
52*
*
Prepare Progress Repor

t
Rework Report
D001
Online Report
3 52
52*
*
STEERING COMMITTEE
3 52
52*
*
No:90%
Review Progress Report
Draft Recommendations
Recommend?
Yes:10%
Unspecified
Figure 2-25 Example of PFD from System Process Model
The system process flow diagram includes the following additional

information:
geographic distribution of organization units
types of user interfaces
form of outputs and inputs
Illustrations are included to facilitate visualization and interpretation. If

there are significant concerns about the user-friendliness of the user
interface, the system process model could also include screen mockups
or working prototypes, and associate these with the process where users
interact with the system. Screen mock-ups and prototypes facilitate
review of the process because they allow users to see and experience the
designers view of how the user interface requirements might be met.
Sometimes users want to see simulated executions of the process.
Multimedia process modeling tools allow the use of audio and video
information, in association with process steps, which can be played back
and presented during simulated executions. The simulation would also
incorporate relative timing of process steps. For this you would need to
include execution times for process steps and delays between steps.
Business Process Modeling versus System Process Modeling

During system process modeling, you should restrict yourself to
modeling and describing functions that represent presentation logic. The
internal application logic should be described separately as business
rules. Refer to Chapter 1 for more information on the reasons for this
distinction. Refer to Chapter 3 for more information on business rule
modeling.
Oracle Method
Verifying the Process Model

The primary way of verifying the process model is to discuss it
interactively with the client personnel whose roles the model represents.
You can also verify the process model in several other ways.
Business Area Comparisons

Companies that are active in a particular business area will generally
respond to the same business events, using similar process work flows.
Verifying the process model can be done merely by comparing the
model with known models of similar companies.
Process Integration within the Business Area

Verifying the process model at the highest levels of the business area
can be performed by examining the context of each process and how the
processes integrate with other processes. Verifying the model by
answering the following questions:
Do your processes have logical predecessor and successor

processes?
Do your process outcomes set up information for downstream

processes?
Do your processes fit into a relative order in the life-cycle of the

business area?
Are there missing process integration points in the business

area?
Processes and Function Areas

When comparing processes to the function areas of the function
hierarchy, common sense may be the main technique used. Answer the
following questions:
Do these processes correspond with function areas in the

business?
Do these processes completely cover or map to the functional

response scope of a functional area?
Process Steps and Elementary Business Functions

Verifying process steps can best be done by examining their eventual
placement within the application hierarchy. Answer the following
questions:
Oracle Method
Are the process steps consistent with the EBF levels in the
application hierarchy?
Do process steps contribute to at least 75% of the EBFs in the

application hierarchy?
Are there transactional based EBFs that are not shown on a

process diagram?

When constructing an overview of all necessary and wanted processes,
keep the following concluding remarks in mind:
Frequency of a process is no indication of its importance.

Nevertheless, frequently executed processes, when designed
correctly, can increase business performance.
Frequently executed processes are excellent candidates for

performance tuning.
Processes should be expressed in active language, starting with

a verb.
It is impossible to create a process model without at least an

implicit concept of the functions involved.
A process defines how an organization integrates with itself or

with other organizations. As a consequence, process steps are
usually distributed across function areas. External process
steps exist across business areas.
A process represents how the business plans to respond to a set

of predefined events. Each process is a collection or abstraction
of similar responses, or scenarios.
As a process completely responds to an event, it may reflect

multiple points in time. When this results in overly complicated
diagrams, a process may be best represented by multiple
processes (and diagrams) each representing one point-in-time
response to an event.
A process diagram should not contain more than 15-20 process

steps.
Similar event responses can be consolidated into a single

process diagram.
Decision outcomes represent two or more mutually exclusive

flows.
Single-step or maintenance EBFs are (usually) not represented

in a process flow diagram. Manual and external EBFs are
represented in a process flow diagram.
CHAPTER
Business Rule
Modeling
T
his chapter discusses how business rules should be identified,

classified and recorded when using Oracle Designer for
requirements modeling.
In Chapter 1, we stated that during requirements modeling, business
rule modeling should be regarded as a discipline of its own. Explicitly,
modeling and classifying business rules have the following benefits:
Oracle Method
It enables and facilitates the developer who is responsible for

rule design and implementation.
It enables a more accurate estimate of the development time

needed for design and build.
Classification of business rules enables automation of the

implementation of business rules.
Classification also gives a good overview of the business rules

which eases communication with the user community.
Business Rule Modeling 3 - 1
This chapter presents the following sections:
classification scheme of business rules, including definitions and

examples for each type of business rule, as well as instructions
on how to record each business rule using Oracle Designer
using the business function object in Oracle Designer to describe

business rules, including business rule hierarchy and
presentation to the user community
the process of business rule modeling
The description of the rule classes includes a section on system design

considerations. For these considerations you may have to make some
system design-related decisions. They are targeted at system analysts
who subsequently will be involved in the design of the system, and
therefore want to take full advantage of the Database Design
Transformer provided by the Oracle Designer tool set and the Headstart
Utilities. If you think your technical skills are not sufficient to make
these decisions, you can ignore these considerations.
3 - 2 Business Rule Modeling
Related CDM Tasks

Classic Approach
Create High-Level Business Function Model (RD.030)
Create Initial Business Date Model (RD.040)
Construct Business Data Model (RD.060)
Construct Detailed Business Function Model (RD.070)
Construct System Data Model (RD.080)
Construct System Function Model (RD.090)
Produce Existing System Function Description (ES.090)
Produce Detailed Existing System Data Model (ES.100)
Fast Track Approach
Oracle Method
Create Composite Business Function Model (RD.031)
Create High-Level Business Data Model (RD.041)
Produce Existing System Function Description (ES.090)
Business Rule Classification Scheme

This section provides a classification scheme for business rules which
helps us to understand which kind of application logic is modeled as
business rules and how these rules should be recorded using Oracle
Designer. The major strength of this classification scheme is
demonstrated in the next volume of the standards and guidelines. It
shows how the classification scheme presented in the following table
provides excellent support for the complex task of determining how
each business rule is best implemented using the Oracle Designer tool
set.
The classification scheme is based on the following definition of a
business rule:
A business rule is either a restriction that applies to the state of data, the
change of data or the use of data OR an automatic action that should take place
after a change in data.
There are five main classes of business rules:
constraint rules
static
dynamic
change event rules
with data manipulation
without data manipulation
authorization rules
Constraint rules define restriction to the state of data (static) or the

change of the data (dynamic)
Change event rules define automatic actions to be taken after the state of
the data has changed. The automatic action can either be another
change in data (insert, update, delete) or an action outside the database
such as sending an e-mail or printing a report.
Authorization rules define which business unit, person or group of
people is able to perform a function or manipulate (a set of) data.
The following table addresses these five classes, their subclasses, types
of rules and how to record them in Designer.
Class
Subclass
Rule
Recording
Access
Static Data
Constraint Rules
Attribute Rules
Simple Attribute
Different Attribute
Properties
ERD
Domain
Domain object
ERD
Other Attribute
Function
Description
FHD
Tuple
Function
Description
FHD
Unique Identifier
Unique Identifier
ERD
Other Entity
Function
Description
FHD
Relationship
Entity Relationship
ERD
Restricted
Relations
Function
Description
FHD
Other InterEntity
Function
Description
FHD
Tuple Rules
Entity Rules
Inter-Entity
Rules
Dynamic Data
Create Rules
Create Rule
Function
Description
FHD
Constraint Rules
Update
Attribute
Transition
Function
Description
FHD
Transferable
Relationship
Transferable
Property
ERD
Other Update
Function
Description
FHD
Oracle Method
Class
Subclass
Rule
Recording
Access
Modify
Modify Rules
Function
Description
FHD
Delete
Relationship
Relationship Notes
ERD
Other Delete
Function
Description
FHD
Default Value
Rules
Default Property/
Function
Description
ERD/
FHD
Other Change
Event Rule
Function
Description
FHD
Change Event
Rules without
DML
Change Event
without DML
Function
Description
FHD
Authorization
Rules
Function Access
Business Unit Function

Association
MD
Vertical Data
Business Unit Entity/Attribute

Association
MD
Horizontal Data
Model as Entity
ERD
Change Event
Rules with DML
The following sections cover in detail every class of business rule. They
provide definitions, examples and guidelines for recording each class in
Designer. The examples that are given are derived from the following
datamodel:
BUSINESS RELATION
DEPARTMENT
# ID
* NAME
SUPPLIER
CUSTOMER
is managed by
employs
* TOTAL PROJECT LIMIT
works for
pays for
manages
EMPLOYEE
executed for
PROJECT
*
*
*
*
o
ID
DESCRIPTION
START DATE
END DATE
BUDGET
has
#
*
o
o
o
o
o
o
o
o
o
o
o
o
EMPLOYEE NUMBER
NAME
STREET
CITY
ZIP CODE
BANK ACCOUNT NUMBE
CIVIL STATE
HIRE DATE
EXIT DATE
JOB
SALARY
COMMISSION
TOTAL INCOME
STANDARD RATE
belongs to
of
is subject of
PROJECT ASSIGNMENT
# START DATE
* END DATE
* RATE
Figure 3-1
Entity Relationship Model that Forms the Basis for the

Examples
It is a fairly simple model where a company has departments with

employees. These employees can be assigned to projects that are
executed for their customers.
These sections also address considerations related to the use of the
Oracle Designer design transformers and subsequently the Oracle
Forms generator. The implications of recording business rules using the
Business (Rule) Function are discussed in a separate section later in this
chapter.
Oracle Method
Static Data Constraint Rules

The following subclasses of static data constraint rules can be identified:
attribute rules
tuple rules
entity rules
inter-entity rules
Strangely enough, making the distinction between static constraints and

change events is not always straight forward. This is because static
constraint rules can also be implemented as change event rules. We will
see this when we talk about rule decomposition. This means that if you
have a change event you should always determine if it should actually
be implemented as a static constraint.
Making the distinction between static and dynamic constraints is easier.
A dynamic constraint always refers to a data operation that is not
allowed. You are not allowed to insert, update or delete a record as a
consequence of the current state of the data. This means that if you see
insert, update or delete in your rule and you cannot rewrite it, you
probably have a dynamic constraint on your hand. If you need old
values (the attribute values before they were changed) or refer to
sysdate or user you also have a dynamic constraint.
Static constraints are constraints that always apply and that you
therefore can always check. It is the state of the data rather than the
operation that is important.
Classifying the rules into the above subcategories is quite simple, since
it is very easy to see if the rule involves
only one attribute (attribute),
one or more attributes in the same row (tuple),
attributes of more than one row in the same entity (entity), or
attributes and/or relationships from different entities (interentity).
Attribute Rules
An attribute rule defines which values are allowed for an attribute. The
following subclassification of attribute rules can be made:
simple attribute rules
domain rules
other attribute rules
Simple Attribute Rules

Simple attribute rules are rules that restrict the state of an attribute and
have a dedicated property in Oracle Designer to record this rule.
Simple format rules define the value for the following components
Examples
format
maximum length
decimal places
required
uppercase
Department code must be numeric.

Salary has a maximum length of 8.
Department name must be in uppercase.
Each employee must have a name.
Oracle Method
Recording
Simple attribute rules are recorded using the format, maximum length,
decimal places, and optional? properties of the attribute. Use the
derivation property and record the word UPPERCASE to indicate that an
attribute must be in uppercase.
Figure 3-2
Oracle Designer Property Palette for Simple Attribute Rules
Design Considerations for Format

The following table shows how the attribute format is translated by the
Database Design Transformer into a column data type and a column
display data type. The server generator subsequently translates the
data type, if the column data type as recorded in Oracle Designer is not
known by Oracle8.
Attribute
Format
Column Data
Type
Col Display
Data Type
Col Data
Type Server
Generator
CHAR
VARCHAR2
Text
VARCHAR2
DATE
DATE
Text
DATE
IMAGE
IMAGE
N/A
LONG RAW
INTEGER
INTEGER
Text
NUMBER
MONEY
NUMBER
Text
NUMBER
NUMBER
NUMBER
Text
NUMBER
PHOTOGRAPH
LONG RAW
N/A
LONG RAW
Attribute
Format
Column Data
Type
Col Display
Data Type
Col Data
Type Server
Generator
SOUND
SOUND
N/A
LONG RAW
TEXT
LONG
N/A
LONG
TIME
DATE
Text
DATE
TIMESTAMP
DATE
Text
DATE
VARCHAR2
VARCHAR2
Text
VARCHAR2
VIDEO
LONG RAW
N/A
LONG RAW
Attention: In Oracle8 LONG and LONG RAW are replaced

by CLOB and BLOB. However, the server and forms
generator do not support CLOB and BLOB. This
functionality is planned for release 6i of Oracle Designer.
Oracle8 still has the datatypes LONG and LONG RAW
available for backwards compatibility.
Design Considerations for Optional?

The Database Design Transformer translates a mandatory attribute to a
NOT NULL column and an optional attribute to a NULL column.
There is one exception to this rule: if a required attribute belongs to a
subtype entity and the supertype entity is mapped to one table, the
column is always defined as NULL. During application design, you
will then need to consider how to enforce this rule.
Headstart provides utilities can help you to enforce this rule.
For more information please look in the Headstart Utilities
Reference Guide.
Design Considerations for Uppercase
The database design transformer does not use the derivation field. This
means that after you have transformed the entities to tables, you must
indicate that the column is uppercase using the uppercase property.
Oracle Method
Domain Rules
A domain rule defines attribute allowable values which always apply,
regardless of the value of any other attribute, constant, or previous
value of the attribute. A domain either enumerates all allowable values
(enumerated domain), or restricts the allowable values by specifying
ranges of lowest and highest value allowed (range domain).
Examples
Employee job must be CLERK, SALES REP, or MANAGER.

(enumerated)
Employee salary must be between 30,000 and 300,000.
(range)
Recording
Structured support is offered for domain rules. You can either record
these rules directly against the attribute or by using the domain object in
Oracle Designer. By associating an Oracle Designer domain with an
attribute, the attribute inherits the properties of the domain.
Attention: If you change properties of a domain after you
have associated this domain with one or more attributes, you
must run the Update Attributes in a Domain utility to
cascade the changes to these attributes of the domain.
Design Considerations
The Oracle Forms generator offers flexibility in the GUI presentation
style (LOV, T-list, pop list, combo box) of columns with enumerated
domains associated. Properties allow you to set which domain
properties (value, abbreviation, or meaning) are actually displayed in
the GUI presentation item. The display sequence of each value
determines the ordering within the GUI item.
This implies that your choice of how the value is actually recorded in
the database (short code/abbreviation or full description) is no longer
dependent on the way you will present the allowable values on the
screen. This choice is based on disk space considerations only: a short
code or abbreviation takes less space than a full description, especially if
the column is to be indexed.
Other Attribute Rules (ATT)

These include all other allowable value rules for an attribute. In some
cases the attribute value depends on the value of a constant.
Examples
Employee salary must be multiple of 1000.

Employee bank account number must fulfill conditions of eleventest.
User name must contain at least 5 characters.
Postal code consists of 4 digits and two letters.
Recording
Use the Business (Rule) Function to record this rule. Refer to a later
section of this chapter for more information.
Tuple Rules (TPL)

Tuple rules define allowable values for attributes which depend on the
value of other attribute(s) within the same entity occurrence (tuple).
Examples
Employee exit date must be later than employee hire date.

An employee with job SALESMAN must have a value for commission.
Recording
Use the Business (Rule) Function object to record an entity rule. Refer
to a later section of this chapter for more information.
Most tuple rules are implemented as restrictions that will lead to an
error message when violated. Compliance with tuple rules can
sometimes be enforced (partially) automatically.
Lets take for example the following tuple rule. In this situation suppose
that all of the three attributes are changeable by the user.
Example
Oracle Method
Salary plus Commission is Total Income.
You can decompose this rule into the following two rules:
When Salary and or Commission are inserted, changed or nullified or
when the Total income is nullified the Total Income will be
automatically derived.
When Total Income is inserted or changed and the rule is violated
a message will be raised.
For more information of the decomposition of business rule please refer

to a later section of this chapter.
Attention: When implementing a relationship between two
entities, attributes of the master entity will become foreign
key columns of the detail table. Sometimes this implies that
validating such a rule can be done using only the foreign key
column for that specific table, that is the inter-entity rule
becomes a tuple or entity rule.
Example:
If an employee is not assigned to a department

(relationship is optional) he cannot have a salary.
If you know this is the case record the rule as a tuple or entity
rule. Recording such a rule as an inter-entity rule has the
consequence that the perceived complexity of the system is
higher than it actually is.
Do not record rules as a tuple rule if you need to select a
value of the other entity. Record the following rule as interentity rule.
Example:
Employees that work for departments other than

SALES cannot have a commission.
As a rule of thumb you can use the following guideline:

Rules whose validation can be triggered by
changes in more than one entity are always
inter-entity rules.
There are no specific Design considerations for tuple rules.
Entity Rules
Entity rules define allowable values for attributes and combination of
attributes which depend on the values of attributes of other occurrences
of the same entity.
Unique Identifier Rules

An entity unique identifier rule defines which (combination of)
attribute(s) and relationship(s) can be used to identify an occurrence of
the entity.
Example
Each employee is uniquely identified by an employee number.
Recording
The Oracle Designer repository provides a separate element for
structured recording of unique identifier entries. An entity can have
multiple unique identifiers, each consisting of one or more unique
identifier entries: an attribute or relationship.
The Database Design Transformer translates the first unique identifier
into the primary key of the corresponding table. The other unique
identifiers are transformed into unique keys. When assigning unique
identifiers, keep in mind the following:
Oracle Method
The primary key of a table should never be updateable in order

to prevent cascading updates on foreign key columns that
reference the primary key. If you are not sure this rule always
holds true for your candidate first unique identifier, introduce a
dummy attribute ID and make it the first unique identifier.
If the first unique identifier is composed of several attributes

and/or relationships, and the entity has one-to-many
relationships to other entities, then the primary key and the
foreign keys in the related table(s) consist of several columns.
This has the consequence that if the table is used in a form as a
lookup to populate the composite foreign key, only a list of
values on the first foreign key column is generated. In this case
introduce a dummy attribute ID and make it the first unique
identifier.
Oracle Designer allows optional unique identifier entries.

Never use an optional entry in the first unique identifier. The
Database Design Transformer automatically changes the
column corresponding to the optional attribute or relationship
into NOT NULL. When using optional entries in a secondary
unique identifier, make sure that for each entity occurrence
either all entries have a value or all entries are null. Add a tuple
rule to enforce this, if necessary.
Attention: The Database Design Transformer automatically
creates a so-called surrogate (artificial) primary key if there is
no first unique identifier. The system designer can always
decide to introduce such a primary key column if you, as
system analyst, did not take into account the design
considerations above. A disadvantage of this approach is
that the Design Transformer always adds the surrogate key to
every entity. You cannot instruct it to add the surrogate key
to only some entities.
Other Entity Rules (ENT)

Other entity rules consist of all allowable value rules which you can
define within an entity.
Examples
No more than 20 departments are allowed.
Recording
Use the Business (Rule) Function object to record an entity rule. Refer
Attention: When using self referencing entities be aware that
if you use the relationship in your rule this will result in an
inter-entity rule not an entity rule. See also next attention box.
Attention: When implementing a relationship between two

entities, attributes of the master entity will become foreign
key columns of the detail table. Sometimes this implies that
validating such a rule can be done by using only the foreign
key column for that specific table, that is the inter-entity rule
becomes a tuple or an entity rule.
Example:
Multiple project assignments of an employee on

the same project should not have overlapping assignment
periods (start date and end date).
If you know this is the case, record the rule as an tuple
or entity rule. Recording such a rule as an inter-entity
rule has the consequence that the perceived complexity of
the system is higher than it actually is.
Do NOT record rules as an entity rule if you need to select a

specific value of the other entity. Record the following rule as
an inter-entity rule.
Example:
A maximum of 80 employees can work in department
SALES.
No specific considerations apply to this type of rule.
Inter-Entity Rules
Inter-entity rules define attribute allowable values which depend on the
values of attributes in one or more occurrences of another entity. They
also define the relationships between entities, and their conditions.
Relationship Rules
An entity relationship rule defines how an entity relates to another
entity. Three main types of relationships are recognized:
one-to-one relationship (1:1, drawn as ------------)
one-to-many relationship (1:m, drawn as ----------<)
many-to-many relationship (m:m, drawn as >-----------<)
Each relationship end can be set to optional (by drawing a dotted line)
or mandatory (by drawing a continuous line).
Oracle Method
Example
Each employee can work for one and only one department. (optional)
Each employee must work for one and only one department.
(mandatory)
The relationship arc construct is used to indicate two or more mutually

exclusive relationship ends of the same entity. In other words, the arc
construct defines a condition on which a relationship can be created:
none of the other relationships included in the arc may exist for the
same entity occurrence. Note that an arc construct can only be used if
both relationship ends have the same cardinality and optionality.
Recording Relationship Rules
The Oracle Designer repository provides the Entity Relationship
Diagrammer with graphical creation and representation of entity
relationship rules. You can also use the Repository Object Navigator
(RON), to create a relationship between two entities. In the RON you
will not find an optionality property for a relationship end. Rather, the
minimum cardinality property defines the minimum number of entities
possible at the other end of the relationship for each entity occurrence
on this side. This tells you both the degree at the other end of the
relationship and the optionality at this end. A zero indicates that a
relationship is optional.
Figure 3-3
Relationship Properties Sheet in Oracle Designer
Refer to Chapter 4, Entity Relationship Modeling, for more

information.
Oracle Method
Design Considerations - Relationship Rule

The Database Design Transformer transforms entity relationship rules
as follows depending on the cardinality of the relationship ends:
one-to-many The many-side of the entity relationship rule is

translated into foreign key column(s) which refer to the primary
key columns of the table that has the entity implemented at the
one-side.
one-to-one Foreign key columns is added to one tables,

referring to the to the primary key of the other table. This type
of relationship is not frequently used, because it is often
possible to combine the two entities into one entity. Define two
separate entities only if it will aid in the understanding of the
business requirements or if they are located in different
systems.
many-to-many An intersection table is created, consisting of

foreign key columns referring to both tables where the entities
involved are implemented.
If the relationship end is mandatory (minimum cardinality 1), the

corresponding foreign key columns will be set to NOT NULL. If the
relationship end is optional (minimum cardinality = 0), the
corresponding foreign key column(s) will be set to NULL. There is one
exception to this rule: If a required relationship end belongs to a
subtype entity and the supertype entity was implemented as a single
table, the foreign key column is always defined as NULL. During
application design, you will need to consider how to enforce this rule.
The Headstart Utilities can help you in this case.
Restricted Relationship Rules (RER)

A restricted relationship rule restricts the set of entity occurrences to
which an entity relationship can refer.
Example
An employee can only be managed by an employee with job MANAGER.
Recording
Use the Business (Rule) Function to record this type of rule. Refer to a
later section of this chapter for more information.
Other Inter-Entity Rules (IER)

Other inter-entity rules consist of all other static rules that exist between
entities.
Examples
The project assignment dates (start and end date) of a project

should lie between the project dates (start and end date).
The sum of the budgets for all Projects of a Customer cannot exceed
his total project limit.
Recording
Additional Remarks
Optional attributes
If a business rule (not only static but also dynamic rules) applies to an
optional attribute you have to be aware what it means if this attribute
has no value. Take the case where the salary is mandatory and the
commission is optional and you have the following business rule:
Salary plus Commission must be smaller than 10,000
Then if the commission has no value what does this mean? The best
way to handle this is to be very specific and have the following rules
instead:
Salary must be smaller than 10,000 and if commission has a value
Salary plus Commission must be smaller 10,000.
You have to be aware of this for every optional attribute and optional
relationship.
Oracle Method
Dynamic Data Constraint Rules

Dynamic Data Constraint rules define conditions on which an entity
occurrence can be created or deleted; an attribute value inserted,
updated, or cleared; and a relationship created, deleted, or transferred.
Dynamic Data Constraint rules are, by definition, dynamic; they apply
to allowed state transitions of data.
Dynamic Data Constraint rules are independent of the person who
performs the data operation. Rules that depend on the person
performing the operation are covered in the section on authorization
rules later in this chapter.
As we have seen in the previous paragraph, a dynamic data constraint
usually has one or more of the following characteristics:
it mentions one or more DML operations (insert, update or

delete)
the old value is necessary to be able to validate the rule
user or sysdate are part of the rule
As we also have mentioned a dynamic data constraint cannot be

checked at a later stage because the necessary data (operation details
and old data values) is not stored. It is possible, however, to make a
static rule out of a dynamic rule. For instance if you have an attribute
transition rule, it will define the allowable from and to values when
updating an attribute. If you save history records with the date of the
update and the old value you can actually check later if all transitions
were allowed.
Create Rules (CRE)

A create rule restricts the creation of an occurrence of entity.
Example
You may not create a project assignment for a project that is

already finished (end date in the past).
Recording
Use the Business (Rule) Function object to record this type of rule.
Update Rules
An update rule defines conditions for the update of an attribute, entity,
or relationship.
Attribute Transition Rules (TRS)

Transition rules define attribute allowable values that depend only on
the previous value of the same attribute.
Example
Allowed transitions for civil state of employee

unmarried -> married
married -> divorced
divorced -> married
married -> widow
widow -> married
Recording
Use the Business (Rule) Function object to record this type of rule. Refer
If the transition rules are likely to change over time, or the number of
allowed state transitions is fairly large, you should consider creating a
separate system table with each row representing an allowed state
transition. This prevents the allowed state transitions from being hard
coded in the application code and allows you to change the transition
rule without modifying the application code. If you, as system analyst,
already know such a table is going to be used, you should add a
corresponding system entity to the system data model.
Transferable Relationship Rule

For every relationship the transferability must be. In other words
whether it is allowed to transfer a child to another parent.
Example
Oracle Method
You may not transfer on order item from one order to another.
Recording
Use the transferable property of a relationship to record the
transferability rule. The default in Oracle Designer is Yes (checked).
When you indicate that the relationship is not transferable this will be
indicated in the diagram by a diamond.
The Database Design Transformer ensures that the foreign key
constraint inherits the transferable property of the corresponding
relationship. The Oracle Forms Generator subsequently uses this
information to generate code for setting the foreign key column to nonupdateable, if the relationship is not transferable.
Other Update Rules (UPD)

Other update rules consist of all other update rules that can exist.
Example
You may not update the standard rate of an employee if the exit
date is in the past.
Recording
Modify Rules (MOD)

Modify rules are a combination of a create, update or delete rule. This
combination makes it possible to specify one rule that is valid for
creating, updating and or deleting.
Example
You may not create or update a Project Assignment if the related

Project is already finished (end date in the past)
Recording
Delete Rules
A delete rule defines conditions for the deletion of an entity or
relationship.
Relationship Delete Rule

The Relationship Delete Rule is part of (a decomposition of) the
implementation of the relationship rule. For example, suppose you
have a rule which states that an employee must be assigned to a
department (mandatory relationship rule). You have to decide what
will happen to the employees if you delete a department. Possible
options are as follows:
restricted deletion of parent should be prevented when

children exist
cascade all children of the parent are deleted also (this is a

change event rule, see in following section)
nullify the children concerned no longer have a parent
In most cases you will use the restricted relationship delete rule because
cascade is rather rigorous. Nullifying is almost never used because it
cannot be implemented for mandatory relationships.
Recording
For the relationship delete rule the default is restricted and nothing
needs to be recorded. If a cascade delete is desired write the word
CASCADE in the relationship notes to indicate the cascade
implementation of this rule.
For the relationship delete rule the database design transformer does
not transform the CASCADE word in the notes. This means that you
have to indicate this yourself at design level.
Oracle Method
Other Delete Rules (DEL)

Other delete rules consist of all other allowable delete rules.
Examples
You may not delete a file when the end date of that file is not in
the past.
You may not delete customer when the related projects are not
finished (end date in past). (in addition to a cascade delete rule.
Recording
Use the function object to record this type of rule.
Change Event Rules with DML

A change event rule defines an automated, derived (secondary) action
that takes place after a data state change. The change event defines
which change of data triggers the automated action. This can be one, or
a combination, of the following events:
creation or deletion of an entity
insert, update or nullify of an attribute value
creation, transfer, or deletion of an entity relationship
The automated action triggered is most likely another data

manipulation action (which in turn can trigger another change event
rule). However, it could be anything else, for example sending an email
or printing a report. This last category is identified as Change Event
Rules without DML (see next section).
Default Rules (DFT)

A special case of change events rules are default rules. These rules
describe the value of an attribute that automatically will be populated
when an occurrence of an entity is created and a no value is given. Note
that this means that the default rule is quite different from a
presentation default.
A presentation default is shown to help the user, if the user nullifies the
value null will be saved. This means that this is only behavior in the
presentation layer. If you have a default rule the default will be set even
if the user has nullified the value.
There is a distinction between a simple and complex default rule. A
complex default rule means that the default value for an attribute has to
be derived from other data and/or has to be derived through
calculation.
Examples
When inserting a Customer the default value of the total project

limit should be set to 100000. (simple)
When inserting a new Employee the default value for the department
is the department of his manager.(complex)
Oracle Method
Recording
Record the simple default rule in the default property of the attribute.
Record the complex default rule as a function.
For simple default rules, the Database Design Transformer uses the
default property of the attribute to populate the default property of the
column. The server generator uses that property to specify the
declarative default in the table and also implements the rule in the Table
API, when server derived is set to yes.
For complex defaults, you will have to record a derivation expression or
function in the derivation expression and derivation expression type
properties of the column. The Database Design Transformer does not
automatically populate these properties.
Other Change Event Rules (CEV)

Change event rules can have different levels. At first you will look at
real business events. Later on at system requirements level you will
look to more detail system events; for instance default change event
rules or a change event rule that implements a tuple rule.
Examples
When the exit date of an employee is set, create an occurrence in

the entity work order (not shown in the diagram) of the type
revoke computer access, so the IS department will make sure the
employee has no access anymore to the companys computer systems
after the exit date.
When the salary of an Employee is changed, create an occurrence in
the Audit Employee entity.
This kind of rules used to be part of the business function that is

responsible for the data manipulation that causes the change event to
emerge.
By applying the concepts of the three-tier model, you should split the
presentation layer and the application logic. In the first example this
means that you want to separate the function of entering the end date
from that of creating an occurrence in the entity Work Order.
Recording
For change events that involve journaling note the following. In some
types of application systems, it can be very important to specify which
entities have to be journaled. In those cases, explicitly model journal
entities as part of the system data model. Another alternative is to
create a specific function that lists all entities that need to include
change history columns (date created, date modified, user created, user
modified) or need to be full journaled (a table that holds all previous
actions of an occurrence).
No specific considerations apply to this type of rule except for
journaling.
Reference: For more information about data auditing, refer
to the Oracle Method CDM Standards and Guidelines
Library, Volume 2 - Design and Generation of Multi-Tier Web
Applications.
Oracle Method
Change Event Rules without DML (CEW)

A change event rule without DML defines an automated action not
involving data manipulation, that takes place after a data state change.
Examples of this type of rule are sending an e-mail and printing a
report.
Examples
When the end date of a Project Assignment is changed, the manager

of this employee should be informed with an e-mail.
Recording
Use the function object to record this type of rule.
In Design and Build you implement these rules at the end of a
transaction.
Authorization Rules (AUT)

Authorization rules define the functional or organizational conditions
users must meet to be authorized to perform a certain business function
or to operate on certain data.
These conditions are defined in terms of the business units to which
people are assigned. A business unit is used in the broadest sense of the
term, including organizational units at the lowest level: user roles. This
definition of business unit is equal to the concept of agents as used in
process modeling. For more information, see Chapter 2, Process
Modeling Guidelines.
Some examples of business units / agents are:
regional manager
administrative assistant
quality management services
project accounting
project leader
customer service representative
customer service supervisor
It is important to include user roles as the lowest level business unit

because different people within a department almost always perform
different functions and therefore need different authorizations. For
example, a manager of a business unit will perform different functions
(for example, approving time sheets) from the employees working for that
business unit (for example, recording time sheets).
User-role analysis can be postponed until systems design, but you, as an
analyst, are often in a better position to efficiently gather the required
information. It also increases your understanding of the business and
often inspires the client to re-evaluate tasks and responsibilities.
Postponing user role analysis until systems design can delay the
complex task of designing the systems architecture.
If the system is to be implemented in a distributed environment, user
role analysis must be performed as early as possible to get insight into
the distribution requirements.
Oracle Method
Authorization rules can be divided into three types of rules:
authorization to perform certain functions
authorization to access and manipulate certain entities and

attributes (vertical data authorization)
authorization to access and manipulate a subset of entity

occurrences (horizontal data authorization)
Function Access Rules

These rules define all of the functions that are accessible for a business
unit / agent.
Example
Only employees that are managers have access to the function

Change Salary.
Recording
You can record business units in the Process Modeler or the Repository
Object Navigator (RON) of Oracle Designer. The relationship between
the business unit and the functions it performs can be recorded in the
Matrix Diagrammer or the RON.
Attention: The meaning of this matrix is interpreted
differently in system requirements modeling than it is in
business requirements modeling. During business
requirements modeling, this matrix refers to the party who is
responsible for a process step/function, which does not
necessarily mean that there are no other agents who are also
authorized to perform the process step/function. During
system requirements modeling, you use it as a means of
recording this function access rule.
The Application Design Transformer uses business units to take into
account access rights during the process of creating candidate modules.
Headstart offers utilities that create roles from the lowest
level business unit and module access for these roles based on
the business function/business unit and business
function/module associations
Vertical Data Access Rules Authorization

These rules define all the entities that are accessible for a business unit /
agent.
Example
Only the project manager has access to the entity Project.
Recording
Use the Matrix Diagrammer to populate the Business Unit - Entity
matrix. In general, you only need to record this rule if the application is
to be implemented in a distributed environment, to get insight into the
distribution requirements.
Oracle Designer does not check for implied usages. If you entered a
usage by business unit B of function F and also a usage by function F of
entity E, then, by implication, business unit B must be able to use entity
E. This usage must be entered manually.
Attention: The meaning of this matrix is interpreted
differently in system requirements modeling than it is in
business requirements modeling. During business
requirements modeling, this matrix represents business unit
responsibility for data; whereas during system requirements
modeling, this matrix represents business unit access to data.
During business requirements modeling, you will populate
this matrix to get another view on the business, allowing you
to cross-check whether different views are consistent. During
system requirements modeling, you use it as a means of
recording business unit data access.
No specific considerations apply to this rule. Neither the Database
Design Transformer nor the Application Design Transformer takes this
information into account.
Headstart offers utilities that create roles from the lowest
level business units and object privileges for roles based on
the business function entity usage and the business
function/business unit association.
Oracle Method
Horizontal Data Access Rules

These rules define the conditions that an entity occurrence must meet in
order to be accessible for a business unit/agent.
Many applications demand that users can only manipulate data when
the data is entered by someone from the same department, or perhaps
only by a specific user.
Example
A manager can only update the salary of his own employees.

A manager can only update project information of projects that fall
under the department he manages.
Recording
This type of authorization rule can only be implemented if the entity
relationship model allows you to describe the rule. In the last example
above, you have to include a relationship between the project and the
department and need a username in the employee entity to be able to
match the current user with the username of the manager of that
specific department.
Horizontal data access rules can be implemented as Dynamic Data
Constraint rules.
No specific considerations apply to this rule.
Recording a Business Rule as a Function

As stated in the previous sections of this chapter, there is a number of
business rule classes that should be recorded using the Business
Function object in Oracle Designer. This has the following advantages:
Oracle Method
You can use the event object to explicitly describe the event(s)
that trigger(s) the rule. See the next section for more
information on event modeling.
You can use the function/entity and function/attribute matrices

to record the entities and attributes which are actually used
(created, retrieved, updated, or deleted) during rule
enforcement. This enables you to perform full entity life-cycle
analysis and impact analysis.
Most of these rules will be implemented in the custom business

rule package (Custom API) which is an Oracle Designer
PL/SQL definition. By populating the Functions
Implemented association of that PL/SQL definition, you can
cross-check the implementation of each rule, ensuring the
completeness of your application design (that is, which rules are
not yet implemented).
If you also implement the rule in the presentation layer because

of timely feedback to the user you can use the module
definition/function associations to indicate that next to the
implementation in the business logic layer the rules is also
implemented in the presentation layer.
You can prevent redundant documentation efforts later on

during systems design. The functional description of the rule
the PL/SQL definition implements is already documented in
the function which can be easily tracked down using the
PL/SQL definition-function association.
You only have to record the rule once even if it is provoked by

more than one business function.
Organizing Rules
It is important to realize that the Oracle Designer repository now
contains two kinds of business functions:
presentation/batch functions
business rule functions
The presentation/batch functions are identified, analyzed and modeled

using the top-down technique of function decomposition as we were
already used to doing prior to the Three-tier era. Refer to Chapter 5,
Function Modeling Guidelines, for more information on function
decomposition.
For the business rule functions you can use a similar approach and do rule
decomposition (see also next session). An alternative is just to record
every rule immediately as you identify it and organize them later on.
There are three criteria that need to be satisfied when recording
business rules as functions.
it must be easy to recognize as a business rule (as opposed to a

presentation function)
it must be easy to relate the business rule to a business area or

entity
it must be easy to identify the type of the business rule
There are a couple of possibilities for organizing business rules.

1.
Create a separate hierarchy and organize per type of rule.
2.
Create a separate hierarchy and organize per business area.
3.
Create a separate hierarchy and organize per most important

entity.
4.
Record them under the presentation function hierarchy in a

special branch.
Of course combinations of these four options are possible as well.

When using the Application Design Transformer it translates the rules
to modules and not to PL/SQL definitions. Therefore, option 4 has one
big disadvantage, as it will be very difficult to use the Application
Design Transformer for the real Business Functions. Therefore a

separate hierarchy is the most convenient way of organizing the rules.
Organizing by the type of rules does not add a lot of value. Therefore
we recommend that you have a separate rule hierarchy organized by
the same business areas (option 2) that are used in the presentation
function hierarchy. If these business areas are too big you can use an
extra level of sub business areas. Under the business area level you can
organize further by entities (option 3). If there are a lot of business rules
(more than 20) belonging to one entity you can even sub divide them
per type (option 1).
Since Inter-Entity Rules involve more than one entity, it may be difficult
to decide to which entity the rule belongs. You can use common
functions to put them under both hierarchies. You can also decompose
an inter-entity rule and create a common function after decomposition.
Change Event Rules should be placed under the entity branch of the
triggering entity and not the entity that is inserted, updated or deleted.
For an example of a business rule hierarchy see the following section.
Rule Decomposition
In most cases decomposition of inter-entity rules is necessary to
describe the behavior of the system in detail. Lets take, for example,
the following inter-entity rule:
The Project Assignment end date must be on or before the end
date of the Project.
There are three events that can trigger this rule
Oracle Method
creation of a Project Assignment
the update of the Project end date
the update of the Project Assignment end date
This rule is phrased as a Static Data Constraint rule. However, you can
also choose to implement this rule as a Change Event rule, thereby
automating enforcement of the rule. In order to implement it as a
Change Event rule, the rule must be decomposed into the following
three rules. (Notice that two of these rules are Change Event rules
while the third is still a Static Data Constraint rule.)
Change Event Rule: when updating the end date of the

Project Assignment to a date that is later than the end
date of the Project, the end date of the Project should be
automatically set equal to the end date of the Project
Assignment.
Change Event Rule:
Static Data Constraint Rule: The Project Assignment end

date must be on or before the end date of the Project.
when updating the end date of the

Project to a date that is earlier than the end date of one
or more Project Assignments, the end date of all those
Project Assignments must be automatically set equal to the
new end date of the Project.
Decomposition of a fairly simple business rule leads to three new

system rules that describe how the system will act in response to
different events. We recommend that you do rule decomposition for
inter-entity rules that require automation.
You can use the common function feature to link the Project assignment
related rules to the right tree in the function hierarchy. Only use
common business functions if they improve the communication to the
user or developer community.
Below you can find an example of the Business Rule hierarchy
populated with most of the business rules used as examples in this
chapter. Notice the naming convention used for each business rule.
BR
Business Rules
BR_HR
BR_EMP
BR_EMP001_ATT
BR_EMP002_ATT
BR_EMP003_ATT
BR_EMP004_TRS
BUSINESS RULES HUMAN RESOURCE

Employee related business rules
Employee zipcode must contain four numbers
and then two characters.
Employee salary must be a multiple of 1000
Employee bank account number must fulfill
conditions of eleven-test.
Allowed transitions for civil state of
Employee
unmarried -> married
married -> divorced
divorced -> married
married -> widow
widow -> married
(Dynamic)
BR
Business Rules
BR_EMP005_TPL
BR_EMP006_TPL
BR_EMP007_TPL
BR_EMP008_TPL
BR_EMP009_UPD
BR_EMP010_IER
BR_EMP011_IER
BR_EMP012_RER
BR_EMP013_CEV
BR_DEP_HR
BR_DEP001_ENT
BR_DEP002_ATT
BR_PA
BR_PAT
BR_PAT001_ENT
BR_PAT002_CEW
BR_PAT002_CEV
master of
BR_PRJ002A_CEV
BR_PAT003_IER
master of
BR_PRJ002C_IER
BR_PAT004_MOD
BR_PRJ
BR_PRJ001_IER
BR_PRJ002_IER
BR_PRJ002A_CEV
Oracle Method
Employee exit date must be later than hire

date.
An Employee with job SALESMAN must have a
value for commission.
If an Employee is not assigned to a
Department (relationship is optional) he
cannot have a salary.
Salary plus commission is total income.
If commission is null salary must be the
same as total income.
You may not update the standard rate of an
Employee if the exit date is in the past.
Employees that work for Departments other
than SALES cannot have a commission.
A maximum of 80 Employees can work in
Department SALES.
An Employee can only be managed by an
Employee with job MANAGER.
When the exit date of an Employee is set,
create an occurrence in the entity Work Order
(not shown in the diagram) of the type
REVOKE COMPUTER ACCESS, so the IS
department will make sure the employee has no
access anymore to the companys computer
systems after the exit date.
Department related business rules
No more than 20 Departments are allowed.
Department name must be in uppercase.
BUSINESS RULES PROJECT ADMINISTRATION
Project assignment related business rules
Multiple Project Assignments of an Employee
on the same project should not overlap
When the end date of a Project Assignment
of an Employee is changed the manager of this
Employee should be informed with an e-mail.
When updating the end date of the Project
Assignment to a date that is later than the
end date of the Project, the end date of
the Project should be automatically set equal
to the end date of the Project Assignment.
The Project Assignment end date should be
on or earlier than the Project end date.
You may not create or update a Project
Assignment if the related Project is already
finished (end date in the past)
Project related business rules
The Project Assignment start date should be
on or later than the Project start date.
Assignment to a date that is after the end
date of the Project, the end date of the
Project should be set to the end date of
that Project Assignment.
BR
Business Rules
BR_PRJ002B_CEV
BR_PRJ002C_IER
BR_PRJ003_CRE
BR_CA
BR_BRN_CA
BR_BRN001_DEL
BR_BRN002_IER
BR_BRN003_DFT

to a date that is earlier than the end date
of one or more Project Assignments, the end
date of all those Project Assignments must
be automatically set equal to the new end
date of the Project.
You may not create a Project Assignment for a
Project that is already finished (end date
in the past).
BUSINESS RULES CLIENT ADMINISTRATION
Business Relation related business rules
You may not delete a Customer if there are
related Projects that are not finished (end
date in past). (in addition to a cascade
delete rule).
The sum of the budgets of all Projects for
a Customer cannot exceed his total project
limit
When inserting a Customer, the default value
of the total project limit should be set to
100000.
Rule-Triggering Events
An event is simply an occurrence that causes a response to execute. In
Chapter 2, Process Modeling Guidelines, we split events into the
following three categories:
External Event something that happens outside the business

area. External events only trigger business processes, they do
not trigger business rules as defined in this chapter. An
example is that the company receives a request for proposal
form a client.
Internal Event something that is initiated inside the business

area. We distinguish two classes of internal events (in Oracle
Designer this is a category on its own):
Change Event involves a change in the status of an

entity. This change can be due to the creation of a new
occurrence of the entity; the deletion of an entity
occurrence; the update of one or more attributes; or the
creation, transfer, or deletion of an entity relationship
occurrence.
System Event anything that happens within the control

of the business but cannot be classified as an entity change
event. For example, the completion of a business function,
or a user requesting the system to compute an employees
remaining holidays.
Time event A real time event occurs when time reaches a

significant point, such as:
the departure time of a flight
every Monday at 2.00 p.m.
the end of the fiscal year
Other Events that can not be categorized in one of the

categories above.
Events provide a structured means of documenting when business

functions and business rules are triggered. Modeling events and the
business and system responses they provoke increases your
understanding of how the business area actually works.
Apart from these general benefits, rule-triggering event modeling
provides a good starting point for decomposing business rules into
system rules that describe the actual implementation of the rule, as we
saw in the previous section. You should not only identify the events but
ask the user what the required response would be. By doing this you
will develop a more user friendly application and add specific value
that can be used later on when designing the system.
Oracle Method
Below you can find an example of how to record an event that triggers a
business rule.
Figure 3-4
Recording Events in Oracle Designer
By using events to model the WHEN conditions of business rules, you

provide structured, valuable support for the system architect, enabling
him to oversee all situation where the rule must be enforced.
We strongly recommend explicit triggering-event modeling for the
following:
restricted relationship rule
other inter-entity rules
modify rules
change event rules
For the other categories of business rules, the triggering events are more
or less trivial and can be omitted.
What to Record
Events and Business Rule Function Entity/Attribute usage
Separate from the event that triggers a rule there is also the actual entity
and attribute usage of the rule itself. Recording these have the
following advantages
a more detailed analysis facilitates the design
impact analysis is extended to rules
the complexity of the rule is clear and estimating techniques like

Function Point Analysis can be applied
it enables business rule automation.
When you have decided not to record entity usages or attribute usage
for real business functions, there is no point in recording them for
business rules.
Oracle Method
Relating Business Function to Business Rule Function?

Another point you have to decide on is, if and how you want to record a
relationship between your business functions, events and business rules
functions. For presentation to the user community, this probably adds a
lot of value in the understanding of the system. (see next section). There
are three possibilities.
1.
You link your business functions to your business rules

explicitly using the business function triggers business rule
function association in Oracle Designer. This means that you do
no real event analysis because Oracle Designer creates a dummy
event (end of business function) that links the business function
to the business rule function. The advantage is that you can
specifically record which business function calls which business
rules.
B u sine ss F un ctio n
E ve nt
B u sine ss R ule F un ction
B u sine ss F un ctio n
E ve nt
B u sine ss R ule F un ction
E xplicitly b y u sin g th e
fun ctio n trig g ers fu n ctio n
a sso ciation th at a u to m a tic ally cre ate s a du m m y
e ve n t: e n d of b u sine ss
fun ctio n
Figure 3-5
Using the Function to Function Association to Connect Business

Functions with Business Rules
2.
You link your business functions explicitly to events that trigger

your business rules by using the business function event
association. Here you have the advantage that you model the
events explicitly, which facilitates design and implementation.
You can precisely specify which business function triggers
which event. If you have very detailed events you can also have
an exact relation between your events and the business rules
that will be triggered. The disadvantage of this approach is that
it is a lot of work and you can get a lot of events.
B usin ess F un ctio n
E ven t
B usin ess R ule Fu nction
E ven t
B usin ess F un ctio n
E ven t
B usin ess R ule Fu nction
E xplicitly b y u sing the

business function
triggers event
association
Figure 3-6
Oracle Method
Using the Function to Event Association to Connect Business

Functions with Business Rules
3.
You do not explicitly link the business function to the events.

However, the connection can be determined implicitly by
comparing the entity/attribute usage of the business function
with the entity, attribute and on condition of the events that
trigger the business rule. The advantage is that you do event
analysis (which facilitates design) and nothing more.
B usiness Function
E vent
B usiness Rule Function
E vent
B usiness Function
E vent
B usiness Rule Function
Im plicitly by
com paring the
business function
entity/attribute usage
with events 'usages'
Figure 3-7
Implicitly Deriving the Connection Between Business

Functions and Business Rules
We recommend that you take the third approach because event analysis
is important and presenting the business function in conjunction with
the business rule function is possible without doing a lot of error prone
work. This approach also supports independent business function and
business rule analysis.
Presentation to the Business Community

A possible disadvantage of recording business rules as separate
functions is that the business community loses sight of the bigger
picture, the context in which the business rules must be placed. By
categorizing rules into the same business areas as used in the business
function hierarchy and sub categorizing into entities this problem is

mostly prevented.
In general, you are likely to present constraint rules together with the
description of the related entities or related functions. Change event
rules are more likely to be presented together with the presentation
functions that cause the rule-triggering event to emerge.
Depending on the choice you have made about linking business
functions, events and business rule function in the previous section, you
can have different reports. However, the components that will show up
in the report will be the same. The report has to show the function
description, usages and the business rule functions that are triggered.
You can also incorporate the events that are triggered by the business
functions.
When you have explicitly made the link between business function and
business rules you can use the function triggers function.
You can make a copy of the following standard Oracle Designer reports
and modify these to include the information needed:
Entity Definition (ckentdef.rdf)
Function Definition (ckfdefin.rdf)
These reports are located in the ORAWIN\REPADM60\SRW directory.
Presentation on the Web

Oracle Consulting has created a package called Cherry Pie that
publishes analysis information on the web in either static or dynamic
format. This package also uses the implicit approach of presenting
business functions in conjunction with the triggered business rules.
Experience with Cherry Pie has taught that customers like it very much.
They can click their way through the meta data and do not get a pile of
paper to look at. By using the hyperlinks it is very easy to get more
information about another object as well. By having a static HTML file
it is not necessary to have the user log on to Oracle Designer.
For more information on Cherry Pie please contact your local Oracle
Consulting representative.
Oracle Method
The Process of Business Rule Modeling

Since we see business rule modeling as a discipline of its own, it has its
own task steps and deliverable components. Below you can find a step
by step approach to identify, classify, record and decompose business
rules. The distinction between business and system requirements is
explained in the CDM Classic Process and Task Reference.
Business Rule Modeling during Business Requirements

1. Identify Business Rules
During interviews and workshops you have with the user community,
the business rules, just like entities, come up almost automatically as
you talk with the users about their business.
Some rules are quite obvious. Others are more hidden in the statements
you hear or read. There are a couple of questions that help you to
identify business rules.
Does the statement contain a restriction to the data?
Does the statement restrict the manipulation of data?
Does the statement include an automated action to the entity

model?
Does the statement include an automated action outside of the

entity model?
Does the statement have anything to do with authorization?
2. Classify Business Rules

By answering the questions above you have already determined the
highest class of business rule. After that, you should do a more detailed
classification before recording the rule. The classification scheme
described earlier in this chapter helps you with this more detailed
classification.
When you make a high-level data model, the first rules you identify are
the inter-entity rules, especially the relationship rules. Then you name
the most important attributes and add most attribute rules and the most
important tuple rules. When your data model is complete, you specify
all other rules. In a Fast Track approach, the data model may change as
a consequence of new requirements after the users have validated a
prototype. This means that next to new entities or attributes new rules
need to be added.
When you make your function model, you will probably identify change
event rules and rules that seem to belong to only the function at hand.
Even if this is the case, you should classify it and record this rule
separately.
3. Analyze Triggering Events of Business Rules
For the more complex rules (entity, inter-entity and change events
rules), you should carefully investigate the triggering events of the
business rule. Most of the time, it is quite easy. For each entity
mentioned in the rule, ask the user if the rule needs to be enforced on
creation, update and/or delete of a tuple in the entity. For each
attribute mentioned in the rule, ask the user if the rule needs to be
enforced on insert, update and/or nullification of the attribute. Once
you have identified the events, you can determine if the rule is a static
rule or dynamic rule. A static rule is always true and can be verified at
any time. A dynamic rule is valid only at the moment the DML is
performed and cannot be verified after the operation has taken place. A
good rule of thumb is: if the rule mentions a type of DML operation
being performed, the user, the system date, or the old value for an
attribute, the rule is dynamic.
4. Set up a Hierarchy for Business Rules
Since the Business (Rule) Function object in Oracle Designer is used to
record business rules, you can set up a hierarchy that groups business
rules belonging to the same business area, same entity and or same class
of rule. You can also do this after you have recorded the rules, but
starting with a high-level hierarchy is quite handy to group the rules
right away.
5. Record Business Rules and Triggering Events
After you have identified and classified the rules, determined the
triggering events, and set up the hierarchy, you can record the rules in
Designer. This can be done by taking your notes of the workshop or
interviews and putting them in Designer. If you follow a Fast Track
approach, a scribe may record the rules and events directly into
Designer during the workshop. The classification scheme and the
description of the rules in the previous sections clearly state how to
record each rule.
Oracle Method
6. Validate Business Rules

It is good practice to validate the requirements that you have recorded.
You can do this either by setting up a validation session or by giving the
user community the requirements on paper and having them give
feedback. Most of the time users like to see most of the business rules in
conjunction with the business functions that trigger the business rule. It
is quite easy to develop a report that shows this information.
In a Fast Track project, you could even implement the most important
business rules in the functional prototype. Or if this takes too much
time, indicate when a business rule will be triggered and what the error
message will be.
Business Rule Modeling during System Requirements

7. Identify Remaining Rules
During system requirements you may discover new (overlooked) rules
that were not identified at the business. You still need to identify these
rules to make your analysis complete.
You may also need to introduce new rules because of the inclusion of
new system entities in your system data model.
8. Analyze Triggering Events of Business Rules
For these new rules you need to analyze the triggering events as
described above.
9. Classify Business Rules
You also need to classify the new rules as described above.
10. Decompose Complex Business Rules
One important step that you need to take at the system requirements
level is to identify how a rule needs to be implemented. Normally a
rule is implemented by raising an error message, but in other cases it
might be much more user friendly to implement rules by automatically
making them true. This means that for each event you should ask the
user how the rule should be enforced. This may lead to decomposition
of the rule and even a change of classification of the rule if automatic
actions are desired. If these are not desired decomposition is not
necessary.
11. Record New and Decomposed Business Rules and Triggering

Events
You need to record the new rules in the same way as described above.
Decomposed business rules should be recorded in the hierarchy as
children of the rule from which they are decomposed.
12. Validation of the Business Rules
Again, you need to validate the new business rules with the users.
Oracle Method
CHAPTER
Entity Relationship
Modeling
T
his chapter describes guidelines for making an entity relationship

model. The following topics are covered:
Oracle Method
The Entity Relationship Model
Entities
Attributes
Relationships
Subtypes and Supertypes
ER Diagrams
Entity Relationship Modeling 4 - 1
Related CDM Tasks

Classic Approach:
Create Initial Business Data Model (RD.040)
Create High-Level Existing System Data Model (ES.030)
Construct System Data Model ( RD.080)
4 - 2 Entity Relationship Modeling
Create High-Level Business Data Model (RD.041)
Create High-Level Existing System Data Model (ES.030)
Revise Requirement Models ( RD.115)
The Entity Relationship Model

As stated in the introduction, the purpose of an Entity Relationship
Model (ERM) depends on the purpose of the requirements modeling.
An ERM always show the information within a business, but the level of
detail, the audience for the model, and how it will be used afterwards
vary between projects.
Business Data Modeling versus System Data Modeling

The Business Data Model provides a full and detailed definition of the
structure of all the data that the business areas use or generate.
The System Data Model provides a full and detailed definition of the
structure of all the data that the system is to store. This includes data
identified within the Business Data Model that is also within the scope
of the system. It also includes additional data structures (technical
entities) that may be required to support any functionality within the
system that is concerned with processing that is not directly visible to
the end user.
The System Data Model may be produced by taking a copy of the
Business Data Model and modifying it to support and facilitate the
functionality of the system (described in the System Function Model).
Changes are likely to include any of the following:
Oracle Method
removal of entities, attributes, relationships, and identities that

are not going to be stored or supported by the computer system
addition of entities, attributes and relationships to support

system functionality concerned with the provision of the
systems infrastructure; for example, configurable parameters,
communications status, interface status, queues, error logs, and
means for users to access subsets of the data that they use
regularly
addition of the surrogate keys which may be required to

support the system functions
generalization of data structures from the business data model,

so that a single data structure can have slightly different uses
making data structures less generic within the Business Data

Model where different types of an entity and dependent entities
are to be processed by different functions
simplification of the data model to simplify the system

functionality
Do not try to make these structures part of the Business Data Model, as
they are part of the particular projected implementation of the system.
Not all entities are clearly technical or not. An entity like ALLOWED
STATE TRANSITION is in the border area but still acceptable in the
Business Data Model.
Attention: A System Data Model is often no longer
technically portable. If there is a decision to alter the tool set
for the project, then the technical entities have to be reinvestigated before system design is begun.
It is a good idea to involve a database designer in the review process,
when nearing the end of system data modeling, to confirm that the ERM
is a good basis for system design.
Client Involvement
Due to the simplicity of the rules for the production of ERMs, they can
be developed interactively with the client. This method reduces
misunderstandings, gives the client a feeling of ownership of the model,
and puts the client in a frame of mind which is more open to the
changes that occur during any systems development.
Given the different audiences and purposes of ERMs, one must ensure
that the models are understandable to the audience. The naming of
entities and relationships is covered later in this chapter, but you must
keep in mind who will read the model. For example, entities related to
the technical implementation (technical entities) would not be
understandable to the client, and a model which showed only the subset
of the actual model used to discuss specific details with the client would
be of no use for moving to system design. There may be a requirement
for more than one model to be used: one could be a high level model
for the client managers, one could be more detailed for the clients staff,
and one could be sufficiently detailed to act as the basis for system
design. Care must be taken when using multiple models to make sure
that inconsistencies do not evolve between them.
A good way to verify the Entity Relationship Model is to make a quick

prototype so the user community can actually see whether the model is
complete and how data is related. In CDM Fast Track prototyping is a
mandatory part of the approach. The prototype then works as the
communication means between the users and the developers. For more
information on prototyping see Chapter 6.
Cross-Checking with Function or Process Model

It is critical that the entity relationship model be developed in
conjunction with the function or process model, if one is being
produced. This is to ensure that all the identified elementary functions
or process steps are supported by information within the ERM and that
all the information within the ERM is correctly handled within the
function or process model. The usage matrices provide a cross-checking
mechanism for the ERMs relationship to the function model.
Oracle Method
Entities
The decision of whether or not something should be recorded as an
entity is subjective, and cannot be made based on any form of
algorithm. The analyst has basic criteria an entity must be uniquely
identifiable by either having information associated with it, or by having
a relationship to another entity but not everything that fulfills this
criteria should be recorded. It is up to the analyst to investigate which
information is both significant to the business and within the scope of
the requirements modeling.
Examples
Objects:
PERSON
PRODUCT
BOOK
Happenings:
BIRTH
RESERVATION
MEETING
Associations:
MARRIAGE (husband - wife)
ORDER LINE (product - order)
Recognizing Entities
Determine what your entities are by doing the following:
Talk with your client and think about what the business does.
Find out what entities are used in a business of this type.
Listen for nouns and occurrences carefully.
For example, your client makes the following statement about the
business, Our main business is what we call recondition clothing.
Our customers are companies which import various textiles. They often
import shiploads full of shirts or dresses from far away. They ship it in
large containers that arrive in the harbor over here. When the clothing
gets unpacked, it often looks like it has been worn before. Nobody
would buy that. So our customers contract us to iron it, sometimes
wash it, put it on a special clothes hanger and often prepare it for
further transport to warehouses or shops.
Take a minute or two to write down some of the entities you will expect
to be of importance; all of the nouns are a good starting point. You have
probably never heard of the business of reconditioning clothing but you
will recognize entities like CUSTOMER, ARTICLE, CLOTHING TYPE,
CONTRACT, TREATMENT, TREATMENT TYPE, SHIPMENT, LOT,
WAREHOUSE, LOCATION, and maybe some others. Maybe the
model that is used for the reconditioning company is completely
different from what is thought up here. That is not important. What is
important is that you have a feel for the entities involved.
Naming Entities
Do not underestimate the importance of names. An entitys name
should uniquely identify that entity in a manner that is understood by
the target audience for that model. The audience should generally be
able to describe to you what an entity is from just the name.
Candidate Names
Search for a word that, according to a good dictionary, has a meaning
close to what the entity stands for this usually covers some 80 % of
the naming problem.
Ordinary words are known by many people and have a rather sharp
definition; if this definition overlaps with the intended meaning of the
entity, use that word. Realize, however, that if a general every day
word is used for something with a slightly different meaning, it will be
unnoticed and therefore confusing for someone who knows the entity
name but not the definition.
There may be information within a business that has become so
synonymous with the mechanism used to capture or retrieve it, that
using the name of that information would only lead to confusion. It
may be useful here to use a new word to describe the information, in
order to avoid confusion with the mechanism. This technique must be
used sparingly, as this entity will no longer be recognizable by the client
and will have to be explained.
Oracle Method
Use entity names that consist of several words if these describe the
entity properly; there are many more entities than there are nice, short,
and perfectly fitting names.
Use the traditional name, as used by the customers company.
Traditional names often seem to be the best names to use because they
are well known and already in use; these are usually the customers
favorites. However, traditional names often have a long record of
covering shifting meanings. Always check that an entity named with
such a traditional name can be well defined, by you, to everyones
satisfaction. If not, let the customer suggest a name that can.
Use a name that is used elsewhere in the client business area. The use of
business jargon is very prevalent in certain businesses. Learn the jargon
and use it for modeling if you are sure the whole of the audience is
aware of the jargon. Make sure that a description of the jargon is held
within Oracle Designer to enable new personnel to understand the
jargon.
Use a logical construction based on combinations of new words or
jargon. Helpful words for combinations may include: ITEM,
ELEMENT, COMBINATION, EVENT, LINE, PERIOD, TYPE, etc.
Often there is someone around who is very creative in finding a nice
word for an entity. Never hesitate to ask those people for advice on
names. Never let your creative requirements modeling process during
an intense analysis session be halted because you cannot find a proper
entity name. Use whatever name you think of first, but at the end of the
session ensure that you have clearly defined the entity such that its
meaning is not forgotten.
Changing Names During Requirements Modeling

During requirements modeling, some entity names will change because
a significantly better name is found or because the initial definition of
the entity changes. Oracle Designer allows you to change names, but it
will not change references to that entity held as text, so reduce the
number of explicit entity names to a minimum. At the end of
requirements modeling, the entity names will have stabilized and all
descriptive texts must be scanned for erroneous references to renamed
entities.
Reserved Words
As the plural of the entity name will become the default table name,
avoid the use of names that in plural lead to reserved words or words
very similar to reserved words. In case of doubt: do not. Realize that
words that are now still unreserved may become so later on. So, avoid,
if possible, database and query programming language terms like
COLUMN, CONSTRAINT, USER, LOOP, END, VALUE, TYPE, and so
on.
Entity Short Names

A good construction mechanism for entity short names is very useful,
the main advantage being that users do not have to guess or to learn
short names by heart. Short names are used very often, during all
system development stages, so good naming saves time. The following
rules have proved useful in constructing unique three-character short
names at a high rate is the following:
1.
Example
ALLOWED STATE TRANSITION -->> ASN

LINE ITEM -->> LIM
2.
Example
Example
If the entity name consists of a single syllable word, use the first
two characters plus the last;
CLASS -->> CLS
COACH -->> COH
4.
Oracle Method
If the entity name consists of one word of two or more syllables,

use the first character of the first and second syllable plus the
last character.
DEPARTMENT -->> DPT
EMPLOYEE -->> EPE
3.
Example
If the entity name consists of two or more words, use the first
character of the first and second words plus the last character of
the last word.
If any part of this rule leads to a short name that is already in

use, then use the last two characters instead of only the last one.
ALLOWED STATE TRANSITION -->> AON
DEPARTMENT -->>DNT
Conceptual Views
Sometimes concepts seem to be entities but actually are composed of
other entities. Usually, these concepts can be seen as what could be
called a conceptual view, based on entities. Examples might include
PRICE LIST, STUDENT PROFILE, etc. Unfortunately, on the
conceptual level in ERM, there is nothing comparable to a view as an
entity is to a table. In dataflow diagramming, conceptual views can be
represented as data stores. Data stores do not play a role in ERM.
Attributes
Attributes form the flesh and blood of entities; they are the information
held about an entity. Entities without attributes are very rare.
Attributes must apply to few instances of an entity, for example the
chassis number of a car is unique to that car and the date of
manufacture may be common to only a few cars in the business, but the
manufacturer may be the same for many types of cars and should be
stored as a separate entity.
Reference: For more information, refer to CASE*Method
Entity Relationship Modeling.
Examples
Attributes Straight Attributes:
Name
Short Name
Id
Description
Birth date
License Number
Score
Attributes Process-oriented:
Creation Date
Last Update By
Approved Indicator
Available Since
Unique Identifier
Every entity must have an attribute, a relationship, or a combination of
attributes and relationships that uniquely identify it. Refer to Chapter 3,
Business Rule Modeling, for more information on modeling unique
identifiers.
Oracle Method
Attributes and Relationships

A frequently made mistake is to define attributes that, in fact, should be
represented by a relationship. Every attribute can, on the other hand, be
modeled away by a relationship to some new entity, because every
piece of data can be promoted to an entity if additional information
about the attribute itself are needed. This can be the case if old attribute
values have to be kept or, to give another example, in cases of multilingual design. Compare the two models in Figure 4-1.
Figure 4-1
Attributes and Relationships
Relationships
Relationships should always be named since there can be various
relationships between two entities, and their purposes must be known.
There are many different relationships possible between two entities; for
example, between the entities PERSON and COMPANY the relationship
is currently working for may be of interest, but so is the relationship is
owner of. You must give each end of a relationship a name, an
optionality, and a degree (1 or many).
Optionality and Degree

The terms many-to-many, m:m, and m:n all mean the same thing.
The type of relationship that occurs most often is as follows:
Example
m:1 >> - - - - (mandatory m to optional 1)
Usually, about 80% of the relationships in a normal model are of the

above type, while about 20% are likely to be as follows:
Example
m:1 > - - - - - - - -
(optional m to optional 1)
m:1 >
(mandatory m to mandatory 1)
1:1 - - - - -
(mandatory 1 to optional 1)
1:1 - - - - - - - - - - (optional 1 to optional 1)

m:n >- - - - - - - - -< (optional m to optional n)
It is very unlikely that you will find correct examples of the following:
Example
m:n > - - - - -< (mandatory m to optional n)

m:n >< (mandatory m to mandatory n)
1:m - - - -< (mandatory 1 to optional m)
1:1 (mandatory 1 to mandatory 1)
It is a good practice to convert as many of the non-m:1 relationships as

you can to m:1 relationships; non-m:1 relationships are often incorrect.
Oracle Method
If the model is to be used as the basis for design, other forms of

relationships are often extremely difficult to implement.
Naming Relationship Ends

When English is the working language, naming relationship ends
according to the following scheme results in proper sentences:
Example
EACH <singular Entity Name>

[MUST|MAY] BE <relationship end name>
[ONE AND ONLY ONE|ONE OR MORE] <singular|plural Entity Name>
Read as follows:
EACH car MUST BE manufactured by ONE OR MORE manufacturers.
EACH person MAY BE the owner of ONE OR MORE cars.
EACH tree MUST BE grown from ONE AND ONLY ONE seed.
In a hierarchy, the instance of the entity at the single end of the
relationship is often called the parent and the one at the many end, the
child. For example, a car manufacturer makes many cars, so the
manufacturer is the parent and the cars the children.
Unfortunately, this type of phrase cannot easily be automatically
translated into another language, as the fixed text in many languages
would depend on the gender of the entity name. Compare
Toute/Tout in French, Jede/Jeder in German, and so on.
Hierarchical Relationships
A 1:m relationship between an entity and an occurrence of the same
entity leads to what is often wrongly identified as a hierarchical
relationship. The classic example of this is the manager-employee
relationship. A manager is one employee who manages many
employees and is in turn one of many employees managed by a
manager. This may sound hierarchical, but a staff member may be
responsible to many managers, in which case the relationship is no
longer hierarchical. It has become a network.
Figure 4-2
Modeling a Hierarchy
If a hierarchical relationship is used, then the following statements

apply:
Oracle Method
An instance of the entity can not have the same relationship to

its parent as the parent has to it. For example, if there is
hierarchy between continents and countries, then a continent
cannot be inside a country.
There is no limit to the number of children a parent can have.
The children cannot inherit the values of the parents.
There is no limit to the number of levels a hierarchy can have.
Try to read the different conceptual consequences of the models in

Figure 4-3. What model, if any, shows:
a customer (B) can never be owned (xxx) by itself?
a supplier (C) can never be owned (xxx) by itself?
an organization (A) can never be owned (xxx) by itself?
the number of levels is limited?
Figure 4-3
Different Conceptual Consequences
Subtypes and Supertypes

Sometimes it makes sense to subdivide an entity into two or more
subtypes. These subtypes can be subtyped themselves. An instance of
the supertype must be classified in one and only one of the subtypes. If
an instance of the supertype can either be classified in none of the
subtypes or more than one of the subtypes, then the model is incorrect.
Reference: For more information, refer to CASE*Method
Entity Relationship Modeling.
Example
ARTICLE with subtypes FOOD and NON FOOD

NON FOOD with subtypes DETERGENT, CLOTHING, HARDWARE
Figure 4-4
Modeling the ARTICLE Example
The first classification is fine. For every article it is rather easily

established whether it is food or not; the number of problematic cases
will certainly be small. The second classification can be correct, but may
not be total. What if the supermarket wants to sell gasoline in the
future? It may seem to be a good idea to complete the subtyping by
adding a keystone subtype OTHER NON-FOOD. This at least
guarantees that the subtypes are total. Gasoline would fit perfectly in
here.
It is better, however, to add a new classification entity like NON-FOOD
TYPE, or, even better, ARTICLE TYPE, to the model, instead of this
second layer of subtypes. Realize that subtypes always exist. Every
entity can be subtyped; that is not the issue. The issue is whether it is
useful to make the distinction. If a supertype has a subtype, then the
supertype and the subtype have an implicit 1:1 relationship.
Oracle Method
Naming of Subtypes
It is a good test for the usefulness of subtyping in a particular case if
good names can be found. If not, reconsider the subtyping. Suppose
you modeled entity A with a subtype B (see Figure 4-5). How do you
name the complementary subtype? In the best case: a word X exists
for the complement of B within A. Then use X. NON-B is a name that
is often chosen. However, the name does not show that it is the
complement of B within A. More importantly, if during requirements
modeling another subtype, say C, of A comes along, the name NON-B
must change. Another often used name is OTHER A. If a second
subtype C comes along, now the name OTHER A can remain the same,
but it is important to realize that implicitly the definition has changed.
Figure 4-5
Naming Subtypes
Supertypes
If two or more entities have relationships or attributes in common, this
may be modeled by creating a supertype for the entities. Be aware that
if you create a supertype B for entities A1 and A2, you implicitly state
that every B is either an A1 or an A2. If not, add a subtype entity NONA1 NON-A2 WITHIN B, or OTHER B.
Implied Subtypes
A frequent mistake is to model implied subtypes. Suppose a company
delivers both services and products; all order lines can be divided into
service order lines and product order lines. This is an implied subtype of
order line that usually can remain implicit. In other words, always
carefully check the constructions, as in Figure 4-6.
Figure 4-6
Implied Subtypes
Arcs and Subtypes

An arc is a particular constraint that has its own symbol in ERM. An
arc is used to show that two or more relationships mutually exclude
each other, such as, ORDER is always either for a PRODUCT or for a
SERVICE. Arcs should only be used for relationship ends that belong
to the same entity, are of the same degree, and are of the same
optionality.
Care must be taken when deciding on the best representation, using
either subtypes or arcs, to make sure that the ERM is both correct and
readable. In most cases, a model with subtypes rather than arcs can be
read more easily. In Figure 4-6, the arc could be modeled away by
introducing a supertype (for example, MONEY MAKER) for entities
SERVICE and PRODUCT.
Almost Subtypes
Often an entity can be divided into important non-disjunct subgroups.
For example, this is quite likely the case for an entity representing
customers, supplying companies, employees, and so on. Suppose this
entity is called CONTACT. A company that supplies goods can be a
Oracle Method
customer as well; an employee may be a customer, too; in short,

CONTACT has no real disjunct subtypes, only almost subtypes.
There are various ways to model this situation (see the following
example). All have their advantages and disadvantages. Each of the
three models can be the best choice in a specific situation.
The model in Figure 4-7 ignores the communality of the three entities;
all common attributes and relationships are repeated. In consequence, if
you are an employee as well as a customer, then your address
information must be stored twice.
Figure 4-7
Almost Subtypes (1)
The model of Figure 4-8 does the opposite: it ignores the differences
and boils all entities down to one entity CONTACT. The various almost
subtypes can now be found as part of the names of the relationships.
Separate indicator attributes have been added for easy recognition.
Note that a mandatory relationship or attribute for an almost subtype
now becomes optional. This means, in short, that some constraints have
to be defined separately that could otherwise have been a part of the
conceptual model.
Figure 4-8
Almost Subtypes (2)
The model of Figure 4-9 is a mix of two worlds. It shows the various
almost subtypes as separate entities, and shows the communality by
keeping common attributes and relationships in entity CONTACT. The
1:1 relationships keep them tied together. One problem here remains.
Where do we put an attribute or relationship end that applies to some
but not all of the almost subtypes?
Figure 4-9
Almost Subtypes (3)
Figure 4-10 Almost Subtypes (4)
The model in Figure 4-10 is a more generic structure than what is shown
in Figure 4-9. It models the concepts of ROLE and ROLE TYPE
explicitly. All attributes and relationships of the subgroups must be
united in ROLE. A mandatory attribute for, say, SUPPLIER, must now
again be modeled as an optional attribute for ROLE. The attributes and
relationships that apply to all groups must be modeled in CONTACT;
all others will be placed in ROLE. Again, extra constraints need to be
Oracle Method
defined to cater for attributes and relationships that are mandatory for
only some subgroups.
Generation Be aware that more generic structures lead to additional functional
complexity. If your data model contains mainly straightforward flesh
and blood entities, then the code generated by Forms Generator is
probably acceptable. However, if your model is of a higher abstraction
level, then the generated code often requires more post-generation
manual adjustments.
ER Diagrams
Drawing ER diagrams of a data model helps the process of thinking
about the data structure. Diagrams also help you to communicate your
thinking. This section addresses the following topics:
Knowing Where to Start
Testing the Data Model
Merging Structures
Cleaning Up
Knowing When to Stop
Verifying the Data Model
Do not confuse your sketches with a final data model. When using
Oracle Designer Entity Relationship Diagrammer as a sketching tool,
use a separate application system for sketching purposes. This can ease
the tidying effort required, as the sketching application can be dropped
without affecting the final data model. The final data model can be
drawn afresh. If the sketch develops into the final data model, then
there will be work involved in tidying the sketch dictionary entries to
ensure that they are correct.
Knowing Where to Start

Start sketching, ideally on a white board, some entities you initially run
into, and try to draw a logical connection between them. The
connection includes relationships and probably entities that are newly
discovered during the session. Remember, these are only sketches.
Testing the Data Model

Talk through the model from entity to entity, describing to a
colleague why the entities are there, why they are important, how the
entities relate, why they relate, why it is important to have the
relationship in your model, and what constraints apply. Start at several
different places; take any direction you feel is important. These sessions
should go smoothly. If not, rethink the part of the model where you get
Oracle Method
stuck. Then switch roles: let a colleague convince you. Your own
arguments spoken by someone else often sound less convincing.
Merging Structures
If two parts of the models are very similar, you should consider
combining them and making the model more generic. You should
always ensure that business information is not lost when structures are
merged.
Cleaning Up
When your data model is ready, spend some time putting the finishing
touches to the diagram. The model layout must be well presented as it
will be the portrait of the system.
Remove as many crossing relationship lines as possible, by slightly
moving entities. Make sure the lines are parallel or perpendicular.
Extend or decrease the size of entity soft boxes; remove unimportant
reoccurring relationship lines and entities entirely, and replace them
with a small symbol.
Make separate diagrams for each important business area and
application system. Start every time from a diagram copy of the
model. Undress it, peel away all insignificant components, but keep the
old floor plan in tact, for reasons of recognition.
Knowing When to Stop

A data model is ready once all necessary functions of the system can be
properly served by the entities, attributes, and relationships. This can
be checked by populating the CRUD matrix. But, of course, this
presupposes the availability of all function definitions.
On the other hand, for functions, the minimal set can always be
specified. This is the set needed to support the full life-cycle of all
entities.
Completeness of a data model can only be checked indirectly and
depends on the function model.
Verifying the Data Model

Every data model reflects parts of the universe of discourse for the
customers business. A particular companys view of its universe of
discourse often overlaps substantially with those of other companies.
For that matter, usually large parts of any data model can be checked by
an outsider, just because the data model is true (or not) in its own right,
independent of the business. Therefore, it often makes sense to discuss
the data model with a knowledgeable outsider who did not participate
in the requirements modeling.
Oracle Method
CHAPTER
Function Modeling
T
his chapter describes relevant issues for the process of function

modeling and provides guidelines for the following:
Oracle Method
Overview of Function Modeling
The Function Hierarchy
Elementary and Non-Decomposed Functions
Function Definition and Description
Function Entity Usage
Function Attribute Usage
Common Functions
Verifying the Function Model
Function Modeling 5 - 1
Related CDM Tasks

Classic Approach:
5 - 2 Function Modeling
Create Composite Business Function Model (RD.031)
Refine Requirement Models (RD.115)
Overview of Function Modeling

We should distinguish between the modeling of business functions versus
the modeling of system functions.
Business Function Modeling

A business function model provides an overview of all the necessary
and desired functionality of a business that is required to achieve the
business objectives. The business functions describe not only what the
business does, but also what it should do.
The scope of investigation is a business area, and focus is on what the
business has to do to meet its objectives. There is no distinction
between manual functions and functions that need to be supported by
the computer system. A sound business function model remains valid
as long as the business objectives do not change. Any change in the way
the business is run, (the how), should not affect the business function
model.
System Function Modeling

A system function model focuses on functionality that must be
implemented or supported by the computer system. This includes
functions which:
Oracle Method
completely implement business functions
provide support for selected steps of business functions
provide different groups of users with different ways of

performing business functions; for example, an infrequent
users function and a fast-path function for regular users
support the way the users will work with the system or to help
them achieve their business functions, such as functions to
support the flow of work between users, like work flow
queuing and management functions
required to help administer the operation of the system, such as:
perform error logging and reporting
administer or control system restart and recovery
report shortage of resources, such as database space
monitor the integrity of data
control the flow of processing through the system, such as:
administer and support the proposed technical architecture,

such as network message transmission, routing and
reception
provide processing workload scheduling; for example,

batch queuing, sequencing, and monitoring functions for
reports and large overnight jobs
provide real-time processing flow and queuing mechanisms
distribute data across geographically dispersed systems
Business versus System Function Modeling

Because the technique of functional decomposition is the same in both
modeling approaches, the rest of this chapter does not explicitly carry
forward the difference between business function and system function
modeling. When the word function is used in the remainder of this
chapter, it refers to a business function as well as a system function.
However, you should be aware of one main difference. During system
function modeling, you should restrict yourself to modeling and
describing functions that represent presentation logic. The internal
application logic should be described separately as business rules. Refer
to Chapter 1 of Volume 2 for more information on the reasons for this
distinction. Although some of these business rules are recorded in
Oracle Designer using the function object (in a separate hierarchy),
business rule modeling should be treated as a discipline of its own, and
not be confused with functional decomposition techniques. Refer to
Chapter 3, Business Rule Modeling, for more information on business
rule modeling.
CDM identifies two separate deliverables for the business function
model and the system function model. This does not mean you will
always end up with two separate function hierarchies. It is very
common to have one function hierarchy with the higher levels
representing business functions and the lower levels representing

system functions. In general, the what (business functions) , as opposed
to the how (system functions), can only be taken down two or three
levels of decomposition within a function hierarchy. Below that, one
usually sees mechanisms on hierarchies. The matter of two separate
function hierarchies will depend on the needs of the client and the
complexity of the business.
Cross-Checking with the Data Model

Often, in Business Requirements Definition, only the functional outlines,
(for example, the top layers of the function hierarchy), are described.
Then a lot of time is spent on creating the entity relationship model.
However, it is impossible to create a data model without at least an
implicit concept of the functions involved. For this reason, it is essential
to start making the functions explicit as early as possible and not to
postpone describing the functions to the last few days of requirements
modeling. Many discussions on the data model are actually discussions
on the functionality and vice versa.
Oracle Method
Function Hierarchy
The set of functions, the function model, is best organized in a
hierarchical structure. The hierarchy shows how each function breaks
down into subfunctions from the business mission statement at the top
to the simplest functions at the bottom. By using this structure, you will
discover missing functions and see possibilities for decomposing
functions or for consolidating them. Describing functionality helps you
to explore various useful levels of abstraction. The hierarchical
structure is easy to grasp, gives a good overview, and is relatively easily
verified.
Keep in mind that any new functions that are discovered while
analyzing or decomposing the function hierarchy most likely also
represent deficiencies in the process model. You should always plan to
keep the process model and function model coordinated.
What a Function Hierarchy Does Not Do

A function hierarchy does not say anything about the importance of
functions. Nor does a hierarchy say anything about the sequence of
processing individual functions. Another thing a function hierarchy
does not do is force you to think, or work, or act top-down.
Let us take the issue of preparing a Sunday lunch as an example. What
functions are involved in that business?
Example
-prepare lunch is
--get bread from freezer
--toast bread
--pour milk in a glass
end
Is anything redundant? Anything lacking? From where does the milk

come? And the glass? Do you eat only toasted bread? Nothing on it?
Always? Apparently, preparing lunch is first collecting some things
and then doing some preparation before eating and drinking. So, lets
try lunch version 2:
Example
-prepare lunch is
--get food
---get skimmed milk from fridge
---get the delicious whole-wheat bread from cupboard or freezer
---get marmalade from cupboard and cheese from fridge
--prepare food
---toast several slices of bread
---make a cheese and marmalade sandwich
---pour a half glass of milk
--eat food
---eat two sandwiches
---drink milk
end
For modeling business functions, this version adds too much detail. It
tells far too much about how things are done. When modeling a system
to automate these functions it is okay to describe the how, because it
helps you and the user to visualize the system.
Business functions should be concerned with what, using the how only
as an example. It is better to try to formulate the functions accurately as
early in the process as possible to avoid re-work later.
Now have a look at Lunch version 3:
Example
-prepare lunch is
--get food
---get milk
---get bread
---get cheese and marmalade
--prepare food
---toast bread
---make sandwich
---pour milk
--eat food
---eat sandwiches
---drink milk
end
Realize that in this example various functions, on various levels, could

rightfully be described as prepare sandwiches; for instance, prepare
lunch, prepare food, toast bread, and prepare sandwiches. This
is something you always run into: several functions, often on different
levels in the hierarchy, could be defined with the same phrase. Oracle
Designer, by the way, allows you to define various functions with the
same definition.
The wording of every function can always be done more generically:
rather than saying get milk one can say get drinks. This leaves
open whether the drink is milk or coffee or whatever. You should
Oracle Method
always try to use generic wording as much as is reasonably possible,

especially on all but the lowest level.
Attention: Functions can (almost) always be expressed as a
phrase that starts with a verb. Function definitions and
descriptions should always use active language.
The Ryders family version of having lunch:
Example
-prepare lunch is
--collect ingredients
--prepare food
---bake bread
---fry eggs
--prepare drinks
---boil hot drinks
----boil coffee
----boil tea
----boil chocolate
---squeeze oranges
--lay the table
--pick flowers
--arrange flowers
--select music
--collect lunch participants
--check various supplies
--maintain shop list
end
Sometimes two sets of potential system functions are essentially

covering the same functionality, but one is much more luxurious than
the other. Achieving clarity on the level of luxury is one of the goals in
system analysis. Prototyping can be used successfully to grasp your
customers wishes in this respect. Examples of little functional luxuries
include:
Example
data entry help, context sensitive list of values, copy (partial)

record buttons, portable context information, well chosen defaults,
user-dependent defaults, smart keys, etc.
Examples of major functional luxuries include:

Example
a function that suggests a driving route from A to B, a function

that creates an allocation, a function that searches for the best
available slot, a function that automatically sends alerts if stock
reaches a certain level, etc.
Software Packages
If standard software packages (logistics, accounting, and so on) play a
role, always define at least the highest level functions that are covered
by these packages and any areas of concern. Compare the package and
the requirements, and decide if the overhead of using the package is
outweighed by the functionality it offers.
Where to Start
Start with a top function that reflects the goal of the company or
division. Divide that function into between three and eight child
functions. Try to keep sibling functions at more or less the same weight.
If you exceed eight child functions for one parent, add a layer of
functions in-between. As a confirmation, also start with some
supposedly elementary functions, ensuring their grouping is correct.
Gaining an understanding of the current systems can ease
communication between the analyst and the client, but it may lead to
confusion between the how is it done at the moment and the what is
being done. Consider the following:
what the current system can and cannot do
what the users see and experience as the strong and pleasant
aspects of it, what they like
what the users see as the weak parts, what they do not like
Sometimes, it is very difficult to define functions. This could be the case

if, for example, an entire new line of business is set up and the analyst is
not an expert in that line of business. The subject matter is relatively
new for all players. For system development projects, functions can be
defined in terms of the life-cycle of the entities; for example, define at
least one function that inserts, updates, deletes, and retrieves the entity
for every entity type. This, of course, is the bare minimum, but is a
good place to start.
Where to Stop
Stop when all functions that will be supported by the system are
decomposed to their elementary level. Elementary means that if the
Oracle Method
function, when executed, always fully succeeds or, if not successful,

fully removes its trails.
Top-Down versus Bottom-Up

As long as the model is unbalanced, you are not ready. Brother
functions should be decomposed such that they each have more or less
the same number of levels. If this is not the case, check whether joining,
and thus re-phrasing, some of the functions might work. Check
whether individual function descriptions still contain various verbs and
phrases chained by the word and. If so, these functions are
candidates for another split. Working bottom-up or top-down are two
approaches to the same goal. You cannot say top-down is better or
easier than bottom-up; nor the other way around, for that matter. It is
probably true that the best way often is a middle course. Use the topdown approach to quickly create a hierarchical function structure. Use
the bottom-up approach to fill in the gaps and to cross-check that the
known elementary level functions the ones you have noticed by just
looking around really fit in the hierarchy; or make sure these fall
explicitly outside the scope of the system.
Elementary Functions and Non-Decomposed Functions

A function model should be broken down to elementary and atomic
levels, unless the client has agreed that this level of detail is not
required. An elementary function is one that must be completed to
ensure business integrity once it has started. For example, if you are
transferring money from one account to another, first an account is
debited, then another is credited. The customer would not be happy if
the account were debited without the other being credited, so this is an
elementary function. The separate functions of debiting and crediting
are atomic functions.
Functions that are not decomposed and not elementary also exist.
Usually it means the function has not yet been decomposed in the
process of creating the function model. Another reason can be that an
entire branch of the function hierarchy is not developed; for instance it
is outside the scope of the system or it will be covered by an existing
package.
Oracle Method
Function Short Definition and Description

The Function Short Definition in Oracle Designer acts as a limited length
(70 positions) long name for the function. This is often not enough to
actually define the function. Therefore, the Function Description is
really the place to define the function extensively. Do not make long
function descriptions when the function model is still unstable; use the
descriptions in that case only if you need more space to clarify the
intention of the function. During requirements modeling, you will be
able to make full descriptions of most of the elementary functions that
are stable by then. Do not describe non-elementary functions
elaborately. Use a set of fixed headings for the function descriptions.
Whenever possible, add an example of a typical situation where the
function is performed. Remember, the function descriptions will be
read and judged by a non-technical public. Record all technical remarks
under Notes and Remarks.
Function Frequency
Frequency of a function is not a measure of its importance, nor does it
necessarily affect the required response time. A lookup type of function
that is used 600 times a day, while a customer is waiting on the
telephone, clearly requires a quick response. A crisis procedure for an
event which occurs less than once a decade also needs a very quick
response.
It is not the frequency, but the nature of the function, that tells
something about how crucial a function is for the business.
Then what is the use of entering frequency information? First, it is very
useful business information, as it identifies the areas where work could
be reduced by streamlining. Second, it helps identify the function. If
your concept of a function actually differs from that of the customer, but
you do not know the concepts are different, it is unlikely that you will
agree on the frequency of the function. Function frequency information
can also be vital for the subsequent design of the system, as the system
must have sufficient capacity to handle the required volumes.
Function-Entity Usage
The association between business functions and entities is known as the
Function-Entity Usage or Function Entity CRUD (Create-RetrieveUpdate-Delete) matrix. The Function-Entity Usage matrix ties the two
major models together. This association is used to define what entities
are used by a particular elementary function, and how the entities are
used.
The Function-Entity Usage matrix is the major check that can be used to
make sure the data model and the function model are consistent and
complete. For every entity, there must be a function that allows for the
various states in the life-cycle of the entity. Every function must have at
least one entity associated with it, unless there is a very good and
documented reason why there is no entity involved. This can be the
case, for instance, if the function is elementary but decomposed.
The Function-Entity Usage matrix is useful for discovering functional
overlap and missing functionality.
Two functions with more or less the same CRUD entries can sometimes,
but not necessarily, be identified, and sometimes they can be merged
into one, more generic, function. Checking the CRUD matrix can
therefore be of help in your search for missing or duplicate functions, or
in your quest for possible mergers.
The Function-Entity Usage matrix must be populated completely for all
functions and all entities. But what is meant by completely in this
respect? If function F allows you to create instances of entity ORDER,
and ORDER has a mandatory relationship to CUSTOMER, should
CUSTOMER be mentioned as well in the CRUD matrix? And what if
the reference is not mandatory? And what if F also allows deletes of
instances of ORDER? Should ORDER ITEM then be in the CRUD
matrix as well?
There are two good alternative approaches here. One is to be as
complete as possible. Mention every entity that might be involved in
this function. So, if ORDER is the base entity for function F, then
make Create, Retrieve, Update, and Delete entries for ORDER. If
CUSTOMER is queried to check the relationship, then make the
Retrieve entry for CUSTOMER. If ORDER ITEMS can be created and
updated through F, make Create, Retrieve, and Update entries for
ORDER ITEMS, and a Retrieve for ARTICLE.
Oracle Method
The result would be as follows:

Example
Function
ORDER
CUSTOMER
ORDER ITEM
ARTICLE
CRUD
YYYY
Y
YYYY
Y
An important advantage of this approach is that it forces you to think

about the exact functionality and entity usage; it is useful information
for checking and cross-checking the entity and function models, but it is
quite a lot of work. If you use this approach for one of the elementary
functions, you have to do it for all. To some extent, this same type of
work will be done again when creating or checking the
MODULE-TABLE CRUD matrix in systems design.
A second approach to the use of the CRUD matrix is only to mention
the base entities of the function, and to leave all the other entities implicit
as the usages are a result of the standard way of treating a relationship.
The result now would be:
Example
Function
ORDER
ORDER ITEM
CRUD
YYYY
YYYY
The advantage is, of course, that it saves you a lot of work now which,
nevertheless, has to be done at some point during systems design. The
non-base, implicit entities will be used by the future module as a
consequence of the relationship definitions and the rules applying there.
You could postpone adding the CRUD details until systems design.
Oracle Generators will find foreign key columns in a table and will
generate lookup functionality and foreign key checks.
Special attention must be paid to functions that allow transfer of a
relationship, that is, a function that enables you to transfer the
assignment of the occurrence A1 of entity A from B1 to B2. A typical
example is the function, Reassign Employee to New Department.
A function that will be used for the transfer of the relationship from
entity A to B is marked as Update for entity A and Retrieve for B. Note
that it is not possible to mention the function usage of a relationship, as
such.
Tools
The Matrix Diagrammer provides an easy to handle, two-dimensional
interface to the Function-Entity Usage. This diagrammer is especially
useful for creating the initial matrix. It is, however, easier to add the
details through the Oracle Designer tabsheets. Later, when the matrix is
(almost) ready, the Matrix Diagrammer gives a good overview and a
very simple access path to the usages that are shown in the cells.
Oracle Method
Function-Attribute Usage
About the same story that applies to the Function-Entity Usage matrix
applies to the Function-Attribute Usage matrix. This matrix is very
detailed and consequently requires a good deal of work, and may well
be left to system design, where its counterpart, the Module-Column
matrix, can be used. This matrix is also often referred to as the
Attribute CRUD matrix, although in a Oracle Designer environment
the name IRUN (for Insert, Retrieve, Update, and Nullify) would be
better. By populating the matrix, you check and cross-check the
attributes and functions. All attributes must be used by at least two
functions, one that Creates (Inserts, to be precise) the attribute and one
that Retrieves it (usually a report). If this is not the case, either the
attribute is obsolete or some functionality is missing. This matrix is
very useful for clarifying functionality. The standards on FunctionAttribute Usage do not prescribe in detail the function usage to attribute
level, unless it helps to clarify some of the functionality. If you specify
attribute usages, specify them all for the particular entity.
Attention: Not all combinations of Function-Entity Usage
and Function-Attribute Usage make sense. For example, if
for a particular function the Usage of Entity ORDER is
defined as Retrieve only, the Usage for an attribute of
ORDER, Orderdate, logically cannot be Update or Nullify. In
other words, some usages at the attribute level imply a usage
at the entity level. Oracle Designer does not check for
consistency between the two usages.
Common Functions
The function hierarchy should represent the net total usage of all
functions of the application system. It should function as an intelligent
catalog of all functions, organized by functional breakdown. In other
words, you should not repeat functions in different branches, unless it is
absolutely necessary. If a single function is executed as part of multiple
processes, you should use global process steps. Refer the section,
Building and Using Function Hierarchies with Oracle Designer, in
Chapter 2, Processing Modeling, for more information on common
functions.
Function Network
The function network can be recorded in Oracle Designer using the
Trigger tabsheet in the Function Hierarchy Diagrammer. By selecting a
function on this tabsheet, a function can be indicated to be executed as a
result of executing another function.
If a function, Fa calls function, Fb, then an entry is made in the Function
Triggering Function screen. Meanwhile, an event (named END-Fa) is
created automatically by Oracle Designer.
Attention: Oracle Designer does not check for loops in the
calling scheme: Fa calling Fb and Fb calling Fa are accepted
at the same time.
Attention: Do not confuse these function triggers with true
business events! Refer to the section, Modeling Primary
Processes, in Chapter 2, Process Modeling, for more
information.
Oracle Method
Verifying the Function Model

The primary way of verifying the function model is to discuss it
interactively with the users whose roles the model represents.
Verifying the function model can also be done in several other ways.
Higher Levels in the Hierarchy

Companies that are active in a particular business area will use roughly
the same functions at a high level. Verifying the function model can
thus be done merely by comparing the model with known models of
similar companies. It is evident that, in order to do this job, one has to
have at least some general knowledge of the business area.
Lower Levels in the Hierarchy

When verifying the model at the lower levels of the hierarchy, common
sense may be the main tool used. Answer questions similar to the
following:
Do these functions really add up to the parent function?
Does this split really makes sense?
Do these functions really cover the scope completely?
Is there an unnoticed overlap between functions of various

branches?
Lowest Level in the Hierarchy

Verifying the lowest levels in the function hierarchy can best be done by
populating the Function-Entity Usages and carefully checking them.

When constructing an overview of all necessary and wanted
functionality, keep the following concluding remarks in mind:
Every function can always be decomposed.
Every set of functions can always be merged.
Frequency of a function is no indication for its importance.
Business functions vary from company to company within the

same business area; the differences are mainly at the lower
levels.
Functions must always be expressed in active language, usually

starting with a verb.
Every function can always be implemented offering little or

much luxury.
Functions that are luxuries in the analysts eyes may be the bare
minimum for someone else; thus, the level of luxury must
always be made explicit.
No function can be fully, absolutely, unambiguously expressed

by a definition, or even by a two-page description. There are
always implicit pre-suppositions.
If two functions are conceptually the same, it is very likely that

their definitions differ; it is very likely that both descriptions
differ.
Two functions that are conceptually different, can rightfully have

the same definition; they may even have identical descriptions.
Parent functions should have between three and eight child

functions in order to get a reasonably balanced hierarchy.
Child functions do not have detail information of their own.
It is impossible to create a data model without at least an

implicit concept of the functions involved.
Many data model discussions are actually discussions of the function

model and vice versa.
Oracle Method
CHAPTER
Prototyping
T
his chapter provides guidelines on the use of prototyping during

requirements modeling. The following topics are covered:
Oracle Method
General Guidelines for Prototyping
Goals of Prototyping During Requirements Modeling
Risks of Prototyping
Conducting Prototyping Sessions
Prototyping using Oracle Designer
Prototyping 6 - 1
Related CDM Tasks

The technique of prototyping applies to the following tasks within the
Classic Approach:
Create Initial Business Data Model (RD.040)
Construct System Data Model (RD.080)
Create Business Process Model (RD.010)
Create System Process Model (RD.100)
Develop User Interface Style Definition (TA.100)
6 - 2 Prototyping
Develop Look and Feel Prototype (AD.010)
Validate Look and Feel (AD.015)
Develop Functional Prototype (AD.040)
Develop Group of Modules (AD.060)
Release Application (AD.070)
Validate Requirements (AD.080)
Approach to Prototyping
Prototyping is a very useful technique when used in the right place for
the correct purpose. However, uncontrolled prototyping can be bad for
the health of a system, as well as for your credibility as a system
analyst/designer. Frequent problems found with its misuse include the
duplication of data and functions, no common look and feel, no
documentation, and generally incoherent systems.
General Guidelines
To be successful at prototyping, there are some basic rules you must
obey:
Clearly communicate the purpose of the prototyping session to

the participants.
Clearly communicate to the participants that the prototype will

be thrown away afterwards. It is NOT the first draft of the final
application system.
Make sure the participants of the prototyping session are key

players in the user community. Are they respected members of
the user community and able to convince their colleagues?
Carefully prepare and plan the prototyping session.
Document the findings of the prototype session (preferably in

an issue management system), and let the participants sign off
on these findings.
Goals of Prototyping During Requirements Modeling

During requirements modeling, prototyping will typically be used for
assessing the following:
Oracle Method
system requirements Is this what is needed?
usability Is this the best approach to fulfil the needs?
user interface requirements Is this the way the system should

look and feel?
Prototyping 6 - 3
It is quite obvious that these different purposes require different mind

sets on the part of the participants. End users, in particular, tend to
focus on details that are probably not important to you at the time.
When you want to validate system requirements, they may be focusing
on the screen layout and function key usage. When you want to assess
the usability of system functions, they may be correcting the example
data used in the prototype application. When you want them to judge
the look and feel of the system, they may want to discuss the
functionality of the screen instead of the general user-interface. Of
course, this is somewhat exaggerated, but anybody who has conducted
prototyping sessions knows that these kind of things happen from time
to time.
By following the general guidelines as described above, you are on the
right track to preventing prototyping sessions from being frustrating
and inefficient. However, there are some specific guidelines, based on
actual field experience, that you should also take into account:
Start off with prototyping the user-interface requirements of the

system. This will prevent the participants in later sessions from
being disturbed by look and feel issues.
When prototyping the look and feel of the system, do not use
screens that implement actual functionality of the system. This
only distracts from the real purpose of the prototyping session.
For prototyping the system requirements, it is best to operate

the screens yourself. This prevents the user from being
distracted by usability details, like navigation and window
handling.
For prototyping the usability, make sure the example data is

representative of the business area the system is to support.
Risks of Prototyping
Prototyping has the following risks associated with it:
6 - 4 Prototyping
Prototyping can be a never ending story, as users may change

their minds; adding or changing requirements at each
prototyping session.
Users may acquire a negative or premature attitude towards the

system, as they may begin to consider the prototype as the final
system.
The prototype may begin to set unrealistic expectations about

the system. The users may believe that the system can be ready
immediately after a prototyping session.
Developers may only focus on the prototype and neglect other

tasks such as performance tuning, data set-up, auditing, etc.
These risks can be mitigated by formalizing your approach to

prototyping. Prior to the execution of the first prototyping activity, the
project leader should clearly communicate the objectives, expected
number of prototyping iterations, and the goal of the prototyping
sessions to the project team and user community.
Conducting Prototype Sessions

As mentioned before, there are a lot of things that can go wrong when
using prototyping techniques. The previous sections provide you with
information on how to avoid the most common pitfalls. However, these
guidelines focused on organizing the prototyping session. There is
another very important but less tangible aspect that greatly affects the
results of prototyping sessions:
Your attitude towards the participants while conducting the sessions.
You are working according to the users requirements and these should,
of course, be reflected in the prototype. However, it is not always in the
users best interest that you implement requirements exactly the way
they were expressed during the prototype session without further
analysis. In fact, requirements should not be of such detail that they
completely prescribe the way you should implement them.
This room for creativity on your side makes it challenging to come up
with a solution that makes the user happy. But this room also exists on
the users side and their creativity is often underestimated. You may
have the feeling that you understand the different aspects of the users
requirements but they do not understand your concerns.
It is crucial to have good team-work between you and the user in order
to make sure you really DO understand the various reasons why the
user wants a particular piece of functionality a certain way. In doing so,
you will automatically find out all the pieces of functionality where the
how is not so important to them and where you therefore have more
room for inventive design. On the other hand, you will find that there
Oracle Method
Prototyping 6 - 5
are pieces of functionality that really must work the way they want in
order for the system to be a success.
This valuable information should not go to waste and can only be the
product of an open and constructive atmosphere during prototyping
sessions. Modeling requirements together with future end users is
really giving and taking. Giving and taking is really one of the most
important aspects of being a system analyst, and should not be
underestimated.
For the user participants, there is often only one thing that counts: the
usability of the final system. Of course, that is a goal you have in
common, but there are many other factors that you, as system
analyst/designer, should take into account. Apart from short-term
issues like available time, personnel, and budget, there are two
important longer-term factors that are often forgotten or
underestimated:
flexibility of the system
maintainability of the system
Why emphasize these two? Because an optimal use of the Oracle

Designer tool set has a very positive impact on these two factors.
Applications that are created with the Oracle Generators are very
flexible and easy to modify when changing information needs call for it.
With all system specifications in the repository, maintenance is much
easier, especially if upgrades to new versions of the tools (for example,
release 6i of Oracle Developer) are needed.
The generatability of the system requirements is key to producing a
high quality system in terms of flexibility and maintainability. When
evaluating user requests defined during prototyping sessions, the
generatability of these requests should always be taken into account. Of
course, at present, 100% generation is not always possible, but that does
not mean you should not strive for it! Finally, the end users will benefit
most from this attitude; although, in the short-term, not all their wishes
may be fulfilled.
6 - 6 Prototyping
Prototyping Using Oracle Designer

The transformers and generators provided by Oracle Designer are very
powerful tools for rapid prototyping.
The working sequence to create a prototype is not significantly different
from the sequence you apply when designing and generating pieces of
the final system.
Reference: Refer to Chapter 1 of the OM CDM Standards
and Guidelines Library, Volume 2 - Design and Generation of
Multi-Tier Web Applications for a detailed description of the
steps to perform.
Depending on the purpose of the prototype, you may want to omit
steps related to user interfacing and enforcement of business rules.
Working steps related to physical database design are usually not
performed at all, unless the prototype requires a bulk of example data.
Managing Design Objects

Creating prototypes with Oracle Designer requires you to create design
objects, like tables and modules, while you are still in the process of
modeling your system requirements in terms of entities and functions.
This raises questions on how to manage these design objects, and how
to feed this information back into the requirement models.
Applying the following guidelines will help you with this data
management issue:
Oracle Method
1.
Make a new version of the application system for

documentation purposes, just before starting the Oracle
Designer prototyping actions. The old version will
automatically be frozen. Start to define the design objects that
are necessary for the prototype in the new version. All
requirement modeling activities in different subject areas can
continue in the new version as well.
2.
Create all database objects required for the prototype under a

dedicated Oracle user.
Prototyping 6 - 7
6 - 8 Prototyping
3.
After finishing the prototyping sessions, export the entire

Application System and then import it under a different name,
for example, PROTO. Freeze this application system
immediately.
4.
Subsequently delete all design objects in the current version of

the Application System. You can use the Force Delete utility for
this purpose.
5.
Make a user export of the dedicated Oracle user to preserve the

database objects and sample data used in the prototype. Drop
the Oracle user afterwards.
6.
Finally, feed all the information gained from the prototype back
into the requirements models. This usually means modifying
the existing requirements and creating new entities, attributes,
relations, and functions. You can retrieve the definitions of the
prototype on-line from the imported application system
(PROTO). Do not forget to perform a cross-check between the
function model and the data model!
Index
A
agents, 2-27, 3-31
specifying, 2-39
application hierarchy, 2-57
arc, 4-19
attribute, 4-11
authorization
vertical data access rule, 3-33
authorization
function access rule, 3-32
horizontal data access rule, 3-34
authorization rules, 3-4, 3-31
B
bottom-up development, 5-10
business area, 2-12
business objectives
in process modeling, 2-13
business objectives, 2-13
business process, 2-6
business process model, 2-5, 2-12
business rule
modeling, 1-6
business rules, 3-1
modeling, 3-4
recording as function, 3-35
business unit, 3-31
C
change event rules, 3-4
Oracle Method
common functions, 5-17

context process diagram
elements, 2-14
context process model, 2-12
cross-functional processes, 2-53
D
data operation rules
attribute transition rule, 3-23
other update rules, 3-24
data rules
static, 3-8
dataflow diagramming, 1-7
decision points
drawing with Oracle Designer, 2-44
decisions
depicting in process model, 2-33
drawing
entity relationship diagrams, 4-23
dusiness rules
audience, 1-7
E
EBF. See elementary business function
elementary business functions, 2-26, 2-27
and process steps, 2-69
elementary business functions, 2-47
elementary function, 5-11
entity
changing names, 4-8
names, 4-7
recognizing, 4-6
Index 1
subtype, 4-17
supertype, 4-17
entity relationship diagram
layout, 4-24
entity relationship model, 1-5, 4-1
hierarchical relationships, 4-15
event, 5-17
rule triggering, 3-40
event mechanisms, 2-47
event mechanisms, 2-48
event response, 2-6, 2-24
Event response analysis, 2-46
events, 2-6, 2-20, 2-24
responses to, 2-46
types of, 2-29
external interfaces
in process modeling, 2-22
F
foreign key, 3-20
function
entity usage, 5-13
function
attribute usage, 5-16
authorized to business unit, 3-32
common, 5-17
description, 5-12
frequency, 5-12
short definition, 5-12
function hierarchy, 5-6
developing in parallel, 2-56
where to start, 5-9
where to stop, 5-9
function modeling, 1-6, 5-1, 5-3
bottom-up, 5-10
top-down, 5-10
functional scope, 2-61
functions
and processes, 2-55
common functions, 2-60
reparenting, 2-59
2 Index
H
hierarchical relationship, 4-15
M
matrices
business unit-entity/attribute usage, 3-33
business unit-function, 3-32
function-attribute usage, 5-16
function-entity usage, 5-13
N
naming
entity, 4-7
relationship, 4-14
subtype, 4-18
O
Oracle Designer
documenting business processes with, 2-36
in constructing context process model, 2-17
process modeling support, 2-9
organization units
use as agents, 2-18
other systems
diagramming, 2-22
outcome events, 2-34
P
planned response system, 2-6, 2-24
primary key, 3-15
primary processes
modeling, 2-24
primary processes, 2-13
process, 2-6, 2-24
process diagrams
complex diagrams, 2-51
hierarchy, 2-36
process flow diagram, 2-3, 2-51
process flows, 2-19
depicting, 2-33
multiple flows, 2-52
process modeling, 1-4, 3-31
downstream benefits, 2-4
primary benefits, 2-4
process steps, 2-3
continuation of, 2-52
depicting, 2-29
global, 2-42
leveling, 2-25
types of, 2-40
process steps, 2-19, 2-25
processes
single-step, 2-52
prototyping, 1-7, 6-1
other entity rules, 3-16

other inter-entity rules, 3-21
relationship rule, 3-17
restricted relationship, 3-20
tuple rules, 3-13
unique identifier rule, 3-15
stores, 2-21
indicating in process model, 2-34
subtype, 4-17
naming, 4-18
supertype, 4-17
support processes, 2-46
modeling, 2-45
system process model
deliverable, 2-7, 2-63
developing, 2-64
relationship, 3-17, 3-20, 4-12, 4-13

name, 4-14
reporting processes, 2-52
roles
using agents to model, 2-27
top-down development, 5-10

trigger events, 2-28
S
single-step processes, 2-52
static data rules
attribute rule, 3-9
domain rule, 3-12
entity rules, 3-15
format rule, 3-9
inter-entity rules, 3-17
other attribute rules, 3-13
Oracle Method
U
unique identifier, 3-15, 4-11
unique key, 3-15
user roles, 3-31
W
working sequence
model requirements, 1-4
Index 3
4 Index

CDM Vol1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CDM Vol1

Încărcat de

Drepturi de autor:

Formate disponibile

ORACLE METHODSM

CDM STANDARDS AND

CDM Standards and Guidelines Library,

Send Us Your Comments..........................................................................vii

Introduction to Requirements Modeling ............................................. 1-1

Process Modeling ..................................................................................... 2-1

The Business Process Model.............................................................. 2-5

Business Rule Modeling ......................................................................... 3-1

Requirements Modeling using Oracle Designer

Static Data Constraint Rules..................................................................... 3-8

Entity Relationship Modeling ................................................................ 4-1

Conceptual Views............................................................................. 4-10

Function Modeling................................................................................... 5-1

Requirements Modeling using Oracle Designer

Function Short Definition and Description ........................................... 5-12

Send Us Your Comments

Did you find any errors?

Is the information clearly presented?

Do you need more information? If so, where?

Are the examples correct? Do you need more examples?

What features did you like most about this manual?

Readers Comment Form vii

his manual, Requirements Modeling using Oracle Designer, provides

other SGL volumes

Oracle Custom Development Method

other system development methods

other Oracle manuals

Relationship to Other SGL Volumes

Volume 1 - Requirements Modeling using Oracle Designer

Volume 2 - Design and Generation of Mult-Tier Web Applications

Volume 3 - Building Systems using Oracle8 Programming Tools

Volume 4 - CDM Standards

Requirements Modeling using Oracle Designer

Relationship to Oracle CDM Classic and CDM Fast Track

Relationship to Other Methods

Relationship to the Oracle Manuals

How This Manual is Organized

Requirements Modeling using Oracle Designer

How to Use This Manual

Conventions Used in This Manual

or examples of computer responses to program code, for example:

Requirements Modeling using Oracle Designer

Tools: Data Diagrammer; Edit Table Table, Column Defn

Requirements Modeling using Oracle Designer

CDM Quick Tour

CDM Classic Method Handbook

CDM Classic Process and Task Reference

CDM Fast Track

CDM Fast Track Method Handbook

CDM Fast Track Process and Task Reference

CDM Fast Track Techniques Handbook

CDM Fast Track Addendum

CDM Standards and Guidelines Library

Volume 1 - Requirements Modeling using Oracle Designer (this

Volume 2 - Design and Generation of Multi-Tier Web Applications

Volume 3 - Building Systems using Oracle8 Programming Tools

Volume 4 - CDM Standards

Each of these books and their relationships to each other is discussed in

PJM Method Handbook

PJM Process and Task Reference

his chapter gives a general introduction to requirements modeling.

the goal of requirements modeling

the various requirements modeling techniques available within